IRC channel logs

2025-03-28.log

back to list of logs

<nick_1>pegaso: avail for chat?
<nomike>I'm having a beginners-issue with my guix-home config: https://paste.debian.net/1365759/ Running 'guix home -L "${PWD}" reconfigure home-config.scm --dry-run` works as it should. But once I uncomment line 27, I'm getting a "error: emacs-packages: unbound variable" error: https://paste.debian.net/1365760/
<nomike>What I'm not getting is a few things: 1. What's different between 'emacs-magit' and 'emacs-org-mode'? 2. Why is it telling mthat emacs-packages is unbound and instructs me to `(use-modules (emacs-packages))'? That's quite confusing.
<identity>nomike: try 'guix repl emacs-packages.scm'
<identity>nomike: there doesn't seem to be an emacs-org-mode package
<identity>you want emacs-org instead
<nomike>Hmm...I've got the config from one of the guix devs (you might know him as daym). It's his personal config and I'm trying to clean up and it seems to work for him. That's why I was a little bit confused.
<nomike>Or could it be, that those packages have recently been renamed?
<nomike>Nahh...I think I messed it up.
<identity>there's also no reason to `(specification->package "emacs")` if you import (gnu packages emacs), you can just use the `emacs` variable
<identity>(same with other packages)
<identity>or you could leave it at that and remove the import
<apteryx>it's strange, I made a service test that minimally checks the shepherd service starts with (start-service 'pounce), and it passes, yet when I log in the VM the service clearly fails to even launch.
<apteryx>should I be checking the return value of start-service, perhaps?
<apteryx>looks like a common idiom now is to check with live-service-running
<apteryx>testing a service runs with (live-service-running (current-service 'name)) does the right thing I think
<mirai>apteryx: maybe the service started and crashed right after?
<mirai>iirc start-service does fail if the service fails to start
<apteryx>start-service and other low-level shepherd actions do not raise on service failures, I think
<apteryx>I think that must have changed around shepherd 0.9, which gained a transient state of services
<apteryx>so start always succeeds by itself (it's now asynchrone), IIUC
<mirai>I see this comment https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/herd.scm#n330
<mirai>your observation seems correct, yeah
<apteryx>at least the quassel service (and many others) seem to rely on the old way, making their tests not too useful
<mirai>maybe we should rewrite them to use the wait-for-service procedure?
<debbugs>Bug in guix-patches changed: "[PATCH 0/7] gnu: Add pay-respects." https://issues.guix.gnu.org/77040
<debbugs>Bug in guix-patches changed: "[PATCH emacs-team 0/1] gnu: emacs-next: Update to 31.0.50-0.467aba6." https://issues.guix.gnu.org/77225
<debbugs>New or unarchived bug in guix-patches: "[PATCH] gnome-xyz: gnome-shell-extension-unite-shell: update to v82" https://issues.guix.gnu.org/77327
<debbugs>Bug in guix-patches changed: "[PATCH emacs-team 0/1] gnu: emacs-next: Update to 31.0.50-0.467aba6." https://issues.guix.gnu.org/77225
<debbugs>Bug in guix-patches changed: "[PATCH] gnome-xyz: gnome-shell-extension-unite-shell: update to v82" https://issues.guix.gnu.org/77327
<debbugs>Bug in guix-patches changed: "[PATCH] gnu: profanity: Update to 0.15.0." https://issues.guix.gnu.org/77322
<debbugs>Bug in guix-patches changed: "[PATCH 0/2] Remove atlas and shogun" https://issues.guix.gnu.org/77321
<flypaper-ultimat>f
<flypaper-ultimat>(oops sory)
<flypaper-ultimat>btw, a while ago I submitted, could somebody have a look at it? https://issues.guix.gnu.org/76324
<flypaper-ultimat>*i submitted my first patch
<debbugs>Bug in guix-patches changed: "[PATCH 0/6] Rootless guix-daemon on Guix System" https://issues.guix.gnu.org/77288
<futurile>Morning all
<debbugs>Bug in guix-patches changed: "[PATCH emacs-team 0/1] gnu: emacs-next: Update to 31.0.50-0.467aba6." https://issues.guix.gnu.org/77225
<debbugs>Bug in guix-patches changed: "[PATCH emacs-team 0/1] gnu: emacs-next: Update to 31.0.50-0.467aba6." https://issues.guix.gnu.org/77225
<debbugs>Bug in guix-patches changed: "[PATCH] gnu: nextpnr: split devices." https://issues.guix.gnu.org/77114
<debbugs>New or unarchived bug in guix-patches: "[PATCH v2] gnu: nextpnr: split devices." https://issues.guix.gnu.org/77330
<debbugs>Bug in guix-patches changed: "[PATCH] gnu: nextpnr: split devices." https://issues.guix.gnu.org/77114
<debbugs>New or unarchived bug in guix-patches: "[PATCH] gnu: Remove variant-tools." https://issues.guix.gnu.org/77331
<debbugs>New or unarchived bug in guix-patches: "[PATCH v2] gnu: nextpnr: split devices." https://issues.guix.gnu.org/77332
<csantosb>What the ? I sent last two nextpnr patches to #77114 ... why they show up as #77332 and #77330 ?
<peanuts>"[PATCH] gnu: nextpnr: split devices." https://issues.guix.gnu.org/77114
<peanuts>"[PATCH v2] gnu: nextpnr: split devices." https://issues.guix.gnu.org/77330
<Rutherther>csantosb: there is a strange cc in your e-mail: Cc: Cayetano Santos via Guix-patches via guix-patches@gnu.org
<Rutherther>csantosb: there is a strange cc in your e-mail: Cc: Cayetano Santos via Guix-patches via guix-patches@gnu.org
<debbugs>Bug in guix-patches changed: "[PATCH] gnu: Add emacs-rescript-mode" https://issues.guix.gnu.org/77290
<civodul>hello debbugs & all! :-)
<janneke>hi civodul, debbugs and others :)
<Rutherther>hi ludo
<debbugs>New or unarchived bug in guix-patches: "[PATCH] gnu: emacs-orderless: Update to 1.4." https://issues.guix.gnu.org/77333
<Rutherther>when should I use mlet* %store-monad and when with-store & run-with-store?
<Rutherther>hi ludo
<Rutherther>when should I use mlet* %store-monad and when with-store & run-with-store?
<civodul>hey Rutherther
<civodul>if you’re in a monadic context, calling monadic procedures & co., then you can use ‘mlet’
<civodul>‘run-with-store’ lets you “escape” the monad
<debbugs>New or unarchived bug in guix-patches: "[PATCH] gnu: emacs-marginalia: Update to 2.0." https://issues.guix.gnu.org/77334
<civodul>whereas ‘with-store’ opens a connection to the daemon
<civodul>there were blog posts on these topics: https://guix.gnu.org/en/blog/2023/dissecting-guix-part-2-the-store-monad/
<Rutherther>I have read that one, but I still have trouble understanding it all, that's why I am asking. I basically just want to get a path to a derivation itself (.drv) without opening new store connection, and I am just trying to make sensve of it all
<Rutherther>I guess it's because of my lack of a thourough understanding of what a monad actually is, as then I cannot easily apply the knowledge to the store monad here. I haven't gotten much knowledge about functional programming
<debbugs>Bug in guix-patches changed: "[PATCH] gnu: go-github-com-lyft-protoc-gen-star-v2: Update to 2.0.4." https://issues.guix.gnu.org/77248
<apteryx>janneke: can hurd use PAM?
<apteryx>(I guess so, but making sure)
<janneke>apteryx: in principle yes, debian/hurd uses pam
<janneke>but "we" don't (yet)
<janneke>afaik
<janneke>"we" don't even have a decent/sensible login thingy yet
<Rutherther>civodul: I think I've managed to do it - https://paste.debian.net/1365874/, now I can use this in anything that accepts gexps, like gc-root-service-type and I get a symlink to a drv! using guix/monads.scm as examples helped me a lot
<apteryx>janneke: OK! I was looking at some package (ngircd) and wondering if we should build it with suppor for PAM for the Hurd
<apteryx>I guess building it with PAM makes sense, eventually we may be able to use it.
<apteryx>(or rather have it configured)
<graywolf>Hi Guix :) I am trying to configure log-rotation-service-type, and I cannot figure out how to tell it to keep X rotated logs. All I see is #:expiry, but that does not seem that useful.
<graywolf>Any ideas?
<debbugs>Bug in guix-patches changed: "[PATCH] gnu: profanity: Update to 0.15.0." https://issues.guix.gnu.org/77322
<graywolf>In general, is it possible to apply different log rotation rules per file?
<debbugs>Bug in guix changed: "=?UTF-8?Q?=E2=80=98guix?= shell =?UTF-8?Q?-C=E2=80=99_?= =?UTF-8?Q?doesn=E2=80=99t?= work on Ubuntu 24.04" https://issues.guix.gnu.org/71226
<futurile>what is with the =UTF-8.... there debbugs? Escaped options I guess
<orahcio>Hello, I want to unsderstand better the icons packages on guix, they need just to have a /share/icons/ThemeName path? And guix add to profile the new theme?
<Rutherther>orahcio: if you add the package to profile, yes, it will be in its output at that path, that's how profiles work, they union all folders from the individual packages
<Rutherther>orahcio: so yes, to produce a package that can be used as an icon theme, it just outputs to #$output/share/icons/name
<debbugs>New or unarchived bug in guix-patches: "[PATCH 0/3] gnome: Replace libgnomekbd with tecla." https://issues.guix.gnu.org/77337
<Rutherther>orahcio: so yes, to produce a package that can be used as an icon theme, it just outputs to #$output/share/icons/name
<orahcio>Rutherther: nice, yesterday I could to package the gartoon-dedux, and I think, nothing more need to do?
<Rutherther>orahcio: nope. As long as you use one of the regular profiles that are already in xdg data dirs.
<orahcio>thanks Rutherther, I need to learn how to submit packages
<debbugs>Bug in guix-patches changed: "[PATCH 0/3] gnome: Replace libgnomekbd with tecla." https://issues.guix.gnu.org/77337
<df>has anything changed recently that might explain why ~/bin is no longer in my PATH? I'm not using guix home so it seems rather unlikely, but I can't think of anything I've changed either
<df>it doesn't help that I can't actually remember how it was previously set
<df>could there have been a change to the global /etc/profile or bashrc?
<df>I'm not sure where the contents of those files comes from but the timestamp suggests that system reconfigure updates them
<Rutherther>df: no, the global files don't and didn't add ~/bin to path in the near past
<trevdev>Remind me: is dmesg the best way to debug failing USB hardware on Guix? The USB microphone in question works in Nix and Winblows so I'm thinking it's a Guix thing
<df>very mysterious, my ~/.bashrc hasn't been updated in a week and my .bash_profile since feb
<df>trevdev: I'd look at dmesg immediately after plugging it in
<df>also lsusb might help
<old>asking again since I'm not sure if I had an answer the other day. Is there a way to remove luk encryption on a file-system? Can I just remove this from my os description?
<trevdev>df: Thanks
<futurile>old: you mean you have an existing filesystem that is encrypted with luks, and you want to use it as an unencrypted filesystem?
<Rutherther>old: your operating system file-systems field just describes what file systems you have, it doesn't modify them. So no, you cannot remove luks encryption just like that, you will have to use other tool for that, then change your config and reconfigure, this all in a live iso / other system of course if it's the root partition
<Rutherther>and I am not even sure if such a tool exists or if you will have to backup, remake the partitions, and copy the stuff back
<old>Right it seems very dangerous
<old>I should probably just dd my whole nvme to my secondary one
<Rutherther>why do you want to do this in the first place?
<old>and try to change the os definition to this nvme
<old>because when my computer booted, Grub prompt for a passphrase
<old>and if I'm not home
<old>well I'm stuck. I can't SSH or anything
<Rutherther>old: if that is the only concern you have, and you don't mind the speed decline etc, you could also just use a key to unlock your system
<old>so I need to call a family member if they are home to enter the passphrase .. really not ideal
<old>what do you mean by key?
<Rutherther>decryption key... that is used to decrypt your partition
<old>like a plugged device?
<Rutherther>can be, doesn't have to be. Can be file on any accessible partition, so even any on the disk inside the device, ie. the efi partition
<old>that does seem to solve the problem of when I'm not home and it's grub asking
<old>does grub have support for minimal ssh?
<old>does not seem*
<Rutherther>how come? the key is available at any time, even for grub...
<old>so I just need to configure grub to take the key at some location in the initfs?
<old>sorry in the fat partition where grub is itself
<old>I mean I could probably configure grub to tell it to enter the exact passphrase automatically
<debbugs>Bug in guix-patches changed: "[PATCH] gnu: Add emacs-rescript-mode" https://issues.guix.gnu.org/77290
<Rutherther>first you generate the key, then add it to the luks decryption keys, then you reconfigure your system to use luks-device-mapping-with-options instead of luks-device-mapping and give it location of the key, that will configure both grub and initrd to get the key. The location
<old>ohh
<Rutherther>... will be just something like "/the-key" if you put it to your efi partition
<old>right that would work
<old>but really I think I should just try to remove the encryption completely. It really slow down the booting time
<old>not that I boot often, but it's still anoying
<Rutherther>that's why I said if the passphrase itself is the only problem
<old>right
<old>so I guess, dd from A to B. Change OS to use B instead of A would work nicely
<Rutherther>would it? doesn't that copy the encrypted partitions?
<old>I'm not sure
<old>eeh that's 756G of copy
<old>Oh well. Just need to backup my home then on a USB and will try to remove encryption directly
<debbugs>Bug in guix-patches changed: "[PATCH] gnu: go-github-com-lyft-protoc-gen-star-v2: Update to 2.0.4." https://issues.guix.gnu.org/77248
<debbugs>New or unarchived bug in guix-patches: "[PATCH mesa-updates 00/15] update vulkan and mesa to latest" https://issues.guix.gnu.org/77339
<debbugs>Bug in guix-patches changed: "[PATCH mesa-updates 00/15] update vulkan and mesa to latest" https://issues.guix.gnu.org/77339
<lechner>Rutherther / does 'reconfigure' call sync?
<debbugs>New or unarchived bug in guix-patches: "Request for merging \"mesa-updates\" branch" https://issues.guix.gnu.org/77340
<debbugs>Bug in guix-patches changed: "[PATCH] gnu: mesa: Update to 24.3.4." https://issues.guix.gnu.org/76411
<podiki>howdy guix!
<ieure>Rutherther, Emailed my system config & some other info just now.
<podiki>anyone know how we are doing on the branches? seems only a few have many rebuilds (like elogind, i assume c++, etc.) while others are just for organizing team work but with a merge request
<podiki>i just put in mesa-updates (~6k rebuilds, done on berlin) and it is 10th in line....
<debbugs>Bug in guix-patches changed: "[PATCH] gnu: llvm-spirv-translator: Fix cross compilation" https://issues.guix.gnu.org/76337
<debbugs>Bug in guix changed: "Filesystems not unmounted on reboot" https://issues.guix.gnu.org/77086
<futurile>podiki: one thing to be aware of is that Chris changed it so it's only building the first 3 branches in the queue
<futurile>python-team is blocked on someone having time to fix some build - details in the issue #
<podiki>i see
<podiki>i guess teams manage their own branches but we don't have and probably need an overall merge director
<bjoli>Ruthether: this is a similar issue to the one I have. I will try the steps in there: https://issues.guix.gnu.org/76959
<Rutherther>bjoli: it is not similar. It is the same issue.
<Rutherther>if you've read my e-mail to guix-devel, I actually sent it because of your and ieure's messages from yesterday
<Rutherther>bjoli: it is not similar. It is the same issue.
<Rutherther>bjoli: and yes, you can take those steps that are in it, you need to get rid of the broken generations
<Rutherther>has anyone considered making a tool similar to systemd's journalctl to read the shepherd logs nicely? filters for boots, services, paging...
<ieure>lol, I despise journalctl
<Rutherther>why?
<ieure>I find it annoying in a variety of ways, the one that happens allll the time is it truncates logs, then prints "call journalctl -xe to not do that." I would like it to never so that, ever, and resent having to correct it every time.
<ieure>Also generally dislike stuff with built-in pagers, since I use Emacs shell-mode for my terminal, pagers don't work there, and many, many programs have gotten too dumb to notice that they're not running in a fixed-coordinate terminal & conditionally use things like that.
<ieure>I'll always be a grep /var/log kind of guy, prolly.
<ieure>journalctl lacks the Unix spirit, it does everything itself instead of leveraging the standard tooling.
<ieure>Same can be said for systemd, really.
<Rutherther>truncates log? are you sure you mean the right thing? maybe I am just misunderstanding, but it's usually systemctl status that truncates logs and then you call journalctl to get the full log
<ieure>I know how to use grep/cat/tail etc, they've worked the same for ages, I don't want to relearn all that, except some specific command's option flag version of it.
<ieure>Mm, maybe you're right about it being systemctl status.
<Rutherther>yeah, I understand the concerns, but there are some thing for me that I don't really like about simple grepping, like seeind only 'last boot' messages kind of stuff, I always have to check the timestamps
<Rutherther>I don't really know what would the best approach be, I didn't really had recreation of journalctl in mind specifically, like it can be much more lightweight
<Rutherther>can be just simple guile / shell scripts that will for example find the shepherd init messages that it prints on boot and 'split' it like that, so that then you can see more clearly where boot happened or even filter by it
<debbugs>New or unarchived bug in guix-patches: "[PATCH] gnu: skalibs: Update to 2.14.3.0" https://issues.guix.gnu.org/77342
<Rutherther>re systemctl status, shepherd added similar thing to herd status recently I think, now I can see recent messages of services. Unfortunately it is only copy of stdout of running service, meaning when service doesn't start, I won't see anything in there about it
<Rutherther>(but it's possible to add -n to increase the number of lines printed from herd status)
<Rutherther>re systemctl status, shepherd added similar thing to herd status recently I think, now I can see recent messages of services. Unfortunately it is only copy of stdout of running service, meaning when service doesn't start, I won't see anything in there about it
<debbugs>Bug in guix-patches changed: "[PATCH 0/7] Add difft program." https://issues.guix.gnu.org/69696
<debbugs>New or unarchived bug in guix-patches: "[PATCH] gnu: mkp224o: Update to 1.7.0." https://issues.guix.gnu.org/77343
<debbugs>New or unarchived bug in guix: "kglobalaccel is missing polkit files" https://issues.guix.gnu.org/77344
<debbugs>Bug in guix-patches changed: "[PATCH] gnu: ddrescue: Update to 1.29.1." https://issues.guix.gnu.org/77247
<debbugs>New or unarchived bug in guix: "itk-snap does not build" https://issues.guix.gnu.org/77346
<debbugs>Bug in guix changed: "itk-snap does not build" https://issues.guix.gnu.org/77346
<dcunit3d>i built a guix system image to iso9660 that I'm trying to boot with a customized grub.cfg (based on https://github.com/aguslr/multibootusb). i can get the initial initramfs to boot, i think. but then it can't find the disk.
<debbugs>Bug in guix-patches changed: "[PATCH 0/2] Fix hdf5-1.14 wrappers and remove generated source files from all hdf5 versions." https://issues.guix.gnu.org/64448
<Rutherther>dcunit3d: so what parameters are you passing to the initrd and what is the log exactly?
<dcunit3d>in my operating-system spec, i've tried specifying this with a file-system label, then specifying `linux (loop)/gnu/store/asdf1234/.../vmlinuz root=$label gnu.system=....`
<dcunit3d>i mounted the .iso image onto loop0 on my desktop. from there, I lifted the lines from the grub config into my mbusb.d/usb-gpg-tools.d/live-generic.cfg
<dcunit3d>so that file looks like this. there aren't options passed to initrd https://0x0.st/8ex0.txt
<dcunit3d>i managed to get into the bournish shell. i can poke around in /sys, but most commands aren't available. i tried specifying root=$label after UUID didn't work. i think the bootloader is running in a different context that it would if the system booted directly from the ISO ... but i'm not sure how
<dcunit3d>if nothing else, i can just burn it onto a USB, but i'd like to have a better grasp over customizing grub.
<dcunit3d>there are a few images that I load fairly often: custom vyos, this usb-gpg-tools image, centos install, OPNsense, etc. so i'm trying to pack these onto one USB to make it easier to update & reach for when i need it. i disable PXE in BIOS on all my systems and don't want TFTP to run without a firewall.
<dcunit3d>btw, this page in the manual is super-helpful. the bootparam's for other distributions are tricky to track down. https://guix.gnu.org/manual/en/html_node/Initial-RAM-Disk.html
<Rutherther>by initrd arguments I mean the arguments passed to the 'kernel' command of grub, because, as far as I know, they are utilized by initrd
<dcunit3d>bootoptions="root=usb-gpg-disk gnu.system=/gnu/store/...-system gnu.load=/gnu/store/...-system/boot modprobe.blacklist=radeon"
<Rutherther>yes you already sent them
<dcunit3d>thanks
<Rutherther>they are fine
<Rutherther>or like.. I am not really sure how that quoting works like in grub but I hope it's fine
<dcunit3d>i'm not 100% sure either, but it works for vyos (i haven't been able to get OPNsense to boot this way)
<Rutherther>and vyos also has multiple arguments?
<dcunit3d>vyos has debian-style arguments, i think
<dcunit3d>bootoptions="boot=live components hostname=vyos username=live nopersistence noautologin nonetworking union=overlay console=ttyS0,115200 console=tty0 net.ifnames=0 biosdevname=0 findiso=${iso_path}"
<Rutherther>okay so the quoting shouldn't be a problem
<dcunit3d>i'm not sure where to find info on "boot=live" or "findiso=${iso_path}"
<dcunit3d>but i think the bootloader's context doesn't include the loop device. i'm not 100% on what it thinks the available devices are
<dcunit3d>boot=live seems to be a debian construct though
<debbugs>Bug in guix changed: "source hash mismatch on hypre" https://issues.guix.gnu.org/49206
<anemofilia>Hello guys :)
<anemofilia>Do someone here know the rationale behind the reset-var-empty phase of openssh?
<anemofilia>I don't understand why the existence of out/var/empty is desirable too
<ieure>It's part of the privsep stuff openssh needs: https://github.com/openssh/openssh-portable/blob/master/README.privsep
<PotentialUser-11>Hi, I installed guix with AwesomeWM. But I cannot open a terminal. As if no terminal emulator was installed. Is this possible?
<ieure>PotentialUser-11, Definitely.
<PotentialUser-11>Do I have to enable something during installation? Edit the default config?
<dcunit3d>the mbusb project does require isolinux though. i'm just going to find another USB for now.
<ieure>PotentialUser-11, I've never done an install with awesomewm, so, not sure. Probably simplest thing is to log into the Linux console (Ctrl+Alt+F1) and `guix install your-favorite-terminal-emulator', then log out/back in of your graphical session.
<anemofilia>ieure: Hm, it says about /var/empty
<anemofilia>Not $OUTPUT/var/empty
<anemofilia>My question is why we don't use /var/empty
<anemofilia>That phase explicitly replaces the use of PRIVSEP=/var/empty to PRIVSEP=$OUTPUT/var/empty
<ieure>anemofilia, Pointing it outside the package build would require some process other than installing the package to create /var/empty, ensure the right permissions, etc. Guix is a non-FHS distro, so very little exists outside the store, and almost nothing that's not a symlink back into the store.
<anemofilia>ieure: I understand that, but I do have a /var/empty nonetheless, I thought Guix provided it by default
<ieure>Not sure why there's a system-level one.
<ieure>Maybe the phase is just to make the package build work and it never gets used?
<ieure>anemofilia, Remove it and build the package and find out!
<anemofilia>Hm, but then it could be deleted in the end of the build, I guess
<ieure>anemofilia, No, it's in the package output.
<ieure>Maybe openssh-service-type makes /var/empty?
<anemofilia>ieure: I know, I was saying that if the $OUT/var/empty existence was due to testing purposes, it could be deleted by a phase after the tests
<anemofilia>ieure: maybe
<anemofilia>Hm, I guess a home service wouldn't be able to do that
<ieure>No.
<debbugs>Bug in guix changed: "Package hypre build failure for output \"doc\"" https://issues.guix.gnu.org/74672
<debbugs>New or unarchived bug in guix-patches: "[PATCH] gnu: Remove mia." https://issues.guix.gnu.org/77347
<Kolev>Hi all. Please do not leave GNU or the GNU FSDG. If you leave GNU, I might as well just use Fedora. Thank you.
<Kabouik>Is it okay to talk aout the guix-cran channel here?
<Rutherther>leave gnu? what does that mean?
<divya>Rutherther: Not sure you've been aware of, but there have been discussions around it: https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00014.html
<Rutherther>divya: thanks
<Kabouik>It seems many (all?) R packages from guix-cran are unavailable for arm64. Wondering if that's a real limitation or just the package definitions were not made with multiplatform in mind. I think nothing should keep us from compiling those on an arm device, yes?
<Kolev>I use Guix because of the GNU stamp of approval. In reality, I find Guix antiquated in some ways compared to Fedora Silverblue, and I might as well use it instead of Guix if Guix becomes just another distro.
<debbugs>Bug in guix-patches changed: "[PATCH] gnu: yt-dlp: Update to 2025.03.26." https://issues.guix.gnu.org/77319
<mjw>Kolev, I think the issue is that GNU is so toxic. And when people try to address the toxic elements inside GNU they get attacked for not being "loyal".