IRC channel logs
2026-02-07.log
back to list of logs
<clone>If i need an old version of a package, what's the easiest way to see which guix commit has the version i need? I've just been going into the source for the package definition and git blaming but I wonder if there's a better way <ieure>clone, `git log -S the-version gnu/packages/whatever.scm' <ieure>clone, Working example: `git log -S 130.0 gnu/packages/librewolf.scm' <ieure>Hmmm, I've always wondered why Emacs completion doesn't know about Git man pages on Guix. <ieure>If I M-x man RET git-add RET, I get the man page. But I get no completions and have to type the whole program name. <ieure>Man completions use man(1)'s built-in apropos feature, basically `man -k your-input'. `man -k git' only shows the guix-git package. So, not an Emacs problem. <ieure>$MANPATH has /home/ieure/.guix-home/profile/share/man in it, which has the Git man pages. <ieure>So, I guess this is a man-db issue. <ieure>Ah yeah, so there's no index.db in my Guix Home man directory. But there is /run/current-system/profile/share/man/index.db <ieure>So all the mandb-using stuff only sees packages in the system profile. That's unfortunate. <clone>I do have index.db in my home profile too. I think it's because I installed man-db in my home profile <futurile>morning all, hope you're having a good weekend <futurile>with a broken leg I am learning the value of the now missing ability to 'go for a walk' or 'carry cup of coffee around house' heh <futurile>rustyguix: thank-you - well at least I'm catching up on my reading heh :-) <rustyguix>well, if that can help you think about other things, I am wondering if anyone has recommendations with respect to running a guix (os) on a hosting service. A quick search suggested vultr (e.g. https://ieong.ovh/posts/guix-vultr/). I also read that others just use physical servers at home or their work. <ekaitz>futurile: i don't want to brag, but I just went for a run <ekaitz>hopefully you'll do the same soon <futurile>ekaitz: heh heh heh - I'm literally staring at a new book that I'd bought 'Training for Ultramarathons' and thinking it's messing with me <futurile>rustyguix: there's definitely blog posts floating around about both - that's a good post about Vultr <futurile>rustyguix: you can probably do most of those steps on any 'VM' hosting set-up <csantosb>This is just me, or all of these languages with thousands of little packages look like a nightmare (go, looking at you) ? <clone>Which languages aren't nightmares? <acidbong>why does guix.gnu.org change its IP? with DNS caching it's hung until the cache times out <futurile>acidbong: on a guix pull? It's actually pointing to codeberg/guix/guix <pull-logout> hi, what could it be that when i do a guix pull i got kicked out from the session and the guix pull procees is killed also? this is a fresh install, how can i debug/find the cause? <Rutherther>pull-logout: how much memory do you have? Do you have any OOM logs in dmesg? <futurile>acidbong: oh I don't know then, web site seems fine to me - it's resolving fine for me <acidbong>futurile: I'm using systemd-resolved, which caches queries by default, and, if it catches the website being down at some minute moment, the website is down for me until the cache expires or i flush it manually <pull-logout>Rutherther: thanks, no ooom in dsmesg only elogind messages about closing session, and guix daemon respawning the tty i was on <aarush>Hi for some reason I am not able to remove gdm from %desktop-services <aarush> 16 (modify-services %desktop-services <Rutherther>aarush: and what makes you think you cannot remove gdm-service-type from desktop-services exactly? <aarush>@kestrelwx yes, it still says after reconfiguring <aarush>kestrelwx: it is running as "file-system-/var/lib/gdm" <yelninei>set-xorg-configuration depends on gdm with an optional argument <aarush>yelninei: will gdm be removed is I remove the set-xorg-configuration? <yelninei>it should but you will be left with no login manager at all <aarush>yelninei: oh, thank you! I like to start sway directly from tty <futurile>anyone having a problem with: ./pre-inst-env guix refresh --list-dependent <futurile>anyone having a problem with: ./pre-inst-env guix refresh --list-dependent <pkg@version> <futurile>It's complaining that gtk+/fixed is unknown variable - new one for me <clamky_>./guix-install.sh uses, but does not check for availability of sudo <Rutherther>clamky_: right. It shouldn't use sudo. It should be called as root <clamshell>Where will i find a good reference of how to write a guix.scm file... trying to grasp the refernece manual, but ends up scrolling all over the place <clamky_>Rutherther: right. it was called as root here and failed because this system does not have sudo <Rutherther>I think it's bad practice when scripts use sudo, not sure how I could've missed this during review <futurile>Rutherther: I think the manual used to tell users NOT to run it with 'sudo' - I remember it because 'sudo' on Ubuntu is hardwired into my brain <futurile>Rutherther: ah sorry, I misunderstood you were reverting a change <clamky_>Rutherther: thanks for the link, i just removed all instances of sudo and reran the script it seemed to have completed without errors <Rutherther>futurile: I am reverting a part of a change, the sudo calls from the script that are not only unnecessary, but also just wrong since the authenticity is then checked as user running the script, not through sudo <Rutherther>sudo is currently used for importing the keys to keyring <clamky_>zsh compinit: insecure files, run compaudit for list. <clamky_>Ignore insecure files and continue [y] or abort compinit [n]? <Rutherther>clamky_: could you send the erro you got on running guix-install.sh? <RavenJoad>Hey all! I borked my spare laptop by doing a BIOS update on it last night. Guix's boot option was lost (presumably because the update cleared the NVRAM used for boot entries). Normally I would live ISO in, chroot, and reinstall boot information. How would I go about doing that with Guix and a full-disk-encryption disk? <Rutherther>RavenJoad: there is no need to do chroot or anything like that, you can just use efibootmgr to craft the entry manually. <ieure>RavenJoad, `cryptsetup luksOpen /dev/whatever' will unlock your encrypted partition and let you do whatever with it. <Rutherther>..except the fact that to mount it you need a few more commands <ieure>RavenJoad, I believe these tools are in the installer, but `guix shell cryptsetup' if not. <RavenJoad>To make the BIOS update take, the laptop rebooted. So I don't have any way of getting into that machine right now. Are you proposing that I take a live image and use efibootmgr to recreate the entry? <RavenJoad>Ok, cool. This laptop is not critical, so a reinstall would be fine too, so I always have that in my backpocket, thankfully. <RavenJoad>Last quick question before I go down rabbit holes. Does Guix's live image ISO work with Ventoy? I know some distros have issues with booting from Ventoy. <Rutherther>RavenJoad: yes, but reinstall is really not needed at all. You have 1. efibootmgr, 2. chroot, 3. even if you couldn't get chrooting right, you have the guix system init to reinitialize your system without doing a full reinstall in the original sense where you would wipe everything. That wipes only the store. <RavenJoad>I agree, reinstall should not be needed. I know I have many options. I'm just saying that it is helpful to have the "easy road" to fix this in this case. <futurile>we really need someone to write a tutorial, I don't think there's anything in the Cookbook is there? <RavenJoad>Even if I don't have to reinstall, not having the stress of needing to make this work is nice. <Rutherther>futurile: tutorial for what exactly? Chrooting is described in the manual <futurile>Rutherther: for the other two, a 'how to recover' - there was a lot of feedback in the survey that the manual is great but sometimes people want/need just the 'steps to do X' <RavenJoad>futurile: I will say, the chroot instructions in the manual are written in a cookbook format already. <Rutherther>futurile: the chrooting part of the manual is a steps to do X and it's how to recover in the end. But it's true that for many people it might not be obvious that they *want* to do the chroot to recover <RavenJoad>I don't know how much "chroot to recover" is a Guix-specific thing either. If I had borked this on another distro (which I have), I would still chroot. It's good to have a list of reasons that would answer the question "should I chroot" for newer people. <RavenJoad>Rutherther: 3 reboots later (1. forgot to reconfigure, 2. locked disk must be named cryptroot, 3. success) and I have the system back. <muaddibb>answer to self: in Emacs, you can set `geiser-guile-binary' to '("guix" "repl") to load guix modules properly and edit config files <untrusem>muaddibb, I don't have this variable in my emacs <makx>anybody else have their guix system reconfigure fail with build of /gnu/store/prm5c8k5mw4zf25nvlsc4rgpk0v7dali-system-config-printer-1.5.16.drv failed <makx> (it complains about Unbound variable: py:add-install-to-pythonpath) <efraim>makx: I just ran into that, it's fixed now <tux1c>does anybody know if i can reach hellseher on irc or any other quick messaging platform? <kestrelwx>They are available on Telegram if you use that. <yarl>Rutherther: Thank you for your support. <jab>weird question...at some point is the initial guix pull going to be changed? I'm noticiding that the initial guix pull is pulling in the entire git history, which is only going to take longer and longer as time goes on...is anyone aware of a plan to change that initial git pull to be faster somehow ? <Tadhgmister>I think modifying it as it is defined in the repo is unlikely to change as that'd impact core bootstrap stuff but setting up an option for the install media (or more generally guix system init) to copy over the guix channel derivation being used by the installing system would be excellent. <Tadhgmister>I think the main issue there is that I don't think the guix channel is technically system wide, different users can be "checked out" to independent channel states <Tadhgmister>and changing the root authenticating commit in the repo would make authenticating commits older than that for things like guix-past would require a whole new mechanism <nixpup>Hey everyone, I've been working on a GNU Guix config over the past weeks and, I haven't been able to test it yet on real hardware/a full Guix install, but could someone here maybe look over my desktop.scm config file and tell me if it would *technically* work? Especially with the Nvidia stuff and such. Link: https://github.com/librepup/geex/blob/main/systems/desktop.scm <Tadhgmister>nixpup I mean if it works enough to load in a VM and your hardware can access internet I can't imagine it wouldn't work well enough to try and debug any kinks from the live system <nixpup>Tadhgmister: I haven't tried it in a VM yet, the only part of my config that I've tried is the guix home configuration (home.scm) via `guix home container home.scm`. I'm currently still on NixOS and only have the guix package manager installed <Tadhgmister>ahh, well I'd highly recommend trying `guix system image` on your config and seeing if it will load in qemu or similar as a minimal check <Tadhgmister>oh wait image requires more details... what ever the man suggests for creating a minimal image definition from a system config <Tadhgmister>alternatively set it to use `grub-efi-removable-bootloader` and directly go through `guix system init` onto a flashdrive. If it can boot from the flashdrive you can just go through the same set of steps onto the main drive <nixpup>Is there a way to evaluate my config.scm and related desktop/laptop.scm files *as if* I were installing Guix? Like a check if it can find everything I configured in it? <Tadhgmister>`guix system build desktop.scm` will tell you if it is coherent/complete/valid but knowing whether it can make use of a GPU without just running it on the real hardware isn't really a thing to my knowledge <Tadhgmister>surely you have access to an external drive though, like the one you would put the guix installer onto to actually install your system on the main drive - you could try to install your config onto that to see if booting it on your hardware works <nixpup>Is `guix system image /path/to/config.scm` a good way to test my config? Because every time I run it I get a lot of errors, it seems like half the services and modules I use/defined don't work or don't exist <ieure>nixpup, `guix system build' is what you want to validate that the configuration is correct. <ieure>nixpup, Once that works, you'll want to do what Tadhgmister mentions and put it on some external media (HDD, thumb drive, whatever) and boot it to see if the hardware-related things are working. <Bezier_Curve>This contains a repo url to the old git repo. Shouldn't that be updated to codeberg? <vagrantc>guix system vm ... takes a system configuration ... though i have had trouble getting it to work <ieure>Bezier_Curve, git.guix.gnu.org is an alias, it points to Codeberg. <vagrantc>Bezier_Curve: thaat's not the old URL, it's a redirect controlled by guix that points to codeberg <vagrantc>admittedly, i point directly to codeberg, because it is one level of redirection and i will probably be paying enough attention if guix moves away from codeberg :) <ieure>Bezier_Curve, The warning is a Git feature which lets you know when you're being redirected, in case the thing is redirected to a malicious server. <ieure>It does not mean the URL is old. <vagrantc>it is admittedly noise when it is the "usual" work flow of guix <vagrantc>e.g. arguably it should be surpressed somehow <vagrantc>teaching people to ignore warnings ... is not a great practice :) <vagrantc>"no, no, pay attention to *that* warning!" <Tadhgmister>is there a way to get a `guix shell` or other container to closely mimic the environment conditions of packages being built? Adding --pure still has things like /bin/sh that aren't in the daemon's build environment and I'm currently tracking down an error that isn't present in a --pure shell <vagrantc>but yeah, it is frustratingly difficult to get an environment just like what guix daemon builds a package in <ieure>Tadhgmister, If you `guix build -k somepackage', the kept build directory will have an `environment' file which captures the exact build env <ieure>Sorry, `environment-variables' is the file name. <ieure>Tadhgmister, See `(guix)Debugging Build Failures' <Tadhgmister>yes but I am currently at the point where -k then going to that folder, `guix shell --pure ; source environment-variables ; cd source ; make` continues the build process without any issues <ieure>Tadhgmister, Likely something is using the network. What's in the log when it fails? <vagrantc>hence my suggestion to also try --container <Tadhgmister>CC scripts/build/make/dlopen.c make[1]: Leaving directory '/tmp/guix-build-freeradius-server-4.0.0.drv-0/source' <Tadhgmister>Makefile:180: build/lib/.libs/libfreeradius-make-dlopen.so: cannot open shared object file: No such file or directory <Tadhgmister>Makefile:180: *** build/lib/.libs/libfreeradius-make-dlopen.so(dlopen_gmk_setup): failed to load. Stop. <Tadhgmister>definitely isn't accessing network, when I build it outside `guix build` the file that error references definitely exists but I'm pretty sure it is being generated by a script it compiled right before the error so I'm wondering if it tries to run /bin/sh or some other variant that creates the file and that is what can't be seen <Tadhgmister>I guess I can easily rule out that specific case by yeeting /bin/sh inside a container... <ieure>I think /bin/sh should exist in the build environment. <yarl>Tadhgmister: maybe add strace to your guix shell and strace the problem? <ieure>Tadhgmister, It can help to add a build step that prints out info about the build environment, then causes an error to abort it. <yarl>Sounds like a loader problem, load path maybe? <Tadhgmister>quite possible load paths and quite possible identified with strace. But this is something I've run into several times and steps like adding build steps that print info then error to keep the build folder or trying to hack in debugging traces to the process executing has been kind of tiresome. Usually `guix shell --pure` is sufficient to recreate the problem and then I can much more easily just do debugging steps