This prevents a crash in flatpak_installation_list_remotes_by_type() if
the `FlatpakDir` can’t ensure it has a repo configured.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #3028
Approved by: alexlarsson
The org.freedesktop.Flatpak user D-Bus service isn't just used by
flatpak(1) or applications running as Flatpaks. It's also used by
toolbox(1) for similar reasons:
* To keep various configuration files inside the container
synchronized with the host
* To let the container request certain commands to be run on the host
The org.freedesktop.Flatpak D-Bus service itself doesn't need much in
the way of dependencies, but inherits a lot of unused shared library
linkages through the libflatpak-common.la convenience library. Removing
these unused shared libraries reduces the footprint of toolbox(1) for
those who care about such things. eg., Fedora CoreOS.
This commit brings down the number of shared libraries to 19 from 62.
Closes: #3052
Approved by: alexlarsson
... by moving the definition of FlatpakHostCommandFlags from the
'common' sub-directory to 'session-helper'. It hasn't been used by
anything else ever since flatpak-builder was moved to a separate
repository in commit 52bd146561.
Closes: #3052
Approved by: alexlarsson
The libxml API is used in a relatively few places inside the 'common'
sub-directory. It's definitely not as widespread as GLib. A subsequent
commit will leverage this to prevent unused shared libraries from
being linked to the session helper.
Closes: #3052
Approved by: alexlarsson
The libarchive API is used in a relatively few places inside the
'common' sub-directory. It's definitely not as widespread as GLib. A
subsequent commit will leverage this to prevent unused shared
libraries from being linked to the session helper.
Closes: #3052
Approved by: alexlarsson
If the download URL for an icon was already cached locally, the HTTP
code returned FLATPAK_OCI_ERROR_NOT_CHANGED - this was treated as a real
error, and after downloading missing icons, all present icons were
deleted!
See https://bugzilla.redhat.com/show_bug.cgi?id=1683375Closes: #3048
Approved by: alexlarsson
Unfortunately in commit 253fcc6e3 I broke the build-bundle command so
that it is unable to resolve remote refs (as opposed to local ones).
This means in the normal case of building a bundle for an app installed
from a remote it fails:
$ flatpak build-bundle /var/lib/flatpak/repo gnome-calculator.flatpak org.gnome.Calculator stable
error: Refspec 'app/org.gnome.Calculator/x86_64/stable' not found
This is because flatpak_repo_resolve_rev() interprets a NULL remote name
to mean the ref is local (in refs/heads/) but in this case we just don't
know which remote it's from. This commit fixes the issue by using
ostree_repo_resolve_rev() directly which searches refs/heads/ and
refs/remotes/, and if that fails falling back to iterating over refs
returned by ostree_repo_list_collection_refs() to catch collection-refs
that may be in refs/mirrors/.
Also, add a unit test that fails without this patch.
Fixes https://github.com/flatpak/flatpak/issues/3026Closes: #3032
Approved by: alexlarsson
It's an error to call g_set_error() on an error that's already set, and
flatpak_dir_get_deploy_data() already sets FLATPAK_ERROR_NOT_INSTALLED
for us when necessary, so just pass on any errors to the caller of
flatpak_dir_get_origin(). In the case that the error is something else,
that should be treated as an error, because we never expect the deploy
directory to exist but not have a deploy file (see the implementations
of flatpak_dir_deploy() and flatpak_dir_undeploy()).
Closes: #3032
Approved by: alexlarsson
The docs for flatpak_is_valid_branch() say branch names can't start with
a digit but the implementation doesn't enforce this, and we have lots of
branches out in the wild that start with a digit (e.g. "3.32" and
"5.12"). So make the docs imply that branches can start with a digit.
The implementation also disallows "." as the leading character for a
branch, so add that to the docs. I'm just guessing that "." was intended
to be disallowed but it makes sense; otherwise the file we create named
with the branch would be hidden.
Closes: #3023
Approved by: alexlarsson
This works around an old polkit client library bug which would cause
a segfault in this situation. The bug was fixed long ago in upstream
polkit, but is still present in Debian 10 'buster', Ubuntu 19.04 'disco'
and all older releases, due to Debian/Ubuntu using a branch of polkit
to avoid the mozjs dependency. It should finally get fixed in Debian 11
and Ubuntu 19.10.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug-Debian: https://bugs.debian.org/923046Closes: #2997
Approved by: matthiasclasen
This restores the ABI to the pre-1.4.0 version. This moves the new signal to
the *end* of the struct and also correctly decrements the padding.
Fixes https://github.com/flatpak/flatpak/issues/2957, although we probably need
a 1.4.1 release with this included pretty quickly to avoid chaos.
Closes: #2958
Approved by: alexlarsson
There are a few cases where -origin remotes don't get removed when
their refs are uninstalled, most notably when xa.noenumerate is set, or
somehow the uninstall gets interrupted at the wrong time. Regardless
of the reason, the remote could never be removed after this, unless a
new ref is installed from it and then removed, or noenumerate is set.
Closes: #2920Closes: #2953
Approved by: alexlarsson
Now that validate-icon uses execvpe(), status and error were never set,
so rerun_in_sandbox() would have crashed while dereferencing a NULL
error if execvpe() failed. This is reproducible with, for example:
FLATPAK_BWRAP=/bin/nope flatpak-validate-icon --sandbox 48 48 /path/to/icon
execvpe() does not return on success (the process image is replaced),
and sets errno on failure, so behave accordingly.
Also print the error message to stderr, even if G_MESSAGES_DEBUG is not
set, since it's our only opportunity to indicate to a caller what has
gone wrong.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2950
Approved by: alexlarsson
