Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On 20.11.2023 11:34, Adrian Bunk wrote: Hi all, Right now the autopkgtests block zlib migration to testing since they test zlib/unstable with texlive-binaries/testing - this is permitted by the dependencies. And this is not just a test issue: Anybody has opened #1056312, I add my statement how to address this issue. So, I guess time to close this bug here. Thanks to all, who contributed! Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On Mon, Nov 20, 2023 at 10:59:02AM +0100, =?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org wrote: >... > Not sure, if we need an updated breaks statement. >... Right now the autopkgtests block zlib migration to testing since they test zlib/unstable with texlive-binaries/testing - this is permitted by the dependencies. And this is not just a test issue: On Sun, Nov 19, 2023 at 01:54:02PM +0100, Hilmar Preuße wrote: > On 11/19/23 00:40, Adrian Bunk wrote: >... > > 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. The idea is to avoid unnecessary duplicate commands, but more than once might be required. And when upgrading to a new stable there are several cycles where triggers run at the end (you might not notice since the package manager takes care of it). On a bookworm -> trixie upgrade the man-db trigger might run 5 or 10 times instead of 1000 packages each executing the command, but it will definitely run more than once. If one of the dependencies of texlive-binaries Pre-Depends on zlib1g, this might be sufficient to ensure that all pending triggers are running after the upgrade of zlib1g and before the upgrade ot texlive-binaries. > Hilmar cu Adrian
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On 20.11.2023 01:13, Adrian Bunk wrote: Hi, I just noticed that we had this issue already 13 years ago. [2] And from then zlib1g still has the Breaks: texlive-binaries (<< 2009-12) that will also require updating again. No, that's younger: zlib (1:1.2.6.dfsg-2) unstable; urgency=low * Break texlive-binaries before 2009-12 due to gzeof() behaviour change (closes: #659681). -- Mark Brown Thu, 23 Feb 2012 23:28:27 + Not sure, if we need an updated breaks statement. Anyway, I'll ping Tiago again, if the test can be removed at all- Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On Mon, Nov 20, 2023 at 12:05:46AM +0100, Hilmar Preuße wrote: > On 11/19/23 00:40, Adrian Bunk wrote: > > Hi Adrian, Hi Hilmar, > > A proper fix would be either to: > > 1. patch the version check out of texlive-bin (preferred), or > > > Did so, see [1]. I did not remove the check completely, I just un-tightened > the version. I can confirm that a texlive package linked on testing (zlib > 1.2.x) is installable on unstable (zlib 1.3.x). I hope this solves the issue > for the next 20 years. I intend to upload new packages tomorrow, this NMU > bug can be closed, once this has been done. > > I just noticed that we had this issue already 13 years ago. [2] And from then zlib1g still has the Breaks: texlive-binaries (<< 2009-12) that will also require updating again. Is there any reason why the check exists at all? If the only effect is breakage every 10-20 years, then it's wrong to keep it. This check would make sense if zlib would make buggy changes where the ABI changes without chaning the library soname, but that is not supposed to happen and if it would happen with a library as widely used as zlib then so much would break in unstable that the revert would be instant. > Hilmar >... cu Adrian
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On 11/19/23 00:40, Adrian Bunk wrote: Hi Adrian, A proper fix would be either to: 1. patch the version check out of texlive-bin (preferred), or Did so, see [1]. I did not remove the check completely, I just un-tightened the version. I can confirm that a texlive package linked on testing (zlib 1.2.x) is installable on unstable (zlib 1.3.x). I hope this solves the issue for the next 20 years. I intend to upload new packages tomorrow, this NMU bug can be closed, once this has been done. I just noticed that we had this issue already 13 years ago. [2] Hilmar [1] https://github.com/debian-tex/texlive-bin/blob/master/debian/patches/untighten_version_check_zlib.diff [2] https://lists.debian.org/debian-tex-maint/2010/06/msg00071.html -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On Sun, Nov 19, 2023 at 01:54:02PM +0100, Hilmar Preuße wrote: >... > 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". ;-) >... It is. https://www.lua.org/manual/5.3/manual.html#lua_error int lua_error (lua_State *L); Generates a Lua error, using the value at the top of the stack as the error object. This function does a long jump, and therefore never returns (see luaL_error). The SIGABRT is generated by calling abort(): https://sources.debian.org/src/lua5.3/5.3.6-2/src/lapi.c/#L1117 https://sources.debian.org/src/lua5.3/5.3.6-2/src/ldebug.c/#L649 https://sources.debian.org/src/lua5.3/5.3.6-2/src/ldo.c/#L130 > Hilmar cu Adrian
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
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
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. 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? 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 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On Sat, Nov 18, 2023 at 11:51:15PM +0100, Hilmar Preuße wrote: > Control: severity -1 important > Control: block 1056183 by -1 > > On 11/18/23 20:18, Samuel Thibault wrote: > > Hi Samuel, > > > > > 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 2. ensure texlive-bin has package dependencies that match this runtime check After a binNMU the migration of zlib to testing would still be blocked forever by the autopkgtest of packages like asymptote that will continue to test with zlib/unstable and texlive-bin/testing. 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. > Hilmar cu Adrian
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
Control: severity -1 important Control: block 1056183 by -1 On 11/18/23 20:18, Samuel Thibault wrote: Hi Samuel, 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. Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
Samuel Thibault, le sam. 18 nov. 2023 20:18:01 +0100, a ecrit:
> nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild against
> new zlib"
I forgot to mention that this should of course be made dep-wait
zlib1g-dev (>= 1:1.3.dfsg-1)
> Hello,
>
> Since the upload of zlib1g 1:1.3.dfsg-1, installing texlive-binaries
> texlive-base fails:
>
> fmtutil failed. Output has been stored in
> /tmp/fmtutil.ndDMEWN5
>
> [...]
>
> fmtutil: running `luatex -ini -jobname=luatex -progname=luatex luatex.ini'
> ...
> PANIC: unprotected error in call to Lua API (zlib library version does not
> match - header: 1.2.13, library: 1.3)
> Aborted
>
> And indeed texlive-bin checks the zlib version:
>
> https://codesearch.debian.net/search?q=zlib+library+version+does+not+match=en
>
> texlive-bin_2023.20230311.66589-7/texk/web2c/luatexdir/luazlib/lzlib.c
>
> if (strncmp(version, ZLIB_VERSION, 4))
> {
> lua_pushfstring(L, "zlib library version does not match - header: %s,
> library: %s", ZLIB_VERSION, version);
> lua_error(L);
> }
>
> So a binnmu of the texlive-bin source package seems needed on all archs
> to fix installing texlive-binaries.
>
> Samuel
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: texlive-...@packages.debian.org
Control: affects -1 + src:texlive-bin
nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild against
new zlib"
Hello,
Since the upload of zlib1g 1:1.3.dfsg-1, installing texlive-binaries
texlive-base fails:
fmtutil failed. Output has been stored in
/tmp/fmtutil.ndDMEWN5
[...]
fmtutil: running `luatex -ini -jobname=luatex -progname=luatex luatex.ini' ...
PANIC: unprotected error in call to Lua API (zlib library version does not
match - header: 1.2.13, library: 1.3)
Aborted
And indeed texlive-bin checks the zlib version:
https://codesearch.debian.net/search?q=zlib+library+version+does+not+match=en
texlive-bin_2023.20230311.66589-7/texk/web2c/luatexdir/luazlib/lzlib.c
if (strncmp(version, ZLIB_VERSION, 4))
{
lua_pushfstring(L, "zlib library version does not match - header: %s,
library: %s", ZLIB_VERSION, version);
lua_error(L);
}
So a binnmu of the texlive-bin source package seems needed on all archs
to fix installing texlive-binaries.
Samuel
