Bug#1111470: trixie-pu: package glib2.0/2.84.4-3~deb13u1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: trixie d-i
X-Debbugs-Cc: glib2.0 at packages.debian.org, debian-boot at lists.debian.org
Control: affects -1 + src:glib2.0
User: release.debian.org at packages.debian.org
Usertags: pu

I'd like to backport the GLib from unstable into trixie for 13.1. We've 
intentionally been keeping most of GNOME 49 in experimental for now, to 
get wider testing for the first round of what will become stable updates
to trixie's GNOME 48.

Or, if this is too many changes, I'd like to at least backport the 
preinst and postrm changes for #1110696, and preferably the new upstream 
release as well - but that would already be most of the changes proposed 
here, at which point we might as well benefit from the full set having 
been tested by users of unstable.

Please let me know whether I can upload as-is, or whether I should do a 
respin of this with a reduced scope.

[ Reason / Impact ]

1. #1110696. There's a corner case in the upgrade path from bookworm to
   trixie that results in functionally necessary files from GLib being
   deleted, causing most GLib/GTK apps to crash out with a fatal error
   until it is worked around with `dpkg-reconfigure libglib2.0-0t64`.
   (This is a special case of #1065022.)

   To reproduce:
   - start on bookworm or older
   - install libglib2.0-0 for a foreign architecture (typically i386)
   - remove all packages from the foreign arch without purging libglib2.0-0
   - remove the foreign arch from dpkg's configuration
   - upgrade to trixie
   - purge the foreign architecture's libglib2.0-0

   Related to #1065022 and #1110696, I made the postrm safer for the
   future: if it detects that there are still GSettings schemas or
   GIO modules present during purge, it will not delete the relevant
   generated files, guarding against accidental loss of those files in
   upgrade scenarios that we haven't yet thought of. If we had done this
   before, #1065022 would not have happened.

2. #1110825. Compiling language bindings against libgirepository-2.0-dev
   would generate dependencies that do not indicate which libffi ABI
   they assume, resulting in some broken combinations being allowed by
   dependencies during the next libffi transition. In practice I believe
   there are not yet any packages in trixie, forky or sid that use
   libgirepository-2.0-dev: gjs, pygobject, etc. are still using
   libgirepository-1.0-dev, except in experimental.
   I addressed this by forward-porting how we handle this in
   libgirepository-1.0-dev (part of src:gobject-introspection).
   If we can fix this before anything uses libgirepository-2.0-dev in
   production, then the next libffi transition won't need sourceful
   uploads of glib2.0 and can most likely be done via binNMUs.

3. The autopkgtest for future bugs related to #1065022 had regressed and
   no longer works. This is mostly harmless (it's marked as flaky anyway)
   but fixing it improves confidence that #1065022 has been handled
   and will not come back.

4. Upstream: #1110640 (CVE-2025-7039), a no-dsa CVE that I believe is not
   exploitable in practice. It would be good to have it fixed in case
   I'm wrong.

5. Upstream: a new upstream bugfix release which came too late to be
   included in 13.0. Nothing hugely urgent but the fixes would be good
   to have; in particular there might be apps/language bindings that
   expect g_settings_bind_with_mapping_closures() to work as documented.

[ Tests ]

In general: autopkgtests are relatively extensive and all pass, my GNOME 
laptop still works normally with the functionally equivalent version in 
sid, and a GNOME desktop still works with the proposed version for 
trixie.

An almost-functionally-equivalent version has been in unstable since 
2025-08-12 with no regressions reported by users. There was one known 
regression in the initial upload, fixed a few days later after I noticed 
it while preparing this trixie-pu: packages compiled against the new 
libgirepository-2.0-dev would be uninstallable, because I forgot to add 
the necessary Provides (now fixed in unstable and in this proposed 
update). But in practice that never affected anything outside experimental.

We saw an autopkgtest regression on i386 only (#1111373, a program that 
was statically linked to GLib segfaulting during startup) but I can't 
reproduce it, and now neither can ci.debian.net.

For the specific changes:

1. Manually tested: I updated the included manual test script
   debian/tests/manual/1065022.sh to also reproduce #1110696 when run
   with argument "1110696", and ran it with that argument.
   As expected, it failed with current trixie and succeeded with the
   proposed version.

   I also expanded the same script to exercise other improvements to the
   safety of the postrm: it now asserts that the generated files are
   correctly deleted during purge, except that when run with argument
   "extra-schema" or "extra-module", it creates an additional,
   unpackaged GSettings schema or GIO module before purge, and asserts
   that in this case the generated file is *not* deleted.

   To verify:
   - put proposed trixie packages in /path/to/proposed/debs
     (both amd64 and i386 are required)
   - "dpkg-scanpackages --multiversion . > Packages" in that directory
   - podman run --rm -it \
         -v /path/to/glib:/mnt/glib:ro -w /mnt/glib \
         -v /path/to/proposed/debs:/mnt/trixie:ro \
         debian:bookworm-slim debian/tests/manual/1065022.sh
   - then repeat with argument "1110696"
   - then repeat with argument "extra-schema" instead
   - then repeat with argument "extra-module" instead
   - in each case exit status should be 0
     (last line on stderr is "+ exit 0")

2. Not tested in the trixie version because there is nothing in trixie
   that would exercise it, but I rebuilt pygobject/experimental locally
   against the version in unstable, and it generates dependencies on
   the new virtual package libgirepository-2.0-0-with-libffi8 as
   expected (and this time they are satisfiable).

3. I ran the updated autopkgtest on amd64 in autopkgtest-virt-qemu and
   autopkgtest-virt-lxc, and it passes.

4. No specific test coverage, only the upstream test suite.

5. No specific test coverage, only the upstream test suite.

[ Risks ]

It's a key package in all desktop environments.

Essentially all changes are targeted at fixing specific bugs. The 
changes for #1110696 are not strictly minimal, but I tried to make them 
as easy as possible to review, even where that increased the diffstat a 
little.

The preinst is (still) doing out-of-spec things to go behind dpkg's back 
and disarm a faulty postrm in an earlier GLib version (as agreed with 
the technical committee on #1065170), so it does need some care.

We don't know why the unreproducible regression #1111373 happened on 
i386, or why it stopped happening. Mitigation: if it recurs, it will 
primarily affect qemu-user:i386 (the only statically linked GLib 
executables that I know about), and I don't think that package is 
frequently-used, particularly now that i386 is officially only for 
compatibility with legacy binaries.

The changes for #1110825 are a bit noisy, but it's still relatively 
narrowly targeted, would give us better confidence that the next libffi 
transition can be done via binNMUs, and as far as I can see nothing in 
trixie depends on the affected binary packages yet. I'm proposing to 
include this change because it would ensure that we don't need Breaks on 
any future trixie backports that might add this dependency.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [~] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

The attached diff is a git diff rather than a debdiff, to minimize the 
noise caused by renaming libgirepository-2.0-0.symbols to 
libgirepository-2.0-0.symbols.in. I intend to upload using dgit, which 
will guarantee that the .dsc exactly matches the tree that is in the git 
repo.

[ Changes ]

The only changes vs. unstable are in debian/tests/manual/1065022.sh and 
metadata (d/changelog, d/control Vcs-Git, d/gbp.conf debian-branch); the 
code that runs on end-user systems is the same as in unstable.

Changes since trixie, broken up by topic (see [ Reason / Impact ] above):

1. #1110696
   - d/libglib2.0-0t64.preinst: the actual bug fix; expand cleanup of
     the faulty postrm in bookworm to delete more instances
   - d/libglib2.0-0t64.postrm: preemptively avoid having this class of
     problem in future by being more careful not to delete files that
     might still be needed, while trying to make the new script as
     obviously-correct as possible
   - d/libglib2.0-0t64.postinst: silence shellcheck warnings
     (I was using shellcheck to try to make sure the maintainer
     scripts don't have real issues; no functional change in practice)
   - d/tests/manual/1065022.sh: Expand manual test script to exercise
     the related bug #1110696 as well as #1065022. This script is not
     included in any .deb or run automatically.

2. #1110825:
   - d/extra-substvars.py, heavily based on the script of the same name
     in src:gobject-introspection
   - d/control: emit a versioned Provides in libgirepository-2.0-0 to
     indicate what libffi ABI it is working with
   - d/control: B-D on python3-debian:native, for that script
   - libgirepository-2.0-0.symbols{,.in}: rename and edit to be
     processed by d/rules, generating dependencies on the virtual
     package if and only if a libffi-related symbol was used
   - d/rules: generate libgirepository-2.0-0.symbols from .in
   - d/clean: clean up the generated files

3. All changes in debian/tests/1065022-futureproofing

4. Upstream changes in glib/gfileutils.c

5. All other upstream changes

[ Other info ]

This will need a d-i ack for libglib2.0-udeb.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trixie.diff
Type: text/x-diff
Size: 34946 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20250818/8951ad0f/attachment-0001.diff>