IRC channel logs

<dcunit3d>apoorv569: make sure you update/close your issue on codeberg

<dcunit3d>would there be interest in a `menuconfig` package? it's a version of kconfig that lets you build a linux kernel config out-of-tree https://docs.zephyrproject.org/latest/build/kconfig/menuconfig.html

<noxi>hi hi, I'm trying to use an HP printer and I get a message "Printer <printer> requires the '/gnu/store/[...]-cups-2.4.14/lib/cups/filter/hpcups' program but it is not installed". obviously, cups isn't supposed to look for the filter there, but why does it do?

<dcunit3d>i hadn't tried upstreaming this bc the main issue for me is that there isn't proper release tracking.

<dcunit3d>the source is pretty simple though https://github.com/dcunited001/ellipsis/blob/master/dc/dc/packages/linux.scm#L18

<dcunit3d>noxi: on nix i have ./lib/cups/backend/rasterto{epson,hp,...}

<dcunit3d>but nothing like hpcups in there

<noxi>hpcups is from hplip/hplip-minimal

<noxi>what confuses me is that hplip is already by default in cups-service-type's config

<noxi>so it should be located

<dcunit3d>is it in `tree -a /gnu/store/[...]-cups-2.4.14/lib`?

<noxi>> is it in `tree -a /gnu/store/[...]-cups-2.4.14/lib`?

<noxi>no, it's another package

<switchy>is there any configuration of the initramfs? if I wanted hibernation to/from a swapfile on an encrypted root, what would I have to do? or would it kind of "just work" becuase the luks unlock is early enough?

<dcunit3d>switchy: see https://guix.gnu.org/manual/devel/en/guix.html#Initial-RAM-Disk-1 and https://guix.gnu.org/manual/devel/en/guix.html#Swap-Space-1

<dcunit3d>it implies that hibernate works from an encrypted ramdisk, but idk. i never got that working (i didn't really try)

<dcunit3d>this section says that "procfs/luks modules are loaded automatically when encrypted devices are declared via `luks-device-mapping`" https://guix.gnu.org/manual/devel/en/guix.html#Automatic-LUKS-Master-Key-Passing

<dcunit3d>so you would need the `resume` kernel argument, some elogind configuration for hibernate, potentially some power service configuration for hibernate/suspend.

<dcunit3d>oof... those procfs/luks modules are for grub actually, so idk.

<dcunit3d>(resume-if-hibernated device) gets called "after loading (storage) modules, but before any on-disk file systems have been mounted" https://codeberg.org/guix/guix/src/commit/ae0aa97e5438af2b39e582a6fb88b72361c3d3ea/gnu/build/linux-boot.scm#L134

<dcunit3d>and initrd is "auto-populated with all the kernel modules necessary for FILE-SYSTEMS and for the given options. Additional kernel modules can be listed in LINUX-MODULES. They will be added to the initrd, and loaded at boot time in the order in which they appear." https://codeberg.org/guix/guix/src/commit/ae0aa97e5438af2b39e582a6fb88b72361c3d3ea/gnu/system/linux-initrd.scm#L419-L422

<dcunit3d>so it would take some work & validation switchy

<switchy>dcunit3d: awesome, thanks! I'll see if I can cobble something together

<futurile>morning all

<folaht>futurile, good morning

<folaht>Where can I find a list of argument values I can give for the cargo-build-system in defining packages?

<trev>folaht: source code XD

<folaht>trev, thanks

<qzdl>:( when you run out of disk in /tmp/guix-inst

<qzdl>time to get weird with mounts

<jlicht>Recently I keep seeing "warning: channel 'foobar' is not trusted" in my time-machine invocations; any (new) manual steps I missed?

<Alavi_me>Hi people

<Alavi_me>So about the recent pull vuln https://guix.gnu.org/en/blog/2026/guix-substitute-pull-vulnerabilities/

<Alavi_me>I did the steps. I checked for vulns, I had 1,3,4 I think, I upgraded with `sudo --login guix pull --no-substitutes`

<Alavi_me>and then restarted my whole system (guix is installed on top of arch)

<Alavi_me>I run the test again, 4 is still vulnerable. What do I do?

<futurile>folaht: Cargo/rust build-system is a bit different. Have a look in the manual at the Gnu build system details, and then you'll have to look at the source code (as trev said). There's also some details in the Cookbook article

<futurile>Alavi_me: check where your guix daemon's systemctl is getting Guix from. I assume it will be the root one but just in case

<Alavi_me>futurile: how do I check that?

<futurile>Alavi_me: look at the service file for the guix service

<futurile>it's normally /etc/systemd or soemthing like that

<Alavi_me> https://paste.rs/Dgb9Z

<Alavi_me>ExecStart=/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon ?

<futurile>ok so you know it's the root guix-daemon

<futurile>so you could check what commit that root's guix is on with guix describe

<futurile>to make sure you'r guix pull as root was successful

<Alavi_me>it points to commit: 9a34a395501c19b0661d1b4a3460c12b95f60f20

<Alavi_me>which isn't the latest

<futurile>Alavi_me: ok so your guix pull didn't work

<Alavi_me>I'm gonna try `sudo --login guix pull --no-substitutes` again then?

<Alavi_me>but it didn't show any signs of failure the first time

<Alavi_me>And it took couple of hours T-T

<futurile>guess so - something didn't work if you're not on the latest commit - I would sudo up into root so you can do it all directly including doing a guix describe after the pull to check it

<Alavi_me>Wierd. `sudo guix describe` shows commit: 436aaa67d19457e9a4ce0ce5d4d6fd792953eb66 which I can't find in guix commits!

<ngz>Hello. I encourter a nightmarish problem. I use the unpriviledged daemon on a foreign distro, and I updated it during the time frame where it was broken (substitutes unavailable). And… I guix gc’ed before realizing it. So I cannot revert the daemon to a previous state. I tried sudo -i guix pull --no-substitutes, but after hours of compilation, it consistently fails on guile-3.0.9 tests.

<ngz>What could I try?

<Alavi_me>futurile: pulled again, `sudo guix describe` shows commit: a575cefb3ab29ce6b36eb84757b05b96027fc701 and `guix describe` still shows commit: 9a34a395501c19b0661d1b4a3460c12b95f60f20

<Alavi_me>I don't get it.

<kestrelwx>Did you `sudo guix pull`?

<Alavi_me>kestrelwx: `sudo --login guix pull --no-substitutes`

IRC channel logs

2026-07-08.log