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
Currently if any command errors out with G_IO_ERROR_NOT_SUPPORTED,
flatpak prints the usage information (the output of --help), but this is
not correct. For example if the create-usb command hits that error when
trying to use extended attributes on a filesystem that doesn't support
them, the help output is printed as we saw here:
https://github.com/flatpak/flatpak/issues/2019#issuecomment-416798304
So this commit removes the check for G_IO_ERROR_NOT_SUPPORTED in
flatpak-main.c and the helper function it uses. The flatpak_run()
function handles printing usage info for the overall flatpak command,
and subcommands use the usage_error() function to print usage
information, so there's no need for it.
Closes: #2082
Approved by: alexlarsson
Currently if you install from a flatpak bundle that doesn't have a
collection ID set or from a flatpakref file that has the CollectionID
key set to the empty sting, you end up with an invalid configuration on
the origin remote created. This is because the collection_id parameter
of flatpak_dir_create_origin_remote() is set to the empty string, not
NULL, and create_origin_remote_config() then only checks for NULL when
deciding whether to set gpg-verify-summary to true or false. Then
because there's no collection ID configured but gpg-verify-summary is
set to false, you get the error "Can't pull from untrusted non-gpg
verified remote" when trying to pull related refs or update the app.
This commit fixes the bug by checking for the empty string when the
collection ID is read from a bundle or ref file, and collapsing that
into NULL.
Closes: #2081
Approved by: alexlarsson
