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

Attachment: 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 ---

Reply via email to