GNU bug report logs -
#29265
gzip-1.8.41 test results: timestamp
Previous Next
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.
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):
[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):
[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):
[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):
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):
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):
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.