On 03.10.2021 08:49, Arkadiusz Miśkiewicz via pld-devel-en wrote: > W dniu 01.10.2021 o 20:27, Jakub Bogusz pisze: > > On Fri, Oct 01, 2021 at 12:36:20PM +0200, arekm wrote: > >> commit 0818a4328225cca2d41e43f0fa816f38bb3cbe69 > >> Author: Arkadiusz Miśkiewicz <ar...@maven.pl> > >> Date: Fri Oct 1 12:36:07 2021 +0200 > >> > >> Rel 6; make sure we don't include expired certs > > > > Unfortunately ix86 `date` doesn't know y2038+... > > > > | date: invalid date 'Oct 25 08:25:55 2043 GMT' > > > > > > Jan, what was the reason behind --disable-year2038 in coreutils? > > Enabling that and date on ix86 parses such date correctly (with > coreutils 9.0).
The primary effect of y2038 handling is change of time_t from 32bit to 64bit which breaks abi compatibility with external libraries that were not compiled with y2038. If there's any library call that involves time_t either directly (argument/return value) or indirectly (member of publicly defined struct) then it will cause incorrect results if caller and callee use different time_t size. That's exactly what happened in wget interacting with libmetalink: https://savannah.gnu.org/bugs/index.php?61140 whether any such situation is possible in coreutils -- don't know, but to be on the safe side I prefer to disable it for the time being. Especially that y2038 handling is still a moving target. ie even if you don't use y2038 glibc requires you to be aware of internal mechanisms to handle it in order to use api correctly: https://github.com/systemd/systemd/issues/20564 I would say y2038 is either all or nothing. At some point we'd need rebuild everything with 64bit time_t (and keep our fingers crossed that abi breakages do not happen too often on builders during the process of transition). _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
