PR/53826 CVS commit: pkgsrc/archivers/gzip

["David H. Gutteridge" <gutteridge%netbsd.org@localhost>]

The following reply was made to PR pkg/53826; it has been noted by GNATS.

From: "David H. Gutteridge" <gutteridge%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/53826 CVS commit: pkgsrc/archivers/gzip
Date: Thu, 10 Jan 2019 06:47:42 +0000

 Module Name:	pkgsrc
 Committed By:	gutteridge
 Date:		Thu Jan 10 06:47:42 UTC 2019
 
 Modified Files:
 	pkgsrc/archivers/gzip: Makefile distinfo
 	pkgsrc/archivers/gzip/patches: patch-lib_fflush.c
 Removed Files:
 	pkgsrc/archivers/gzip/patches: patch-lib_fseeko.c
 
 Log Message:
 archivers/gzip: update to release 1.10
 
 Prompted in part because prior releases fail to build on Linux
 distributions that use glibc >= 2.27 (relates to PR pkg/53826).
 
 * Noteworthy changes in release 1.10 (2018-12-29) [stable]
 
 ** Changes in behavior
 
   Compressed gzip output no longer contains the current time as a
   timestamp when the input is not a regular file.  Instead, the output
   contains a null (zero) timestamp.  This makes gzip's behavior more
   reproducible when used as part of a pipeline.  (As a reminder, even
   regular files will use null timestamps after the year 2106, due to a
   limitation in the gzip format.)
 
 ** Bug fixes
 
   A use of uninitialized memory on some malformed inputs has been fixed.
   [bug present since the beginning]
 
   A few theoretical race conditions in signal handers have been fixed.
   These bugs most likely do not happen on practical platforms.
   [bugs present since the beginning]
 
 * Noteworthy changes in release 1.9 (2018-01-07) [stable]
 
 ** Bug fixes
 
   gzip -d -S SUFFIX file.SUFFIX would fail for any upper-case byte in SUFFIX.
   E.g., before, this command would fail:
     $ :|gzip > kT && gzip -d -S T kT
     gzip: kT: unknown suffix -- ignored
   [bug present since the beginning]
 
   When decompressing data in 'pack' format, gzip no longer mishandles
   leading zeros in the end-of-block code.  [bug introduced in gzip-1.6]
 
   When converting from system-dependent time_t format to the 32-bit
   unsigned MTIME format used in gzip files, if a timestamp does not
   fit gzip now substitutes zero instead of the timestamp's low-order
   32 bits, as per Internet RFC 1952.  When converting from MTIME to
   time_t format, if a timestamp does not fit gzip now warns and
   substitutes the nearest in-range value instead of crashing or
   silently substituting an implementation-defined value (typically,
   the timestamp's low-order bits).  This affects timestamps before
   1970 and after 2106, and timestamps after 2038 on platforms with
   32-bit signed time_t.  [bug present since the beginning]
 
   Commands implemented via shell scripts are now more consistent about
   failure status.  For example, 'gunzip --help >/dev/full' now
   consistently exits with status 1 (error), instead of with status 2
   (warning) on some platforms.  [bug present since the beginning]
 
   Support for VMS and Amiga has been removed.  It was not working anyway,
   and it reportedly caused file name glitches on MS-Windowsish platforms.
 
 * Noteworthy changes in release 1.8 (2016-04-26) [stable]
 
 ** Bug fixes
 
   gzip -l no longer falsely reports a write error when writing to a pipe.
   [bug introduced in gzip-1.7]
 
   Port to Oracle Solaris Studio 12 on x86-64.
   [bug present since at least gzip-1.2.4]
 
   When configuring gzip, ./configure DEFS='...-DNO_ASM...' now
   suppresses assembler again.  [bug introduced in gzip-1.3.5]
 
 * Noteworthy changes in release 1.7 (2016-03-27) [stable]
 
 ** Changes in behavior
 
   The GZIP environment variable is now obsolescent; gzip now warns if
   it is used, and rejects attempts to use dangerous options or operands.
   You can use an alias or script instead.
 
   Installed programs like 'zgrep' now use the PATH environment variable
   as usual to find subsidiary programs like 'gzip' and 'grep'.
   Previously they prepended the installation directory to the PATH,
   which sometimes caused 'make check' to test the wrong gzip executable.
   [bug introduced in gzip-1.3.13]
 
 ** New features
 
   gzip now accepts the --synchronous option, which causes it to use
   fsync and similar primitives to transfer output data to the output
   file's storage device when the file system supports this.  Although
   this option makes gzip safer in the presence of system crashes, it
   can make gzip considerably slower.
 
   gzip now accepts the --rsyncable option. This option is accepted in
   all modes, but has effect only when compressing: it makes the resulting
   output more amenable to efficient use of rsync.  For example, when a
   large input file gets a small change, a gzip --rsyncable image of
   that file will remain largely unchanged, too.  Without --rsyncable,
   even a tiny change in the input could result in a totally different
   gzip-compressed output file.
 
 ** Bug fixes
 
   gzip -k -v no longer reports that files are replaced.
   [bug present since the beginning]
 
   zgrep -f A B C no longer reads A more than once if A is not a regular file.
   This better supports invocations like 'zgrep -f <(COMMAND) B C' in Bash.
   [bug introduced in gzip-1.2]
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.35 -r1.36 pkgsrc/archivers/gzip/Makefile
 cvs rdiff -u -r1.9 -r1.10 pkgsrc/archivers/gzip/distinfo
 cvs rdiff -u -r1.2 -r1.3 pkgsrc/archivers/gzip/patches/patch-lib_fflush.c
 cvs rdiff -u -r1.2 -r0 pkgsrc/archivers/gzip/patches/patch-lib_fseeko.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.