Bug#893472: libfurl-perl: broken on s390x?
On Tue, Mar 20, 2018 at 10:02:34AM +0100, Jonas Smedegaard wrote: > I believe circular build-dependencies for testsuite needs can - and > should be addressed by marking such build-dependencies appropriately, > rather than skipping them - for exactly situations like this. Sure. > Question then what the appropriate way to express cycle-breaking > hints... :-) I believe the way to express this is to annotate the build dependency with . (Though build cycles are probably not much of a deal with arch:all packages in the first place.) -- Niko
Bug#893472: libfurl-perl: broken on s390x?
Control: retitle -1 libplack-middleware-deflater-perl: broken on big endian
hosts
Control: reassign -1 libplack-middleware-deflater-perl 0.12-1
Control: tag -1 patch
Control: affects -1 libfurl-perl
On Mon, Mar 19, 2018 at 09:35:03PM +0200, Niko Tyni wrote:
> I got as far as seeing that removing line 144 in Deflater.pm
>
>
> https://sources.debian.org/src/libplack-middleware-deflater-perl/0.12-1/lib/Plack/Middleware/Deflater.pm/#L144
>
> - $buf .= pack("LL", $self->{crc},$self->{length}) if $self->{encoding}
> eq 'gzip';
>
> makes both test suites pass, but that doesn't seem like a fully
> satisfactory patch. (And no, s/LL/NN/ doesn't fix it.)
Hum, this is somewhat embarrassing. s/LL/VV/ does seem to fix it, which
makes sense as L and N are equivalent on big-endian while L and V are
equivalent on little-endian. I blame lack of sleep.
Also, RFC 1952 says
All multi-byte numbers in the format described here are stored
with the least-significant byte first (at the lower memory address).
so little endian seems to be correct.
Lightly tested patch attached; reassigning.
--
Niko
>From 480e68c781ddad1e5a19446c13134c8fde2a34e8 Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Tue, 20 Mar 2018 21:51:49 +0200
Subject: [PATCH] Fix gzip trailer on big endian hosts
These values need to be stored as little endian regardless
of the host endianness.
Bug-Debian: https://bugs.debian.org/893472
---
lib/Plack/Middleware/Deflater.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/Plack/Middleware/Deflater.pm b/lib/Plack/Middleware/Deflater.pm
index 4cb0b03..c823c38 100644
--- a/lib/Plack/Middleware/Deflater.pm
+++ b/lib/Plack/Middleware/Deflater.pm
@@ -141,7 +141,7 @@ sub print : method {
if ( !$self->{header} && $self->{encoding} eq 'gzip' ) {
$buf = pack("nccVcc",GZIP_MAGIC,Z_DEFLATED,0,time(),0,$Compress::Raw::Zlib::gzip_os_code) . $buf
}
-$buf .= pack("LL", $self->{crc},$self->{length}) if $self->{encoding} eq 'gzip';
+$buf .= pack("VV", $self->{crc},$self->{length}) if $self->{encoding} eq 'gzip';
$self->{closed} = 1;
return $buf;
}
--
2.16.2
Bug#893472: libfurl-perl: broken on s390x?
Quoting Niko Tyni (2018-03-19 20:35:03) > On Mon, Mar 19, 2018 at 01:03:12AM -0700, Steve Langasek wrote: > > Source: libfurl-perl > > Version: 3.13-1 > > Severity: grave > > User: ubuntu-de...@lists.ubuntu.com > > Usertags: origin-ubuntu bionic autopkgtest > > > t/100_low/13_deflate.t .. > > # normal 1 gzip > > Uncompress error: data error at /usr/share/perl5/Furl/HTTP.pm line 845. > > > From what I'm able to tell, this test failure points to the library > > actually being broken on s390x, as it fails to decompress data sent > > back by the test server which is implemented using > > libplack-middleware-deflater-perl. But it's also possible that it's > > libplack-middleware-deflater-perl which is broken on s390x, in which > > case this bug should be certainly reassigned. > > Thanks for the report. Testing on zelenka.d.o, I see the same behaviour. Thanks to both of you for the investigations. > I suspect the real culprit is libplack-middleware-deflater-perl; it > uses pack() in suspicious ways that might break on big vs. little > endian. Its own t/furl.t is failing similarly, but gets skipped on > Debian build+autopkgtest because libfurl-perl is not a build > dependency of libplack-middleware-deflater-perl (possibly due to build > cycle reasons.) I believe circular build-dependencies for testsuite needs can - and should be addressed by marking such build-dependencies appropriately, rather than skipping them - for exactly situations like this. Question then what the appropriate way to express cycle-breaking hints... :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#893472: libfurl-perl: broken on s390x?
On Mon, Mar 19, 2018 at 01:03:12AM -0700, Steve Langasek wrote:
> Source: libfurl-perl
> Version: 3.13-1
> Severity: grave
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu bionic autopkgtest
> t/100_low/13_deflate.t ..
> # normal 1 gzip
> Uncompress error: data error at /usr/share/perl5/Furl/HTTP.pm line 845.
> From what I'm able to tell, this test failure points to the library actually
> being broken on s390x, as it fails to decompress data sent back by the
> test server which is implemented using libplack-middleware-deflater-perl.
> But it's also possible that it's libplack-middleware-deflater-perl which is
> broken on s390x, in which case this bug should be certainly reassigned.
Thanks for the report. Testing on zelenka.d.o, I see the same behaviour.
I suspect the real culprit is libplack-middleware-deflater-perl; it uses
pack() in suspicious ways that might break on big vs. little endian.
Its own t/furl.t is failing similarly, but gets skipped on Debian
build+autopkgtest because libfurl-perl is not a build dependency of
libplack-middleware-deflater-perl (possibly due to build cycle reasons.)
I got as far as seeing that removing line 144 in Deflater.pm
https://sources.debian.org/src/libplack-middleware-deflater-perl/0.12-1/lib/Plack/Middleware/Deflater.pm/#L144
- $buf .= pack("LL", $self->{crc},$self->{length}) if $self->{encoding}
eq 'gzip';
makes both test suites pass, but that doesn't seem like a fully
satisfactory patch. (And no, s/LL/NN/ doesn't fix it.)
There's some probably related upstream discussion in
https://github.com/miyagawa/Plack-Middleware-Deflater/issues/11
https://github.com/miyagawa/Plack-Middleware-Deflater/commit/02db7d339af94c9013a81f17189fccf082cfe3a9
No tuits to actually dig into gzip streams at least tonight...
--
Niko Tyni nt...@debian.org
Bug#893472: libfurl-perl: broken on s390x?
Source: libfurl-perl Version: 3.13-1 Severity: grave User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu bionic autopkgtest Dear Jonas, In Ubuntu, the most recent upload of libfurl-perl has been blocked from inclusion in the upcoming bionic release by a failing autopkgtest on s390x: [...] t/100_low/13_deflate.t .. # normal 1 gzip Uncompress error: data error at /usr/share/perl5/Furl/HTTP.pm line 845. ok 1 # Tests were run but no plan was declared and done_testing() was not seen. # Looks like your test exited with 255 just after 1. Dubious, test returned 255 (wstat 65280, 0xff00) [...] Test Summary Report --- t/100_low/13_deflate.t(Wstat: 65280 Tests: 1 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output Files=51, Tests=734, 60 wallclock secs ( 0.09 usr 0.02 sys + 4.58 cusr 0.58 csys = 5.27 CPU) Result: FAIL autopkgtest [03:19:59]: test command1: ---] [...] http://autopkgtest.ubuntu.com/packages/libf/libfurl-perl/bionic/s390x From what I'm able to tell, this test failure points to the library actually being broken on s390x, as it fails to decompress data sent back by the test server which is implemented using libplack-middleware-deflater-perl. But it's also possible that it's libplack-middleware-deflater-perl which is broken on s390x, in which case this bug should be certainly reassigned. I have also established that this same test fails when run against the previous version of libfurl-perl, so this should not be considered a regression in libfurl-perl. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
