Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
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
Reply to: