This commands lets you selectively disable auto-download of extensions
based on patterns. With this we can have extensions that install
by default, yet still allow the user to not have them re-installed
each time flatpak update is run.
This fixes https://github.com/flatpak/flatpak/issues/3090
This allows you to ensure that a particular app/runtime is installed
and with the latest version in a single operation, which is useful
for instance in automatic use, like CI systems.
Currently flatpak_installation_fetch_remote_ref_sync() does not work
offline. It returns an error when it fails to fetch the remote's summary
in flatpak_dir_get_remote_state(). This is a problem since GNOME
Software (or at least the Endless fork) uses this library function to
display apps it finds on a USB drive (see gs_plugin_refine_item_origin()
in gs-flatpak.c) and that's something that should work even offline.
So this commit changes flatpak_dir_get_remote_state_optional() so that
it accepts the only_cached option, and updates the call sites. Also have
fetch_remote_ref_sync() use flatpak_dir_get_remote_state_optional(),
which means that when we're offline we will use the xa.cache data in the
ostree-metadata ref as a list of refs list instead of using a summary.
However since the commit checksums are not in xa.cache, we don't have
enough information to form a FlatpakRemoteRef. So also call
ostree_repo_find_remotes_async() to get the commit from any LAN or USB
sources that may be available. This may not be very performant but at
least it only happens if the ref wasn't found in a remote summary; see
https://github.com/flatpak/flatpak/issues/1862
It's sad this code is so long-winded but it's difficult to break out a
helper function that could be shared with
list_remotes_for_configured_remote() above. Longer term we could improve
the ostree_repo_find_remotes_async() API and add options to remove the
need to manually handle OstreeRepoFinder objects.
Closes: #3114
Approved by: alexlarsson
The commands array contains entries that serve
just as section titles; avoid returning those
when looking for misspelt commands.
Pointed out in https://github.com/flatpak/flatpak/issues/3040Closes: #3107
Approved by: matthiasclasen
If xa.languages is set, use these, and no others. Otherwise, take the union
of xa.extra-languages, and the system default locales for system repos;
xa.extra-languages for user repo and the langs based on the user's locale
Fixes https://github.com/flatpak/flatpak/issues/3043
Currently "flatpak --installation=default info ..." leads to an
assertion failure:
$ flatpak --installation=default info us.zoom.Zoom
(flatpak info:24593): GLib-GObject-CRITICAL **: 10:01:36.040: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
This is because in flatpak_find_installed_pref(), we set "dir =
installation_dir" but then installation_dir is freed by g_autoptr before
we try to return dir.
Fix the problem by stealing the pointer, and doing the same for the
other places dir is set.
Closes: #3077
Approved by: alexlarsson
When we export a manifest to the index, always pass the ref we're
targeting instead of relying on the org.opencontainers.image.ref.name
annotation, because that may not be set if we're using labels instead.
This is no big deal, because we know what ref we're handling anyway.
Closes: #2978
Approved by: alexlarsson
This allows the user to pick at runtime whether to use
annotations or labels as OCI metadata carrier. For historical
reasons annotations is the default, but some registries don't
support this and then you can use labels instead.
Closes: #2978
Approved by: alexlarsson
We now pull the image config as well as the manifest and fall
back on the labels field if the keys we're looking for are not
in the annotations field.
This lets us support docker manifests too, which don't have
annotations (but do have labels).
Closes: #2978
Approved by: alexlarsson
This doesn't change the behaviour, it just breaks out everything related
to flatpak-specific annotations into one place where it can be resued.
Closes: #2978
Approved by: alexlarsson
The org.freedesktop.Flatpak user D-Bus service isn't just used by
flatpak(1) or applications running as Flatpaks. It's also used by
toolbox(1) for similar reasons:
* To keep various configuration files inside the container
synchronized with the host
* To let the container request certain commands to be run on the host
The org.freedesktop.Flatpak D-Bus service itself doesn't need much in
the way of dependencies, but inherits a lot of unused shared library
linkages through the libflatpak-common.la convenience library. Removing
these unused shared libraries reduces the footprint of toolbox(1) for
those who care about such things. eg., Fedora CoreOS.
This commit brings down the number of shared libraries to 19 from 62.
Closes: #3052
Approved by: alexlarsson
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
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
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
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
Flatpak already doesn't show the architecture column in the output of
"flatpak list" if every flatpak has the same architecture. This commit
does the same for the table printed for install/update/uninstall
operations, except if the user specifies an arch on the command line.
Fixes https://github.com/flatpak/flatpak/issues/2794Closes: #2930
Approved by: matthiasclasen
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
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
As described in the last commit message, it makes sense to move toward
using flatpak_repo_resolve_rev() rather than ostree_repo_resolve_rev()
for a few reasons:
1) It means we can use OSTREE_REPO_PULL_FLAGS_MIRROR which causes refs
to be pulled into repo/refs/mirrors/ rather than repo/refs/remotes/
which fixes a few edge cases of using collection IDs[1]
2) It falls back to using ostree_repo_resolve_rev() if
ostree_repo_resolve_collection_ref() fails so we can maintain backwards
compatibility for repo/refs/remotes/
3) It distinguishes between remote and local refs, and in the local case
uses OSTREE_REPO_RESOLVE_REV_EXT_LOCAL_ONLY and
ostree_repo_resolve_rev_ext() to make sure we don't for example
accidentally use a remote's repo metadata rather than the local repo's
metadata for the "flatpak repo" command.
So this commit changes every instance of ostree_repo_resolve_rev() in
the codebase to flatpak_repo_resolve_rev().
[1] https://github.com/flatpak/flatpak/issues/1832Closes: #2705
Approved by: alexlarsson
If you're adding a remote with --if-not-exists and it exists,
apply the filter key anyway. Typically this is used to allow a
user to use the standard instructions to add a remote even if there
is a pre-existing filtered remote already configured.
Closes: #2869
Approved by: alexlarsson
This is kind of special as it handles non-existing filter keys
as "override to no filters" instead of "leave existing filters" whic
we do for other things. However, that matches how we want to use
.flatpakrepo files to override site-local filters.
Closes: #2869
Approved by: alexlarsson
readlink() and readlinkat() have weird semantics (they return the
number of bytes they would have written if there was enough space,
even if that's larger than the buffer), but glnx_readlinkat_malloc()
takes care to do the right thing in all situations.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2873
Approved by: matthiasclasen
Any log output interferes with comletion.
We already refrain from installing our verbose
log handlers in this case, but we are still
vulnerable to GLib default message handling,
e.g. via the G_MESSAGES_DEBUG environment
variable. To avoid that, explicitly install
a message handler that suppresses all output.
Closes: https://github.com/flatpak/flatpak/issues/2860Closes: #2862
Approved by: alexlarsson
We now return a NULL error meaning nothing is printed as before
but a FALSE result which means the exist code marks the failure.
Closes: #2858
Approved by: alexlarsson
This is very useful for the CLI where you want to fail the operation and
return a failure exit code, but the user actively chose to do so on
a prompt, so you don't need to print out anything.
Semantics are: if return FALSE => print error if non-null, then exit
with failure code.
Closes: #2858
Approved by: alexlarsson
This mostly worked because QuietTransaction doesn't ask anything, but
some early checks in the commands itself only checked opt_yes.
Closes: #2858
Approved by: alexlarsson
We need to handle operation_error and report errors, and for
fatal errors remember this and report a failure in run(), because
otherwise it returns ABORTED, which is treated as a failure (because
generally that meant the user chose "no" on some question).
Fixes#2839, #2757Closes: #2858
Approved by: alexlarsson
