For example, if org.the.App or org.the.Platform is masked that means
we don't want to get any updates to it. Its very likely that we also
don't want updates to extensions of this app or runtime. For example,
we definately don't want to update the .Locale or .Debug extensions.
As per https://gitlab.gnome.org/GNOME/glib/merge_requests/490
there is a bug in glib < 2.60 where g_spawn_* can sometimes deadlock
due to using malloc in the child func to close fds.
We work around this in places where the code is (potentially) threaded
by passing glib flags to leave fds alone and then do a very naive
(but safe) fd cloexec loop ourselves.
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 means you can use "org.foo.bar//stable" instead of "org.foo.bar/*/stable"
which is similar to what other APIs do.
We want to use this for masking extensions too, thus the export.
This allows the introspection data to be generated with the correct type for each of these properties, instead of just `int`. This should improve the quality of the documentation as well as bindings generated from the introspection data.
If the installation contains 1 or more installed refs, but none of those
refs have a remote with a collection ID, then 'results' will be NULL but
'installed' will be non-NULL. Since
c29e686246, 'results[0]' is used in this
situation – a NULL pointer dereference. There is an existing 'results !=
NULL' check inside the body of this loop, but this is too late.
Check whether 'results' is NULL before dereferencing it.
Fixes#3134.
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
Currently FlatpakInstalledRef objects are constructed without the
collection-id property set. This is a problem because in the USB app
update support in the Endless fork of GNOME Software, when we find a
FlatpakRemoteRef on a USB drive which matches the ref of a
FlatpakInstalledRef object, the collection IDs of the two objects must
also match, and currently the installed one has a NULL collection ID.
So get the collection ID on the relevant configured remote when
constructing a FlatpakInstalledRef. This should be good enough in most
cases but isn't perfect; see
https://github.com/flatpak/flatpak/issues/3103Closes: #3114
Approved by: alexlarsson
In commit b8a3075d8 I changed a few places to check if the array
returned by ostree_repo_find_remotes_finish() is empty, which would mean
either none of the configured remotes (or P2P sources) provide the
requested refs, or the one(s) that do are offline. That was mostly
correct but in the case of
flatpak_installation_list_installed_refs_for_update() we don't want to
treat empty results as an error, because otherwise GNOME Software prints
an error message when offline: "No remotes found which provide these
refs: ...".
So this commit makes list_installed_refs_for_update() return an empty
array in case it can't find any updates (we don't distinguish "remotes
checked and provide no updates" from "remotes couldn't be reached").
This matches the behavior of the non-P2P code: the for loop above which
handles remotes without collection IDs prints a debug message if an
error is encountered.
Also, add a unit test that fails without this patch.
Closes: #3066
Approved by: alexlarsson
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
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 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
When looking for deployed extensions, use the same prefix as when
looking for extension refs. E.g. look for refs that start with
"io.github.Hexchat.Plugin." rather than "io.github.Hexchat.Plugin".
This is a follow-up to https://github.com/flatpak/flatpak/pull/3067#discussion_r322173197Closes: #3092
Approved by: alexlarsson
Currently the "test_remote()" test calls
flatpak_remote_set_gpg_verify (remote, FALSE) and disables GPG
verification on a remote while a collection ID is set on it, which
should not be possible. The remote-add command enforces that GPG
verification is used if a collection ID is set, but the library API does
not. This commit changes libflatpak to return an error when such an
invalidly configured remote is being committed to disk. Also, update the
unit test to check for the newly added error, and to unset the
collection ID before disabling GPG verification.
Later in the unit test, GPG verification is re-enabled on the remote,
but libflatpak erroneously sets gpg-verify-summary=true in addition to
gpg-verify=true (summary verification is supposed to be disabled when
collections are used, but the library doesn't notice the mistake since a
collection ID isn't set in the same transaction and was already set).
This fix addresses both issues.
Closes: #3095
Approved by: alexlarsson
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: mwleeds
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
Currently if you delete a remote when it still has installed apps (using
--force), you're then unable to uninstall those orphaned apps (or
runtimes). This commit makes the uninstall operation succeed despite the
missing remote. Since we don't need a FlatpakRemoteState for an
uninstall operation, just avoid calling flatpak_ensure_remote_state().
Also, do some refactoring in flatpak_transaction_real_run() that should
improve readability and allows us to add a g_return_val_if_fail() in the
helper function, which ensures that only uninstall operations are
allowed to not have remote state.
This also includes a unit test for uninstalling with a missing remote.
Fixes https://github.com/flatpak/flatpak/issues/1982Closes: #3067
Approved by: alexlarsson
This is similar to the last commit in that it's making
flatpak_dir_find_local_related_for_metadata() tolerant of a condition
that happens in the wake of the user running "flatpak remote-delete
--force ...". Since that command deletes refs tied to the remote being
deleted but leaves behind installed apps/runtimes, and
find_local_related_for_metadata() uses flatpak_repo_resolve_rev() to
check for extensions' existence, it misses any that are associated with
a deleted remote.
The effect of this is that if I run "flatpak remote-delete --force
kdeapps" followed by "flatpak uninstall org.kde.okular", org.kde.okular
is removed but org.kde.okular.Locale is left behind.
So this commit makes find_local_related_for_metadata() check for a
deploy of each extension if it can't find its ref, and finding either
one is reason enough to return it to the caller (which for an uninstall
operation means it will be deleted). We can't just check for the deploy,
because as evidenced by the "deployed" argument of
flatpak_dir_find_local_related(), the ref in question is not always
deployed (which presumably means the extension can't be expected to be
deployed either).
Closes: #3067
Approved by: alexlarsson
As a step toward the goal of making uninstalls work when the
corresponding remote is missing, this commit makes
flatpak_dir_find_local_related_for_metadata() tolerant of the specified
remote being missing. To do this we get the collection ID from the
commit metadata rather than the remote config, which is more robust
anyway since in some cases the commit's collection may not match that of
the remote (see https://github.com/flatpak/flatpak/issues/1477).
This commit also changes the call sites of
flatpak_dir_find_local_related_for_metadata() so they pass in the commit
to be used, which means resolving transaction operations to a commit
even for uninstall operations (just the current installed commit).
Closes: #3067
Approved by: alexlarsson
flatpak_dir_collect_deployed_refs() has the order of its "branch" and "arch"
arguments wrong, as does its only caller flatpak_list_deployed_refs().
When flatpak_list_deployed_refs() is called by add_extension() the arch
is put in the branch argument and vice versa. But then in the
implementation the arch is used as if it's the branch and vice versa, so
there's no functional bug here. Fix the order for readability.
Similarly, flatpak_list_unmaintained_refs() has the order wrong, but the
confusion is only within that function, since the order is correct in
its caller add_extension() and in the function it uses,
flatpak_dir_collect_unmaintained_refs(). So there's no functional bug
there either, but fix the order.
Closes: #3067
Approved by: alexlarsson
Currently the FlatpakDir object for the default system installation is
constructed differently depending on where the construction is
happening. In flatpak_dir_get_system_default() it's created with a NULL
DirExtraData object which means flatpak_dir_get_id() returns NULL when
called on it. But if constructed in
flatpak_get_system_base_dir_locations(), the FlatpakDir object gets a
DirExtraData object with the default values, including the id "default",
so flatpak_dir_get_id() returns "default" for it.
This commit changes flatpak_dir_get_system_default() so it constructs
the default object consistently with the other construction. This means
that in the places where the dir id is compared to "default" that check
will work correctly. Practically this means for CLI transactions the
"Proceed with these changes?" prompt will say "the system installation"
rather than "the Default system installation".
Also change flatpak_dir_get_system_by_id() so it returns the default dir
when id == "default", but continue to also return it if id == NULL. This
means the --installation=default CLI option will work correctly, but we
can avoid breaking any software that might currently be calling
flatpak_installation_new_system_with_id() with a NULL id.
And finally change flatpak_dir_get_display_name() so it continues to
return "Default system installation" for the default system
installation.
Closes: #3077
Approved by: alexlarsson
This was happening for the org.opencontainers.image.ref.name annotation
when we're in labels mode, but might as well be handled in a generic
way.
Closes: #2978
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
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 is not compatible with the old stuff, but works with registries
that only support the docker manifest format.
Closes: #2978
Approved by: alexlarsson
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
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
... by moving the definition of FlatpakHostCommandFlags from the
'common' sub-directory to 'session-helper'. It hasn't been used by
anything else ever since flatpak-builder was moved to a separate
repository in commit 52bd146561.
Closes: #3052
Approved by: alexlarsson
