IRC channel logs
2026-02-18.log
back to list of logs
<mitchell>hello guix. I have a channel which has received some pull requests that I want to merge. How do I merge without screwing up guix authenticate? <mange>You'll need to sign the commits yourself as you push them. I think you can do that by just rebasing/cherry picking the changes onto your branch, then manually pushing and closing the PRs. <theruran>Can anyone confirm that Efraim Flashner controls this PGP key used to sign guix-system-install-1.5.0.x86_64-linux.iso? a28bf40c3e551372662D14f741aae7dcca3d8351 <vntsuyo>I've followed all instructions in the docs(#Contributing) and updated my keyring branch to upstream but no luck <mange>vntsuyo: Do you want to be authenticating that commit? I don't think you can authenticate a commit on your own fork, because you need an existing key in the repo to sign yours? (Unless you change the introduction commit or something.) <mange>I would think that you probably want to not have the hook (in .git/hooks/pre-push). From memory a bad hook can get installed by following the instructions in the manual. Let me find the thread about it... <vntsuyo>mange: thanks. i'll remove the pre-push hook for now <apteryx>looks like offloading is implemented as a hook, in build.cc; I was trying to see how I could pass user-provided options such as --max-silent-time to the remote daemon <efraim>it also honors GUIX_BUILD_OPTIONS which is something I use in vim-guix-vim <apteryx>uh, guix shell: error: package codeberg-cli@0.5.0 does not support powerpc64le-linux. Why not <apteryx>(trying to setup a 'guix shell' on power9) <apteryx>uh, rust is not available on powerpc64le: systems: x86_64-linux aarch64-linux <apteryx>I thought it was on every 64 bit systems <gabber>futurile: i have not. so it's not just me (: <gabber>guess i'll try the old pull&reconfigure&hope it solves itself <efraim>apteryx: I wasn't able to build rust-1.73 or rust-bootstrap-1.74 on ppc64le but after the rust-team merge I'll be able to work on the new rust-bootstrap-1.90 <apteryx>efraim: is d31b86a69835 a mistake? it's the one causing `rust` to be marked as powerpc64le incompatible <apteryx>i'd expect that arch to build it just fine, but I can check <efraim>apteryx: we could have removed support at 1.73 instead of at 1.55 but then we would've built almost 20 versions of rust for no particular use <apteryx>efraim: OK; just read you explicitly wrote you were not able to build it for ppc64le. I'm surprised but trust your findings :-) <gabber>i try to build PR locally but `./pre-inst-env guix build or-tools` gives: "error: <substitutable>: unbound variable". i've never seen this <futurile>janneke: when do you want to publish your blog post? I'm working on one to end the fundraising, making sure we don't clash ... <Kabouik>yqshao: turns out the snippet I tried yesterday to use greetd + tuigreet did not work, with a "guix system: error: service 'term-tty1' provided more than once" error. <efraim>do we have a function to take clang or llvm and return the llvm or clang variable of the same version? <sturm>gabber: did you have to do anything other than make to resolve that "unbound variable" issue? I'm still seeing that after `guix pull` and `make` <futurile>welp I think I've managed to find an area of 'Free' that's even less sustainable than 'Free Software' and that is 'Free Services', specifically video/peertube. Video transcoding/bandwidth is so expensive compared to the expectations users have <jlicht> sturm: `make clean-go`, followed by a `./bootstrap; ./configure; make -j$(nproc)` worked for my, YMMV <Kabouik>yqshao: I finally got it working but with https://0x0.st/PuK0.txt but there are a few culprits still to iron out: (1) GDM still launches (after tuigreet) and replaces it, and I have to specifically switch tty with Ctrl-Alt-Fx to go back to tty, and (2) when I log in using tuigreet and launch Sway, my .bashrc refuses to source while it does source just fine when I log in using GDM, and this cascades into other issues (like my Guix extra profiles not <Kabouik>I suspect it might be due to my Shell being Fish, and somehow GDM maybe still uses Bash while tuigreet might respect SHELL and use Fish, resulting in .bashrc not being sourced fine? I don't know. <Kabouik>Is that related efraim? I don't understand the patch. <efraim>apparently there's been some issues with fish as a login shell since the update to 4.3.3 <Kabouik>Somehow I had no issue so far with GDM at least, but logging in with greetd/tuigreet, I get issues. But now that I look more closely, I think my login shell still is Bash, because I have this at the end of my .bashrc: https://0x0.st/PuPQ.txt <yqshao>Kabouik: Glad that the services are sorted out at least (I did it quite differently basing on %base-services, but that should not affect much) <trev>old: i fail to do a guix pull for a few days now as well. did you resolve this? <futurile>andreas-e: oh that's probably a good option for us <old>trev: I removed guix-hpc <aaaavigatori>Rutherther I did some more investigating: I tried quitting "info" on TTY2 to get to a shell, because that was the only function one, however I did not succeed. The documentation was just restarted. <Rutherther>aaaavigatori: yes. It hard starts it. I mean you could make your own image as you suggested and just execute bash in one of the ttys. That should work if the issue is with the login itself, like if pam gets stuck <aaaavigatori>Rutherther however, I managed to "crash" it. On TTY12 I saw a confirmation, that the process term-tty2 was respawned until eventually I got the message that the process was disabled due to respawning too fast. After that point TTY2 also became unresponsive... However, after that I could log into the other TTYs and also get past the first dialogue <aaaavigatori>Rutherther I tried to recreate that behaviour but now there are no more hangs after rebooting. So my suspicion now is that maybe Windows does something to cause this. I am currently rebooting into it to test the theory. Sadly booting it takes 40min+ so it'll be a while X) <aaaavigatori>Rutherther if I manage to cause the problem again, are there logs etc. I should look at to find the cause? <aaaavigatori>Rutherther no clue. It's always been slow (though not that slow) <Rutherther>aaaavigatori: you can try /var/log/messages. But I am afraid hangs are usually not logged as it is behavior no one has handled properly <futurile>we should probably add logging to the installer and output it to a tty <aaaavigatori>Hmm, Windows fast boot is active as I suspected, but the installer issue is still absent. How very odd. <futurile>aaaavigatori: so the issue was something to do with the state that Windows left? What did you change to sort it out? <aaaavigatori>futurile that was my idea but I didn't change anything. It just works now. Which I find very odd. It works every time now. I also thought that maybe I gave everything more time to load properly but no matter how fast or slow I interact with the system now, it works every time. <yelninei>ACTION rebuilds commencement.scm again because they were to ambitious in reenabling tests <yqshao>Kabouik: I tried set it up as you but cannot reproduce the issue (I got fish with that bash snippet in a sway session as expected), guessing without confidence that is something with bash profile or sway config (my home is managed by guix home and they look like this: https://paste.debian.net/hidden/c1fdf937 ) <jab>hello, guix shell and guix shell --check is not work for me for this manifest file: (specifications->manifest (list "ikiwiki" "perl" "perl-search-xapian" "perl-text-markdown" "perl-yaml-syck" "texinfo")) <jab>I am getting an error that breezy cannot be built. <jab>I'm not sure why a python git alternative gets dragged into the build...but weird. Where should I report this bug ? <jab>bug-hurd@gnu.org ? or codeberg ? <jab>I'm trying to see if "guix build ikiwiki" works right now. <jab>yup, that looks like it. thanks! <jab>I wonder why breezy gets pulled in when building ikiwiki. weird. <yelninei>jab: ikiwiki has subversion git breezy cvs and mercurial as native-inputs this feel like a lot of VCSs, maybe for tests? <nomike>I'm trying to setup Guix on WSL2. I'created anm image with "guix system image gnu/system/images/wsl2.scm` and imported it into WSL. I'm able to open a sllin guix. But when I run `guix pull` for example, it is just stuck. I've waited for almost two hours and there was no output at all. <nomike>`guix searcg shadow` for example works. <nomike>Any idea how I can troubleshoot this? Normally I would use strace, but it's a fresh system, strace is not installed yet. <nomike>Well, actually I ran `guix pull --verbosity=3`, but there's still no output at all. <andreas-e>jab: If you have a local guix checkout, you can remove breezy from the native-inputs of ikiwiki and compile. Otherwise, maybe the time-machine will be useful. <rogerfarrell>Hi all, Could someone please point me in the right direction: My goal is to have a pinned channels module that can be updated automatically via guix time-machine -C unpinned.scm -- guix describe -f channels > lock.scm. I use my channels throughout my system and home configs, so I would rather have them in a module. I have a working test using (include "/absolute/path/to/unpinned.scm"), but I cannot figure out how generate the path in a <rogerfarrell>way that works at both compile time and run time (and reconfigure). <yelninei>janneke: There still seems to be an issue with raise (SIGABRT) / abort() at least thats what still fails in openssl <yelninei>but at least the issue with shell replacements is gone :) <yelninei>yes, with bootstrap files rebuild with the new mig. I'll try with the intr msg clobber patch for libc again and if that now works try the proper fix <janneke>yelninei: and the i586 bootstrap binaries can remain unchanged? <janneke>nice -- well, updating bootstrap binaries is never nice .. but still :) <janneke>for a new emerging architecture, which the 64-bit hurd is, it's okay i guess <rogerfarrell>Ah. Looks like I needed sleep. The answer was to get the filepath with search-path. <yelninei>i am just happy that guile -c '(raise SIGABRT)' triggers the bug and I dont have to go through commencement to test a change <dariqq>andreas-e: breezy is also used for bzr-download <andreas-e>dariqq: Hm, I always use "guix refresh -l" to check dependencies. Which is not enough! <andreas-e>In any case, I agree it would be nice if someone could update the breezy package. <trev>how many more days until module-import-compiled will compile on substitutes? rations are running low <ekaitz>efraim: about people complaining about the language being inclusive. This is something we should be smart about. There are ways to write nobody can complain to. That's the right spot <vagrantc>i need to use a combination of "guix refresh --list-dependent" and "guix build --dependents" (not the pluralized form in one but not the other!) because sometimes "guix build --dependents" tries to build packages for the wrong architecture and it is difficult to exclude them ... and "guix refresh --list-dependents" also has this problem, but it gives you a list of packages to build that you can manually <vagrantc>having a lot of heaadaches with that with the fuse updates i've been working on <vagrantc>i *thought* i could work around it with "guix build --dependents PACKAGE --derivations" but it seems to ignore the --derivations argument? <vagrantc>(i swear i actually did that in the past, maybe this is a new bug?) <dariqq>andreas-e: I can try to see if ifupdating solves the issue. <andreas-e>That would be nice, thanks! The package is a bit annoying as it combines Python and Rust. I suppose one needs to do a cargo dance as explained in the cookbook. <kestrelwx>nomike: is it stuck off the bat, or there's some output? <andreas-e>dariqq: That looks a bit old, we were above this version even before. <dariqq>oh yeah i just searched the release notes for dulwich <dariqq>hmm guix import crate modified some unrelated changes? <dariqq>andreas-e: breezy has dependencies dulwich==0.24.1 <andreas-e>Would it be possible to re-add the old dulwich for breezy, without creating profile conflicts due to propagation? <dariqq>this seems fixed in git version of breezy. <dariqq>andreas-e: There is a python-dulwich-0.24 and breezy does not propagate things <andreas-e>Interesting find! The 0.24 version is there and currently not used by anything. Then it should be easy to repair breezy. <dariqq>andreas-e: i'll look if some of the (ugly) test skips can be removed as well <andreas-e>relax-gcc-14-strictness would also be a candidate for removal in the case of an update. <dariqq>yeah that seems no longer neccessary. Also python-cython can be bumbed to the regular one <dariqq>Also tried updating python-patiencediff and python-fastbencode but there is more rust there. ypthon-merge3 does not rquire rust (yet) <dariqq>tests are still failing, still dont like that the testnames are so long <yelninei>janneke: intr-msg-clobber did not help. I guess we are missing another libc patch? <yelninei>i guess that might also resolve some of the other hangs <Kabouik>yqshao: I narrowed the issue down as greetd/tuigreet not using a login shell, and hence not sourcing my ~/.bash_profile (where my Guix env vars are set). Is ~/.bash_profile sourced in your case, and if so, is this something managed in your guix home (I am not using guix home)? <yelninei>thank god i remeberd youpi mentioning it some time ago in #hurd, i thoght i tried that back then <yelninei>janneke: Not sure if the mig change is still needed then? But if we dont break things now things will break with the next mig tag <janneke>yelninei: if changing mig now isn't necessary, or not actually helping anything, then i'd suggest postponing the change <janneke>possibly it can be postponed indefinitely <yelninei>Ill need to try if it also fixes the shell replacement issue <yelninei>janneke: It does not fix ncursesw-config <aaavigatori>I tried gnome first but now I am back on Plasma. Somehow Gnome crashed on me every 2min or so. Something that I need to investigate. I hope it doesn't also suddenly disappear >_< <identity>chances are, it will suddenly disappear after gnome-team merge <trev>no one else is having a guix pull problem lately? 😞 <yelninei>janneke: The tests in coreutils and diffutils that hung before now work as expected PASS/XFAIL <trev>aaavigatori: the classic `/gnu/store/rsc3pbj4hwdsbynbh2sf7arf7c7xi5qa-module-import-compiled.drv' failed` <janneke>yelninei: this is going to be a very noteworthy set of changes/fixes! <trev>i'm somehow in a state where i can't pull or reconfigure <trev>gabber: didn't try a time machine yet <trev>gotta find a good commit <gabber>just try `guix time-machine` and you'll know whether you *could* go to the most recent point in time <gabber>if that works you could `guix time-machine -- system reconfigure foo.scm` or similar <trev>ok let me do that, thanks <aaavigatori>Why is this "guix/build-system/gnu.scm:394:6: warning: importing module (ice-9 string-fun) from the host" worth a warning and what does it tell me? <andreas-e>But it should not be a problem for the last few days... As far as I can see, it is only the last commit. <andreas-e>Problem corrected, "guix pull" should work again (I have just tried it myself). <trev>i ended up pinning to an old commit <gabber>andreas-e: what was the problem? <andreas-e>A bad commit that apparently introduced a rust crate that does not exist, resulting in "unbound variable". <andreas-e>I have just reverted it and informed the author. <dgr>hi, how to do guix install linux-libre-headers@`uname -r | grep -oP '^\d*\.\d*'` in manifest.scm to get the right headers for the running kernel? <gabber>dgr: i think you'd have to look up the variable name and use that reference in the manifest <Kabouik>yqshao: some news. This 100% works for me (as in, everything works like it did with GDM, env correctly loaded): https://0x0.st/Pu1-.txt I did struggle a bit to get .bash_profile be sourced at all, but well, now it works. Interestingly, despite the `(delete gdm-service-type)`, I still have GDM on tty7. I'm not sure why, but I'm thinking I might keep it if it doesn't hurt, as a foolproof fallback in case I break things with greetd/tuigreet later. 