IRC channel logs
2026-01-24.log
back to list of logs
<acid-bong>moin, guixers. is there a TUI frontend for a `guix graph`? i'm used to `nix-tree`, which is text-based and displays dependencies in a Ranger file manager fashion, and i'm a bit too impatient to render graphics <acid-bong>ik, but they take too long to render, and i'd like to use a text-based tree instead <untrusem>So I am trying to package a rust package, I have included both the files in this paste https://paste.debian.net/hidden/244992fd , I get `guix build: error: zarumet: unknown package` error when I do `guix build -L . zarumet` froh the guix shell <yelninei>hmm, running the drv with LC_ALL set causes patch-source-shebangs to complain about large blocks even output of guix-daemon. I guess that is the 16k bytevector from dump-port but idk <yelninei>also i am super happy with a little utility that reads and runs a drv automatically, but why are strings in C so painful? <yelninei>huh, I can reproduce it now when redirecting stdin to /dev/null. what is happening? <yelninei>i guess a similar thing could be happing with guix authenticate which has a pipe to guix-daemon <gabber>i guess i'd have to add an RSS feed to my website (and publish more content) for it to appear on planet.g.g.o ? <andreas-e>gabber: Yes to the first question (well, Atom works as well). In case you use haunt, this is quite trivial. <gabber>updating my home profile fails at building taglib, but `guix build taglib` yields a store path <Rutherther>can I compare revisions on qa.guix.gnu.org instead of branches? I would like to compare next-master with master, but latest next-master commit hasn't been processed yet, so I wanted to see the previous one <gabber>huh. we have taglib and taglib-next both being essentially the same package definition <gabber>except, with taglib-next cppunit is missing from inputs, so it fails to build <gabber>so i guess i'm gonna delete taglib-next (and change its only reference back) <acid-bong>is there a way to extend Guix with custom subcommands without forking it? <yelninei>acid-bong: There is GUIX_EXTENSIONS_PATH but I dont think it is well documented right now <gabber>acid-bong: what are you trying to do/achieve? <Rutherther>acid-bong: also if you make a channel with "guix/scripts" or "guix/extensions", it should work as well <acid-bong>gabber: nothing specific at the moment, maybe i'll borrow smth from Nix, like `nix fmt` <acid-bong>(or maybe i'll just have a Justfile in my repo and run commands with it instead) <Rutherther>btw acid-bong, I expect nix-tree to be adaptable to Guix quite well since I do not think the database schema changed in any way on Guix's side. <gabber>what does `nix fmt` do? format some code? <gabber>or do you mean my commit from just now? <Rutherther>gabber: yes, but it is very generic, it can help you format code in mostly any projects based on what formatters you specify <geri>hi, is there a way to do `guix system install` without a bootloader? i got a working debian install and just wanna try guix on my hardware without commiting yet <gabber>is it bad that i fixed it on master just now? not sure why anybody wanted to keep a broken package <acid-bong>gabber: it's a command to format your Nix repo as a whole (with no flags) or a specific directory (if you pass a path). basically, a glorified `nix run FLAKE#formatter` wrapper <gabber>acid-bong: i'm only aware of `guix style FOO` to format package code <acid-bong>i guess i'll just have a manifest.scm with Treefmt in it and use that <Rutherther>geri: btw in case you installed the bootloader as well, I do not think it can break much. It's not like it would remove your Debian bootloader. And tbh I cannot really imagine how you're going to boot into it without the bootloader <geri>was planning to reuse debian's grub, although not sure if that'll work out <Rutherther>geri: it will be hard, especially since the parameters to Guix change with each generation (reconfigure) <gabber>geri: you can add you other OS specs to the bootloader in your Guix system configuration and boot Debian from there <Rutherther>geri: but not impossible, that's for sure. As an approximation you can just use the /var/guix/profiles/system folder as your current system generation <Rutherther>geri: but I wouldn't recommend it to a newcomer who doesn't really know how the system comes <gabber>geri: maybe you have a spare disk laying around from which you could boot (without touching your main system)? <geri>gabber: also an option, but then if i mess up (and with my partitioning shenanigans i probably will), then ill have a broken system until i figure it out lol <Rutherther>geri: assuming EFI, install bootloader will do three things: 1. populate /boot, that can share the root partition of the Guix System, 2. populate esp, typically somewhere like /boot/efi, a separate partition (it will just add a file, not override anything), 3. add and prioritize an efi entry in efi (that can be reverted with efibootmgr if you wanted, or in your setup when booting your computer) <geri>i used guix for like 9 months, but partitioning stuff is kind of a mystery for me ngl <Rutherther>geri: so normally it shouldn't really touch your Debian's bootloader and you should be able to boot to both <geri>gabber: will the usb stick work <gabber>geri: of course. but depending on the hardware it could be rather slow <gabber>i'd suggest an external SSD if you have one laying around <Rutherther>geri: just be careful to not disconnect it during operation (some older usb sticks can be a bit unreliable - just losing communication sometimes -, so I wouldn't choose those) <Rutherther>if you would disconnect it you might have to deal with corruption <geri>sadly i dont have an ssd and closest store is like an hour drive away <gabber>when i switched a bunch of years ago i had this spare SSD duct-taped to the back of my macbook pro and plugged the USB in and out whenever necessary. that way i could also access my data from the main hard drive and in the end just dd'ed the whole disk to the internal SSD for the final switch <geri>Rutherther: ill triple check and maybe just install second bootloader on same paritition <Rutherther>geri: yes definitely have only one esp partition per disk, more is not really supported <Rutherther>geri: and I wouldn't worry about the esp, just make sure to keep Guix fully on a separate partition including the /boot and you should be fine with your Debian installation. In the esp, guix installs inside of Guix subfolder, so that cannot really clash with Debian <geri>gabber: that's some admirable low-tech solutions, i love it <geri>Rutherther: i got an encrypted device with lvm + ext4 partitions, + for some reason 2 more partitions for EFI stuff and bootloader <geri>wanted to reuse root from debian as home eventually to not have to reinstall everything again <gabber>had to teach my mates at university that if it looks stupid but works it is not *that* stupid <Rutherther>geri: hmm, I am afraid luks+lvm is not completely supported as root device <geri>and i guess guix still asks you to input your decryption password twice when booting? <andreas-e>gabber: It was not a good idea to repeat work on master that has been done similarly (but not with the exact same commits) on next-master. It will create a merge conflict later. But we will manage, maybe by reverting your commit, actually... Would that be okay? In any case I am not going to complain, I made the mistake of pushing a few next-master commits to master yesterday. Some of them were related to taglib... <gabber>andreas-e: of course that's ok! i don't really care of the occurrences of my name in our git history. but keeping a broken taglib on master hindered upgrading my home configuration. i guess taglib-next evaded team-audio's review and QA? <geri>Rutherther: what does the mod do exactly? im a tad lost 😅 <gabber>geri: i think that mod would enable us to unlock our drives with only entering the password once (instead of twice, as it currently is the case) <acid-bong>is Grub currently the only* bootloader that has a Guix service? *EFI-capable and relatively modern <acid-bong>Gentoo folks were able to build Systemd-boot separately and it's perfectly usable on its own <andreas-e>Rutherther: I am not aware of doing a comparison between the previous next-master and master on QA. It is usually not a big problem for other branches, which are not updated so often. <Rutherther>geri: it's just to give support for more features in grub, in this case for opening an lvm device. But really I cannot guarantee it will work. I think I will be able to do some testing in the near future, but not less than a week or two <Rutherther>andreas-e: yeah, I figured for team branches it's fine, but since with next-master, a lot of people can be putting commits to it it got me a bit worried I might not be able to see the state at all :/ <Rutherther>acid-bong: no, u-boot is also in the Guix channel. Note that bootloadejcare not services, they're handled separately from services <geri>acid-bong: modularizing systemd back, lets gooo <andreas-e>gabber: Thanks! We will see what to do then when rebasing. I do not know about the taglib review. Probably also we committers should better follow the procedures of pull requests and so on (which I also tend not to do, so this is not a reproach, or at least also to myself). <andreas-e>Rutherther: It is probably not worth modifying QA; I think one conclusion from the release is that next-master was not a success. <acid-bong>Rutherther: by "services" i meant "automated with and maintainable from Guix System" <Rutherther>andreas-e: I think the question if to modify QA is mostly about, how it exactly works in this regard... does it just show latest revision, but could handle previous ones, or is it that it really knows only the data for the last one... and if it does already know everything, I would be for modifying it, since it then should be fairly simple change. Probably something to discuss with cbaines <Rutherther>andreas-e: but well I want to first contribute few changes to Cuirass before taking a look at this <andreas-e>I suppose that the data comes from the data service. If you just wish to look at single packages, you can already do so at https://data.qa.guix.gnu.org/ , but you will not have the comparison there. <Rutherther>andreas-e: yeah, I am using that quite often when I want specific packages, it's quite good. But now I would like to see the branch's state to prepare for the merge, ie. fix some issues in case there wer any <Rutherther>andreas-e: do you happen to know about any regressions? <geri>so debian automatically made /boot and /boot/efi into separate partitions, wonder if i'd eat dirt if i moved everything into /boot and used the other paritition for guix bootloader <Rutherther>geri: definitely don't do that, that will break Debian boot <Rutherther>geri: just use the same esp for both (/boot/efi) and keep Guix's /boot on the same partition as Guix's / <andreas-e>Rutherther: Just before I merged r-team into next-master, the numbers looked good, but were a bit lower than on master. I did not check for regressions. <Rutherther>geri: no need for a separate /boot partition, if you really wanted it to be separate (it contains only grub files, the modules and config), you can create a new one. Here reusing the one Debian is using can be dangerous. Guix uses /boot/grub for the grub files. I suspect Debian could do the same <geri>how are you gonna start grub if its on an encrypted partition with lvm? 🤔 <Rutherther>geri: :) well grub manages this in a way where part of the config that knows to decrypt everything is directly in the efi file. Then after it decrypts it, it will switch to the config and modules in the encrypted partition. But as I was saying, I am not completely sure it will work with lvm with the way Guix sets up the grub. <geri>so you dont need a separate /boot but do need separate /boot/efi? <Rutherther>maybe it will be easiest for you if for now you install to a VM <geri>in fact, i passed my lvm partition to the vm and wanted to do guix system install like that haha <Rutherther>geri: correct, you always need a separate efi partition (esp). UEFI cannot really deal with encryptions/ext4 and so on, only simple filesystems like VFAT <Rutherther>geri: oh I see - note that if you did that, you will have to create the efi entry yourself in case you did not use --no-bootloader, and it might break your installation in the VM due to new efi entry pointing to a partition that won't exist in the VM afterwards <geri>oh damn right, that partition has different device name and uuid <pinoaffe>does anyone use gimp with plugins on guix? cuz to me it seems like there's no search-path specification in the gimp package, and i haven't succeeded at manually making gimp find any plugins <davidl__>Hi, how can I use guix system init to create a new system on an external disk that's been mounted to /mnt? Im trying to avoid rebooting with the installer image and just use my regular Guix system. I considered trying to add the cow-store-service to my running system but since its not exported from (gnu system install) I don't know how to. Is it possible to use some guile/guix procedure to retrieve a service object from the installation-os <davidl__>object that is exported from (gnu system install)? <pinoaffe>davidl__: i think you don't need cow-store-service, you can just run `guix system init` <davidl__>And that would populate /mnt/gnu/store when completed? <davidl__>pinoaffe: ah okay because it was not happening while the new system derivation was being created, but I see now it seems to do the copying at the end. <Rutherther>davidl__: the cow store is only for iso because then you write everything to memory and chances are you do not have enough memory to cover the whole store with your system <cbaines>how do you match up guix refresh -l telling you things are related, and guix graph --path telling you they're not? <cbaines>I guess guix graph --path is wrong/looking at different information, but it would be useful if it could help you make sense of guix refresh output <cbaines>ieure, I'm currently looking through something similar to guix refresh -l sqlite@3.39.3 <cbaines>so guix graph --path erlang-erlang-color@2.0.0 sqlite@3.39.3 fails for me for example <cbaines>I have a feeling the cause in this case is rust related packages being weird <ieure>cbaines, Noticed that erlang-erlang-color had no inputs, so the path has to be through the rebar-build-system. So the issue is that `guix graph' doesn't consider build-system things, while `guix refresh' does. <ieure>cbaines, The true path is sqlite -> webkitgtk-with-libsoup -> wxwidgets -> erlang -> erlang-erlang-color <ieure>So bumping sqlite will rebuild every erlang package. <yelninei>The default type seems to exclude implicit inputs <ieure>I still don't really understand what a "bag" is. <cbaines>ieure, bags are packages without build systems <cbaines>so it's sort of like package (with build system) -> bag -> derivation <cbaines>when you're moving from packages to derivations, it's an intermediate representation that's useful for abstracting over all the packages <cbaines>another way to look at it is build systems return bags for a package, and those bags can then be converted to derivations in the store <ieure>cbaines, Okay, I think I basically get it. I thought packages got compiled straight to derivations, those get executed, and the store item results. <cbaines>this just feels like it should be simpler to do than I'm making it <htgoebel>Hi, how can I download an archive from pulls.ci.guix.gnu.org? The package did build there, but can't be build on my machine due to too less memory. This I want to substitute from pulls.ci.… to fix the build of dependents. <ieure>htgoebel, I'm not sure there's a reasonable way to download manually. I think pulls.ci builds end up on the CI substitute server. Sounds like maybe the build is from an unmerged PR? If so, you'd have to check it out use the pre-inst-env. <Rutherther>htgoebel: sure just add it to substitute-urls and authorize the key. To get the key probably easiest is using guix weather, it will tell you the key. <Rutherther>ieure: no they do not end up on CI substitute server, that would be dangerous as pretty much anyone can build anything there <ieure>Rutherther, Yeah, but you'd have to be running the code from the PR that produced it to download. <Rutherther>ieure: no, that's not true. As you have the full control over what cuirass evaluates you can change the way derivation outputs are computed and substitute any output path you would want <htgoebel>ieure: pre-inst-env does not work since building required to much space/memory. <Rutherther>htgoebel: it will wor after you add pulls.ci as substitute server, including authorizing it as with every new substitute server <Rutherther>htgoebel: I suggest you to do it just one time though, because as said above, downloading from it is generally more dangerous. Better to download only builds you really just saw should be fine <htgoebel>rutherer: Sure :--) But guix weather doe not show thy key and there is no such option. What am I doing wrong? <Rutherther>htgoebel: what is your invocation and what is the output? <htgoebel>computing 1 package derivations for x86_64-linux... <htgoebel>guix weather: warning: could not read '/etc/guix/acl': Keine Berechtigung <htgoebel>guix weather: warning: '/etc/guix/acl' is unreadable, cannot determine whether substi <Rutherther>htgoebel: please don't send multiple lines here use a paste site <Rutherther>htgoebel: as you can read the error, your /etc/guix/acl is inaccessible, just chmod it to 777 and /etc/guix to 555 <htgoebel>rutherer: Of course, no writer-permissions for normal users. Anyway, this did the trick. Thanks. <vagrantc>weirdly enough, the first system i tested a guix 1.5.0 out on ... was a debian riscv64 machine :) ... having troubles getting systemd to start guix-daemon, though... had to manually start guix-daemon <vagrantc>as in directly call guix-daemon ... my hunch is apparmor or something <vagrantc>also, does guix-daemon still default to run as root, or is the unprivledged daemon the default? <Rutherther>vagrantc: have you accepted the apparmor policy? <Rutherther>vagrantc: no, did you type Y or enter when the guix-install.sh asked you to install the apparmor policy? <vagrantc>did not use guix-install.sh ... using a .deb package i built ... trying to see what it would be like to get back into debian <Rutherther>vagrantc: I see. Then yeah, missing apparmor, see the profiles in Guix under etc/apparmor.d <Rutherther>vagrantc: the Debian package should supposedly ship this profile, but probably a bit modified so that it includes /usr/bin/guix-daemon and /usr/bin/guix <vagrantc>i think the apparmor policies are present, but i suspect it might actually not provide enough permissions <vagrantc>though the log is totally unhelped, basically "it did not start" and nothing more <noe>you can look at the output of aa-status to see if the process is running under apparmor or not <Rutherther>vagrantc: if you like installed through make install, then I suppose the policies won't actually work since guix-daemon is in /usr/bin/guix-daemon at that point and this is not in the policies <vagrantc>wonder if i can figure out how to crank up verbosity on the error logs <vagrantc>Rutherther: right ... it is asically make install and then wrap into a .deb <noe>The apparmor policies are not needed on Debian though, so if they are not applied and/or you see no apparmor errors in your system logs, its probably unrelated <vagrantc>installing a .deb package on a debian system is how i've done all of my aarch64-linux guix system installs so far (since the installer did not exist until recently!) <vagrantc>noe: they are installed into /etc/apparmor.d or whatever, but yeah, will check logs <Rutherther>sure, it's architecture agnostic, only thing is if the aarch64 tarball has been released, which I don't know if it was, but would guess it was. It definitely was in 1.4.0, so 3 years at least <csantosb>I'm trying to figure out how can a package depend on two different versions of another package, `guix graph adaptivecpp` and bzip2/zlib <Rutherther>it's just a shell script that searches for a tarball at ftpmirror.gnu.org <Rutherther>vagrantc: yes, what else if we're talking about installing on debian? <vagrantc>Rutherther: installing guix System using the debian provided packages to run "guix system init ..." :) <vagrantc>i did start guix on aarch64-linux before there was even an aarch64 linux-libre kernel :) <vagrantc>5a9dc4a8074cde2fec3ecc7ea71f2e976c8c38c0 ... in 2018 ... my how time flies <noe>csantosb, one of the `zlib`s is zlib-final from (gnu packages commencement) <ponyboy>hey everybody. after upgrading to the unprivileged daemon on a foreign distro (following the commands in the manual), i'm getting a 'newgidmap failed with exit code 1' occurring dozens of times in any guix operation. is there a fix for that? <Rutherther>vagrantc: in that case I suppose the discussions about configuration of arm64 kernel should be held with you and not lfam? I pinged lfam on codeberg multiple times and got no response. So I suppose I was contacting the wrong person <Rutherther>vagrantc: though we've already talked about it briefly as well <Rutherther>ponyboy: 1. do you have newgidmap installed, 2. if yes, do you have group kvm on your system? <ponyboy>Rutherther: 1. yes, 2. yes. i didn't previously have it installed, but then it was exiting with code 127, not 1 <vagrantc>Rutherther: i have been busy proposing kernel updates ... my guess is lfam is not active at the moment? ... i do sometimes think i should maybe join the kernel team, since i've been testing them anyways ... <Rutherther>ponyboy: in that case, have you added mapping to /etc/subgid so that the daemon can use kvm group, ie. line "guix-daemon:$kvmgid:1", where the $kvmgid is the gid of the group, see /etc/group for the gid <vagrantc>ACTION is in the middle of building and testing all the latest kernels for aarch64-linux for #5864 <vagrantc>Rutherther: i figured during the release freeze it made sense to not fire off tons of kernel builds ... but now i might start being a squeaky wheel :) <ponyboy>Rutherther: i didn't have that one. added it and restarted guix-daemon, but still get the same error. thanks for that tip though, i didn't see it in the docs <ponyboy>oh, should guix-daemon also get a kvm line of some kind on /etc/subgid ? <ponyboy>Rutherther: /etc/group says gid for guix-daemon is 994. so: guix-daemon:994:1 <ponyboy>will try restarting machine quickly just to be on the safe side... one moment <htgoebel>Now, since 1.5 is release, what about next-master? Are changes still expected to go there? Or can I push to master again? <ponyboy>restarting was worth a try, but no luck there either <Rutherther>ponyboy: if you try "sudo -u guix-daemon newgidmap 994 40000 1", what does it say? <ponyboy>Rutherther: Could not open proc directory for target 994: No such file or directory <ponyboy>however that group is definitely 994 as far as i can tell: guix-daemon:x:994:guix-daemon <ponyboy>Rutherther: no worries -- the strange thing is everything appears to work <Rutherther>it's normal with this newgidmap, the errors aren't harmful for normal usage <civodul>hmm what’s the status of guix-gc.timer on foreign distros? <civodul>is it installed and activated by default? <Rutherther>civodul: I don't think so, I don't think it's even copied from guix profile to the systemd services dir <ieure>If I add #:test-command #~(list "emacs" "--batch" "...etc..."), the build fails with "Unbound variable: gexp" <ieure>But many other packages in this module use the same formulation and seem to work fine. <ieure>...yeah, so copying, say the emacs-helix #:test-command verbatim causes the same build failure. <ieure>Genuinely no idea what's wrong here. <ieure>Ooh, okay, I see what's wrong. <ieure>(arguments (list ...)) vs. (arguments '(...))