Bug#1006905: bullseye-pu: package ostree/2020.8-2+deb11u1
On Mon, Mar 7, 2022 at 6:09 PM Simon McVittie <smcv@debian.org> wrote:
>
> If d/p/Fall-back-if-copy_file_range-fails-with-EINVAL.patch is not applied,
> users with an eCryptFS encrypted home directory cannot use `flatpak --user`.
> If they had already configured all necessary remotes before encrypting the
> home directory, the symptom is that `flatpak build-bundle` crashes; if not,
> from my tests on unstable, it appears that the symptom is that
> `flatpak remote-add` fails. (#1004467)
> There are indications from upstream bug reports that this patch might
> also fix similar issues for ZFS users, although this is not yet confirmed.
This is a safe patch as it just extends the cases where a fallback
will be run. Since it affects all users of ecryptfs, it seems like a
good idea to include.
> If d/p/Fix-marking-static-delta-commits-as-partial.patch is not applied,
> interrupted downloads can result in a corrupted local repository, requiring
> manual cleanup via `flatpak repair` or `ostree fsck`.
This is a really unfortunate bug in ostree that should be fixed ASAP.
For Endless I'm going to backport this to all of our supported stable
branches but haven't gotten around to it yet.
> If d/p/libotutil-Avoid-infinite-recursion-during-error-unwinding.patch is
> not applied, some failure modes (in particular the symptom of #1004467)
> lead to a crash instead of a graceful failure.
The change here is clearly correct and should have no unintended side
effects. Since this also affects all users of ecryptfs, it's a good
idea to have it in stable.
> If d/p/Fix-translation-of-file-URIs-into-paths.patch is not applied,
> users will be unable to install Flatpak apps from paths on the local
> filesystem that contain a backslash or non-ASCII, most commonly during
> "sideloading" from a USB stick created by `flatpak create-usb`.
We've been shipping this in Endless stable for about a year with no
reported issues.
> If d/p/lib-Fix-a-bad-call-to-g_file_get_child.patch is not applied,
> checking out only a subset of a commit (most frequently seen in Flatpak
> when installing locale data) can fail with an assertion failure if a
> backport or local build of GLib 2.71 is in use. I'm a little unsure about
> this one for bullseye, since I would generally not recommend backporting
> something as foundational as GLib, but it's a one-line fix. With my
> GNOME team hat on, we need to get GLib >= 2.72 into bookworm within the
> next few weeks, so if someone does a backport of bookworm's GLib into
> bullseye-backports, then the priority of this change will suddenly go up.
Even though this would only manifest with a newer GLib release, I
think this is a good idea to include in bullseye. It's a bit
unfortunate that GLib changed the semantics of g_file_get_child, but
the change makes OSTree checkouts more robust all around in the face
of user supplied subpaths.
> [ Risks ]
> I would say this is low-risk. They're narrowly-targeted patches, and
> all are straightforward backports, either from upstream release 2022.2
> (in unstable, not in testing yet) or from older releases that are already
> in testing.
I would agree that this is low risk. These patches fix real bugs, were
vetted by upstream, and are narrowly scoped. I think the risk of
regressions is very low. These are all things I plan to put in our
stable branch for Endless (I actually have the task to do that this
week).
--
Dan
Reply to: