bug#59196: guix pull fails on A20-OlinuXino-LIME2-eMMC
I've tried to cross compile an image but I end up with this build
failure:
> $ zcat
> /var/log/guix/drvs/fl/nrxka21fgd5hpbchzp3fyv01xyrs2v-linux-modules.drv.gz
> Backtrace: 5 (primitive-load
> "/gnu/store/lm7mjsdx6p16pbavv80hpf561df?") In ice-9/eval.scm:
> 619:8 4 (_ #f)
>626:19 3 (_ #)
>293:34 2 (_ #(# #))
> In srfi/srfi-1.scm:
>586:17 1 (map1 ("ahci" "usb-storage" "uas" "usbhid" "hid-gene?"
> ?)) In gnu/build/linux-modules.scm:
> 257:5 0 (_)
>
> gnu/build/linux-modules.scm:257:5: kernel module not found "ahci"
> "/gnu/store/is9dg680cwlzhj6k6j0vxz86zwkqvx5m-linux-libre-6.0.8/lib/modules"
Though I don't know if it is related or not to your issue.
Denis.
pgp79tcJHK07q.pgp
Description: OpenPGP digital signature
bug#58926: Shepherd becomes unresponsive after an interrupt
Hello! Ludovic Courtès skribis: > These fresh Shepherd commits install a non-blocking ‘system*’ replacement: > > 975b0aa service: Provide a non-blocking replacement of 'system*'. > 039c7a8 service: Spawn a fiber responsible for process monitoring. > > We’ll have to do more testing and probably go for a 0.9.3 release soon. Shepherd commit ada88074f0ab7551fd0f3dce8bf06de971382e79 passes my tests. It definitely solves the wireguard example and similar things (uses of ‘system*’ in service constructors/destructors); I can’t tell for sure about nginx because I haven’t been able to reproduce it in a VM. I’m interested in ways to reproduce it. It does look like we could go with 0.9.3 real soon now. Ludo’.
bug#59261: castor 0.8.18 build failure
build log here: http://ix.io/4fU9 I was just running routine upgrades and was stopped on this, so reporting.
bug#59256: Emacs-guix tab-completion returns gexp error
To Guix, Emacs-guix tab-completion or M-x guix-command returns: Error in evaluating guile expression: ice-9/boot-9.scm:1685:16: In procedure raise-exception: /home/crono/.config/guix/current/share/guile/site/3.0/guix/scripts/deploy.scm:177:7: Unknown # object: "#~" Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(emacs-guix) [1]> It seems to me that the repl doesnt have the gexp module loaded? I have tried changing the guix-load-path and guix-compiled-load-path for emacs. As well as loading the gexp module in both the emacs-guix and internal repl. For the "is this reproducible" question just in case: https://logs.guix.gnu.org/guix/2022-11-08.log#204945 https://logs.guix.gnu.org/guix/2022-11-13.log#195613 Thank you, -Joshua
bug#56290: Guix is at version 0, according to "guix --version"
Hi, Efraim Flashner skribis: > I've hunted this down using 'guix time-machine' and it looks like the > first commit where the version string returns 0 is > 076e825dc5d585943ce820a279fffe4af09757fb. On that > commit 'guix time-machine --commit=076e... -- --version' returns 0 and > on the commit before that 5996aab354831d942b10253bc70217a4f2e6a247 we > get the commit as the version string. > > Looking at the commits I'm guessing that the 076e825d commit interacts > with the af57d1bf commit 2 before it, and whether the guile is guile-3.0 > or guile-final or guile-3.0-latest. Fun! Turns out this was caused by cross-module inlining: the initial config.scm generated in ‘compiled-guix’ does (define %guix-version "0"), and that got inlined in (guix ui). Fixed in 54003af85cc5b689bd328b30617c93ed2f5fd647! Ludo’.
bug#59196: guix pull fails on A20-OlinuXino-LIME2-eMMC
Quoting Denis 'GNUtoo' Carikli (2022-11-13 21:54:49) > On Sun, 13 Nov 2022 11:48:18 +0100 > Tanguy LE CARROUR wrote: > > > Sat, 12 Nov 2022 16:40:20 +0100 > > > Does it also fails with 'guix pull -M 1 -c 1' ? > [...] > > I'll try on a brand new SD card, because the one I used is a bit old. > > > > Any other ideas about what might have gone wrong? > The command I gave sometimes works on 32bit machines with a low > amount of RAM, so it was worth trying. > > Unfortunately here I'm out of ideas, other people with more experience > in Guix might know better. > > Also note that I also do have an A20-OlinuXino-LIME2-eMMC, so I might > be able to run tests too if they are fast to do. Maybe I should try to > cross compile a rootfs and see if it boots. > > Long time ago it booted if I recall well, and then it stopped working > but I didn't take the time to track the regression down or to try again. Good to know. I don't actually need Guix System on my SBC, but you know, I have it on my computer @work, @home, on my laptop… so I thought to myself that it would make more sense to have it everywhere! Today my computers, tomorrow the world! 😎 -- Tanguy
bug#59278: how gcc-toolchain can depends a package who doesn't exists?
in version c81457a5883ea43950eb2ecdcbb58a5b144bcd11 of guix, gcc-toolchain depends gcc: ``` $ DEFAULT_CHANNELS=/tmp/default_channels.scm $ echo "%default-channels" > $DEFAULT_CHANNELS # I force guix to use only %default-channels here $ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11 -C $DEFAULT_CHANNELS -- search gcc-toolchain guile: warning: failed to install locale name: gcc-toolchain version: 9.3.0 outputs: out debug static systems: x86_64-linux i686-linux dependencies: binutils@2.32 gcc@9.3.0 glibc@2.29 ld-wrapper@0 ``` However, I can't find gcc package in this version of guix ``` $ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11 -C $DEFAULT_CHANNELS -- search gcc # no found gcc # guix install failure message confirm that gcc doesn't exist in commit c81457 $ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11 -C $DEFAULT_CHANNELS -- install gcc -p ~/opt/python-dev_3_7 guile: warning: failed to install locale guix install: error: gcc: unknown package ``` in commit c81457, how gcc-toolchain can depends a package who doesn't exists?
bug#59278: how gcc-toolchain can depends a package who doesn't exists?
Hi, This is not a bug. The gcc package exists, but is hidden from CLI on purpose because you shouldn't install it and use it directly. You should use gcc-toolchain instead. Le 15 novembre 2022 00:53:32 GMT+01:00, bbb ee a écrit : >in version c81457a5883ea43950eb2ecdcbb58a5b144bcd11 of guix, gcc-toolchain >depends gcc: >``` >$ DEFAULT_CHANNELS=/tmp/default_channels.scm >$ echo "%default-channels" > $DEFAULT_CHANNELS ># I force guix to use only %default-channels here >$ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11 -C >$DEFAULT_CHANNELS -- search gcc-toolchain >guile: warning: failed to install locale >name: gcc-toolchain >version: 9.3.0 >outputs: out debug static >systems: x86_64-linux i686-linux >dependencies: binutils@2.32 gcc@9.3.0 glibc@2.29 ld-wrapper@0 >``` > > >However, I can't find gcc package in this version of guix >``` >$ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11 -C >$DEFAULT_CHANNELS -- search gcc ># no found gcc > ># guix install failure message confirm that gcc doesn't exist in commit >c81457 >$ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11 -C >$DEFAULT_CHANNELS -- install gcc -p ~/opt/python-dev_3_7 >guile: warning: failed to install locale >guix install: error: gcc: unknown package >``` > >in commit c81457, how gcc-toolchain can depends a package who doesn't >exists?
