V Thu, Jun 02, 2022 at 04:33:23PM +0200, Antonio T. sagitter napsal(a):
Hi all.
rpmuncompress is failing in Rawhide i686 architecture only with:
/usr/bin/tar: Archive value 4027676192 is out of time_t range
-2147483648..2147483647
/usr/bin/tar:
icecat-91.10.0/extensions/gnu/jid1-KtlZuoiikVfFew(a)jetpack/bundle.js:
implausibly old time stamp 1969-12-31 23:59:59
...
(
https://kojipkgs.fedoraproject.org//work/tasks/1685/87811685/build.log)
If it was an archive issue, it should happen in all architectures.
Anyone know why this occurs?
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