As per https://bugs.kde.org/show_bug.cgi?id=361770, this is not supported
by valgrind. We just don't seal the fds when debugging, this won't
affect anything at runtime in the normal case.
Closes: #1720
Approved by: alexlarsson
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
Add FLATPAK_UPDATE_FLAGS_NO_PRUNE and flatpak_installation_uninstall_full()
to the documentation, along with a couple of small fixes.
https://github.com/flatpak/flatpak/issues/1703Closes: #1705
Approved by: pwithnall
Sometimes, it can be interesting to allow specifying that we don't want to
run a prune operation right after uninstalling a flatpak, so let's add this
new method and a new FlatpakUninstallFlags type so that we can express that.
https://github.com/flatpak/flatpak/issues/1703Closes: #1704
Approved by: alexlarsson
Add a new FLATPAK_UPDATE_FLAGS_NO_PRUNE so that we can specify from clients
when we don't want to perform a prune right after updating a flatpak, even
if no FLATPAK_UPDATE_FLAGS_NO_PULL flag has been set.
https://github.com/flatpak/flatpak/issues/1703Closes: #1704
Approved by: alexlarsson
The current condition being checked to decide when to prune after updating
a flatpak from the public API is probably not the best one, since NO_DEPLOY
doesn't imply that prunable objects will be available, as that's something
that depends on whether a pull operation is performed, not a deployment.
So, change that condition so that we now always prune after updating unless
a NO_PULL flag has been explicitly set, which means that no prunable objects
would be available and so it's safe to ignore that step.
https://github.com/flatpak/flatpak/issues/1703Closes: #1704
Approved by: alexlarsson
Since the remote metadata can come from either the summary file or the
ostree-metadata ref, and the latter is available offline, there's no
reason to require the summary file when fetching metadata. This commit
changes flatpak_installation_fetch_remote_metadata_sync() and
flatpak_installation_fetch_remote_size_sync() to treat summary fetch
errors as non-fatal. Treating them as fatal is currently preventing
GNOME Software from doing LAN app updates.
GNOME Software should ideally be using metadata from the commits
themselves, but that change will have to wait for the fix for
https://github.com/flatpak/flatpak/issues/1592, I think.
Closes: #1701
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
Currently flatpak's bash completion is a bit broken. It shows all files
with the appropriate extension (.flatpak or .flatpakref) rather than
just the ones starting with the characters you've already typed. So this
commit fixes that behavior by using the -X compgen option rather than
-G. For example, here's the old behavior:
$ flatpak install e<TAB>
bijiben.flatpak eos eos-runtimes
builder.flatpak eos-apps eos-sdk
and here's the new behavior:
$ flatpak install e<TAB>
eos eos-apps eos-runtimes eos-sdk
$ flatpak install b<TAB>
bijiben.flatpak builder.flatpak
Closes: #1645
Approved by: alexlarsson
In the cleanup() function used after each unit test exits, we kill the
dbus daemon process and remove the temporary test directory. However, on
an Endless Mini the daemon doesn't always exit properly before we try to
remove the test directory, leading to an error like:
rm: cannot remove '/var/tmp/test-flatpak-AlmZul/runtime/.dbus-proxy': Device or resource busy
which causes some of the tests to fail with e.g.:
ERROR: tests/test-bundle.sh - exited with status 1
I don't think this is specific to the Mini or to ARM computers; it could
probably happen on any slow computer. So this commit uses "kill -9"
instead of just "kill" to make sure the daemon exits.
Closes: #1642
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
