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
This commit fixes the handling of errors from installing/updating
related refs during a transaction, so that they're treated as non-fatal,
and so that the operation is skipped if the primary operation fails. The
current behavior is that a failure to install/update a related ref
causes the whole transaction to fail, and even after a failure to
install/update the primary ref the related ref install/update is
attempted.
I hit this error when doing an offline USB app install, when the USB
repo has an older version of the runtime and the runtime's locale
extension than what's in the local repo. Without this commit, the
failure to update the runtime (due to it being a downgrade) is treated
as a warning, but the failure to update the runtime locale is treated as
an error. With this commit, the runtime update failure is still treated
as a warning, and the locale update is not attempted. This is better
behavior because the locale extension update (or even install) is not
critical to the app install.
Closes: #1979
Approved by: alexlarsson
In https://github.com/flatpak/flatpak/pull/1689 we were meant to
have limited the receiving of broadcasts on portals, but die to a
bug in the proxy we accidentally allowed all broadcasts anyway.
The change which ignores all applied filters < POLICY_TALK fixes that.
However, it also turns out that the desktop portal actually *does*
rely on signals. For example the network portal uses property change
notification.
So, to make sure this works we allow all signal from the portal
names, but only if they are on a object path starting under
/org/freedesktop/portal (which incidentally all portal object are).
This means there is no real change in anything that is currently
deployed, but it does allow portals to opt out of this global signal
visiblity if they want by using a different object path, which we
want to use in dconf.
Closes: #1976
Approved by: alexlarsson
This commit fixes a regression that causes installing from a bundle to
fail if the bundled app's runtime was itself installed from a bundle, or
otherwise has a non-working remote (such as when the user is offline).
The fix is to treat a failure of flatpak_dir_find_latest_rev() as
non-fatal in resolve_ops() if the ref in question is already installed.
In other words, if we don't need to fetch a ref for the transaction to
succeed, errors in fetching remote info about the ref shouldn't be
fatal.
Closes: #1973
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
When I run `flatpak update` I get messages saying "Warning: No
xa.metadata in commit" which isn't very helpful without knowing what
commit is being referred to. So this commit adds the checksum and ref to
such error messages.
Closes: #1978
Approved by: alexlarsson
In the output of `flatpak build-bundle --help` it's not clear what
LOCATION is, so the least we can do is add an example of its usage to
the man page. At some point it would be nice to also have explanations
of positional arguments in help output.
Closes: #1974
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
