From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id iCbyJx0vC2bU/QAAqHPOHw:P1 (envelope-from ) for ; Tue, 02 Apr 2024 00:03:09 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id iCbyJx0vC2bU/QAAqHPOHw (envelope-from ) for ; Tue, 02 Apr 2024 00:03:09 +0200 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=XP6PmyeA; 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=1712008989; 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=Pk5ZFVdasAGgUyRY7A5xD5aN6LUceqq5QODXGX+y4Eg=; b=GiWscGmKuYwSxdkCVw2xgy4bynxr87j+6dqiDVn4dA4hn8M0c0i3ITl9uQNMu4PXUWB/c0 tPdvFR9KU6vNb+uieWBOLQdpGkXHuCtBQGPFjObQNEYOgyYWu8JKIPpl++aCs3emxREUSq 0PT2SzOmCFLDz2gBDWsb2zYJVig6rs9NDfaGX26FgzNS0Ryiih+2+O3ESIQE/TuIbwE9yk CMYbR4JQQfCiwFQ1hwtUQfVl+hLSoM8uagVPTwPpat0R/qjf4fKMiRJOuJ7EUy+oSxQoMN fKiJPV+h4ZoZWjNBUC8j3tnLjPBK4uxT0MyhIMPFo3GZcv3SzetjkB3bW+3cgA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=cyberdimension.org header.s=dkim header.b=XP6PmyeA; 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=1712008989; a=rsa-sha256; cv=none; b=FrZUr9yi1gOdQ353Ycq0quaAqS+3xmSwFjAmRaWm+2rSuwjsGHT8eru7m3rmSUOi0SU2yy mpQaJSNw3sMJhrJ3xrMLOHzuESSlX1l4wEc+mkr2j/UJZm4uUSouGlnE1tCmpBgBRN1D9A Q5qvq0V47ahzyav/FJianW79BJh4Mq55CauSKproH3OiL48nigTHPAOw4+XLy2SYJU8qVf 2MxJgvZmOujrms85amA8XCHk2CpYU4PvJ/wZd6djFfintO80VWkbG3lMylB6Eyj2zExSki TwMIvx9SiEPP31QvAbKOcUbXzJ2DTS6F4MaawUvxV6H8dV2yF7O6ugIKNYpXGw== 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 E093B72294 for ; Tue, 2 Apr 2024 00:03:08 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rrPji-00018L-83; Mon, 01 Apr 2024 18:02:38 -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 1rrPjc-00016E-6K for help-guix@gnu.org; Mon, 01 Apr 2024 18:02:32 -0400 Received: from cyberdimension.org ([79.143.250.36] helo=localhost) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1rrPjZ-0000D2-OX; Mon, 01 Apr 2024 18:02:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=dkim; bh=Mi34lhBw48/FMoW W/w9aLzCqT1Y2zZV3TmS3OK5uLw0=; h=references:in-reply-to:subject:cc:to: from:date; d=cyberdimension.org; b=XP6PmyeAAigMxNDMp4dvI4aD76s4MsEaG4P 2mLyb9XxQUiARfbv0MA3E9sa7JDUyY8563S3UNFQDufoZR7qlS14qvxSvlOTo7nK+3PmEy A0CSKIhzN/Wuq2BMeBmraEGKflsw2LAKqLvllI3bzjxu2N5EMSe3DDkDuWrrUM8zPKEgEz 2AFHsnMSq7dOBQJQ67aCSwnX5rU7VW6zpeoN52Uqgxv7zOOl6Sdyy+56YYp8JxeBBLuSDQ Ka9Ed+sSaDoYQpXjFrFCOy5XC1ZtQXNa2pOeNPhq2qEsDRvVc9g3wiZe7r3DCTR37E229Z k1sZBSrbQ6tWgOfyU8p/3e8qIUw== Received: from primary_laptop (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 7ef1d8d9; Mon, 1 Apr 2024 22:02:16 +0000 (UTC) Date: Tue, 2 Apr 2024 00:02:03 +0200 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: <20240402000203.5a39092a@primary_laptop> In-Reply-To: <87v857kjgf.fsf@pelzflorian.de> References: <20240316020307.6bf7335c@primary_laptop> <87y1ad6qwa.fsf@pelzflorian.de> <20240322015224.6e7e92cf@primary_laptop> <87il1eeibw.fsf@pelzflorian.de> <20240325012653.4ad16320@primary_laptop> <87y1a6md0l.fsf@pelzflorian.de> <20240327022847.7b3376b9@primary_laptop> <87v857kjgf.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_/IZsQujO1BnZbWEp6x_XXTMU"; protocol="application/pgp-signature"; micalg=pgp-sha256 Received-SPF: pass client-ip=79.143.250.36; envelope-from=GNUtoo@cyberdimension.org; helo=localhost X-Spam_score_int: 17 X-Spam_score: 1.7 X-Spam_bar: + X-Spam_report: (1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FSL_HELO_NON_FQDN_1=0.001, HELO_LOCALHOST=3.828, 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: E093B72294 X-Spam-Score: -6.95 X-Migadu-Spam-Score: -6.95 X-Migadu-Scanner: mx10.migadu.com X-TUID: Zirk4+F1tVBA --Sig_/IZsQujO1BnZbWEp6x_XXTMU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 27 Mar 2024 12:22:40 +0100 "pelzflorian (Florian Pelz)" wrote: > Hi there. [...] Hi > Denis 'GNUtoo' Carikli writes: > > On Mon, 25 Mar 2024 18:34:18 +0100 > > "pelzflorian (Florian Pelz)" wrote: =20 > >> Hello, what you intend does sound very interesting. As for =E2=80=9Cg= uix > >> time-machine=E2=80=9D, I do not see the problem [...] =20 > > 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. =20 >=20 > No, it does not fail. Thanks a lot, this is very interesting as it could simplify a lot the code. In addition running guix time-machine doesn't modify the current Guix version so it's not invasive. I recall that when I tried it on older versions of Guix, it did fail, but maybe more recent versions don't fail anymore. I'd need to do more tests with that to understand when it fails or doesn't fail and somehow get/require the right conditions and then remove all the code that isn't needed anymore. > >> I do not know, but maybe the Autotools of Guix itself use something > >> like this to deal with =E2=80=9Cmake -j4=E2=80=9D. =20 > > 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. =20 >=20 > So from reading the Guix build machinery, Makefile.am runs >=20 > https://git.savannah.gnu.org/cgit/guix.git/plain/build-aux/compile-all.scm >=20 > and they use (getenv "MAKEFLAGS") to check if make gets any > --jobserver flag that specifies the number of parallel compilations. > This seems slightly nicer than a non-standard configure option, but > is also more complicated in that Makefile.am calls out to > compile-all.scm to do the work. Thanks for that information. This could make things work out of the box without more configuration. Though I still need to think about that one as the code is much harder to understand than with configuration options. > Why do you need so many different Guix versions? Are there > regressions or is it just that you have tried building different > parts of Libreboot with different versions of Guix? We don't necessarily need multiple Guix versions but I think it fits better in the current design if we allow that. The old structure of Libreboot we inherited was converted to look more like packages. Now each "package" has a directory in resources/packages/ like resources/packages/grub for instance. And inside the package directory there are shell scripts with specific names like download, build that are tasks. Because of that it makes sense to treat each "package" separately and allow the use of different Guix versions. So practically speaking if I want to replace the code that builds SeaBIOS with shell scripts I could first write a local guix seabios-coreboot package that I add inside resources/packages/seabios/seabios.scm and call guix build inside resources/packages/seabios/payload (which builds SeaBIOS for Coreboot). At this point I could use Guix 1.4.0 if there are no security issues in SeaBIOS or its dependencies for Guix 1.4.0. But once seabios-coreboot is upstreamed in Guix it would make sense to get rid of resources/packages/seabios/seabios.scm completely if possible (if we use the same build options, don't have extra patches, etc) and instead update the shell script that calls guix build to use the Guix version where seabios-coreboot was added. Thanks to that it's easier to update each package without affecting the rest. When everything will have been converted to use Guix packages we would need to think again if using a single Guix revision could make sense or not depending on the amount of risk of breakages. The main advantage of a single revision would be to have way faster builds. > That is, you move Libreboot=E2=80=99s build system stepwise towards using= guix > build instead. Sounds good from outside; I have not perused all the > links throughly. It is very interesting, though. The main rationale behind that is to have at any point something that still works. Using Guix just for specific packages like GRUB enable to test the resulting images like with any other changes, and also consistently update the documentation along the way and so on. We can even write some automatic tests that work with images made before Guix is integrated and after without needing any special consideration. And finally it also lowers a lot the odds of having never-ending work to do the conversion, and never finishing nor making any releases, especially because some of the tasks (like building Coreboot) are not trivial (it requires an ada compiler and Guix doesn't have one yet). And all that also makes it easier to collaborate with upstream as we don't need to rush to convert everything to Guix packages, so it leaves time to upstream things. Denis. --Sig_/IZsQujO1BnZbWEp6x_XXTMU Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAmYLLtsACgkQX138wUF3 4mO4jQ/9FCS2P0kb444E+qHMA6f16yUdQoyLF/2iOmVbxOLFADiIZYOky7we1iqU h6nuJK+Vifw26J/ZXwEx5Wy8zG2R2fvSdyuRY97kKu8lDlJHA3BUBupv2HA8iW43 RU4NNljBXUe6wgVIX5UXGH9FWve0dx4YWyqaASGHdW05Hriyn7BTirHJbUZbDipN ez+mCG+sFbnN9KLnTvnbpfQQhmc0KUuHc4kzlW0Wf3ar4AkYMGE3e5ucWg0+SA24 PRqb37PitaCdSf6/vYIxVemR+ZXPgh3LGubw05Z271BoD4KVrI225BeJzI5tXMMV dI0HfQtO+5mTAbtyGgNQ4UH7WVxaXwlvPDlMIurn3hOu0mBRVA+G3nZddnrCBx1H 83bqPaiNicZii9udo8E0JP5NKfll1xlisf0N3z/u+h/s4BnbS3uBjen1PLaDsqU9 0q9GR4e1doD+weNIZdG00JJr7oWkLjm+HJMaCT2jTziKv65iuLPNe+ubZqa2z8qx LcAhmYsvjc6a0tN2rbB+j7K9ZLkojK6WfvOgtq0nQ4mrvr51XQxxO8eVmrIgbrR4 mrJPThDHODlB1mrbPzg1nXKFdJ3fInzGTFKFHJkIo9gHAtZp0GUQn6bhiwBMZDyf sV1yosFSpR7Y9h5g4jH7Snp8AaAxeplYMDOjei9apj4hVnpRm5Y= =fBR3 -----END PGP SIGNATURE----- --Sig_/IZsQujO1BnZbWEp6x_XXTMU--