* Guix 1.4.0+i686: getting ghc substitutes? @ 2024-10-18 20:26 Denis 'GNUtoo' Carikli 2024-10-24 14:32 ` Denis 'GNUtoo' Carikli 0 siblings, 1 reply; 4+ messages in thread From: Denis 'GNUtoo' Carikli @ 2024-10-18 20:26 UTC (permalink / raw) To: help-guix, Adrien 'neox' Bourmault, Jason Self [-- Attachment #1: Type: text/plain, Size: 1432 bytes --] Hi, In GNU Boot we use Guix 1.4.0 instead of the latest revision because we can easily point to the 1.4.0 manual and we don't need to update our code following Guix changes. We also use i686 (--system=i686-linux) to enable to build GNU Boot on all the computers we support. Until now that worked fine but we then hit an issue that we cannot solve on our own. We also want to use Guix 1.4.0 + --system=i686-linux for building our website as well and this requires pandoc, which in turn requires ghc. However even if ghc builds fine for i686, it takes a very long time to build (more than 1 night of compilation on a ThinkPad X200). Building on a way faster computer (a KGPE-D16) doesn't make things much faster. Part of the issue is because tests are very long to run, and another part is that we have ghc -> ghc@8.6 -> ghc@8.4 -> ghc@8.0 -> ghc@7. Disabling tests makes the build an order of magnitude faster, but we still have multiple hours just for building ghc, so it's not good enough just to get pandoc to build a website. Would it be possible to somehow trigger a build on one of the default substitute server to fix this issue? If not we could simply change the Guix revision and somehow publish the corresponding manual as well, but using a release probably makes things much easier for contributors. Not using Guix by default for building the website is also an option. Denis. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Guix 1.4.0+i686: getting ghc substitutes? 2024-10-18 20:26 Guix 1.4.0+i686: getting ghc substitutes? Denis 'GNUtoo' Carikli @ 2024-10-24 14:32 ` Denis 'GNUtoo' Carikli 2024-10-25 9:17 ` Andreas Enge 0 siblings, 1 reply; 4+ messages in thread From: Denis 'GNUtoo' Carikli @ 2024-10-24 14:32 UTC (permalink / raw) To: help-guix, Adrien 'neox' Bourmault, Jason Self [-- Attachment #1: Type: text/plain, Size: 2064 bytes --] Hi, On Fri, 18 Oct 2024 22:26:05 +0200 Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote: [Missing pandoc / ghc substitutes for Guix 1.4.0 for i686] [...] > Would it be possible to somehow trigger a build on one of the default > substitute server to fix this issue? [...] > If not we could simply change the Guix revision and somehow publish > the corresponding manual as well, but using a release probably makes > things much easier for contributors. Not using Guix by default for > building the website is also an option. I've found a better workaround but I'm unsure what is going on under the hood: Here the first substitute server has 0 substitutes: > $ guix time-machine --commit=v1.4.0 -- weather -s i686-linux pandoc > [...] > computing 1 package derivations for i686-linux... > looking for 3 store items on https://ci.guix.gnu.org... > https://ci.guix.gnu.org ⛈ > 0.0% substitutes available (0 out of 3) But then the same command also prints that: > looking for 3 store items on https://bordeaux.guix.gnu.org... > https://bordeaux.guix.gnu.org ☀ > 100.0% substitutes available (3 out of 3) And so I end up being able to download these: > $ guix build \ > --substitute-urls=https://bordeaux.guix.gnu.org \ > --system=i686-linux \ > pandoc > [...] > substituting > /gnu/store/aqxhlbiy3zfcv81y4f439b6x1pcmvynn-pandoc-2.19.2... > downloading > from https://bordeaux.guix.gnu.org/nar/lzip/aqxhlbiy3zfcv81y4f439b6x1pcmvynn-pandoc-2.19.2 ... pandoc-2.19.2 10.6MiB 3.2MiB/s 00:03 ▕██████████████████▏ 100.0% > > /gnu/store/aqxhlbiy3zfcv81y4f439b6x1pcmvynn-pandoc-2.19.2 So this at least works. But I've no idea why it doesn't fallback on bordeaux when substitutes are unavailable on ci.guix.gnu.org (maybe there are good reasons for that). So at the end a workaround I could do here is to detect if the Bordeaux substitute is enabled and if so force its use. Denis. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Guix 1.4.0+i686: getting ghc substitutes? 2024-10-24 14:32 ` Denis 'GNUtoo' Carikli @ 2024-10-25 9:17 ` Andreas Enge 2024-10-26 16:33 ` Denis 'GNUtoo' Carikli 0 siblings, 1 reply; 4+ messages in thread From: Andreas Enge @ 2024-10-25 9:17 UTC (permalink / raw) To: Denis 'GNUtoo' Carikli Cc: help-guix, Adrien 'neox' Bourmault, Jason Self Hello Denis, Am Thu, Oct 24, 2024 at 04:32:33PM +0200 schrieb Denis 'GNUtoo' Carikli: > And so I end up being able to download these: > > $ guix build \ > > --substitute-urls=https://bordeaux.guix.gnu.org \ > > --system=i686-linux \ > > pandoc > > [...] > > substituting this looks as if you are using too old a Guix daemon; more recent versions enable the Bordeaux build farm by default. We should do a release :) Andreas ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Guix 1.4.0+i686: getting ghc substitutes? 2024-10-25 9:17 ` Andreas Enge @ 2024-10-26 16:33 ` Denis 'GNUtoo' Carikli 0 siblings, 0 replies; 4+ messages in thread From: Denis 'GNUtoo' Carikli @ 2024-10-26 16:33 UTC (permalink / raw) To: Andreas Enge; +Cc: help-guix, Adrien 'neox' Bourmault, Jason Self [-- Attachment #1: Type: text/plain, Size: 3909 bytes --] On Fri, 25 Oct 2024 11:17:12 +0200 Andreas Enge <andreas@enge.fr> wrote: > Hello Denis, Hi, > Am Thu, Oct 24, 2024 at 04:32:33PM +0200 schrieb Denis 'GNUtoo' > Carikli: > > And so I end up being able to download these: > > > $ guix build \ > > > --substitute-urls=https://bordeaux.guix.gnu.org \ > > > --system=i686-linux \ > > > pandoc > > > [...] > > > substituting > > this looks as if you are using too old a Guix daemon; more recent > versions enable the Bordeaux build farm by default. Before I did most of the tests on Guix system, and I only verified that my script that detects the use of Bordeaux worked on both Guix system and a fresh Trisquel 11 VM, with Guix installed through guix-install.sh, without substitutes enabled. But when doing more tests before finishing the patches for GNU Boot[1] I found more issues. Missing Bordeaux in older Debian packages: ------------------------------------------ In debian/rules of the Trisquel package, we have that (modified to fit the ~70 lines limits of mails): > override_dh_install: > dh_install > [...] > # Add /etc/default/acl with the default substitute server, > # with identical output as "guix archive --authorize" > mkdir -p debian/guix/etc/guix/ > printf '(acl\n (entry\n' > \ > debian/guix/etc/guix/acl > sed -e 's,^, ,g' -e 's, $$,,g' \ > etc/substitutes/ci.guix.gnu.org.pub >> \ > debian/guix/etc/guix/acl > printf ' (tag\n (guix import)\n )\n )\n )\n' >> \ > debian/guix/etc/guix/acl Bordeaux is added later on in the Debian package[2]. After testing on Trisquel 11 with the Guix package, as expected, 'guix build --substitute-urls=https://bordeaux.guix.gnu.org' results in ghc being built instead of downloaded. So I'm unsure what to do here. I could ask to add Bordeaux in the Trisquel package but that's probably not the best way to deal with that. Potential issue with /etc/guix/acl ---------------------------------- My previous attempt to workaround the lack of substitutes was to detect bordeaux and force its use if it's authorized. Here's my code (GPLv3+): > (define bordeaux.guix.gnu.org > "(public-key > (ecc > (curve Ed25519) > (q > #7D602902D3A2DBB83F8A0FB98602A754C5493B0B778C8D1DD4E0F41DE14DE34F#)))") > > (if (authorized-key? (string->canonical-sexp bordeaux.guix.gnu.org)) > (display "--substitute-urls=https://bordeaux.guix.gnu.org")) But in some situations we have: > $ guix repl force-bordeaux-substitute.scm > guix repl: error: open-file: Permission denied: "/etc/guix/acl" So under Trisquel 11 with the guix package we have: > $ ls -la /etc/guix/acl > -rw------- 1 root root 355 Oct 26 18:06 /etc/guix/acl With Guix system we have: > $ ls -la /etc/guix/acl > -r--r--r-- 1 root root 528 Oct 26 13:53 /etc/guix/acl With 'sudo ./guix-install.sh' with substitutes enabled we have: > $ ls -la /etc/guix/acl > -rw------- 1 root root 355 Oct 26 18:06 /etc/guix/acl And with 'sudo ./guix-install.sh' without substitutes enabled there is no issue since /etc/guix/acl doesn't exist so my detection of Bordeaux works fine. Is this a bug? Should the permissions be the same in all the situations? Beside bugreporting / fixing it in the Debian package and in guix-install.sh, it also brings the question of what to do for previous installations. References: ----------- [1]Since GNU Boot wants to make it as easy as possible to contribute I test builds and changes in various environments (Trisquel 11 + guix-install.sh, guix system, Trisquel 11 + guix package, etc). [2]It's added in the commit 2700105e8f ("debian/rules: Add "bordeaux" substitute server to /etc/guix/acl.") from the https://salsa.debian.org/debian/guix.git/ repository. Denis. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-10-26 16:43 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-10-18 20:26 Guix 1.4.0+i686: getting ghc substitutes? Denis 'GNUtoo' Carikli 2024-10-24 14:32 ` Denis 'GNUtoo' Carikli 2024-10-25 9:17 ` Andreas Enge 2024-10-26 16:33 ` Denis 'GNUtoo' Carikli
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).