This commit removes the call to flatpak_dir_update_summary() in the
create-usb implementation. It turns out that libostree does not rely on
a summary being present when a pull is local (meaning it uses a file://
URI). I'm not sure where I got the idea that create-usb depends on a
summary in the source repo. I went back to the first commit that
introduced the "ostree create-usb" command and even using that a summary
isn't required, so it seems unlikely that this changed recently.
One important benefit of removing the summary update is that currently
summary generation takes an exclusive lock, and we've seen on Endless
the attempt to acquire that lock time out (possibly due to a prune
happening in another process).
We could also remove the system-helper method UpdateSummary since it
doesn't have any users after this commit, but maybe someone will need it
in the future, and technically removing it would be an API break.
Closes: #2166
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
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
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
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
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
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
Remotes can provide appstream in both compressed form under the ref
appstream/<arch> and uncompressed form under the ref appstream2/<arch>.
Flatpak only pulls the legacy appstream ref for a remote if appstream2
is not available. But then the create-usb command prints a warning if
appstream is not available locally, even if appstream2 is available,
which is a bit misleading. So this commit changes create-usb so that it
only prints an error if both refs are missing.
Closes: #2084
Approved by: alexlarsson
This changes install to use FLATPAK_BUILTIN_FLAG_STANDARD_DIRS, which
returns the default dirs. This is tweaked such that it returns the
system installaton first if no options were set, which is the default
in the old ONE_DIR case.
In the bundle and flatpakref install case we use the first element
of the dirs[], which now is the same as the old default, and
otherwise is the one the options picked.
However, if a remote is specified, we use
flatpak_resolve_duplicate_remotes() to pick the actual installation.
Closes: #2073
Approved by: mwleeds
Without this call, we show monsters like:
error: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code1: No such file or directory
With this call, it will be just:
error: No such file or directory
Closes: #2066
Approved by: alexlarsson
When the uninstall operation was moved to FlatpakCliTransaction the
prompting moved there. Unfortunately some prompting was left over
in the main code, this just deletes that.
This fixes#1928Closes: #2056
Approved by: alexlarsson
If some app uses a particular runtime as an sdk, consider it used.
This means if you once downloaded the sdk for some app you're debugging
it will not be removed until that app is uninstalled.
Its unclear exactly whether this is "used", but lets error on
the side of not deleting stuff.
Closes: #2057
Approved by: alexlarsson
This option shows the contents of an override file. If an appid
is given, it shows overrides for that app, otherwise
the global overrides.
Closes: #2041
Approved by: alexlarsson
This option removes an override file. If an appid
is given, it removes overrides for that app, otherwise
the global overrides.
Closes: #2041
Approved by: alexlarsson
The current pid column reports the pid of the bwrap
wrapper process running outside the sandbox. Add a
child-pid column that reports the pid of the main
sandbox process ("PID 1" on the inside).
Closes: #2039
Approved by: alexlarsson
This enumerates running Flatpak instances.
For now, we just print the app ID and the PID.
More details can be added in the future.
Closes: #2023
Approved by: alexlarsson
Store the pid of the bwrap process which gets spawned or exec'ed
by flatpak inside the instance directory. This can be useful
for others, such as gnome-software, or a future 'flatpak ps'
command.
We write the pid to a file named 'pid'. It will get cleaned
up together with the instance directory.
Closes: #2023
Approved by: alexlarsson
Currently the create-usb command reads the subpaths listed in the
flatpak deploy data and just passes those to the ostree pull operation
to copy them to the USB. But this is not the correct way to handle them,
and leads to installs from the USB failing in the case where the locale
is partial (more specifically the install of the main ref succeeds but
the install of the locale extension doesn't).
So this commit changes create-usb to handle subpaths the same way
flatpak_dir_pull() and flatpak_dir_deploy() do, which is to copy the
/metadata path along with a subdirectory of /files for each listed
subpath. So in the case of an English partial locale, /metadata and
/files/en will be copied to the USB drive, and those are the subpaths
that will be pulled during the install (if the installing computer also
uses English).
Closes: #1972
Approved by: alexlarsson
This only fixes the leak when we don't hit an error condition. To fix it
in that case we need an autoptr for deep lists.
Closes: #1966
Approved by: alexlarsson
It's a good idea to NULL initialize g_autoptr/g_autofree variables, so
we can be sure uninitialized memory isn't passed to g_free or similar.
Closes: #1968
Approved by: alexlarsson
The old pattern of using a separate 'OCI' flag was very ugly
internally in the code once it was extended to flatpak bundles and
flatpakrefs - using a different URI scheme means that the nature
of the remote can't be accidentally lost in some part of the code.
Probing would be possible as well, but would make it difficult to
add a remote when offline, and also doesn't deal well with the
fact that our data layout is different for the two types of remotes -
the type of remote could change at any point!
As a side effect this change enables flatpakrefs and flatpak bundles for OCI
registries.
