On Guix integration: -------------------- On Fri, 22 Mar 2024 10:17:39 +0100 "pelzflorian (Florian Pelz)" <pelzflor...@pelzflorian.de> wrote: > Side note, as an observer from outside, it also seems relevant how the > project goal is different from Canoeboot. Is the difference that GNU > Boot seeks to integrate more with FSDG distros like Guix? Right now our goal is more to work with upstream Guix to add packages in Guix for what we need, and then use these packages to build the images that we distribute in ftp.gnu.org/gnu/gnuboot.
We already added grub-coreboot in Guix but we need to add more (at least seabios-coreboot, and the Coreboot memtest86+, and Coreboot itself if possible). Since both GNU Boot maintainers are also Guix users, it also enable us to collaborate with Guix by sending patches and through that somewhat share the maintenance with Guix of a very small number of packages. GNU Boot is also based on an older version of the Libreboot build system that does everything with shell scripts, and we already adapted it to be able to easily replace build commands (./configure, make) by 'guix shell' commands. Since writing Guix packages is relatively easy and that Guix is well documented, if contributors can use 'guix build', then the rest is pretty straightforward and they can learn it step by step, by looking at examples, asking other GNU Boot or Guix contributors for help, etc. So this is why the integration of Guix as a dependency in GNU Boot is something really crucial and that it has to be done right: we don't want to loose contributors because there is too much setup, or because our automatic way to install and update Guix fails. What you suggested could indeed be the way to go: replace the code to at least install and configure Guix with a pointer to the installation section of the official Guix manual, and improve it along the way if we need to (by mentioning more distro packages for instance). This should take care of the substitutes configuration issue. But then we would still like to somehow make guix time-machine --commit=<hash> work automatically, so we need to somehow fetch that revision, and if possible without touching the current guix revision not to mess up the system of people that also use Guix for other things. For that we probably need to add an option to guix pull and upstream that. Since that could take some time, we could start by detecting if the revision we need is not there and in that case at the same time point users to the Guix manual to run guix pull, and warn about the issue of changing guix revision, store the older guix revision in a well known place and provide instructions to restore it. As for supporting various guix build options (like '-c, --cores=N', '--max-jobs=N'), we could probably make that configurable in GNU Boot with the help of autotools. > Guix also supports i686 more or less; it will not be dropped, so > memory use can be trusted to not be more than i686 can do. That's a good point. Once we build all our software with Guix, doing that would also enable building on i686 for free[1]. Answers to your other questions: -------------------------------- Another key difference with Canoeboot is that we also want to work directly with various upstream projects like GRUB or Coreboot to make sure we can keep maintaining the same devices over time. This decision also probably aligns well with Guix goals as having too much extra patch can be a burden to maintain and many distributions have formal or informal policies to limit that to the strict minimum. There are probably other differences as well (website build system, etc) but they might not be very relevant to the use of Guix has a mandatory dependency. Also note that GNU Boot is still pretty new (and doesn't even have an official release yet) so over time there might be more technical differences. > Leah takes it personal, but on the Canoeboot FAQ, I find “GNU Boot > does support downloading, deblobbing and re-compressing U-Boot > archives, and in fact does a better job of *that* than Canoeboot in > some ways, but it does not yet actually build U-Boot, and it does not > boot U-Boot in any way, on any actual mainboards.” If I understood right, Canoeboot dropped that functionality, and it's still in the code of GNU Boot, but I wouldn't rely on that until GNU Boot starts releasing deblobbed u-boot archives or that it's integrated upstream in Guix in some form. References: ----------- [1]The FSDG distributions versions mentioned in the build documentation (https://www.gnu.org/software/gnuboot/web/docs/build/) do not support i686. Using Guix would fix that. All that is because we want to continue supporting the KGPE-D16 (that Guix also uses for its infrastructure), and that right now we use an older Coreboot revision for it, which requires older compiler revisions. We have plans for re-upstreaming this mainboard in Coreboot in a sustainable way (so it doesn't get dropped again) but in the future we might need help to complete that task that either with coding (we might be able to provide reverse engineered documentation to write maintainable code) or funding. Denis.
pgpPMK9QiB4q1.pgp
Description: OpenPGP digital signature
