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 af4504c8d3)
We were only handling the old single-value 'version' key, even though
we handled the 'versions' key when finding remote related refs.
The result of this was that some extensions, such as the 19.08 opengl
default one was installed by default (as it was found as remote related)
yet still removed with --unused (as it was not locally related).
Fixes https://github.com/flatpak/flatpak/issues/3004Closes: #3093
Approved by: mwleed
(manually cherry-picked from commit e4b1d16b7d)
This puts the checksum autoptr in the inner scope of the loop where
it gets assigned to avoid leaking all but the last iteration value.
Closes: #3093
Approved by: mwleeds
(cherry picked from commit ca72dd5474)
This prevents a crash in flatpak_installation_list_remotes_by_type() if
the `FlatpakDir` can’t ensure it has a repo configured.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #3028
Approved by: alexlarsson
(cherry picked from commit 791f31898b)
If the download URL for an icon was already cached locally, the HTTP
code returned FLATPAK_OCI_ERROR_NOT_CHANGED - this was treated as a real
error, and after downloading missing icons, all present icons were
deleted!
See https://bugzilla.redhat.com/show_bug.cgi?id=1683375Closes: #3048
Approved by: alexlarsson
(cherry picked from commit a794c07e18)
Unfortunately in commit 253fcc6e3 I broke the build-bundle command so
that it is unable to resolve remote refs (as opposed to local ones).
This means in the normal case of building a bundle for an app installed
from a remote it fails:
$ flatpak build-bundle /var/lib/flatpak/repo gnome-calculator.flatpak org.gnome.Calculator stable
error: Refspec 'app/org.gnome.Calculator/x86_64/stable' not found
This is because flatpak_repo_resolve_rev() interprets a NULL remote name
to mean the ref is local (in refs/heads/) but in this case we just don't
know which remote it's from. This commit fixes the issue by using
ostree_repo_resolve_rev() directly which searches refs/heads/ and
refs/remotes/, and if that fails falling back to iterating over refs
returned by ostree_repo_list_collection_refs() to catch collection-refs
that may be in refs/mirrors/.
Also, add a unit test that fails without this patch.
Fixes https://github.com/flatpak/flatpak/issues/3026Closes: #3032
Approved by: alexlarsson
(cherry picked from commit 5e65174e8d)
It's an error to call g_set_error() on an error that's already set, and
flatpak_dir_get_deploy_data() already sets FLATPAK_ERROR_NOT_INSTALLED
for us when necessary, so just pass on any errors to the caller of
flatpak_dir_get_origin(). In the case that the error is something else,
that should be treated as an error, because we never expect the deploy
directory to exist but not have a deploy file (see the implementations
of flatpak_dir_deploy() and flatpak_dir_undeploy()).
Closes: #3032
Approved by: alexlarsson
(cherry picked from commit b44c1a5799)
This works around an old polkit client library bug which would cause
a segfault in this situation. The bug was fixed long ago in upstream
polkit, but is still present in Debian 10 'buster', Ubuntu 19.04 'disco'
and all older releases, due to Debian/Ubuntu using a branch of polkit
to avoid the mozjs dependency. It should finally get fixed in Debian 11
and Ubuntu 19.10.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug-Debian: https://bugs.debian.org/923046Closes: #2997
Approved by: matthiasclasen
(cherry picked from commit 75b5b7c763)
When checking for Flatpak directories in $XDG_DATA_DIRS, treat
/example//path/ as equivalent to /example/path/.
Fixes https://github.com/flatpak/flatpak/issues/2989Closes: #2990
Approved by: alexlarsson
(cherry picked from commit 4fd7d7d209)
Closes: #2992
Approved by: alexlarsson
Without this, extensions cannot use extra-data, as there is no
indication of what runtime to run apply_extra in.
Closes: #2954
Approved by: alexlarsson
(cherry picked from commit 7222a83678)
Closes: #2992
Approved by: alexlarsson
This restores the ABI to the pre-1.4.0 version. This moves the new signal to
the *end* of the struct and also correctly decrements the padding.
Fixes https://github.com/flatpak/flatpak/issues/2957, although we probably need
a 1.4.1 release with this included pretty quickly to avoid chaos.
Closes: #2958
Approved by: alexlarsson
(cherry picked from commit 4f327649fd)
There are a few cases where -origin remotes don't get removed when
their refs are uninstalled, most notably when xa.noenumerate is set, or
somehow the uninstall gets interrupted at the wrong time. Regardless
of the reason, the remote could never be removed after this, unless a
new ref is installed from it and then removed, or noenumerate is set.
Closes: #2920Closes: #2953
Approved by: alexlarsson
(cherry picked from commit 71fcf99b2e)
Now that validate-icon uses execvpe(), status and error were never set,
so rerun_in_sandbox() would have crashed while dereferencing a NULL
error if execvpe() failed. This is reproducible with, for example:
FLATPAK_BWRAP=/bin/nope flatpak-validate-icon --sandbox 48 48 /path/to/icon
execvpe() does not return on success (the process image is replaced),
and sets errno on failure, so behave accordingly.
Also print the error message to stderr, even if G_MESSAGES_DEBUG is not
set, since it's our only opportunity to indicate to a caller what has
gone wrong.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2950
Approved by: alexlarsson
(cherry picked from commit 8deef94f9d)
I spotted this line in the output from `flatpak history`:
Jun 4 16:17:20 deploy install com.discordapp.Discord x86_64 stable system flathub 8a0fc700c701 Installed %s from %s root (test) flatpak-system-helper (gnome-software) 1.3.3
This is because the format string is passed as the 'url' parameter, the
first format parameter (the ref) is passed as the 'format' parameter,
and 'origin' is ignored because (fortunately) as far as I know, no
character significant to printf (like '%') is permitted in ref names.
Fix this by passing a NULL 'url', like the neighbouring call in
flatpak_dir_deploy_update().
(cherry picked from commit dbc90df513)
Download size of object depends on the compression used in the ostree
repository. When a different source repository is specified, download
size might change. So this metadata needs to be recalculated.
This issue happens with Freedesktop SDK which for build time
optimization reason run an intermediate build-export on a bare
repository.
See issue https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/787Closes: #2925
Approved by: alexlarsson
Toolbox [1] containers, like Flatpak containers, need to keep some
configuration files synchronized with the host. eg., /etc/localtime,
/etc/resolv.conf, etc.. The easiest way to keep them updated is to bind
mount the entire /etc from the host at some location inside the
container, and then replace the container's copy of the files with
symbolic links to the bind mounted copies.
However, this doesn't work when the host's copy of a configuration file
is itself a symbolic link to a location outside /etc. eg.,
/etc/localtime, which points somewhere inside /usr/share/zoneinfo. In
that case the host needs to be actively monitored via inotify(7) and
an updated copy of the file needs to maintained in a separate
directory, which can be bind mounted into the container.
This monitoring infrastructure is already present in Flatpak and it
makes sense to leverage it for Toolbox containers too.
However, Flatpak containers have only one user, the current one logged
into the host, whereas Toolbox containers have a longer list of users
like the host itself. Therefore, if the directory getting bind mounted
(ie., $XDG_RUNTIME_DIR/.flatpak-helper/monitor) isn't world readable,
then some users inside the container won't be able to read the
configuration file. eg., this will fail:
$ sudo -u operator cat /run/host/monitor/localtime
Relaxing the directory permissions on the host shouldn't pose a
security risk. They are copies of originals that are world readable
anyway.
[1] https://github.com/debarshiray/toolboxCloses: #2916
Approved by: alexlarsson
This fixes a warning pointed out by lgtm.com. I checked that the following
still works:
$ PAGER=more flatpak-bisect -b stable org.gnome.Builder log
Closes: #2894
Approved by: matthiasclasen
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 adds a new error to FlatpakError and uses it everywhere a ref is not
found, either locally or in a remote. This should hopefully be more useful than
the status quo of either returning FLATPAK_ERROR_INVALID_DATA or
G_IO_ERROR_NOT_FOUND or something else. Technically this is an API break but it
seems worth the risk. I checked gnome-software which does not seem affected by
this, and I checked eos-updater which does check for G_IO_ERROR_NOT_FOUND in
one place that will be affected by this but we can patch that.
Closes: #2895
Approved by: matthiasclasen
