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,
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". ;-)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 still suspect that something broke in the API of zlib, the zlib people are not aware of.
2. ensure texlive-bin has package dependencies that match this runtime check The zlib people, did not change the API version or created a versionstatement 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?
And it also might affects users directly, without proper dependencies e.g. a bookworm -> trixie upgrade might end up with the following order (among many other things happening during the upgrade): 1. zlib gets upgraded 2. the tex-common trigger runs 3. texlive-bin gets upgraded If this is permitted by the dependencies, then step 2 must not fail.
I'd rather expect that the triggers run at the end of the setup process, i.e. after all packages replaced their files. At least this was the original ideal behind them IIRC.
Hilmar -- Testmail
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature