Re: Time travel accident

[Vagrant Cascadian <vagrant@reproducible-builds.org>]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

On 2023-04-17, Simon Tournier wrote:
> On lun., 17 avril 2023 at 15:32, Ludovic Courtès <ludo@gnu.org> 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.
>
> Do you mean “in the future” instead?  We need to know if the package
> will still build with a different time from the future, no?

I can see "in the past" being useful to handle builds with time-bombs
that already slipped through the cracks, and "in the future" to detect
these time-bombs while there is still time to fix them...


> 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...

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!

If guix someday has a long-term support release model, catching these
sorts of time-bombs as early as possible becomes even more important,
though with the current release model of once or twice a year or so, it
is a bit less problematic... although if it happens in something low on
the dependency graph, it of course gets more urgent!


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]