Source: lua-luv Version: 1.44.2-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-luv as an affected package, on the basis that it depends on some library whose ABI is sensitive to time_t, which requires reverse-dependencies to be built with LFS support enabled, and lua-luv's own ABI is sensitive to LFS support. However, lua-luv's shlibs file declares a dependency on a library package name that contains no ABI information: $ cat DEBIAN/shlibs liblua5.1-luv 0 lua-luv (>= 1.44.2-0) liblua5.2-luv 0 lua-luv (>= 1.44.2-0) liblua5.3-luv 0 lua-luv (>= 1.44.2-0) liblua5.4-luv 0 lua-luv (>= 1.44.2-0) $ It is therefore not obvious that we should rename the package to 'lua-luvt64' as part of this transition. Looking at the archive, there are packages built from the separate lua-nvim and neovim source packages that depend 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
signature.asc
Description: PGP signature
