Bug#1024179: zlib breaks libcompress-raw-zlib-perl autopkgtest: 02zlib.t fails
On Thu, 17 Nov 2022 19:10:49 +, 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'
> > Hu?
> Uh, I was debugging this manually with 'perl t/02zlib.t'
> and must have mixed up the logs. Sorry!
No worries, I guessed later that you might have done some manual
debugging.
> > 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
> Yeah I guess that's the way to go if we want to allow the version skew.
> I think I have a slight preference for this over the rebuild solution.
Alright.
So something like this?
#v+
--- a/t/02zlib.t.orig 2022-11-17 19:42:16.512726239 +
+++ b/t/02zlib.t2022-11-17 19:45:06.421757489 +
@@ -12,7 +12,7 @@
use Test::More ;
-use constant ZLIB_1_2_12_0 => 0x12C0;
+use constant ZLIB_1_2_12_0 => '1.2.12';
BEGIN
{
@@ -489,7 +489,7 @@
# Z_STREAM_END returned by 1.12.2, Z_DATA_ERROR for older zlib
# ZLIB_NG has the fix for all versions
-if (ZLIB_VERNUM >= ZLIB_1_2_12_0 || Compress::Raw::Zlib::is_zlibng)
+if ($Zlib_ver gt ZLIB_1_2_12_0 || Compress::Raw::Zlib::is_zlibng)
{
cmp_ok $status, '==', Z_STREAM_END ;
}
@@ -523,7 +523,7 @@
$GOT = '';
$status = $k->inflate($rest, $GOT);
# Z_STREAM_END returned by 1.12.2, Z_DATA_ERROR for older zlib
-if (ZLIB_VERNUM >= ZLIB_1_2_12_0 || Compress::Raw::Zlib::is_zlibng)
+if ($Zlib_ver gt ZLIB_1_2_12_0 || Compress::Raw::Zlib::is_zlibng)
{
cmp_ok $status, '==', Z_STREAM_END ;
}
#v-
$Zlib_ver comes from line 44:
my $Zlib_ver = Compress::Raw::Zlib::zlib_version ;
And I'm never sure if 'gt' is a good idea for comparing versions or I
should wrap my head around version->parse().
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
Bug#1024179: zlib breaks libcompress-raw-zlib-perl autopkgtest: 02zlib.t fails
On Wed, Nov 16, 2022 at 10:44:33PM +0100, gregor herrmann wrote: > 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? Uh, I was debugging this manually with 'perl t/02zlib.t' and must have mixed up the logs. Sorry! > 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 Yeah I guess that's the way to go if we want to allow the version skew. I think I have a slight preference for this over the rebuild solution. > Assuming this is not a recurring pattern, a one-time binNMU might be > not so bad … If this is for safety rather than just fixing the failing test, we'd want to do that for src:perl as well. -- Niko
Bug#1024179: zlib breaks libcompress-raw-zlib-perl autopkgtest: 02zlib.t fails
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
Processed: Re: Bug#1024179: zlib breaks libcompress-raw-zlib-perl autopkgtest: 02zlib.t fails
Processing control commands: > reassign -1 libcompress-raw-zlib-perl 2.202-1 Bug #1024179 [src:zlib, src:libcompress-raw-zlib-perl] zlib breaks libcompress-raw-zlib-perl autopkgtest: 02zlib.t fails Bug reassigned from package 'src:zlib, src:libcompress-raw-zlib-perl' to 'libcompress-raw-zlib-perl'. No longer marked as found in versions zlib/1:1.2.13.dfsg-1 and libcompress-raw-zlib-perl/2.202-1. Ignoring request to alter fixed versions of bug #1024179 to the same values previously set Bug #1024179 [libcompress-raw-zlib-perl] zlib breaks libcompress-raw-zlib-perl autopkgtest: 02zlib.t fails Marked as found in versions libcompress-raw-zlib-perl/2.202-1. -- 1024179: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024179 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1024179: zlib breaks libcompress-raw-zlib-perl autopkgtest: 02zlib.t fails
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
Bug#1024179: zlib breaks libcompress-raw-zlib-perl autopkgtest: 02zlib.t fails
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 Dear maintainer(s), With a recent upload of zlib the autopkgtest of libcompress-raw-zlib-perl fails in testing when that autopkgtest is run with the binary packages of zlib from unstable. It passes when run with only packages from testing. In tabular form: passfail zlib from testing1:1.2.13.dfsg-1 libcompress-raw-zlib-perl from testing2.202-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of zlib to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=zlib https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libcompress-raw-zlib-perl/28323429/log.gz t/02zlib.t . 1..353 [...] not ok 126 # Failed test (t/02zlib.t at line 498) # got: 1 # expected: -3 ok 127 ok 128 ok 129 ok 130 ok 131 ok 132 ok 133 - expected compressed output not ok 134 # Failed test (t/02zlib.t at line 532) # got: 1 # expected: -3 OpenPGP_signature Description: OpenPGP digital signature
