bug#66315: guile-ini is missing a dependency on guile-lib

Hi, I think guile-ini package is missing a dependency on guile-lib package. $ guix shell -C guile guile-ini -- guile -c '(use-modules (ini))' Backtrace: In ice-9/boot-9.scm: 3564:26 19 (_) In unknown file: 18 (primitive-load-path "ini/fsm" #) In

bug#66268: Guix makes invalid assumptions regarding guile-git guarantees leading to guix pull failing

On 2023-09-30 17:48:55 +0200, Simon Tournier wrote: > Hi, > > Hum, the updates seem: > > + libgit2 on Feb 17 2023, > + guile-git on May 15 2022. > > (See 8d8e1438ae5a2e50005b500dacd0a26be540fe69 and > b6bfe9ea6a1b19159455b34f1af4ac00ef9b94ab) > > And some commits with large body are around:

bug#66305: Error with recursive git checkout

Workaround: by rebooting the machine to an older generation (and therefore an older guix-daemon, with Guix at 4f35ff1275e05be31f5d41464ccf147e9dbfd016), the recursive git-fetch works. signature.asc Description: PGP signature

bug#66309: [Hurd] ext2fs crash while building GCC

Hello! As discussed on IRC today, I tried to build GCC natively by offloading it to my childhurd. Turns out that it crashes the system after a while; I could get this interesting hint via VNC: I wouldn’t be surprised if it happens under memory pressure. This childhurd is configured with

bug#66306: Too many services depend on ‘networking’

I believe too many services depend on ‘networking’ for no good reason. There’s a good discussion of the problem at: https://systemd.io/NETWORK_ONLINE/ For example, bitlbee, ntpd, hurd-vm, and avahi-daemon all depend on ‘networking’. Is it always justified? For example, avahi-daemon

bug#64653: ‘static-networking’ fails to start

Ludovic Courtès skribis: > [ 121.281600] shepherd[1]: Service user-homes has been started. > [ 121.282538] shepherd[1]: Service user-homes started. > [ 121.368316] ipmi_si IPI0001:00: Using irq 10 > [ 121.405790] ipmi_si IPI0001:00: IPMI message handler: Found new BMC > (man_id: 0x0002a2,

bug#66305: Error with recursive git checkout

Hi. With Guix at 47d0346553fdad9795c9390a60944ccaad7e5255, I'm unable to build a package (see attached patch) requiring a recursive git-fetch to get the sources: --8<---cut here---start->8--- $ ./pre-inst-env guix build bladerf The following derivations will

bug#66304: exim vulnearable to CVE-2023-42115 et al

Hi Guix, Exim currently has unpatched vulnearabilities regarding its EXTERNAL Auth driver as well as its SPA/NTLM authenticator. According to the project[0] prospective fixes seem to be around the corner. We should probably bump the Exim version we ship to a non-vulnearable version as soon as

bug#66268: Guix makes invalid assumptions regarding guile-git guarantees leading to guix pull failing

Hi, Hum, the updates seem: + libgit2 on Feb 17 2023, + guile-git on May 15 2022. (See 8d8e1438ae5a2e50005b500dacd0a26be540fe69 and b6bfe9ea6a1b19159455b34f1af4ac00ef9b94ab) And some commits with large body are around: + 7b45ead9ec40a5ea1ef8332d55c2bb4beff85eb5 from Jul 18 2023 +

bug#51000: The Web manual situation is still needlessly confusing

Hi, On Mon, 04 Oct 2021 at 00:12, Tobias Geerinckx-Rice wrote: > Instead: > > - We should make the ‘devel’ > version, and move the stable version to to a versioned URL like > . Considering this

bug#66189: [gnu.org #1975364] Broken link in Guix manual.

Hi, > Le Jeu 14 Sep 2023 09:14:20, yuval.lan...@gmail.com a écrit : >> https://ftp.gnu.org/gnu/guix/guix-system-vm-image-e5f7c14.x86_64-linux.qcow2 >> >> in >> >> https://guix.gnu.org/manual/devel/en/html_node/Running-Guix-in-a-VM.html >> >> is broken. Yes, the link is automatically

bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor

Hello, Ricardo Wurmus skribis: > IT had installed some DoS attack protection thing for the DMZ with > different thresholds based on past access patterns. > > Upon my request they have now disabled this completely for our IPs > corresponding to ci.guix.gnu.org and its sibling node. I’m late to