IRC channel logs
2025-12-05.log
back to list of logs
<postroutine>Guix System is very new for me. On the other distributions I have used, the /boot is not encrypted and contain grub, initramfs and the kernel. I didn't think it would be different on Guix system. But that make sense if the kernel and initramfs are in the store and not copied in the /boot. <ieure>Yes, this is a known issue. It is rather annoying. It'd be less annoying if Grub's decryption was faster. <ieure>postroutine, Yes, the only thing Guix leaves cleartext is the Grub EFI payload. Which is a thing I like. <Rutherther>I think it took a minute for me with 800 GB partition, so I stopped letting grub do the decryptions rather fast :) <ieure>I don't think it has anything to do with the partition size, it's using the KEK to decrypt the DEK. <Rutherther>really? so why did it take so much time for me then, I read somewhere it's much faster for other people <postroutine>If the kernel and initrd are in the encrypted partition, I think it would help if grub simply ask for passphrase instead of only show a grub shell. <Rutherther>it should ask you for a passphrase, did it really not? <Rutherther>maybe it will fix for you after reconfigure. Who knows. Something must've gone wrong <ieure>Rutherther, I haven't timed it, but it is very slow. <ieure>Have to boot to reconfigure. <ieure>Yeah, that's not right at all. <ieure>Literal very first thing is Grub asking for a passphrase. On my main ThinkPad, it doesn't even clear the screen, it prints in the upper-left and you can still see the Lenovo logo. <ieure>Rutherther, I haven't timed it, but it's insanely slow. I'm pretty sure Debian on the same hardware would get to the GUI greeter before Grub even finishes. <postroutine>Maybe I need to clean my disk before installation. Because here, I still found a `efi/fedora/` in my boot partition. So, maybe it was not erased and something from the previous distribution make grub fail without an error messag. <postroutine>But for now, it freeze after login to the gnome session. And the force shutdown didn't work. I need to found the reset button. <ieure>postroutine, Not sure what you did, exactly. I don't think Guix formats the disk in every case, since you might want to dual-boot, and it'd be very rude to nuke the other OS. Sounds like whatever you did in your install, it did not wipe and repartition/reformat, and the old OS artifacts are causing the issue. <postroutine>I remake the installation and the guided graphical installation say it will write the partition table and format the partitions. It also say they data will be lost. <postroutine>So, I don't know why the boot partition still have a `efi/fedora` directory. <postroutine>Great, the new installation is not recognized by the PC. <postroutine>The EFI show me the list of disk to boot from and when I select the SSD it come back to this menu. <postroutine>I think grub was not installed by the disk installer. <postroutine>I will not have Guix System today. Well, I'll search tomorrow why. <meaty>how do I get php packages installed? <meaty>or rather, I'm trying to serve a php script but it can't seem to find the php modules included in the php package <bdju>I tried a guix pull + upgrade again today, now it's a different python thing stopping me from upgrading. python-cryptography, propagated from python-authobahn and magic-wormhole. <basicnpc>If my project depends on some other libraries, but I want to make some quick changes on the libraries, what should I do? Should I patch the library? Or is there some easier, temporarily mutable way? <basicnpc>(Or can I temporarily make that lib not read-only, and make change directly in guix store?) <flurando>Hi, does the unbound-service-type in (gnu services dns) use DNSSEC for forward-server by default? Or must I set anchor stuff in extra-options mannually? <flurando>I wish this is enabled by fault as I don't see any triggers for it, and DOT/DOH is banned here in China so the tls switch would not work. <apteryx>sneek: later tell civodul congrats/thanks for having resolved the remaining memory leaks in Shepherd/inetd services; it seems to be operating stably now! <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, apteryx says: congrats/thanks for having resolved the remaining memory leaks in Shepherd/inetd services; it seems to be operating stably now! <apteryx>I just pushed 9e77e52dc37 that fixed the containers test regression the (scandir "/proc/self/task") thing which would fail in some environments <Kabouik>Hey #guix. Is there a way to tell when I started using Guix if I garbage collected my oldest system generations? <Kabouik>I was trying to do some archeology and put a date to my first Guix install. <Rutherther>You could look at an edit date of a file that doesn't really change, like /etc/machine-id <civodul>apteryx: thanks (didn’t see the PR for the /proc fix, sorry) <bdju> https://0x0.st/Kt0k.txt Is this worth filing an issue on codeberg? I had a bad experience last time I reported a package conflict. I'm not trying to skip anything here, though (other than the --keep-going but I don't see a build failure). <Rutherther>no, it is expected that you cannot install two variants of the same package to the same profile <bdju>Sigh. Yeah that's the kinda thing they told me last time. I'm not actually trying to do that, though. I'm literally just trying to upgrade my packages. So why isn't it working? <Rutherther>send your profile manifest - "guix package --export-manifest" <bdju>A few days ago I had a similar conflict with a different package, then it changed to this after some guix pulls, so I assume it is an upstream issue being slowly worked on or something. <bdju>Maybe the dependencies for something changed. <Rutherther>no, you do have magic-wormhole twice in your profile <bdju>Ah, right, the transit-relay thing, I guess? <bdju>I don't think that was a recent addition so something must've changed with the recipes. <Rutherther>no, this is not about magic-wormhole-transit-relay, it's only about magic-wormhole package, there are somehow two in your profile <Rutherther>okay, then I am confused. The manifests contain only one magic-wormhole. Can you try "guix package -m manifest.scm", manifest.scm being the one you obtained through --export-manifest, if that will fix it? <bdju>Something wrong with python-axolotl now. <bdju>Looks like it's called python-axolotl-curve25519 now maybe. <bdju>Should I just hand-edit that manifest with the new name? <bdju>I see also the -dr version that says it's a fork, maybe I wanted that. <bdju>Wait, no that one's omemo. Ugh. <bdju>What happened to the python-axolotl package? I wonder why I even had it. Maybe for gajim. I'll just comment it out. <Rutherther>it got removed 279df705b44353e1cf345ef04e8183a91994bc8a, but I do not know why <bdju>Now I'm got a build failure for font-cozette, and I believe I can't skip packages when applying a manifest, and if I comment it out it'll remove it entirely... <bdju>If I remove it to get the manifest to apply, won't I also be unable to manually install it afterward since the latest version doesn't build? Or is there some sorta way to get the old one with time machine? <bdju>I used to use manifests a few years ago but I haven't in a while due to constantly needing to skip stuff like that. <Rutherther>sure you can use guix time machine or just your older /var/guix/profiles/per-user/$USER/current-guix-X-link/bin/guix install <bdju>Hmmm. Interesting. Have not done that before. <Rutherther>I think that the error message you got initially is somehow wrong <Rutherther>and that the actual cause of the issue is that python-axolotl that can no longer be updated, because it got removed <Rutherther>I think that if you do "guix remove python-axolotl" and then try to upgrade, it could all be fine <Rutherther>if that is the case... I think there is a bug, specifically in the logic that figures out where a conflict arose <bdju>Ah, good idea. Lemme try that. <Rutherther>because previously they could rely on file-systems, they cannot anymore <morenonatural>hey, y'all… I want guix to use a directory under /home (I believe it uses /gnu/store) how can I configure that? <bdju>Rutherther: Thanks for the help, I didn't get the package conflict when updating now after removing python-axolotl. <Rutherther>bdju: feel free to report this as a bug, stating that the message is wrong <Rutherther>morenonatural: you would do that by setting the NIX_STORE env var for both your session and when starting guix-daemon. But you will probably figure out you don't really want to do that, because you will have to build everything yourself <Rutherther>note that you would have to install guix from source, the tarballs are ready for /gnu/store only <morenonatural>Rutherther, I guess it's easier to symlink, then… I'm using a systemd-based OS, any service I should stop before migrating-then-symlink? <Rutherther>I don't think symlinking will help, only changing root, ie. proot/user namespaces and so on <Rutherther>I am not aware of any tool that would make that easier for Guix, I have seen few only for nix <morenonatural>oh, crap… this is the last time I use a separate partition for /home ( / is running out of space ) <morenonatural>I could symlink in a similar situation with docker, but hey, no biggie <morenonatural>I want to use the arei package in emacs, providing the files with guix… how do I use use-package in this context? <bdju>I also stopped using a separate partition for /home because of Guix System (or maybe it was NixOS) some years ago, haha. <bdju>I think even when I gave / 100GB it wasn't enough, and it became too much of a pain to keep resizing from a liveCD. <look>btrfs and subvolumes for me was the answer for this whole partitioning problem, never looked back to ext4 <look>i can have my home separate from / and still use the whole device space for everything, very convenient <orahcio>Hi, I'm wondering what happened to the python-bibtexparser package in the Guix repository. The latest version available is a beta (v2). Why is the stable version no longer there? <avalenn>codeberg.org is a bit unstable at the moment, they are now aware of it <avalenn>my "git pull" was not working because of 503 <avalenn>s/git pull/guix pull/ (I constantly mistype the one for the other <lee-thomp>what is the current state of the art for cross-building and running on Guix? for example if I had some arm64 assembly source and wanted to assemble it into an arm64 binary and then run the binary using qemu-user all from an x86-64 host? <Rutherther>what do you mean on guix, do you mean on guix system? Or how exactly does guix come into the picture? <lee-thomp>apologies, indeed a full guix system install <Rutherther>then probably the easiest solution is using qemu binfmt, then you can just start the executables directly without having to execute qemu user yourself. There is a service for that <lee-thomp>okay that looks good for running binaries thanks <ieure>Note that the qemu binfmt service *emulates* aarch64, which is dirt slow on just about any x86 rig. <lee-thomp>for compiling/assembling some arm64 binary on an x86-64 guix system host would my best option be to wrap the whole thing in a package definition and then `guix build <package> -s arm64? <lee-thomp>ieure: I think this may be fine for very small experiments, could I also get this hooked up to KVM to accelerate things? <Rutherther>guix build -s will not cross compile, that does emulation. --target is for cross compilation <ieure>Right, but note that cross compilation produces different hashes than native compilation. <ieure>I think the only scenario where cross-compilation is a good idea for Guix is if you're using `guix deploy' from one arch to another arch; and never reconfigure the other host from itself. <lee-thomp>it may be useful for me to clarify all I really want to do is learn some arm64 assembly and I don't have a Raspberry Pi or other ARM sbc with me currently. I could really just set up a VM I suppose <ieure>lee-thomp, I agree with Rutherer, then, a cross shell is probably your best bet. <Rutherther>If you do not want to depend on a third party tool, then "cross-gcc-toolchain" procedure from gnu packages cross-base could support your scenario, as long as you do not want to add any libraries except for libc. Make sure to NOT have gcc-toolchain in the same profile you install this to. They are incompatible and will cause issues <Rutherther>however I would really appreciate if someone tried my own cross shells :) I haven't received much feedback that would outline some of its limitations in scenarios other people use <lee-thomp>Rutherther: thanks for the advice, cross-gcc-toolchain and the qemu-binfmt service have gotten me going quite well, I'll try out your shells and see how I get on with them also, cheers <ieure>"0.0% substitutes available (0 out of 1)" on both machines. <ieure>It has since yesterday, I tried to install a machine and the online check failed. <postroutine>Hello. I'm trying to boot on a freshly installed Guix System. The system is installed in 2 partitions: The boot and the root. In the boot one, there is a grubx64.efi but the computer cannot boot when I select this disk. It always come back to the disk selector with no error message. During the system installation, there was no error message about the installation of the bootloader. <vagrantc>postroutine: secure boot configuration? although i would have expected that would have blocked the installer... <ieure>postroutine, I have encountered this a few times, and don't have a solid hypothesis for what causes it. I've solved it before by booting the installer to GRUB and chainloading the EFI payload from the internal disk, and pulling/reconfiguring the system. <ieure>postroutine, I've also seen improvement in install reliability from updating my BIOS, and making sure it's set to UEFI-only boot. I have seen some buggy BIOSes which refuse to boot Linuxen for some reason (not just Guix), or cause installer confusion around legacy BIOS/UEFI boot. <ieure>But since I don't really know what causes it, I'm not 100% sure those are doing anything that trying again isn't. <postroutine>The computer was booting with no problem on Fedora Workstation. <postroutine>Secure boot was enabled, but disable it give the same result. <ieure>If Secure Boot was enabled, the installer wouldn't have booted, it's not signed. <postroutine>In the computer EFI menu, secure boot was marked as enabled. <postroutine>I will try to start on the installation disk grub and chainload fron the internal disk, as suggested by ieure. <cdegroot>Since the last pull, my (common lisp based) window manager doesn't want to start anymore. It's distributed as a Guix package, just a bunch of .fasl files under /gnu/store, but on loading it from the REPL it wants to write a new .fasl file in the store, which fails with a readonly error of course. Not sure whether "compiling .fasl" makes sense, but that's weird, not? Mostly posting this here on the off chance that someone has seen <cdegroot>something similar and can save me the debugging time :) <Rutherther>postroutine: have you tried booting from the efi shell - does that not produce any errors? <Rutherther>cdegroot: I haven't encountered that, but it sounds to me a bit like the guix package didn't compile a file for some reason and now it's being compiled on the fly when running the application. And that is impossible because gnu store is immutable <cdegroot>Yeah, but given that the package in the store just has fasl files (lisp object files, sorta), and not lisp source files, I have no idea why it wants to do that. <identity>it seems that the font-opendyslexic package does not contain OpenDyslexic Mono and some other fonts, the git repository does not have the compiled font files for Mono&co. either; should i open an issue? <postroutine>I could chainload from the install disk grub to the system disk grub. <cdegroot>It is stumpwm, yes. But I've been using it all the time, that issue is 5 months old (I'll still give it a good read, might be related. I did do some cleaning up of Common Lisp related stuff on that machine so I may have accidentally unmasked the bug) <cdegroot>(my issue happens earlier, I think. STR is essentially 1. start SBCL, 2. (asdf:load-system "stumpwm"). <cdegroot>That works on a Guix setup from a week ago, fails on a fresh pull. I guess I have some digging and disecting to do :) <FuncProgLinux>I'm looking at the commit history and see if that particular wm changed, though I'm not very experienced on the matter <cdegroot>Yeah, I gotta run, I'll do some digging this weekend. I mean, I'm not even 100% sure of course that it's something that changes in Guix (versus something that changed on that particular machine; I always have small issues with bundled common lisp packages, SBCL, StumpWM and my normal development activities conflicting. Haven't been able to put my finger on it yet, but it doesn't feel separated/contained enough. <mwette>almost there: journalctl shows error during guix-daemon startup: guile: guile: warning: failed to install locale ; any ideas? root's package includes glibc-locales <identity>i.e. what is $GUIX_LOCPATH, does it point to locales and is the glibc used by the daemon compatible with the locales in question? <mwette>Environment='GUIX_STATE_DIRECTORY=/var/guix' 'GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8 ; locale/ contains 2.33/ <mwette>but guile used by guix-daemon seems to be using glibc 2.41 <FuncProgLinux>anybody else getting this iptables error after rebooting? arguments: (\"/gnu/store/wy7r78c7fq4as7pkp1sjpnd734agbmrf-iptables.rules\") exit-status: 2 term-signal: #f stop-signal: #f>")'. <ieure>Well, that's a new one. Accidentally reconfigured this box network-manager-service-type in the operating-system services. This caused the reconfigure to hang, because it killed nm / wpa-supplicant / etc, then tried to look for substitues. <ieure>I killed the reconfigure, but it still switched to the new generation, even though it didn't complete.