Mark installed apps to be updatable if an installed in missing
its runtime for some reasons. In pre-FlatpakTransaction world,
an app migration from runtime X to runtime Y would have rendered
an app unusable because runtime Y would not be installed
automatically by clients like gnome-software.
The goal here is that clients like gnome-software can show
those installed apps as updatable again, if such a situation
arises. The FlatpakTransaction API can automatically resolve one of
its ops to install the new runtime, provided we can mark the app
as updatable again at the first place.
While updating, if the related extension is missing on
the installation of an installed ref (could be an app or
runtime), FlatpakTransaction tends to "repair" the ref by
automatically downloading the related extension again and
restoring the overall functionality of the ref.
The related extension concerned that are the ones associated with
`should-download` to TRUE only.
Hence, teach the libflatpak API to do that same, so that clients
like gnome-software can mark those refs as updatable, if their
related extensions is missing.
FlatpakTransaction will automatically download the related ref
(.Locale ref in this case). In case of mentioning previous-ids
in the deploy file, the related ref(.Locale) should be also
be requiring an update.
Hence, flatpak_installation_list_installed_refs_for_update now
will return 2 refs (app and related .Locale extension) to be
updated, instead of 1.
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
This test was intended to verify that updates from remote B can't
interfere with updates from remote A even if remote B maliciously sets
the same collection ID as remote A. However, the commits intended to
protect against this turned out to have nasty side effects and need to
be reverted.[1] A subsequent commit will revert the use of
OSTREE_REPO_PULL_FLAGS_MIRROR which means this attack is not exploitable
(since refs will be resolved using a refspec which includes the remote
name), at the cost of not supporting more than one remote having the
same collection ID configured. Since we don't support that, it doesn't
make sense to keep this unit test.
Also, the test seems to be failing.
[1] https://github.com/flatpak/flatpak/issues/3215
Also update the tests to use the same format, and make sure to include
coverage of all forms of locale (language-only, with locale, with
codeset, and with modifier).
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.
Adding generated files to foo_SOURCES causes them to be distributed,
even if that was not intended. Use nodist_foo_SOURCES instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
There's no need for this file to be executable. If it was executed,
shells would typically try to execute it as a shell script (because it
isn't an ELF executable and doesn't start with #!), which isn't going
to work.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This ensures that when the operation to install the app completes, the
app is ready to run — rather than having to wait for subsequent
operations to install extensions which the app depends on (such as
content, or locales).
This fits in with the current ordering for *un*installing apps, where
the main app is uninstalled first, followed by its extensions.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://github.com/flatpak/flatpak/issues/3017
Files in the srcdir need to be explicitly prefixed as such in rule
commands. This fixes `make install` when installed-tests are enabled.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than this weird shell loop with a timeout and polling we
move the httpd spawning entirely into the python code, and use
a pipe to synchronize the spawning. This way we can also use
the shell job control to properly clean up any running processes
from the test suite.
Additionally, this adds some (lame) support for token handling in the
test webserver, where you for any file foo can create a foo.need_token
containing a token that is needed for that file.
FlatpakTransaction inherently doesn't differentiate between a
autoupdate and a regular update; both are
FLATPAK_TRANSACTION_OPERATION_UPDATE.
This getter can help differentiate between a regular update
and autoupdate in clients like gnome-software. Autoupdates
work in two separate transaction passes; first that runs with
"no-deploy" and the second pass that deploys all the downloaded
update (i.e. with "no-pull").
We add socat to the test runtime, and then we use that to run a
test app outside the sandbox as if it was inside.
The testcase connects creates a monitor and ensure we properly get signals
for updates.
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.
Assert it was successful instead. This is probably pointless from the
point of view of testing things (why would symlink() ever realistically
fail but everything else succeed?), but it does shut up a compiler
warning, which gives us a better chance to spot legitimate warnings in
future.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #3116
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
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
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
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
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
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
