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 script doesn't work anymore and it's not clear that it's worth
maintaining since no one seems to be using it.
Closes: #2788
Approved by: matthiasclasen
Currently a FlatpakTransaction object only operates on one installation,
but uses others (by default the system installations) for dependencies
such as runtimes. In addition to checking those dependency installations
for runtimes we check their configured remotes when deciding whether to
add a new remote as an origin for a flatpakref or as a runtime remote
for a flatpakref. This commit changes the behavior so that we only check
the installation being operated on to find out if a remote already
exists. This is the correct behavior in both cases: the origin remote
and the runtime remote. Otherwise the installation can error out when it
fails to find the runtime, or it can fail to respect the
SuggestRemoteName key which is supposed to dictate the name for the
origin remote.
One side effect of this is that a remote might be duplicated in the user
installation which already exists in the system installation, even if
the runtime it provides is already installed. But if you don't want
remotes in multiple installations you can just stick to using one
installation consistently.
Also, add a unit test for this in testlibrary.c (which required a bit of
refactoring).
Fixes https://github.com/flatpak/flatpak/issues/2758Closes: #2761
Approved by: alexlarsson
Currently Flatpak has a few different implementations of helper
functions to download a URI using libsoup, but the best one seems to be
in common/flatpak-utils-http.c. So this commit deletes the others and
makes use of flatpak_load_http_uri() in place of download_uri() in a
few places. This has a couple consequences:
1) It means that we're now properly checking HTTP status codes rather
than assuming that the request was successful, in the install command,
remote-add command, and in FlatpakTransaction. This fixes an assertion
failure seen by a user when they tried to use a flatpakref URL that hit
a 404.
2) It means that in the places where we're using flatpak_load_http_uri()
we are only supporting http:// and https:// URLs not, say, file:// ones.
For the install and remote-add commands this was already being enforced.
For the handling of flatpakref files and bundles in FlatpakTransaction,
I believe it's just convention because it doesn't make much sense to
do anything else; this commit enforces that convention.
Also, add a unit test for the case of trying to install a flatpakref at
a URL that hits a 404 error.
Fixes https://github.com/flatpak/flatpak/issues/2727Closes: #2740
Approved by: matthiasclasen
Uncrustify has an option "nl_func_var_def_blk" which is supposed to
ensure there's a newline character between the block of variable
definitions and the rest of the function body, but it gets confused and
thinks that the first instance of "g_autoptr" or "g_auto" being used on
a variable is the start of the function body. So this commit removes
those extra newline characters and removes that option in uncrustify.cfg
so they don't get re-added the next time uncrustify is run.
Here's the command I used:
perl -0777 -i -pe 's/\n(\n\s*g_auto\()/\1/g' `git ls-tree --name-only
-r HEAD | grep \\\.[ch]$ | grep -v common/valgrind-private.h |
grep -v app/flatpak-polkit-agent-text-listener\\\.[ch]`
I ran it again with "g_autoptr" in place of "g_auto", and made a few
manual edits to add back the newline when the g_auto* was in the middle
of a function body rather than at the top.
Closes: #2715
Approved by: matthiasclasen
We only interested in a few of the attributes of some
tags, but we shouldn't fail if other valid attributes
are present.
Add some of the allowed attributes to the <release> element
in the appdata test and verify that we can still parse it.
The appstream spec is here:
https://www.freedesktop.org/software/appstream/docs/Closes: #2674
Approved by: matthiasclasen
During build-time tests, bwrap doesn't necessarily work. In particular,
official Debian autobuilders can't enter namespaces.
We continue to leave the sandbox enabled in the build-export calls in
tests/test-extensions.sh, tests/test-unsigned-summaries.sh
and tests/test-update-remote-configuration.sh, which are already
skipped if bwrap isn't available. This means we exercise both the
normal and --disable-sandbox code paths.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #2661
Approved by: alexlarsson
These were part of the flatpak-builder tests, and are no longer
distributed in tarballs or used by Flatpak's tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2607
Approved by: matthiasclasen
The compatible architectures are not symmetric: x86_64 and aarch64 can
run i386 and arm binaries, but i386 and arm cannot usually run x86_64
and aarch64 binaries.
This caused test failures on Debian i386 autobuilders.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2603
Approved by: matthiasclasen
The generated DBus permission header is included by an header in under
app/ that we include from testcommon.c. We already added the app/
directory under the source directory, but we need to include the same
directory under the build directory in order for the compiler to find
the generated header.
Fixes the build in GNOME Continuous, which is failing with:
```
In file included from ../tests/testcommon.c:10:0:
../app/flatpak-builtins-utils.h:28:47: fatal error: flatpak-permission-dbus-generated.h: No such file or directory
compilation terminated.
```
This tests the situation when we can't accommodate
the requested width with the available shrinkage.
This used to cause an infinite loop in the table
printer.
Closes: #2498
Approved by: matthiasclasen
Add another test that links against libflatpak-common.la
and tests functions that are not part of the public
library api.
Closes: #2498
Approved by: matthiasclasen
test-info.sh was needlessly relying on the exact output
of flatpak info --show-extensions. Update it to match the
new output.
Closes: #2502
Approved by: alexlarsson
I was seeing some issues because make check was
picking up a custom installation that was defined
in /etc/flatpak/installations.d/ on my system.
Avoid that by pointing FLATPAK_CONFIG_DIR at
a non-existing place.
Closes: #2534
Approved by: alexlarsson
Use only the last section in the id for origin remotes, to avoid
the origin column being really wide when listing stuff.
Closes: #2448
Approved by: alexlarsson
These were relying on details of the remote-ls output.
We can avoid this by explicitly specifying what columns
we want.
Closes: #2409
Approved by: alexlarsson
test-repo.sh was needlessly assuming that the application ID
is the first column in flatpak list -d output. Other tests
don't do the same. This is why test-repo.sh was broken by
the addition of the description column in list output.
Change the test to remove that assumption.
Closes: #2409
Approved by: alexlarsson
