From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id CDezF52LAWY5kQAA62LTzQ:P1 (envelope-from ) for ; Mon, 25 Mar 2024 15:35:09 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id CDezF52LAWY5kQAA62LTzQ (envelope-from ) for ; Mon, 25 Mar 2024 15:35:09 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=cyberdimension.org header.s=dkim header.b="tb1/y4fV"; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1711377309; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=O52R2jDJ/Xi/QtLqi4aThf8ExwDQgVloE5C3WCjhIMg=; b=YaGprQVhcQdTp4hixfxSX8ii9KB4BSTcmcUgXoXEAgTBeDAJEQMdhgL3Xia1Z6LIqD4WOA n1ue03ZQuHe3QnFH0g28VxR+hx9YRaOE5LOLvAAUAICwgbr4YLW59GfIdSuYyRmVtfS2pj UuADv1U/XOW/69/wlFtueyxya8wSZQ5pXmg3vR004Y0uPuoeA/lUk2zEQUYBM9vpKAtJbX 1fAbrLp6mWtD6Kz3zbYglFClvwk4nNot+vWnGblZDhE26bq7XhF+IlL0IwfOzxbRL1podK THpUmO52PXo1JQcshMNo1hytFxRZJVtL8fSS0NhoWJ5cRz/FmikE/TEwQoP8WA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=cyberdimension.org header.s=dkim header.b="tb1/y4fV"; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1711377309; a=rsa-sha256; cv=none; b=BEMDEzeare9xXDN4sld4NWLrvBsI0NNElUI7A2RiALitl847zkkj8ubYYNgIok2YJvaFmD +djWIsub97LCFHGEpSCfP7y0pyIvMfWSGEZ8+blHiDkEDJSGu2VipTfivn2FRlJ6yDCByo aY/bkbzbp5DviR8mAurNjI2vSv8RTN2Bj7hfy8Ln4VNjODO0kTi2nxSdNT9bcawD3GUK8A kIUU9EHPzguelOtYx+Tgs9VMKB9fy9HeDVbNCMmkrR5ims81BhzW8lqQKOhucmkUvTflVa T1+/U82oQ+y28gN+IOgMEh9hPz8697LRSydAoldwTsRdckre0h7vGReW5e7JKg== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0A5A36BD11 for ; Mon, 25 Mar 2024 15:35:09 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rolPH-0001Zp-Eo; Mon, 25 Mar 2024 10:34:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rolPF-0001Zh-7p for help-guix@gnu.org; Mon, 25 Mar 2024 10:34:33 -0400 Received: from cyberdimension.org ([80.67.179.20] helo=gnutoo.cyberdimension.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rolPB-0000pm-T9; Mon, 25 Mar 2024 10:34:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=dkim; bh=sIrKTHNP08yw06a Pf/8jfu//ji9meKKuYUPVj6qG+60=; h=references:in-reply-to:subject:cc:to: from:date; d=cyberdimension.org; b=tb1/y4fVl6mm4E1YSvqOdhDvS2i1h+evRuq ed3HzXcO7FrYj3guTtiZnHNaaA4+QNqrfTTNw2c4fcFx0nbiGeaoIzytoHBa/Ln+qi2gS/ 5zrZgXWa+17jLwyX3YIih8hM0LzIBkRU70LGsq1k9ll7u0LJ4wgTHKtFHt7NQzOKbC/htG Xe4DLi7HYm4Y5k3j9+a6wO8gx663UgpvgVF7Im1fjC2kdyGN5rcOWkWS04bXJeqkboaQ+C gkBd2YwiwwOf7kYMscsfSrIbrGewr80+S+83QwevAxBepG+lOyOoDPlvgFnx7FRCnO5Mub 0DA1X9zASmYivXdX6pycWHN5MoA== Received: from primary_laptop (localhost [::1]) by gnutoo.cyberdimension.org (OpenSMTPD) with ESMTP id 9d04959a; Mon, 25 Mar 2024 14:34:20 +0000 (UTC) Date: Mon, 25 Mar 2024 01:26:53 +0100 From: Denis 'GNUtoo' Carikli To: "pelzflorian (Florian Pelz)" Cc: help-guix@gnu.org, Adrien 'neox' Bourmault Subject: Re: Guix as a non-optional dependency in another project, and Guix resources requirements. Message-ID: <20240325012653.4ad16320@primary_laptop> In-Reply-To: <87il1eeibw.fsf@pelzflorian.de> References: <20240316020307.6bf7335c@primary_laptop> <87y1ad6qwa.fsf@pelzflorian.de> <20240322015224.6e7e92cf@primary_laptop> <87il1eeibw.fsf@pelzflorian.de> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.37; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/TZ/JMVRqIcm0Pkv2FW8pfUW"; protocol="application/pgp-signature"; micalg=pgp-sha256 Received-SPF: pass client-ip=80.67.179.20; envelope-from=GNUtoo@cyberdimension.org; helo=gnutoo.cyberdimension.org X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: help-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Queue-Id: 0A5A36BD11 X-Spam-Score: -6.94 X-Migadu-Spam-Score: -6.94 X-Migadu-Scanner: mx11.migadu.com X-TUID: yD/fCcSMG33w --Sig_/TZ/JMVRqIcm0Pkv2FW8pfUW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Guix integration: -------------------- On Fri, 22 Mar 2024 10:17:39 +0100 "pelzflorian (Florian Pelz)" 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.=20 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=3D 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.=20 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=3DN', '--max-jobs=3DN'), 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 =E2=80=9CGNU 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.=E2=80=9D 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. --Sig_/TZ/JMVRqIcm0Pkv2FW8pfUW Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAmYAxM0ACgkQX138wUF3 4mNmvw/+Pz+qvTb5k2qt2iKa9/H4RfO+OitLQEaWy6T494Oxsiwr2lE+f2gwXkkK xdx8A4HuBtoCWY2eU3C7cCxe3V59Kv+cLnDQx7aKQtjqymyBnbpLW+XtaM2Fi8yx kbxIkYqscrEJjVzS8VADWFMHNZa/x3MDop3/kEAAi3UdPP4ZSaCyppmD0QLP7xa4 HjjhevEaafx7pO79cieYdsg8lB2aq9n+WOgdaNZTvDVjghGx/NUHhfMC6LRCRjNF v2RWFCxOx01yJdCLm1s3x//BWndP+7XwpbeFjt7fPJFwm77/MVAXw+9TU0xWMhI9 XAEjt8xGcdqEm6USBTvzDFGlVgs7Ce4hgC1eYk0+h4x8EY5+pJHTNg7/IRi2AIRT t9Hlx8AeUREmdaoltpKwNN6uTpzlTG4Upy8vribpUaeg2wi2FGLcW6IfLGpoRFwS kyimshGqS9A5yyB8yoVuEYDGBPHXBqAv6mF2pWdEuowBwGh6NMn96kdUoUMVTJYg dPX/0NTOZDrzwUlJSG8Z1dd5UXUzpN57ZZM7HPWfYHtpcIpgtvyvQWwYdn0VQgj7 j70hkV5mEj6421R8ZNDarqso6hnifPhieKedLhejGq5mxuucM255B67+zwWRcqfi AmoBpjXN7sxDHagRFYI9/BDNd+1UxdHQX5MQXseJppN0J99jQmE= =Vebt -----END PGP SIGNATURE----- --Sig_/TZ/JMVRqIcm0Pkv2FW8pfUW--