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>
Due to an issue with ostree (https://github.com/ostreedev/ostree/pull/362)
applying non-from-scratch deltas fail when using parent_repo such as
in the system-helper case. We fix this temporarily by disabling the
use of deltas for that case.
The xdp-impl-dbus.h header no longer exists - it came from an
earlier version of the document commands branch where I introduced
a separate interface. Just drop the include, it is not needed.
This adds --forbid-read, --forbid-write, --forbid-delete and
--forbid-grant-permissons options to flatpaks document-export
command, to let it revoke permissions on exported documents.
We want to let the flatpak command show more information.
These functions will not be allowed from inside the sandbox
to prevent leaking information to sandboxed applications.
Lookup: go from a file (handed in via an fd) to a document id
Info: return origin and permissions for an id
List: return information about all exported documents
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>
Simon McVittie