Hi Mamoru. Could be useful changing timestamp of that file when i create the IceCat source archive to resolve this problem? On 6/2/22 16:50, Mamoru TASAKA wrote: -- --- Antonio Trande Fedora Project mailto: sagitter(a)fedoraproject.org GPG key: 0xCC1CFEF30920C8AE GPG key server: https://keyserver1.pgp.com/

V Thu, Jun 02, 2022 at 04:33:23PM +0200, Antonio T. sagitter napsal(a): I don't know tar format, so I cannot tell whether it's a broken archive or not. Definitely the time stamps are unreal. tar NEWS files mentions: On 32-bit hosts, 'tar' now assumes that an incoming time stamp T in the range 2**31 <= T < 2**32 represents the negative time (T - 2**32). This behavior is nonstandard and is not portable to 64-bit time_t hosts, so 'tar' issues a warning. I'm able to reproduce it with "tar tjf icecat-91.10.0-rh2.tar.bz2 >/dev/null" where tar comes from tar-1.34-3.fc36.i686 and icecat-91.10.0-rh2.tar.bz2 from currect icecat dist-git sources (SHA512 = 9b46b67d5a6206c491aa9285a361170420cc0b421acd46be8e658b39a26b75c07e89d201525fcbde7bec125699d52970f0fb3d5a7a00dad8408e2a1201ae2f9a). tar internally stores time stamps in a variable of time_t type. That type is by default 32-bit on i686 architecture. tar program indeed reports an error if it cannot internally represent the values read from a tar achive headers. A possible fix should be compile tar with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 CFLAGS: $ cat main.c #include <stdio.h> #include <time.h> int main(void) { printf("sizeof(time_t)=%d\n", sizeof(time_t)); return 0; } $ gcc -m32 main.c $ ./a.out sizeof(time_t)=4 $ gcc -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 main.c $ ./a.out sizeof(time_t)=8 I recommend you to file a bug against tar in Fedora's Bugzilla. However, this proposed solution would require rebuilding in the same way all libraries which tar uses and which pass time_t and similar types in their interface. That would probably break other packages. So maybe more realisic fix will enhancing tar to ignore these time stamps when unpacking an archive. -- Petr

On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote: Now that the kernel and glibc have this feature, would it make sense to change the global CFLAGS to build everything with 64-bit time_t on all currently supported 32-bit archs? If not now, how close to the 32-bit overflow in 2038? It's not just about keeping current time and file timestamps. There are applications/libraries that calculate future dates and overflows can lead to serious issues. Switching to 64-bit time_t may require some patching, e.g. when the code assumes sizeof(long) == sizeof(time_t). -- Miroslav Lichvar

On 6/6/22 13:29, Petr Pisar wrote: The way glibc compatibility works, existing binaries will continue to get the ABIs they were built with once upon a time and continue to work like nothing ever happened. Except of course that time will wrap around eventually. Or at least that's how the theory goes, IIRC the time_t transition has its own peculiarities that other similar transitions haven't had. Yup, but i686 can be easily built on x86_64 which alleviates things quite a bit. - Panu -

Am 06.06.22 um 16:38 schrieb Petr Pisar: How about dlopened libraries? I'd assume these can become problematic. Ralf