This means we pick up the built services. Also we set
FLATPAK_SYSTEM_HELPER_ON_SESSION so that the system-helper
runs on the session-bus just like in libtest.sh.
Closes: #2397
Approved by: matthiasclasen
We were relying on the order of string lists obtained
from a keyfile. But the way the keyfile is constructed
involved iterating of hash tables, which doesn't guarantee
order.
This was causing test failures with GLib master.
Closes: #2375
Approved by: matthiasclasen
Rename permission-list and document-list to
permissions and documents, for consistency with
how we handle remotes. The old command names
are kept as hidden aliases.
Closes: #2131Closes: #2366
Approved by: mwleeds
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
This makes it clearer that we are not assuming that the test is running
on an x86_64.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #2353
Approved by: matthiasclasen
This adds support for fuzzy matching ref names (AKA "typo helper") to
the uninstall command to mirror what the install command has. In short,
this means you can do "flatpak uninstall gedit" instead of "flatpak
uninstall org.gnome.gedit". Flatpak will prompt you to choose between
similarly named installed refs, and will only make the choice for you if
--assumeyes was used and there's only one match.
Note that this commit does have the side effect that if there are
multiple matching refs with the same ID (e.g. with different branches or
in different installations) you are prompted to choose between them.
Previously you were shown an error message.
Closes: #2330
Approved by: matthiasclasen
If you have a pre-existing remote configured its exact definition
might differ from the one specified in a flatpakrepo file and yet
be the same.
For example, i have:
$ flatpak --user remotes -d
Name Title URL Collection ID Priority Options
flathub Flathub https://dl.flathub.org/repo/ org.flathub.Stable 1
Yet when i install a flatpakref:
$ flatpak --user install http://flathub.org/repo/appstream/org.gnome.gedit.flatpakref
The application org.gnome.gedit depends on runtimes from:
https://dl.flathub.org/repo/
Configure this as new remote 'flathub-1' [y/n]:
Because the flathub flatpakrepo does not yet have the collection id specified.
So, we need to be more lenient when matching the pre-configured remotes.
Closes: #2324
Approved by: alexlarsson
This commit adds a key called DeployCollectionID to the flatpakref and
flatpakrepo file formats, which is intended to replace the CollectionID
key (which is still supported but deprecated). The reason for the change
is the same as for the metadata key change from xa.collection-id to
ostree.deploy-collection-id, which is that old versions of Flatpak
(roughly 0.9.8 through 1.0.1 depending on compile time options) hit
various bugs when collection IDs are in use. Flathub will soon enable
the metadata key to deploy collection IDs, and this change means Flathub
can also deploy the collection ID in flatpakref and flatpakrepo files
without affecting old clients.
Adding DeployCollectionID to the flatpakref and flatpakrepo files will
mean the flathub remote can be automatically configured with a
collection ID without depending on the metadata key to do that.
Closes: #2329
Approved by: alexlarsson
Currently if the user doesn't specify a remote name to the install
command, Flatpak chooses the first one that has a matching ref, either
with or without user interaction depending on whether --assumeyes/-y was
used. Then if more than one remote ref is similar to the one specified,
the user is prompted to choose between them. I think this asymmetry
doesn't make much sense; why not have the user choose between remotes
just as they choose between refs?
For example, the string "libre" matches refs from both flathub and
eos-apps, so if I do "flatpak install -y libre" a remote is arbitrarily
chosen for me but I'm still prompted to choose between the refs (since
-y can't choose for you when there are mutliple choices).
So this commit changes the install command implementation to present the
user with a list of remotes that have matching refs all at once rather
than one at a time. The reason I didn't implement it this way at first
is that I was worried about the performance impact, but in testing I'm
not able to measure a difference between stopping at the first remote
with a match and checking every remote (although the story might be
different if you have many remotes or don't have up-to-date metadata
downloaded).
If there's an error searching a remote, it's treated as a warning so
that one misconfigured remote doesn't take down the whole operation with
it.
This commit also updates the unit tests so they continue to succeed.
Closes: #2288
Approved by: matthiasclasen
Currently the install command requires the user to specify the remote
name in addition to each ref that is to be installed. This commit
implements an auto-detection feature so that the user can specify only
refs (or partial refs) and Flatpak will try to determine the remote to
use.
The Flatpak security model does not consider all remotes equally
trustworthy, but that's okay because the user is asked to confirm the
remote choice before it's used.
The way it's implemented is that we look at only the first ref (even if
there are several) and iterate through each remote in each installation
trying to find it, stopping at the first one where it's found and asking
for confirmation of it. There's a trade-off here between efficiency and
accuracy, since it could be pretty costly to search every remote in
every installation. I think this should be good enough for most use
cases, and the user is still free to specify a remote and avoid that
code path.
This should hopefully save people a bit of typing and make the Flatpak
CLI a bit friendlier.
Closes: #2113
Approved by: matthiasclasen
This commit implements a "typo helper" for the install command, so that
if you don't get the app ID exactly correct you're prompted with
similarly named apps available in the remote that you can choose from.
Essentially this allows you to do "flatpak install flathub devhelp"
instead of "flatpak install flathub org.gnome.Devhelp".
The choice is only made for you in two cases: 1. If it's an exact match
and there's only one match, it is used as before this commit. 2. If the
-y/--assume-yes option was used and there's only one match, it is used.
Presumably scripts would always specify the full app ID, so this should
only affect users on the command line who choose to use that option.
In the future we may want to use the groundwork laid in this commit to
add similar functionality to other commands, like perhaps remote-info
and run.
This is a partial fix for https://github.com/flatpak/flatpak/issues/1258Closes: #2113
Approved by: matthiasclasen
We now avoid sleeps in the test, instead use the proper
ways to deal with races: poll for the child pid after
launching the app, and use a child watch after killing
it.
This is using the new flatpak_installation_launch_full API.
Closes: #2221
Approved by: matthiasclasen
This adds the logic from test_install_launch_uninstall() to
test_instance() and test_overrides() so that all three are skipped in CI
environments where bwrap may not be working. This is necessary because
they all use flatpak_installation_launch().
Currently `make distcheck` fails with:
PATH=$(cd . && pwd):${PATH} tests/make-test-runtime.sh
tests/runtime-repo org.test.Platform ""
/bin/bash: tests/make-test-runtime.sh: No such file or directory
This was caused by commit b5d86fe90 and is fixed by this commit.
I had a report of (and old version of) flatpak stopping
an entire "flatpak update" because one app had a new required
version. This adds a test of this (and it seems fixed now).
The tests added here include checks for expected types in
the library (including enum types that are needed for
introspection), and for error handling around names.
Closes: #2245
Approved by: alexlarsson
One of the transaction tests contains the situation
that was modified in the previous commit. Update it
to expect the new behavior. At the same time, add
some comments to the tests to guide the reader.
Avoid the initial sleep statement, and instead poll
for the child pid.
We also need the test app to stick around and not
exit right away, so change it to exec a shell.
Give the test app a Locale extension, so we can test
things around related refs and subpaths. Fix up the
library tests to work with a related ref in the repo.
