GNU bug report logs - #44559
gnutls 3.6.12 fails to build: FAIL: status-request-revoked

Previous Next

Full log

View this message in rfc822 format

From: Maxime Devos <maximedevos <at> telenet.be>
To: Ludovic Courtès <ludo <at> gnu.org>, Carl Dong <contact <at> carldong.me>
Cc: 44559 <at> debbugs.gnu.org, Mathieu Othacehe <othacehe <at> gnu.org>
Subject: bug#44559: 
Date: Fri, 19 Feb 2021 19:32:34 +0100

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.