unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludovic.courtes@inria.fr>
To: Suhail <suhail@bayesians.ca>
Cc: 68677@debbugs.gnu.org
Subject: [bug#68677] [PATCH 0/6] Service for "virtual build machines"
Date: Wed, 07 Feb 2024 18:33:50 +0100	[thread overview]
Message-ID: <87jzng41s1.fsf@gnu.org> (raw)
In-Reply-To: <87y1bygbjp.fsf@> (suhail@bayesians.ca's message of "Mon, 05 Feb 2024 15:45:18 +0000")

Hi Suhail,

Suhail <suhail@bayesians.ca> skribis:

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

What this patch adds is a service one can use on Guix System.  Someone
who adds this service to their Guix System config can then run ‘herd
start build-vm’ to enable offloading to the virtual build machine.

It’s possible to do something similar on a distro other than Guix System
but this patch series won’t help with that.  On another distro, one
would need to create a VM image and then manually start QEMU with the
right flags and set up offloading to that VM.  Nothing insurmountable,
but it’s quite tedious.

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

I picked a date in the past because I figured this would be the most
common use case at first: being able to rebuild things “in the past”
(the manual says that the default date is “in the past”).  Apart from
that, it has no significance.  I’ll add a comment as you suggest.

The manual cannot really say which date “won’t work” because (1) it
depends on what one is building, and (2) we simply don’t know in most
cases.

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

Yes, I agree we need complete examples (maybe not in the manual, rather
as blog posts and/or Cookbook entries I’d say).

Thanks for chiming in!

Ludo’.




  reply	other threads:[~2024-02-07 17:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-23 16:46 [bug#68677] [PATCH 0/6] Service for "virtual build machines" Ludovic Courtès
2024-01-23 16:48 ` [bug#68677] [PATCH 1/6] services: secret-service: Make the endpoint configurable Ludovic Courtès
2024-01-23 16:48 ` [bug#68677] [PATCH 2/6] vm: Add ‘date’ field to <virtual-machine> Ludovic Courtès
2024-01-23 16:48 ` [bug#68677] [PATCH 3/6] vm: Export <virtual-machine> accessors Ludovic Courtès
2024-01-23 16:48 ` [bug#68677] [PATCH 4/6] vm: Add ‘cpu-count’ field to <virtual-machine> Ludovic Courtès
2024-01-23 16:48 ` [bug#68677] [PATCH 5/6] marionette: Add #:peek? to ‘wait-for-tcp-port?’ Ludovic Courtès
2024-01-23 16:48 ` [bug#68677] [PATCH 6/6] services: Add ‘virtual-build-machine’ service Ludovic Courtès
2024-01-25 14:18 ` [bug#68677] [PATCH 0/6] Service for "virtual build machines" Simon Tournier
2024-01-29 11:25   ` Ludovic Courtès
2024-02-05 13:37 ` Ludovic Courtès
2024-02-05 15:45 ` Suhail via Guix-patches via
2024-02-07 17:33   ` Ludovic Courtès [this message]
2024-02-14 15:15   ` Simon Tournier
2024-02-10 22:35 ` bug#68677: " Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87jzng41s1.fsf@gnu.org \
    --to=ludovic.courtes@inria.fr \
    --cc=68677@debbugs.gnu.org \
    --cc=suhail@bayesians.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).