From: "Ludovic Courtès" <ludo@gnu.org>
To: Maxime Devos <maximedevos@telenet.be>
Cc: 44559@debbugs.gnu.org, Mathieu Othacehe <othacehe@gnu.org>,
Carl Dong <contact@carldong.me>
Subject: bug#44559:
Date: Sat, 20 Feb 2021 14:46:28 +0100 [thread overview]
Message-ID: <87v9amj1hn.fsf@gnu.org> (raw)
In-Reply-To: <5d72d9c66d0e9f70f6ff1fb3b4d08ed530551288.camel@telenet.be> (Maxime Devos's message of "Fri, 19 Feb 2021 19:32:34 +0100")
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’.
next prev parent reply other threads:[~2021-02-20 13:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 20:49 bug#44559: gnutls 3.6.12 fails to build: FAIL: status-request-revoked Christopher Baines
2020-11-12 21:06 ` Ludovic Courtès
2020-11-12 21:18 ` Marius Bakke
2020-11-15 11:05 ` Ludovic Courtès
2020-12-31 0:27 ` bug#44559: Solution jeremiah
2021-02-16 21:00 ` bug#44559: Carl Dong
2021-02-16 21:49 ` bug#44559: Leo Famulari
2021-02-19 15:33 ` bug#44559: Ludovic Courtès
2021-02-19 18:32 ` bug#44559: Maxime Devos
2021-02-20 13:46 ` Ludovic Courtès [this message]
2021-02-20 14:12 ` bug#44559: Detecting “expiring” builds Ludovic Courtès
2021-02-19 23:49 ` bug#44559: Carl Dong
2021-02-22 22:36 ` bug#44559: Christopher Baines
2021-02-23 8:41 ` bug#44559: Ludovic Courtès
2021-02-23 8:55 ` bug#44559: Christopher Baines
2022-07-13 15:03 ` bug#44559: gnutls 3.6.12 fails to build: FAIL: status-request-revoked Maxim Cournoyer
2022-07-15 13:17 ` Ludovic Courtès
2022-07-16 1:33 ` Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v9amj1hn.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=44559@debbugs.gnu.org \
--cc=contact@carldong.me \
--cc=maximedevos@telenet.be \
--cc=othacehe@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.