IRC channel logs
2025-11-01.log
back to list of logs
<pomel0>but I feel this may be may last one for a while? I just don't understand how to set flags under (file-system) in config.scm <luca>tbh I also had a bit of trouble finding that link. Just lucky I knew roughly the name and that it exists <pomel0>I tried doing `(file-system (flags `(("user"))))` <pomel0>there's more code in file-system but that's what's failing when I try reconfiguring <ColdSideOfPillow>namely, it will choose a random background during build time, this then choice will remain static throughout the shepherd service's runtime <rly>ColdSideOfPillow: instead of doing that computation inside of the simple-service definition, where it will be evaluated once when you evaluate your config.scm, you need that logic to be executed by the cron job you are creating. <ColdSideOfPillow>rly: Yes, I realized that that was one way to do it, but I was hoping for a method in Scheme haha <rly>yeah I don't know of any shortcuts off of the top of my head, I would probably just iterate over all of the images in the list at build time and add them to the store, then have the cron job do the random selection between the different store paths <bhoot>Hello all! I run a Guix system with GNOME as the DE. How do I find out what causes `qtbase-5.xx.xx-debug` to be pulled in as a dependency during a `guix system reconfigure`? <Rutherther>bhoot: unfortunately there is no definitive way. What should work most of the time is "guix system build --derivation" and then "guix graph" on it <bhoot>Ok. That's a bit problematic. I think I even saw `plasma` packages getting pulled in. Qt, I can imagine being depended on somewhere, but I don't have any packages which should depend on plasma. <trev>i would imagine some software with a gui would depend on that even if you're not using kde. no gentoo use-flags here :] <csantosb>Good morning Guix ! I'm upgrading a couple of Python packages, and the questions arises about propagating optional dependencies, do we ? <bhoot>yeah that sucks. I am disproportionately getting bothered by this. Probaby will have to grep through the modules to find the culprit. <trev>bhoot: the graph isn't showing it? <bhoot>trev: oh yes. Let me try that first. <bhoot>Rutherther, trev: guix system build --derivation will still download the substitute binaries and build the non-substitutable packages, right? I am on a weak internet temporarily. <bhoot>Any way to just build the derivation without the build/download? <Rutherther>no, the derivation needs its inputs to be placed in the store, so there is no way to get it without getting the dependencies it refers to <bhoot>Thanks. I will try it out later. <bhoot>That makes sense. Anything guix computes, it would base it on the store. <Rutherther>in your case, you might try running this procedure extract-all-packages on your operating-system https://paste.debian.net/1403944/. Then you can put output of this procedure into a dummy package as propagated-inputs. And run guix graph on this package <Rutherther>but again it's not going to list completely all packages, similarly to the --derivation, but even worse <Rutherther>unfortunately this part of guix is not so introspectable due to the structure of the gnu/system, the scripts etc. that join together multiple things that are never 'joined' together, but rather built separately when you do reconfigure <Rutherther> https://paste.debian.net/1403947/ ie. like this, but instead of full-installer-os put your own operating system. Assuming this file is named a.scm (or change the define-module accordingly) and you can then do just "guix graph --path my-os-packages plasma" (or whatever the package you are interested in). It will show you through which packages it goes and then you can track it back, ie. to a service of a package in your packages list <futurile>csantosb: no, we try to avoid propagation as much as possible because it complicated the dependency graph. It lands up in a situation where a user cannot upgrade something because a propagated dependency conflicts with another propagated dependency. <csantosb>futurile: This was my understanding, just wanted to be sure, thanks ! <futurile>csantosb: I don't think there's a written 'rule' in the manual that I've seen. But, that's what I've had back in reviews :-) <apteryx>Is Guix still using Guile 2.0 for running the grafts code? <futurile>anyone know how to specify an em-dash in a haunt/sxml file? <futurile>Rutherther: I got blocked on trying to fix the system tests for ubuntu - uh which I'm also blocked on <futurile>Rutherther: the update to perl to the current version, somehow made locale stop working <futurile>Rutherther: it's got to be something to do with me running on Ubuntu though, it made no sense <futurile>yeah the 'guix build xxx' immediately started complaining locale was set to C ... <futurile>moving to the non-privilege daemon means that the installer needs to work with Ubuntu's apparmor policies. So that got me fiddling with the system tests. <Rutherther>hm, so the non privileged daemon doesn't work currently on Ubuntu? <futurile>Correct. To get the 'non-priv' one to work I had to add an Apparmor policy. The installer doesn't do this so I started adding to it. Then you need a system-test so ... But for some reason that I'm struggling with I can't get the system test to work correctly. Apteryx is looking at something similar so I'm hoping they will figure it out. <snamellit>I tried installing guix on a raspberry pi with the shell script. It took like forever and when checking I found it was still pulling from savannah. I copied a channels.scm from another machine and it finished relatively quickly. Is pulling from savannah still desired behavior? <luca>Ideally pull from codeberg whenever you can <Rutherther>no, but it's the behavior you get with guix 1.4.0 that is the latest version. It will change once there will be a new version <snamellit>luca: that's what I did by copying the channels file over. <kratacoa>lol, I'm on the 7th run of `guix gc --verify=contents,repair` this morning and I keep finding new "path $PATH was modified! expected hash X , got Y" errors <kratacoa>yeah I should probably run a btrfs scrub.. but I did that less than a week ago and got no issues, hm <kratacoa>it's new ones every time too, it's not like it repairs the same things and they get fixed again <padtole>hi guix, looking for help on my i686 install. i got a nvme disk for my old device to try to speed it up. <padtole>unfortunately, the bios doesn't see the nvme disk. when i put the bootloader on another device, grub doesn't seem to see it either. additionally, when i try to chroot into it from the install disk i get a segfault 5 <padtole>currently thinking i should try to install coreboot, but given chroot not working i thought i'd mention it <padtole>also curious if there's any guixy implementation of coreboot/libreboot/heads etc somewhere <ieure>padtole, Yeah, if your BIOS can't boot off NVMe, you need a boot disk it can see to load the OS. SATA or USB, just for the bootloader. <padtole>ieure i performed a guix system init with a boot disk but it drops me to grub-rescue saying it can't find the uuid, do i need to enable a grub module or something ...? <ieure>padtole, I had an older HP ProLiant for a while, I stuck an NVMe PCIe card in it, but same issue, it wouldn't boot. Added an m.2 SATA SSD for /boot, once Grub loads, that can talk to the NVMe. <ieure>padtole, How do you have the NVMe in this machine? Same sort of deal, PCIe card? <ieure>Genuinely have no idea what options you have for i686. <padtole>ieure basically i'm using a minipcie adaptor <ieure>padtole, Gotcha. And the installer can see the NVMe after the machine boots? <padtole>ieure yes i've installed a full system :D took minutes instead of days 0_0 <ieure>padtole, I'm not sure, then. Someone who knows Grub better might have an idea. <ate>just donated, keep up the good work! <ate>i hope the campaign is fruitful