This means only refs that are allowed will be visible in the deployed
appstream.
This sometimes means we have to uncompress the xml.gz before rewriting
and then re-compressing that.
As a result of this we now always end up with both the compressed and
the uncompressed xml file, whereas we before didn't get an uncompressed
one if the remote was using the old appstream format.
Closes: #2869
Approved by: alexlarsson
Instead of combining name and comment we split them into two columns.
We also disable the comment column by default for list and remote-ls
as it is very poor in long tables. However, it is still there for search
where it seems more useful.
Also, the Application column title changed to Application ID to make
it clearer what it is compared to the "Name" column.
Closes: #2852
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
This follows the same logic as the system bwrap.
Otherwise, build-time tests will fail when we are using a system
xdg-dbus-proxy and not compiling our own (the symptom is that testlibrary
hangs).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2823
Approved by: matthiasclasen
This tests that we pick a new version, that the old is uninstalled
and that when running it old data is migrated.
Closes: #2775
Approved by: alexlarsson
This copy-pastes a lot of internal code from flatpak-dir.c to mess with
the deploy file. It could be made a lot shorter...
https://phabricator.endlessm.com/T23845Closes: #2775
Approved by: alexlarsson
When installing via the child repo we now strip the permissions early
so the import will fail instead of import and then canonicalize.
Either is ok, as nothing should be non-canonical in real life.
Closes: #2657
Approved by: alexlarsson
In the normal case, pass the full LIBEXEC path, and in the tests,
pass the path via the env var FLATPAK_REVOKEFS_FUSE.
Closes: #2657
Approved by: alexlarsson
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
