On 2023-11-19 13:54:02 +0100, Hilmar Preuße wrote: > On 11/19/23 00:40, Adrian Bunk wrote: > > On Sat, Nov 18, 2023 at 11:51:15PM +0100, Hilmar Preuße wrote: > > > On 11/18/23 20:18, Samuel Thibault wrote: > > Hi all, > > > > > nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild > > > > against new zlib" > > > > > > > Thanks for filing the NMU bug. > > > > > > > So a binnmu of the texlive-bin source package seems needed on all archs > > > > to fix installing texlive-binaries. > > > > > > > > > > I tested if recompiling solves the issue and it does. Hence I bump > > > severity > > > of the NMU bug the get a solution ASAP. > > > > I don't see how a binNMU would solve the problem. > > > > A proper fix would be either to: > > 1. patch the version check out of texlive-bin (preferred), or > > > I can patch out that version check as found by Samuel, but I don't see how > that would solve the core dump or the SIGABRT, which was reported. I hope > lua_error(L) is not the equivalent of "exit with SIGABRT". ;-) > > I still suspect that something broke in the API of zlib, the zlib people are > not aware of.
That crash is the fault of lua_error(L). Removing the version check including the call to lua_error is the proper fix for this. If any of the binaries of texlive-bin require a minimum version of the zlib, this needs to be reflected in Depends and not with a deliberate crash. > > 2. ensure texlive-bin has package dependencies that match this runtime > > check > > The zlib people, did not change the API version or created a version > statement in the depends line like "Depends: ... zlib1g (>= 1:1.3)", hence > I'd add an artificial "Breaks: ... zlib1g (<= 1:1.2.3)" to my > texlive-binaries package to make sure 1.3 is in place, when the new > texlive-binaries comes in. Correct? No, that's certainly the incorrect fix. Especially if that is hard-coded. Cheers -- Sebastian Ramacher