IRC channel logs
2025-06-23.log
back to list of logs
<pinoaffe>futurile1: yup - I don't see much merit in collectively deciding "we should do yearly releases" when the last release was way more than a year ago and when there's no clarity as to how many people are motivated to work on a release - to me it seems like it'd make a whole lot more sense to streamline the release process, do a release, evaluate, and *then* consider if a regular release schedule with this process (or a slightly changed <pinoaffe>process) is feasible and if so, at which cadence, based on how the release team recruitment and the release itself went <podiki>i need to catch up on that gcd discussion. my broad thoughts are "release" should mean the installer and the guix package (for other distros), with related tags where substitute availability and general working of a system is good enough to then get to an up to date version <meaty>does shepherd handle autostart files? <podiki>the idea would be to replace an autostart file with a shepherd/home service <meaty>I asked about the autostart spec in my compositor's support chat and they said it's expected for the init system to handle them <meaty>and indeed it seems systemd does it? <meaty>which is news to me, I thought GDM etc. would be doing it if anything <meaty>podiki: yes, that's essentially what systemd does <podiki>DEs should handle it, for just bare WM that is up to you <podiki>i assume you mean things like programs with .desktop files in and xdg autostart directory? <podiki>though many WMs have a way to start programs on startup; i do that and in the past used that to call dex to get programs that provided an autostart file <meaty>hmm... wait, if GDM handles starting session .desktop files, but systemd handles autostarts, how does systemd start/stop the autostarts in concert with the wm process? and what should shepherd do <podiki>i could imagine a shepherd (home?) service that does the same thing of handling autostart files <podiki>sorry, don't know specifically about gdm/systemd <meaty>podiki: the thing is, how would that service know when the wm/compositor starts and stops? <podiki>one is a dependent on the other? <podiki>i don't know, just throwing an idea out there :-) <podiki>autostarts are annoyingly scattered in my experience, now i just have a few via home services and called directly from my WM config <meaty>podiki: yes, we would want to avoid running an autostart before a compositor starts or is ready <podiki>i think this gets rather specific for each wm/compositor unfortunately <meaty>or having services error out instead of exiting gracefully when the wm stops, or worse blocking the wm from closing <podiki>it is the freedom and difficulty when making your own DE essentially <viaken>It appears the GNU site is blocking my IP and I have no idea why. <viaken>Not a serious hindrance or anything, but puzzling. <kosto>Good morning. I have a couple of questions about mailing lists. I have done registration in help-guix (https://lists.gnu.org/mailman/listinfo/help-guix) and wrote my first email. But after that nothing. No feedback emails, no new messages in the archives. What am I doing wrong? <kosto>Or I wrote at the wrong time (early/late)? <z572``>kosto: maybe is plasma packageing issue, please open a issue on the codeberg. <mange>Your first message to the list will have to be approved by a moderator, I believe. <z572``>I haven't tested starting with gdm. Maybe some of the required qml dependencies are passed to the environment by sddm, which might be a problem. <untrusem>I fix that everytime by running guix gc but this time it is not working <untrusem>I did the last step > switched to previous gen > remove broken gen > guix gc > guix system reconfigure <kosto>z572`` how can I setup sddm instead gdm right? <untrusem>I tried rebooting and yes all the deleted generations are still present in grub, something is faulty in grub <untrusem>I ran guix repair but it could fix the broken derivation, how to debug this then <civodul>jakef: oh yes, it’s the same thing! apologies for not noticing earlier <civodul>do you know if the bug is in the source? <jakef>i haven't had a chance to investigate sorry <jakef>i've just been using hdf5-1.10 in the meantime, which is before they moved to cmake IIUC <janneke>hmm, how do i push a fix to codeberg? i'm suddenly(?) getting <janneke>remote: Forgejo: branch master is protected from unverified commit b198616c44b53b9975755080d96e53dc27a974af <efraim>are you sure that commit is already on codeberg? <janneke>efraim: nope, trying to push it there <efraim>ah, I thought you meant there was an unsigned commit <efraim>are you sure your commit is signed? :P <janneke>gpg: Good signature from "Jan (janneke) Nieuwenhuizen <janneke@gnu.org>" [unknown] <efraim>sounds like you need to sign your own key <janneke>gpg doesn't know my own key anymore? <efraim>I think I have to do it on each new computer and when extending the expiration date on the key <janneke>hmm, i did no such thing...but on another computer my key is still valid <janneke>ACTION goes to look further...thanks <ennoausberlin>Hello I yesterday asked about ssh urls in package definitions inside private channels. There was a problem with missing host keys (probably due to sandboxed build environment) Got no answer here, but found a workaround by using git-checkout instead of git-fetch. This works for now, but I would like to see a solution for git-fetch as well. Any <janneke>gpg: Good signature from "Jan (janneke) Nieuwenhuizen <janneke@gnu.org>" [full] <janneke>but still the unverified message; istm i cannot push to master anymore <efraim>is the keyring branch checked out? <efraim>did you sign it with the right key? <efraim>is it multiple commits and they're all signed? <ekaitz>janneke: vagrantc had the same problem not that long ago <ekaitz>and civodul opened an issue in codeberg because of it if I'm not mistaken <janneke>ACTION is pretty sure they already pushed to codeberg...but that might have been to core-packages-team <ekaitz>oh janneke might be because of branch permissions? <jlicht>should I not push to master? I was about to :O <janneke>ekaitz: yes, trying to push a master <civodul>janneke: is it your first push to Codeberg? <janneke>jlicht: you can push afaic, i've got just one mingw build fix commit, i can rebase :) <janneke>civodul: i've pushed to core-packages-team, but not to master yet, i believe <jlicht>if a contributor adds their copyright to all files that are touched in a commit, but they happen to make a mechanical change (1/2 lines) to one particular file that they havent touched before, should I remove the copyright line addition for that file, or not? <yelninei>janneke: did you associate your public key with your codeberg account <efraim>the FSF says the Magic Number™ of lines for a copyright is 15, but we're not particular about the minimum. I don't normally add it (for myself or others) if it's pretty much a whitespace adjustment. <janneke>yelninei: i've pushed to core-packages-team... <janneke>do i need to add my gpg key there too? <civodul>janneke: yes, you need to add your gpg key on Codeberg <janneke>ACTION pushes libxcrypt mingw cross build fix (again--why daes that keep breaking? ;) <janneke>yeah! thanks to all who helped thinking along <ieure>How long should I expect to wait for CI to build stuff? I set it up to build the librewolf-updates branch so there are substitutes when my PR merges, but after 18 hours, the builds are still "scheduled." https://ci.guix.gnu.org/eval/2066059 <apoorv569>If I add multiple machine records to the list for guix deploy I get error about unbound variable for some opearting-system config I specify. Each operating-system config works if I only have a machine record for that specific config in the list only.. but when I add more I get the error.. what could be causing this? <janneke>huh, /me ^C's a --keep-failed build, and /tmp/guix-build-package is owned by root? <civodul>(unless you’re running the rootless daemon) <charlesroelli-al>> <ruther> are there any automatic ways for checking if source contains any binary blobs? <janneke>Generation 36 Jun 12 2025 19:35:32 (current) <janneke> commit: 6719e395128c61626125e4baf654f45f56b33c77 <janneke>ACTION has a really awesome day today :-/ <z572>civodul: Could you review the pr I sent to core-packages-team? <ruther>janneke: in case like this probably the guix-daemon's version is more important than your user's guix describe <janneke>oops, system describe is more interesting: 799d930bf740a66792240eb27d98823f041b1335 <ruther>janneke: even system describe doesn't uniquely determine the guix-daemon version. You could've changed the guix service type to refer to a different guix than the guix package in the guix channel <janneke>ruther: right, herd status guix-daemon gives: /gnu/store/9skc0cncscmbqy891s73sicbvh1yfhxq-guix-1.4.0-37.096dedd/bin/guix-daemon <janneke>(but that's probably harder to relate back to git?) <ruther>janneke: just --version on that guix-daemon <ruther>and no, it's not hard as it's part of the version - 096dedd <janneke>hmm, for libxcrypt the post mortem build directory is owned by root, but for guile-gcrypt it nicely owned by myself <civodul>are you using the unprivileged daemon? <janneke>civodul: yes, i've made no changes; doing nothing special <kosto>Does help-guix mailing list work? I've sent two emails on `help-guix@gnu.org` and didn't get feedback <janneke>./pre-inst-env guix build libxcrypt --with-configure-flag=libxcrypt=foo=bar --keep-failed <janneke>and hit ^C during build/make, when doing it during configure'ing, all is fine <untrusem>I have hit the guix reconfiguring issue due to unclean shutdown <janneke>it also works for "hello" -- but you have to be quick :) <untrusem>guix system: error: error parsing derivation `/gnu/store/bkriy4pzgv9pgbn2m80d3nzllhas8vyj-grub-efi-2.12.drv': expected string `Derive([' <ruther>untrusem: you need to get rid of that derivation <untrusem>I tried with guix gc --delete but it say it is still alive <ruther>untrusem: so you need to make it not alive... there is no way around that, you need to delete it to proceed... <untrusem>guix gc: error: cannot delete path `/gnu/store/bkriy4pzgv9pgbn2m80d3nzllhas8vyj-grub-efi-2.12.drv' since it is still alive <ruther>untrusem: there are couple of options. A generic way is to 1. switch to generation that didn't have any issues, 2. remove the affected generation(s) with guix package / manually in /var/guix/per-user/system-X-link, 3. guix gc the whole store <untrusem>actually that's what I have been doing all day <ruther>if you do not want to gc the whole store, you need to find out what's keeping it alive, you check the --references with guix gc on this path. Also check if the output of the derivation exists (it probably does), and if it does, you need to either get rid of the output, or start guix daemon with --gc-keep-derivations=no <ruther>untrusem: you must've missed an affected generation then, otherwise it would get gc'd away <untrusem>ohh there are two of refferers and refferences <ruther>untrusem: I am sorry I meant referrers, not references <ruther>the references are not relevant here <ruther>untrusem: so you do not want to gc the whole store, is that so? <ruther>ie. don't want to lose some old shells <ruther>so if you did, what's there to lose? <untrusem>I would like to not dowload things for 40mins this time if I can <ruther>untrusem: okay, in that case you need to look through the referrers to the leaves of the tree and start removing those first, ie. you run --referrers on the grub-efi, that shows two entries, so you run --referrers on those and so on, until you reach one that doesn't print anything <untrusem>btw how does guix gc affects shells?, because at one time fish was throwing some gibberish after guix gc <untrusem>ok both of refferers of guix-efi point to the same drv <untrusem>`/gnu/store/r642y13yyp65b3h8qjayqkndg3sssk2dz-grub.cfg.drv` <untrusem>and this one doesn't print anything, nice <untrusem>weird, guix gc referrers on grub.cfs doesn't print anything but if I try to delete it, it throws the same `is alive` error <ruther>untrusem: probably the output exists and is alive, you need to either get rid of the output, or start guix-daemon with --gc-keep-derivations=no <jlicht>I'm seeing some issues /w contributing.texi containing invalid syntax <untrusem>but it ain't printing anything, so I don't what to get rid of <ruther>untrusem: the output of it... ie. what it guix build's <ruther>untrusem: either guix build it or look in the drv file for the output <ruther>I guess it's in the database then <ruther>anyway probably easier to just start daemon with the gc keep derivations no <untrusem>ok, kill current one, and start with `sudo guix-daemon --gc-keep-derivations=no`? <ruther>untrusem: definitely do not use kill, shepherd will restart it, use herd to stop it <ruther>untrusem: and if you start it just with that switch, do not build anything with that daemon, just the gc. Then start the original one <ruther>and optionally you can add --debug option as that will give you more information on why guix gc -D isn't working <untrusem>ok `sudo herd stop guix-daemon` > start the new guix-daemon in cli `sudo guix-daemon --gc-keep-derivations=no --debug` > do the guix gc i.e `guix gc --delete <files>` > start the original daemon with `sudo herd start guix-daemon` <ruther>sure, but you don't need to do the last step until you're done with all the gcs <ruther>just do not run guix build, reconfigure etc with this daemon <untrusem>yep, should I just run `guix gc` to make things easier, guess will need to give download time then <robin>when updating a PR on codeberg, is there a preference for creating new commits or amending commits in the relevant branch? (if it's the sort of change that would be an amended commit locally) <ruther>if you're going to do that, don't forget to check with verify contents to see if there really are no more gc rooted paths that would be damaged <untrusem>warning: daemon is running as root, so using `--build-users-group' is highly recommended <untrusem>no option now, I should run `sudo guix gc --verify='contents'`? <untrusem>do I need to change to a previous generation to do this, the generation I am on is the working one <kkremitzki>Hello all, I recently figured out how to get libvirt's `virsh console` working with a Guix System VM, and I was thinking of submitting this to the cookbook, but it would be quite small, probably one paragraph and one code snippet, thoughts? Should I just go ahead and write that up? <identity>robin: amend it unless it is a separate change (i.e. avoid separate fixup commits) <untrusem>sure kkremitzki, its a contribution in the end <identity>kkremitzki: most things in the cookbook are like that <ruther>untrusem: that warning about running as root is why I advised you to not build with that guix-daemon <untrusem>the manual way was throwing some error, send in the paste above, so I am doing `guix gc --verify="contents" now <ruther>untrusem: I don't know what you mean by 'generation I am on is the working one'. The important thing is if affected drvs are gc rooted by it or not. If they are, you need to get rid of those generations, so yes, switch to one that doesn't have those issues <untrusem>ohh I mean to say, the generation I am currently on is working one, i.e I switched to it and deleted the faulty one and currently doing all these steps <untrusem>guix gc finished, I started the original guix-daemon <ruther>untrusem: so verify printed no errors? <untrusem>1 - ran `sudo guix gc --verify="contents"`, it resulted in no errors <untrusem>3 - ran `guix gc --verify="contents"`, it resulted in no errors, same as 1 <untrusem>4 - ran `guix system vm`, which I stopped in middle <ruther>untrusem: that doesn't make sense to me, `guix gc` shouldn't throw errors, ever <ieure>untrusem, Your paste link 404s. <ieure>Presumably `guix gc' did not produce a 404 :) <untrusem>can't create paste, 413 Request Entity Too Large <untrusem>which pastebin supports over 291k lines, lol <untrusem>sending to 0x0.st, its 32mb file lets see <untrusem>I would recommend to open that file in emacs, I have added pointers to make search a tiny bit easy <janneke>sneek: later tell civodul: ah, to run with the new non-privileged guix-daemon i would need to add (privileged? #f); i haven't done that and so my guix-daemon still runs as root <pastor>Hello. Does anyone know if there is a near future where we will have a way of packaging python programs in a more automated way, as we do with rust now? <ruther>pastor: what does that mean? guix import already supports pypi <pastor>I've been trying to package `aider' the last few days. But I'm too deep in dependency hell so I'm going to give up <ruther>pastor: right, but what does that have to do with rust? <pastor>Rust now reads the lock files, and solves the dependency generation for you, no? <ruther>pastor: there is no way the python packaging would work the same way as rust's... rust has the crates statically built into the binaries, while python needs all the dependencies loaded, so you cannot isolate versions for packaging individual software <pastor>I'm having many issues related to mismaching dependencies due to propagated inputs not being compatible <ruther>the only way would be to make a complete environment for running some packages, but that is not going to be something used for guix packages as it would introduce incompatibilities when you load different packages <pastor>ruther: and since people have this bad habit of setting hard dependencies with `==` instead of `>=` I'm really suck <vagrantc>guix does have a good workaround for that, no <pastor>please, could someone take a look at the package situation to recomend me if I should just give up? <vagrantc>kind of a fundamental incompatibility, and propagated-inputs is the best compromise in the guix environment <vagrantc>but propagated-inputs results in such incompatibilities with multiple incompatible versions <pastor>vagrantc: I know. But I really don't see a way out of it :( <vagrantc>basically, you have to tweak all the packages in the dependency chain <pastor>vagrantc: that's what I'm doing. But the chain is getting too massive for a single person <pastor>There are two relevant files `pastor/packages/aider.scm' and `pastor/packages/aider-deps.scm'. <ruther>As an alternative a tool could be made for making individual environments, like what someone has done with nix https://github.com/nix-community/poetry2nix, but it is not something concievable for guix channel itself I am afraid... as users wouldn't be able to just guix shell python-a python-b python-c etc. and *just work*, because they can face incompatibilities <pastor>As you can see I'm doing a lot of dependency tweaking, but I've reached a point that other dependencies restrict the dependencies to a point that they are incompatible <ruther>but I don't think anyone has done this for guix yet, or at least I cannot find it <pastor>ruther: ah, yes. One of the many tools of the nix project, I'm not familiar with it but it seems restricted to poetry projects <ruther>pastor: yes it is, because it uses a lock file, and python doesn't have lock files out of poetry <pastor>ruther: please, could you take a peak at the link I sent, specially the `relax-requirements' phase, and tell me if this is a lost cause? <pastor>I see, sad, another language to the list of hell <vagrantc>it seems to be the fad of language-specific package managers as of the last coupel decades... <ruther>pastor: I am sorry, I cannot really tell you if that is lost cause... maybe yes, maybe not, hard to say, I see some major version changes, those are kind of red flags, I would expect some breakage that might or might not be visible during normal usage <ruther>pastor: really the easiest way would be just to update the dependencies <redacted>Were there recent changes to desktop services? org.freedesktop.secrets is no longer available on dbus. <redacted>I'm using %desktop-services with none of the DE services (gnome-desktop-service-type et al) <redacted>Some chat apps are complaining that there's no secrets service, and I don't see a secrets service when querying the available dbus apis with dbus-send <ieure>No idea what that is. Element Desktop is Free Software, just difficult to bootstrap from source, is why it's only available from unofficial sources. <ieure>I have the same issue, org.gnome.keychain is present in my session dbus services, which I'd think would suffice. <luca>vagrantc: In particular any programming language you think has dependency management done "right"? <redacted>nheko is a C++ client for Matrix. I tested nheko just in case it was an Electron bug <ruther>redacted: so you've used nheko before, and it was working? <redacted>ruther: Good question. I can't remember clearly. <ruther>redacted: because from the info you gave here it seems you never did have secrets d-bus service <ruther>redacted: note that %desktop-services definitely didn't contain any in the last few months at least, and I doubt it ever did <redacted>I guess the real mystery to me is why element-desktop ever worked, then. <ruther>redacted: well it's just that the latest version of element started requiring secrets service <redacted>Oh! Thanks. I've been making incorrect assumptions. <untrusem>hey ruther did you had the time to look at the guix gc logs <ruther>untrusem: yes, and as can be seen in the log, you still have errors in guix gc --verify=contents <ruther>ie. for grub-efi builder, grub-keymap.us, grub-locales-builder and probably more <vagrantc>luca: the difficulty is striking the balance between "making project X work" (e.g. developer focused) and "making projects X, Y and Z work together" (e.g. distribution focused) ... most focus on the former, while most package collections focus on the latter ... they are largely at odds with each other, and there is no right way, although i'm biased towards the distro-focused approach <ruther>you need to get rid of them first and only then expect things to work... why are you still ignoring the log? I really don't understand that... <pastor>ruther: I see. Sadly updating the dependencies is quite an endeavour. Many I update. But some are quite difficult to package. <ruther>untrusem: note that it's probably better to not run the whole guix gc and verify with the debug option. I mentioned it only for the individual deletion with -D <untrusem>my bad, I should have looked properly in the los <untrusem>what steps should I take from this point on? <ruther>untrusem: since you still have those files after running `guix gc` it means you still have the generation(s) that keep those files in the store <ruther>so you need to idenfity what generations those are and remove them <ruther>or you could also just get rid of multiple recent generations, since those are likely the ones affected, while older aren't going to be, that way you don't have to look into what generations are affected specifically <ruther>untrusem: also... after you removed the latest generation, did you run guix system switch-generation? <untrusem>So I had 11 generations and this array started showing about 11th, I currently am on 7th, I deleted the other generations with your suggestion in the issue, https://codeberg.org/guix/guix/issues/111, but if I boot into the machine, the grub show all the generations, that is 11 to 1 <untrusem>ruther: I first switch to generation 7 and deleted the corrupted generation. <ruther>untrusem: yes, that is normal, run guix system switch-generation to rebuild the bootloader <untrusem>you mean run this command in current generation i.e 7? <ruther>yes, switch to any generation, and then back if you want to be on 7 <ruther>that will fix the bootloader. And possibly also the gc roots <untrusem>I see, will switch to 6 and then back to seven <untrusem>ohh I can't use the switch-generation command <untrusem>it throws the same `expected string derive´ error <untrusem>guess will need to use `guix package -p` as you mentioned in the issue <untrusem>I used the same command to switch to generation 7 <ruther>no, do not use guix package... use guix system switch-generation <ruther>if it doesn't work, then you're stuck and need to resolve it first, and only then switch the generations <ruther>switching with guix package is not going to fix anything <untrusem>guix system: error: error parsing derivation `/gnu/store/a86phw0svkq54fcn1i7wvyfy41rg57b7-grub-locales.drv': expected string `Derive([' <untrusem>ruther, I have been switching generation with guix package this whole time, that's why It didnt't work then <ruther>I think the easiest is going to be to use older guix generation of your user to do the switch <untrusem>you mean? time-machine or pinning, cause I don't know both <ruther>neither, just run guix from older generation under /var/guix/profiles/per-user/$USER/current-guix-X-link <untrusem>user in this is root or current user i.e `untrusem`? <ruther>it's the user you pull with, so probably untrusem <ruther>or... maybe a better idea... use /run/current-system/profile/bin/guix <ruther>untrusem: so you're running system switch-generation with that? <untrusem>why does it make system-7-link the current system? <ruther>untrusem: I don't know, maybe just a bug in the logging <ruther>untrusem: so did it finish without errors including the bootloader? That is missing in the log it seems to me <untrusem>it has downloaded grub, it is in the logs <ruther>untrusem: right, but I don't see it saying it is installing the bootloader <untrusem>ohh yes, I do see `building /gnu/store/cdn06ssf2q43fb5xzvlsjiib9hi4b6ca-install-bootloader.scm.drv...` <ruther>untrusem: yes, and then this built file needs to be executed. I am not sure why it's not in the log, but I presume it has been executed <ruther>untrusem: so right now your grub isn't pointing to the corrupted files anymore, so you might be able to guix gc to remove the corrupted files <untrusem>does running guix gc with sudo does something different? <ruther>untrusem: guix gc without arguments no, it would be relevant only if you ran something like --delete-generations <untrusem>guix gc: error: cannot unlink `/gnu/store/trash/drdhmyipl8p60c7lf1g15dvhpgiwb4yn-python-pyqt-5.15.10/lib/python3.11/site-packages/PyQt5/bindings/QtNetwork/qssldiffiehellmanparameters.sip': No such file or directory <untrusem>guix gc: error: cannot unlink `/gnu/store/trash/drdhmyipl8p60c7lf1g15dvhpgiwb4yn-python-pyqt-5.15.10/lib/python3.11/site-packages/PyQt5/bindings/QtNetwork/qssldiffiehellmanparameters.sip': No such file or directory <ruther>untrusem: that seems strange, maybe rerunning it will help <untrusem>atleast its not grub, I installed some python stuff with guix in the genration, maybe its related to that <ruther>it sort of seems to me you have the database corrupted, not sure why else this would happen <ruther>probably won't be resolved without a reboot (and it's possible you won't be able to boot if it really is in too of a wrong state) <untrusem>I don't wanna reboot, I will just keep it on suspend. <ruther>untrusem: since you cannot execute commands I don't know how you would switch generations <ruther>and I don't know how that would help <ruther>as I said, I don't know about any options other than rebooting and seeing what will happen. If you won't boot, you will have to boot live iso and reinit your system. If you will boot, you can continue where you left of <untrusem`>just to confirm, I could also reconfigure from this generation right, or could switch to 7 and reconfigure from there, I will do this later <ruther>you can do either, but by switching only (with the user's guix instance, not with the /run/current-system...), you will confirm the files are removed more quickly as you won't have to download everything needed for a full reconfigure <ruther>another option to confirm that is the guix gc verify contents <ruther>if you verify it, it doesn't matter at all if you first switch and then reconfigure or the other way round <untrusem`>its stuck on `checking hashes..` for over 10 mins, I am letting it be <podiki>heads up for anyone committing: it would be great to keep things quiet on the 24th 14h UTC +/- 1 hour; or even better from about 05h UTC <podiki>(just to make it a bit quicker to deploy fixes) <ieure>It's probably just a silly ol local priv escalation. <podiki>that or some sort of "write to memory you aren't supposed to"/"not sanitizing something" 