Bug#1125101: RM: xpra [armhf i386] -- RoQA; not built since 2023, still depends on pre-t64 libraries
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: xpra@packages.debian.org, debian-arm@lists.debian.org, debian-arm@lists.debian.org, debian-ports@lists.debian.org
Control: affects -1 + src:xpra
User: ftp.debian.org@packages.debian.org
Usertags: remove
User: debian-arm@lists.debian.org
Usertags: armhf
User: debian-qa@lists.debian.org
Usertags: i386
User: debian-superh@lists.debian.org
Usertags: sh4
User: debian-68k@lists.debian.org
Usertags: m68k
User: debian-hppa@lists.debian.org
Usertags: hppa
User: debian-amd64@lists.debian.org
Usertags: x32
xpra in unstable seems to have most recently been built successfully on
32-bit architectures in 2023 (possibly due to #1067627), and still
Depends on libglib2.0-0 on armhf and i386 (plus -ports architectures
hppa, ia64, m68k, sh4 and x32). libglib2.0-0 was superseded by
libglib2.0-0t64 in early 2024 during the time_t transition.
On the release architectures, this is keeping the obsolete libglib2.0-0
around as a "cruft" package, which in turn is causing problems for
piuparts testing of newer versions of src:glib2.0 (#1111475). On the
-ports architectures, if I understand correctly it will be
uninstallable, because the dak reimplementation used for -ports
immediately removes "cruft" even if something depends on it.
ftp team: please consider removing xpra:armhf (it's uninstallable) and
perhaps xpra:i386 (still installable, but only because
libglib2.0-0t64:i386 still has its old ABI and therefore Provides the
old name). It doesn't appear to have any rdeps, and isn't in testing.
-ports team (cc'd): it might be a good idea to remove xpra from the
affected architectures on -ports too, for consistency.
Thanks,
smcv
Reply to: