IRC channel logs
2026-02-05.log
back to list of logs
<Tadhgmister>@the_tubular does `df` show efivars filesystem is full? <Tadhgmister>not sure but using grub-efi-removable-bootloader doens't rely on that fs so using that until you do figure it out may be a good idea <the_tubular>I used efibootmgr to delete an entry, but it didn't free any space <the_tubular>That's why I'm afraid I won't be able to reboot, but not sure what to do next <Tadhgmister>I'd just edit your system config to use the removable option (grub-efi-removable-bootloader) as it should work regardless of the variables there <Tadhgmister>*just -> would start with. this is obviously not a fix for the actual problem but side steps it being a blocking one <Tadhgmister>rebooting and gettting into UEFI settings and seeing if there is an option to clear out variables there would probably be what I'd try but obv after I know it's in a state where I can boot back into the system <the_tubular> (bootloader grub-efi-bootloader) for (grub-efi-removable-bootloader) right ? <Tadhgmister>EFI standard says there is a specific file location it will look for as the "default" boot option, any other location like "EFI/Guix/grub.efi" where guix typically puts it relies on the filepath being stored in the UEFI boot variable storage to actually boot from <Tadhgmister>the removable bootloader puts grub in that default spot, the intention is that removable flashdrives that don't have any access to putting themselves in a machines efi data would still be able to boot <the_tubular>I see, and how would I debug the second part after ? <the_tubular>I'm trying to reconfigure, not sure the change I did were correct, let's see <Tadhgmister>Unfortunately not sure I can help there, brief looking up on the arch wiki forums has a suggestion that is followed by "warning this may brick your system if you are on an older model without properly write protected variables" so not sure I want to endorse that <the_tubular>Seems to be working, hope I it will stay stable for a while <the_tubular>Anything else I should confirm before rebooting Knowing I deleted my guix entry using efiboomgr <Tadhgmister>make sure `.../EFI/BOOT/BOOTX64.EFI` exists, where "..." is the efi partition listed by `lsblk` (probably /boot) <Tadhgmister>so on my system it is /boot/efi/EFI/BOOT/BOOTX64.EFI <the_tubular>Was stuck on this issue for a while, so it might take a moment <the_tubular>-rwxr-xr-x 1 root root 360K Feb 4 00:20 /boot/efi/EFI/BOOT/BOOTX64.EFI <Tadhgmister>yeah ok, so assuming your EFI implementation is able to load flashdrives it should have no problem booting back into your guix system <Tadhgmister>good luck with the rest of it, although I just stick with removable it is less hassle <the_tubular>When I run efibootmgr I don't see a guix entry anymore <Tadhgmister>efibootmgr reads data stored in the computer motherboard, removable bootloader does not put anything there <Tadhgmister>after you do reboot there will probably be an entry just listing the block device without saying anything about guix <Tadhgmister>can't really compare to mine but efibootmgr shows some entries right? <Tadhgmister>I have done both but always to fix a system which was shortly after permenantly fixed by setting it to use a removable bootloader <Tadhgmister>(manually making an entry you get `--loader` to point to grub and skip the part about kernel arguments as grub doesn't use those <apteryx>does 'logger -p user.warn "syslog test message"' cause the message to be logged to /var/log/messages for anyone? <Tadhgmister>apteryx, also doesn't seem to put it in /var/log/messages but I do wonder if that is the wrong place to be looking, unfamiliar with logger <apteryx>logger logs to syslog; on Guix System at least these should be (or used to be) shown in /var/log/messages <apteryx>syslogd has been replaced/absorbed by shepherd, so there may be an issue there <apteryx>its output says the log files in use are: /var/log/messages /dev/tty12 /var/log/debug /dev/console /var/log/secure <apteryx>ah, it's in /var/log/messages according to grep <apteryx>missed it; maybe it was buried under other messages <Tadhgmister>I am trying to package freeradius for guix and in the build process it compiles a program it then tries to run as part of the build, I know the linux kernel successfully does this even when cross compiling but this is giving me an error that "file does not exist" that often comes up when an executable tries to access a dynamic library that isn't on guix and I'm wondering if it is the same problem <apteryx>are you perhaps cross-compiling? this error often happens when attempting to run an executable built for the wrong architecture <Tadhgmister>no, I'd totally expect it if cross compiling. `guix shell --pure -Df guix.scm -- make` works just fine, even from the directory created by `--keep-failed` it just isn't working in the guix build environment <Tadhgmister>haven't yet figured out how to isolate the issue outside of "some command that 'make' invoked failed" but it is definitely failing between compiling that executable and then invoking it to create some libraries <apteryx>maybe you can put strace -f -s200 in front and log in the current directory (-o file.strace) <apteryx>and keep the failed build with -K to inspect <Tadhgmister>strace on the guix build command? I've been doing -K but even a pure shell inside that directory can continue the build no problem <Tadhgmister>no this seems like it is just showing the calls of the guix build command which is all forwarding text from the build daemon, I guess I'd need to replace the build phase with invoking strace? <apteryx>Tadhgmister: if the build succeeds in a 'guix shell --pure' environment but fails in the container, it may be due to accessing something like /bin/sh or the likes <Tadhgmister>but it patches the shebangs?? ohhh I guess the c file it compiled might be doing that... <apteryx>s/in the container/in the 'guix build' environment/ <apteryx>sometimes scripts are dynamically built post the shebang patching business, or there's a system('/bin/sh -c ...') in the source somewhere <apteryx>(the automated patching only affects the first line/shebangs of source files) <Tadhgmister>if I have the source code downloaded and run the configure script from `guix shell --pure -Df guix.scm` can I use that folder as the source of a package with the configure step disabled and expect it to behave like it would in a proper build? the configure step is very long to keep rerunning every test <Tadhgmister>that is 100% what is happening, it has strings in the c file that look like shell related commands but does a bunch of string manipulation making it non obvious how exactly to fix it <ieure>Why is `guix pull --list-generations' showing me the excruciatingly slow "indexing objects" progress bar? <ieure>Listing generations requires updating a Git repo? <mange>Did it just do the indexing at the start? Or is it doing it repeatedly? I agree it seems weird. <mange>Sorry, by "the indexing" I really mean "the git fetch". <ieure>mange, It printed 8 generations, then started "receiving objects" and "indexing objects." <ieure>Actually, that's not accurate, it printed generations 1 & 2, then received/indexed, then printed 3-8, then did more receiving and indexing. <ieure>And indexing objects is so painfully slow. <mange>I think the fetch is coming from channel-news-for-commit in guix/channels.scm. <ieure>Hmm, okay, I remember talking about this. <mange>When it's displaying news it needs to grab the repo to know which news entries to show, so I imagine it has to fetch the history between the generations. <mange>Unless you already have it all locally. <ieure>Hmm, I would have thought that `guix pull' fetches them. <mange>I also would have expected that. update-cached-checkout does call "git gc", but I assume that wouldn't remove reachable commits? I don't know. <sunless>i'm struggling to use gpg, listed and installed gpg, painentry, pinentry-emacs in home config pasted the recommended config in the docs, when i run gpg --gen-key, it fails with error 'no pinentry' <mange>So you have a home-gpg-agent-service-type defined with pinentry-program set to e.g. (file-append pinentry-tty "/bin/pinentry-tty")? <mange>(Or whichever other pinentry program you want to use - I don't actually know how tty works.) <sunless>mange: i copied this from the docs (pinentry-program (file-append pinentry-emacs "/bin/pinentry-emacs")) ... but lemme try the tty one <mange>Oh, sorry, you said emacs, I just didn't read properly. Are you running it from within emacs? <mange>I don't know if that matters. <mange>But more significantly, what does "herd status gpg-agent" say? <sunless>running, enabled, "replacement pending (restart to upgrade)", messages showing commands failing because, pinentry <mange>That's exactly what I was about to say. :) <mange>If you had a gpg-agent without the pinentry configured and then reconfigured it, then I would expect you to need to restart to see that work. <sunless>thanks, i think it worked, i didn't know about using herd to restart the process ... i'll try to make it use pinentry-emacs <sunless>i also think it's weird the pinentry-emacs program when run it returns no file or directory <sunless>both pinentry and pinentry-tty seem to be timing out when i'm generating the key (maybe not detecting my eratic mouse movements) <sunless>so is there anyone who's successfully using gpg especially with emacs? <ieure>sneek, later tell sunless I use GPG with emacs-pinentry and a Yubikey. <csantosb>Good morning Guix ! I'm having recurrent 504 when accessing ci.guix.gnu.org, am I the only one ? <sunless>simendsjo: i haven't understood packaging stuffs yet, but since it looks necessary, i'll check in after i've learnt it <sneek>Welcome back sunless, you have 1 message! <sneek>sunless, ieure says: I use GPG with emacs-pinentry and a Yubikey. <sunless>nice, i was just going through the dotfiles shared by simendsjo ... i really hope there's another solution <sunless>sneek: i've gone to check out "yubikey" <futurile>hey hey, anyone got some fun things today? <acid-bong>moin. the Cookbook suggests running `cargo generate-lockfile` when adding/updating Rust packages, but what if the source already provides a lockfile? <sneek>efraim, ekaitz says: I just asked guix to build gcc-boot0 in the riscv machine. We'll see what it does <efraim>ekaitz: I'm fighting binutils-muslboot0 on i686. If we can get x86 using the same bootstrap path it should make the process faster <ekaitz>efraim: that was one of the goals of this process too <ekaitz>but that would split the bootstrapping for hurd and linux <efraim>If I add binutils-mesboot0 to binutils-muslboot0 and use ar from it then I can build binutils-muslboot0 <efraim>so now I'm assuming I need ar and not 'tcc -ar' for i686 <sunless>i've fixed my gpg pinentry errors :) ... i had to download "emacs-pinentry" and start it in order to get asked the passphrase, i thought "pinentry-emacs" was enough, otherwise everythings working now, thanks to all who helped me along <ekaitz>efraim: no idea, but tcc -ar kinda works <andreas-e>So far this is just a draft and not yet a concrete proposal, as far as I can tell. <futurile>andreas-e: yeah, sorry should have said that <futurile>andreas-e: I would like to clarify the policy, I'm not really in favour of making the process more onerous in terms of other admin you have to do with upstream and blah blah blah <futurile>I feel like "co-ordination" with close channels is something that's open to a lot of interpretation <andreas-e>I have not read it yet; I am also in favour of making the whole process faster and simpler compared to what we do now. <andreas-e>The suggestion at Guix Days was to not coordinate with other channels, but to give them a simple way of getting information on upcoming changes. The idea was to add a Codebnerg team to which each channel could add one account; and then to add a "cc @channels" or something like this to each issue doing a deprecation or moving a package from one module to another, since this can potentially break "guix pull" until the other channel is updated accordingly. <theesm1>wouldn't that be a task where a generated rss feed listing upcoming deprecations would be feasible? <futurile>theesm1: means creating code, hosting it, maintaining it, the less infrastructure code/services we create the better I reckon <futurile>don't know how other rolling releases do it though, this must be a general problem <theesm1>futurile: that's true, i mean codeberg does already provide rss feeds for commit histories and branches etc. (i don't know if they provide a way to prefilter feeds by keywords, but that would kinda solve it) <SrainUser>I just had a weird experience with guix system reconfigure. I added an etc-files-service extension that added an SSL cert to /etc/ssl/certs. This correctly installed the certificate I asked for, but it overwrote all the other certs in that directory. Is that expected/documented behaviour? I would not be as surprised if I had asked for clashing behaviour (e.g. two services try to create the same file). But in this case I just wanted to add a <SrainUser> file to a directory that some other service populates. <acidbong>recompiling all of Guix between branches (especially rust-team, which is way behind master) is quite annoying, are worktrees the way? <acidbong>also, how do yall organize your worktrees, if any? <efraim>I ended up with my sources for everything in ~/workspace so I have ~/workspace/guix, ~/workspace/guix-rust, ~/workspace/guix-bootstrap etc <futurile>acidbong: yeah worktrees are definitely the way to go, and keep the paths short like efraim has because there's a maximum path length for some tests <efraim>If I were to go back in time ~15 years I'd use ~/src instead of ~/workspace. now I have muscle memory <futurile>acidbong: unfortunately my overly descriptive ~/workspace/guix/workrees/branch-2025-12-01-feature-do-stuff doesn't work heh heh heh <acidbong>ight, `~/src/guix-{gnome,python,rust}` it is then <sunless>oh, i added that later for a sanity check ... i'm aware even in the original --share=$HOME/.mozilla does not share the extensions i have in my host ... when i enter the container, i find there's even no .mozilla <sunless>apparently the order of sharing matters, i had to share the $HOME first, then other files (emacs + firefox) <untrusem>ohh intresting is information about "order of sharing" mentioned in docs? <jnms>I was attempting to reduce the size of compiled guix. I noticed the .go files contain a lot of null bytes, they easily compress 5-10x. I managed to patch guile to support loading zstd compressed .go files, and a compression phase to guile, guix, and all the guix system compilation steps. <jnms>I'm using that for guix system right now, but I fear I might have missed a big oversight. <jnms>This obviously does not work for grafting, right? <ekaitz>jnms: isn't that a very interesting patch for guile itself? <jnms>du -sh $(g time-machine -q --branch=version-1.5.0 -- build guix-minimal) → 445M <jnms>du -sh $(guix build guix-minimal) → 217M <jnms>ekaitz: it's very small, it implies linking with compression libraries though, so it's very opinionated <jnms>i'm mainly asking if grafting compressed files is a thing? <acidbong>jnms: does your patch only compile the modules differently or compresses them akin to kernel modules (which can be loaded from, say, .ko.zst)? <jnms>no compile functionality is changed (i tried to patch guile's (system vm assembler) but that was messy and didn't work) <jnms>only loader.c decompresses a .go file first if zstd the magic bytes are found <jnms>compression is just done as a guix phase, i renamed the .go.zst back to .go instead of adding a load extension for compatibility <yelninei>finally I have a patch that should be able to build llvm/clang@20 on hurd but I am not sure if it is worth submitting <yelninei>also should because i have not run tests yet because It ran out of space and a retry is 4h+ of waiting