[bug#68677] [PATCH 0/6] Service for "virtual build machines"

[Simon Tournier]

Hi,

Thanks for your feedback.

On lun., 05 févr. 2024 at 15:45, Suhail via Guix-patches via 
<guix-patches@gnu.org> wrote:

> 1. The documentation references GNU Shepherd.  Is GNU Shepherd a hard
>    requirement in order to use the facilities provided by the patch
>    series?  Would it be possible to use, say, Systemd on a foreign
>    distribution?  If so, could examples of those be documented in the
>    appropriate place as well?

>From my understanding, for now, it is for Guix System, so using
Shepherd.  It might be possible to use the ’vm’ on foreign distros but
some details must be configured by hand, when it is automatically done
by the “extended service”.  More or less. :-)


> 2. The code sets the default date to be 2020-01-01; does this date have
>    any significance?  It might help for the code to have a comment
>    explaining whether this value is completely arbitrary or whether it
>    has some significance.  On a related note, it might help for the
>    documentation to note dates that are less likely to work (in case
>    values before a certain time aren't expected to be well supported).

For this date, nothing specific I guess.  The oldest commit that one can
reaches using “guix time-machine” is May 2019.

Aside, it is hard to maintain a list of dates that “work”.  Because
nothing is written in stone and the passing of time cannot be frozen.

For instance, 6 months ago, a jump of ~4 years was just working [1].
And now, it is broken [2].  Somehow, Guix provides features that demo a
real-world experience which was simply impossible.  Therefore, things
are fluctuating toward more robustness.

That’s said, based on my experience playing with “guix time-machine”, my
rule of thumb is: 2-3 years old is most of the time ok.  Older than 3
years is… cross-finger.


1: https://simon.tournier.info/posts/2023-06-23-hackathon-repro.html
2: https://issues.guix.gnu.org/69058


> Additionally, I'm not sure if this belongs in the manual or in the
> cookbook (or elsewhere), but it would be helpful to have some small, but
> complete, examples.  The documentation in the patch series mentions two
> situations (time traps, and CPU microarchitecture optimizations) and for
> each it would be helpful to have a self-contained full working example
> referenced.  For the "time trap" use-case, perhaps one of the
> submissions from the Ten Years Reproducibility Challenge could be used.

The issue with time-trap is documented in the manual, see:

           Due to ‘guix time-machine’ relying on the “inferiors” mechanism
        (*note Inferiors::), the oldest commit it can travel to is commit
        ‘6298c3ff’ (“v1.0.0”), dated May 1^{st}, 2019, which is the first
        release that included the inferiors mechanism.  An error is returned
        when attempting to navigate to older commits.

             Note: Although it should technically be possible to travel to such
             an old commit, 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.

        
https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-time_002dmachine


However, it appears to me hard to maintain a list of all the known
time-trap.  For now, we are not re-building the past, therefore most of
the time-trap get unnoticed.

About CPU microarchitecture, I know only two: Python [3] and OpenBLAS
[4].

All in all we are at the infancy of this work and any help is
welcome. :-)

Cheers,
simon


3: Try “guix time-machine --commit=v1.0.0 -- describe”

4: Investigating a reproducibility failure
Konrad Hinsen <konrad.hinsen@fastmail.net>
Tue, 01 Feb 2022 15:05:40 +0100
id:m1a6fahebv.fsf@fastmail.net
https://lists.gnu.org/archive/html/guix-devel/2022-02
https://yhetil.org/guix/m1a6fahebv.fsf@fastmail.net

Follow-up:
Re: Investigating a reproducibility failure
zimoun <zimon.toutoune@gmail.com>
Wed, 02 Feb 2022 21:35:06 +0100
id:871r0l9fd1.fsf@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2022-02
https://yhetil.org/guix/871r0l9fd1.fsf@gmail.com