Re: Archive value is out of time_t range
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 T. sagitter wrote on 2022/06/02 23:33: 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@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? Best, Perhaps it is 32 bit architecture. Actually: [tasaka1@localhost icecat-91.10.0]$ ls -al extensions/gnu/jid1-KtlZuoiikVfFew@jetpack/bundle.js -rw-r--r--. 1 tasaka1 tasaka1 433208 Jul 29 2114 extensions/gnu/jid1-KtlZuoiikVfFew@jetpack/bundle.js This is above year 2038. (Anyway the timestamp on this file seems strange.) Regards, Mamoru ___ -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0xCC1CFEF30920C8AE GPG key server: https://keyserver1.pgp.com/ OpenPGP_0xCC1CFEF30920C8AE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Archive value is out of time_t range
* Ralf Corsépius: > Am 06.06.22 um 16:38 schrieb Petr Pisar: > >> I believe that glibc payed a special attention to provide both >> ABIs. But that does not apply to other libraries. Maybe it's not so >> important problem. Proprietary software tends to bundle the >> libraries, externally relying only on kernel and glibc. (X libraries, Motif, glib are usually not bundled, either, and there are a couple mor examples. It's likely that there is at least some time_t or struct timeval/timespec exposre in all of these otherwise ABI-stable libraries.) > How about dlopened libraries? I'd assume these can become problematic. dlsym calls need to be taught to use the time64 aliases. Symbol versioning isn't used. Maybe we could add a time64 version of dlsym and dlvsym that knows about the aliased symbols, but we really shouldn't be doing new development work for 32-bit architectures. It doesn't benefit Fedora, and most embedded 32-bit users do not use glibc, either. However, there was a strong push from a few interested parties who funded the initial development (and at least one party is still involved and addresses any fallout from the changes). I'm not really happy how things turned out, but at least there is no immediate harm to Fedora's i686 compatibility packages (beyond the occasional bug, but as I mentioned, someone is still around to fix them). Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Archive value is out of time_t range
Am 06.06.22 um 16:38 schrieb Petr Pisar: I believe that glibc payed a special attention to provide both ABIs. But that does not apply to other libraries. Maybe it's not so important problem. Proprietary software tends to bundle the libraries, externally relying only on kernel and glibc. How about dlopened libraries? I'd assume these can become problematic. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Archive value is out of time_t range
V Mon, Jun 06, 2022 at 02:40:50PM +0300, Panu Matilainen napsal(a): > On 6/6/22 13:29, Petr Pisar wrote: > > V Mon, Jun 06, 2022 at 12:07:18PM +0200, Miroslav Lichvar napsal(a): > > > On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote: > > > > $ 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. > > > > > > 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? > > > > > That would be ideal, but I worry that Fedora will rather drop i686 > > archicture > > than change ABI of all packages. > > > > Most of the uses cases for i686 is a multilib for proprietary software. > > Changing ABI would break it. How much of that software will be relevant in > > 15 > > years? > > 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. > I believe that glibc payed a special attention to provide both ABIs. But that does not apply to other libraries. Maybe it's not so important problem. Proprietary software tends to bundle the libraries, externally relying only on kernel and glibc. > 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. > > > > > We dropped 32-bit ARM because we were unable to build the software (in > > a reasonable time). As software becomes hungrier (and less tested on 32 > > bits), we > > start observing the same problem in i686. > > Yup, but i686 can be easily built on x86_64 which alleviates things quite a > bit. > Wasn't that also said about ARMv7 on AArch64? -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Archive value is out of time_t range
On 6/6/22 13:29, Petr Pisar wrote: V Mon, Jun 06, 2022 at 12:07:18PM +0200, Miroslav Lichvar napsal(a): On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote: $ 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. 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? That would be ideal, but I worry that Fedora will rather drop i686 archicture than change ABI of all packages. Most of the uses cases for i686 is a multilib for proprietary software. Changing ABI would break it. How much of that software will be relevant in 15 years? 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. We dropped 32-bit ARM because we were unable to build the software (in a reasonable time). As software becomes hungrier (and less tested on 32 bits), we start observing the same problem in i686. Yup, but i686 can be easily built on x86_64 which alleviates things quite a bit. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Archive value is out of time_t range
V Mon, Jun 06, 2022 at 12:07:18PM +0200, Miroslav Lichvar napsal(a): > On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote: > > $ 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. > > 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? > That would be ideal, but I worry that Fedora will rather drop i686 archicture than change ABI of all packages. Most of the uses cases for i686 is a multilib for proprietary software. Changing ABI would break it. How much of that software will be relevant in 15 years? We dropped 32-bit ARM because we were unable to build the software (in a reasonable time). As software becomes hungrier (and less tested on 32 bits), we start observing the same problem in i686. -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Archive value is out of time_t range
On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote: > $ 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. 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Archive value is out of time_t range
https://bugzilla.redhat.com/show_bug.cgi?id=2092964 On 6/2/22 17:46, Petr Pisar wrote: 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0xCC1CFEF30920C8AE GPG key server: https://keyserver1.pgp.com/ OpenPGP_0xCC1CFEF30920C8AE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Archive value is out of time_t range
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@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
#include
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
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Archive value is out of time_t range
On Thu, 2 Jun 2022 at 10:34, Antonio T. sagitter wrote: > 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@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? > > So something seems odd with that file or some sort of conversion and I am guessing it is a 64bit to 32 bit conversion of some sort. [The other architecture it might happen on would be arm32bit which is not in rawhide anymore.] However those dates seem really weird to the point of a corrupt archive or something before that part causing an overflow. Again it is probably a 32 bit/64 bit ``` $ date --date='@4027676192' Sun 18 Aug 10:56:32 EDT 2097 ``` on a 64 bit architecture and on a 32 bit would wrap to -267291104 (?? I think I got that right). The error I see above is that should be a time stamp of 'Thu 13 Jul 04:28:16 EDT 1961' > Best, > -- > --- > Antonio Trande > Fedora Project > mailto: sagit...@fedoraproject.org > GPG key: 0xCC1CFEF30920C8AE > GPG key server: https://keyserver1.pgp.com/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Archive value is out of time_t range
Antonio T. sagitter wrote on 2022/06/02 23:33: 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@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? Best, Perhaps it is 32 bit architecture. Actually: [tasaka1@localhost icecat-91.10.0]$ ls -al extensions/gnu/jid1-KtlZuoiikVfFew@jetpack/bundle.js -rw-r--r--. 1 tasaka1 tasaka1 433208 Jul 29 2114 extensions/gnu/jid1-KtlZuoiikVfFew@jetpack/bundle.js This is above year 2038. (Anyway the timestamp on this file seems strange.) Regards, Mamoru ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Archive value is out of time_t range
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@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? Best, -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0xCC1CFEF30920C8AE GPG key server: https://keyserver1.pgp.com/ OpenPGP_0xCC1CFEF30920C8AE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
