Discussion:
bug#29033: [platform-testers] new snapshot available: gzip-1.8.32-4606
Add Reply
Paul Eggert
2017-11-07 07:29:01 UTC
Reply
Permalink
Raw Message
+ touch -t 210602070628.15 in
touch: invalid date format '210602070628.15'
+ printf '\037\213\10\0\377\377\377\377\0\377\3\0\0\0\0\0\0\0\0\0'
+ returns_ 2 gzip -Nlv
method crc date time compressed uncompressed ratio uncompressed_name
defla 00000000 Oct 28 00:47 20 0 0.0% stdout
+ fail=1
Instead of suppressing the test, how about if we tell builders not to build with
-m32 on platforms supporting 64-bit time_t? That way, they won't run into a
problem where gzip mishandles file timestamps due to OS screwups or
errno==EOVERFLOW problems that cannot happen with 64-bit time_t. In the
not-too-distant future we're going to have to insist on 64-bit time_t anyway,
and in the meantime we can strongly suggest 64-bit time_t by installing the
first attached patch to gzip (which I've done), by installing the attached
proposed patch to Gnulib (which I have not done yet, pending your comments), and
by syncing gzip to gnulib.
# On platforms that fail to support timestamps within gzip's range,
# test that gzip warns when converting them from gzip format.
Gzip's behaviour depends on libc, and what the 'touch' program is doing
is a different thing. It's incorrect to assume that libc's behaviour and
touch's behaviour are consistent.
The testcase doesn't assume that. It merely assumes that standard utilities
support a superset of the timestamps that libc supports. This should be a
reasonable assumption for the -m32 case that you describe (and which I'm trying
to discourage with the abovementioned patches).

The assumption would not be reasonable for platforms where standard utilities
are worse than libc, but this should be uncommon. If it is a problem, perhaps we
can get by, by simply telling users to ignore the tests in that case.

CC'ing to bug-gnulib since the 2nd patch is for Gnulib.
Paul Eggert
2017-11-11 07:26:01 UTC
Reply
Permalink
Raw Message
Post by Paul Eggert
Instead of suppressing the test, how about if we tell builders not to build with
-m32 on platforms supporting 64-bit time_t?
No further comment, and it seems like a good idea regardless of the test failure
since the year 2038 will arrive sooner than we'd like, so I installed the patch
into Gnulib and synced it into gzip.
Bruno Haible
2017-11-11 14:30:22 UTC
Reply
Permalink
Raw Message
Post by Paul Eggert
Post by Paul Eggert
Instead of suppressing the test, how about if we tell builders not to build with
-m32 on platforms supporting 64-bit time_t?
No further comment, and it seems like a good idea regardless of the test failure
since the year 2038 will arrive sooner than we'd like, so I installed the patch
into Gnulib and synced it into gzip.
Thanks. Very thoughtful patch.

I'm only adding a no-op tweak regarding indentation.

2017-11-11 Bruno Haible <***@clisp.org>

year2038: Tweak last patch.
* m4/year2038.m4 (gl_YEAR2038): Correct indentation.
Bruno Haible
2017-11-11 14:30:41 UTC
Reply
Permalink
Raw Message
Hi Pádraig, Bernhard,

You may have seen that Paul made the gnulib module 'year2038' [1] useful for all
platforms, especially Linux/i386.

I think it would be a good idea for coreutils and findutils to include this module,
in order to raise awareness of the year 2038 problem for those people who build
binaries that will be in use for a long time (e.g. embedded and busybox environments).

Bruno

[1] https://www.gnu.org/software/gnulib/manual/html_node/Avoiding-the-year-2038-problem.html
Bernhard Voelker
2017-11-13 08:12:40 UTC
Reply
Permalink
Raw Message
Hi Pádraig, Bernhard,
You may have seen that Paul made the gnulib module 'year2038' [1] useful for all
platforms, especially Linux/i386.
I think it would be a good idea for coreutils and findutils to include this module,
in order to raise awareness of the year 2038 problem for those people who build
binaries that will be in use for a long time (e.g. embedded and busybox environments).
Bruno
[1] https://www.gnu.org/software/gnulib/manual/html_node/Avoiding-the-year-2038-problem.html
... and here the same for coreutils.

Have a nice day,
Berny
Pádraig Brady
2017-11-13 06:27:30 UTC
Reply
Permalink
Raw Message
Post by Bruno Haible
Hi Pádraig, Bernhard,
You may have seen that Paul made the gnulib module 'year2038' [1] useful for all
platforms, especially Linux/i386.
I think it would be a good idea for coreutils and findutils to include this module,
in order to raise awareness of the year 2038 problem for those people who build
binaries that will be in use for a long time (e.g. embedded and busybox environments).
Bruno
[1] https://www.gnu.org/software/gnulib/manual/html_node/Avoiding-the-year-2038-problem.html
Good idea - patch attached.
+1
thanks!
Paul Eggert
2017-11-11 20:13:38 UTC
Reply
Permalink
Raw Message
Post by Bruno Haible
I think it would be a good idea for coreutils and findutils to include this module
I agree. I'm also thinking of having Emacs use it, though for different reasons
(I doubt whether Emacs will be installed on many embedded apps...). gzip should
make a good guinea pig for this.

Loading...