flatpak currently installs a gdm env.d and a bash profile.d file to
ensure XDG_DATA_DIRS is set to the right value. Neither is sufficient
when the dbus daemon is activated as a system --user service.
This commit adds a dbus service file snippet to frob its environment
variable for that case.
When the document portal is called from within the sandbox with an
app-private file path, translate the path to a document portal URI in
order to make it available to other applications.
This lets distributors share a system copy of bubblewrap (>= 0.1.0)
between Flatpak and any other projects that benefit from it, if they are
careful to keep new versions in sync. The default is still to use the
bundled submodule, ensuring compatibility and simplifying dependencies.
Enable $PATH search everywhere that runs bwrap, so that $BWRAP doesn't
necessarily need to be a fully-qualified path.
Signed-off-by: Simon McVittie <smcv@debian.org>
We shouldn't install .test metadata for these, and run them as TAP
test scripts. In glib-tap.mk jargon that makes them "extra scripts".
Signed-off-by: Simon McVittie <smcv@debian.org>
As explained in bubblewrap commit f6ca3690, libraries should
always go in LDADD and not LDFLAGS, because the order of arguments
to the linker matters. Many distributions' linkers are tolerant
enough that it doesn't matter in practice, but it matters for
static linking, and it might also matter on Ubuntu.
Signed-off-by: Simon McVittie <smcv@debian.org>
Listing variables whose values are conditional in EXTRA_DIST is
problematic: if Flatpak was configured without installed-tests,
we would not distribute those files. This is a problem during
distcheck, where installed-tests are disabled.
For files not placed in a special subdirectory, glib-tap.mk handles
this for us. For the keyring and the databases, we have to do it
ourselves, by arranging for them to be in a dist_ variable that is
special to Automake - when determining what to distribute, Automake
includes anything that is selected for distribution under any
combination of conditionals.
While I'm here, include test keyring's README in tarballs: its advice
is equally applicable in a tarball release.
Signed-off-by: Simon McVittie <smcv@debian.org>
According to the FHS, applications which place internal libraries in
/usr/libexec should not also use /usr/lib for this purpose:
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
As several flatpak helpers are already installed in libexecdir, move
the bwrap helper to /usr/libexec/flatpak-bwrap.
Bubblewrap is a new tool from project atomic. Its similar to the old
xdg-app-helper, but even more minimal, and a bit more generic. Its designed
to be easy to git submodule install, but at some point we will probably
support using the system installed version too.
Using bubblewraps lets us share the load of security mainainance and
allows other people to use bubblewrap to do their own unprivileged
sandboxes.
The FHS specifies a limited number of subdirectories for /var,
which do not include xdg-app. Packaging systems like RPM and dpkg
use a subdirectory of /var/lib, so it seems appropriate for system-wide
xdg-app runtimes and apps too.
Signed-off-by: Simon McVittie <smcv@debian.org>
This avoids exporting glnx_*, calc_sizes(), etc. However, we do want to
export xdg_app_error_quark(), so do that.
Signed-off-by: Simon McVittie <smcv@debian.org>
This is a highlevel library for working with xdg-app without using
the commandline interface. The primary usecase for this is for
creating a graphical frontend for app installation/update.
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.
Cosimo Cecchi