This sets FLATPAK_FANCY_OUTPUT=0 in most tests and then special cases
the test_fancy_output() test in case the installable tests are running
on an actual tty. This was causing failures because the added bold escapes
caused some test cases to not generate the expected output.
Closes: #2907
Approved by: alexlarsson
This is basically modify_remote, but it fails if the remote is
already configured instead of modifying it. Although it also
has a if_needed option, and if that is set it will silently complete
as a no-op (exept resetting filters).
Closes: #2888
Approved by: alexlarsson
We still look at the regular file to pick up changes, but to avoid
issues if the file disappears (for example if it was in a package
that was uninstalled) then we still have something to show so we don't
start accidentally showing unfiltered stuff.
Closes: #2890
Approved by: alexlarsson
This test is meant to test the issue described in the message for the
commit "dir: Use the right keyring to verify P2P pulls".
Closes: #2705
Approved by: alexlarsson
There's not much point in using /bin/bash for all but three scripts and
using /bin/sh for those, so use bash for everything.
Closes: #2705
Approved by: alexlarsson
A *.flatpakrepo file in this directory will be automatically
added as a system remote with the basename (sans extension) as the
name unless that name already exist. Also, once this is done we
record the name in the repo config so that it is not applied again if
the remote is removed.
Closes: #2884
Approved by: alexlarsson
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
