Bug 104355 – gzip-x86 zgrep inconsistency as compared to app-arch/gzip

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description David Sparks 2005-08-31 01:46:50 UTC]

base system already has app-arch/gzip installed


scanner1 ~ # cat > test
abcd 123 abcd

scanner1 ~ # /bin/zgrep -h 123 /root/test
abcd 123 abcd

emerge gzip-x86 ...

scanner1 ~ # /bin/zgrep -h 123 /root/test
Binary file (standard input) matches


As you can see above, the zgrep that comes with gzip-x86 does not find the
string in the file but returns "Binary file (standard input) matches" which is
not expected.

Reproducible: Always
Steps to Reproduce:
1. emerge gzip-x86
2. gzip-x86 does not perform identically to gzip


Actual Results:  
Problem found when 2 similar machine gave different results.  One machine was
using gzip-x86.


Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130,
glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r8 i686)
=================================================================
System uname: 2.6.11-gentoo-r8 i686 Intel(R) Xeon(TM) CPU 3.20GHz
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.5 [2.3.5 (#1, May 17 2005, 15:29:31)]
distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
ccache version 2.3 [enabled]
dev-lang/python:     2.3.5
sys-apps/sandbox:    [Not Present]
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.8.5-r3, 1.7.9-r1, 1.9.5, 1.6.3, 1.4_p6, 1.5
sys-devel/binutils:  2.15.92.0.2-r7
sys-devel/libtool:   1.5.16
virtual/os-headers:  2.6.8.1-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig buildpkg ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://portage.mirror.com/tsp-cache/gentoo.oregonstate.edu"
MAKEOPTS="-j6"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://portage.mirror.com/gentoo-portage"
USE="x86 alsa berkdb crypt eds emboss gd gstreamer guile innodb jpeg libg++
libwww lm_sensors milter mp3 mysql ncurses nptl nptlonly ogg perl png python
readline rrdtool snmp spell sse sse2 ssl truetype truetype-fonts type1-fonts
vorbis xml2 zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS

[Comment 1 Jakub Moc (RETIRED) 2005-08-31 03:14:34 UTC]

File a bug upstream, Gentoo does not apply any patches to gzip-x86 so it's not a
Gentoo problem.

[Comment 2 David Sparks 2005-08-31 12:12:10 UTC]

I already filed a bug with the upstream maintainer, however the gzip-x86 hasn't
been updated since 2002.

Perhaps this package should be removed from portage if it isn't being maintained
upstream?

[Comment 3 Jakub Moc (RETIRED) 2005-08-31 14:24:00 UTC]

(In reply to comment #2)
> Perhaps this package should be removed from portage if it isn't being maintained
> upstream?

Good idea... 

[Comment 4 Ian Leitch (RETIRED) 2005-09-01 16:37:47 UTC]

Segmentation Faults all over for me. Any news from upstream?

[Comment 5 James Rowe 2005-09-17 00:37:27 UTC]

  The case for removal is probably a very good one, as this package is also
missing security fixes/updates.  0.91 is just a "hacked" gzip-1.3.3 source tree
and as such is vunerable to at least glsa-200406-18 glsa-200505-05, and any
other fixes which have happened in the actual gzip tree since 1.3.3 was 
released.

[Comment 6 Mark Loeser (RETIRED) 2005-09-20 06:41:53 UTC]

I've package.mask'd this package because of the exploits and not being
maintained upstream.  If no one wants to maintain the package and fixes it up
within the next 30 days, its getting the boot.  I'm keeping this bug around as a
reminder to myself and will close it after I remove it from the tree.

[Comment 7 Mark Loeser (RETIRED) 2005-10-21 14:37:04 UTC]

Removed from the tree.