bug#71495: Add command line flag to add to load path without evaluation
Hi Guix! In Guile, -L is a equivalent shorthand for adding to the %load-path variable. No actual files are evaluated. In Guix, -L actually evaluates files (at least in some capacity) to look for package definitions, allowing for uses like $ guix -L . . This has a performance impact as channels grow, so it would be nice if there was an alternative command line flag that matched Guile's behavior. To showcase the issue, here's three examples of "building" an already-built home environment. I would use $ guix repl instead, but -L in guix repl seems to match Guile's behavior, not Guix's. --8<---cut here---start->8--- # Baseline, no load path additions gibraltar :) rsent$ bash -c 'time guix home build rsent/home/minimal.scm' /gnu/store/5m062lg4f32j9hlirfkcp5141px6sgkv-home real0m9.776s user0m22.981s sys 0m0.233s # GUILE_LOAD_PATH, within margin of error of baseline gibraltar :) rsent$ GUILE_LOAD_PATH=. bash -c 'time guix home build rsent/home/minimal.scm' /gnu/store/5m062lg4f32j9hlirfkcp5141px6sgkv-home real0m10.016s user0m23.064s sys 0m0.186s # -L ., consistently ~25% longer to complete gibraltar :) rsent$ bash -c 'time guix home build -L . rsent/home/minimal.scm' /gnu/store/5m062lg4f32j9hlirfkcp5141px6sgkv-home real0m12.791s user0m29.569s sys 0m0.247s --8<---cut here---end--->8--- At present one can set GUILE_LOAD_PATH manually to work around this issue. In my opinion this isn't very discoverable. Furthermore, it can't _cleanly_ handle cases when GUILE_LOAD_PATH is already set or needs multiple entries. It also makes certain commands with bash builtins (like time...) awkward since you have to enter a subshell. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71214: bordeaux linux-libre-6.8.10-guix.tar.gz corrupt nar
Christopher Baines writes: > I've investigated this now Thanks for looking into this! -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71312: Dead download links on guix.gnu.org/en/download/latest
Some download links on https://guix.gnu.org/en/download/latest/ return a JSON payload containing the following content: > error "Could not find the requested build product." This occurs for the links under "GNU Guix System on Linux" and "GNU Guix System on GNU Hurd". -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71299: Fixed link for demonstration of the problem
I was informed that the link I mentioned in the first issue is nonpublic. Here's the definitely public build output that demonstrates the problem, albeit in trimmed form: https://builds.sr.ht/~freakingpenguin/job/1238029 -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71299: Investigation
Hi Guix! I started looking into this problem and unfortunately it looks like it might be more complicated than I thought. My initial thought was having two progress-reporters and selecting on based on a simple conditional if current-error-port was a tty or not. This would be in guix/scripts/substitute. Unfortunately, this might be a bit more challenging. Unlike the other scripts, guix/scripts/substitute is invoked by the daemon directly. Furthermore, it isn't passed a file descriptor to the invokers stderr. Instead, it goes through the build daemon. See nix/libstore/local-store.cc:LocalStore::getLineFromSubstituter. >From my testing calling istty? on that error port always returns #f, ergo the "simple" progress-reporter is always used and we lose the interactive progress bars. Testing this is also a pain as well because it involves changing the build daemon. In my experience the easiest way is: 1. Change the commit field for the guix package in package-management.scm to the commit you want to check 2. Update the url field for the guix package to "file:///path/to/guix/clone" 3. Forcefully disable authentication in guix/build-system/channel.scm 4. Generate an installer image via $ ./pre-inst-env guix system image gnu/system/install.scm --image-type=iso9660, then boot from that image and observe the output. So, that leaves two options that I can see: 1. The daemon stops capturing stderr from the substituter and merely passes it the daemon's stderr. 1. Challenging to get right and this may have unforseen consequences. Two processes writing freely to the same output at once is a bad idea. 2. The daemon has a isatty? check and sets a flag for the build agent which is passed along to scripts/substitute. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71299: Better handle "updating substitutes" messages in CI pipelines and dumb terminals
Hi Guix! Due to it's nature as an incremental counter (from 0% to 100%), Guix prints many messages to the terminal when it is updating substitutes. This hurts CI log files because large portions of the output is filled with cruft [1]. This problem is made worse because Guix updates substitutes multiple times during a build. verbosity=0 can be used to disable ALL output messages. However, this isn't ideal for automated build pipelines where people need to monitor the status and review what may have gone wrong. Because "updating substitutes" prints so many lines to the terminal that aren't typically relevant from a log reviewer's perspective that hide useful information, it should be possible to disable just those messages. Alternatively, I believe Guix has code to detect when it's attached to a "dumb" terminal. Perhaps these messages should be conditionally removed or replaced with a pair of static messages like the following: --8<---cut here---start->8--- substitute: Updating subsitutes from . substitute: Finished updating substitutes from --8<---cut here---end--->8--- This would make log files much easier to parse. Instead of having potentially thousands of lines printed to the console per "build stage", it would be limited to 2. [1]: https://builds.sr.ht/query/log/1238029/update-readme/log -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71298: --verbosity=0 does not disable all substitute messages in shell
Hi Guix! Setting verbosity to 0 (which according to the manual disables all output) does not actually disable all output in Guix shell. --8<---cut here---start->8--- ~/code/projects/srht-readme $ guix shell --verbosity=0 ghc -- ls substitute: updating substitutes from 'http://10.1.2.2:80'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% COPYING org-to-html README.html README.org setup-environment --8<---cut here---end--->8--- --8<---cut here---start->8--- ~/code/projects/srht-readme $ guix shell emacs-back-button --verbosity=0 substitute: updating substitutes from 'http://10.1.2.2:80'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% gibraltar :) srht-readme [env]$ --8<---cut here---end--->8--- This problem seems unique to guix shell. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71297: guix time-machine does not have a verbosity option
Hi Guix! guix time-machine does not have a verbosity option. --8<---cut here---start->8--- ~/code/projects/srht-readme $ guix time-machine -q --verbosity 0 -- describe guix time-machine: error: verbosity: unrecognized option --8<---cut here---end--->8--- This is unfortunate because it hurts it's usability as part of a CI system. Pipelines using time-machine are filled with excess logging messages that aren't always needed and can't be disabled unless output redirection is available. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#48907: Other possibly related issues
Hi all, I believe https://issues.guix.gnu.org/62890 is another example of this problem. Possibly https://issues.guix.gnu.org/47115#23 as well. One idea I had was to somehow graft each output as a unique derivation via repeated calls to graft-derivation. From what I've seen so far though that looks much easier said than done. It hasn't progressed beyond the "huh, I wonder" phase. Funny, I just started investigating the grafting code myself to see if I could understand what's going on and I stumble upon this 3 year old issue just an hour after Maxim comments. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71238: Installer image consistently fails to run system init due to TLS error
Richard Sent writes: > 1. There was a transient network issue for ~3 hours when I attempted to > install Guix ~4 times using different installation media that caused a > specific TLS handshake to fail. > > 2. A specific TLS handshake Guix undertakes during the installation > process fails to pass one of the built-in firewall rules shipped with > opnsense. > > 3. Some other odd aspect of my network messes things up for a specific > TLS handshake. > > My money is on 2 given how this is a seemingly common issue on > enterprise networks [1] and the rules I have added seem irrelevant. (I'd > rather not talk openly about my firewall rules in an archived public > forum, but can discuss off-list). However, there is another comment in > that thread that says IT didn't notice any firewall blocking. I ran the 1.4.0 installer again today behind my opnsense router and it completed successfully, which is horrifying. I was hoping starting from a constant image would make the error reproducible but that doesn't seem to be the case. Even with a consistent system image and network, it's only reproducible for somewhere between a few hours and one day. Perhaps server load plays a part? (Technically my process was a little bit different. Instead of fully completing the graphical installer I swapped to a TTY after activating the wired connection, mounted the root fs, and run $ guix system build /mnt/etc/config.scm, where config.scm was unmodified since initial installation. I'd be stunned if this caused the change in behavior but figured I'd mention for completeness.) -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71238: Installer image consistently fails to run system init due to TLS error
Richard Sent writes: > What the heck is going on here? Those two images are wildly different > and are downloading wildly different sets of substitutes. Bad news. I connected my device to a different network with just an ordinary consumer router and the installation succeeded (using the guix 00384aed media). Ordinary my devices are behind a opnsense router with a /very/ lightly-customized firewall. To me, this means there are three possibilities, none of which is particularly comforting: 1. There was a transient network issue for ~3 hours when I attempted to install Guix ~4 times using different installation media that caused a specific TLS handshake to fail. 2. A specific TLS handshake Guix undertakes during the installation process fails to pass one of the built-in firewall rules shipped with opnsense. 3. Some other odd aspect of my network messes things up for a specific TLS handshake. My money is on 2 given how this is a seemingly common issue on enterprise networks [1] and the rules I have added seem irrelevant. (I'd rather not talk openly about my firewall rules in an archived public forum, but can discuss off-list). However, there is another comment in that thread that says IT didn't notice any firewall blocking. >> Sometimes, usually when I'm on an enterprise network like my >> university's of library's wifi, the `guix substitute` process dies >> with a "TLS error in procedure 'write_to_session_record_port': Error >> in the push function" error message. My connection is rock-solid >> otherwise, and sometimes it doesn't happen at all. > I get the same error on guix pull almost always when I am on my > enterprise network. Re-running guix pull a second time also almost > always then runs fine. I checked with our IT: nothing suspicious on > the network, i.e. no firewall blocking. Running Guix pull to work around the problem is great.. unless you're trying to install Guix via the guided installer! :) In my case it also wasn't guix pull that was failing. I want to emphasize that the error occured in the same phase of the installer every time, it was not the first handshake, no other machine has ever had this issue, and the installer was (3/4 times) on a commit that should include the fix described in [1]. I'm happy to assist with debugging this, although I'm not some TLS networking genius so trying to solve it outright is probably beyond me. I'd also LOVE to hear if other people using a largely stock opnsense or other firewall software encountered this issue, particularly with the installation media. At some point I'll attempt to gradually "de-enterprise" parts of my network and see exactly when (if ever) the problem is resolved. Due to the nature of the problem, reliably reproducing it in the future will be a challenge. CC'ing people involved in [1] because this is just so weird and I don't want it to be consigned to the dustbins of history. I don't think we heard anyone with the issue explicitly say the fix resolved or at least mitigated the problem. [1]: https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00150.html -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71238: Installer image consistently fails to run system init due to TLS error
> Curiously this does NOT occur the first time substitutes are fetched. I > observed it occur three times when substitutes were fetched after Ruby > was substituted. I don't mean to say that Ruby is the problem (that'd be > crazy), just that the TLS error occurs at the same stage in the > installation every time. NOT randomly. > > I've never encountered this error before on any other Guix machine on my > network. The installation machine was using a wired connection. I have now tried the v1.4.0 installer and get a failure at (seemingly) the same point in the install, although the actual error is different. See installer-dump-22e789d5. What the heck is going on here? Those two images are wildly different and are downloading wildly different sets of substitutes. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71238: Installer image consistently fails to run system init due to TLS error
Hi Guix! The dump was uploaded as installer-dump-2e7b5f8f. Here's the installer's error message: --8<---cut here---start->8--- May 27 22:15:49 localhost installer[708]: substitute: ^[[Kupdating substitutes from 'https://bordeaux.guix.gnu.org'... 0.0%guix substitute: error: TLS error in procedure 'write_to_session_record_port': Error in the push function. May 27 22:15:49 localhost installer[708]: guix system: ^[[1;31merror: ^[[0m`/gnu/store/rdjjpch9m9xv4rdhhr6sv044qd322pj8-guix-command substitute' died unexpectedly --8<---cut here---end--->8--- A Guix system installation generated via the following method consistently fails to install due to a TLS error when updating substitutes. --8<---cut here---start->8--- gibraltar :( guix$ guix time-machine -q -- describe guix 00384ae repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 00384aedbc6a371aaf90ca344a446952fdd5a6b3 gibraltar :) guix$ guix time-machine -q -- system image --image-type=iso9660 -e '(@ (gnu system install) installation-os)' guix system: warning: Consider running 'guix pull' followed by 'guix system reconfigure' to get up-to-date packages and security updates. Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Computing Guix derivation for 'x86_64-linux'... \ /gnu/store/x9a2nflpnfpr8i3n1759hw7wg2qv5mm8-image.iso --8<---cut here---end--->8--- Curiously this does NOT occur the first time substitutes are fetched. I observed it occur three times when substitutes were fetched after Ruby was substituted. I don't mean to say that Ruby is the problem (that'd be crazy), just that the TLS error occurs at the same stage in the installation every time. NOT randomly. I've never encountered this error before on any other Guix machine on my network. The installation machine was using a wired connection. Possibly related: [1], [2], [3], [4] Notably [3] claims to have a fix that was merged into Guix, but 00384ae is after said fix was merged (and yes, $ guix describe on the installer image does report 00384ae) [1]: https://issues.guix.gnu.org/66786 [2]: https://issues.guix.gnu.org/48903 [3]: https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00150.html [4]: https://issues.guix.gnu.org/70244 -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#62890: StumpWM fails to start - Read only file system
Richard Sent writes: > Packages that depend on say, A:lib graft their own copies of A:lib that > is distinct from grafting A:out and A:lib together. This behavior > confuses asdf-build-system and leads to breakage. I should rephase this. asdf-build-system is doing its job just fine. I don't think it's the build-system that's broken. It's that splitting outputs like this simply leads to incompatibility with asdf itself. That being said, I've never actually /used/ asdf. I welcome thoughts from my betters! :) -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#47115: Another occurence in the wild
Hi Guix! I believe I found another instance of this bug coming back to haunt unfortunate, wayward souls. (including me! ). https://issues.guix.gnu.org/62890 -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#62890: Likely cause found, excess library grafting
cl-2.4.0" .
"/gnu/store/vj5jdgz6dajq25f6arjw976h6awwblgh-sbcl-2.4.0")
("/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16" .
"/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16")
("/gnu/store/kf04j56xzh2pglwz3d8ybiz7wxwrs4df-sbcl-clx-0.7.5-1.3840045" .
"/gnu/store/3sbrd8gj3ddq3cya2fygj0q788wp0kbr-sbcl-clx-0.7.5-1.3840045")
("/gnu/store/1xpjw51n2alaszrvwwm2f78k3nnnlrk1-sbcl-fiasco-0.0.1-2.bb47d2f" .
"/gnu/store/z4l73b6b1a6ijfd5chpijjbi37mbq5wl-sbcl-fiasco-0.0.1-2.bb47d2f")
("/gnu/store/7xiwhrv7x4isj2860par69xas9lrk4av-sbcl-cl-ppcre-2.1.1" .
"/gnu/store/h7r9c6wxm7d3yk803jyw86c0pr86rxcj-sbcl-cl-ppcre-2.1.1")))
(map (match-lambda ((name . file) (cons
(assoc-ref old-outputs name) file))) %outputs (graft old-outputs %outputs
mapping)))
;; guix build sbcl-stumpwm-cpu, stumpwm-graft builder
(begin (use-modules (guix build graft) (guix build utils) (ice-9 match))
(define %outputs (list (cons "lib" ((@ (guile) getenv) "lib"
(begin (setenv "GUIX_LOCPATH"
"/gnu/store/visfdda934gvivwihwhlm63fdqhhcc8a-glibc-utf8-locales-2.35/lib/locale")
(setlocale LC_ALL "en_US.utf8"))
(let* ((old-outputs (quote (("lib" .
"/gnu/store/j73w1n1sf3gqgx8qx3cx9csbrndddq0b-stumpwm-22.11-lib"
(mapping (append (quote
(("/gnu/store/kf04j56xzh2pglwz3d8ybiz7wxwrs4df-sbcl-clx-0.7.5-1.3840045" .
"/gnu/store/3sbrd8gj3ddq3cya2fygj0q788wp0kbr-sbcl-clx-0.7.5-1.3840045")
("/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16" .
"/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16")
("/gnu/store/1xpjw51n2alaszrvwwm2f78k3nnnlrk1-sbcl-fiasco-0.0.1-2.bb47d2f" .
"/gnu/store/z4l73b6b1a6ijfd5chpijjbi37mbq5wl-sbcl-fiasco-0.0.1-2.bb47d2f")
("/gnu/store/jd34ay8cyyl2dag62n94m15gg1b4s1sw-sbcl-2.4.0" .
"/gnu/store/vj5jdgz6dajq25f6arjw976h6awwblgh-sbcl-2.4.0")
("/gnu/store/7xiwhrv7x4isj2860par69xas9lrk4av-sbcl-cl-ppcre-2.1.1" .
"/gnu/store/h7r9c6wxm7d3yk803jyw86c0pr86rxcj-sbcl-cl-ppcre-2.1.1")))
(map (match-lambda ((name . file) (cons
(assoc-ref old-outputs name) file))) %outputs (graft old-outputs %outputs
mapping)))--8<---cut here---end--->8---
Different builders? Different outputs. Different outputs? Different
50-stumpwm.conf files. Different 50-stumpwm.conf files? Sadness.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
bug#71133: linux-libre-guix.tar.xz CI times out on aarch64-linux
New issue opened at https://issues.guix.gnu.org/71214. I'l close this one. Thanks! -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71214: bordeaux linux-libre-6.8.10-guix.tar.gz corrupt nar
Hi Guix! The nar for /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz on Bordeaux seems to have been corrupted by some mechanism. The URL in question is > URL: nar/none/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz >From comments by cbaines on an earlier issue [1] that had misdiagnosed the problem: > Yeah, something's up here specifically with the bordeaux build farm, > feel free to open a new issue. > > You can tell something is wrong just by looking at the narinfo: > > https://bordeaux.guix.gnu.org/y813phs2n9xnb7zbcr07g0j9509bzbsb.narinfo > > Given there's no compression here, the file size should be the same as > the nar size, but it's not, it's missing a few bytes. For reference: > NarSize: 143081664 > Compression: none > FileSize: 143081472 On a related note, whatever issue is going on here seems to cause [2]. The actual issues are distinct. [1]: https://issues.guix.gnu.org/71133 [2]: https://issues.guix.gnu.org/71160 -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71133: linux-libre-guix.tar.xz CI times out on aarch64-linux
Christopher Baines writes: > This derivation seems to have been built fine by the bordeaux build > farm: > > > https://data.guix.gnu.org/gnu/store/ny56fdcig9cd9bd3pssmlraz2c1q10q8-linux-libre-6.8.10-guix.tar.xz.drv You're right. It looks like the derivation itself built fine based on that, but something seems off when the nar is sent. Assuming I understand the following correctly: --8<---cut here---start->8--- ~/code/cloned/guix/guix $ guix build linux-libre --system=aarch64-linux substitute: updating substitutes from 'http://10.1.2.2:80'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% The following derivations will be built: /gnu/store/v471590wpsw1fcnqrrr9bwh52skbb5rn-linux-libre-6.8.10.drv /gnu/store/1wi10rg7236ck8k5vdrdfap5l7a9s9z0-linux-libre-6.8.10-guix.tar.xz.drv 143.1 MB will be downloaded: /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz substituting /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz... downloading from https://bordeaux.guix.gnu.org/nar/none/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz ... linux-libre-6.8.10-guix.tar.xz 136.5MiB 23.9MiB/s 00:06 ▕█▋▏ 98.0%guix substitute: error: corrupt input while restoring '/gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz' from # substitution of /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz failed guix build: error: some substitutes for the outputs of derivation `/gnu/store/ny56fdcig9cd9bd3pssmlraz2c1q10q8-linux-libre-6.8.10-guix.tar.xz.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source --8<---cut here---end--->8--- Even though the derivation was built, the substitution fails. Just for fun, here's the output on a ARM64-native system: --8<---cut here---start->8--- root@caustic ~# guix build linux-libre substitute: updating substitutes from 'http://10.1.2.2:80'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% The following derivations will be built: /gnu/store/v471590wpsw1fcnqrrr9bwh52skbb5rn-linux-libre-6.8.10.drv /gnu/store/1wi10rg7236ck8k5vdrdfap5l7a9s9z0-linux-libre-6.8.10-guix.tar.xz.drv 143.1 MB will be downloaded: /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz substituting /gnu/store/0jfsx4hljddyand45z7i77ynpvr0mhb5-module-import-compiled... downloading from http://10.1.2.2/nar/zstd/0jfsx4hljddyand45z7i77ynpvr0mhb5-module-import-compiled ... module-import-compiled 4.2MiB/s 00:00 | 244KiB transferred substituting /gnu/store/fwqy5d6xyar9x5yksny79r2d519s25cx-100gnu+freedo.patch... downloading from http://10.1.2.2/nar/zstd/fwqy5d6xyar9x5yksny79r2d519s25cx-100gnu%2Bfreedo.patch ... 100gnu%2Bfreedo.patch 1.8MiB/s 00:00 | 46KiB transferred substituting /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz... downloading from https://bordeaux.guix.gnu.org/nar/none/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz ... linux-libre-6.8.10-guix.tar.xz 136.5MiB 1.7MiB/s 01:21 ▕█▉▏ 99.9%guix substitute: error: corrupt input while restoring '/gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz' from # substitution of /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz failed guix build: error: corrupt input while restoring archive from # --8<---cut here---end------->8--- -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71160: --fallback and (fallback #t) do not apply when receiving a corrupt nar
Richard Sent writes: > Trying to pass --fallback on the command line has no effect, even though > both the documentation and [1] imply that should work. This issue might have some spiciness to it. I have two machines with identical guix commits and --fallback works on one but not the other. --8<---cut here---start->8--- # Failing machine: root@lifeline ~# guix describe Generation 2May 25 2024 21:03:46(current) guix 94c8cec repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 94c8cec99969fe9f65777637fde1f05e1c576a3f # Good machine: Generation 3May 25 2024 21:58:15(current) guix 94c8cec repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 94c8cec99969fe9f65777637fde1f05e1c576a3f --8<---cut here---end--->8--- On the failing machine, I get an error like this: --8<---cut here---start->8--- root@lifeline ~# guix build linux-libre-arm64-generic --system=aarch64-linux --fallback # snip downloading from https://bordeaux.guix.gnu.org/nar/none/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz ... linux-libre-6.8.10-guix.tar.xz 136.5MiB 19.0MiB/s 00:07 ▕█▉▏ 99.9%guix substitute: error: corrupt input while restoring '/gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz' from # substitution of /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz failed guix build: error: corrupt input while restoring archive from # root@lifeline ~# logout --8<---cut here---end--->8--- whereas on the good machine: --8<---cut here---start->8--- root@gibraltar ~# guix build linux-libre-arm64-generic --system=aarch64-linux --fallback # snip downloading from https://bordeaux.guix.gnu.org/nar/none/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz ... linux-libre-6.8.10-guix.tar.xz 136.5MiB 19.6MiB/s 00:07 ▕█▊▏ 98.8%guix substitute: error: corrupt input while restoring '/gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz' from # substitution of /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz failed building /gnu/store/ny56fdcig9cd9bd3pssmlraz2c1q10q8-linux-libre-6.8.10-guix.tar.xz.drv... --8<---cut here---end--->8--- I thought perhaps there was some hyper-odd race condition going on here (lifeline is consistently at a higher percent than gibraltar when the error is detected), but I just had a outlier that seems to disprove that, where lifeline had the same error with a 97.2% download progress bar. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71139: herd unresponsive on new 1.4.0 install
> Perhaps we should consider using Fibers 1.1 for all architectures? This > problem occurred on a x86-64 machine. This issue reverted Fibers 1.3 > just for ARM: > https://issues.guix.gnu.org/64966#6 With https://issues.guix.gnu.org/70892#3 Fibers is also reverted to 1.1 on RISC-V 64. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71197: visionfive2-barebones-os fails to boot Linux from MMC2
Z572 writes: > hello!, can you try boot from mmc1, and do setenv and saveenv on mmc1 > uboot, then reset and boot from mmc2? Hi! Sorry for not mentioning that. Those setenv + saveenv commands were run with MMC1 (SPI) boot selected, not MMC2. I confirmed the printenv fdtfile output matched starfive/jh7110-starfive-visionfive-2-v1.3b.dtb on both MMC1 and MMC2. However, I ran the commands again just now and suddenly it can boot from MMC2. I have no idea idea what could have happened (Originally entered from MMC1, no typos, and printenv matched the expected values after rebooting), but it boots now. Very strange, but seemingly the issue is resolved. I wonder if anyone else will encounter it in the future. Thanks! -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71197: visionfive2-barebones-os fails to boot Linux from MMC2
fset : 0x3 Firmware Heap Size: 42 KB (total), 2 KB (reserved), 9 KB (used), 30 KB (free) Firmware Scratch Size : 4096 B (total), 760 B (used), 3336 B (free) Runtime SBI Version : 1.0 Domain0 Name : root Domain0 Boot HART : 3 Domain0 HARTs : 0*,1*,2*,3*,4* Domain0 Region00 : 0x0200-0x0200 M: (I,R,W) S/U: () Domain0 Region01 : 0x4000-0x4001 M: (R,X) S/U: () Domain0 Region02 : 0x4002-0x4003 M: (R,W) S/U: () Domain0 Region03 : 0x-0x M: (R,W,X) S/U: (R,W,X) Domain0 Next Address : 0x4020 Domain0 Next Arg1 : 0x4040 Domain0 Next Mode : S-mode Domain0 SysReset : yes Domain0 SysSuspend: yes Boot HART ID : 3 Boot HART Domain : root Boot HART Priv Version: v1.11 Boot HART Base ISA: rv64imafdcbx Boot HART ISA Extensions : none Boot HART PMP Count : 8 Boot HART PMP Granularity : 4096 Boot HART PMP Address Bits: 34 Boot HART MHPM Count : 2 Boot HART MIDELEG : 0x0222 Boot HART MEDELEG : 0xb109 U-Boot 2024.01 (Jan 01 1970 - 00:00:01 +) CPU: rv64imafdc_zba_zbb Model: StarFive VisionFive 2 v1.3B DRAM: 8 GiB Core: 134 devices, 26 uclasses, devicetree: board WDT: Not starting watchdog@1307 MMC: mmc@1601: 0, mmc@1602: 1 Loading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK StarFive EEPROM format v2 EEPROM INFO Vendor : StarFive Technology Co., Ltd. Product full SN: VF7110B1-2253-D008E000-4582 data version: 0x2 PCB revision: 0xb2 BOM revision: A Ethernet MAC0 address: 6c:cf:39:00:47:28 Ethernet MAC1 address: 6c:cf:39:00:47:29 EEPROM INFO starfive_7110_pcie pcie@2b00: Starfive PCIe bus probed. starfive_7110_pcie pcie@2c00: Starfive PCIe bus probed. In:serial@1000 Out: serial@1000 Err: serial@1000 Net: eth0: ethernet@1603, eth1: ethernet@1604 libfdt fdt_check_header(): FDT_ERR_BADMAGIC Card did not respond to voltage select! : -110 Card did not respond to voltage select! : -110 bootmode flash device 0 Card did not respond to voltage select! : -110 Hit any key to stop autoboot: 0 Card did not respond to voltage select! : -110 ** Bad device specification mmc 0 ** Couldn't find partition mmc 0:3 Can't set block device Importing environment from mmc0 ... ## Warning: Input data exceeds 1048576 bytes - truncated ## Info: input data size = 1048578 = 0x12 Can't set block device ## Warning: defaulting to text format ## Error: "boot2" not defined Card did not respond to voltage select! : -110 ethernet@1603 Waiting for PHY auto negotiation to complete. TIMEOUT ! phy_startup() failed: -110FAILED: -110ethernet@1604 Waiting for PHY auto negotiation to complete. TIMEOUT ! phy_startup() failed: -110FAILED: -110ethernet@1603 Waiting for PHY auto negotiation to complete. TIMEOUT ! phy_startup() failed: -110FAILED: -110ethernet@1604 Waiting for PHY auto negotiation to complete. TIMEOUT ! phy_startup() failed: -110FAILED: -110StarFive # StarFive # [1]: https://github.com/starfive-tech/VisionFive2/issues/20 -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71183: elogind tests fail on QEMU riscv64-linux but not native with identical derivations
Hi Guix! Building elogind fails due to a failing test on a QEMU riscv64 build: --8<---cut here---start->8--- gibraltar :) guix$ guix describe Generation 77 May 24 2024 00:15:41(current) guix 9901416 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 9901416233867233192b63fde7f616751127b189 gibraltar :) guix$ guix build elogind --system=riscv64-linux --8<---cut here---end--->8--- I'll attach the full build log to this message. Here's the brief output: --8<---cut here---start->8--- 85/143 elogind:test / test-mountpoint-util FAIL 0.03s killed by signal 6 SIGABRT # snip mnt ids of /gnu/store/vaznv17j32jky10bi6942fdfxh7awl67-python-minimal-3.10.7 are 739 (from /proc/self/mountinfo), 0 (from path_get_mnt_id()). Assertion 'q = hashmap_get(h, INT_TO_PTR(mnt_id2))' failed at src/test/test-mountpoint-util.c:104, function test_mnt_id(). Aborting. --8<---cut here---end--->8--- When the build is done natively (thanks for the VisionFive2 image!), it succeeds even though the derivation hash is the same. --8<---cut here---start->8--- # QEMU gibraltar :( guix$ guix build elogind --no-grafts --derivations --system=riscv64-linux /gnu/store/cjbqi2shgn2a99zmwbiqp1kaa7x0zpik-elogind-252.9.drv # Native root@visionfive2 ~# guix build elogind --no-grafts --derivations /gnu/store/cjbqi2shgn2a99zmwbiqp1kaa7x0zpik-elogind-252.9.drv --8<---cut here---end--->8--- I tried disabling just that one test, but it seemed to cause another failure. I haven't investigated beyond that. bqi2shgn2a99zmwbiqp1kaa7x0zpik-elogind-252.9.drv.gz Description: emulated_failure_log bqi2shgn2a99zmwbiqp1kaa7x0zpik-elogind-252.9.drv.gz Description: native_success_log -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71153: [PATCH] gnu: Validate substitute URLs for guix service.
Antero Mejr writes: > +(define (validate-substitute-url url-str) > + (if (string->uri url-str) > + url-str > + (error "Not a valid substitute URL: " url-str))) > + > + (substitute-urls > + (map validate-substitute-url > +(append (guix-extension-substitute-urls extension) > +(guix-configuration-substitute-urls config Should we instead create a validate-substitute-urls and use that as a sanitizer for the guix-extension and guix-configuration records? This would catch errors during record creation instead of service creation, as well as still perform validation if anything else does or will use those records in the future. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71160: --fallback and (fallback #t) do not apply when receiving a corrupt nar
Hi Guix! As part of building linux-libre-arm64-generic, Guix tries substituting linux-libre-arm64-generic.tar.xz. Unfortunately it looks like a corrupt nar snuck into bordeaux. --8<---cut here---start->8--- root@lifeline ~# guix build linux-libre-arm64-generic --system=aarch64-linux --fallback The following derivations will be built: /gnu/store/9626zaczwl5x4ypxmmdklvkclqx2dlpi-linux-libre-arm64-generic-6.8.10.drv /gnu/store/1wi10rg7236ck8k5vdrdfap5l7a9s9z0-linux-libre-6.8.10-guix.tar.xz.drv 199.7 MB will be downloaded: # Snip /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz substituting /gnu/store/0jfsx4hljddyand45z7i77ynpvr0mhb5-module-import-compiled... downloading from https://bordeaux.guix.gnu.org/nar/lzip/0jfsx4hljddyand45z7i77ynpvr0mhb5-module-import-compiled ... module-import-compiled 171KiB 676KiB/s 00:00 ▕██▏ 100.0% substituting /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz... downloading from https://bordeaux.guix.gnu.org/nar/none/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz ... linux-libre-6.8.10-guix.tar.xz 136.5MiB 20.5MiB/s 00:06 ▕█▌▏ 97.6%guix substitute: error: corrupt input while restoring '/gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz' from # substitution of /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz failed guix build: error: corrupt input while restoring archive from # root@lifeline ~# --8<---cut here---end--->8--- Trying to pass --fallback on the command line has no effect, even though both the documentation and [1] imply that should work. Similarly with Cuirass, I have a spec that tries to build an operating-system with a linux-libre-arm64-generic kernel. Even though cuirass-configuration has (fallback #t), no attempt is made to recover by building the derivation locally. --8<---cut here---start->8--- ;; In config (define %rsent-cuirass-service (service cuirass-service-type (cuirass-configuration (specifications %rsent-cuirass-specs) (host "0.0.0.0") (fallback? #t ;; From /var/log/cuirass.log 2024-05-23 22:23:36 Uncaught exception in task: 2024-05-23 22:23:36 In fibers.scm: 2024-05-23 22:23:36 172:8 8 (_) 2024-05-23 22:23:36 In ice-9/boot-9.scm: 2024-05-23 22:23:36 1752:10 7 (with-exception-handler _ _ #:unwind? _ # _) 2024-05-23 22:23:36 In guix/store.scm: 2024-05-23 22:23:36684:37 6 (thunk) 2024-05-23 22:23:36 In cuirass/base.scm: 2024-05-23 22:23:36421:14 5 (_ _) 2024-05-23 22:23:36267:10 4 (spawn-builds # _ ?) 2024-05-23 22:23:36 In ice-9/boot-9.scm: 2024-05-23 22:23:36 1752:10 3 (with-exception-handler _ _ #:unwind? _ # _) 2024-05-23 22:23:36 1685:16 2 (raise-exception _ #:continuable? _) 2024-05-23 22:23:36 1683:16 1 (raise-exception _ #:continuable? _) 2024-05-23 22:23:36 1685:16 0 (raise-exception _ #:continuable? _) 2024-05-23 22:23:36 ice-9/boot-9.scm:1685:16: In procedure raise-exception: 2024-05-23 22:23:36 ERROR: 2024-05-23 22:23:36 1. : 2024-05-23 22:23:36 file: #f 2024-05-23 22:23:36 port: # --8<---cut here---end--->8--- I'm no rocket scientist, but that error looks very similar to the error found when building from the CLI. Given that cuirass-configuration has fallback #t, it should be recoverable. Possibly related: [2] and [3] [1]: https://issues.guix.gnu.org/23103 [2]: https://issues.guix.gnu.org/55820 [3]: Guix 3f59fd6d114548480c719d4b8f8509bdf3e8dcca -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#55909: Converging aux-files/linux-libre/* towards mainline defconfigs
I would be in favor of building more initrd modules into the kernel when done so upstream. To my understanding the distinction between linux-libre and linux-libre-*-generic is to have both: a) A kernel with options that support the various Guix services OOTB, such as CONFIG_BINFMT_MISC and qemu-binfmt-service-type. b) A kernel that matches upstream defconfigs as much as possible, with the exception of a subset of flags considered essential. See %default-extra-linux-options or linux-libre-riscv64-generic. With this model, linux-libre should avoid diverging from upstream defconfigs whenever possible, particularly when toggling a module from y to m. linux-libre would become a superset of *-generic kernels. Obviously I'm not packaging linux-libre myself. I might misunderstand the purpose of these variants. :) On a related note, the *-generic kernels seem to also have encapsulated "add support for a specific board on this platform", which to me feels a bit like a hacky solution. See linux-libre-arm64-generic and the Pinebook Pro comments. I'd think that would belong in a linux-libre-pinebook-pro or similar. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#61986: qemu-binfmt-service-type should protect against adding platforms for target system
Hi Guix! I can confirm that this issue is still around and still causing headaches! ;) It's definitely a problem on the aarch64 architecture. It's probably safe to say it's a problem on every platform. Given how cryptic this error is and how easily it can sneak up in more complicated system configurations ([1] and [2]), we should capture this mistake sometime during the build process. Even if putting the target system as a QEMU emulation platform doesn't make sense, a broken system with no helpful diagnostics isn't a proportional consequence. [1]: https://lists.gnu.org/archive/html/help-guix/2023-03/msg00121.html [2]: https://lists.gnu.org/archive/html/help-guix/2024-05/msg00160.html -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#61173: Wireguard and NF Tables service broken on aarch64
> Hi. It turns out you should use a `linux-libre` kernel same as you > would in x64. If you’re running arm64 then it will still build and > have all the features you expect. I forgot I filed a bug for this but > it’s resolved on my end now. Thanks for the tip. In my case I'm using a certain SBC and am in a catch-22 situation, so I still think there's a bug here: 1. Use linux-libre so kernel config options for various Guix services are set, but not have all the config options required to boot and run the board. 1. Adding config options with dependencies via customize-linux can best be described as a pain. [1] 2. Use linux-libre-arm64-generic to boot the board, but need to manually enable additional config options for every service that requires them. I can eventually either power through 1 or piece together the options I need for 2, but this behavior is definitely surprising. I have three proposed solutions in order of complexity: 1. The documentation for -generic kernels can be improved so their meaning is clearer. -generic as in "as close to upstream as possible". See [2]. 2. Add more entries to %default-extra-linux-options using config options required by various services. 3. A "linux-config-service" or similar could be created that other services extend with their required kernel support, if any. Of the 3, 3 seems the most elegant. It could easily complicate the substitutability of the kernel however. Perhaps it could simply be a system build-time check to confirm that the kernel's .config file does in fact have those options set. [1]: https://issues.guix.gnu.org/66355 [2]: https://issues.guix.gnu.org/43078#2 -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71133: linux-libre-guix.tar.xz CI times out on aarch64-linux
Hi Guix! On aarch64 platforms, the linux-libre-guix.tar.xz.drv build times out [1]. This package is known to have a long build time [2]. Users can work around this by running the build locally with a (very, very large) max-silent-time (~28800 seconds on my machine). Given the impact of this issue (unable to build linux-libre on 64-bit Arm without running a multi-hour build), I think it's worth revisiting if the substitute server timeout should be increased again. Alternatively, perhaps we could fetch the officially released Linux-libre tarballs instead of computing them ourselves [3]. [1]: https://ci.guix.gnu.org/build/4711550/log/raw [2]: https://mail.gnu.org/archive/html/guix-devel/2021-08/msg00077.html [3]: http://linux-libre.fsfla.org/pub/linux-libre/releases/ CC'ing Christopher Baines since this deals with substitutes. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#61173: Wireguard and NF Tables service broken on aarch64
el...@fastmail.com writes: > Right now wireguard and nftable services are broken on the aarch64 > kernel due to their respective kernel config parameters not being > added as modules or compiled into the kernel. I'm hesitant to call > this a bug but it does mean wireguard and nftables are unavailable. A > good chunk of iptables operations are missing as well. I don't have > much experience configuring a kernel but perhaps there's a way to > insure feature parity between the x86_64 and aarch64 kernels? I ran into this issue myself when using linux-libre-arm64-generic so it's still around. It can cause boot problems too depending on what exactly is missing. qemu-binfmt-service-type adds a file-system dependency on /proc/sys/fs/binfmt_misc, and requires the kernel to have CONFIG_BINFMT_MISC set. The 6.8-arm64.conf file does have CONFIG_BINFMT_MISC=m, but in the compiled kernel that option is unset. Ergo the file-system doesn't exist and Shepherd fails to finish initializing file systems. Seeing as how certain config changes are made to linux-libre-arm64-generic to improve device compatibility, I hope the differences can be minimized between the "vanilla" linux-libre and customized linux-libre-arm64-generic outside of device compatibility changes to reduce surprises like this. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#70865: Unable to generate a bootable image for pinebook pro
Hi Guix! When building a system image for the pinebook pro, the image either fails to build or fail to boot. This occurs when when using the pinebook-pro-barebones-raw-image defined in the Guix repository. When --system=aarch64-linux is not passed, the image build fails when cross compiling packages. --8<---cut here---start->8--- $ guix system image gnu/system/images/pinebook-pro.scm ... building /gnu/store/ibjl0n8d1ac107vvkvjgrlb74sxm2b0k-gawk-mesboot-3.1.8.drv... \ 'configure' phasebuilder for `/gnu/store/ibjl0n8d1ac107vvkvjgrlb74sxm2b0k-gawk-mesboot-3.1.8.drv' failed with exit code 1 build of /gnu/store/ibjl0n8d1ac107vvkvjgrlb74sxm2b0k-gawk-mesboot-3.1.8.drv failed View build log at '/var/log/guix/drvs/ib/jl0n8d1ac107vvkvjgrlb74sxm2b0k-gawk-mesboot-3.1.8.drv.gz'. --8<---cut here---end--->8--- When --system=aarch64-linux is passed (enforcing QEMU builds for packages instead of attempting cross compilation), the image builds but the Pinebook Pro does not appear to detect it and will fall back on eMMC. --8<---cut here---start->8--- guix system image gnu/system/images/pinebook-pro.scm --system=aarch64-linux --8<---cut here---end--->8--- Per the blog post on https://othacehe.org/distributing-guix-system-pinebook-pro-images.html, building a pinebook pro system image should be as simple as the first command. When package compilation errors occurs, the user should be able to fall back on the second command. Below is the tail of the log when cross compiling gawk-mesboot: --8<---cut here---start->8--- ... checking for function prototypes... yes checking for string.h... (cached) yes checking whether NLS is requested... yes checking for msgfmt... no checking for gmsgfmt... : checking for xgettext... no checking for msgmerge... no checking build system type... x86_64-unknown-linux-gnu checking host system type... Invalid configuration `aarch64-linux-gnu': machine `aarch64' not recognized configure: error: /gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash ./config.sub aarch64-linux-gnu failed error: in phase 'configure': uncaught exception: srfi-34 # phase `configure' failed after 30.6 seconds command "/gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash" "./configure" "CC_FOR_BUILD=gcc" "CONFIG_SHELL=/gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash" "SHELL=/gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash" "--prefix=/gnu/store/bl3aq7fnpyxq9w2a7bqa4zqgd8z88y8x-gawk-mesboot-3.1.8" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" "--host=aarch64-linux-gnu" "ac_cv_func_connect=no" failed with status 1 --8<---cut here---end--->8--- -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#70543: issues.guix.gnu.org considers a trailing period as part of a hyperlink
Haven't had the chance to properly hack on this yet, but I believe the code to update is located here: https://git.savannah.gnu.org/cgit/guix/mumi.git/tree/mumi/web/view/utils.scm#n127 Let's test how we handle links like <https://example.com>. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#70761: Guix deploy cannot reboot remote machines without an error
Hi Guix,
One neat feature of guix deploy is the ability to run a command on a
list of remote machines. One command that would commonly be run is
reboot, so that upgrades to, say, the Linux kernel take effect.
While the command itself /does/ run and the system /does/ restart, guix
deploy doesn't gracefully handle the connection loss. The first machine
rebooted will throw an error, halting the reboot of the rest of the
machines in the list.
tmux and screen aren't really compatible with '-x -- ' since
you can't start and detach from sessions and the & in '-x -- nohup
&' gets swallowed by the host shell. I haven't found a
workaround. Even if they did work, I suspect there is a race condition
between "host closes session" and "remote restarts".
We shouldn't assume that any command may potentially close the SSH
session and catch errors by default.
One solution could be adding an alternative to -x that nohup's the
command and attempts to cleanly close the SSH session. If the session
errors out after the command is nohup'd (e.g. reboot race condition),
catch the SSH error and exit.
Alternatively we could add a --reboot flag, although I prefer the more
general solution.
Perhaps this can be the impetus for implementing the "deploy-hook"
functionality described at https://issues.guix.gnu.org/53486. In a
particularly fancy world, we could combine rebooting with pre and post
reboot command execution, but now I'm thinking of pies 不 in skies ⛅.
Or maybe I'm completely wrong and this is possible (sorry!), in which
case we probably could add a quick mention of it in the manual.
--8<---cut here---start->8---
gibraltar :( rsent$ guix deploy rsent/machines/lan.scm --no-grafts -x -- reboot
guix deploy: warning: without a 'host-key' is
deprecated
guix deploy: sending 1 store item (0 MiB) to 'horizon.local'...
;;; [2024/05/03 17:16:45.032361, 0] [GSSH ERROR] Parent session is not
connected: #
Backtrace:
16 (primitive-load "/home/richard/.config/guix/current/bin/guix")
In guix/ui.scm:
2312:7 15 (run-guix . _)
2275:10 14 (run-guix-command _ . _)
In ice-9/boot-9.scm:
1752:10 13 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/status.scm:
839:4 12 (call-with-status-report _ _)
In ice-9/boot-9.scm:
1752:10 11 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/store.scm:
666:37 10 (thunk)
1302:8 9 (call-with-build-handler _ _)
1302:8 8 (call-with-build-handler # _)
In guix/scripts/deploy.scm:
274:23 7 (_)
In srfi/srfi-1.scm:
460:18 6 (fold # #t (#< operating-system: #< ke…>))
In guix/scripts/deploy.scm:
214:2 5 (_ #< operating-system: #< kernel:
#
kernel-loada…> …)
In guix/store.scm:
2182:25 4 (run-with-store #
# #:guile-for-build _
# _ # _)
In guix/remote.scm:
72:20 3 (_ _)
In unknown file:
2 (channel-get-exit-status #)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `guile-ssh-error' with args `("channel-get-exit-status" "Parent
session is not connected" # #f)'.
--8<---cut here---end--->8---
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
bug#62890: Specific graft that's at fault
Hi Guix!
The issue is likely caused by the glibc/fixed graft in (gnu packages
base). When this graft is removed, the the path discussed earlier is
coherent. Other grafts do not appear relevant.
--8<---cut here---start->8---
Building stumpwm
(("/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
:**/
:*.*.*)
("/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
:**/
:*.*.*))
(:tree
"/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")
Building sbcl-stumpwm-cpu
(("/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
:**/
:*.*.*)
("/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
:**/
:*.*.*))
(:tree
"/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")
--8<---cut here---end--->8---
Unfortunately stumpwm currently doesn't build on core-updates so I can't
check if the discrepency would occur there where glibc isn't grafted.
How exactly does that graft causes the problem? No clue.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
bug#70704: make maintainer-clean deletes VC'd file doc/he-config-bare-bones.scm
Hi Guix! Running '$ make maintainer-clean' in the guix repo deletes the version-controlled file doc/he-config-bare-bones.scm. Documentation for the maintainer-clean target states: > Delete almost everything that can be reconstructed with this Makefile. Either this file is constructed by the Makefile and shouldn't be version controlled, or it isn't constructed by the Makefile and shouldn't be deleted. (99% odds it's the latter.) I bet it just needs to be added to EXTRA_DIST in doc/local.mk, but I don't fully understand the doc subdirectory or what the effects of that might be. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#70689: guix search doesn't weigh word matches higher than subword matches
Hi Guix! When running guix search, relevance in synopsis and description fields are computed strictly by the number of matches, both as a word and as a subword. Ideally, if a search string matches an isolated word in a search, that result should be considered more relevant than simply matching a subword, even multiple times. To illustrate, imagine trying to find what package provides the `rsh` binary and running running `$ guix search rsh`. This binary is part of `inetutils` and the description field contains: > Inetutils is a collection of common network programs, such as an ftp > client and server, a telnet client and server, an rsh client and > server, and hostname. Most likely, this is what the user is interested in. However, inetutils does not show up until roughly the ~75th result with a relevance of 2 (the lowest possible relevance). Almost every search result beforehand contains the string "rsh" as a component of another word, such as "marshaling", "powershell", and "hershey". However, these match multiple times and are weighted significantly higher. Ideally, guix search should rate inetutils higher because the string "rsh" occurs as its own word, not as a component of another, unrelated word. (Very, very people would search "rsh" looking for matches with "hershey", even if "hershey" occurs multiple times.) Another example of where this can happen is with "dig", part of the bind package. Searching for "dig" returns garbage because "dig" is a common subword. Bind is scored with a relevance of 2, even though bind's description emphasises that dig is part of it. This would improve the experience when searching with strings that commonly occur as subwords. Since this change can't occur in a vacuum, care should be taken not to reduce the effectiveness of other reasonably forseeable search queries. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#70553: Packages built via gexp but not "installed" are not visible in containerized environments
Hi Guix!
Consider a home environment with the following configuration:
--8<---cut here---start->8---
(use-modules (guix gexp)
(gnu home)
(gnu home services shells)
(gnu services)
(gnu packages dns))
(home-environment
;; (packages `((,isc-bind "utils")))
(services
(list
(service home-bash-service-type
(home-bash-configuration
(aliases
`(;; Add other aliases here
,@(let ((dig (file-append (gexp-input isc-bind "utils")
"/bin/dig")))
`(("wanip" . ,#~(string-append #$dig "
@resolver4.opendns.com myip.opendns.com +short"))
("wanip4" . ,#~(string-append #$dig "
@resolver4.opendns.com myip.opendns.com +short -4"))
("wanip6" . ,#~(string-append #$dig "
@resolver1.ipv6-sandbox.opendns.com myip.opendns.com +short -6")))
--8<---cut here---end--->8---
When starting a container with this home environment via `$ guix home
container home.scm`, `wanip` will be successfully aliased to
`/gnu/store/...-bind--utils/bin/dig` and that package will be
built by the daemon.
However, because the container only sees a subset of /gnu/store that
contains packages registered in the profile, that path will not be
present in the container. This can be confirmed by uncommenting the
(packages) field.
I don't know the best way to resolve this, but in my opinion the fact
that Guix lets you combine package "installation" and usage in a gexp is
a great feature. This is definitely cleaner than needing to create an
entire custom service that extends both the home profile service and
home bash service. Especially if this is done multiple times. I also
think this is better than adding isc-bind to the profile and hardcoding
"dig" in .bashrc.
It would be nice if Guix was smart enough to register that store path as
belonging to the home environment and keep it visible to the container
so the behavior could be consistent between `$ guix home reconfigure`
and `$ guix home container`.
Perhaps there's a better way to determine the /gnu/store subset that
should be visible to containers besides just reading the environmnet's
profile.
I expect this crops up in a lot more places than just home environments
and home bash service. I'd hope for a more generalized solution
that solves this problem across multiple services, not specifically
home-bash-service.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
bug#70543: issues.guix.gnu.org considers a trailing period as part of a hyperlink
Correction to the issue I just discovered: apparently most symbols are fair game to be included in the hyperlink. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#70543: issues.guix.gnu.org considers a trailing period as part of a hyperlink
Hi Guix! Not sure where to report this, but when issues.guix.gnu.org creates a hyperlink, it will include trailing periods. Like https://www.example.com. Or as seen in https://issues.guix.gnu.org/70542. (If for whatever reason the error refuses to reproduce here, that issue does actually have an example.) This behavior does not match the behavior of the mailing list archives (See the issues.guix.info link at https://lists.nongnu.org/archive/html/guix-devel/2019-05/msg00083.html) or the Debbugs UI. (See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70542) Thanks! -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#70194: SDDM fails to start, black screen on 188d18fc47
After updating to 4e7337536ba41e888a601c92fada8a4adca9d2c6, the issue seems to have been resolved. I'll leave this open in case anyone else who experienced the issue earlier is still dealing with it. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#70279: emacs-vterm not working
I was unable to replicate this myself, the following commands worked: --8<---cut here---start->8--- $ guix time-machine -q --commit=bfc614397b5f146056bda4b5a8e3a67bd1ca7b23 \ -- shell --pure emacs emacs-vterm -- emacs -Q (require 'vterm) M-x vterm --8<---cut here---end--->8--- I've seen that message before when installing vterm via straight.el. vterm requires an external library (libvterm) to function. Guix usually handles compiling that library as an input of the emacs-vterm package. Perhaps it has something to do with how libvterm is a native input, not a regular input? If it's required at runtime my understanding is it should be the latter, not the former. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#70223: Search for empty string uses excessive memory
Patch submitted at https://issues.guix.gnu.org/70226. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#70194: SDDM fails to start, black screen on 188d18fc47
PER: Writing cookie to "/tmp/xauth_PUcYpV" [23:30:58.489] (II) HELPER: Starting X11 session: "" "/gnu/store/n0msvb8vfd3q3f9349kpq8305c4mx67x-sddm-0.20.0/bin/sddm-greeter --socket /tmp/sddm-:0-cMaMMt --theme /gnu/store/vvdgqz68b7hjysyxvx4jgrfs9n8l161a-guix-simplyblack-sddm-theme-0.1/share/sddm/themes/guix-simplyblack-sddm" [23:30:58.491] (II) DAEMON: Greeter session started successfully [23:31:01.616] (II) DAEMON: Message received from greeter: Connect [23:31:05.982] (II) DAEMON: Message received from greeter: Login [23:31:05.982] (II) DAEMON: Reading from "/run/current-system/profile/share/xsessions/stumpwm.desktop" [23:31:05.982] (II) DAEMON: Session "/run/current-system/profile/share/xsessions/stumpwm.desktop" selected, command: "/gnu/store/fvm9ibhr11bqj09dx5wwha5260hgw2p3-stumpwm-22.11/bin/stumpwm" for VT 7 [23:31:05.991] (II) HELPER: [PAM] Starting... [23:31:05.991] (II) HELPER: [PAM] Authenticating... [23:31:05.991] (II) HELPER: [PAM] Preparing to converse... [23:31:05.991] (II) HELPER: [PAM] Conversation with 1 messages [23:31:05.996] (II) HELPER: [PAM] returning. [23:31:05.996] (II) DAEMON: Authentication for user "richard" successful [23:31:06.028] (II) HELPER: Writing cookie to "/tmp/xauth_qHpzQg" [23:31:06.028] (II) HELPER: Starting X11 session: "" "/gnu/store/by9l6s04vi7g7q8nd3ycvaz2p9373y0h-xinitrc \"/gnu/store/fvm9ibhr11bqj09dx5wwha5260hgw2p3-stumpwm-22.11/bin/stumpwm\"" [23:31:06.030] (II) DAEMON: Session started true [23:31:06.044] (II) HELPER: [PAM] Closing session [23:31:06.045] (II) HELPER: [PAM] Ended. [23:31:06.047] (II) DAEMON: Auth: sddm-helper exited successfully [23:31:06.047] (II) DAEMON: Greeter stopped. SDDM::Auth::HELPER_SUCCESS --8<---cut here---end--->8--- -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#70164: home-bash-service default PS1 overwrites .bashrc PS1 in login shells
Hi Guix! A common convention for where to set PS1 is in .bashrc, not .bash_profile [1-3]. Unfortunately home-bash-service doesn't support this convention for login shells. home-bash-service generates a default .bash_profile that follows these steps: 1. Source .profile 2. Source .bashrc 3. Set PS1 if guix-defaults? is truthy This means that any PS1 configuration in .bashrc is overwritten by .bash_profile for login shells specifically. This is visible in a TTY, but also in WSL, which defaults to opening a login shell. PS1 will be Guix's predefined value instead of the value set in .bashrc. Setting guix-defaults? to #f has many side effects, so I don't feel that is a valid solution. A comment in home/serivces/shells.scm suggests setting PS1 via environment-variables since that is appended to the end of .bash_profile. This is fine for simple prompts, but complicated prompts are often split apart into separate bash functions and variables. Either an implicit dependency between .bashrc and .bash_profile is created, or .bash_profile balloons into a mega-file while the conventional wisdom is to keep it as simple as possible. environment-variables also exports PS1, causing it to become an environment variable, not a shell variable. This might cause some odd behavior when subprocesses inherit it. [4] Some possible solutions: 1. Move default PS1 to bashrc, right after serializing %default-bashrc 2. Keep default PS1 in .bash_profile, but before loading .bashrc 3. Add a set-prompt? field to home-bash-configuration Of the 3, I think 1 is the best and plan to submit a patch for it soon. I'm opening the bug in case anyone thinks I missed something. [1] https://unix.stackexchange.com/a/549075 [2] https://superuser.com/a/789465 [3] https://superuser.com/a/789454 [4] https://unix.stackexchange.com/a/44000 -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#65463: Herd `fport_write: Broken pipe` error when running `guix home reconfigure`
Hi Ludo, I tried replicating this issue on guix d67e4f0f9b10c7ddac8fb0ca68cbf1d6ad0a6e5d and was not able to. My guess is either shepherd 10.2->10.3 resolved the issue or there was a change in fish. It seems to work fine now, but I've not tested thoroughly. Hopefully anyone else who can into the issue can chime in. > (I assume this is the strace of shepherd, not herd.) When you say this do you mean daemon vs. CLI process? I'm fairly confident that was the strace of the daemon although I can't recall how I pulled that off. > Maybe we should unconditionally run shepherd with stdout/stderr > redirected to /dev/null? > > That would sidestep the problem and it’s probably a good idea anyway. Would unconditionally redirecting to /dev/null mess with the system shepherd? I noticed that stdout and stderr for my system shepherd (in /proc/1/fd) are printing to /dev/console. If so that would probably make debugging shepherd issues harder, particularly on something like a single board computer. Thanks for looking at this! -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#69868: Source downloads result in suspicious ownership or permission errors
Possibly related to bug#69753. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#69753: Git checkout fail after daemon checks permissions
I've encountered this issue myself, so it's not an isolated incident. I observed that it only occured when building packages from a custom channel (or perhaps with -L, I don't recall for sure.) The issue seemed to disappear after a while. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#69710: [67960be] failed to compute the derivation for Guix x86_64-linux
> From what I understand, not enabling > substitutes should lead to building from source. Did you try pulling with --fallback? I believe if substitute fetching fails Guix won't build from source unless you add that flag. Perhaps the error message in Guix pull could be updated to not say --8<---cut here---start->8--- guix pull: error: You found a bug: the program ... failed to compute the derivation for Guix Please report the COMPLETE output above by email to . --8<---cut here---end--->8--- When the store protocol error is --8<---cut here---start->8--- ERROR: 1. : message: "some substitutes for the outputs of derivation ... failed (usually happens due to networking issues); try `--fallback' to build derivation from source " status: 1 --8<---cut here---end--->8--- and --fallback isn't provided. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#69836: Guix build builds but errors when given file-like object
When running ~$ guix build -f test.scm~, where test.scm returns a file
like object, the output is built but an error is printed. According to
(info (guix) Additional Build Options), file-like objects are supported
by guix build -f.
For example, with the following file:
--8<---cut here---start->8---
(use-modules
(guix gexp))
(plain-file "hello-world" "HELLO WORLD")
--8<---cut here---end--->8---
/gnu/store/.-hello-world is built and contains "HELLO WORLD", but
there is an match error in guix/ui.scm:show-derivation-outputs.
--8<---cut here---start->8---
...
In guix/scripts/build.scm:
804:26 4 (_)
In srfi/srfi-1.scm:
634:9 3 (for-each # ?)
In guix/ui.scm:
956:2 2 (show-derivation-outputs _)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern"
"/gnu/store/wvr6byljawdlxgxabl6798i0afqgpyiq-hello-world")'.
--8<---cut here---end--->8---
This error could be fixed with the following patch:
--8<---cut here---start->8---
diff --git a/guix/ui.scm b/guix/ui.scm
index 962d291d2e..4dc926cbfe 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -958,7 +958,9 @@ (define (show-derivation-outputs derivation)
(show-outputs derivation (derivation-output-names derivation)))
((? derivation-input? input)
(show-outputs (derivation-input-derivation input)
- (derivation-input-sub-derivations input)
+ (derivation-input-sub-derivations input)))
+((? string?) ;file-like object was built
+ (format #t "~a~%" derivation
(define* (check-available-space need
#:optional (directory (%store-prefix)))
--8<---cut here---end--->8---
However, this brings up another error.
--8<---cut here---start->8---
...
In guix/scripts/build.scm:
808:49 3 (_ "/gnu/store/wvr6byljawdlxgxabl6798i0afqgpyiq-hello-w?")
In guix/derivations.scm:
709:7 2 (derivation->output-paths "/gnu/store/wvr6byljawdlxgxab?")
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 (expecting
struct): "/gnu/store/wvr6byljawdlxgxabl6798i0afqgpyiq-hello-world"
--8<---cut here---end--->8---
In my opinion, being able to directly build file-like objects from the
command line is a useful feature and should be better supported. I don't
know if the ideal fix involves changing the guix-build command in
guix/scripts/build.scm to stop assuming everything is a derivation or
changing the logic in guix/derivations.scm to handle strings in addition
to derivation structs.
Possible related:
https://lists.gnu.org/archive/html/bug-guix/2022-07/msg00037.html.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
bug#68093: Guix system reconfigure starts services with auto-start? #f
Patch submitted, https://issues.guix.gnu.org/69801 -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#69737: GSL cannot find CBLAS symbols
Hi Artyom, I found your code ran when I added --8<---cut here---start->8--- (define libcblas ;; Your store path may differ (load-foreign-library "/gnu/store/dzx94b3xv4h1ik1bfrbxaw7n84y9r8zz-gsl-2.7.1/lib/libgslcblas.so" #:global? #t)) --8<---cut here---end--->8--- before (define libgsl ...) > If global? is true, symbols defined by the loaded library will be > available when other modules need to resolve symbols; the default is > #f, which keeps symbols local. https://www.gnu.org/software/guile/manual/html_node/Foreign-Libraries.html I have not tested if the calculation is correct. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#61343: bug#61574: bug#61343: bug#61574: [PATCH] scripts: repl: Extend REPL %load-path with all channels. For real.
I'm not sure as to the comments regarding program name memoization, but could the solution be as simple as adding the call to (%package-module-path) without deleting (current-profile)? There's probably a more elegant solution, but I found that this patch resolved the issue: --8<---cut here---start->8--- guix/scripts/repl.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/guix/scripts/repl.scm b/guix/scripts/repl.scm index cb71e59b05..c8e875eb05 100644 --- a/guix/scripts/repl.scm +++ b/guix/scripts/repl.scm @@ -26,6 +26,7 @@ (define-module (guix scripts repl) #:use-module (srfi srfi-37) #:use-module (ice-9 match) #:autoload (guix describe) (current-profile) + #:autoload (gnu packages) (%package-module-path) #:autoload (system repl repl) (start-repl) #:autoload (system repl server) (make-tcp-server-socket make-unix-domain-server-socket) @@ -192,8 +193,8 @@ (define-command (guix-repl . args) ;; (%package-module-path) will contain entries for the channels ;; available in the current profile. (current-profile) - (set-program-arguments script) + (%package-module-path) (set-user-module) ;; When passed a relative file name, 'load-in-vicinity' searches the @@ -209,7 +210,6 @@ (define-command (guix-repl . args) ((guile) (save-module-excursion (lambda () - (current-profile) ;populate (%package-module-path); see above (set-user-module) ;; Do not exit repl on SIGINT. ((@@ (ice-9 top-repl) call-with-sigint) base-commit: 6f5ea7ac1acb3d1c53baf7620cca66cc87fe5a73 -- 2.41.0 --8<---cut here---end--->8--- The previous fix in 96739561b87db592716431953cfbbb614e8ff87a did not matter in my testing, so with that + earlier discussion I removed the second (current-profile) call. I have a barebones channel set up at https://git.sr.ht/~freakingpenguin/channel-demo if it's of any help for reproducing the issue. Just a couple of Guile scripts + guix time-machine wrappers. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#68715: Undocumented base services in Guix manual
Hi all, Despite being exported by gnu/services/base.scm, and despite Section 11.9.1 Base Services saying --8<---cut here---start->8--- The ‘(gnu services base)’ module provides definitions for the basic services that one expects from the system. The services exported by this module are listed below. --8<---cut here---end--->8--- the following services and/or types are exported by base.scm, but are not documented in the reference manual (commit 250477d869). I marked extendable services with (e). - fstab-service-type (e) - root-file-system-service - file-system-service-type (e) - swap-service An argument could be made for not documenting root-file-system-service and swap-service, since they're a) not extensible b) not service types and c) likely not relevant for the vast majority of users. Personally I'd still lean towards documenting them, if only to match what the manual says. fstab-service-type and file-system-service-type, however, are extensible and conceivably could be extended by a user. For instance, a custom NAS client service that creates a mount point. As such, I believe those two should be documented. That should help make them a bit more discoverable to users. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#68610: URI path in git-http-nginx-location-configuration doesn't accept / properly
Hi all,
In the documentation for Version Control Services, there is example code
for sharing Git repos through Nginx, posted below. The line
(git-http-configuration (uri-path "/")) implies that git repositories
can be reached at "git.my-host.org/repo.git". However, this doesn't work.
--8<---cut here---start->8---
(service nginx-service-type
(nginx-configuration
(server-blocks
(list
(nginx-server-configuration
(listen '("443 ssl"))
(server-name "git.my-host.org")
(ssl-certificate
"/etc/letsencrypt/live/git.my-host.org/fullchain.pem")
(ssl-certificate-key
"/etc/letsencrypt/live/git.my-host.org/privkey.pem")
(locations
(list
(git-http-nginx-location-configuration
(git-http-configuration (uri-path "/"))
--8<---cut here---end--->8---
Nginx's location information is generated by
git-http-nginx-location-configuration, which runs
--8<---cut here---start->8---
(uri (string-append "~ /" (string-trim-both uri-path #\/) "(/.*)"))
--8<---cut here---end--->8---
If uri-path is "/" (or "", or "\"), this entry will be created in nginx.conf:
--8<---cut here---start->8---
location ~ /(/.*) {
}
--8<---cut here---end--->8---
This location regex pattern will match git.my-host.org//, but not
git.my-host.org/. However, Nginx merges slashes by default, so you
cannot access the repo with 'http://git.my-host.org//repo.git' because
Nginx collapses that to http://git.my-host.org/repo.git before matching
the URI against the location pattern. Which, as mentioned, does not
match.
I did find that (uri-path "*") does work, but I've not tested it
extensively. I also found that I can add `(raw-content (list
"merge_slashes off;"))` to nginx-server-configuration, then use `$ git
clone http://git.my-host.org//repo.git`, but that's not ideal.
At minimum, the documentation should be updated to reflect this
(uri-path "/" vs "\" vs "" are identical). I don't know what the future
plans are for git-http-service, but I can think of two possible solutions:
1. git-http-nginx-location-configuration no longer modifies uri-path and
instead pastes it literally in nginx.conf. To my understanding "/git"
would work identically without the regex match currently used, exposing
repos at "host.domain/git/path/to/repo.git", but I've not tested this.
2. git-http-nginx-location-configuration takes an optional Nginx-style
URI pattern argument that, if passed, replaces the URI generated from
git-http-configuration.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
bug#68429: Catch2-3.5.1 tests fails on i686-linux, SSE extension
Opening a ticket so discussions a bit more organized. Hope this doesn't step on anybody's toes. Catch2-3.5.1 fails to build with system=i686-linux, log attached. This is due to a test added upstream that assumes the SSE extension is present, SelfTest/IntrospectiveTests/RandomNumberGeneration.tests.cpp:570. One fix was proposed that replaces GCC with Clang, attached. This works because Clang assumes the SSE extension by default. If we add "-DCMAKE_CXX_FLAGS=-mno-sse", the test fails again. Another solution is to add "-DCMAKE_CXX_FLAGS=-msse -mfpmath=sse" to the existing package definition. Of the two, the second is more explicit in how the problem is resolved, but I don't know if we should assume SSE is present on i686. An issue was opened upstream at https://github.com/catchorg/Catch2/issues/2796 Richard Sentdiff --git a/gnu/packages/check.scm b/gnu/packages/check.scm index 449340f331..e09a7bd82a 100644 --- a/gnu/packages/check.scm +++ b/gnu/packages/check.scm @@ -621,9 +621,14 @@ (define-public catch2-3 (arguments (list #:configure-flags - #~(list "-DCATCH_DEVELOPMENT_BUILD=ON" + #~(list "-DCMAKE_CXX_COMPILER=clang++" ; tests fail with gcc-11 on i686 + "-DCMAKE_CXX_STANDARD=14" + "-DCMAKE_CXX_STANDARD_REQUIRED=ON" + "-DCMAKE_CXX_EXTENSIONS=OFF" + "-DCATCH_DEVELOPMENT_BUILD=ON" "-DCATCH_ENABLE_WERROR=OFF" "-DBUILD_SHARED_LIBS=ON"))) +(native-inputs (list clang-10)) (inputs (list python-wrapper)) (synopsis "Automated test framework for C++ and Objective-C") (description "Catch2 stands for C++ Automated Test Cases in Headers and is sll1zarpy78qi6fgrz9xrpx99hhn3b-catch2-3.5.1.drv.gz Description: application/gzip
bug#62890: StumpWM with --no-grafts and System/Home mismatches
I've noticed the same behavior and was able to resolve it by adding --no-grafts whenever I reconfigure my system and home profiles. Likely just the former is necessary, but I haven't tested it. I've also noticed this behavior (SBCL trying to place .fasl in /gnu/store) once when I pulled, reconfigured system, and didn't reconfigure home. I have my setup configured such that StumpWM is installed at the system level, while contrib packages are installed via guix home. I ran a git bisect and continually reconfigured my system to try and narrow down what commit it was, and was able to isolate it to either an xorgproto or Mesa update. Home was built before (49a7a95ba4) the commit, System after (d55a4431f3). The offending commit in this particular case lies somewhere between d55a4431f3 and 17c3a3bfff. (This probably isn't actually a bug, but I'm posting it in case anyone else runs into a similar issue in the future.) If anyone else has a similar setup, encounters this issue, and already uses --no-grafts, be sure both the system and home profiles are built with the same version of Guix. Richard Sent
bug#68093: Guix system reconfigure starts services with auto-start? #f
When reconfiguring the system with Guix, shepherd services that have auto-start? set to #f are started during reconfiguration. Per https://issues.guix.gnu.org/22039#26, services shouldn't be started by reconfigure if auto-start is #f. These services are not started on boot, which matches expected behavior. This is different from bug#42167, as this problem occurs even if the service already exists and is stopped. I created an test OS configuration to help others reproduce it, see attached. This was run on guix 931d893c550128591018587c90d2491fd66a11a4. I used openssh-service with %auto-start set to #f as well as ganeti-metad-service since both of these services are already supplied with Guix and are/can be set to auto-start?=#f. I haven't actually configured ganeti-metad-service so the service won't start successfully, but we can still see Guix attempt to start the service when it shouldn't. Below are snippets of the console output. I've attached the full versions to this email. I also attached result of building upgrade-shepherd-services.scm.drv. On a clean boot, post test.scm reconfiguration: --8<---cut here---start->8--- richard@test ~$ sudo herd status Password: Started: [...] Stopped: - ganeti-metad - ssh-daemon [...] --8<---cut here---end--->8--- While running reconfigure: --8<---cut here---start->8--- building /gnu/store/6dcgjsa8gbv6wdq8nyrdkm5sxw8zgxl3-upgrade-shepherd-services.scm.drv... [...] shepherd: Service user-homes has been started. shepherd: Starting service ganeti-metad... shepherd: Service ganeti-metad could not be started. shepherd: Service user-homes has been started. shepherd: Starting service ssh-daemon... shepherd: Service ssh-daemon has been started. To complete the upgrade, run 'herd restart SERVICE' to stop, upgrade, and restart each service that was not automatically restarted. Run 'herd status' to view the list of services on your system. --8<---cut here---end--->8--- After running reconfigure: --8<---cut here---start->8--- richard@test ~$ sudo herd status Started: [...] + ssh-daemon [...] Failed to start: ! ganeti-metad --8<---cut here---end--->8--- Guix describe output: --8<---cut here---start->8--- Generation 5Dec 27 2023 16:35:46(current) nonguix 71a53fa repository URL: https://gitlab.com/nonguix/nonguix branch: master commit: 71a53faf2e1925a309b480f17e5b836740ce54bc guix 931d893 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 931d893c550128591018587c90d2491fd66a11a4 --8<---cut here---end--->8---richard@test ~$ sudo herd status Password: Started: + NetworkManager + avahi-daemon + console-font-tty1 + console-font-tty2 + console-font-tty3 + console-font-tty4 + console-font-tty5 + console-font-tty6 + dbus-system + elogind + file-system-/boot/efi + file-system-/dev/pts + file-system-/dev/shm + file-system-/gnu/store + file-system-/run/systemd + file-system-/run/user + file-system-/sys/firmware/efi/efivars + file-system-/sys/fs/cgroup + file-system-/sys/fs/cgroup/elogind + file-system-/sys/kernel/debug + file-system-/var/cache/fontconfig + file-system-/var/lib/gdm + file-systems + guix-daemon + loopback + mcron + nscd + ntpd + pam + root + root-file-system + swap-a5da62d0-0f8e-4401-8fb6-17b284e166d0 + syslogd + term-console + term-tty1 + term-tty2 + term-tty3 + term-tty4 + term-tty5 + term-tty6 + udev + upower-daemon + urandom-seed + user-file-systems + user-processes + virtual-terminal + wpa-supplicant + xorg-server Stopped: - ganeti-metad - ssh-daemon One-shot: * host-name * sysctl * user-homes * x11-socket-directory Generation 5Dec 27 2023 16:35:46(current) nonguix 71a53fa repository URL: https://gitlab.com/nonguix/nonguix branch: master commit: 71a53faf2e1925a309b480f17e5b836740ce54bc guix 931d893 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 931d893c550128591018587c90d2491fd66a11a4 richard@test ~$ sudo herd status Started: + NetworkManager + avahi-daemon + console-font-tty1 + console-font-tty2 + console-font-tty3 + console-font-tty4 + console-font-tty5 + console-font-tty6 + dbus-system + elogind + file-system-/boot/efi + file-system-/dev/pts + file-system-/dev/shm + file-system-/gnu/store + file-system-/run/systemd + file-system-/run/user + file-system-/sys/firmware/efi/efivars + file-system-/sys/fs/cgroup + file-system-/sys/fs/cgroup/elogind + file-system-/sys/kernel/debug + file-system-/var/cache/fontconfig + file-system-/var/lib/gdm + file-systems + guix-daemon + loopback + mcron + nscd + ntpd + pam + root + root-file-system +
bug#68031: Error running Guix pull: no code for module (gnu packages ed)
Hi all, Noticed this error when running Guix pull today. Not entirely sure of the problem, but the console said to report it and I didn't notice any identical bug reports recently. Full log attached. Abridged version below. ice-9/boot-9.scm:3330:6: In procedure resolve-interface: no code for module (gnu packages ed) Computing Guix derivation for 'x86_64-linux'... guix pull: error: You found a bug: the program '/gnu/store/zd32rmipj4nqlq6rnc0mv638x3i7yvfs-compute-guix-derivation' failed to compute the derivation for Guix (version: "2a66a96634b33667a45f4493a37eef48033b7287"; system: "x86_64-linux"; host version: "49a7a95ba44e231e9e15a274f9a96de6fa012daf"; pull-version: 1). Please report the COMPLETE output above by email to . ~ $ guix pull Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Authenticating channel 'guix', commits 9edb3f6 to 2a66a96 (63 new commits)... Updating channel 'nonguix' from Git repository at 'https://gitlab.com/nonguix/nonguix'... Building from these channels: nonguix https://gitlab.com/nonguix/nonguix 71a53fa guix https://git.savannah.gnu.org/git/guix.git 2a66a96 substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% building /gnu/store/1gh4qf7bxi1x804safzcx349dyaivq0w-module-import.drv... module-import 2KiB 314KiB/s 00:00 ââââââââââââââââââââ 100.0% module-import-compiled 1.2MiB1.7MiB/s 00:01 ââââââââââââââââââââ 100.0% module-import-compiled 1.2MiB9.9MiB/s 00:00 ââââââââââââââââââââ 100.0% building /gnu/store/0wymjdji79657n3i0ya1v4x9n8yag6gz-compute-guix-derivation.drv... Backtrace: In ice-9/boot-9.scm: 222:29 19 (map1 (((guix licenses) #:prefix license:) ((guix packages)) ((guix download)) ((guix git-download)) # ?)) 222:29 18 (map1 (((guix packages)) ((guix download)) ((guix git-download)) ((guix gexp)) ((guix utils)) ((# ?)) ?)) 222:29 17 (map1 (((guix download)) ((guix git-download)) ((guix gexp)) ((guix utils)) ((guix build-system #)) # ?)) 222:29 16 (map1 (((guix git-download)) ((guix gexp)) ((guix utils)) ((guix build-system copy)) ((guix # gnu)) # ?)) 222:29 15 (map1 (((guix gexp)) ((guix utils)) ((guix build-system copy)) ((guix build-system gnu)) ((guix # #)) ?)) 222:29 14 (map1 (((guix utils)) ((guix build-system copy)) ((guix build-system gnu)) ((guix build-system #)) (#) ?)) 222:29 13 (map1 (((guix build-system copy)) ((guix build-system gnu)) ((guix build-system haskell)) ((guix # ?)) ?)) 222:29 12 (map1 (((guix build-system gnu)) ((guix build-system haskell)) ((guix build-system trivial)) ((gnu ?)) ?)) 222:29 11 (map1 (((guix build-system haskell)) ((guix build-system trivial)) ((gnu packages admin)) ((gnu # #)) ?)) 222:29 10 (map1 (((guix build-system trivial)) ((gnu packages admin)) ((gnu packages algebra)) ((gnu # base)) # ?)) 222:29 9 (map1 (((gnu packages admin)) ((gnu packages algebra)) ((gnu packages base)) ((gnu packages bash)) (#) ?)) 222:29 8 (map1 (((gnu packages algebra)) ((gnu packages base)) ((gnu packages bash)) ((gnu packages bdw-gc)) # ?)) 222:29 7 (map1 (((gnu packages base)) ((gnu packages bash)) ((gnu packages bdw-gc)) ((gnu packages check)) (#) ?)) 222:29 6 (map1 (((gnu packages bash)) ((gnu packages bdw-gc)) ((gnu packages check)) ((gnu packages #)) ((# ?)) ?)) 222:29 5 (map1 (((gnu packages bdw-gc)) ((gnu packages check)) ((gnu packages compression)) ((gnu packages #)) ?)) 222:29 4 (map1 (((gnu packages check)) ((gnu packages compression)) ((gnu packages dbm)) ((gnu packages ed)) # ?)) 222:29 3 (map1 (((gnu packages compression)) ((gnu packages dbm)) ((gnu packages ed)) ((gnu packages #)) ((?)) ?)) 222:29 2 (map1 (((gnu packages dbm)) ((gnu packages ed)) ((gnu packages fontutils)) ((gnu packages gcc)) ((?)) ?)) 222:17 1 (map1 (((gnu packages ed)) ((gnu packages fontutils)) ((gnu packages gcc)) ((gnu packages gettext)) # ?)) 3330:6 0 (resolve-interface (gnu packages ed) #:select _ #:hide _ #:prefix _ #:renamer _ #:version _) ice-9/boot-9.scm:3330:6: In procedure resolve-interface: no code for module (gnu packages ed) Computing Guix derivation for 'x86_64-linux'... guix pull: error: You found a bug: the program '/gnu/store/zd32rmipj4nqlq6rnc0mv638x3i7yvfs-compute-guix-derivation' failed to compute the derivation for Guix (version:
bug#65463: Herd `fport_write: Broken pipe` error when running `guix home reconfigure`
Did some more testing and I was able to find a workaround for my version
of this issue, although I don't know if it'll solve it for others. TL;DR
is I changed my login shell from fish back to bash.
The system configuration for the nonworking machine was using fish
`(user-account (shell (file-append fish "/bin/fish") ...)`. There seems
to be some unintended behavior with executing the `on-first-login`
script in `.profile` using fish.
The stock `config.fish` sources $HOME/.profile, which executes the
.guix-home/on-first-login script via fenv source $HOME/.profile. Herd
seems to start up nicely, but somehow stdout for herd winds assigned to
a pipe without a reader between initialization and spawning gpg-agent.
initialization writes to the logfile just fine regardless of if you're
using fish or bash:
--8<---cut here---start->8---
2023-11-16 14:17:15 Starting service root...
2023-11-16 14:17:15 Service root started.
2023-11-16 14:17:15 Service root running with value #t.
2023-11-16 14:17:15 Service root has been started.
2023-11-16 14:17:15 Daemonizing...
2023-11-16 14:17:15 Restarting signal handler.
2023-11-16 14:17:15 Now running as process 936.
2023-11-16 14:17:15 Starting services...
2023-11-16 14:17:15 Configuration successfully loaded from
'/gnu/store/kzh1x4y030drw0jrdk08nynvvyasm3c1-shepherd.conf'.
2023-11-16 14:17:15 Starting service gpg-agent...
2023-11-16 14:17:15 Service gpg-agent has been started.
2023-11-16 14:17:15 Service gpg-agent started.
2023-11-16 14:17:15 Service gpg-agent running with value (("ssh" .
#) ("browser" . #)
("extra" . #) ("std" . #20>)).
2023-11-16 14:17:15 Successfully started 2 services in the background.
--8<---cut here---end--->8---
When using bash instead of fish, stdout (file descriptor 1) points to
/dev/null so the write does not fail. Another write is for
$HOME/.local/state/shepherd.log.
bash fds
--8<---cut here---start->8---
$ ls -l /proc//fd)
lr-x-- 1 richardusers64 2023-11-16 14:17 0 ->
/dev/null
l-wx-- 1 richardusers64 2023-11-16 14:17 1 ->
/dev/null
l-wx-- 1 richardusers64 2023-11-16 15:04 2 ->
/home/richard/.local/share/sddm/xorg-session.log
l-wx-- 1 richardusers64 2023-11-16 14:17 6 ->
/home/richard/.local/state/log/shepherd.log
// ...
--8<---cut here---end--->8---
bash login shell strace of herd, right after running $ gpg
--card-status:
--8<---cut here---start->8---
write(1, "Spawning systemd-style service
/gnu/store/2zgdxhbnkz8fgsb1l4xydm3nbvj66mih-gnupg-2.2.39/bin/gpg-agent.\n",
103) = 103
newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0444,
st_size=3536, ...}, 0) = 0
write(6, "2023-11-16 14:36:29 Spawning systemd-style service
/gnu/store/2zgdxhbnkz8fgsb1l4xydm3nbvj66mih-gnupg-2.2.39/bin/gpg-agent.\n",
123) = 123
// happy success messages
--8<---cut here---end--->8---
However, when fish is in charge of executing on-first-login, stdout and
stderr for the user shepherd get directed to a pipe instead of
/dev/null.
fish fds, both stdout and stderr point to a pipe:
--8<---cut here---start->8---
$ ls -l /proc//fd)
lr-x-- 1 richardusers64 2023-11-16 14:47 0 ->
/dev/null
l-wx-- 1 richardusers64 2023-11-16 14:47 1 ->
pipe:[41039]
l-wx-- 1 richardusers64 2023-11-16 14:47 2 ->
pipe:[41039]
l-wx-- 1 richardusers64 2023-11-16 14:47 6 ->
/home/richard/.local/state/log/shepherd.log
// ...
--8<---cut here---end--->8---
fish login shell strace of herd:
--8<---cut here---start->8---
21:46:43 write(1, "Spawning systemd-style service
/gnu/store/2zgdxhbnkz8fgsb1l4xydm3nbvj66mih-gnupg-2.2.39/bin/gpg-agent.\n",
103) = -1 EPIPE (Broken pipe)
--8<---cut here---end--->8---
Details of what processes are using the pipe: (i.e. nothing else is
using the pipe. Which makes sense for a broken pipe error at least...)
--8<---cut here---start->8---
$ lsof -n | grep -w 41039
(standard input):shepherd 991 richard1w FIFO
0,14 0t0 41039 pipe
(standard input):shepherd 991 richard2w FIFO
0,14 0t0 41039 pipe
--8<---cut here---end--->8---
What confuses me about this situation is judging from that bash behavior
pipes shouldn't be involved at all for stdin/stdout/stderr. There's also
an discrepancy in that stderr for bash points to xorg-session.log while
for fish it points to the same pipe as stdout. It would be interesting
to know if other users who are
