This test effectively assumed that ${test_builddir} is in /home, /opt,
a non-FHS top level directory, or some other directory that isn't
in dont_mount_in_root[] in flatpak-run.c. In a distro build where
${libexecdir} is below /usr, when running the installed-tests
so ${test_builddir} is ${libexecdir}, this assumption doesn't hold.
We can't just copy the file we're dealing with into a subdirectory
of /tmp or /var/tmp either, because those directories aren't
part of --filesystem=host. Meanwhile, we also don't want to pollute
$HOME with test detritus.
For the best possible coverage given all those constraints, we try
three directories: ${test_builddir}; ${TEST_DATA_DIR}, which is
in /var/tmp; and ~/.flatpak-tests, but only if it already exists.
When testing --[no]filesystem=host overrides, we don't even try
${TEST_DATA_DIR}, because we know it's in /var/tmp which can only
be shared explicitly, but we do try the others.
Signed-off-by: Simon McVittie <smcv@debian.org>
This gives the application full access to the host /dev. Obviously
this is not great in terms of sandboxing, but its nice for applications
that use flatpak mostly as a way to do distribution of the app.
Also, its not like the app has full access to anything, its still
limited to the access right of the user.
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>
This avoids hard-coding the (potentially absolute) srcdir used at
autogen time into the build system. It's fine for an Automake build
system to use relative paths in dependencies and rely on them being
interpreted as relative to ${srcdir} even though the current working
directory is ${buildddir}, because of make's "VPATH" feature, and we
do it all the time in the handwritten parts of the build system.
In particular, this (finally) makes distcheck work.
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>
Linearize the tree of modules and submodules when the modules
are set on the manifest, while filtering out disabled modules
at the same time.
Skip source-less modules when building; this makes it possible
to have modules that only contain submodules.
With this approach, we use the tree structure of modules for
serializing and deserializing to and from json, while using
a linear list of modules for building.
