mbox series

[bug#69343,v2,00/12] Simplify bootloader data structures and procedures

Message ID cover.1709885528.git.lilah@lunabee.space
Headers
Series Simplify bootloader data structures and procedures |

Message

Lilah Tascheter March 8, 2024, 8:11 a.m. UTC 
hey!

this is really useful!! love having access to generation numbers alongside
boot params, and the terminology fixing's great too :)

noticed a few problems - took the liberty to fix them in this v2 patch series:
* (gnu system boot) was missing a few imports that it needs to work.
* (gnu system boot) requires the procedure system-linux-image-file-name, which
  is defined in (gnu system). I moved it over to (gnu system boot).
* generation->boot-alternative in (guix scripts system) had typos in variables
  resulting in them not being used.
* commit messages didn't have relevant gnu changelog info.
* one of those commit messages had a wholeass log that's Way too much extraneous
  information and just got in the way when trying to look at the actual patch

this v2 passes all relevant unit tests, but could still definately use some
verification that the modified paths function properly before I'd say this is
ready to be merged. notably, system reconfigure and ssh managed machine
reconfigure should be verified, but then it should be good?

thanks ya!!

- lilah

Felix Lechner (12):
  Fix bug where the extra menu entries for a bootloader were shown
    twice.
  Move <boot-parameters> record to a separate file.
  Also move boot-parameters->menu-entry.
  Rename seconds->string procedure to epoch->date-string.
  Move epoch->date-string to gnu/system/boot.scm and use it elsewhere.
  Offer a uniform decorated-boot-label and use it.
  Rename boot-parameters to boot-alternatives when appropriate.
  Rename two remote variables confusingly named 'generations'.
  Give a separate name to a commonly used expression.
  Simplify profile->boot-alternatives.
  Split generation->boot-parameters out of profile->boot-alternatives.
  Encapsulate <boot-parameters> to retain generation, system-path and
    epoch.

 gnu/machine/ssh.scm       |  74 ++++----
 gnu/system.scm            | 264 +---------------------------
 gnu/system/boot.scm       | 354 ++++++++++++++++++++++++++++++++++++++
 guix/scripts/system.scm   |  71 ++++----
 tests/boot-parameters.scm |   1 +
 5 files changed, 430 insertions(+), 334 deletions(-)
 create mode 100644 gnu/system/boot.scm


base-commit: 9038a46751c5090246e64b63ff752064833c435b

Comments

Felix Lechner March 8, 2024, 4:33 p.m. UTC | #1 
Hi Lilah,

On Fri, Mar 08 2024, Lilah Tascheter wrote:

> this is really useful!! love having access to generation numbers
> alongside boot params, and the terminology fixing's great too :)

Thank you for taking a closer look! Sorry I did not get back to you on
the system-path question before. Of course, you were right.

If you will please accept an excuse for my tardiness: My family has a
new sister. Time passes when a baby cries.

> * (gnu system boot) was missing a few imports that it needs to work.

I regularly notice missing imports, too, but haven't figured out when
they present an obstacle to running a Guile program.

> * (gnu system boot) requires the procedure
> system-linux-image-file-name, which is defined in (gnu system). I
> moved it over to (gnu system boot).

Thanks for doing that! Now you and I are co-conspirators in re-arranging
the procedures.

> * generation->boot-alternative in (guix scripts system) had typos in
> variables resulting in them not being used.

Thank you for finding those. I have poor vision and am not good with
details, including speling.

> * commit messages didn't have relevant gnu changelog info.

Yes, I will read the GNU ChangeLog spec one more time, but all hope may
be lost.

> * one of those commit messages had a wholeass log that's Way too much
> extraneous information and just got in the way

My commit messages are widely regarded as wordy, roundabout and overly
documentative.

> this v2 passes all relevant unit tests, but could still definately use some
> verification that the modified paths function properly before I'd say this is
> ready to be merged.

I use 'guix deploy' and will test your patch series shortly. (Despite
the previous shortcomings, I have been using it in production.) My
branch rebase is overdue.

Unfortunately, I have many custom patches, including some affecting core
packages. A branch rebase locally causes a full bootstrap and takes
about two days.

Given your attention here, I am sure your changes are fine. Folks should
feel free to merge your work before I return with confirmation. Thanks!

Kind regards
Felix