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
Revamp the FlatpakCliTransaction output to be closer to this:
https://github.com/flatpak/flatpak/wiki/CLI-experimental-design
We only do this style of formatting when fancy output is possible.
For plain output, we don't redraw the table and only use '\r'
to rewrite the progress line in-place.
Closes: #2371
Approved by: alexlarsson
This avoids a crash or deadlock if the timeout is reached during test
teardown, after the GMainLoop has already been freed. That appears to
be more likely to happen when run as an installed-test.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: https://github.com/flatpak/flatpak/issues/2422Closes: #2425
Approved by: matthiasclasen
The uninstall command supports the syntax "flatpak uninstall
org.gnome.Builder stable" as an alternative to "flatpak uninstall
org.gnome.Builder//stable", but this support was broken by the fuzzy
matching (partial ref) feature. Since that syntax only supported full
app IDs not partial ones, assume it's being used if the first argument
is a full app ID and the second argument looks like a branch. This means
we don't support the syntax "flatpak uninstall builder stable" (unless
you're trying to uninstall an app called stable).
Similarly, fix the install command's support for the syntax "flatpak
install flathub org.gnome.Builder stable".
Also, add a unit test for both of the above.
Fixes https://github.com/flatpak/flatpak/issues/2395Closes: #2405
Approved by: matthiasclasen
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
