GNU bug report logs - #29265
gzip-1.8.41 test results: timestamp

Previous Next

Package: gzip;

Reported by: Bruno Haible <bruno <at> clisp.org>

Date: Sat, 11 Nov 2017 23:37:01 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29265 in the body.
You can then email your comments to 29265 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gzip <at> gnu.org:
bug#29265; Package gzip. (Sat, 11 Nov 2017 23:37:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bruno Haible <bruno <at> clisp.org>:
New bug report received and forwarded. Copy sent to bug-gzip <at> gnu.org. (Sat, 11 Nov 2017 23:37:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-gzip <at> gnu.org
Subject: gzip-1.8.41 test results: timestamp
Date: Sun, 12 Nov 2017 00:36:29 +0100
[Message part 1 (text/plain, inline)]
Hi,

Here are test results of the today's gzip git + newest gnulib (= nearly
the same as Jim's gzip-1.8.40). I tested only 32-bit platforms.

1) On
Linux/i386 (on a bi-arch system):
Linux/hppa (on a Linux/x86_64 system):
Linux/m68k (on a Linux/x86_64 system):
Linux/arm (on a bi-arch system):
Linux/powerpc (on a bi-arch system):
Linux/s390 (on a bi-arch system):
AIX/powerpc (on a bi-arch system):

- By default:
configure: error: This package requires a 64-bit 'time_t' type, which your system appears to support. You might try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'. To build with a 32-bit time_t anyway (not recommended), configure with 'TIME_T_32_BIT_OK=yes'.
- With TIME_T_32_BIT_OK=yes:
FAIL: timestamp

2) On
Linux/x86_64-x32 (on a bi-arch system):
Linux/mips o32:
Linux/mips o32 (on a bi-arch system):
Linux/mips n32 (on a bi-arch system):
Linux/arm:
Hurd/i386:
NetBSD/i386:
Solaris 10/i386 (on a bi-arch system):
Solaris 10/sparc (on a bi-arch system):
Mac OS X/i386 (on a bi-arch system):
Mac OS X/powerpc (on an x86_64 system):

All tests pass.

3)
Linux/sparc (on a bi-arch system):

On some machines, like 1). On other machines, like 2).

4)
FreeBSD/i386:
Haiku/i386:
HP-UX/hppa:
HP-UX/ia64:

The timestamp test passes, but some other tests fail (see separate mail).

5)
OpenBSD/i386:
NetBSD/sparc:
IRIX n32:
FAIL: timestamp

Find attached the test-suite.log of each platform.


Bruno
[test-suite.netbsd-sparc (text/plain, attachment)]
[test-suite.openbsd-i386 (text/plain, attachment)]
[test-suite.irix-n32 (text/plain, attachment)]

Information forwarded to bug-gzip <at> gnu.org:
bug#29265; Package gzip. (Sun, 12 Nov 2017 00:04:02 GMT) Full text and rfc822 format available.

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-gzip <at> gnu.org
Subject: Re: gzip-1.8.41 test results: timestamp
Date: Sun, 12 Nov 2017 01:02:56 +0100
[Message part 1 (text/plain, inline)]
I wrote:
> 5)
> OpenBSD/i386:
> NetBSD/sparc:
> IRIX n32:
> FAIL: timestamp
> 
> Find attached the test-suite.log of each platform.

Since Paul asked about more details on this one in
https://lists.gnu.org/archive/html/bug-gzip/2017-11/msg00005.html
here are more details (on OpenBSD/i386):

$ make check TESTS=timestamp VERBOSE=yes > timestamp.x 2>&1

Find it attached.
[timestamp.x (text/plain, attachment)]

Information forwarded to bug-gzip <at> gnu.org:
bug#29265; Package gzip. (Sun, 12 Nov 2017 08:26:02 GMT) Full text and rfc822 format available.

Message #11 received at 29265 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruno Haible <bruno <at> clisp.org>, 29265 <at> debbugs.gnu.org
Subject: Re: bug#29265: gzip-1.8.41 test results: timestamp
Date: Sun, 12 Nov 2017 00:25:23 -0800
[Message part 1 (text/plain, inline)]
Bruno Haible wrote:

> Since Paul asked about more details on this one in
> https://lists.gnu.org/archive/html/bug-gzip/2017-11/msg00005.html
> here are more details (on OpenBSD/i386):
> 
> $ make check TESTS=timestamp VERBOSE=yes > timestamp.x 2>&1

Thanks. I am puzzled by the failures. For example:

> + touch -t 190101010000 in
> + returns_ 2 gzip in
> + fail=1

Here, 'touch' succeeded, but gzip did not diagnose the negative timestamp. Do 
other programs report that the timestamp is 1901? For example, what is the 
output of this?

  export TZ=UTC0
  touch -t 190101010000 in
  ls -l in

Likewise for the timestamps 203801190314.08 and 210602070628.15, both of which 
are out of range for gzip but gzip did not diagnose it.

I installed the attached patch to tests/timestamp, partly in response to your 
earlier advice that we can't trust 'touch' to have the same time_t range as 
'gzip', and partly in response to the abovementioned failures. This patch uses 
'ls' to check the timestamp that 'touch' succeeded on. If the check fails, we 
don't bother to try 'gzip' on the same timestamp since the files' timestamp is 
dicey. Although this weakens the gzip testing, that's probably better than all 
these false alarms. This should fix some of the timestamp failures that you have 
reported.

