Source: xmorph Version: 1:20150712-4 Severity: serious User: debian-...@lists.debian.org Usertags: time-t
Ciao Andrea, Analysis of the archive for the 64-bit time_t transition[0][1] identifies xmorph as an affected package, on the basis that the headers could not be compiled and analyzed out of the box using abi-compliance-checker[2], so we have to assume it's affected. However, libmorph's shlibs file declares a dependency on a library package name that contains no ABI information: $ cat DEBIAN/shlibs libmorph 1 libmorph (>= 1:20150712) $ It is not obvious that we should rename the package to 'libmorpht64' as part of this transition. Looking at the archive, there is a package that depends on this library, xmorph. Despite being built from the same source package, it does not have a strict versioned dependency on libmorph but instead uses the shlibs. Since there is no self-evident thing to do with the library package name here, we will not be handling this package as part of the mass NMUs. Instead I am filing a serious bug because partial upgrades from bookworm to trixie on 32-bit architectures (upgrading libmorph without also upgrading xmorph) will result in ABI skew and may result in broken behavior. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [0] https://wiki.debian.org/ReleaseGoals/64bit-time [1] https://lists.debian.org/debian-devel/2024/01/msg00041.html [2] https://adrien.dcln.fr/misc/armhf-time_t/2024-02-03T09%3A18%3A00/logs/libmorph-dev/base/log.txt
signature.asc
Description: PGP signature