From: Simon Tournier <zimon.toutoune@gmail.com>
To: "Vagrant Cascadian" <vagrant@reproducible-builds.org>,
"Ludovic Courtès" <ludo@gnu.org>,
"Konrad Hinsen" <konrad.hinsen@fastmail.net>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Time travel accident
Date: Tue, 18 Apr 2023 11:39:30 +0200 [thread overview]
Message-ID: <868reppm0d.fsf@gmail.com> (raw)
In-Reply-To: <87354ynoh0.fsf@wireframe>
Hi,
On Mon, 17 Apr 2023 at 15:16, Vagrant Cascadian <vagrant@reproducible-builds.org> wrote:
> On 2023-04-17, Simon Tournier wrote:
>>> My plan is to write a service that makes it easy to offload a build to a
>>> VM that runs with a different time (“in the past”) or something along
>>> these lines to mitigate the problem.
[...]
> I can see "in the past" being useful to handle builds with time-bombs
> that already slipped through the cracks
My use-case is a researcher trying to redo in the future of 5 years some
computations from a published (3 years ago) article providing some
channels.scm and manifest.scm files.
In this use-case, this researcher often runs Guix on the top of some
GNU/Linux distro and probably on some shared machine in some University.
Last, I envision for my use-case that the Guix infrastructure ecosystem
would not be there to run this “offloading service”. Otherwise, it
appears to me far easier to just store the current substitutes – or say
part of the current substitutes.
>> Wording aside :-) What do Reproducible Builds for that? Because
>> time-bomb seems similar as timestamp…
>
> At least for https://tests.reproducible-builds.org/debian on
> amd64/x86_64, I think one of the builds runs approximately 1 year, 1
> month and 1 day in the future (+397 days?), which pretty much maximizes
> the chance of a difference in year, month or day, while sommewhat
> minimizing detection of time bombs...
Since we are somehow building (at least) twice (Bordeaux and Berlin),
maybe we could exploit this fact and so build “in the future“.
I mean, similarly as we are doing world-rebuild with core-updates
cycles, we could do a feature branch with a different time (”in the
future“) more or less around the release. Somehow, similarly as we are
tagging some packages with ‘non reproducible’, we could tag the ones
with ’time bombs’.
> For detecting time-bombs, I would guess you want to test even further
> into the future, maybe 5-10 years or so. Much longer, and you are
> getting pretty close to 2038, which is an extra-special set of timebombs
> that will need to be addressed at some point!
Yeah, 2038 is something [1]…
1: <https://en.wikipedia.org/wiki/Year_2038_problem>
Cheers,
simon
prev parent reply other threads:[~2023-04-18 9:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-07 7:47 Time travel accident Konrad Hinsen
2023-04-07 8:30 ` Josselin Poiret
2023-04-07 10:07 ` Julien Lepiller
2023-04-07 16:10 ` Konrad Hinsen
2023-04-07 17:39 ` Julien Lepiller
2023-04-11 15:20 ` Konrad Hinsen
2023-04-12 10:17 ` Konrad Hinsen
2023-04-12 14:09 ` Simon Tournier
2023-04-13 8:14 ` Konrad Hinsen
2023-04-12 11:03 ` Simon Tournier
2023-04-12 12:53 ` Konrad Hinsen
2023-04-07 17:26 ` Simon Tournier
2023-04-17 13:32 ` Ludovic Courtès
2023-04-17 17:50 ` Simon Tournier
2023-04-17 22:16 ` Vagrant Cascadian
2023-04-18 9:39 ` Simon Tournier [this message]
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=868reppm0d.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=guix-devel@gnu.org \
--cc=konrad.hinsen@fastmail.net \
--cc=ludo@gnu.org \
--cc=vagrant@reproducible-builds.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.