Re: tests/time01.at failing on i586, ppc and armv7l

[Bernhard Voelker]

[+Danilo (=downstream maintainer)]

Hi Paul,

On 10/13/21 23:58, Paul Eggert wrote:
> On 10/13/21 13:57, Bernhard Voelker wrote:
> 
>> Is it possible that newer touch(1) from coreutils-9.0 supports more of the 
>> tricky timestamps
>> which tar-1.34 still fails to grok?
> 
> 
> I guess that coreutils was built with 64-bit time_t, but the compiler or 
> development library for some reason doesn't support 64-bit time_t. 
> Perhaps a coreutils/glibc mismatch? You'll need glibc 2.34 or later on 
> platforms like i586 where time_t is traditionally 32-bit but recent 
> Linux kernels have support for 64-bit time_t (this is true for 32-bit 
> x86 and ARM; I don't know about 32-bit PPC).
> 
> To pass the tests you can build on a 32-bit-only system, with a 
> coreutils that does not support 64-bit time_t, so that the 'tar' tests 
> don't attempt to try file timestamps past the year 2038.
> 
> I suppose we could modify GNU tar's tests so that it doesn't attempt to 
> try these post-2038 timestamps on 32-bit builds. However, it might be 
> better to leave those tests alone, to remind people to be wary of 
> building 32-bit time_t apps with the clock ticking away towards the year 
> 2038 (when these apps will stop working).
> 
> Since GNU tar is a core GNU app, I expect that it should use the same 
> year2038 module that coreutils does, to underscore the importance of 
> being year-2038 safe. So I added the year2038 module to the 
> gnulib.modules files of paxutils and tar on Savannah. If you build from 
> bleeding-edge tar and don't want 64-bit time_t, you can configure with 
> --disable-year2038 (though the tests you mention will still fail if 
> coreutils is 64-bit).

Thanks for the clarification.
We'll exempt that test on those platforms for now.

One remark: it seems surprising that `tar -c` succeeds, and only the
later `tar -d` complains, because both supposedly do a stat().
I didn't look into the code, so I assume that -c is constraining
the values silently into the valid range, doesn't it?

Have a nice day,
Berny