On Mon, 25 Mar 2024 18:34:18 +0100 "pelzflorian (Florian Pelz)" <pelzflor...@pelzflorian.de> wrote:
> Hello, what you intend does sound very interesting. As for “guix > time-machine”, I do not see the problem [...] Let's say a user install Guix 1.4.0 and GNU Boot use a guix commit after v1.4.0, as I understand guix time-machine will fail. Here we have code to detect that situation already, the issue is more what to do when this situation happens. A second problem is if a user install guix and runs guix pull right after but doesn't run guix pull again, and that in the future we start using commits/revisions newer than the ones the user had right after running guix pull. Especially in the second case, running an additional 'guix pull' behind the back of the user can have some bad consequences if the user is also using Guix for other things and for some reasons didn't plan to update guix yet. So my current plan is just to detect that the commit is not there and tell the user to run guix pull and also give the user a way to restore the old guix revision afterward if needed. It's not ideal but it could work right now for all use cases. > Simplifying install docs is being discussed and we would like more > feedback: > > https://issues.guix.gnu.org/69977 > > At the same time, me citing the Arch Wiki’s negative stance on > distros’ guix packages > <https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00068.html> > and the dealing with the recent Guix local privilege escalation > vulnerability > <https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00238.html> > hopefully will not cost us our Debian package. Thanks, I'll read all these threads. > > 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. > > I do not know, but maybe the Autotools of Guix itself use something > like this to deal with “make -j4”. My question was more about the user interface and if it was the right thing to do. As for the code implementing it[1], it was pretty easy to do for me and it integrates fine with the current GNU Boot structure: if users run './autogen.sh && ./configure' they can still use the scripts manually, so this avoids too much invasive changes. I still need to do some cleanups though and complete that work (as some things are still missing, like handling 'guix pull' to make sure that guix-time-machine works). [1]https://git.savannah.gnu.org/cgit/gnuboot.git/log/?h=GNUtoo/guix-configure > I’m looking forward to reading much of the info you gave in this mail > on a GNU Boot website, or if the info is there already I just missed > it. The issue is that there is a chicken and egg issue as for the code/documentation to be merged in GNU Boot, we need to figure out the questions I asked in this thread. And there is also a second chicken and egg: we don't want to add a dependency on Guix without a real use case that really requires Guix in some non-optional way (more on that below). As for the code that is actually merged, building the GNU Boot website can be done with guix shell but to do that the user needs to pass --enable-guix to the ./configure in that directory: https://git.savannah.gnu.org/cgit/gnuboot.git/tree/website-build We used Guix shell here because it makes Guix optional, so we didn't need to have the Guix part being ultra robust/polished/documented. If it worked for users already familiar with Guix, it was good enough. And we also already merged code to update Guix: https://git.savannah.gnu.org/cgit/gnuboot.git/tree/resources/dependencies/guix https://git.savannah.gnu.org/cgit/gnuboot.git/tree/resources/scripts/misc/guix.sh but this is not run automatically, and not mentioned in the documentation either. So users that know about it could run it manually but that's pretty much it. So in the meantime the code/documentation we have on Guix non-optional integration in GNU Boot is available in various branches as it is not ready yet. And we don't want to make Guix non-optional for the website right now, as it works fine in the way it is. And the idea is to try to integrate Guix as a required dependency with the least amount of changes. So it will probably be done to build some tools first like with this branch: https://git.savannah.gnu.org/cgit/gnuboot.git/log/?h=GNUtoo/guix-configure This kind of changes really makes sense as it would enable us to fix some installation instructions for some devices which would make the first release closer, and it limits the risk of breakages since it doesn't modify in any way the binaries to install. As for deeper integration that can build GRUB with Guix, it can be found here: https://git.savannah.gnu.org/cgit/gnuboot.git/log/?h=GNUtoo/guix Note that this branch is older and will probably be rebased / cleaned up much later (probably after the release). To get there we converted the Libreboot directory structures to resemble more packages with tasks[2], and that is merged already. So that enables us to then just remove the shell commands that build grub and replace that with a call to guix build and keep the rest of the shell commands that reuses the output. [2]https://git.savannah.gnu.org/cgit/gnuboot.git/commit/?id=857afa42a8ade870115391b09d712b110e6a1066 It's done in this commit for instance: https://git.savannah.gnu.org/cgit/gnuboot.git/commit/?h=GNUtoo/guix&id=f96d93160d6c29cb45b999c56f03ec8a4312140d But as explained before, this commit need to be rebased, split, cleaned up, etc. For instance it was made at a time where grub-coreboot wasn't in Guix yet, so now we can simply use the upstream package instead. Denis.
pgpjPp8qmqsms.pgp
Description: OpenPGP digital signature