These are explicitly made short to save space, so lets have defines
for them to make sure we don't mistype them, especially as we
will be adding new keys.
There is no need to read the links, just look at the inode nr
which is the same info, and that also works on the bind-mounted
.userns thing where readlink fails.
Also, don't fail for non-existing namespaces.
Assuming unprivileged namespaces works we can now user the .userns
bindmount to access the intermediate bubblewrap user namespace.
This also drops the warning about root, and make sure we drop all caps
at the end.
Neither of these ever need a polkit agent, and run/build are somewhat
performance sensitive and we don't want to connect to dbus unnecessarily.
For enter this is critical though, as the dbus connection starts a thread
which is not compatible with the setns syscall.
Due to bug #3215 some systems have refs in refs/mirrors/ in addition to
the usual refs/remotes/ location. The remote refs are always at least as
new as the mirror ones since the repo_pull() invocation in
flatpak_dir_pull() which does not use OSTREE_PULL_FLAGS_MIRROR happened
after the one that did. Cleaning up these mirror refs is important since
otherwise when the remote ref is either updated or removed (by an
uninstall) disk space will be leaked since the mirror ref will point to
a no longer needed commit.
So, remove (almost) all mirror refs during flatpak repair, uninstall,
or update operations. And for the uninstall and update operations do it
in FlatpakDir so that it happens regardless of if the CLI of libflatpak
are used.
Also, add a unit test for this.
Fixes https://github.com/flatpak/flatpak/issues/3222
In commit 0772ab6c9 we changed "in preference of" to "in favor of" in an
informational message produced by FlatpakCliTransaction for clarity. Do
the same for FlatpakQuietTransaction.
Currently, if you run:
flatpak remote-ls flathub --app-runtime=com.endlessm.Platform//eos3.2
you see no apps (correct) but hundreds of runtimes. This is inconsistent
with the documentation for the '--app-runtime' option, which says:
> List applications that use the given runtime
To fix this, default to not showing runtimes if '--app-runtime' is
given. This is consistent with the behaviour if just '--app' is
specified. If you run 'flatpak list --app-runtime=com.example.Foo
--runtime' then you get apps using that runtime, plus all other
runtimes, which seems fair enough to me.
Accept the locale format as documented by `setlocale(3)`, rather than
another arbitrary format.
This reworks the validation code, and was tested to accept all the
locales on my F30 system using:
```
flatpak config --user --set extra-languages $(locale -a | tr -s '\n' ';' | head -c -1)
```
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to configure gnome-software to show specific apps in one region
without showing to all language speakers, we allow the storage of full
locales on the extra-languages key. However, these locales are ignored when
calling flatpak_installation_get_default_languages, so locales will be reduced
to their language identifier (eg. en_IN locale will be returned as 'en', and
az_Latn_AZ will be returned as 'az'). In order to get the full locales, we can
call flatpak_installation_get_default_locales instead, which can return languages
and locales.
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
