Use FLATPAK_TESTS_VALGRIND_LEAKS to check for leaks.
We're not currently passing the leak checks, so this helps letting
us make valgrind checks useful.
This means we don't have to add it to EXTRA_DIST, and also means
we can have generated (non-distributed) test data in future if we
want to.
Signed-off-by: Simon McVittie <smcv@debian.org>
In autobuilder environments that deprive the build of capabilities,
it is entirely possible that we have a system bwrap(1) but cannot
run it, for example because CAP_SYS_ADMIN has been excluded from
the capability bounding set. Tell the tests which bwrap we are
going to run, so we can run it in a simpler way and see whether
it works.
Debian's sbuild autobuilder currently suffers from a different
issue in which pivot_root(2) returns EINVAL, possibly caused by
sbuild being chroot-based and so not having the mount point
structure that is required for pivot_root. This avoids the
problematic build-time tests there too; they work on ci.debian.net,
which uses lxc instead of chroots, and in virtual machines.
Because $(BWRAP) might be non-absolute, we need to search PATH for it.
Signed-off-by: Simon McVittie <smcv@debian.org>
An assertion failure that says res is FALSE is a lot less useful
than an assertion failure that says we got a specific GError.
Signed-off-by: Simon McVittie <smcv@debian.org>
This catches regressions in the fix in the previous commit, where old
stale .py[oc] files can wrongly become "unstale" when we change the
.py file mtime to 1.
dbus-launch is X11-specific and contains a lot of legacy code to
support X11 autolaunching. It should not be part of the Wayland
(and/or Mir) future.
Start a dbus-daemon directly instead.
One of the variations tested on Debian's reproducible build
infrastructure is that the second build is done in a French locale.
This test fails there, because it doesn't see "Usage:" in the help.
Signed-off-by: Simon McVittie <smcv@debian.org>
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>
Otherwise, service activation will start a new xdg-document-portal
(because we're using a private DBUS_SESSION_BUS_ADDRESS), but because
XDG_RUNTIME_DIR is shared with the real system, it won't be able to
mount its filesystem.
We need to unmount the document portal before removing the private
XDG_RUNTIME_DIR.
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>
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>
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>
