We're getting "fuse: copy from pipe: short read" from
libfuse and a broken filesystem with this. See
https://github.com/flatpak/flatpak/issues/570
I've tried to look into if this is fixable, but I can't
really find any way we could do things differently that
may help, so the fix is to disable spice_read.
(cherry picked from commit 4fdac9e5d4)
Otherwise, anytime we fail in ostree_repo_write_metadata() will cause
an invalid free to happen, and flatpak to crash.
(cherry picked from commit d0b5b51076)
In case you happen to have a reference A with a related reference
B (say a runtime and a GL extension), and they come from different
remotes, then updating A should not cause B to update from the same
remote as A, but rather the current remote.
(cherry picked from commit 6793d90b82)
When we update an app and add updates for all the related
operations, such as locates, and it is already installed,
make sure we inherit the current subpaths rather than
use the default ones.
Fixes https://github.com/flatpak/flatpak/issues/587
(cherry picked from commit 51e14fe33b)
At the moment, flatpak applications are only given FamilyLocal family
xauth cookies from the Xauthority file. This is so, the sandboxed
application doesn't inadvertently get access to displays on other
computers.
But FamilyLocal isn't the only xauth family that's local. FamilyWild
entries can be local as well.
Furthermore, FamilyWild entries are preferable to FamilyLocal entries
when found, because they don't break if the system hostname is changed.
This commit makes FamilyWild xauth entries get propagated in the same
way as their FamilyLocal counterparts.
(cherry picked from commit a82708cb10)
So far, the installation of external apps can only be cancelled
before flatpak starts downloading the extra data, as there's no
cancellable being passed to g_input_stream_read_async().
This fixes that problem, making it possible to cancel installs
from GNOME Software regardless of the installation stage.
(cherry picked from commit 86bf88d89f)
Otherwise, clients such as GNOME Software won't be able to report
any progress once the flatpak application has been downloaded and
we enter the stage to download the extra data.
(cherry picked from commit 2e1740297c)
Otherwise, all the progress reporting for the extra data being downloaded
won't work, as the main context used by OstreeAsyncProgress will not be
the same than the one from the nested main loop used to download this.
(cherry picked from commit ca952b0f21)
It turns out that it is impossible for to get ptrace capabilities
for child user namespaces in the current kernel if the user
namespace is created as root, which is what happens when bwrap
is setuid root (see https://github.com/flatpak/flatpak/issues/557
for details).
This is very problematic, as ptrace rights controls access to
/proc/$pid/root which is what we base the detection of peer
app id and rights on for portals.
For now, we disable user namespaces (except for the case of
unprivileged user namespaces, where it is necessary and works).
(cherry picked from commit 521e7e6a37)
If we have network access, then nvidia talks to the xserver
and for some reason it then also needs /dev/nvidia-modeset.
So, lets add that to the dri device list.
(cherry picked from commit 763a686d87)
This is supposed to list all the currently loaded "non-standard" gl drivers.
If FLATPAK_GL_DRIVERS is set, then that is used, otherwise it looks
for an nvidia driver and if so, uses that, and always adding "default"
at the end which is meant to resolve to a stable mesa fallback build, as
well as "host" which can be used if you have a host-side driver
as an unmaintained extension.
(cherry picked from commit d4d15c7211)
If directory is "foo" and the extension id ends with ".ext" and
subdirectory-suffix is "sub" then the extension point will
be "/usr/foo/ext/sub" rather than just "/usr/foo/ext".
This is very useful when the extension point naming scheme is
"reversed". For instance, this happens for the /usr/share/themes directory.
An extension point for a gtk3 theme would be in /usr/share/themes/$NAME/gtk-3.0,
which could be achived by using subdirectory-suffix=gtk-3.0.
(cherry picked from commit 5e1d456b8b)
If your extension points set this, then each extension will have
the corresponding subdirectory added to LD_LIBRARY_PATH.
We also support a priority property in the ExtensionOf group
in the extensions themselves to set the search order.
(cherry picked from commit a3da0b3da8)
If we sort, or subset the extensions we use, then we can't just
set need_tmpfs on the first one, instead do the checking
for the first one when we're applying the extensions.
(cherry picked from commit 7f8ad5b3a1)
In extract_extra_data(), flatpak currently returns TRUE whenever
flatpak_repo_get_extra_data_sources() returns NULL, which is correct
most of the times since that's usually caused by the extra-data
finish-args argument not being present.
However, that operation relies on OSTree's ostree_repo_load_variant()
too, which could fail for unrelated reasons. And in those cases flatpak
would still keep returning TRUE here even in cases where the extra-data
sources could be there, but an error happened while retrieving it.
This seems to be a bug leading to unlikely -yet possible- situations,
where the user would end up with an "external app" like Spotify reported
to be succesfully installed but without the files/extra directory, which
is useless.
(cherry picked from commit 1d7357616b)
Alexander Larsson