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