IRC channel logs
2024-12-02.log
back to list of logs
<apteryx>is anyone else having an issue with Magit when using git worktrees? <apteryx>in the COMMIT_MSG buffer, the current directory gets set to the .git of the worktree; breaks things like 'C' (GNU ChangeLog). I need to manually M-x cd to set it to the top worktree checkout... it's a pain. <lilyp>but… shouldn't you be maintaining the changelog of the worktree in the worktree? <jason>hello! I'm trying to use gnu artanis with guix shell but it needs a config file to go to /etc/artanis/artanis.conf (if you don't use the application layout yada yada). Is there something I can set up in a manifest to move a .conf file in my project folder to /etc/artanis/artanis.conf similar to something you'd do in a guix home configuration? <wakyct>maybe you could make use of --emulate-fhs? <wakyct>or sorry jason maybe I'm misunderstanding <jason>wakyct I could use --emulate-fhs + --expose=/etc/artanis/artanis.conf if I keep that file there outside of my project but ideally I could keep everything within the project folder <efraim>what about --expose=artanis.conf=/etc/artanis/artanis.conf, or does it need to be in a folder for expose to work <jason>efraim I think that's what I'm looking for, thanks! I didn't realize you could do it <sneek>bilke, gnucode says: I personally find it really easy to edit the Hurd wiki. I typically look through changes that I can make to the open issues pages. <sneek>bilke, gnucode says: or I grep through the irc logs to find cool tibbits to add to various pages. <civodul>bilke: hi! there’s ncnscd (?), which picnoir mentions in that thread <civodul>i believe it’s packaged in major distros like Fedora <bilke>Thanks I will try it (it's called nsncd). <civodul>cool; could you let us know how it goes and maybe propose a way to adjust the doc? <bilke>it seems to work! Thank you! I will submit some paragraph to doc page.. <civodul>78 x86_64-linux builds queued on ci.guix <efraim>i'm not convinced it's offloading evenly between 10.0.0.13 and 10.0.0.7 <csantosb>bilke: for the record, nsncd-git under Arch Linux <efraim>wow. ok, so even if it isn't it doesn't matter <efraim>i'll continue to not feel bad using berlin for testing ppc64le builds <efraim>civodul: can we cancel them all and then tell cuirass to resubmit all the aarch64 builds on master, and restart their failed/canceled dependencies? <civodul>efraim: i occasionally cancel more-than-N-month-old aarch64-linux builds (i added a protip to doc/cuirass.org in maintenance.git) <civodul>but the problem is that it’s just unable to keep up <efraim>perhaps if we had it build fewer aarch64 packages at a time? <civodul>well it’s stubbornly trying to build all the packages <efraim>I mean only offload 2 builds at a time to aarch64 machines <civodul>(which is why the percentage at qa.guix is always low: it shows the latest commit) <civodul>build machines are statically configured to run up to N builds in parallel <civodul>and they ask for new builds when a slot becomes available <civodul>then again Cuirass is doing a poor job when it comes to scheduling <civodul>so there’s a bit of wasted time due to that <civodul>i don’t think that alone explains the evergrowing aarch64 backlog tho <efraim>might be worth comparing what cbaines has with offload-in-build-order vs curiass's free-for-all <efraim>but I feel like if it successfully built it would eventually try to offer derivations which have already been built and turn those around quickly <efraim>and we never seem to actually hit that point with the aarch64 machines <Deltafire>funny how switching off a VPN in Gnome displays the notification "Activation of a network connection failed" <efraim>trying to build zig-0.10.0-675 for ppc64le, looks like the problem is zig vs llvm <rekado>civodul: oh, looking forward to the surprise reveal when 1.0.0 is out! <rekado>efraim: is the rust-team branch ready to be merged or are you still waiting for the build farm to finish building it? <csantosb>This is just me or it is not possible to replay by email to comments from codeberg ? <efraim>I was waiting on the build farm, but it's ready to be merged otherwise <efraim>ACTION goes out to pickup lunch, will be back soon <civodul>csantosb: good question, i don’t know! did you try fj.el BTW? <csantosb>civodul: not yet, worth it ? ... (email support under forgejo is wip apparently) <marmar>there seems to be some problem screensharing on plasma wayland with the error 'Failed to connect PipeWire context' <z572>marmar: maybe need home-pipewire-service-type. <jakef>congrats on merging rust-team, efraim! <jlicht>civodul: chapeau on the `--dependents` flag; You've made my day with it :) <civodul>meaning that these are not trivial updates, after all <rekado>python-redis fails to build. I wonder if that's because of the update to redis. <efraim>heh, there's already a new rust version released <janneke>and no single rust developer uses guix? <efraim>some people have tried to use rust on guix, but they've mostly just used the binaries from the compiler and crates from crates.io <rekado>ACTION fixed python-redis, tries to fix python-fakeredis next <apteryx>ah! I fixed it on python-team too I think, but not yet pushed for review: 0490a76804 * gnu: python-redis: Fix test suite <apteryx>anyway, good that you fixed it on master <rekado>locally, I upgraded to python-redis 5.2.0 <rekado>I'd rather keep it on 4.5.x for master <rekado>could you please apply this to master to fix the build? <rekado>I'd push my upgrade to python-team then. <apteryx>rekado: some building to do on master, but it'll be coming <apteryx>rekado: my change is not enough to resolve python-redis on master <apteryx>must be some of its deps that are outdated on master <efraim>were they failing before the redis update? <rekado>I got a user report about jupyterlab (from guix-science?) failing, and the cause is python-redis. <rekado>I haven't looked any further than that. <rekado>this makes it very likely that the upgrade of redis is to blame <rekado>a number of bioinfo packages are also affected <rekado>python-jupyterlab-server fails, too, which breaks multiuser setups of jupyter <rekado>the upgrade I prepared would necessitate yet other upgrades, and I don't have the time to assess the impact of upgrading these Python things <rekado>it's especially unpleasant to do this work in the knowledge of the existence of the perpetual python-team branch <rekado>ACTION fixed python-fakeredis, now tries to build python-jupyterlab-server <gabber>how can i find the guix checkout that builds a specific version of a package? <rekado>gabber: when you click on "Evaluation" it shows you which commit was used. <rekado>ACTION fixed python-jupyterlab-server <targetdisk>Does anyone know if the Thunderbolt 3 Alpine Ridge NHI (Native Host Interface) on my motherboard requires any blobs to run? <targetdisk>I just got a Dell 2-in-1 for a sweet deal ($80 USD) and am trying to dangle PCIe off of a Razer gfx enclosure I got at a swap meet on my linux-libre kernel <targetdisk>So far I don't see any devices at the other end in lspci :( <targetdisk>If no one knows, I will keep digging, was just curious if anyone knew <old>anyone know how -ffile-prefix-map can be used in a autotools project?? <nutcase>Hi. What should make my guix home shepherd service stop? It's surviving logouts and after re-login, my user has several instances of shepherd (not the pid=0 one). I don't have a display manager running, I'm using elogind. I don't know, how to debug that issue. <rho`n>hi nutcase, haven't run things from the home shepherd service. I did find two mentions of this issue <unmush>is there a reason that the gcc used for #:system "i686-linux" doesn't seem to support ubsan or asan? It complains during linking about a ton of undefined references <nutcase>rho`n: thanks, the issue seems to be related (and I haven't noticed that before) and the mail is written by myself :-) <rho`n>nutcase, lol, i thought one of those might be you <rho`n>It is a weird one. started reading the userguide, but nothing stuck out that might explain what is going on. <anemofilia>Just noticed I sent some messages in the wrong channel <anemofilia>I was investigating some strange behaviour of shepherd timers where a thunk with spawn-shell-command in its toplevel is blocking the shepherd process (and spawn-shell-command exists precisely to avoid that issue) <Rutherther>nutcase: it happens sometimes that guix home will start multiple instances. It should happen mostly on reconfigure. Or does it happen to you even after you kill those instances and just go about your day normally? <anemofilia>That made me think, is there any reason for make-timer-constructor don't, by-default, wrap thunk actions with some expression to make it suspendable? <anemofilia>When would one desire to have a timer action to block the whole shepherd process? <nutcase>Rutherther reconfigure isn't involved in my case. Stable Issue after reboot, login as user, logout, login as root, root sees user's shepherd. Now I observed: root isn't able to kill the user's shepherd (kill -9 works, of course) <nutcase>anemofilia: I have only mcron + syncthing as home shepherd services configured. I can kill both (but they are still running after logout and they need to be killed manually), shepherd also survives logout and lives without the user being logged in and without being killable by root <nutcase>I'm not sure, whether one of my home shepherd services involves spawn-shell-commands or make-timer-constructors <anemofilia>Ah, yeah, I know mcron, have used it for periodic gc for a long time <anemofilia>But I'm interested in test the shepherd 1.0.0rc2 features <civodul>if everything goes well, 1.0 is for next week <nutcase>anemofilia: I'm already on shepherd 0.10.99-tarball, which is 1.0.0rc2, no? <nutcase>another test i did: login as user, logout as user, login as user. I have two user's shepherd instances then. Killing the first user's shepherd instance fails. Killing the second user's shepherd instance succeeds. <janneke>794e079437c8687f49d294322dab3b7a8a6abacf is the first bad commit <civodul>i noticed that Home would somehow start a new user shepherd if i log out a log in again <janneke>gnu: rust-security-framework-2: Update to 2.11.1. <janneke>i guess we don't push anything until tests pass again? <janneke>civodul: tests/guix-build.sh fails for me on master <janneke>i tried to bisect (see above), but feels fishy because i fail to see how that commit could break this <nutcase>civodul: for me, a user's shepherd process becomes unkillable, once the user logs out. No other processes need to run to reproduce this. <janneke>ACTION had a free night to push some installer and hurd-team thingies ;) <janneke>now just been running tests, and wrote a patch for pipewire config :) <civodul>yeah, we should Do Something About It <civodul>there’s logic in Home to determine whether shepherd is already running <civodul>(get a seat in the Home team for free!) <nutcase>civodul: it's too late then. I tried: login as user, stop all herd services, logout. login as root, root fails to kill user's shepherd process, already ten <nutcase>the issue is not about the second shepherd started. The issue is already not being able to kill the first user's shepherd, after the user logged out <civodul>i’m not sure what you mean by “not being able to kill” <civodul>in my case, i can definitely kill it <civodul>it’s just that the Home stuff doesn’t realize it shouldn’t start a new one, in my view <nutcase>a normal "kill <pid of user's shepherd after user logged out>" fails. A "kill -9 <pid...>" succeeds, of course. It's not zombied, but blocked <nutcase>I'm using elogind, no clue, if that matters <civodul>if you look at shepherd.scm, it handle SIG{INT,HUP,TERM} in the same way <civodul>but maybe the process that starts your user shepherd masks signals or something? <nutcase>but SIGKILL does not need to be handled at all. <nutcase>SIGKILL kills my user's shepherd a normal SIGTERM does not <nutcase>before the user logs out, he (or root) can SIGTERM the user's shepherd. Once the user logged out, the user's shepherd starts ignoring SIGTERM <civodul>are you using ‘guix-home-service-type’ (on Guix System)? <civodul>so perhaps this has to do with how it’s started <nutcase>maybe. I can try to switch, however, creating a minimal home config is also done fast <nutcase>ACTION tries to figure out, how to wrap it into a "guix-home-service-type" into his "operating-system" <civodul>i have: (service guix-home-service-type `(("ludo" ,home-for-ludo))) <civodul>and ‘home-for-ludo’ is (home-environment …) <civodul>nutcase: i don’t know if it will fix the problem <civodul>all i’m saying is that it’s what i’m using :-) <nutcase>I have (use-modules (gnu home)) , but system reconfigure tells me "guix-home-service-type: unbound variable" <civodul>‘guix-home-service-type’ is defined in (gnu services guix) <civodul>it seems the doc is misleading or wrong <nutcase>civodul: I just now noticed, that I am still using 0.10.5 in ~/.guix-home/profile. Only my ~/.guix-profile uses 0.10.99-tarball, but that's not picked up, of course. I'll first try to make my system / home profile use 0.10.99 <nutcase>civodul: yes, I referred to the docs, therefore, I was wondering <vagrantc>is there a branch with libssh 0.11.x up somewhere? <vagrantc>guile-ssh 0.18.0 should build fine with that (at least, it fixed the build issue on debian) <nutcase>"hint: You cannot have two different versions or variants of `shepherd' in the same profile." :-$ <civodul>that breaks 3 of its direct dependents <anemofilia>Hm, I wonder how... Don't you have two instances of home-shepherd? I guess the error would be different in that case, though <vagrantc>civodul: well, that's clearly a successful build, but not sure where to find the updated package definition :) <vagrantc>civodul: e.g. i see no auto-update or security-updates branches <anemofilia>nutcase: The shepherd used by home is specified using home-shepherd-service-type, I guess that's what you want <vagrantc>avp: i am noticing a different hash for libssh 0.11.1 tarball than you have in guile-ssh's guix.scm <vagrantc>avp: nevermind, i was holding it wrong. : <nutcase>anemofilia: it's downloading texlivetexmf-20240312, takes a while <civodul>janneke: i see the tests/guix-build.sh failure, my brand new test already broken! :-) <vagrantc>civodul: are git patches a thing of the past too? :P <vagrantc>something i could git am on a local branch <vagrantc>civodul: basically, i am apparently still on the obsolete workflow of submitting patches to guix-patches :) <civodul>you can run “./pre-inst-env guix refresh -u libssh” and you’ll get the “patch” that’s used in that jobset <vagrantc>e.g. you mentioned updating libssh 0.11.x breaks guile-ssh ... so i want to test if updating guile-ssh fixes that ... this is all i am doing <civodul>yes, so you first need to upgrade libssh as shown above <vagrantc>how do i go about verifying the signatures on what that pulls in? <civodul>except when there’s no info on how to get signatures <vagrantc>i did not know guix refresh became signature aware ... how does it even know who is a valid signer for an arbitrary upstream project? <vagrantc>civodul: somehow i did not glean all this from reading that mailing list post :) <civodul>‘guix refresh’ has always been capable of checking signatures :-) <civodul>of course it doesn’t know who’s supposed to sign releases <vagrantc>well, there is at least one thing better on this alternate reality timeline... <civodul>so it just offers to download the key to a dedicated keyring if it’s missing <vagrantc>yeah, that seems like the hardest part :) <vagrantc>it's signed by evil malicious oliogarch, ship it! <civodul>so in practice, what ‘guix refresh -u’ does is TOFU <civodul>as in: you notice when the signing key changes <vagrantc>eesh. rust on arm64 again? *sigh* what pulled it in this time? <civodul>vagrantc: rust-team was just merged… <vagrantc>yeah, although i think something happened even before rust-team branch was merged <nutcase>civodul: anemofilia with shepherd@0.10.99-tarball started from guix home profile, I can kill (SIGTERM) the shepherd that keeps running after user's logout. That wasn't possible with 0.10.5. But it (0.10.99-tarball) is still running after logout and a second instance is started on next login and a third, etc.. I will try the "guix-home-service-type" in my "operating-system" tomorrow. <vagrantc>e.g. my previous configuration avoided rust entirely, but now it's back to haunt me <civodul>nutcase: ok, i’m observing the same thing <civodul>that it’s still running and a 2nd instance is started is a Home issue (not a Shepherd issue) <nutcase>and that's still the case with guix-home-service-type in system? <nutcase>It's kind of soothing, that I'm not the only person, affected by that <nutcase>ok, then I don't need to try guix-home-service-type, right? Expectation: no difference <civodul>i find it convenient, but that’s another story :-) <nutcase>however, let me know, if there is anything, that I could / should test. And thanks for your efforts! <vagrantc>hmmm... 18 revisions to bisect, .... bearable <ddaglenn>Hello, I have been using nixos for a year or two and recently discovered guix. I am interested in guix but want to make sure that it is a good fit for my needs. First, how is non-free software handled in guix? Is it possible to install within the guix software management or is completely separate from that? <Kolev>ddaglenn, yes you can get nonfree software on Guix System but it's off-topic here.