IRC channel logs
2026-08-19.log
back to list of logs
<graywolf>I think pull is broken. I wonder how this got through CI. <graywolf>apteryx: 6393e03a6e6a19593140f40bb2e51ddd7855d150 seems like a likely cause <apteryx>hm, I did run 'make as-derivation' to check <graywolf>But too late to bisect, just wanted to let people know before I go to sleep <apteryx>ok, yeah 'guix pull --url=$PWD --profile=/tmp/guix.master --no-channel-files --disable-authentication' reproduces, it seems to be with the guix-package-cache.drv <abrenon>hi! anyone else has trouble building wireshark or usrsctp (or I suppose any other package from networking.scm)? <abrenon>it's not even the build, guix crashes complaining about not being able to hide libcamera-minimal <abrenon>both my local copy of guix sources and my system-wide version are at cb704c4cab774dfd, it works perfectly from my local build but not from my regular install of guix <abrenon>so, in anycase, after 4557a3c which hid libcamera-minimal from linux.scm, keeping the deprecated leftover of libcamera-minimal in networking.scm <abrenon>anyone else has seen it and is opening an issue? <abrenon>(the one updating mangowm, which I don't care about but happens to be the latest change both when I guix pulled this morning and when I git pulled 10mn after that to see if I could replicate the issue — which I cannot) <untrusem>you should open a issue then, I am not updated with current situation. <abrenon>what I don't get is: the message reads like libcamera-minimal has been entirely removed and the #:hide thing now breaks everything, but the deprecated libcamera-minimal is still here <abrenon>I just wish I understood why it works from my local build from sources but not from my system-wide install of guix, when they're on the same commit exactly <untrusem>ask it in the issue as well, you might get an answer <adanska>man, gpg is broken with gpg-agent as of the recent crypto-team commits. I need to have gpg functional to do any programming work so I will just have to stay on an old commit while i wait for #10645 to get merged.. Really hoping it wont take another crypto-team cycle to get merged tho!! <untrusem>adanska, I have shifted to using sequoia a while back <adanska>thanks untrusem! Do I need to do anything special to get it working with home-gpg-agent-service-type? <untrusem>I don't use it but it provides a field for it <adanska>untrusem, no this wont work with git signing and the gpg-agent, sq doesnt provide a gpg-agent of its own and ssh and all the related machinery thereof still breaks :( <csantosb>adanska: what is your config ? guix system, foreign ? <csantosb>I have just updated to guix 549462d two guix installs on foreign systems, Alma (headless) and Arch (x11), both running `home-gpg-agent-service-type` <adanska>csantosb, guix system, config was on 3e478b7ec2d3d898e8c2a4c70637d71e8ee70b3f and i had to roll back after a reboot (presumably the new gpg binaries were loaded after the services were restarted) <csantosb>I think you also need an update to pinentry, see ca708296f3f, <csantosb>I'll upgrade my guix system this afternoon to see how it is going on a native guix install <adanska>csantosb, I'll give it a go with the pinentry updates :) <csantosb>This is just me or there is no `--supervised` flag on `gpg-agent 2.5.20` ? <csantosb>Asking because `herd status gpg-agent` returns "...imv-gnupg-2.5.20/bin/gpg-agent --supervised --enable-ssh-support" <csantosb>Ok, I see I'm not the only one to get crazy with this 🤓 ! <csantosb>`herd stop gpg-agent`, then manually run `gpg-agent --daemon --enable-ssh-support` and see what happens ! <cmack>csantosb: indeed, that did work for my git push use-case <vagrantc>ci no longer seems to be evaluating the kernel-updates branch ... <ieure>Might be the same, at least the symptoms sound similar. <ieure>But I think there are currently a lot of bugs that wedge Cuirass. <vagrantc>yeah, master hasn't had any evaluations either <jlicht>is qemu also failing for anyone else? <jlicht>JazzJackalope9: something ephemeral I guess, as a rebuild (to actually see the logs) seems to have succeeded this time :-) <Deltafire>tried to update an agit PR and accidentally created a new PR <perryprog>Yeah you gotta make sure you use the same topic <perryprog>and the PR with that topic can't be already merged or closed <perryprog>I do wish they went with the change-id method that gerrit uses but it isn't too bad <perryprog>the topic is either what you supplied with -o topic="foo-bar" or it's the end of the refspec like in git push origin HEAD:refs/for/some-branch/the-topic-name <perryprog>I mean, I'm not actually sure if spaces work or not <perryprog>oh, if you wanna be careful you can set the default refspec for the branch with git config branch.whatever-branch-your-work-is-on.merge refs/for/some-branch/the-topic-name <Deltafire>they're in there on codeberg, but i pulled the PR back onto another computer and it tried to create a branch containing the spaces, which didn't work <perryprog>in that it /should/ reject topics with spaces <Deltafire>so i just need to use -o topic="original topic with spaces" when I force-push the changes <perryprog>(Note: if you do the git config thing I mentioned you might need to set push.default to be upstream as well; I'm not entirely sure if that'll work with the simple push method) <Deltafire>i think i followed the agit guide, and it set the topic to the first line of the commit msg <Deltafire>i can't remember now, maybe i used the magit extension <perryprog>huh... -o topic="gnu: emacs-org-msg: Update to 4.0-1.7b45df7" doesn't work? <perryprog>oh, yeah, I wouldn't try spaces in the refspec <perryprog>so it'd be git push --force-with-lease HEAD:refs/for/master -o topic="gnu: emacs-org-msg: Update to 4.0-1.7b45df7" I think <Deltafire>i was trying with the magit interface, will try again from command line <Deltafire>done.. lessons learned for next time! thanks for the help <vagrantc>yay, looks like ci is evaluating things again <vagrantc>and... new round of upstream kernel updates, whee <perryprog>And in the rare case that an open source project does reach the point of "finished", there's sure to be a new project rewritten from scratch to take its place :P <Deltafire>surely they're never finished, but 'abandoned' <perryprog>True; I honestly can't think of a time off the top of my head that it was a project being declared "done" (and taking no more commits) rather than it being abandonware