Source: lua-cqueues
Version: 3.1.0-1
Severity: serious
User: debian-arm@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,

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,