Re: Guix integration and various other patches.

[Denis 'GNUtoo' Carikli]

On Sat, 20 Apr 2024 00:57:50 +0100
Leah Rowe <info@minifree.org> wrote:
> btw coreboot has bucts under util/ now. i haven't checked whether you
> use theirs or the old one still. the coreboot one is much more heavily
> developed than the old stuge.se one.
I used the Coreboot one.

> also, regarding flashrom: you may wish to use flashprog instead, in
> gnuboot. libreboot has done this (flashprog is a fork of flashrom) for
> the reasons written here:
I'm aware of flashprog, and even of its release and I plan to switch to
it later on, mainly because (1) it works better on I945 and (2)
it's closer to flashrom 1.2 than newer flashrom, so it means less to
keep the patch we use working, but at the end of the day I tested the
patch on flashrom 1.2 at a time where flashprog wasn't released yet, so
I kept flashrom 1.2 for now.

> what of my patch set that i sent in january? i fixed a lot of major
> issues, including critical build issues, making your gnuboot build on
> the latest distros. also the grub luks2 stuff.
This patch set contains one of your patch, and the cover letter also
mentions that.

Now I had personal issues to take care of, so I was away during ~1
month, and had less time before that, and I could not look at all the
patches.

And anyway of the issue is that there are too much patches (you sent 3
series almost at the same time), and usually some projects like Linux
don't even reply and/or complain, but don't look at the patches anyway,
but at the same time the good side of your approach is that the most
interesting patches are not in the first serie you sent but in the next
serie, especially that helps to improve the documentation, so these are
being looked at first.

Updating GRUB 2 is also useful, and I've also patches (in branches) to
do that through Guix, but it might be better to merge your patch before
as that minimize the amount of changes.

As we already discussed on this mailing list, we don't want to maintain
too much extra patches that are not upstream, so that prevents
merging some of your patches. Which ones are obvious (it's the ones
with extra patches that can't easily be removed).

In addition we want to minimize as much as possible the probability of
breakage and add-in automatic testing as soon as possible, so both also
affect the order in which patches are being merged.

For instance if we merge code to test the qemu image with qemu before
updating GRUB, then we can test for regressions with the tests, hence
the delay with that patch.

And this is exactly why I tried to add a qemu image as soon as
possible, but right now we don't have automatic tests with qemu yet,
though I know exactly how to add simple tests for that.

And as you could see, this patch set adds things that don't affect the
existing images, so the risk of breakage is low here.

Denis.

pgppqCwYPC90h.pgp
Description: OpenPGP digital signature