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]