IRC channel logs

2026-01-04.log

back to list of logs

<noe>lfam, the freeze is still in effect until the release is done
<lfam>noe: Okay, so that means no updates on 'master'?
<gabber>why is my pine64-barebones-os-like image not booting (the system waits for a partition with a specific uuid to appear)?
<nckx>Rutherther: mailing list moderation is actually Guix, not GNU, but in this PotentialUser's case there was a reason for the hold.
<nckx>Mostly excess suspicion on my part but that's a reason.
<nckx>👀
<Rutherther>nckx: oh? interesting. Thanks for correcting me. Every time someone asked this question, no one knew the answer to who is doing the moderation.
<Rutherther>gabber: that sounds like it cannot detect that partition. Happens for example when missing a module in initrd modules. Has it ever booted with image made the same way? What device is image put to?
<Nessah>Good morning, Guix. Was Enlightenment removed from the installer, as it's not a working login option atm?
<untrusem>seems like it was https://codeberg.org/guix/guix/commit/214aa26e5c281473d641fb026d2ad7d3b7515031
<Rutherther>Nessah: it was removed from the installer because it hasn't been touched in a long time
<Nessah>That's understandable, thanks for the notice.
<gabber>Rutherther: exactly. it's a pine64 lts. no, it has never booted (yet) with this image, but i had it booting at some point. adding sunxi-mmc to initrd modules did not help, guess i'll have to try a non-liberated kernel next
<Rutherther>gabber: yeah, I would expect just sunxi-mmc to not be enough
<Rutherther>at least also mmc_core, mmc_block. And even though I suppose these are dependencies of sunxi-mmc, I would also add sdhci and sdhci_pci
<Rutherther>or maybe sdhci_spi instead of pci
<lilyp>noe: It's fine; packaging whatever we can takes priority
<lilyp>btw. do you have the resources to build webkitgtk on your own? I kinda want to enable webrtc
<mthl>Hello, I am looking for someone interested in reviewing some Clojure related PR <https://codeberg.org/guix/guix/pulls/5162>
<umanwizard>I was able to bisect to find the commit that is breaking Mate on my system and causing it to boot with a blank screen: 7db9c56b770 (gnu: xorg-server: Update to 21.1.20)
<umanwizard>Rutherther: If you're still around -- you mentioned Mate is working fine for you on an aarch64 VM setup? Could you check whether you have that commit?
<Rutherther>umanwizard: yes, I did have that commit. That is strange to me though, since it's just a minor bump
<Rutherther>what gpu do you have attached in the VM? Is it virtio_gpu?
<umanwizard>I need to shut down in order to check that (UTM UI doesn't let you see most settings unless the machine is shut down ...)
<umanwizard>And this IRC session is running in the VM
<umanwizard>So, let me check and then come back and tell you
<umanwizard>alright, I checked, no, it's virtio-gpu-gl-pci
<umanwizard>which is hardware-accelerated
<umanwizard>maybe worth trying the one you mentioned?
<umanwizard>lol, nope, `virtio-gpu-device` (I think that's the one you mentioned?) doesn't work at all (no display output whatsoever, not even the SDDM login screen which was working previously)
<umanwizard>aha, `virtio-gpu-pci` does work!
<Rutherther>umanwizard: does work - even MATE does work?
<umanwizard>Yes
<umanwizard>Rutherther: thanks for the tip to check GPU device, that is very helpful! A bit sad that I lose hardware acceleration... but I'm not exactly playing games on this VM, so I think this unblocks me
<umanwizard>I would file an issue somewhere, but it's hard to know whether the bug is in Guix, UTM, Qemu, Mate, xorg-server, or my hardware manufacturer (Apple)
<Rutherther>great to hear that. Still we should probably do something about that, but I am not sure what, this is not an area I would have much knowledge in. I think it would be worth it at least creating an issue. I can try virtio-gpu-gl-pci at my end later, to see if I have the same behavior
<umanwizard>Or even something else
<umanwizard>Sure, I'll at least file an issue in Guix, which can't hurt
<Rutherther>I would go with opening a bug to Guix for the time being, it's likely people will be searching there if they encounter these issues
<Rutherther>(as long as they are using Guix System I mean)
<umanwizard>What's the current best place to file issues against Guix? Is it still the mailing list, or is it Codeberg now?
<umanwizard>Looks like the Codeberg issue tracker is active, I'll file one there later today
<umanwizard>Thanks again for the help
<Rutherther>umanwizard: Codeberg definitely. bug-guix is obsolete, in favor of Codeberg
<FuncProgLinux>Rutherther: A bit late, but MATE does work lol.
<Rutherther>FuncProgLinux: hm? Could you elaborate?
<mthl>My PR <https://codeberg.org/guix/guix/pulls/5162> has been reviewed (Thanks Sergey Trofimov). I would be really pleased if some committer could take a look at it, and merge the branch if the changes are fine.
<FuncProgLinux>Rutherther: I was reading the older messages from today. Idk if the user could fix their broken MATE installation
<Rutherther>FuncProgLinux: yes they could by swapping out the virtio gpu driver they used. Minor bump of xorg-server has broken the one they use
<FuncProgLinux>Rutherther: Ah I understand now. I though it was an issue with MATE itself :s
<Rutherther>also note that this is about AArch64
<csantosb>mthl: Your PR implies changes in clojure-build-system, right ? Consider how may packages this change will affect
<FuncProgLinux>Rutherther: oof, not much I can do there :(
<lh>apteryx: why did you revert bash 5.3? nothing in the commit message. should we have an issue for the update if there’s prerequisites to unravel?
<mthl>csantosb: Yes it upgrades the version of Clojure that is used in the clojure-build-system. The number of impacted packages is rather low. only 25 packages are using this build system (all defined in the (gnu packages clojure) module) and nobody depends on this module
<mthl>except the clojure-build-system itself
<gabber>how can i tell `guix gc` to delete specific (e.g. `/gnu/store/*-disk-image') files from the store, but not their dependencies?
<Rutherther>to delete a specific path, you use the -D option. Dependencies are never removed, only dependents
<gabber>but that stops at the first "live" path
<gabber>can i tell it to keep going after a failure?
<Rutherther>oh you mean like when you supply all the paths to one guix gc -D. Just make it multiple guix gc -D commands with one path each
<gabber>you mean something like `find /gnu/store -name "*-disk-image" -exec guix gc -D {} \;` ?
<Rutherther>yes
<gabber>darn. had not thought of that. am rebuilding linux-arm64 through qemu again now :(
<lilyp>because you *want to* or because you're chasing a moving branch?
<lilyp>imho, rebasing gnome-team on master regularly is quite annoying with all the unwarranted pseudo-world rebuilds thrown my way like weekly
<Rutherther>who is doing those rebases and why? I understand them when the branch is in the QA queue, but not really when it's in the development phase
<gabber>lilyp: because i idiotically `guix gc --collect-garbage`d even though i knew i'd have to rebuild the big packages
<lilyp>oof, ouch
<gabber>i have to build the non-liberated one (not sure why yet)
<gabber>well
<umanwizard>ok, now I've bisected (in the xserver git repo) to the exact commit that causes my problem:
<gabber>it's a bummer when working on disk-images, because you don't need the images after they failed, but each build is a 5GiB drain on my
<gabber>main drive
<umanwizard> https://gitlab.freedesktop.org/xorg/xserver/-/commit/fc7012515308e860130e29bb55d070adaae3e87c
<lilyp>Rutherther: I do it, because gnome-team is somewhat overdue and because the only thing more annoying than world rebuilds are conflicts on top of world rebuilds
<umanwizard> https://codeberg.org/guix/guix/issues/5367
<umanwizard>Maybe I'll submit an issue to Xorg too, given that I bisected to the exact commit that's causing the problem.
<Rutherther>umanwizard: good, you're really not afraid of bisecting it seems. Agreed, seems it's indeed an issue at their side
<umanwizard>It wasn't too hard in this case, I just made a separate my-xorg-server package that got the source from a git commit and used that in my configuration instead of default xorg. So I just needed to edit my desktop config and reconfigure at each stage, I didn't need to do `guix pull` taking forever
<umanwizard>hmmm, now I get 503 when attempting to load codeberg ...
<gabber>umanwizard: they're having issues atm. -> status.codeberg.org
<umanwizard>thx
<gabber>HTH
<meaty>
<gnucode>well, that's a first...starting Emacs in sway, kills sway. and I am brought back to the console.
<gnucode>weird.
<gnucode>I guess I am using vim today.
<gabber>gnucode: why no roll-back?
<bdunahu>would `home-channels-service-type' allow me to pull from a different set of channels per machine?
<bdunahu>or is that the best way to do that?
<gabber>bdunahu: WDYM "different set of channels per machine"?
<gabber>IIUC home-channels-service is for differnt channels per user profile
<bdunahu>That's not quite what I need then, I have one set of dotfiles and two machines, and I want each machine to use a different set of channels in the least manual way possible
<gabber>guix (package) channels?
<bdunahu>yes
<gabber>then i think home-channels-service-type is right for you
<gabber>though i am not 100% what the dotfiles have to do with it
<Rutherther>bdunahu: so just define the service with different value for each machine. Also note that the service just populates ~/.config/guix/channels.scm, meaning that it's just that you will pull from these channels when you do "guix pull" without -C specified
<bdunahu>okay that sounds like it will work for me, thank you both!
<cow_2001>is there an emacs M-x compile but with commands that run in guix shell containers and those containers are not recreated each time compile is being run?
<gabber>cow_2001: you mean something like direnv?
<cow_2001>hmm... would have to look into it