As noticed in https://github.com/flatpak/flatpak/issues/3412 we
regressed at some point and are no longer using from-scratch deltas.
This is caused by an optimization in ostree where it decides to not
use a from-scratch deltas if theres is *some* version of the ref
locally available.
This conflicts with some code in flatpak that pulls *only* the commit
object in order to look for extra data size information so that we can
get the progress reporting right. Unfortunately the existance of
just the object triggers the above causing us to *never* use from-scratch
deltas.
We fix this by throwing away the partial pull in an aborted ostree
transaction.
(cherry picked from commit b371ef9007)
This breaks Deploy which can't find the ref. It used to work due to
the extra non-mirroring pull in flatpak_dir_setup_extra_data, but
this is not needed here.
(cherry picked from commit 9aecad7f4f)
This reverts commit 915ad583a7.
This commit turned out to have unintended side effects. Specifically,
with it we do a pull with OSTREE_REPO_PULL_FLAGS_MIRROR, and then
flatpak_dir_setup_extra_data() does a non-mirror pull in the same
transaction, so the ref being pulled ends up being written to disk under
both refs/remotes/ and refs/mirrors/ in
ostree_repo_commit_transaction(). This is a problem because only the
remote ref is deleted during an uninstall, so the disk space is leaked,
and we don't have the infrastructure in place to keep both refs up to
date as they're updated.
It would be nice to consistently use OSTREE_REPO_PULL_FLAGS_MIRROR for
all pulls but that turns out to be a deep rabbit hole to go down; see
the discussion in https://github.com/flatpak/flatpak/pull/3220
So revert the commit instead (with a few exceptions: keep a
still-relevant FIXME comment, keep an assertion in the "out:"
section, and keep a debug statement printing out the resolved rev).
Note that this means that since we're no longer checking commit
signatures during ref resolution, in theory remote B could try to set
the same collection ID as remote A and serve a malicious update for
something from remote A, but the signature would be found to be invalid
during the pull phase due to our use of "ref-keyring-map" so the
transaction would fail.
All the other uses of OSTREE_REPO_PULL_FLAGS_MIRROR across the codebase
should be kept I think:
- flatpak create-usb uses it when pulling into the repo on the USB which
works perfectly well with refs/mirrors/ (and the USB is mirroring the
collection-refs!)
- it's used when pulling into a temporary "child" repo in a few places
and there it makes sense since the child repo is mirroring the refs so
they can be pulled into the main repo. In fact, in the case of
flatpak_dir_do_resolve_p2p_refs(), we need MIRROR since otherwise
ostree_repo_resolve_collection_ref() gives us the commit on-disk
rather than the just-pulled one that's in memory.
(cherry picked from commit 13366524d8)
On master we're python3 only, but there is no need to change this for
the 1.4 branch.
However, some recent systems have the /usr/bin/python being python3,
which breaks the tests. So, we hardcode python2 to make it work on
these systems.
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)
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)
The iovec write_vecs[] array on the stack was just 2 element, but we
sometimes use 3 elements of it. This was causing random crashes due to
corrupting the stack.
Closes: #3110
Approved by: alexlarsson
(cherry picked from commit 84e7b19683)
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
