This adds variable support for collection IDs: they can either be
enabled on the server, on the server and client, or not at all. If
enabled on the server, apps and runtimes are built with collection IDs
and the repository has one set. If enabled on the client, the remote
config is added to the local repository with a collection ID and GPG
verification enabled. They are controlled with
USE_COLLECTIONS_IN_{SERVER,CLIENT}={yes,no}.
These variables are used in the new wrapper tests,
test-repo-collections.sh and test-repo-collections-server-only.sh.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to provide a transition path for repositories to add collection
IDs to themselves and propagate those collection IDs to clients’ remote
configurations, add another repo config key which controls whether the
repository’s collection ID is published. If xa.collection-id is set in
the repo’s published metadata, the client will update its configuration
to the given ID — but only if no ID is set already. This is a one-time
transition to prevent malicious repositories from remotely changing the
user’s configuration to associate their remote with a well-known
collection ID they don’t own.
Add a test for this.
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>
Any build-args specified in the manifest should be used during the
cleanup and platform-cleanup stages. This is because if you are using
QEMU to build for another architecture, for example, you need to pass
--bind-mount in the build-args, and the bind mount also needs to be
present while running cleanup commands.
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>
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.
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>
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.
This uses various environment variables set during make check
to find the trigger, bwrap and xdg-app-dbusproxy from the build/source dir
rather than the installed location.
Alexander Larsson