bug#64746: [PATCH v2 3/3] scripts: time-machine: Error when attempting to visit too old commits.

[Maxim Cournoyer]

Hi Simon,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi Maxim,
>
> For the record, I have documented [1] the various roadblocks when using
> “guix time-machine” rebuilding all from source.  Time-bomb is one among
> other annoyances – I have in mind the complete bootstrap.
>
> Well, as Ludo pointed, the CI is currently building all the past
> releases.  Waiting the fixes for all the bugs, I suggest that we retain
> the substitutes for the release.  I mean that,
>
>     guix time-machine --commit=v1.X.0 -- help
>
> just works when substitutes are available.  If the project is lacking
> disk space, the University of Montpellier (France) is proposing to store
> some binary artifact outputs.  At least, they were proposing back on
> past September in 10 Years of Guix event. :-)  There is discussion on
> guix-sysadmin, I guess.  Maybe we could resume this discussion and
> complete the last steps.  WDYT?

That make sense.  The current means this can be achieved is by having a
jobset for each release in Cuirass, as hinted in doc/release.org from
the guix-maintenance repo:

--8<---------------cut here---------------start------------->8---
** Adding a Cuirass jobset for branch =version-X.Y.Z=

This jobset will have to be kept until the next release, so that
substitutes remain available.  The easiest way to add a new jobset is
directly via the web interface of Cuirass.  To be allowed to do so,
you must authenticate with the Cuirass instance via a private TLS
certificate imported into your browser.
--8<---------------cut here---------------end--------------->8---

They should be added declaratively in the guix-maintenance repo to avoid
loosing them.  Would you like to give it a try?

[...]

>> diff --git a/doc/guix.texi b/doc/guix.texi
>> index b50feed4c4..a3754b7019 100644
>> --- a/doc/guix.texi
>> +++ b/doc/guix.texi
>> @@ -5060,6 +5060,20 @@ Invoking guix time-machine
>>  large number of packages; the result is cached though and subsequent
>>  commands targeting the same commit are almost instantaneous.
>>
>> +Due to @command{guix time-machine} relying on the ``inferiors''
>> +mechanism (@pxref{Inferiors}), the oldest commit it can travel to is
>> +commit @samp{6298c3ff} (``v1.0.0''), dated May 1@sup{st}, 2019, which is
>> +the first release that included the inferiors mechanism.  An error is
>> +returned when attempting to navigate to older commits.
>
> There is also some issue with bootstrapping depending on your hardware.
>
> About time-bomb, there are also gnutls and openssl or libgit2.  It was
> probably transparent for you because there are substitutable, I guess.
> While Python 2 had probably been removed for some reasons.
>
> Well, I would move the workaround to some dedicated block and move this
> comment after the note about security
>
> @quotation Note
> The history of Guix is immutable and @command{guix time-machine}
> provides the exact same software as they are in a specific Guix
> revision.  Naturally, no security fixes are provided for old versions
> of Guix or its channels.  A careless use of @command{guix time-machine}
> opens the door to security vulnerabilities.  @xref{Invoking guix pull,
> @option{--allow-downgrades}}.
> @end quotation
>
> +Due to @command{guix time-machine} relying on the ``inferiors''
> +mechanism (@pxref{Inferiors}), the oldest commit it can travel to is
> +commit @samp{6298c3ff} (``v1.0.0''), dated May 1@sup{st}, 2019, which is
> +the first release that included the inferiors mechanism.  An error is
> +returned when attempting to navigate to older commits.
> +
> +@quotation Note
> +Although it should technically be possible to travel to such an old
> +revision, the ease to do so will largely depend on the availability of
> +binary substitutes.  When traveling to a distant past, some packages may
> +not easily build from source anymore.  One such example are old versions
> +of Python 2 which had time bombs in its test suite, in the form of
> +expiring SSL certificates.  This particular problem can be worked around
> +by setting the hardware clock to a value in the past before attempting
> +the build.
> +@end quotation

Good suggestion, done!

>  The general syntax is:
>
>  @example
>
>
>
>> new file mode 100644
>> index 0000000000..8b62ef75ea
>> --- /dev/null
>> +++ b/tests/guix-time-machine.sh
>
> [...]
>
>> +# Visiting a commit older than v1.0.0 fails.
>> +! guix time-machine --commit=v0.15.0
>
> Cool to add test.  But this test needs a network access:
>
> $ ./pre-inst-env guix time-machine --commit=v0.15.0 -- describe
> guix time-machine: error: Git error: failed to resolve address for 
> git.savannah.gnu.org: Name or service not known
>
> It’s as I said elsewhere. :-)  Well, I have not investigated more but I
> guess a bug in some Git manipulation.

>From my testing, the test doesn't require networking, perhaps because it
doesn't use the --commit or --branch arguments.  I've tested that with
this in /etc/hosts, with the first IP being bogus:

--8<---------------cut here---------------start------------->8---
192.168.254.254         git.savannah.gnu.org    savannah
--8<---------------cut here---------------end--------------->8---

I've investigated a bit, and it seems that reaching to the network is
only done when using tags or branch names, not exact commits.  That is
expected I think, since tags or branch names are not immutable in Git,
while a commit ID is.

I've now installed this change; thanks for the review and suggestions!

--
Thanks,
Maxim