For the portal's use of --env-fd= to be safe, we want the environment
variables that it sets to end up in the environment for the program
that is run by `bwrap` as process 2, but they must not go into the
environment that gets used to run `flatpak run` or `bwrap`. Assert
that this is the case.
For completeness, we're testing both --env= and --env-fd= here,
even though the earlier commit
"portal: Do not use caller-supplied variables in environment"
always uses --env-fd=.
Part-of: https://github.com/flatpak/flatpak/security/advisories/GHSA-4ppf-fxf6-vxg2
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it possible to cherry-pick improved test coverage from newer
branches without having to edit it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Support a list of versions that are supported. This will be useful
for e.g. the extra_data for extensions once that is backported to
1.2, because that will require it to say that it is supported for
> 1.2.5 in the 1.2 series and > 1.4.2 otherwise.
Closes: #3112
Approved by: alexlarsson
(cherry picked from commit 5026f01153)
(cherry picked from commit 9bbe6fbb48)
Closes: #3115
Approved by: alexlarsson
This sets required-flatpak in the metadata to some different versions
and ensure we're properly able or not able to install it.
Additionally it uses some options with multiple versions. This is not
yet supported but I want to test the existing code and make sure it
properly falls back to just using the first element of the list.
Closes: #3112
Approved by: alexlarsson
(cherry picked from commit 62117308c1)
(cherry picked from commit 5db4631a79)
Closes: #3115
Approved by: alexlarsson
Currently if you have a remote configured with the URL
"https://dl.flathub.org/repo/" (as you would if you use the flatpakrepo
file) and you use a flatpakref file which specifies the URL
"https://dl.flathub.org/repo", Flatpak tries to add a duplicate remote
because it doesn't see those URLs as equal. So ignore the trailing slash
when comparing remote URLs. OSTree works equally well with both kinds
(it uses g_build_filename()).
Flathub served flatpakref files with URLs missing a trailing slash until
this commit:
https://github.com/flathub/ansible-playbook/commit/b20694f09
Also, add a unit test that fails without this patch.
Fixes https://github.com/flatpak/flatpak/issues/2979Closes: #3065
Approved by: alexlarsson
(cherry picked from commit 866ba643d2)
Closes: #3115
Approved by: alexlarsson
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
