This adds new FlatpakTransaction API, and a new top level CLI command to
preinstall flatpaks, that is to install flatpaks that are considered
part of the operating system.
A new drop-in directory /etc/flatpak/preinstall.d/ allows configuring
what apps should be preinstalled, and a new flatpak preinstall command
installs and removes apps based on the current configuration.
A drop-in loupe.preinstall file can look something like this:
[Flatpak Preinstall org.gnome.Loupe]
Branch=stable
IsRuntime=false
The corresponding API is flatpak_transaction_add_sync_preinstalled()
which can be implemented by GUI clients to drive the actual installs
on system startup.
Resolves: https://github.com/flatpak/flatpak/issues/5579
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
I was trying to get the `flatpak` for Chimera Linux template to run
tests. However, due to Chimera Linux using core utilities based on
FreeBSD's, some stuff used in the test shell scripts didn't work there
and caused issues. While I eventually gave that endeavour up, I wanted
to upstream the upstreamable changes I had anyway.
Otherwise, tests for OCI and the update portal fail with:
/usr/libexec/installed-tests/Flatpak/libtest.sh: line 611: FUSERMOUNT: unbound variable
Fixes: 2cb17b4e "Do not hard-code fusermount, add option or auto-detect instead"
Signed-off-by: Simon McVittie <smcv@collabora.com>
The hard-coding is not appropriate. According to libfuse 3.0.0 release
notes: "The fusermount and mount.fuse binaries have been renamed to
fusermount3 and mount.fuse3 to allow co-installation of libfuse 2.x
and 3.x". Some distributions seem to install a symlink, but this is
not upstream's default behavior.
In addition, fusermount might be provided from non-distro sources. So
a build-time option takes precedence over auto-detection logic.
Fixes#5104Fixes#5694
Meson's TAP parser is more strict than the one in Automake, and will
not accept and ignore arbitrary output.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As discussed in #4848, this disables fuzzy matching entirely if stdin or
stdout is not a tty, meaning that something like "flatpak install
firefox" would be treated as incorrect syntax, since this syntax is
intended for interactive CLI use. Even before this commit, "flatpak
install firefox" would error out if run without a tty, since we don't
automatically choose a matching app ID even if there is only one match.
However "flatpak install -y firefox" could work before, but won't any
more. People should be specifying the full app ID in any context other
than a tty.
This commit also introduces a new env var so the unit tests can continue
to check the fuzzy matching behavior, despite them being run without a
tty.
We weren't distinguishing here between overrides that should have been
negated (xdg-documents) and overrides that should not have been negated
(everything else).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This fixes a few issues with the unit test logs that make them ugly:
1. Currently some lines of output from a command will appear after the
line from xtrace which has the next command, since the command was
printing to stdout and xtrace uses stderr. E.g. "Installation complete."
will appear after "+ flatpak --user install -y ..." but it is from the
previous install command.
2. Lines of output have many spaces after them to pad them to the table
width but this is not needed for non-fancy output.
3. Lines of output are mixed with output from httpd since they don't end
with a newline character, e.g. "Installing… ▊
4%127.0.0.1 - - [16/Nov/2021 00:18:24] "GET /..."
This gives new support for the new XDG_STATE_HOME addition to XDG_BASE_DIRS
which allows applications to use this without breaking because they would
assume $HOME/.local/state which may be unavailable to the flatpak
This adds it as .local/state as to make --persist=.local/state the same behaviour
as in new flatpak. This in turn means that the transition should be seamless between
old and new flatpak.
This also has the benefit of working if the application doesn't follow XDG spec thanks
to --persist=.local/state.
This fixes https://github.com/flatpak/flatpak/issues/4477
[smcv: Don't call nonexistent g_get_user_state_dir(); fix a reference
to XDG_STATE_DIR]
If the tests are run as root, the system helper is not used even when
commands are run with `--system`. This means a different cache path is
used (see `_flatpak_dir_ensure_repo()`). The tests did not accommodate
for that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We enforce --no-update-summary when we create test apps and
runtimes, and then we ensure we always manually call update_repo
after all modifications are done.
This means we save work avoiding summary updates, but it also means we
can do special handling in update_summary and guarantee that this is
the only place this happens. For example, we want this to work around
the mtime handling of summary updates.
The code to use the pre-generated test platform was buggy so it wasn't
used. Also, generate a "stable" branch of it too as that is used
by test-run.sh.
We normally don't remove a runtime when the last app using it is
uninstalled, since runtimes are large and re-downloading it in the
future may be difficult. But if the runtime is end-of-life, there's a
reasonable chance it won't be used again, so uninstall it in that case.
Similarly, if the last app using a runtime is upgraded to a different
runtime, and the runtime is EOL, uninstall it.
A unit test is included, and the subsequent unit test also had to be
modified. Otherwise we get a "Update is older than current version"
error, since the runtime is installed from test-repo but
setup_repo_no_add() calls make_runtime() which uses the one in
runtime-repo instead, which is older than the one in test-repo.
Re-implement flatpak_installation_list_installed_refs_for_update() using
a FlatpakTransaction, so we can guarantee it always gives the same set
of things to update as the update command. This API is used by GNOME
Software and many times in the past g-s has not shown the same list of
apps to be updated as the flatpak CLI. See:
- https://gitlab.gnome.org/GNOME/gnome-software/issues/539
- https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/430
This commit also expands the unit tests for this API, which were already
quite good. Now we test that missing subpaths of locale extensions show
up as updates, and updates that have been pulled but not deployed show
up as well. The latter is a break from how this function used to behave,
but it seems unlikely to break any application.
Instead of having a global config option we scan a directory for
symlinks into the sideload repos. These come from
/var/lib/flatpak/sideload-repos and /run/flatpak/sideload-repos (for
default system installation).
This is much easier to update atomically, and the two different
options are useful for persistant (the first) or dynamic (the second)
usescase.
Fixes https://github.com/flatpak/flatpak/issues/3494
We use the localcache-repos option to ostree_repo_pull to make ostree
directly import any files that are locally available in the sideload
repo even when pulling the main commit from upstream.
This also adds a test that verifies that such files are not
pulled via http.
We use some BASH_XTRACEFD hackery to hide the trace output from
the internals of the assert (and ok) functions, so that the
log output can focus on what is important, i.e. what asserts are
checked and what errors do they print.
Rather than this weird shell loop with a timeout and polling we
move the httpd spawning entirely into the python code, and use
a pipe to synchronize the spawning. This way we can also use
the shell job control to properly clean up any running processes
from the test suite.
Additionally, this adds some (lame) support for token handling in the
test webserver, where you for any file foo can create a foo.need_token
containing a token that is needed for that file.
We add socat to the test runtime, and then we use that to run a
test app outside the sandbox as if it was inside.
The testcase connects creates a monitor and ensure we properly get signals
for updates.
This sets FLATPAK_FANCY_OUTPUT=0 in most tests and then special cases
the test_fancy_output() test in case the installable tests are running
on an actual tty. This was causing failures because the added bold escapes
caused some test cases to not generate the expected output.
Closes: #2907
Approved by: alexlarsson
This test is meant to test the issue described in the message for the
commit "dir: Use the right keyring to verify P2P pulls".
Closes: #2705
Approved by: alexlarsson
A *.flatpakrepo file in this directory will be automatically
added as a system remote with the basename (sans extension) as the
name unless that name already exist. Also, once this is done we
record the name in the repo config so that it is not applied again if
the remote is removed.
Closes: #2884
Approved by: alexlarsson
On some systems we can't make use of FUSE, especially on the same
locked-down systems where distribution packages are typically built.
For example, official Debian autobuilders (buildds) are configured to
disallow module loading after boot has finished as a form of security
hardening, some build chroots don't have a valid /etc/mtab, and Docker
containers give us uid 0 but not CAP_SYS_ADMIN.
These checks are taken from libostree.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2824
Approved by: matthiasclasen
Currently when the user doesn't specify a branch to the run command, for
apps it will use the current branch and for runtimes it just tries to
use "master" and fails if that doesn't work. Since runtimes don't have
current branches, it would be nice if we could determine the right one
to use rather than just erroring out. So this commit changes the
implementation so that it looks at each installed runtime and if only
one matches it is used. If there's more than one match the user is
prompted to choose. This is the first interactivity added to the run
command but I don't think that's an issue; any time it's run in a
non-interactive shell it will error out upon encountering ambiguity.
Also, add a couple unit tests for the success path and error paths.
Fixes https://github.com/flatpak/flatpak/issues/2780Closes: #2788
Approved by: matthiasclasen
This commit makes it so that a unit test can create the test app and
runtime using a branch other than master, and changes test-run.sh to use
the branch "stable". This will allow the run command to be tested better
in the following commit.
Closes: #2788
Approved by: matthiasclasen
This requires some new mechanisms: now we're skipping individual tests,
not just whole test scripts.
There are two main reasons why autobuilder environments might not be
able to run these tests successfully, both of which apply in Debian.
Tests that rely on bwrap typically can't pass in builds that take place
in a chroot, because bwrap's use of pivot_root() assumes that the root
directory is a mount point, but a chroot will typically have an unpacked
directory somewhere below the mount point as its root.
Some autobuilder environments are also sufficiently restricted that they
can't create new user namespaces at all, as a way to harden the
autobuilder host.
As a result, Debian autobuilders can't run the majority of the Flatpak
tests. We would like to be able to continue to run the subset that don't
need bwrap, to have the best test coverage we can. For the rest we have
to rely on installed-tests (which I've wired up to Debian's autopkgtest)
rather than using build-time tests.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #2339
Approved by: matthiasclasen
