[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44559:
From: |
Ludovic Courtès |
Subject: |
bug#44559: |
Date: |
Sat, 20 Feb 2021 14:46:28 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Hi,
Maxime Devos <maximedevos@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’.