IRC channel logs

<ieure>Heterochromium, btrfs is supported, I have run it on a few systems (Guix and not) without issues, but have never pushed it hard. It seems like it's harder to operate at high scale, requiring periodic rebalances to perform. And the rebalances have a big negative impact on your primary workload.

<ieure>My most heavily used filesystem is the ZFS pool for my NAS.

<ieure>I appreciate that whatever stuff it needs to do to maintain the data is scheduled in a way that doesn't have any impact on my workload. I even rotated out every disk in the pool while it was online and serving, without noticeable delay for anything (I'm sure there was some stuff in the Grafana graphs, though).

<Heterochromium>ieure: Guix supports ZFS?

<Heterochromium>How do I get KVM working? I'm trying to use QEMU.

<Heterochromium>I got `Could not access KVM kernel module: Permission denied`.

<sham1>And you're sure you're a) in the kvm group, and b) that the kernel module has actually been enabled

<Heterochromium>I'll reconfigure to get myself into group `kvm`. How do I check if the kernel module is enabled?

<sham1>Do you see anything related to kvm if you use lsmod

<Heterochromium>sham1: I got `kvm_intel` and `kvm` from `lsmod | grep kvm`.

<sham1>Then you have the module. IIRC now the only thing you need is the group membership

<ieure>Heterochromium, Guix supports ZFS, but not well. My ZFS box still runs Debian, and I expect it to stay that way for a good while.

<gkoebel>Hi, I'm getting 404's for the ftp servers for GUIX System. Can anyone else please confirm? https://ftp.rediris.es/mirror/GNU//gnu/guix/guix-system-install-1.5.0.x86_64-linux.iso

<gkoebel>That link is not a mistype it appears to be a redirect from the link on https://guix.gnu.org/en/download/

<gkoebel>So https://ftpmirror.gnu.org/gnu/guix/guix-system-install-1.5.0.x86_64-linux.iso redirects to the broken link

<gkoebel>I can reach the ftp server directly fine so I think its just an issue in whatever is routing the request

<gkoebel>Directly meaning https://ftp.gnu.org/gnu/guix/

<cellarweasel>I posted a couple of days ago but I found that ftp.gnu.org works and frpmirror.gnu.org is just down and the gnu@gnu.org email address has been notified. It's also an issue in the issue tracker.

<cellarweasel> https://issues.guix.gnu.org/81789

<cellarweasel>if you just edit the guix-install.sh there is a variable that's easy to find

<cellarweasel>I think only new folks are following the tutorial so I don't know who to get a hold of to change the manual.

<gkoebel>thx for the info

<Heterochromium>Does anyone know how to open LVM-on-LUKS upon booting the system? I can't figure out what exactly I need to supply to the config.

<PuercoPop>Its also hard to detect that that is the issue as the script guix-install.sh does't error out in that case

<jlicht>hey guix

<apteryx>jlicht: o/

<civodul>o/

<apteryx>hello :-)

<jlicht>if any of the resident gexp wizards have some time to peek at https://codeberg.org/guix/guix/issues/11120, that'd be swell.

<apteryx>I had a quick look, it looks reasonable, though that "cross-compiled package needs itself in native inputs" situation I've not encountered myself before (but I rarely cross-build things)

<jlicht>apteryx: what confused me is that other cross-comp stuff I tried seems to work just fine /w the @73 version, so the actual underlying issue may be more complex than I've grokked

<jlicht>although it is cool that it is possible to write "recursive" packages, in a sense :-)

<apteryx>agreed, it's a surprising property

<civodul>jlicht: it should work :-)

<civodul>i commented with a slightly more elaborate response

<civodul>note that ‘guile’ does that: it needs a native build of itself to be cross-compiled

<PotentialUser-39>hello there

<PotentialUser-39>Don't know if I should put this here

<PotentialUser-39>I tried to install guix this morning and the URL https://ftpmirror.gnu.org/gnu/guix/ in guix-install.sh seems to lead to a broken link

<PotentialUser-39>and install don't work...

<jlicht>civodul, apteryx: thanks! Feel free to re-ponder those orbs ;-)

<civodul>PotentialUser-39: as a workaround, could you modify guix-install.sh to refer to ftp.gnu.org instead of ftpmirror.gnu.org?

<PotentialUser-39>install still blocks with messages for both links :

<PotentialUser-39>2026-09-09 11:23:33 URL:https://mirrors.dotsrc.org/gnu// [58277] -> "-" [1]

<PotentialUser-39>2026-09-09 11:23:56 URL:https://ftp.gnu.org/ [9405] -> "-" [1]

<bremner>if "guix build --system=armhf-linux

<bremner>succeeds. but ./pre-inst-env guix build --system=armhf fails with guix system: error: /home/bremner/software/guix/gnu/packages/web.scm:6184:2: package `jq@1.8.2' has an invalid input: ("_" #<syntax-transformer oniguruma>), it that a bug in jq packaging or something else?

<bremner>I'm in a checkout of (todays'

<bremner>oof.

<bremner>today's master, with one patch to gnupg

<bremner>I guess "guix build --system=armhf-linux" doesn't actually succeed because it needs the gnupg patch in question.

<mfg>bremner: sry, I had to go yesterday. It seems it still is the same problem?

<mfg>Do you have an actual armhf-linux machine or are you using qemu_binfmt? If you use qemu I can try out your patch and see if I can reproduce the problem here :)

<bremner>I'm using qemu_binfmt, although I just realized I probably want aarch64-linux, not armhf_linux

<bremner>patch is in https://codeberg.org/guix/guix/issues/10932 if you want to try

<mfg>I'll try it out.

<noxi>managed to flash an arduino uno with guix today btw

<noxi>pretty cool

<mfg>bremner: I also don't think the error has omething to do with your patch actually. The error is because there has been added the deprecation warning telling you that oniguruma was moved into a different module, that warning is iiuc a syntax-transformer, hence the error message.

<mfg>I'm currently building the checkout, can tell you soon if i have the same error

<mfg>bremner: So here it seems to build fine with pre-inst-env. I did: Add a worktree for this, guix shell -D guix, ./bootstrap, ./configure --localstatedir=/var, make -j11, ./pre-inst-env guix build --system=armhf-linux libgpg-error on a x86_64 machine. Currently builds, so is way past the error you encountered. THough not finished yet.

<mfg>Since I used a new worktree I have a pristine repo state, some lingering thing must be the cause for the error you see, I can't imageine something else.

<mfg>successfully built /gnu/store/86nyln5lxnjvsdqipaffd2pkinkh7irr-libgpg-error-1.61.drv

<apteryx>codeberg is not in shape tonight

<apteryx>noxi: neat!

<jlicht>Is a failed package build during compilation due to SIGTERM on pulls.ci.guix.gnu.org something in my sphere of influence as a packager, or something outside of my control entirely?

<jlicht>it seems to happen consistently for the librewolf build I'm tracking

<untrusem>jlicht, librewolf? your custom one? or the pr from ieure?

<jlicht> untrusem: just librewolf being rebuilt as a consequence of my node-lts changes

<jlicht>or rather, not rebuilding, :-)

<untrusem>someone with ci access would be able to help

<bremner>mfg: ok, thanks for investigating. I'll have a look in a few hours with a fresh worktree or clone

IRC channel logs

2026-09-09.log