IRC channel logs
2026-02-21.log
back to list of logs
<mwette>gnu/machine/hetzner.scm is using dhcp-client-service-type (still?), seems deprecated (now?) <fhang>Anyone here have a working Qtile setup in Guix, running the latest version? Latest Qtile version is 0.34.1. <fhang>The mismatching versions causes Qtile to crash. <fhang>So I was wondering if anyone else here is having the same issue, or at least have it working. <fhang>This issue will probably be solved when Python gets updated to 3.12 or greater. So I guess it's just a waiting game until then. <ieure>Who owns sneek? Is there some way to get it to join #guix-browsers? <ieure>#guix-browsers is very new, hence, why there's no bot in there. <ieure>But... as many as we like. Channels are free. <ieure>I had no idea #guix-devel existed, lol. <ieure>FuncProgLinux, You're the only one in #guix-devel <FuncProgLinux>I'll have to search it on thunderbird but I remember someone here told me that <FuncProgLinux>I found it, it's at 02/09/2025 and it was you ieure who suggested it to me xD but your message only says "guix-devel", not "#guix-devel" <ieure>FuncProgLinux, guix-devel is a mailing list. <ieure>I tell people to talk there if they have intricate problems that need more time or space than IRC is a good tool for. <andreas-e>Yes! I am preparing the follow-up rebasing, force pushing and branch reordering. <andreas-e>I am letting kde-team go to the front, as it should be a small and low-risk branch; this will hopefully give us enough time to sort out gnome-team. <futurile>andreas-e: so what's happened with gnome-team, do we know, or we just know it's got a 'problem' when it's built? <andreas-e>I am right now git-bisecting the branch, where a test consists in pushing it and letting the data service try an evaluation. I am 3 steps away from knowing the faulty commit, if the hypothesis of a commit introducing some circular dependency between package modules (or a similar problem) is correct. <andreas-e>The build step (the equivalence of "guix pull"ing to gnome-team) works; it explodes in the step where all derivations are computed. <futurile>cool, got one of the peertube hosts to respond and they are OK with the type of content. Now I need to learn video encoding formats to try and squeeze the presentation down to be as small 'as is reasonable' <dariqq>i tried to update my fractal package but that thing is unpackagable even with the simplified rust crates. it depends on random git commits of 2 large workspaces who then also depend on more git workspaces recursively. Cargo is repeating the mistakes of npm <Rutherther>dariqq: I expect it shouldn't be too hard for Guix to support importer for workspaces. Or do you think otherwise? <dariqq>so in addition to every version on crates.io guix should package every commit in a workspace? The cargo ecosystem is beyond unmanagable and makes me actively want to avoid it <avigatori>So I've been wondering: when one just opens a guile repl by invoking "guile", is there a way to show all the functions and macros available at this point? <rrobin>avigatori: do you mean interactively, like tab completion? <avigatori>rrobin: no, a list is fine. I am just curious what is available by default because I haven't found a list of that anywhere <avigatori>I have a program I need to start with custom arguments. Is there a guix-y way to implement this? <Guest21>Through SSH I login to my Guix machine. I am currently working on my config. I thought with -X flag I can just forword the output auf qemu-img (I am running the command guix system vm) but it says gtk initialization failed. I assume it doesnÄt work as easy as that. The Guix machine has KDE installed through the installer. Does someone know a way, <Guest21>how I can look at the the qemu vm from remote? <Rutherther>Guest21: first of all, do you have x11 forwarding enabled on the server? <Guest21>Rutherther: I have not. Thanks for the hint. Will try again <yelninei>is it known why gash is so much slower than bash? <Guest21>Rutherther: Still gtk initialization failed error. I enabled x11 in the config and sshed with -X <Rutherther>so you've reconfigured the system and restarted the ssh service manually / rebooted, correct? <Rutherther>okay. Then try something simpler first, like xeyes to test it <Guest21>Maybe it is because kvm requires root <Guest21>Error: Can't open display: (I have a monitored attached to the Guix machine through DVI, it has also a keyboard and mouse connected, fyi) <Rutherther>it doesn't matter what is attached to the guix system machine <Guest21>Okay, it says the above error with -X <Rutherther>so you're connecting from a computer from within X11 session / wayland session with xwayland and, correct? What is the value of DISPLAY environment variable in the ssh? <Guest21>I am on a MacBook with iTerm that connects through SSH with -X flag enabled. The Guix machine runs KDE with GDM and defaults to Wayland <Rutherther>are you using XQuartz or something? Or where is the xorg server supposed to come from? <Rutherther>again what runs on the target machine doesn't matter. It is not used. X11 forwarding uses display of the machine that is connecting to the target computer (Guix System). Not the display of the machine you're connecting to. <Guest21>Rutherther: I am rebooting my mac and try it again. brb <Guest65>Rutherther: eyes work but running qemu results in X11 connection rejected because of wrong authentication. <Rutherther>Guest65: okay, that is probably solvable through some xhost invocation <Rutherther>that is likely the problem then, root doesn't have access to the display somehow <Rutherther>first of all, there is no need to run it with sudo as long as you add yourself to the proper groups <Guest65>its just a throwaway system, though i can fix it. <futurile>Guest65: is it 'local' or actually 'remote', you could use virt-viewer for example <Rutherther>yeah, you can switch the graphics of the vm to create a vnc server instead of creating a window and connect to it directly <Guest65>futurile: it is local. I simply don't want to switch systems all the time. I wanted to try out x11 first, since it would be less steps <Guest65>i don't get an error anymore, though I don't see a window either. It's probably not meant for this <Guest65>Rutherther: thanks for helping me out <Guest65>i assume it takes just ages till the data is received <yarl>I thought my table (3) was clear but I'm not sure ekaitz understood it when I read his answer. <Rutherther>I am also not sure because your e-mail seems to propose exactly what Ekaitz is saying we should do in his e-mail <yarl>1/ Is it understandable? 2/ What's your assessment? <Rutherther>anyway I think this isn't really an easy topic. Breaking the CLI interface is not free. There are definitely both people and CI processes that rely on it. So I don't think your proposal can be implemented easily <yarl>Still, there's no hurry. <yarl>And I think it has to be done. <Rutherther>that's why I proposed only a new store command that will implement parts of the guix gc, but it will not remove guix gc. Similarly, I do not think that we can just change the package subcommand completely <Rutherther>this is not about a hurry or not I would say. It's more like about thinking of a way to do it in a backward compatible way <Rutherther>like we cannot just replace the package subcommand of the guix command. We have to keep the old one and add a new one somehow somewhere <Rutherther>as I said, because both people and CIs/scripts rely on it. They will break on the pull that changes it <Rutherther>this is why commands are a GCD in the first place. Reverts are next to impossible. We cannot easily make breaking changes <yarl>Well, then I don't want to work on this. <yarl>It's already kind of a mess. <Rutherther>when people start relying on a given command, it is not possible to change it in a breaking way just from one version to another <Rutherther>for example nix solved it in a way of just adding a completely different command for a new version, so called nix3 commands <Rutherther>but for them, they had nix-build, nix-shell and so on commands and they replaced and improved it all with one nix command that has various subcommands <yarl>Rutherther: did they keep the old ones? <yarl>I think a clean and clear user interface is very important. <yarl>Rutherther: Do you know if they plan to remove the old interface at some point? <yarl>Do we plan to remove environment at some point? <yarl>Then I guess, the sooner we start, the better it will be. But maybe that's just my personnal opinion and most users don't care. <yarl>I'll wait for some comments on the mails. <nemin>Hey all. I'm working on a package and I'm getting a really bizarre error. When I use a specific module, Guix starts complaining about resolve-interface being unbound in a completely different file than what I'm either editing or referencing: https://paste.debian.net/hidden/32fb83c9 <nemin>Could someone please offer some wisdom? <nemin>My only guess is that it's a circular dependency, but if so, I'm not sure how to resolve it. <Rutherther>yes, likely a circular dependency. Send the diff you have please <yarl>ekaitz: take a look at the conversation with Rutherther ;) <ekaitz>yarl and Rutherther : the original email doesn't mention delete-generations under package <yarl>I thought that every action on profiles should go under one common domain : profile. <ekaitz>i didn't get the profile part! But I do like it a lot because we now have the concept of the profiles but they are hidden to the user in some way <ekaitz>in my defense I have to say that one was hard to find :) <ekaitz>yarl: if you are proposing a GCD, you should clarify where goes what <ekaitz>so the "ekaitz" case doesn't happen <ekaitz>but yeah, your proposal is what I wanted to do as the first GCD but never got the time to propose <ekaitz>so yeah according to 1/ and 2/ they are understandable but the intent is not so obvious so we should state it in text. <yarl>ekaitz: right. I'll wait a bit to get some more comments and clarify my intent if not clear enough. <yarl>generate-key should go under store <ekaitz>(well, in the internet nobody knows) <yarl>not under "store archive" <yarl>yeah, you're right about that. <yarl>I wanted to bring a draft discussion, for people to mention problems the faced. Just as you did with --help. <yarl>And to see if people are interested in this. <ekaitz>we should probably make some argument parsing library that handles all that automatically <yarl>And if that's feasible. Rutherther warned me above that it would be difficult. <nemin>Sorry if this is only tangentially related, but was there ever discussion for a "guix run" command? I'm thinking of something that'd work like "guix shell $PKG -- $PKG". It's an incredibly convenient feature of Nix. <yarl>nemin: I don't know nix, so I don't really get it. <yarl>what command would you have? <nemin>Let's say I want to run `tree`, but I don't have it installed. I could enter a shell, but I really just want to shoot it one-off. In Guix, I have to do `guix shell tree -- tree`. In Nix, I can just do `nix run tree`. <futurile>nemin: people mostly use 'guix shell -- ' as you suggested. The main think we're really missing is no shell hooks <futurile>nemin: I have a bunch of scripts that do guix shell -- bash -c 'blah blah' <nemin>It's definitely not a must-have, "shell --" works good enough, I just think it's an UX part where things could be slightly better, because you don't have to repeat the command and all. But maybe I'm biased by prior experience. <futurile>nemin: you're probably right, I don't anyone has said 'No', there just hasn't been an implementation attempt AFAIK <futurile>nemin: and a lot of people, like me, don't have that much experience with Nix - so we tend not to know the equivalent - I really should check it out but somehow never find the time <nemin>My bad, really. I figured people probably tried both since there aren't many declarative distros out there and the two share history. <mwette>nemin: Will a bash function do? (e.g., `function run () { guix shell $1 -- $1 }') <nemin>That certainly works, I was just thinking of having it part of the guix executable for consistency. <yarl>mwette, nemin: and if the package name and the command arent the same, you could rely on locate, but "For now, ‘guix locate’ builds its database based on purely local knowledge[...]" <futurile>nemin: you can always propose it / have a go ;-) <futurile>nemin: can you do the shell trigger thing they have while you're at it ;-) <yelninei>sneek: later tell civodul I rebuilt commencement.scm on my branch with coreutils 9.10 and new gash so all new problems should be resolved. Id appreciate it if some of the changes can be moved off to find out what else upgrading perl breaks. I solved it for the 3 texinfos but i am unsure what to do about curl. <nemin>futurile: Oh man, I can barely use Guix, haha. Maybe once I have a bit of experience. <nemin>Oh crap, I actually figured out my Hare problem. Turns out I had to combine module-ref+resolve-interface and then put it in the *propagated* inputs, not native. <mrh57>I created a service for a package (copyparty), but copyparty can't see a runtime dependency (ffmpeg) when run as a service, even though it can when executed normally as a user. <mrh57>Is there some special care needed to make sure $PATH is right for shepherd services? <yarl>mrh57: what is copyparty? I can't find it <mrh57>I packaged it, its currently in my own private channel while I'm testing/using <yarl>mrh57: Did you tried to use it in a guix shell? <mrh57>yarl: yes it works in guix shell <mrh57>yarl: I suppose the only odd thing I noticed is that it wasn't working with ffmpeg as an input, I had to make it a propagated input which isn't quite right logically <yarl>mrh57: I think that's a known issue with ffmpeg, I don't recall why <mrh57>yarl: oh hm I see, yeah I suspect it's ffmpeg specific because copyparty does find the other input deps <yarl>Actually no, what I was thinking about is an issue on mpv's propagated inputs, which includes ffmpeg. <yarl>"videos/audio: ffmpeg and ffprobe somewhere in $PATH" <mrh57>yarl: right, shouldn't putting ffmpeg in the package "inputs" or "propagated-inputs" do just that (it seems to work when not run as a service)? <yarl>I'm not sure for the service. <yarl>I'm looking at "(shepherd)Service De- and Constructors" <mrh57>yarl: oh perhaps play with environment-variables and user-environment-variables <Rutherther>the most idiomatic solution for supplying runtime dependencies like that is either replacing them with full paths or wrapping the binary when that's not feasible <Rutherther>if for some reason even that wasn't feasible, then you would have to start the service with proper environment yourself <Rutherther>propagated-inputs are better kept for packages where it's really a must. Otherwise they clobber user's profile and can easily cause conflicts <ieure>Yes, this is the correct way. <Rutherther>something like (substitute* "bin/mtag/audio-bpm.py" (("b"ffmpeg"") (string-append """ #$(this-package-input "ffmpeg") "/bin/ffmpeg""))) <ieure>yarl, Also FYI, the stuff in your `copyparty-shepherd-service' that's making directories and chowning them should really be in an activation-service-type extension, not the shepherd service. <Rutherther>argh the bridge I am using has removed the escape quotes <mrh57>Rutherther: okay good to know, I thought about substitute patching but was lazily hoping for an abstraction <Rutherther>patching is the cleanest solution. Wrapping with PATH is the lazy solution. <mrh57>ieure: yes I realized that after I wrote it lol, todo! <Rutherther>Wrapping means that processes started from it will also have that environment in their PATH, implying it 'leaks' it to other processes. This might not be problematic in this case, though. So it might be fine. I don't know what the application does <mrh57>Rutherther: where would that wrapping be done, in the service def? <mrh57>Rutherther: fyi it's a file server <Rutherther>look up 'wrap in the guix repository, there are plenty of phases with that name <mrh57>Rutherther: oh I see, good to know, I'll probably just do patching since that's the right thing I'd want to do eventually anyways <mrh57>Rutherther: and it works without ffmpeg so it's not a critical fix <Rutherther>or maybe better to look up "(wrap-program", because there are plenty of wrap phases that do not use it, but in your case it's going to be easiest <mrh57>actually I might try that first just to learn it for the future <avigatori>somehow emacs is an impenetrable brick wall to me even though it has all the documentation :s <emacsomancer>is ungoogled-chromium failing to build, or just stuck in the build queue still? <emacsomancer>(on the upside - this has finally prompted me to get offloading daemons working so my poor X200 doesn't try to build chromium) <untrusem>emacsomancer: you mean your other machines <emacsomancer>untrusem: yeah, having it build on a desktop that has standalone guix (on-foreign) on it <untrusem>I also need build daemons but don't have machines <emacsomancer>yeah, that can be an issue. there's ways round it - like using Nix's packages as stopgaps, but for this machine I'm avoiding doing anything like that. <avigatori>andreas-e: I would, but there is no way to quit it ;_; <andreas-e>Several failed dependencies on CI, which is weird - when I pretend to build locally, the inputs are there, probably from the bordeaux build farm. <andreas-e>avigatori: Easy as well, pull the electric plug and remove the battery. <emacsomancer>andreas-e: yeah - speech-dispatcher, pulseaudio, pipewire, qtbase <andreas-e>emacsomancer: All of them are available on bordeaux; it may be due to a problem with full disks on CI that was resolved only yesterday. <kat>following on from what andreas said: if you have an internal battery in your laptop, consider modding to add a switch to make it easier to exit vim :) <andreas-e>But I do not see the actual error message in the log. <untrusem> though i don't need to do it now as don't leave emacr <kat>a serious answer? oh god, oh god. <emacsomancer>andreas-e: well, the bordeaux build seems to fail at `[608/51672] CXX obj/third_party/protobuf/protoc_cpp/message.o <emacsomancer>ninja: build stopped: subcommand failed.` - and my local build has made it past that point at least. <andreas-e>emacsomancer: Often the error message in a parallel build appears quite a bit above the last printed line. Here I do not see any. <andreas-e>On CI, there seems to be a build failure in inkscape that propagates to lots of other packages. <emacsomancer>andreas-e: how can you tell the build failure in inkscape is propagating to other packages? <andreas-e>ungoogled-chromium mas marked as failed due to a dependency. Then I opened all the dependencies and clicked through to the root cause. <andreas-e>On bordeaux, the build may simply have been affected by a full disk as well; I will submit it again. <kat>i to do ZZ, when i want to exit vim i get into bed, put my head on the pillow and go ZZ <kat>do you tuck your machine in? :) <kat>why do you zzz -H instead of ZZZ <emacsomancer>andreas-e: oh, I see - seemingly affecting dblatex, and then gtk-doc <emacsomancer>untrusem: maybe - it depends (at least for this machine) on what i can get to build natively in guix <untrusem>or you can just use librewolf maintained by yours truly and ieure <emacsomancer>(which one can run on Guix via a distrobox, but I've idly wondered about try to port some of the patches) <untrusem>kat: it is a t480, I wonder why it doesn't work <bdunahu>to exit vim, why not just open it in emacs and use M-x kill-buffer? <andreas-e>avigatori: I now realise I misunderstood. I thought you had trouble quitting emacs so as to be able to start vi :) What put me off emacs was exactly that I did not manage to close it. <avigatori>andreas-e: ah. I was shooting for the old vim joke. I just close the emacs window X) <avigatori>I am trying to get geiser to work but it is stubborn <andreas-e>Which emacs window? Try the one from emacs-minimal :) <emacsomancer>untrusem: I shift back on forth on browsers; supposed to be some security advantages in chromium <emacsomancer>but firefox-based (incl. librewolf etc.) is more pleasant <andreas-e>emacsomancer: My local ungoogled-chromium fails with this error message: <andreas-e>cp: cannot stat 'default_for_rust_host_build_tools/obj/build/rust/std/libunicode_width.rlib': No such file or directory <untrusem>emacsomancer: try chawan, dillo and offpunk <emacsomancer>untrusem: ah, haven't tried chawan or offpunk before (or heard of them). dillo doesn't run under wayland, I think. <emacsomancer>untrusem: made a badwolf guix package and playing with that a bit <andreas-e>It also fails on bordeaux again. This is a genuine build failure. <avigatori>andreas-e: I have not acended to this higher plane of existence. I am stuck down here with the guis ;) <andreas-e>emacsomancer: Probably some change in rust. But I do not know how to find in the data service when a package stopped building. <untrusem>emacsomancer: dillo works in wayland or maybe its used xwayland-sattelite <gabber>is a GCD in the discussion period immutable? <avigatori>I think I created an invisible to me repository :o <avigatori>maybe I should have used the "all branches" option instead <emacsomancer>andreas-e: my local build failed too, but with seemingly different complaints <avigatori>is it normal that forking a repository takes 10+ minutes? <andreas-e>But much earlier than you, around file 1000. Maybe I am running out of memory there. <emacsomancer>[1047/51672] COPY default_for_rust_host_build_tools/obj/build/rust/std/libunicode_width.rlib default_for_rust_host_build_tools/prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunicode_width.rlib <emacsomancer>which seems to go through fine (assuming that's the thing that was missing in your log?) <emacsomancer>maybe that makes sense because the CI build referenced pipewire and pulseaudio related dependency failures <andreas-e>commit 63fbbd42dff2334dae62691bfc55f29bea0fa756 <andreas-e>And someone later added pipewire-minimal-1.4 to fix webrtc-for-telegram-desktop. <emacsomancer>and the errors I'm seeing are also to do with webrtc, yeah <andreas-e>So I will try to build it with pipewire-minimal-1.4, on a machine with fewer cores and more memory. A good task for the night, I can ZZ during that time :) <emacsomancer>so would this be adding pipewire-minimal or replacing the current pipewire dep? <futurile>gabber: No it's not; you can push out multiple revisions <futurile>gabber: this is to your question about GCD's during the discussion period <futurile>gabber: for the release one - to get the widest discussion I revised it - accepted changes / rewrote bits following feedback <futurile>gabber: then I sent a new revision with a summary to the mailing list - to make sure it was widely distributed <futurile>gabber: maybe you don't need to do that - summarising changes is probably useful for the mailing list <gabber>futurile: ok. so i guess i'll wait until somebody supports my GCD (hopefully in time), then yank out the current state and send it as the first non-draft revision through guix-devel <gabber>futurile: thanks for the clarification! <futurile>gabber: yeah I found the 'discuss' period being 7 days a bit odd - I actually accidently landed up discussing it for about 3 weeks - then I realised I was supposed to label it discuss heh heh <futurile>gabber: AFAIK simon (zimoun) is very interested in clarifying teams - you should email them and ask them if they are interested in sponsoring with you <gabber>futurile: i'm glad to hear we're not super strict with the 7 day period. 7 days seems *very* short for seriously drafting a GCD <gabber>thanks, i will! i sensed there were quite a few people interested in ratifying roles at Guix Days, but i understand not everybody feels like taking up even more work <gabber>that being said: what are the responsibilities of the sponsors? <valorzard>is this the right place to ask about guix bootstraping? <valorzard>so, i saw rust wants to improve their bootstrapping as part of google summer of code, and i was wondering if guix could help out <valorzard>(im not really associated with either project, im just curious since there seems to be a huge overlap here) <gabber>not an expert, but if rust were able to jump some versions in the bootstrapping process, that'd already be great (: <valorzard>i think mrustc is already on 1.90, which is really recent <valorzard>mrustc is the current way you can bootstrap rust, since its written in c++14 <gabber>AFAICT we do the bootstrapping, but currently (i think) we need to build every rust version with the one right before it. it would be cool if we could go from rust-1.0 to rust-1.x or rust-2 or whichever is the most modern in a single step <valorzard>ah gotcha, i feel like this is really a thing where the rust project and the guix project could collaborate, i just dont know how lol <ieure>gabber, I believe you're correct, the Guix Rust bootstrapping chain is to bootstrap OCaml, then build early Rust versions with that, then use those to build the later ones. <gabber>ekaitz: weren't you doing these things recently? or do i misremember? <ieure>gabber, I believe we /mostly/ bootstrap Rust N using Rust N-1, but strongly suspect we can eliminate some of those intermediate versions. <gabber>other bootstrapping wizards on our ends are (but are not limited to) ephraim and janneke <ekaitz>gabber: I built some package in riscv that built all the rusts and I complained about it in social media, but I don't know anything about rust and I don't want to <gabber>valorzard: i think if you have any contact information on the rust end you could email the Guix bootstrapping team by (sorry, i'm not proud of that hoop you might have to jump) using our etc/teams.scm script and use the headers to write an email <valorzard>this is the zulip chat thread for bootstrapping if you guys wanna jump in <ekaitz>also (warning: opinion) i don't think we are in the position to help rust people, they are way stronger as a project than we are, in terms of community size, money and all <valorzard>yeah for sure, i just think both projects are cool lol <ekaitz>(still opinion) it's them who should try to help packagers a little bit more <valorzard>i kinda wanna try applying that project, which is why i was asking since id wanna use guix as a basis <ekaitz>valorzard: try, we can still help you with the guix parte <gabber>ekaitz: this may be, but we are cooler <ekaitz>gabber: ofc, if we weren't I wouldn't be here, I just didn't say it because it was obvious to me :) <gabber>valorzard: like ekaitz says: we're happy to help you with this! <ekaitz>in any case, i wouldn't trust *any* community for anything <gabber>valorzard: if you want to really reach the right people you should consult help-guix or guix-devel mailing lists. this has more reach but is somewhat slower <avigatori>when codeberg tells you to "contact the administrator" does that mean I should open an issue or like email someone? <ekaitz>the amount of support a non-organized group of people can give anyone is pretty unpredictable <gabber>avigatori: administrator of what? codeberg? or the project? or the repository? <valorzard>okay i made a message on the zulip about this lol <avigatori>I get status 500 when I try to fork the guix repository