While testing this, I discovered that on Solaris 10 and 11, file timestamps 
before the Epoch result in tv_nsec < 0! This bug is new to me. I plan to look 
into that bug separately. I expect that the best way to work around it is to add 
Gnulib code to fix the bogus timestamps.
[0001-tests-don-t-be-so-strict-about-timestamps.txt (text/plain, attachment)]

Information forwarded to bug-gzip <at> gnu.org:
bug#29265; Package gzip. (Sun, 12 Nov 2017 17:35:01 GMT) Full text and rfc822 format available.

Message #14 received at 29265 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 29265 <at> debbugs.gnu.org
Subject: Re: bug#29265: gzip-1.8.41 test results: timestamp
Date: Sun, 12 Nov 2017 18:34:30 +0100
Paul Eggert wrote:
> Thanks. I am puzzled by the failures. For example:
> 
> > + touch -t 190101010000 in
> > + returns_ 2 gzip in
> > + fail=1
> 
> Here, 'touch' succeeded, but gzip did not diagnose the negative timestamp. Do 
> other programs report that the timestamp is 1901? For example, what is the 
> output of this?
> 
>    export TZ=UTC0
>    touch -t 190101010000 in
>    ls -l in
>
> Likewise for the timestamps 203801190314.08 and 210602070628.15, both of which 
> are out of range for gzip but gzip did not diagnose it.

OpenBSD/i386:
NetBSD/sparc:

$ export TZ=UTC0
$ touch -t 190101010000 in
$ ls -l in
-rw-r--r--  1 bruno  bruno  0 Feb  6  2037 in
$ ls -lT in
-rw-r--r--  1 bruno  bruno  0 Feb  6  06:28:16 2037 in
$ touch -t 203801190314.08 in2
$ ls -l in2
-rw-r--r--  1 bruno  bruno  0 Dec 13  1901 in2
$ ls -lT in2
-rw-r--r--  1 bruno  bruno  0 Dec 13 20:45:52 1901 in2
$ touch -t 210602070628.15 in3
$ ls -l in3
-rw-r--r--  1 bruno  bruno  0 Dec 31  1969 in3
$ ls -lT in3
-rw-r--r--  1 bruno  bruno  0 Dec 31 23:59:59 in3

IRIX 6.5 with n32:

$ export TZ=UTC0
$ touch -t 190101010000 in
Bad date conversion
$ ls -l in
Cannot access in: No such file or directory
$ touch -t 203801190314.08 in2
$ ls -l in2
-rw-r--r--    1 bruno    bruno          0 Dec 13  1901 in2
$ touch -t 210602070628.15 in3
Bad date conversion
$ ls -l in3
Cannot access in3: No such file or directory

Regarding OpenBSD, I've just reported this to the OpenBSD people:
https://marc.info/?l=openbsd-bugs&r=1&b=201711&w=2

> I installed the attached patch to tests/timestamp, partly in response to your 
> earlier advice that we can't trust 'touch' to have the same time_t range as 
> 'gzip', and partly in response to the abovementioned failures. This patch uses 
> 'ls' to check the timestamp that 'touch' succeeded on.

This patch fixes the test failure on all three platforms.

> While testing this, I discovered that on Solaris 10 and 11, file timestamps 
> before the Epoch result in tv_nsec < 0! This bug is new to me. I plan to look 
> into that bug separately. I expect that the best way to work around it is to add 
> Gnulib code to fix the bogus timestamps.

I expect that Solaris will not be the only platform with this bug...

Bruno





Reply sent to Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility. (Mon, 26 Dec 2022 05:38:01 GMT) Full text and rfc822 format available.

Notification sent to Bruno Haible <bruno <at> clisp.org>:
bug acknowledged by developer. (Mon, 26 Dec 2022 05:38:01 GMT) Full text and rfc822 format available.

Message #19 received at 29265-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 29265-done <at> debbugs.gnu.org
Subject: Re: bug#29265: gzip-1.8.41 test results: timestamp
Date: Sun, 25 Dec 2022 21:37:10 -0800
On 11/12/17 00:25, Paul Eggert wrote:
> I installed the attached patch to tests/timestamp

As this appears to have fixed the bug, I'm closing this old bug report.





Information forwarded to bug-gzip <at> gnu.org:
bug#29265; Package gzip. (Mon, 26 Dec 2022 07:43:01 GMT) Full text and rfc822 format available.

Message #22 received at 29265 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 29265 <at> debbugs.gnu.org
Subject: Re: bug#29265: gzip-1.8.41 test results: timestamp
Date: Mon, 26 Dec 2022 08:42:53 +0100
In 2017 I wrote:
> Regarding OpenBSD, I've just reported this to the OpenBSD people:
> https://marc.info/?l=openbsd-bugs&r=1&b=201711&w=2

They discussed the issue, but AFAICS with no consequences:
  https://marc.info/?t=151050797500001&r=1&w=2

Bruno







bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 23 Jan 2023 12:24:12 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 65 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.