IRC channel logs
2023-11-29.log
back to list of logs
<zilti>I am trying to add `(service home-shepherd-service-type)` to my Home config, but when I then run `guix home reconfigure`, I get file or directory not found for `/run/user/1000/shepherd`, did I forget something? <peanuts>"yuvallangerontheroad/guile-clipboard-speaker: [mirror] Accessibility tool that reads the contents of your clipboard buffer. Meant to be run with keybindings / shortcuts. <Guest77>Just tried installing 1.40.0 from the .iso file, installation appeared to go ok, but on reboot, got an ERROR pty failed to exec child - in src/pty.c at line 299 <Guest77>and it looks like an infinite loop. Does anyone have any ideas? <lechner>Guest77 / not sure; did you run guix pull and reconfigure before rebooting? <Guest77>no. there was no way to do that, anyway, I used the graphical method instead of the shell. But I powered the system down, went and made a Debian iso, stuck that in and rebooted - and got a working GUIX desktop, go figure... Is there any documentation for GUIX or is it just guesswork? <Guest77>got the answer for the question above... <cmack>There is a patch series on guix-patches that I'm interested in evaluating however I'm seeing a "error: could not build fake ancestor" message when using git am (via magit). I'm a bit new to git patches via email, but is this error a sign my MUA is having a problem or is it likely the patch series needs work? (For example, I don't see a base commit id on the 0th PATCH email... <isaneran>something up with the substitute servers? or is it just that releases of ungoogled chromium and qt take ages to compile haha <zilti>qt does take ages to compile, it is a massive and complex beast <isaneran>zilti: yeah I suspected it might be that <isaneran>I wonder what I have that even depends on qt <zilti>I am trying to add `(service home-shepherd-service-type)` to my Home config, but when I then run `guix home reconfigure`, I get file or directory not found for `/run/user/1000/shepherd`, did I forget something? <sarg>hey guix, my root shepherd misbehaves - it doesn't react to herd commands and inetd feature doesn't work. I have enabled repl-service, but can't connect to it either. I've managed to start sshd on custom port and have access to the machine, though not sure what debug options I have. Any ideas? Maybe I can gdb in the process? <isaneran>are you using sudo for the herd command? <sarg>I also see some zombie processes where parent pid is 1 <efraim>sarg: check sudo top and see if PID1 is using 100% CPU <efraim>sarg: also what kernel version and what architecture? <sarg>yes, 100%. x86_64, libre 6.5.12 <efraim>I just had that issue with a riscv64 box running Linux-Libre-Riscv64-Generic 6.5.11, I'd suggest booting into an earlier generation <sarg>and who will figure out what's the issue then? :) <efraim>I can say I don't think I had that problem with 6.5.11 or 6.5.12 on my x86_64 box, but I don't normally ssh into it <efraim>you're welcome to try and figure it out :) my riscv64 box is too slow for me to try to debug on <sarg>I have a service to mount an USB disk. When the disk is turned off the service should just fail after 20 seconds of waiting. According to dmesg it didn't happen <sarg>and this issue is not permanent, most of the times the machine boots just fine <efraim>does the drive show up in df -h? <sarg>oooh, I have a very wild guess. So the machine is a semi-broken laptop which I try to repurpose as a headless server. One of the failing things is the RTC clock battery. When I do a cold boot, the RTC clock has unix time 0. While shepherd waits for the disk device to appear, ntp starts and synchronises the time <sarg>it looks like it messes up shepherd's internals and it is stuck in a very long sleep <efraim>I feel like you've described most of my SBCs, except sometimes its 2016 and sometimes its 1970 <sarg>hmm, how does `sleep` work in guile? Does it use system clock or some monotonic counter? <efraim>why not move the 2tb disk to file-systems, mark it as not-required-for-boot? <efraim>looks like system clock and then aims for "close enough" <efraim>I didn't realize needed-for-boot? was #f by default <sarg>when I put it to file-systems it becomes required for `file-systems` service. It then stops the server when I unmount using `herd stop file-systems-/media/2tb` <efraim>you should be able to just use `umount /media/2tb`, but I don't think I've tested that with an external drive before <efraim>maybe mount? #f would fix that, but I don't have another idea in that direction <sarg>but I want jellyfin to stop as well, that's why using herd for unmounint <efraim>was there a previous generation that Just Worked™? <efraim>(and when was it from? trying to narrow down changes in Guix) <sarg>not really, the setup has not stabilised yet <efraim>I'll continue thinking about it, but no ideas yet <sarg>I'll experiment by removing ntp from the equation <sarg>guile does `select` with a timeout for `sleep`. And `select` is using CLOCK_REALTIME as the time source <sarg>ok, confirmed. Shepherd hangs when system clock jumps forward due to ntp synchronisation <Guest14>Can someone sent me an example wpa configuration. <sarg>efraim, can you test it on your guix: `sudo date --set yesterday` followed by `sudo herd status`. It should hang. When you restore the date it gets back to normal <sarg>though you might want to use network manager or something similar <civodul>janneke, cbaines: hey! by combining your patches, i have something that appears to fix the loop plus locales for the Hurd <civodul>i need to clean up and test some more <zilti>Uh oh, even more, Guix says that $XDG_RUNTIME_DIR does not exist. I have no idea why that's the case. I used the TUI installer to install the system, and that was the state it was in afterwards. <sarg>zilti, is `/run/user` mounted on your system? Do you have elogind installed? <zilti>sarg: I have (service elogind-service-type) in my config.scm. /run/user however... The directory does not even exist <zilti>Ooh I haven't run `guix system reconfigure` <gabber>i have issues (i thought have been mentioned here before) applying patches. in the same patchset the ones which reached me directly via mail and saved from mutt worked fine, but the ones that did not reach me directly don't apply (either downloaded from issues.g.g.o or the emacs debbugs interface). is it me? am i doing something wrong? <cmack>reposting after 8hrs: There is a patch series on guix-patches that I'm interested in evaluating however I'm seeing a "error: could not build fake ancestor" message when using git am (via magit). I'm a bit new to git patches via email, but is this error a sign my MUA is causing a problem or is it likely the patch series needs work? (For example, I don't see a base commit id on the 0th PATCH email...) <zilti>I think I am missing a `use`-statement, but I can't figure out which one... I get "Service 'console-font-tty1' requires 'term-tty1', which isn't provided by any service" <sarg>zilti you've deleted mingetty-service-type, that's why <zilti>sarg: Huh, okay. The documentation told me to... But the other delete is fine? <zilti>But when I un-delete mingetty-service-type, I then get "Service 'term-tty1' appears multiple times" <zilti>when I enable greetd-service-type. <sarg>zilti %desktop-services which you extend already contain most of the services you explicitly define <sarg>ok, not most, but at least udisks and elogind <sarg>hmm, I see. greetd indeed defines `term-tty-` shepherd services <zilti>Alright. So how do I get greetd to work? Because when I delete mingetty, I get the same error as above, just with tty2 instead. <sarg>idk, maybe delete console-font-service-type as well? <sarg>civodul, can you try reproducing the shepherd bug I've mentioned today? It hangs if system time jumps significantly. You can `sudo date --set yesterday` and then `sudo herd status` will hang <civodul>we may need to revert the “timer wheel” thing if nobody has the bandwidth to fix it <zilti>sarg: ah yes, that seems to do it! <zilti>Thanks, I have a running Guix SD now :) <civodul>(it’s called “Guix System” these days :-)) <zilti>The login prompt tells me it is the GNU system even :P <sarg>fine, time to buy a new cr2032 for the RTC clock <lechner>the number one sign you are loyal to your equipment <civodul>feel free to give it a spin because qa.guix seems to be busy these days :-) <janneke>civodul, cbaines: nice, i'll give them a look/go <lilyp>interesting find; do you have an exact failure? <vivien>I’m trying to reproduce this, and I will see if I can run git bisect (although since there is a merge in range, I doubt it will be helpful) <cmack>If a patch series doesn't have a base-commit hash is that a sign it wasn't submitted correctly? <vivien>lilyp, I could be wrong, but I think CI lied, because 1c41971e721dde203580ec17899beae546f1133a seems to fail (no CPU activity while test 11/13 blocks) <lilyp>vivien: I don't think bisecting would be useful here; we'd rather have to fix whatever issue is cropping up in gnome-shell <vivien>You fixed an issue in a similar package (mutter) that had a similar kind of failure (failed to connect to d-bus socket), e21f0cb7b7a87992004193cd56638ad961fe5928, and you removed a propagated-input from sysprof <vivien>CI tells me e38d6a9c2fba815ac34e74baa843f15e33846813 was good, let me bisect a bit <vivien>Maybe there is a naive update in this range that has wrong propagated-inputs <lilyp>gnome-bluetooth appears to be the culprit <lilyp>guix graph --path; then verified that it propagates libadwaita <lilyp>from gnome-shell to libadwaita <lilyp>yep, again separate pkgconf for ui <vivien>What lead you to consider libadwaita? <lilyp>because libadwaita was what broke mutter <vivien>Do you plan to push a fix to gnome-team, like for mutter? <lilyp>haven't built it yet, would need a confirmation that it works <lilyp>btw. it seems i have an incomplete gnome-connections on my branch rn <vivien>I have removed gtk and libadwaita from the propagated-inputs of gnome-bluetooth and moved them to inputs instead. Same problem, same path. <lilyp>dunno what you mean with same path, but I do still appear to get a test timeout <vivien>Should we try and find a gnome-bluetooth version that builds with gtk+? <vivien>Gtk+ support was removed oct 27, 2021 <vivien>So we would be looking at 3.34.5 <vivien>Looks like it’s what Debian is doing <vivien>From what I understand, they have just 1 patch on top of 3.34.5, to upgrade the build system <vivien>So maybe it could work for us as well? <yewscion>Hello Guix! Hope You all are having a great day! <sneek>yewscion, you have 3 messages! <sneek>yewscion, lechner says: / somehow it's getting confused by your setup. perhaps it cannot find your boot.cfg <sneek>yewscion, lechner says: / i believe the boot drive in the Linode setup screens is set incorrectly <yewscion>sneek: later tell lechner: I ended up choosing to upgrade my service and recombine my store and cache partitions with my root partition, since it will end up being roughly the same cost. Would never come up during SOP, so seemed like a WONTFIX to me. <yewscion>sneek: later tell lechner: Thank You for Your help, though! Helped me make sense of what the issue was, for sure! I was very confused. <vivien>lilyp, I’ll prepare a patch to have a gnome-bluetooth-with-gtk+ <lilyp>I'm not sure how much that'd help tbh <lilyp>it doesn't seem as though it's needed (or does it?) <vivien>It helps a bit, because now the path from gnome-shell to libadwaita goes through baobab <vivien>(I have to go now, I will continue later) <sneek>lechner, you have 2 messages! <sneek>lechner, yewscion says: I ended up choosing to upgrade my service and recombine my store and cache partitions with my root partition, since it will end up being roughly the same cost. Would never come up during SOP, so seemed like a WONTFIX to me. <sneek>lechner, yewscion says: Thank You for Your help, though! Helped me make sense of what the issue was, for sure! I was very confused. <acrow>Maybe it's not worthy of an issue but no substitutes currently exist for x86_64 icecat, icecat-minimal or the ffmpeg@5.1.4 dependency. Building these locally, of course, will work given ample time, and resources but the less patient may simply see updates fail and go to another distro. <civodul>acrow: ouch, that’s a problem indeed <civodul>i’ll have to go afk for a few hours but Someone should take a look <civodul>i restarted the ffmpeg build, which should eventually unlock icecat{,-minimal} <lechner>ACTION recommends updating no more frequently than every two months <acrow>I see that the ffmpeg build process is starting again. :) <acrow>Argh, the ffmpeg build failed again after 65 seconds. Reporting something about a channel change. Odd because I thought it built locally, for me. <Kolev>Entering my container is tedious. I have to copy and paste commands from the output of `guix system container`. <Kolev>`guix system container enter` would be cool. <Andronikos>I am not 100% sure but guix system container is more of an environment and not exactly the same as Docker. <twilk>Hi! I run Guix System on a remote server, and I've just had Shepherd hang itself completely during a "guix system reconfigure". This is the system Shepherd, i.e. PID 1, so I can't really kill and restart it. Nor can I restart the machine, since the "reboot" executable just tries to talk to Shepherd's socket, which is hung. As an extra bonus, the <twilk>server isn't accepting SSH connections (since normally, Shepherd receives the connection and launches an sshd instance per connection). What am I supposed to do in this situation? I've got one open SSH session and no physical access to the server right now, so I can't just pull the plug either. <sneek>twilk, nckhexen says: Anyway, if you do return: '("picom" "") → '("picom") or it will be invoked with a single empty argument string; literally ‘picom ""’. <twilk>Ooh, that's useful, thanks cmiller and peanuts! <cmiller>Normally this is done by using a key combination. Also this is forcefully. <twilk>I realise that, I'll do a "sync" beforehand at least... <twilk>Though I think I'll investigate a bit and write up a bug report with what I can find out. Any tips for debugging a stuck Shepherd? <cmiller>twilk: Sadly no. I have trouble using it, since I am still used to systemd. You remote machine is not an ARM one without a RTC by any chance? <twilk>No, it's a plain old x86-64 machine! <cmiller>There was once a bug that resulted in Shepherd fully utilizing one CPU core and be unresponsive. <sarg>twilk: you might be affected by the same issue with shepherd hanging on system date change (read NTP sync) <twilk>cmiller: Hm, this looks different. Htop shows 0% CPU use for PID 1. <cmiller>I guess that means you have a different issue. <twilk>sarg: Thanks, I'll see if that could be it! I run the Guix-standard ntpd, and this particular "guix system reconfigure" shouldn't have done anything special to it, I think. According to the generated /gnu/store/...-upgrade-shepherd-services.scm, it should've done a `(for-each unload-service '(fcgiwrap))` + `(for-each start-service '(host-name <twilk>user-homes sysctl mysql-upgrade nginx))`. I even saw the message from shepherd saying it had unloaded fcgiwrap ("shepherd: Removing service 'fcgiwrap'... shepherd: Done."), but then it hangs, I guess in one of the `start-service`s... <sarg>check /var/log/messages, you'll see it from the timestamps if there was some sync in play <attila_lendvai_>twilk, i've seen this, too, without the 100% CPU issue, so i suspect there's more than the time issue. i'm in the process of making shepherd more debuggable with extensive logging and better error handling internally. <attila_lendvai>someone else here on IRC also described the same behavior, so it's at least 3 of us. <twilk>attila_lendvai: Thanks, that sounds like valuable work! I'll finish writing up my mail to bug-guix, then vulcan-nerve-pinch the server. Looking forward to a more verbose Shepherd to make debugging this easier if/when it happens again :) <Partos>what do you think, is it good idea to use Guix build system for web apps development, as replace for Bazel? <lilyp>Well, you would need to bootstrap some of your standard JS stuff, I'm pretty sure. <lilyp>I'd personally separate the concerns of package management (via Guix) from the build system (whatever else you have) however. Having the two merged hasn't turned out all that well for any "ecosystem" that tried, ever. <lilyp>I checked; 2677bf985c0025d04ffdcff31763978b633dbc58 is indeed good and does appear bad, with no merge between <lilyp>These were some world rebuilds, so I did not bother building gnome-shell back then