Hi, On Mon, 17 Apr 2023 at 15:16, Vagrant Cascadian <vagr...@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
