On some code paths, flatpak_dir_get_remote_state_optional() is used so
summary fetch errors and metadata fetch errors are treated as non-fatal,
and later flatpak_remote_state_ensure_summary() or
flatpak_remote_state_ensure_metadata() is used, which gives a pretty
unhelpful error message. So this commit saves the error from a failed
summary or metadata fetch into the FlatpakRemoteState object and prints
the message when the flatpak_remote_state_ensure_* function is called to
make that error message more specific and useful.
This also means that the "fail with missing gpg key" unit test in
test-repo.sh is working again. It was broken by the last commit ("dir:
make optional summary really optional) which caused the install
operation in that test to fail later than before with a different error
message.
Closes: #1637
Approved by: alexlarsson
We should not require a collection ID to be set for this to actually be
optional.
Doing so will make us require a network connection for flatpak installs
and updates even in case we already have the requested ref available.
A use-case that breaks is pulling a ref beforehand (e.g. using ostree
pull, or flatpak with FLATPAK_INSTALL_FLAGS_NO_DEPLOY), and later
deploying it explicitly at a time when network is not available anymore
(e.g. during boot time), using FLATPAK_INSTALL_FLAGS_NO_PULL.
This also means that creating a FlatpakRemoteState object for a disabled
remote no longer causes an error as long as the summary is optional, so
installing .flatpak bundles works again.
Fixes https://github.com/flatpak/flatpak/issues/1636Closes: #1637
Approved by: alexlarsson
In flatpak there are two ways a remote can be disabled, an empty URL or
xa.disable set to TRUE. flatpak_dir_remote_fetch_summary() already
doesn't try to fetch the summary in the former case; this checks the
latter as well.
Closes: #1641
Approved by: alexlarsson
The fix in 5122766284 was not right.
First of all it didn't changethe regressing behaviour for
build-finish, just install.
Secondly, it changed the prefix matches to always use
flatpak_name_matches_one_wildcard_prefix() which had slight
differences in behaviour that the previously used
flatpak_name_matches_one_prefix. For example, it always removed
the extension, no matter what it was.
This has all been replaced with a shared (between install and
build-finish) version that is more strict with extensions, and with
what names can be exported as service files (these have to match
exactly, with the wildcard and cannot have suffixes).
To test this i tried to install these apps from flathub that has
some more complex exports:
org.sparkleshare.SparkleShare:
org.sparkleshare.SparkleShare.Invites.desktop
org.sparkleshare.SparkleShare-symbolic.svg
org.libreoffice.LibreOffice:
org.libreoffice.LibreOffice.desktop
org.libreoffice.LibreOffice-impress.desktop
org.libreoffice.LibreOffice-writer.png
org.libreoffice.LibreOffice-calc.png
com.github.bajoja.indicator-kdeconnect:
com.github.bajoja.indicator-kdeconnect.desktop
com.github.bajoja.indicator-kdeconnect.settings.desktop
com.github.bajoja.indicator-kdeconnect.tablettrusted.svg
com.github.philip_scott.spice-up:
com.github.philip_scott.spice-up.svg
com.github.philip_scott.spice-up-mime.svg
com.github.philip_scott.spice-up.mime.xml
org.gnome.Recipes:
org.gnome.Recipes.desktop
org.gnome.Recipes.service
org.gnome.Recipes-search-provider.ini
org.gnome.Recipes.png
org.gnome.Recipes-symbolic.symbolic.png
org.gnome.Recipes-mime.xml
org.gnome.Characters:
org.gnome.Characters.desktop
org.gnome.Characters.BackgroundService.service
org.gnome.Characters.service
org.gnome.Characters.search-provider.ini
org.gnome.Characters.png
org.gnome.Characters-symbolic.svg
org.gnome.Weather
org.gnome.Weather.Application.desktop
org.gnome.Weather.Application.service
org.gnome.Weather.BackgroundService.service
org.gnome.Weather.Application.search-provider.ini
org.gpodder.gpodder:
org.gpodder.gpodder.desktop
org.gpodder.gpodder.gpodder-url-handler.desktop
Only complete to subrefs is fully matching real part. For example,
only match org.foo.Bar.Sources for "org.foo.Bar", "org.foo.Bar." or
"org.foo.Bar.S", but not for "org.foo" or other shorter prefixes.
This commit changes flatpak_dir_pull_untrusted_local() to avoid using
the summary file in the source repo if a collection ID is set and use
ostree_repo_resolve_rev() instead in that case. Since summary signatures
are not part of the security model when collection IDs are used, this
doesn't change any security properties. But it does make pulls succeed
when there's nothing to do (i.e. the child repo has no refs because the
parent repo already has the desired commit). In that case, the summary
file will be empty if collection IDs are being used because of
child_repo_ensure_summary().
The end result of this is that "flatpak update --appstream" works when
there's a collection ID set on the remote and the appstream is already
up to date locally. This problem only recently became visible because
flatpak_dir_check_for_appstream_update() was removed in a recent commit.
This is a partial fix for https://github.com/flatpak/flatpak/issues/1615
In flatpak_dir_update_appstream(), we check for the appstream ref after
pulling it and before deploying it. When the system helper is not being
used we properly include the remote name in the refspec passed to
ostree_repo_resolve_rev(), so this commit does the same for the system
helper case. Otherwise we might end up with the checksum for an
appstream ref from another remote because of the relationship between
the child and parent repos. This doesn't have any user visible effect
except preventing a "false positive" of thinking an appstream pull was
successful when it wasn't.
Currently we try to update the "appstream2" branch and if that fails try
to update the "appstream" branch. If that fails too we return the error
message from the appstream2 update, which can be misleading. So this
commit combines both error messages into one so you get something like
this:
$ flatpak update --appstream tamaulipas-apps
error: Error updating appstream2: No such ref 'appstream2/x86_64' in
remote tamaulipas-apps; Error updating appstream: Update is older than
current version
That should make debugging easier for
https://github.com/flatpak/flatpak/issues/1615.
A symbol from this (flatpak_portal_error_quark) was leaked to libflatpak
due to being marked FLATPAK_EXTERN, so to keep ABI we move it back.
Fixes https://github.com/flatpak/flatpak/issues/1613Closes: #1616
Approved by: alexlarsson
On 32 bit ARM platforms, flatpak_get_compat_arch() returns NULL, so
handle that gracefully in flatpak_get_arches().
Closes: #1614
Approved by: alexlarsson
The telegram app id is org.telegram.desktop, and its appstream
component id is org.telegram.desktop.desktop, which we did not
properly handle (we special cased the app-id-ends-with-desktop case
and then did not remote .desktop). This replaces that with a more
approach that *always* matches the whole app id as prefix, and then
replaces a ".desktop" in the suffix part only.
Closes: #1593
Approved by: alexlarsson
This makes flatpak_remote_state_lookup_cache() return the metadata
from the actual FlatpakRemoteState rather than duplicating it.
All callers are updated to not free anymore and to strdup if needed.
Closes: #1594
Approved by: alexlarsson
This is safe as we do the pull locally, and root configured the local
path. We already do the same for regular installs, so its weird that
its not done for appstream.
Should fix https://github.com/flatpak/flatpak/issues/1580Closes: #1585
Approved by: alexlarsson
By default we use the new appstream2 branch if it exists in the remote,
also in this case we compress the xml when deploying to be backwards
compat with the old deploys.
Closes: #1585
Approved by: alexlarsson
For example, if a i386 build is in the repo but no x86-64 version then
also add the i386 build to the x86-64 appstream data. However, don't
add it if that would cause a duplicate (i.e. both the x86-64 and i386
version).
Closes: #1585
Approved by: alexlarsson
This early bailout is not really needed, because noop updates is
pretty fast. Also, doing that breaks the timestamp updates.
Closes: #1585
Approved by: alexlarsson
This fixes the ability of the remote-ls command to take a file:// URI
instead of a remote name, which is especially useful for repos on USB
drives (created via `ostree create-usb`) which are temporary and don't
warrant being added to the repo config. This commit also updates
relevant documentation, adds a unit test, and updates a few variable
names to improve readability.
I can't find a commit in the history where this was working, but it's
working on the Endless fork of flatpak so I think there was agreement at
some point that it's desired behavior.
Fixes https://github.com/flatpak/flatpak/issues/1588Closes: #1587
Approved by: mwleeds
Currently _flatpak_dir_get_remote_state() only fetches the
ostree-metadata ref if it was able to fetch the remote summary, but this
is unnecessary because we don't need to know the checksum just to fetch
it, and this is especially problematic in the offline use case when the
remote summary can't be fetched. So this commit makes flatpak fetch
ostree-metadata even if the summary fetch failed, which is consistent
with how things worked before commit fedb0e5bd.
Closes: #1587
Approved by: mwleeds
When listing refs installed or from a remote, only the refs matching the
main collection-id were being returned. However, it is very important to
have access to all refs, independently from their collection-id,
especially when trying to list remotes coming from a USB repository.
These changes add the mentioned refs and update the places that use
this list, both in the lib and in the CLI.
For the implementation to become easier, we introduce also a
FlatpakCollectionRef, that should be replaced by OstreeCollectionRef
once the latter becomes part of the general API (currently it is in the
experimental one).
Closes: #1587
Approved by: mwleeds
We will use this later to work out which .service files we can export
based on names that we are allowed to own.
Closes: #1589
Approved by: alexlarsson
This moves the prune call out of flatpak_dir_update() and
flatpak_dir_uninstall() and instead does this manually at all call
sites. The advantage is that we now only call it *once* even if you
uninstall or update multiple apps.
This means update everything is much faster as we don't have to scan
over the entire local repo for each updated app.
A desktop file can specify this key to add additional arguments
to flatpak run. Right now, only 'no-a11y-bus' is supported.
Closes: #1579
Approved by: alexlarsson
_flatpak_dir_fetch_remote_state_metadata_branch is only used when building
with p2p, so #ifdef the entire function.
Closes: #1575
Approved by: alexlarsson
