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.
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
Currently, we only remove stale instance directories
when a new instance ID is allocated. A future 'flatpak ps'
command will want to remove stale instances before
enumerating them, so make this function available.
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
The information in this file is of interest to other
users outside the sandbox, like gnome-software, or
a possible future 'flatpak ps' command.
We use the already existing instance directory, and
put the file at /run/user/$UID/.flatpak/$INSTANCE/info
The existing logic for cleaning up instance directories
will clean up the file.
Closes: #2023
Approved by: alexlarsson
I've inferred this by walking through the code, which ultimately calls
one of flatpak_build_[app|runtime]_ref() which both implement these
defaults.
Closes: #1995
Approved by: alexlarsson
There were two reasons why no docs for this class appeared in the HTML
documentation:
* flatpak-transaction-operation.xml was not included by
flatpak-docs.xml.
* all its symbols were listed in <SUBSECTION Standard>, which is hidden
from the HTML output. It appears that if a section has no visible
symbols, it's omitted.
Many symbols which belong to FlatpakTransaction were erroneously grouped
with FlatpakTransactionOperation and so also hidden; fix this too.
Closes: #1995
Approved by: alexlarsson
Without this, it's not safe to use 'pref': if there are no slashes in
'ref', 'pref == 0x1', and any attempt to dereference it later in the
function will crash.
Closes: #1995
Approved by: alexlarsson
Without explicit annotation, all optional parameters are assumed to be
mandatory, and 'const gchar **locales' is assumed to be a scalar string
input parameter (rather than an array or an in/out) for some reason.
Closes: #1995
Approved by: alexlarsson
If no installation path is specified at construct time, or if it doesn't
exist, priv->dir will be NULL even after initable_init() has been
called.
Closes: #1995
Approved by: alexlarsson
This is only used in the flatpak-builder tests now, not the main
flatpak tests.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #1990
Approved by: alexlarsson
For installed-tests, the installed test directory is not on the PATH.
To make this easier, put the uninstalled binary in tests/, so that
in both build-time and installed tests, it is in ${test_builddir}.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #1989
Approved by: alexlarsson
When deploying the appstream for an OCI remote we actually pull the
http remote. This triggers some libsoup code that recurses the default
mainloop. As this happens of the main thread we can get the response
back on the wrong thread leading causing us to never send the reply
back, hanging the call.
Closes: #2010
Approved by: alexlarsson
Apparently -- is not valid XML, so a nonbreakable space was added, but
that breaks gdbus-codegen, so lets just drop the dashes totally.
Closes: #1988
Approved by: alexlarsson
This reverts commit ed1d7eacf4 and fixes
the issue in a different way.
With the introduction of peer (LAN/USB) sources of refs comes a problem:
they may have outdated repository metadata (which is stored as
contentless commits on the branch "ostree-metadata"). Currently Flatpak
allows the older metadata to be pulled into the local repo, but this is
undesirable for a few reasons: it hurts the security properties of the
system because for example the GPG keys might have been rotated and you
don't want to go back to using the old ones, and it's undesirable
because the old metadata might have missing or wrong information about
the apps installed on the system.
So this commit makes Flatpak ignore the downgrade and use the newer
metadata for the offline operation. This is not a perfect solution,
because the newer metadata might have information (such as the download
size or needed runtime) that's not accurate for the old versions of the
refs that are available offline. This issue is significantly mitigated
by the fact that FlatpakTransaction operations use commit metadata to
make decisions, rather than depending on the xa.cache.
Another possible solution would be to read the outdated metadata into
the FlatpakRemoteState object without pulling it into the local repo or
using it to update the remote config, but that's not perfect either
because there's no guarantee you'll pull the metadata from the same
source as the refs (perhaps one comes from a USB drive and the other
from a LAN peer). Longer term, we should figure out how to rely less on
the xa.cache (which is stored in ostree-metadata) or otherwise make
architectural changes to solve those issues. For now, I think this fix
will be enough to make USB updates usable and secure.
Fixes https://github.com/flatpak/flatpak/issues/1473Closes: #1965
Approved by: alexlarsson
This will allow us to return anything in the FlatpakError domain using
g_dbus_method_invocation_return_gerror().
Closes: #1965
Approved by: alexlarsson
