bug#64073: libvirtd requires restart to function

Hi, Christian Miller skribis: > Currently libvirtd does not work without running "sudo herd restart > libvirtd". Upon starting virt-manager I can't connect to the socket > but if I restart libvirtd it works fine. > > I tested the 1.4.0 image in a VM and there is no issue. After that I > did a gu

bug#64074: guix [COMMAND] --load-path does not check if path is valid

Hi, Christian Miller skribis: > User can set load path with -L or --load-path in commands like guix > build, guix time-machine and so on. But this flag does not check if > the path is actually a valid directory. You can point to a directory > that doesn't even exist on the filesystem. Indeed.

bug#64015: guix refresh fails to find latest version for libuv

Hi, Maxim Cournoyer skribis: > Attempting to use 'guix refresh libuv' says: > > $ LANG=C guix refresh libuv > gnu/packages/libevent.scm:117:13: 1.44.2 is already the latest version of > libuv > > The release form is here: https://dist.libuv.org/dist/v1.45.0/; there's > also a release tag in git

bug#63852: ‘guix-package-cache.drv’ eats all your memory with ‘guix-cran’

Ludovic Courtès skribis: > Ludovic Courtès skribis: > >> Ludovic Courtès skribis: >> >>> It goes OK until building >>> /gnu/store/6rfaqfq693vda59a55asc4wjjg52ilns-guix-package-cache.drv, which >>> consumes memory until it gets OOM-killed. >> >> The culprit is easily found (here on just the 22K

bug#63197: video acceleration/libva segfaults caused by stale mesa shader cache

Hi Maxim, I learned about this issue today Maxim Cournoyer writes: [...] >> After tracing the process, I noticed that the last thing it did was >> loading its mesa shader cache, stored under: >> >> ~/.cache/mesa_shader_cache >> >> Deleting that directory resolved the issue. >> >> It seems that

bug#64031: Guix system entirely broken by updating second runc or by accidental hard reset

Steven Roose skribis: > Ok, I don't know how to close this issue, but I managed to fix it with > guix package --roll-back. I took me so long to find that possibility > because both `guix system` and `guix home` have a `roll-back` > *command* while in packages it's a flag. I thought it was for > i

bug#64014: guix pack regression

Hi, André A. Gomes skribis: > I've produced a guix pack with the same command that I've always used > (which includes passing the -RR flag), but I now get the following > message: > > bwrap: No permissions to creating new namespace, likely because the kernel > does not allow non-privileged user

bug#64014: guix pack regression

Ludovic Courtès writes: > I suppose you might get this is you do ‘guix pack -R bubblewrap’ and > then try to run ‘bwrap’ from that pack: the ‘bwrap’ executable already > runs in a separate user namespace and might be unable to create one (?). Hi Ludovic, Thanks for the answer. You've helped me

bug#54812: ‘guix system reconfigure’ closes SSH connections

Hi Christine, Christine Lemmer-Webber skribis: > Christine Lemmer-Webber writes: > >> Ludovic Courtès writes: >> >>> Ludovic Courtès skribis: >>> With OpenSSH turned into inetd style in commit 808b9e850491c7b1d867a5f1f4d5ee6f61f345d4, the service upgrade code used by ‘guix syst

bug#51071: OpenFOAM 4.1 fails to build

Ludovic Courtès skribis: > On 1327ec822fa6dd396e979efd8d4e1f7479f1d5b3 (current master), > OpenFOAM 4.1 fails to build (from > ): It builds fine now: --8<---cut here---start->8--- $ guix weather openfoam computing

bug#33968: errors in shepherd service constructors are not logged and lead to misleading status

Florian Dold skribis: > when defining a service type that extends shepherd-root-service-type and > the 'start' function of the shepherd-service definition contains an > error, the error is silently ignored. No log output is generated at all. [...] > I generally feel like the state machine for

bug#64057: qemu-guest-agent-shepherd-service probably lacks (requirement '(udev))

Hi, Yann Dupont skribis: > Hi all, we've noticed that qemu-guest-agent doesn't start reliably on virtual > machines generated by guix system. > the log file shows the following: > > 2023-06-12 14:36:14 1686573373.873765: critical: error opening channel > '/dev/virtio-ports/org.qemu.guest_agen

bug#64090: Cannot compute a file with a G-exp

Hi, I seem to be having two issues with writing a G-exp that computes a file. The first issue I ran into is that source-module-closure returns null no matter what modules I give it. ``` scheme@(guile-user)> (source-module-closure '((ice-9 popen) (ice-9 atomic) (ini) (json))) $8 = () ``` This se