On Wed, 16 Nov 2022 21:56:31 +0200, Niko Tyni wrote: > 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.
Hu?
We have in d/rules:
override_dh_auto_test:
TEST_SKIP_VERSION_CHECK=1 dh_auto_test
and that should be honoured in t/compress/CompTestUtils.pm.
But then, I also don't see this in
https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libcompress-raw-zlib-perl/28323429/log.gz
But
t/01version.t ......
1..9
ok 1 - use Compress::Raw::Zlib;
ok 2 # skip TEST_SKIP_VERSION_CHECK is set
Is there a different log I'm missing?
But anyway, I guess this is the real problem:
> 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.
Thanks for this analysis.
Some quick thoughts:
- we could play with zlib_version vs. ZLIB_VERSION (1.2.13 vs.
1.2.11, according to t/000prereq.t) in t/02zlib.t
- we could skip these two tests with TEST_SKIP_VERSION_CHECK
- we could just do a binNMU
> 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.
*nod*
> 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.
Assuming this is not a recurring pattern, a one-time binNMU might be
not so bad …
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
signature.asc
Description: Digital Signature
