[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44559:
From: |
Maxime Devos |
Subject: |
bug#44559: |
Date: |
Fri, 19 Feb 2021 19:32:34 +0100 |
User-agent: |
Evolution 3.34.2 |
Hi Guix,
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/
Hurd analogue:
https://www.gnu.org/software/hurd/gnumach-doc/Host-Interface.html#Host-Interface
(Of course, someone needs to find the time to write the patches first. Maybe
I'll have a try at it eventually, but probably not anytime soon.)
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.
Greetings,
Maxime
signature.asc
Description: This is a digitally signed message part