Bug#893472: libfurl-perl: broken on s390x?

[Niko Tyni]

On Mon, Mar 19, 2018 at 01:03:12AM -0700, Steve Langasek wrote:
> Source: libfurl-perl
> Version: 3.13-1
> Severity: grave
> User: ubuntu-devel at 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   ntyni at debian.org