Add FLATPAK_ERROR_INVALID_DATA and use if for cases where
the incoming data for an update or install is faulty, and
add FLATPAK_ERROR_UNTRUSTED, FLATPAK_ERROR_SETUP_FAILED and
FLATPAK_ERROR_EXPORT_FAILED to cover more error conditions.
Closes: #2150
Approved by: alexlarsson
flatpak_fail is a convenient shortcut, but falls short
for actual error reporting. Use proper G_OPTION_ERROR
error codes here.
Closes: #2150
Approved by: alexlarsson
It may be an unlikely case, but if the same app
is installed in multiple installations, there was
no way to select which one to run, so far.
Closes: #2146Closes: #2158
Approved by: alexlarsson
flatpak_find_deploy_for_ref_in is a variation of
flatpak_find_deploy_for_ref that allows to restrict
what installations to search in.
Closes: #2158
Approved by: alexlarsson
The code was looking for a ref with the name
ostree-metadata, but using an api that falls
back to remote refs with the same name, which
is not desirable here.
Use a different ostree api instead that only
resolves local refs.
Closes: #1805Closes: #2157
Approved by: alexlarsson
We were exporting files in subdirectories of all the common
directories. This only really makes sense for icons. For
desktop files, D-Bus service files and mime types, we should
only export from the exact directory itself.
Note that this makes us no longer support the obsolescent
vendor-prefix convention of the desktop entry spec, which was
only relevant for KDE4 and breaks app-id matching.
Closes: #2142Closes: #2152
Approved by: alexlarsson
This fixes the “bwrap: Can't mkdir parents for /var/run/user/1000/.dbus-proxy/: No such file or directory” error. This error occurs on systems where the path in the XDG_RUNTIME_DIR variable contains a symlink under var, for example /var/run → /run.
The reason for the error is that bubblewrap was called both with “--bind /var /var” and “--bind /var/run/user/1000/.dbus-proxy/ /var/run/user/1000/.dbus-proxy/”. This leads to the destination path already existing but with “/var/run” being a symlink. Bubblewrap then tries to make sure the mount point is present in the sandbox and creates all the dirs with its parents, which fails for “/var/run/user” because its parent is a symlink.
This fix simply resolves the path used for the runtime dir before it adds it to the bind parameter.
Closes: #2137
Approved by: alexlarsson
Currently it's possible for Flatpak to consider a runtime used but
consider its Locale extension unused when executing `flatpak uninstall
--unused`, which doesn't make much sense. This only happens if the
runtime is indirectly used; in other words it's used as a related ref
rather than directly as the runtime of an installed app.
In the case of Endless, `com.endlessm.EknServicesMultiplexer` uses all
versions of `com.endlessm.apps.Platform`, and since v1 isn't used by any
app on this computer its Locale extension is considered unused:
$ flatpak list --runtime -a | grep com.endlessm.apps.Platform.*/x86_64/1
com.endlessm.apps.Platform.Locale/x86_64/1 system,partial
com.endlessm.apps.Platform/x86_64/1 system
$ flatpak uninstall --unused
Uninstalling from system:
com.endlessm.apps.Platform.Locale/x86_64/1
Is this ok [y/n]:
This commit changes the behavior of uninstall --unused so that when
something is considered used because it's a related ref, we recursively
check its own related refs so they are considered used too.
Closes: #2103
Approved by: alexlarsson
Mention how flatpak run handles environment variables,
and include the blacklist of variables we always override.
Closes: #2141
Approved by: alexlarsson
Based on my understanding of the matter, we claim
that FlatpakInstallation api is threadsafe.
This commit rewords things a bit, to more strongly
recommend FlatpakTransaction as the preferred API
for the tasks that it covers.
Closes: #2141
Approved by: alexlarsson
This information is nice to have. For example, it can be used
to optimize deltas by reusing delta parts from the base ref.
Closes: #2140
Approved by: alexlarsson
Split flatpak-builtins-add-remote.c into separate files
for the two commands that are defined in here, and rename
things to match the other commands.
Closes: #2132
Approved by: alexlarsson
Better to only call g_dir_close() if dir isn't NULL.
Take this opportunity to move the function to utils,
instead of carrying 4 identical copies.
Closes: https://github.com/flatpak/flatpak/issues/2130Closes: #2133
Approved by: alexlarsson
Change the create-usb command so that it always creates the destination
repository using the "archive" mode, rather than using archive mode when
xattrs aren't supported and bare-user otherwise. This has a few
advantages:
1. The archive mode works with FAT filesystems, which is what most USB
drives are, and which doesn't support xattrs. This should fix
https://github.com/flatpak/flatpak/issues/2019 but it would be good to
confirm.
2. At least in some quick testing I did, archive mode is about twice as
performant as bare-user mode, in terms of how long it takes for the
create-usb command to complete.
3. This ensures that a tool can safely change the permissions on
".ostree/repo" and subdirectories after create-usb completes, which is
important for Endless since otherwise you can't use `ostree create-usb`
as root and then `flatpak create-usb` as a non-root user on the same USB
drive (or in other words copy OS updates and apps to the same USB).
Closes: #2124
Approved by: alexlarsson
This commit avoids passing the error pointer to
flatpak_dir_get_deploy_data() in add_related() because we're not
treating the error as fatal. Otherwise the already-set error pointer can
get passed to flatpak_dir_update_summary() causing libostree to hit an
assertion failure when it checks (error == NULL || *error == NULL) in
_ostree_repo_lock_push().
Closes: #2110
Approved by: alexlarsson
If we rely on the background subshell to create the httpd-output file,
and we are unlucky, then the "cp" invocation in the loop might execute
before the file has been created, and fail. This appears to have
happened on Debian's arm64 autobuilder, which failed with:
Running web server: PYTHONUNBUFFERED=1 setsid python3 /<<PKGBUILDDIR>>/tests/http-utils-test-server.py 0
Web server pid: 13319
Waiting for web server (1/300)...
cp: cannot stat '/var/tmp/tap-test.p1cxRN/httpd-output': No such file or directory
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #2098
Approved by: alexlarsson
Currently Flatpak reads a repo metadata key called "xa.collection-id" to
decide whether to configure a collection ID on a remote. This commit
drops support for xa.collection-id and replaces it with
ostree.deploy-collection-id, which is a key defined by OSTree but so far
only implemented here.
The reason for the change is so that collection IDs can only be deployed
to users running recent versions of Flatpak and OSTree. The current
situation is that Endless wants to deploy collection IDs (and therefore
support for doing USB updates) to users, but servers such as Flathub
can't safely set xa.collection-id in their metadata, because many users
are still using old versions of Flatpak and OSTree[1] which would hit
various bugs[2][3][4] on the P2P code paths that are enabled by
collection IDs. Defining a new key means that only users running
recent (as-yet-unreleased) versions of Flatpak and OSTree will pay
attention to it and deploy the collection ID, leaving the users on old
versions unaffected.
The reason this metadata key is being defined at the level of OSTree
instead of Flatpak, is that OSTree may want to implement it in the
future.
The functionality of deploying a collection ID by setting the
"deploy-collection-id" key in the config on the server side (which in
turn causes ostree.deploy-collection-id to be set) is already covered by
the unit tests in test-update-remote-configuration.sh; this commit just
tweaks them to use the new key.
Another solution I proposed to this problem was to have a key
"eos.collection-id" which would only be understood by the Endless fork
of Flatpak, and use that temporarily until enough people are running
recent versions of Flatpak, at which point "xa.collection-id" can be
used. But this solution (abandoning xa.collection-id upstream) allows us
to avoid that migration step and leave users on old versions of Flatpak
completely unaffected.
[1] https://ahayzen.com/direct/flathub.html#downloadsbyflatpakstacked
[2] https://github.com/ostreedev/ostree/commit/e4e6d85ea
[3] https://github.com/flatpak/flatpak/commit/5813639f
[4] https://github.com/flatpak/flatpak/commit/5b21a5b7
The collection id check that was added leaks if we were able
to read the collection-id, but then it was ignored.
Closes: #2093
Approved by: alexlarsson
