This allows one extension point to match multiple versions of an extension.
In particular, this is useful for OpenGL so that we can match the version matching the current
runtime, as well as the "magic" 1.4 version for nvidia.
Closes: #1722
Approved by: alexlarsson
We forgot to include the sources. Also, we rename the valgrind header
to -private to avoid gtk-doc blowing its mind trying to parse it.
Closes: #1729
Approved by: alexlarsson
This gives access to AF_BLUETOOTH sockets in the seccomp rules. You additionally
need to give network access for the sockets to really work, because the
kernel doesn't (yet) namespace bluetooth sockets.
Closes: #1721
Approved by: alexlarsson
This also adds a call to this from flatpak build, although it is
not (yet) strictly necessary as all the flags it sets so far
are always set when building. This may change in the future though.
Closes: #1721
Approved by: alexlarsson
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
