Re: armhf version of bzip2 is broken

[Reco <recoverym4n@enotuniq.net>]

	Hi.

On Mon, Nov 11, 2019 at 01:24:50PM -0500, Gene Heskett wrote:
> On Monday 11 November 2019 12:34:08 Greg Wooledge wrote:
> 
> > On Mon, Nov 11, 2019 at 12:08:15PM -0500, Gene Heskett wrote:
> > > And its man page says its a 2010 version. And it won't touch a just
> > > over 4G built kernel tarball.
> > >
> > > Suggestions?
> >
> > 0) Give all the background details of your setup, like what version of
> >    Debian you're running, what hardware, what version of bzip2 is
> >    installed, where you got this input file....
> Not debian since your arm is now arm64 from buster on.

Your inability to locate armhf in Debian's main archive is well-known to
debian-arm denizens, but please refrain from spreading your hopefully
honest errors here.


> The problem is that a built kernel is 4038000640 byte when converted to a 
> tarball, but the best compressor is a 2010 version of bzip2 and it has 
> an instant tummy ache with that big a file:
> 
> pi@rpi4:/media/pi/slash $ bzip2 -z 4.19.71-rt24-v7l+.tar
> bzip2: Can't open input file 4.19.71-rt24-v7l+.tar: Value too large for 
> defined data type.

Confirming, real debian armhf is affected. The problematic place is:

$ strace -eopenat bzip2 -z 4038000640
...
openat(AT_FDCWD, "4038000640", O_RDONLY) = -1 EOVERFLOW (Value too large for defined data type)


And EOVERFLOW in openat(2) is:

pathname refers to a regular file that is too large to be opened.  The
usual scenario here is that an application compiled on a 32-bit platform
without -D_FILE_OFFSET_BITS=64 tried to open  a  file  whose  size
exceeds (1<<31)-1 bytes; see also O_LARGEFILE above.  This is the
error specified by POSIX.1; in kernels before 2.6.24, Linux gave the
error EFBIG for this case.


So, yep, you've found a bug in Debian packaging, consider filling it via
proper channels.


EOVERFLOW is a known beast, working workarounds are:

1) "busybox bzip2" instead of "bzip2 -z" (-z is kind of redundant anyway).

2) cat foo | bzip2 -c > foo.bz2


> The realtime is totally moot IMO,

True, one has to build a binary a certain way.

> the size of slightly over 4Gigs is the real problem

First, it's *under* 4Gb (assuming right and proper 1024=1Kb):

$ echo 4038000640/1024/1024/1024 | bc -l
3.76068115234375

Second, it's actually 2Gb-1 that's problematic.

Reco