"pear package" fails on Debian-testing --- being resolved

Hi PEARs, quite some while ago Vincent and I investigated in a problem with still exists on current Debian-testing when you try to "pear package". If you use --nocompress everything works fine. The bug only occured in Debian-testing, as far as I can tell. At first we expected it to be an Archive_Tar-bug, but it turned out to be in php/gzip. Find attached an email I just received. The Debian-guys were able to isolate the bug and are working on it. The problem seems to be more difficult than we expected, since it wasn't a php-problem but a problem of that special version of zlib. Depending on the compiler- settings of zlib the bug occured or not. Just to let you know - maybe somebody else has problems doing a "pear package" or similar on Debian ... Regards, Stefan ------- Forwarded message follows ------- Date sent: Sun, 22 Feb 2004 12:30:19 -0600 From: Steve Langasek <vorlon@debian.org> To: Stefan Neufeind <stefan@neufeind.net>, 208608@bugs.debian.org Copies to: zlib@packages.debian.org Subject: Re: Bug#208608: php4-cgi fails in zlib-extension clone 208608 -1 retitle -1 zlib1g breaks when used from apps build with -D_FILE_OFFSET_BITS=64 reassign -1 zlib1g thanks Hi Stefan, On Thu, Sep 04, 2003 at 09:18:17AM +0200, Stefan Neufeind wrote: > Please be sure that you: > 1) are running the latest php4-cgi as available for testing / > unstable > 2) did a "pear upgrade-all" to update all pear-packages to the > latest (even this doesn't have to do anything with the > pear-packages). > Go to a dir and extract the attached archive. Enter the directory > created - there you find the package.xml-file. Now do a simple "pear > package" and the commandline ... and see it hang. > The "hang" occurs in the pear-class "Archive_Tar". But we tracked > down the problem (programmer of Archive_Tar and me) and he told me > that it hasn't got to do a thing with Archive_Tar but that the > gzwrite-function has some error. > I also attached the Archive_Tar-programmers testfiles - and here are > his findings: > "The problems seems to comes from the gzwrite() function. I first > modify the Tar.php file to put into comments line 1447 (writeblock) > and it seems to work (at least finish correctly the loop). So I > tried a little script (test.php in coding/pear/Net_traceroute) which > is a copy of this Tar.php code. When removing gzwrite() everything > works if using gzwrite() it hangs after 20 written blocks. Then I > tried test2.php to see if this is the nested gzread-open > gzwrite-open files, but it hangs also. Then I tried in test3.php to > write 100 times "Hello world" in a gz archive with gzwrite and it > hangs also." I have been able to isolate this bug. It appears that the zlib headers interact poorly with LFS support: zconf.h defines z_off_t as off_t, which will be a different size on 32-bit platforms depending on whether or not the source is being compiled with -D_FILE_OFFSET_BITS=64. Disabling LFS support for all of PHP would be a step backwards; I'm going to see if I can sensibly disable LFS support *only* for the zlib extension. The zlib package should also be fixed in one of two ways: - fix the headers so that the declared size of z_off_t is set at the time the library is built, not dependent on the size of off_t at the time the headers are used from other programs - equip zlib1g with two sets of the routines in question -- one with the existing names, and one with names like gzseek64(), gzwrite64(), etc -- and autodetect the correct libs to use based on the application compile environment (-D_FILE_OFSET_BITS=64 and - D_LARGEFILE64_SOURCE in CFLAGS). Cheers, -- Steve Langasek postmodern programmer ------- End of forwarded message -------