The GLib logging framework automatically appends a \n to messages, so it
doesn’t need to be added by callers.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
For example, add $(AM_CFLAGS) to mumble_CFLAGS. Since $(WARN_CFLAGS) is
only added to $(AM_CFLAGS), this fixes the lack of inclusion of the
compiler warning flags in the compilation of half of flatpak.
Note that $(AM_*) variables are only used by automake if a more specific
(per-target) special variable is not defined instead. So if you define
mumble_CFLAGS, AM_CFLAGS will not be used for that target unless
explicitly included in mumble_CFLAGS.
See
https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html.
Do the same for $(AM_LIBADD), $(AM_LDFLAGS), etc. These are not
currently defined, but it’s good practice to include them in
mumble_LIBADD (etc.) just in case they’re defined in future. Hopefully
their inclusions will be cargo-culted to any new targets which are
added, retaining full coverage of the code base.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Just because stdout/stderr happen to be going to a terminal doesn't
necessarily mean that we want the command launched by HostCommand
to take ownership of the terminal - in the case where 'flatpak run'
is launched from a terminal, stderr will typically be left pointing
to the terminal for any command. In that case the terminal already
has a controlling process, and TIOCSCTTY will fail; avoid scary
messages by making the failure only a g_debug()
This was using the "from" fd from the fd_map, which will have already been
closed by time we reach this portion of the child setup.
Tracking the movement of FDs while resolving the remappings is rather
tedious and error prone, so just locate the final fd before calling
the ioctl() in child setup.
This is needed by e.g gnome-builder that want to pass this pid to
a profiler service. Its not really less secure/sandboxed this way,
because the app can launch whatever he wants in the host, which could
anyway talk back and report the real pid.
This lets any client, possibly in a sandbox if it has access to the
session helper, spawn a process on the host, outside any sandbox.
Clearly this is not something you typically want a sandboxed app to
do. However, it is sometimes very useful when using flatpak mainly
for distribution. For instance, an IDE needs to use this to launch a
flatpak build operation inside the sandbox. (Because otherwise recursive
calls to flatpak will not work.)
Using the bus name as the name of the service file is mandatory
for system services, and recommended for session services.
Signed-off-by: Simon McVittie <smcv@debian.org>
This moves a all source code into separate subdirs per binary. The
helper and the generic stuff goes into lib/ which is then used by all
the others. For now this is a completely internal library, but at
some point we will probably clean it up and expose some subset.
Also, we move the dbus proxy to libexecdir.
Matthias Clasen