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
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
These portals are under their own bus name and
object path, clarify this in the docs. For the
document portal, this is just a sync-up with
the master copy in the xdg-desktop-portal repo.
Closes: #2074
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
Our benchmarks show this significantly reduces the interactivity impact of
ongoing Flatpak operations while the user is continuing other tasks on the
system. The effect is very pronounced with the default CFQ scheduler, and in
combination with BFQ, using the idle class improves the worst case to nearly
the same as an unloaded system.
Closes: #2071
Approved by: alexlarsson
This is made to let gnome-software enumerate all
running instances and get the same information
about them that flatpak ps provides.
For now, we keep it private. It will become library
api once we open new development
Whenever we forward some error from a lower level dbus call to the
caller of the library we strip the extra gdbus error info via a call
to g_dbus_error_strip_remote_error(). We do this, because callers of
libflatpak has no idea that there were remote calls involved, so they
will not do this themselves.
Closes: #2070
Approved by: alexlarsson
There have been some minor edits in the official version
of this in xdg-desktop-portal. Sync up the version here.
Closes: #2064
Approved by: alexlarsson
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
Create a bwrapinfo.json file and tell bubblewrap
to write its 'info' there. For now, this just contains
the child-pid. More may appear over time.
Closes: #2039
Approved by: alexlarsson
Flatpak has API called flatpak_installation_list_remotes_by_type() which
can list dynamic (LAN/USB) remotes that mirror configured remotes in an
installation. It does this by searching them for the appstream/<arch>
ref, such as appstream/x86_64. But Flatpak now supports
appstream2/<arch> as a way to provide the appstream data as uncompressed
XML, and it's possible that a USB created with `flatpak create-usb` (or
a LAN peer) only has the appstream2 ref available for a certain
collection ID. So this commit changes
list_remotes_for_configured_remote() so that it looks for both
appstream/<arch> and appstream2/<arch>, which makes
flatpak_installation_list_remotes_by_type() robust to that scenario.