Hi, Maxime Devos <maximede...@telenet.be> skribis:
> On Fri, 2021-02-19 at 16:33 +0100, Ludovic Courtès wrote: >> [...] >> Longer-term, we need to find a way to address or avoid this issue. A >> brute-force approach would be to have the build machines at ci.guix run >> with a clock ten years ahead. That should generally be fine since the >> only place where timestamps matter are unmodified upstream tarballs. In >> all other cases, mtime is set to 1. > > Alternatively, could the build container be adjusted to always begin at > 1970-01-01, using ‘time namespaces’? > > Linux: https://lwn.net/Articles/766089/ Unfortunately, time namespaces are just for CLOCK_{MONOTONIC,BOOTTIME}, which I think is of little use here: https://issues.guix.gnu.org/44559#3 > Also, is there any particular reason to set the clock only ten years ahead, > and not, say, a millenia or two? Some possible reasons: > > * year 2038,2446 problem: the ext2 and ext4 filesystems have a restricted > date range > * year 2038 problem: > https://www.gnu.org/software/hurd/gnumach-doc/Host-Interface.html#Host-Interface > > IMO, the year 2038 problem is a bug and affected packages should simply be > fixed. > But perhaps reality is a little more complicated. Yeah, one problem at a time. :-) Setting it 10 years ahead would cache the kind of issue we’re talking about, while not opening the Y2038 can of worms. I think we need to try that out and see how it goes. Ludo’.