On Sun, 25 Feb 2024 at 23:56:58 -0800, Steve Langasek wrote:
> I have attached the full list of current packages missing correct builds in
> experimental here for review. I am also attaching dd-list output for the
> same. Please check whether you have packages on this list that need
> attention.
> glib2.0 # already in experimental
The upstream version in experimental is unsuitable for unstable, but it's
"the same shape" as the version in unstable in all the places that matter,
and we ack'd the earlier NMU to experimental already, so I'm confident
that similar changes will apply cleanly to the version in unstable. The
GNOME team can probably handle this one when the time comes, if that
would help (I know your Canonical colleague Jeremy Bícha was asking to
let the GNOME team do coordinated team-uploads rather than NMUs, I'm not
sure what the resolution of that was).
Also, if it's valid to apply this reasoning:
- libhigh0 depends on liblow0
- liblow0 will transition to liblow0t64
- libhigh0 does not really need to change its name because we know that the
version built against liblow0 is the old ABI, the version built against
liblow0t64 is the new ABI, and they cannot be co-installable
then we can cross all of the GLib-based packages off the list
immediately, and handle them by transitioning glib2.0 from libglib2.0-0
to libglib2.0-0t64. That covers at least these:
> evolution # no sane ABI info, but maintainer handling via e-d-s
> gimp # already in experimental
> gtk+2.0 # false positive
> gtk+3.0 # false positive
> libvirt-glib # ftbfs
> mutter # already in experimental
> telepathy-farstream # known ftbfs
... and similar logic could be applied to in the Qt ecosystem, with Qt
as the low-level package. Does that help to reduce the numbers?
smcv
