On 2023-04-17, Simon Tournier wrote: > On lun., 17 avril 2023 at 15:32, Ludovic Courtès 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