emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30029: closed (gzip-1.9 released [stable])


From: GNU bug Tracking System
Subject: bug#30029: closed (gzip-1.9 released [stable])
Date: Thu, 31 Mar 2022 23:54:01 +0000

Your message dated Thu, 31 Mar 2022 16:53:30 -0700
with message-id <70da0fd3-1c9e-e9f1-00df-86996c20e95e@cs.ucla.edu>
and subject line Re: gzip-1.9 released [stable]
has caused the debbugs.gnu.org bug report #30029,
regarding gzip-1.9 released [stable]
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
30029: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30029
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: Re: gzip-1.9 released [stable] Date: Mon, 8 Jan 2018 19:32:26 +0100 User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101 Thunderbird/56.0
On 07/01/2018 23:56, Jim Meyering wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

This is to announce gzip-1.9, a stable release.

There have been 53 commits by 2 people in the 89 weeks since 1.8.
Thanks to Paul Eggert for all of his help.

See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

  Jim Meyering (28)
  Paul Eggert (25)

Jim [on behalf of the gzip maintainers]
==================================================================

32-bit results - I package both sizes - in case there is an library interface. However, applications are only available in 64-bit.

(cc to bug-gzip maillist, have tried subscribing, but no confirmation mail yet).


============================================================================
Testsuite summary for gzip 1.9
============================================================================
# TOTAL: 21
# PASS:  18
# SKIP:  1
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0
============================================================================
See tests/test-suite.log
Please report to bug-gzip@gnu.org
============================================================================

a:
  +826  + eval 'env $i  zin.gz < $tmp_in > $tmp_out'
  +827  ++ env zless zin.gz
  +828  /data/prj/gnu/gzip/gzip-1.9/tests/../zless[71]: less:  not found
  +829  + echo FAIL: zless
  +830  FAIL: zless
  +831  + fail=1

  +891  FAIL: timestamp
  +892  ===============
This is to be expected - I expect - with 32-bit timestamp (OBJECT_MODE=32)

64-bit results

============================================================================
Testsuite summary for gzip 1.9
============================================================================
# TOTAL: 21
# PASS:  19
# SKIP:  1
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See tests/test-suite.log
Please report to bug-gzip@gnu.org
============================================================================

Again, less is still not installed.

--- End Message ---
--- Begin Message --- Subject: Re: gzip-1.9 released [stable] Date: Thu, 31 Mar 2022 16:53:30 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
  +826  + eval 'env $i  zin.gz < $tmp_in > $tmp_out'
  +827  ++ env zless zin.gz
  +828  /data/prj/gnu/gzip/gzip-1.9/tests/../zless[71]: less:  not found
  +829  + echo FAIL: zless
  +830  FAIL: zless
  +831  + fail=1

Thanks for reporting that. As 'less' is not required by POSIX we shouldn't assume it's installed. I installed the first attached patch to fix that (by not installing zless when 'less' is absent), and the second attached patch to fix a bug I found in the test cases for 'zmore' when I ran it with PAGER='less'.


q>   +891  FAIL: timestamp
  +892  ===============
This is to be expected - I expect - with 32-bit timestamp (OBJECT_MODE=32)

Yes, we don't worry about people perversely building a 32-bit time_t gzip on platforms that support 64-bit timestamps.

Recent versions of GNU/Linux have added support for 64-bit time_t even to platforms where 'long' and pointers are 32 bits.[1] Do recent versions of AIX have something similar? If so, we should teach Gnulib's year2038 module[2] how to enable that. This would fix this AIX problem for several GNU programs, not just gzip.

[1]: https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html [2]: https://www.gnu.org/software/gnulib/manual/html_node/Avoiding-the-year-2038-problem.html

Attachment: 0001-zless-install-only-on-platforms-with-less.patch
Description: Text Data

Attachment: 0002-zmore-don-t-assume-benign-PAGER-in-testing.patch
Description: Text Data


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]