Control: reassign -1 libcompress-raw-zlib-perl 2.202-1 On Tue, Nov 15, 2022 at 09:56:57PM +0100, Paul Gevers wrote: > Source: zlib, libcompress-raw-zlib-perl > Control: found -1 zlib/1:1.2.13.dfsg-1 > Control: found -1 libcompress-raw-zlib-perl/2.202-1 > Severity: serious > Tags: sid bookworm > User: debian...@lists.debian.org > Usertags: breaks needs-update
Thanks for the report. > # Failed test (t/02zlib.t at line 532) > # got: 1 > # expected: -3 It looks like this is a (possibly test-only) problem in libcompress-raw-zlib-perl. >From the log: not ok 2 - ZLIB_VERSION (1.2.11) matches Compress::Raw::Zlib::zlib_version # Failed test (t/compress/CompTestUtils.pm at line 61) # got: '1.2.11' # expected: '1.2.13' # # The version of zlib.h does not match the version of libz # # You have zlib.h version 1.2.11 # and libz version 1.2.13 # # You probably have two versions of zlib installed on your system. # Try removing the one you don't want to use and rebuild. This is failing just because the runtime zlib version is not the same that the package was built with. not ok 126 # Failed test (t/02zlib.t at line 498) # got: 1 # expected: -3 [...] not ok 134 # Failed test (t/02zlib.t at line 532) # got: 1 # expected: -3 These two trip on the same thing: apparently there's been a behaviour change in zlib 1.2.12. The test file has been adjusted for the change and has this comment: # Z_STREAM_END returned by 1.12.2, Z_DATA_ERROR for older zlib but it's choosing the expected behaviour based on the build time zlib version rather than the runtime one. Not sure how to fix these issues best. Ideally the package would not bake the build time zlib version in the binary, but it's probably part of the interface now . The documentation says all the zlib constants are automatically imported and I suppose that includes ZLIB_VERSION. I doubt the version skew causes any real problems but we can't really be sure about that. Applications could be choosing their behaviour based on ZLIB_VERSION. So just disarming the failing tests during autopkgtest and allowing version skew runs seems a bit risky. The obvious alternative is to play it safe and add tight versioned dependencies on the zlib1g package, requiring rebuilds whenever there's a new zlib upstream version. That seems overkill to me. Note that if we do introduce the tight dependencies, src:perl has a separate copy of Compress-Raw-Zlib which should probably get the same treatment. -- Niko Tyni nt...@debian.org