IRC channel logs

2025-09-19.log

back to list of logs

<Deltafire>if i'm using time-machine to system reconfigure using the same commit as the current system, why is it downloading hundreds of megabytes of packages? surely they're already there
<kestrelwx>Morning.
<apteryx>why do we keep rust-bootstrap-1.54 still?
<apteryx>efraim: ^
<apteryx>ah, nevermind, it's for the arm and other architectures
<FuncProgLinux>πŸ€” code teams can be "proposed" via MR by anyone or should I ask the higher gnus for help? 😁
<apteryx>what do you mean?
<civodul>Hello Guix!
<mange>Good evening civodul!
<jlicht>hi guix! Is there support for installing librewolf extensions using guix?
<attila_lendvai>after a recent reconfigure my keyboard layouts have disappeared. am i alone with this?
<attila_lendvai>it's on Gnome, i must add
<jlicht>attila_lendvai: it has something to do with the libxml grafting issue; for now the 'workaround' is to use setxkbmap.
<jlicht>if you are on wayland, I don't know if there is anything that you can do at the moment
<attila_lendvai>yep, i'm on wayland
<attila_lendvai>jlicht, that's already helpful, thank you! at least i know it's not my config... i have a custom layout in ~/.config/xkb and i thought the problem is with that
<attila_lendvai>LLM says that 'GNOME 46 don’t talk to xkb directly anymore; they rely on IBus to enumerate all input sources.` and my custom layout is not listed by `ibus list-engine`. it suggests that i need to create some ibus XML and put it in ~/.config/ibus/rime/. i hope it's not indeed more complexity that has been added recently.
<Rutherther>I doubt that would work. The issue here is that gnome cannot parse xml file in the first place, so I don't know how making another xml file would fix that
<attila_lendvai>Rutherther, but everything else seems to work fine for me. shouldn't i see more pervasive problems?
<attila_lendvai>i pulled on sep 16, i'm on https://codeberg.org/guix/guix/commit/25e0b40ddf6f9699f11fc8e8c2d954502f77ad6f
<Rutherther>I don't know why you would have to see any more pervasive problems
<attila_lendvai>i (wrongly) assumed that not being able to parse xml would mean to more issues due to config files
<Rutherther>it's just libxlst that has issues
<csantosb>Hi Guix, good morning ! I'm wondering if it is possible to pull from a single channel, `(list (channel (name "mychannel" ...) ...))`
<csantosb>No guix default channel involved, I mean.
<attila_lendvai>FTR, i think this is where this issue is discusssed: https://codeberg.org/guix/guix/issues/2699
<Rutherther>attila_lendvai: sorry, libxkbcommon and libxslt, but libxslt is used elsewhere, not for input sources. See https://codeberg.org/guix/guix/pulls/2636
<Rutherther>csantosb: no, guix channel is an implicit dependency of every channel, there is no guix command or channels without guix channel
<csantosb>Oh. Not pulling again an already up to date guix just to include a new channel would be great to have.
<csantosb>By the way, any means of speeding up the fetching of CVE databases ?
<attila_lendvai>plus somethimes it's much faster/simpler to pull one commit from a channel than to also pull from the constant stream of commits to guix master...
<Deltafire>csantosb: you can pin the guix channel to a specific commit
<Deltafire>like, the one before the libxml updates broke keyboard layouts in gnome ;)
<csantosb>And so guix pulling keeps current revision ... neat, thanks
<attila_lendvai>Deltafire, do you have a commit hash for that?
<attila_lendvai>maybe this is the one where it started? https://codeberg.org/guix/guix/commit/3f0c91bf2670b3d5be1ae21586d51e979d8ef2d6
<csantosb>Given `guix lint -c archival -e '(@ (gnu packages guile) guile-3.0)'`, how to check all package in guile ?
<attila_lendvai>FTR, that commit doesn't work: profile contains conflicting entries for libxml2
<attila_lendvai>i mean its parent: f2bd80bdb74837d42f36b12e36781790b05002ff
<attila_lendvai>ACTION just tries to boot a previous generation to finally write that email
<attila_lendvai>yay! booting older generations to the rescue! :)
<simendsjo>I noticed chromium too is broken because of the libxml2 issue. It's not necessary to report this I guess?
<attila_lendvai>simendsjo, it's known. i've seen comments when clicking through the links i've pasted above
<hugohugo>@simendsjo a workaround to get ungoogled chromium to work: https://codeberg.org/guix/guix/issues/2733
<hugohugo>@csantosb the CVE databases are cached, so only pulling the latest one should take a siginficant amount of time. (Random thought: maybe we could make the CVE databases a package? One that is (automatically) refreshed daily.)
<yelninei>civodul: whats the status on the x86_64-gnu substitutes?
<tusharhero>futurile: About the substitution servers, how hard would it be to add this feature?
<tusharhero>I added a bunch of them expecting guix to automatically use the fastest
<jakef>is there a way to find out which gcc is being used by e.g. gnu-build-system? i know it's gcc@14 at the moment, but is there a programatic way?
<ieure>tusharhero, You probably want to see how fast the substitute servers are and configure the fastest one; same as you'd choose a local package mirror on Debian.
<tusharhero> ieure: there are some tools to do the equivalent automatically on archlinux
<Rutherther>jakef: for a programatic way, make a package that you turn into a bag (package->bag). Look at the inputs of the bag, choose one with name gcc and look at the version
<Rutherther>(to be more specific the bag-build-inputs)
<ieure>tusharhero, Not sure how Arch does it, but Guix is a bit different than other systems, and that means you'd need to account for that, rather than transplanting what works for another distro. Substitute servers aren't mirrors, often you'll have N substitute servers configured, but the substitute you want is on <N of them. And you'll almost always want to download from a "slow" substitute server rather than compile locally.
<FuncProgLinux>Finally brisk-menu on Guix \o/
<tusharhe`>ieure: I don't understand why we can't have a commadn which "ranks" the substitution servers, and then uses the fastest substitution server for future commands?
<tusharhe`> https://man.archlinux.org/man/rankmirrors.8.en
<ieure>tusharhe`, As I explained, different substitute servers have different set of substitutes. "The fastest" one may not have your substitute at all, and compiling locally is usually going to be slower than using a "slow" substitute server.
<FuncProgLinux>Can emacs packages be "excluded" from guix? I'm having issues with lsp-mode being pulled for some packages, I think I also saw that if you install emacs-nix-mode it pulls in company for some reason :o
<ieure>tusharhe`, Substitute servers are not mirrors, they're, at best, partial mirrors.
<ieure>FuncProgLinux, You can make package variants which remove the inputs, though the packages may break or have reduced functionality.
<FuncProgLinux>ieure: I see, so it's best to "just ignore"? I won't get really picky about it lol
<Rutherther>what arch rankmirror does is just order the servers. I don't see why it wouldn't make sense for Guix. As long as Guix chooses the first substitute server that has the path, you get the fastest substitute for given package. I am not sure in what way the logic of choosing is currently written though, if it's the first one or not
<ieure>Rutherther, Yes, you'd want some kind of priority per substitute server, where it prefers the higher-priority ones. I don't think we have that today.
<FuncProgLinux>btw ieure, thanks a lot for the emacs info-mode the other day, it was a lifesaver. I now ready manuals there, even guile is listed and it's so nice when learning scheme on a split screen :)
<ieure>FuncProgLinux, Oh nice! I really like info-mode, easily the best way to read info manuals.
<Rutherther>I doubt it chooses randomly... I would expect the first one to be picked and then it's already possible to do the same thing Arch is doing
<ieure>FuncProgLinux, Whether it's best to ignore stuff you don't like is a question for you. There are certainly tradeoffs involved.
<FuncProgLinux>ieure: I experimented that with pls. Someone added it and it works fine on lsp-mode but not on eglot
<FuncProgLinux>(Perl Language Server)
<ieure>FuncProgLinux, Interesting.
<civodul> https://pulls.ci.guix.gnu.org/pull-requests is starting to do stuff, but now it needs more disk space
<FuncProgLinux>Speaking about perl, if I wanted to submit an update, will it have to meet the same requirements as 2287?
<FuncProgLinux>If I bumped it to v5.42.0 I understood now all past versions should inherit from that new definition.
<FuncProgLinux>s/I understood/if I understand correctly
<futurile>FuncProgLinux: that's a big change - updating Perl will cause everything to be rebuild because it's so deep in the dependency tree
<FuncProgLinux>futurile: I was told that. 56k~ packages if I'm not mistaken :/
<futurile>FuncProgLinux: probably, I actually looked at something slightly higher up the other day - one of the Perl libs - and then realised it was going to be hell to test
<futurile>FuncProgLinux: there's no way I can build even 10% locally
<FuncProgLinux>oh no
<FuncProgLinux>We are on a Perl version older than Debian stable. But if that's way too much then I guess there's not much I can do then :(
<futurile>well no-one really works on Perl, there is no perl team
<futurile>we could create a branch for it, but realistically there should be a team of people willing to work on the changes
<FuncProgLinux>πŸ˜… i saw that
<futurile>in guix terms that realistically means 'more than 1 person, probably 2' - cos all our teams are tiny
<FuncProgLinux>I use the two things without a team on guix, mate and perl lol
<futurile>I don't mind looking at perl lib changes - I feel reasonably confident with those now - but I personally wouldn't commit a change to all of Perl
<FuncProgLinux>I would if I had more experience. I'm very green at contributing so all I can only commit to keep mate in a healthy state :s
<futurile>makes sense, if you care about Mate that's a big job in itself :-))
<FuncProgLinux>iyzsong and Rutherther have helped me a lot with that. For now I want to package the missing parts of the desktop and see if I can request a team-mate tag in the future for updates or users with issues there
<ieure>FuncProgLinux, I'm not sure Guix even has 56k package in it.
<FuncProgLinux>ieure: I've re read the issue and I overstated that! sorry :( the number was 35,334
<Rutherther>"guix refresh -l perl@5.36 perl@5.14" gives "Building the following 9112 packages would ensure 30164 dependent packages are rebuilt"
<futurile> https://packages.guix.gnu.org/ says 29k, but what's a few more between friends
<tusharhero>rutherther: I am not sure how it picks which server to use
<FuncProgLinux>Rutherther: Hey that's 5k packages less!
<yelninei>updating perl triggers a full system rebootstrap. Probably a good idea is to combine it with some other base packages (coreutils, patch, ...)
<FuncProgLinux>It makes me wonder how does nix do it x.x or how powerful is the OBS for the green gecko distro
<ieure>FuncProgLinux, Nix has probably an order of magnitude more people using and working on it than Guix.
<futurile>and they get free sponsorship from AWS, at least for the NARs (read a post the other day), not sure about the build farm
<FuncProgLinux>I see. It's a matter of peoplepower & infra being available
<futurile>we're pretty much struggling with the costs of our existing build farm - we spend a lot more on it than we receive from supporters
<ieure>Yeah, also, a lot of the infra Guix has (GNU) is very unreliable.
<futurile>not pretty much - that was a bit too British - we *are* struggling
<Rutherther>nixpkgs has a staging branch where all changes changing more than 500 packages go. This branch is then merged every two weeks to master (if nothing is broken ofc). So while the responsibility for individual changes is more vague there, they group more changes into just one branch, unlike guix where the changes are living on team branches, making it possible there will be multiple world rebuilds 'unnecessarily' (as in they might have been grouped...
<Rutherther>... together)
<Rutherther>(note that I have oversimplified it a bit, there is also staging-next, but just to get the idea...)
<FuncProgLinux>I understand, I'll try to donate this December if it's within my possibilities :)
<FuncProgLinux>I liked this system more than gentoo or any other source based I tried because most things wor automagically
<FuncProgLinux>s/wor/work
<bdju>I haven't used mgba in a little bit, but it seems like since it was upgraded in recent months on guix, it no longer has any sort of menu/gui system, and my old controls were reset. Also it lost the file type associations I had.
<bdju>It looks like the keys in the config file are all listed as numbers. How do I even figure out what's what?
<ieure>bdju, Is there a service that configures mgba? If not, that seems like an upstream doc question.
<bdju>Well, I was able to poke around a GUI to set my binds before. I'm just wondering if anyone even uses this package or if someone just broke it in an upgrade and never tested it, I guess.
<bdju>Maybe it's that the package doesn't have the Qt frontend anymore? I only see the one output for the package, though, and no separate package.
<ieure>The last update was https://codeberg.org/guix/guix/commit/a0f061d1b6af9bd18ecade9aa091e5108236839e
<ieure>Looks like it changed the build-system, but should def. still have a GUI.
<bdju>Thanks for the link. Interesting.
<bdju>Is `mgba` the only command provided by the package? I saw mgba-qt in my shell history but that doesn't seem to be found anymore.
<bdju>Although it's possible it didn't work when I ran it in the past either. I have a mix of mgba and mgba-qt in my history. I think I mostly just launched the gui thing from bemenu and navigated from there, though.
<ieure>bdju, `ls $(guix build mgba)/bin'
<bdju>I ran `guix locate mgba` and in the path to one of the older versions I found the gui at mgba-qt.
<bdju>0.10.3 and 0.10.4 on my system had mgba-qt but 0.10.5 doesn't have it.
<ieure>bdju, Sounds like a bug than, would you file it on codeberg? Might also mention apteryx, since I strongly suspect the build-system change is what caused your issue.
<bdju>Sure. Thanks for the help.
<ieure>No problem.
<FuncProgLinux>Oh wow, Artanis + HTMX + Missing.CSS is actually very nice :)
<FuncProgLinux>no npm required ;)
<e3bc54b2>anybody here using GuixSD on GPD microPC?
<e3bc54b2>I have decent investment in NixOS, ~4.5k lines of config for 4 devices including 2 servers, and am getting curious about trying guix
<e3bc54b2>it seems to need fair bit of work to etup guixsd on RPi, so microPC seems like the next best bet..
<ieure>e3bc54b2, Yeah, raspi is rough because it needs firmware blobs, which Guix forbids. I tried making it work (not all that much, but hey), but haven't pursued it.
<ieure>e3bc54b2, I did some work on the firmware end of things, https://codeberg.org/ieure/atomized-guix/src/branch/main/atomized/packages/raspberry-pi.scm and https://codeberg.org/ieure/atomized-guix/src/branch/main/atomized/services/raspberry-pi.scm if you want a starting point.
<e3bc54b2>I'll take a look, thanks!
<e3bc54b2>Although I'm worried about performance. Neither RPi 4 nor GPD micro are exactly workhorses
<ieure>Yeah, I wouldn't use either as my primary machine. I have a raspi that runs MPD and connects to my fancy headphone setup.
<ieure>e3bc54b2, I think there's an example raspi operating-system in the Guix repo also, though I believe things don't work 100% due to no firmware.
<ieure>But I think you can probably hack something together with that and my stuff as a starting point.
<ieure>PRs welcomed if you find issues with my stuff.
<e3bc54b2>haha, I don't know scheme beyond car and cdr
<e3bc54b2>anyway, I'll probably take first shot with microPC. At least it has dumb old Intel inside
<vagrantc>e3bc54b2: i've gone pretty far without knowing what car and cdr are, fwiw
<vagrantc>but do occasionally have "pulling at my hair for hours knowing some trivial thing should be doable"
<e3bc54b2>vagrantc: that gives me hope
<e3bc54b2>whats the simplest dumbest way to learn scheme? Hopefully by implementing stuff more than reading about it first, something tailored towards experienced programmers.
<e3bc54b2>And without tying my whole system to it, for now haha
<vagrantc>i don't know scheme, i just package stuff in guix
<vagrantc>which gives the illusion of me knowing scheme, but i assure you, it is all smoke and mirrors :)
<e3bc54b2>like.. I know how computers work, what memory, pointers, basic data structures.. I wanna build some things, but even if I start writing a small script I don't know any requisite APIs and finding them takes up all the spare time available
<vagrantc>pretty much, i looke at a package definition and learned how to use guix hash and fill in the blanks ... learn how to use substitute (if poorly) ... and figured out how the patch thingies work
<e3bc54b2>LLMs are not bad, but then I haven't learned anything..
<vagrantc>take a package you like that is in guix ... and "guix edit PACKAGE" ... and see how it is packaged ...
<vagrantc>if you're lucky, it will show you the code that actually produces the package... though occasionally it misses a bit :)
<e3bc54b2>okay, I'll check out some package definitions. It is so nice browsing codeberg for random guix package code too
<vagrantc>i'd recommend avoiding the huge projects like web browsers or the linux-libre kernel, as those are a little unusual ... but many package definitions are pretty straightforward
<e3bc54b2>yep. I'm very used to browsing Nixpkgs, but I still have no idea what goes on in building KDE stuff or kernel versions. All black magic to me
<getstate>question, does any %desktop-service create /etc/ipsec.secrets?
<getstate>nvm, it's network manager