Your message dated Sun, 3 Mar 2024 20:06:09 -0500 with message-id <2uvfgbjsjsopyqpqubmqqimmfqf5lu3iauu242xlexeavdryb6@wnjek6z3r2ik> and subject line Re: Bug#1064193: lua-cqueues: identified for time_t transition but no ABI in shlibs has caused the Debian Bug report #1064193, regarding lua-cqueues: identified for time_t transition but no ABI in shlibs to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1064193: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064193 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Source: lua-cqueues Version: 3.1.0-1 Severity: serious User: debian-...@lists.debian.org Usertags: time-t Dear maintainers, Analysis of the archive for the 64-bit time_t transition[0][1] identifies lua-cqueues 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, lua-cqueue's shlibs file declares a dependency on a library package name that contains no ABI information: $ cat DEBIAN/shlibs liblua5.1-cqueues 0 lua-cqueues (>= 20200726) liblua5.2-cqueues 0 lua-cqueues (>= 20200726) liblua5.3-cqueues 0 lua-cqueues (>= 20200726) liblua5.4-cqueues 0 lua-cqueues (>= 20200726) $ It is therefore not obvious that we should rename the package to 'lua-cqueuest64' as part of this transition. Looking at the archive, there is a package built from the separate lua-http source package that depends on this library. 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 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-16T21%3A19%3A00/logs/lua-cqueues-dev/base/log.txt
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---On Sun, Feb 18, 2024 at 12:10:48AM -0800, Steve Langasek wrote: > Analysis of the archive for the 64-bit time_t transition[0][1] identifies > lua-cqueues 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. It was the latter. After fixing the path to compat-5.3.h, includuing lua.h from the proper lua version, and working around a-c-c's insistence on using the C++ backend, the analysis shows that lua-cqueues is not affected by the transition. Closing the bug. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
--- End Message ---