This moves all the files from lib into common, and it also adds all the libflatpak
sources into libflatpak-common, making libflatpak just a wrapper around the common
helper library.
This move allows the CLI to use all the code from libflatpak. We were already doing
this with a few things like flatpak-error*.[ch], and we want to do it even more
when sharing FlatpakTransaction. This also allows use to slowly move
the CLI to using the libflatpak apis for some things.
Closes: #1706
Approved by: alexlarsson
This way everything works with /var/tmp on tmpfs or other non-xattr system
by default. The reason we used to use bare-user for the child repo is that bare-user-only
can't represent all possible ostree repos. For instance a file non-canonical permissions
such as "readable by user but not other/group" cannot be stored. Reading back such a file
when commiting to the real repo would give you a repo-corrupt error.
However, its been a long time since we made flatpak always generate canonical permissions
for all exports, so at this point I think its safe to switch this over by default.
This also fixes https://github.com/flatpak/flatpak/issues/1622Closes: #1686
Approved by: alexlarsson
Currently if you try to do an offline app install from a USB drive and
the app requires a runtime that's not already installed (or a different
version is installed), the install operation will fail, even if the
needed runtime is available on the USB drive.
The commit ensures that you can successfully find the dependencies
available from peer sources by making flatpak_dir_remote_has_ref() use
flatpak_dir_get_remote_state_optional(), which treats a summary fetch
error as non-fatal. Due to how flatpak_remote_state_lookup_ref() is
written, the summary is still required if there's not a collection ID
set on the remote.
This is a partial fix for https://github.com/flatpak/flatpak/issues/1583Closes: #1673
Approved by: pwithnall
Currently when you try to do an offline app install from a USB drive,
the install succeeds but without installing any of the related refs,
even if they're available on the USB. This means you end up with a
broken install that's missing locale extensions, content, etc. depending
on what the related refs provide.
The related ref information is already gleaned from the xa.cache data
which is available offline via ostree-metadata refs that should be
provided by peer sources (and available in summary files as well). In
the near future this will be changed so that we use commit metadata
instead of xa.cache (see https://github.com/flatpak/flatpak/issues/1592)
but for now it at least allows offline installs to work. So the only
remaining step is to remove a dependency on the remote summary when
checking for the related ref in the remote in
flatpak_dir_find_remote_related(). This is accomplished by reworking
flatpak_remote_state_lookup_ref() so that it falls back to using the
xa.cache data when the summary isn't available. One effect of this is
that we no longer necessarily have the checksum for the ref, since
checksums aren't present in xa.cache data. As far as I can tell, none of
the consumers of this API have a hard dependency on the checksum
information (I checked GNOME Software too).
This is a partial fix for https://github.com/flatpak/flatpak/issues/1583Closes: #1673
Approved by: pwithnall
This shortens the commandline length of the proxy a lot, making it typically:
/usr/libexec/flatpak-bwrap --args 20 /usr/libexec/flatpak-dbus-proxy --args=23
This looks a lot nicer in ps.
Closes: #1676
Approved by: alexlarsson
This uses FlatpakBwrap to simplify the setup of the dbus-proxy,
resulting in cleaner code, but also a better base for future work
to pass pre-created socket fds into the proxy instead of paths.
Closes: #1676
Approved by: alexlarsson
It was taking a copy of the repository configuration, modifying the
original repository configuration (not the copy), then saving the copy
to disk.
Add a test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1667
Approved by: mwleeds
When we start a sandbox and one of the directories we bind-mount into the sandbox, for example
one of the top dirs like /boot, is an autofs, then the bind mount will trigger an automount.
Often this is not really a problem, but in some cases (such as a missing device or a network
mount that is not available) this can block for potentially a very long time.
Ideally we would like to avoid this by not triggering the automount when bind-mounting, but
that doesn't seem possible with the current kernel APIs. So, instead we try to detect
any autofs paths and try to do a blocking operation on them, if this takes more than
200 milliseconds we assume the mountpoint is broken and ignore it.
There are various technical details here:
We can check for autofs using open(O_PATH) + fstatfs() and looking for
f_type == AUTOFS_SUPER_MAGIC (as described in the open manpage).
The blocking operation we do is open(O_DIRECTORY), but to allow this to timeout we
need to fork() and do this in the child, which we can kill after timing out, whick
we detect via select() using a self-pipe.
This fixes https://github.com/flatpak/flatpak/issues/1633Closes: #1648
Approved by: alexlarsson
See the comment added in the code for an explanation: if
core.add-remotes-config-dir=true, we must avoid adding configuration in
both /etc/flatpak/remotes.d/ and /ostree/repo/config. In lieu of
actually supporting adding the configuration in the right place, bail
early to avoid leaving partial configuration in the wrong place.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://github.com/flatpak/flatpak/issues/1665Closes: #1666
Approved by: alexlarsson
This commit makes two more functions P2P friendly:
flatpak_dir_find_remote_ref() and flatpak_dir_find_remote_refs(). This
is accomplished by getting the list of remote refs from the Flatpak
cache stored on the ostree-metadata ref, rather than from the remote
summary. I put the remote refs into the same data structure that was
used before so the rest of the code can stay the same. It would be more
efficient to use a separate data structure for the cached refs so we can
do a binary search rather than a linear one, but I don't think the
performance difference will matter.
One effect of this is that offline P2P app installs (such as from a USB
drive) are working now. This is also a partial fix for
https://github.com/flatpak/flatpak/issues/1583
Fixes https://github.com/flatpak/flatpak/issues/1522Closes: #1670
Approved by: alexlarsson
On some code paths, flatpak_dir_get_remote_state_optional() is used so
summary fetch errors and metadata fetch errors are treated as non-fatal,
and later flatpak_remote_state_ensure_summary() or
flatpak_remote_state_ensure_metadata() is used, which gives a pretty
unhelpful error message. So this commit saves the error from a failed
summary or metadata fetch into the FlatpakRemoteState object and prints
the message when the flatpak_remote_state_ensure_* function is called to
make that error message more specific and useful.
This also means that the "fail with missing gpg key" unit test in
test-repo.sh is working again. It was broken by the last commit ("dir:
make optional summary really optional) which caused the install
operation in that test to fail later than before with a different error
message.
Closes: #1637
Approved by: alexlarsson
We should not require a collection ID to be set for this to actually be
optional.
Doing so will make us require a network connection for flatpak installs
and updates even in case we already have the requested ref available.
A use-case that breaks is pulling a ref beforehand (e.g. using ostree
pull, or flatpak with FLATPAK_INSTALL_FLAGS_NO_DEPLOY), and later
deploying it explicitly at a time when network is not available anymore
(e.g. during boot time), using FLATPAK_INSTALL_FLAGS_NO_PULL.
This also means that creating a FlatpakRemoteState object for a disabled
remote no longer causes an error as long as the summary is optional, so
installing .flatpak bundles works again.
Fixes https://github.com/flatpak/flatpak/issues/1636Closes: #1637
Approved by: alexlarsson
In flatpak there are two ways a remote can be disabled, an empty URL or
xa.disable set to TRUE. flatpak_dir_remote_fetch_summary() already
doesn't try to fetch the summary in the former case; this checks the
latter as well.
Closes: #1641
Approved by: alexlarsson
The fix in 5122766284 was not right.
First of all it didn't changethe regressing behaviour for
build-finish, just install.
Secondly, it changed the prefix matches to always use
flatpak_name_matches_one_wildcard_prefix() which had slight
differences in behaviour that the previously used
flatpak_name_matches_one_prefix. For example, it always removed
the extension, no matter what it was.
This has all been replaced with a shared (between install and
build-finish) version that is more strict with extensions, and with
what names can be exported as service files (these have to match
exactly, with the wildcard and cannot have suffixes).
To test this i tried to install these apps from flathub that has
some more complex exports:
org.sparkleshare.SparkleShare:
org.sparkleshare.SparkleShare.Invites.desktop
org.sparkleshare.SparkleShare-symbolic.svg
org.libreoffice.LibreOffice:
org.libreoffice.LibreOffice.desktop
org.libreoffice.LibreOffice-impress.desktop
org.libreoffice.LibreOffice-writer.png
org.libreoffice.LibreOffice-calc.png
com.github.bajoja.indicator-kdeconnect:
com.github.bajoja.indicator-kdeconnect.desktop
com.github.bajoja.indicator-kdeconnect.settings.desktop
com.github.bajoja.indicator-kdeconnect.tablettrusted.svg
com.github.philip_scott.spice-up:
com.github.philip_scott.spice-up.svg
com.github.philip_scott.spice-up-mime.svg
com.github.philip_scott.spice-up.mime.xml
org.gnome.Recipes:
org.gnome.Recipes.desktop
org.gnome.Recipes.service
org.gnome.Recipes-search-provider.ini
org.gnome.Recipes.png
org.gnome.Recipes-symbolic.symbolic.png
org.gnome.Recipes-mime.xml
org.gnome.Characters:
org.gnome.Characters.desktop
org.gnome.Characters.BackgroundService.service
org.gnome.Characters.service
org.gnome.Characters.search-provider.ini
org.gnome.Characters.png
org.gnome.Characters-symbolic.svg
org.gnome.Weather
org.gnome.Weather.Application.desktop
org.gnome.Weather.Application.service
org.gnome.Weather.BackgroundService.service
org.gnome.Weather.Application.search-provider.ini
org.gpodder.gpodder:
org.gpodder.gpodder.desktop
org.gpodder.gpodder.gpodder-url-handler.desktop
Only complete to subrefs is fully matching real part. For example,
only match org.foo.Bar.Sources for "org.foo.Bar", "org.foo.Bar." or
"org.foo.Bar.S", but not for "org.foo" or other shorter prefixes.
This commit changes flatpak_dir_pull_untrusted_local() to avoid using
the summary file in the source repo if a collection ID is set and use
ostree_repo_resolve_rev() instead in that case. Since summary signatures
are not part of the security model when collection IDs are used, this
doesn't change any security properties. But it does make pulls succeed
when there's nothing to do (i.e. the child repo has no refs because the
parent repo already has the desired commit). In that case, the summary
file will be empty if collection IDs are being used because of
child_repo_ensure_summary().
The end result of this is that "flatpak update --appstream" works when
there's a collection ID set on the remote and the appstream is already
up to date locally. This problem only recently became visible because
flatpak_dir_check_for_appstream_update() was removed in a recent commit.
This is a partial fix for https://github.com/flatpak/flatpak/issues/1615
In flatpak_dir_update_appstream(), we check for the appstream ref after
pulling it and before deploying it. When the system helper is not being
used we properly include the remote name in the refspec passed to
ostree_repo_resolve_rev(), so this commit does the same for the system
helper case. Otherwise we might end up with the checksum for an
appstream ref from another remote because of the relationship between
the child and parent repos. This doesn't have any user visible effect
except preventing a "false positive" of thinking an appstream pull was
successful when it wasn't.
Currently we try to update the "appstream2" branch and if that fails try
to update the "appstream" branch. If that fails too we return the error
message from the appstream2 update, which can be misleading. So this
commit combines both error messages into one so you get something like
this:
$ flatpak update --appstream tamaulipas-apps
error: Error updating appstream2: No such ref 'appstream2/x86_64' in
remote tamaulipas-apps; Error updating appstream: Update is older than
current version
That should make debugging easier for
https://github.com/flatpak/flatpak/issues/1615.
A symbol from this (flatpak_portal_error_quark) was leaked to libflatpak
due to being marked FLATPAK_EXTERN, so to keep ABI we move it back.
Fixes https://github.com/flatpak/flatpak/issues/1613Closes: #1616
Approved by: alexlarsson
On 32 bit ARM platforms, flatpak_get_compat_arch() returns NULL, so
handle that gracefully in flatpak_get_arches().
Closes: #1614
Approved by: alexlarsson
The telegram app id is org.telegram.desktop, and its appstream
component id is org.telegram.desktop.desktop, which we did not
properly handle (we special cased the app-id-ends-with-desktop case
and then did not remote .desktop). This replaces that with a more
approach that *always* matches the whole app id as prefix, and then
replaces a ".desktop" in the suffix part only.
Closes: #1593
Approved by: alexlarsson
This makes flatpak_remote_state_lookup_cache() return the metadata
from the actual FlatpakRemoteState rather than duplicating it.
All callers are updated to not free anymore and to strdup if needed.
Closes: #1594
Approved by: alexlarsson
