IRC channel logs
2025-11-16.log
back to list of logs
<flurando>hi, anyone has idea on configuring gpg subkey for ssh connection usage here? <flurando>Now I am stuck with this error: sign_and_send_pubkey: signing failed for ED25519 "(none)" from agent: agent refused operation <flurando>even my key has AS ability, and home gnupg service with ssh-enabled. <flurando>Tried everything but failed, is there anyone else had experience on configuring gpg-agent to use a gpg subkey? Need help, already planning a reinstall on remote server, as the key is the only way to auth after I forgot the .ssh/id_... key passwords. <rekado>this is for using Nix environments instead of images for Kubernetes. <rekado>I'm not a Kubernetes user, but there's value in positioning Guix as a tool to cut out all the docker / base image / registry nonesense when dealing with established infrastructure tools. <cbaines>rekado, yeah, and if done correctly, Guile has a lot to offer over using YAML for this kind of "declarative" infrastructure stuff <identity>almost anything has a lot to offer over YAML <df0>anyone know why alacritty is opening links in a non-default web browser? the underlying 'xdg-open' command chooses correctly <df0>same problem with Signal, but i think that was something to do with it running inside a container <JodiJodington>df0: how did you set the default browser? for xdg-open, it should just use the BROWSER environment variable. if you set it with some gnome/gtk/etc tool, afaik that only works for the gtk launch api <PotentialUser-85>"I" have packaged gnome-tour, but I mostly copied from gnome-authenticator. I'm having a hard time understanding why this works, which is why I'm not sure if making a pull request is a good Idea. What do yall think? <trev>ieure: were you able to get printing working? just tried it myself and the job always fails with "unable to locate printer", which seems to be an avahi thing <untrusem>I am getting git: corrupted loose reference file error which trying to reconfigure my system <nckx>untrusem: If it's really a corrupted local repository then removing ~/.cache/guix/checkouts should help. <untrusem>removed that directory contents, same error <nckx>PotentialUser-85: Either play around remove bits (inputs, phases, …) to learn what's necessary and what's cruft, and/or just submit your first PR and explain the situation, nobody will get angry. <nckx>It's harmless. If you're really worried, move it to a different name. <untrusem>why did it happend, something related to guix pull? <PotentialUser-85>nckx yea I'm just not knowledgeable when it comes to meson - I'll clean up, go through the list and submit it. Thanks! <Rutherther>untrusem: did you have a power outage during reconfigure? or maybe is your disk bad? Can be a lot of things... <nckx>untrusem: As in, something happened during the previous pull that left your local cached copy of the Guix git repository corrupted. Could've been guix's fault but I think something lower level is much more likely. <nckx>I guess, but on a regular Guix System that should be graceful. <untrusem>that's why I first do a `guix system vm` first to test the new generation <ArneBab> created a pull request with a change that gets Wine 10.5 to build, but it does not run programs yet: <ArneBab>Would be great if one of you with more domain knowledge could take it up and get our wine current again! <trev>ieure: ignore my previous message. resolved the printing issue with adding `(name-service-switch %mdns-host-lookup-nss)' <trev>should probably be a default for gnome so idiots like me don't have to search around for hours <ColdSide`>i'm trying to get RiseUp VPN working, but I'm having trouble <ColdSide`>I installed it with `guix package -i bitmask-vpn` <ColdSide`>firstly, it doesn't seem to have a `.desktop` file, so I have to run `bitmask` from the commandline <ColdSide`>but the main issue is that when I click "connect" it just fails <trev>leaking your private vpn ip <pomel0>didn't riseup vpn use its own client? <pomel0>I tried the bitmask way years ago and got nowhere. Liked it much better when you could use it on openvpn cli <ColdSideOfPillow>pomel0: RiseUp supposedly uses a minimally-modified version of Bitmask, but I've tried them before and I haven't actually noticed a difference <trev>ColdSideOfPillow: is the point of riseup obfuscation? <trev>oh nevermind, it looks like just one of those paid vpns <pomel0>ColdSideOfPillow: yes, I know that, but I never got riseup to work with the regular bitmask <pomel0>trev: Riseup VPN from what I know is probably the only free good vpn, slow, but that's to be expected for a free service <identity>if you would trust Riseup with money, you could trust them without money <trev>at least money may give them an incentive to behave <pomel0>trev: yeah it's scary. but afaik riseup has about 20 years of people trusting in them. For their mail, they had to comply with the FBI once and after that increased security measures by encrypting mail automatically so that even they couldn't read it. Of course, that their email sevice is pretty secure doesn't mean their vpn service is secure too. But it helps <pomel0>(sorry for the long message, I guess you can tell I have a riseup account, lol) <trev>i totally forgot it's an email provider as well <ieure>Is master broken? I'm getting build failures on doc/guix.fr.info <ieure>Lots of "@pxref reference to nonexistent node `Building from Git'" <mwette>I'm building guix from tarball (downloaded today), and I get the build error "no code for module (d-bus protocol messages)". Does anyone have an idea how to resolve this? <mwette>I'm building on Ubuntu 24.04, BTW. <ieure>mwette, My guess is that you need guile-dbus installed, but I don't know for sure. <mwette>ieure: I figured something like that, but I could not find a ref. Ubuntu seems to have no such package. (All the other ones where in there -- thanks, rlb). <nckx>It's packaged in Guix; dunno 'bout 'buntu. <abbe__>I'm trying to provision a guix container without shepherd service, but it seems like whatever I do, shepherd keeps making it into it. <nckx>Hm. I don't see how guile-ac-d-bus gets into Guix's closure in Guix, though (as in, I don't think it does). <mwette>nckx: I'm not sure what you are saying. The build seems to choke during "LOAD gnu/tests/telephony.scm" <nckx>mwette: I just mean that Guix's ‘guix’ package doesn't have guile-ac-d-bus as an input and in fact nothing does. <mwette>Thanks. I see what you mean. I searched sources for clue and found nothing, including in the installed OS packages. <mwette>Ah. There it is, in gnu/test/telephony.scm. <nckx>Well, gnu/tests/telephony.scm does refer to guile-ac-d-bus, but in a gexp, so it's—yeah. <nckx>But that is not a ‘you need guile-ac-d-bus installed to compile this file’, unless it's buggy. <mwette>I'm no guix expert, but it does not seem to appear in a gexp. The scope is (define* (run-jami-test ...) (define test (with-extensions (list ... guile-ac-d-bus ...)))) <mwette>But the reference is outside the gexp, right? <Rutherther>reference to guile-ac-d-bus, yes, it has to be outside of a gexp, it doesn't exist inside of the gexp <mwette>So, to compile telephony.scm you need guile-ac-d-bus. <Rutherther>no, you do not. You need the definition of the package called guile-ac-d-bus. If guix worked like that, you would have to compile all packages when building guix... guix refers to packages in a ton of places <mwette>Rutherther: got it -- that symbol is a guix package. <mwette>It's been a while since I used guix. I guess I will install as a workaround to build. I assume this is some sort of anomaly. <Rutherther>are you sure the no code for module is actually an error that stops the compilation and not just a warning? <nckx>‘You need guile-ac-d-bus installed to compile this file’ looks like ‘#:use-module (d-bus protocol messages)’ or so, which the file does kind of do through its use of (gnu build dbus-service), but that should all be properly auto-loaded. <Rutherther>for me compiling gnu/buld/dbus-service.scm provides "no code for module (d-bus ...)", but as a warning, it compiles the file fine <Rutherther>yeah, the error is no such file or directory here, not that no code for module <nckx>Well I for one am actually more confused now. <abbe__>oh, there are other services which are dependent on shepherd-root-service, so it's implied. <nckx>Figured (heh) as much, but there was a chance you'd half-forked Guix to desperately rip out the core services and I wanted to be here for it if so. <nckx>Is the Shepherd actually interfering with your use of the container or was it just a minimalist preference? <Rutherther>shepherd is the PID 1, so it's really not easy to get rid of it... it would mean completely changing the init <nckx>Not without losing most of the reasons for using *Guix* as opposed to any other containers in the first place. <abbe__>well, I was trying to replace shepherd with openrc <abbe__>but shepherd is integrated with guix system ..., so it's hard <abbe__>there is filesystem corruption bug with shepherd, so it's not as reliable as I would like it to be <Rutherther>abbe__: there is just one person reporting that they are still experiencing that issue while all others have confirmed they no longer are. And the only person who claims experiences it hasn't shared a reporoducer as far as I can tell <abbe__>well, I'm the latest responder, and it happens to me on all of my guix systems from VMs, to baremetals. <abbe__>I run guix system reconfigure at least 3-4 times daily, and reboot the host daily. <abbe__>all of my hosts are in production. <abbe__>there are others also, who also experienced, just not able to figure out what causes it <Rutherther>that is 7 months ago when yes the bug has been confirmed by multiple users <abbe__>root of the problem is, root filesystem doesn't get unmounted cleanly <ieure>abbe__, I opened a similar bug, the issue was fixed. <abbe__>yes, I shared your bug, but for me, my setups still exhibit those symptoms <nckx>I mean, if you are the latest responder, ‘those claiming to run Guix System in prod are actually confused and running something else, silly’ isn't a great start to further discussion. <ieure>abbe__, If you have a VM which reproduces the issue, please share it. <abbe__>well, those who seem to run guix in production, seem to run it in containers with non-guix base os <abbe__>which seems to be fine, as long as shepherd is not in charge of the base system. <ieure>abbe__, You are painting with a very broad brush here, and this conversation is verging into unhelpful territory. If there's a bug, we want to fix it. If you have a reproducer, that will help -- please file a bug and share it, or send it to one of the others. <nckx>Accepting that there might be something interesting about your use case that is giving you more of this bug than others would be a help, because it might hint towards a reproducer, rather than claim that this bug affects more systems than it does. <nckx>Hence making claims about how people use Guix is probably unwise, if you can only find two(!) examples. <abbe__>nckx: i'm not denying it, but even with running core guix (not other channels) stuff, the problem happens for me. although usually, I'm running custom services in my own channel + nonguix <ieure>Bickering about usecases is not going to help fix the bug. Providing a reproducer will. <abbe__>right, unfortunately i don't know how. <abbe__>but the way i use guix is i run guix system reconfigure in conjunction with guix pull every few hours on my hosts <ieure>And that process is breaking? Or it's broken on reboot? <abbe__>and sometimes when I reboot, I see fsck messages about lost files, and sometimes guix system reconfigure fails because of /gnu/store has empty derivation files <nckx>Do you think it happens only (or more likely) on the first reboot after a reconfigure? <abbe__>that's the thing, that's why I'm able to stick with it, and keep contributing to it <abbe__>i tried to submit a video recording demonstrating the issue, and if anyone has any kind of debugging I could add in my setup, I'm happy to <Rutherther>back in March reconfigure, or more accurately the shepherd services replacement script caused the services to stop in a wrong order / not at all. But that has been fixed since, presumably by an update to shepherd, but I haven't ever confirmed that <ieure>abbe__, If you can provide a system image definition and the Guix commit it was built from, and say, running `guix system reconfigure' in here causes it, that would help a great deal. <Rutherther>abbe__: yes, sharing your setup and also the script you run is all we are asking for... a reproducer <abbe__>well, I don't know the reproducer exactly, and my configurations are also independent, except for same packages/services repository, but each has individual repository <abbe__>let me see, I'll provision a minimal VM, and try to stress it. <nckx>I've always had a feeling that Guix doesn't sync as much as (or at least exactly when) it should, but I've never investigated that hunch. However, you'd still need to add an ungraceful shutdown to lose data. <abbe__>well, I always do: sudo shutdown <abbe__>now if that resulted in ungraceful, or not, I can't always tell. <nckx>Sure, anything normal like that should be fine (including halt, or a GUI). <abbe__>it's possible shepherd doesn't wait long enough, unlike systemd which prolongs the shutdown <Rutherther>nckx: Nix has moved to a lot of fsyncs after like anything is put to the store, but Guix doesn't do so, yeah <nckx>Bit blunt, but have you tried adding $something after all file systems should be unmounted, even just a (display "…") && sleep 5m, just to test whether the code is reached? <abbe__>and there's no way for me to verify <nckx>abbe__: If the kernel reports a successful unmount, the init system should take it at its word and not randomly wait. It might sound like a good just-in-case but it doesn't actually make sense. I don't use systemd but I hope it doesn't randomly sleep for magical reasons. <nckx>abbe__: No, I don't, I just suggested it now. And I've not experienced any unmounting bugs. <nckx>So no reason to have one handy. <abbe__>right, I never had filesystem corruption with systemd shutting down cleanly. <Rutherther>unmount should wait until everything is written to the disk, no? at least that has seemed for me to be the case when ie writing images to flash drives. The dd can finish quite quickly and then I have to wait for a long unmount <nckx>It's not a guessing game. <Rutherther>and shepherd definitely waits until the commands are finished, at least according to what I could read from the source, of course there could be a bug, but the current intent is definitely to wait for all services to stop gracefully <ieure>Yes, umount blocks until caches have been synced to the disk. <nckx>Now, I haven't read the Scheme wrappers, but I can't imagine they randomly add 42% more stoopid around basic syscalls. <ieure>Sync on unmount is kernel behavior, you can't do anything about it without physically manipulating the hardware (unplugging the disk/computer, pushing the power switch, etc). <nckx>Yes, but you could return before the kernel says its done (I'm aware that this would require *more effort*, hence the stoopid comment). <nckx>It was not a serious suggestion but I don't have any of those yet… <nckx>Is the only alternative that unmount isn't called at all? <abbe__>also weird thing is in the videos, i linked user-homes service is starting again when shutting down :/ <nckx>And am I mistaken or is NetworkManager happily herd restarting nscd for us during shutdown? <abbe__>also root-file-system only waits for 10s <nckx>(nckx: Yes, pointlessly, but it's later stopped again, so it's not what's keeping anything busy that shouldn't be.) <Rutherther>if you are talking about that let loop n 10, I read that as the unmount happenng maximum of 10 times in case there are any errors <abbe__>right, so even after it failed to unmount, it'll just give up <Rutherther>if it fails 10 times, yes. What is it supposed to do other than that? <abbe__>well, systemd indefinitely waits <nckx>Your video doesn't wait 10s to reboot though. <abbe__>there is no indication when root-file-system service stopping started <nckx>Well services should be stopped in reverse order of dependency but you're right, that's a ‘should’. <Rutherther>abbe__: waiting serves no purpose. Calling unmount infinitely many times could maybe serve a slight purpose, but if it fails 10 times, I doubt in cases like that it would succeed. So the user will be left to force shutdown their computer and be left in the same state as if the computer shut down by itself <Rutherther>really if unmounting/remounting fails, something else is already wrong that has to be fixed, not the unmount logic itself <abbe__>Rutherther: well, whatever is holding it open, could timeout itself, and exit <abbe__>so 10s is just something arbitrary <nckx>Well then, that's where I'd be adding some debug printing, I guess. When root-file-system first starts stopping and if/whenever it loops. <Rutherther>nckx: that is already logged by shepherd, normally. I presume not in some circumstances when somehow the log is completely closed, including stdout. But in those cases adding more logs won't help <nckx>I thought abbe__ said that there were no such logs. Maybe I misread. <abbe__>well, there is no log message on console about filesystems being mounted readonly <nckx>I didn't mean proper logging, just a few dirty debugging displays of what's going on inside the service itself. <Rutherther>you can see all the logs "Service X is stopping". That's logged from shepherd. Until those logs stop, that's presumably when shepherd somehow closes stdout or something like that. So that has to be kept open. As in adding more logs is not going to help. Preventing close of stdout will help <abbe__>Rutherther: maybe a configuration option to specify a timeout that'll help, so instead of 10s, it can wait 30s <abbe__>30s is just the maximum, it doesn't mean it'll always wait 30s, if it's able to remount readonly sooner <abbe__>(unless (catch 'system-error (lambda _ (mount ...) #t) (const #f)) <Rutherther>of course, if mount succeeds it proceeds normally. It never aborts if mount fails <Rutherther>Currently the behavior is abort after 10 failed retries <abbe__>right, so if it's stalling forever <abbe__>then I can see what's breaking it <nckx>‘According to the standard specification (e.g., POSIX.1-2001), sync() schedules the writes, but may return before the actual writing is done. However Linux waits for I/O completions, and thus sync() or syncfs() provide the same guarantees as fsync() called on every file in the system or filesystem respectively’ so (sync)'s not part of the problem. <mwette>re telephony.scm, I started on d-bus install and then decided to just remove test/telephony and test/desktop refs in Makefile. It then built. I'm working on the foreign setup. The default configure installs everything under /usr/local btw, which is fine for me. <nckx>FWIW, I do agree that it's all a bit simplistic and optimistic. <Rutherther>I do not think so. This remounts all the mounts under a mount you want to remount. Then after it does that and gets to the mount you actually wanted to remote, it treats any fail here fatal and aborts. That's that if (path_equal(x, prefix)) return r;`. So when you try to remount / and it fails, it will abort this whole function. I haven't read the rest of the source code, but the line you sent definitely doesn't prove that it retries indefinitely <abbe__>alternatively, add my gpg key to the keyring ;-) <Rutherther>I am not a commiter, so I cannot even if I wanted to. And I wouldn't even if I was, seems dangeours to just sign a random commit I do not want to see in the guix repo <abbe__>oh! i see, i didn't know. thanks! <Rutherther>I am not sure why those set stdout + stderr calls are still there since even the commit message mentions they are unnecessary since syslog is used for logging <Rutherther>but yeah that seems to be what actually cuts the log <nckx>Ooh I'm glad I was AFK just now to miss the annual Guix phishing test. Nice try! <ieure>:/ wanted to make a collectd-service-type, but the collectd package is borken. <nckx>Rutherther: I would… if only because I haven't pushed to Codeberg yet and would probably muck it up. <ieure>It doesn't build against curl 8, I think. <abbe__>And happens again, no delay whatsoever, nor any messages :( <df0>grr, just rebooted and got a corrupt /gnu/store filesystem :| <df0>i wonder if it's possible to add a delay after the filesystem sync before reboot/poweroff <mwette>I installed guix from source tarball. Now, as root, after other fails, I ran "guix build hello" and get "guix build: error: invalid name: `.4.18.tar.xz-builder'". Any ideas? <abbe__>df0: about my video, or you got it too ? <df0>what's the video of? <df0>just reading the backlog in reverse.. are you experiencing the same issue? uncleanly mounted filesystems? <df0>i have a theory.. on some systems, the storage controller reports that the data is sync'd when it's still in some cache and not yet written <df0>mwette: no idea what the issue is, but the source tarball on the website is a few years old and probably full of aarch64 incompatibilites <df0>try the current git head <abbe__>well, i experience it on amd/intel/ampere hosts :/ <df0>abbe__: i seem to get the problem fairly often on my laptop, but i don't recall having any issues on the desktop machine <df0>laptop is nvme, about 10 years old, destop is ssd <abbe__>df0: do you get the fsck on the reboot, i.e. unclean shutdown ? <df0>yeah, i had to run a manual fsck to get the system back up <abbe__>i tried with xfs, ext4, and btrfs <df0>found a bunch of errors, but in the end it was just the latest user profile that was corrupted so i rolled back <abbe__>and different NVME/SSD manufacturers <df0>i think there's a way to disable the hardware cache on the drive, might investigate that <abbe__>well, apparently it's only reproducible with guix, not on nixos. <abbe__>df0: do you use non-guix channels ? <df0>trying "hdparm -W 0 /dev/sda" to disable write caching <df0>i think it's an issue on nixos also, at least from what i read somewhere <abbe__>well, should that matter on VMs too (like hetzner, netcup) ? <df0>no idea, i would think it would only affect the host since that's what's resetting/powering off the drive before all data is written <df0>does systemd do anything differently? <abbe__>well, i guess more mature than shepherd. <abbe__>now deploying a new VM on hetzner with just guix channel to see if i can reproduce this. <df0>systemd syncs, stops services, chroots to ram, syncs again then reboots <df0>oh, unmounts before the final sync <df0>ACTION looks what shepherd does <Rutherther>abbe__: after removing the two lines that redirect stdout/stderr to null, I see all the shutdown messages, including root-file-system service stopping. Ofc only after rebooting as a running service's stop procedure is not changed <abbe__>Rutherther: do you recall before/after messages ? Apparently I don't seem to get the messages. :/ <mwette>Building guix from git source is a rabbit's hole: depends on current (git) which is on gitlab, but releases don't include configure and my autoreconf breaks on it. This is with ubuntu 24.04 which is not ancient. <abbe__>Those messages about remounting root read-only from the patch I sent <Rutherther>removed that two lines that set stdout and stderr to null as I said <Rutherther>but as I was saying, the bug doesn't happen for me, you need to share a reproducer for me to try it... my VM is fine. no matter how many reconfigures I do, it remounts cleanly as readonly <Rutherther>without a reproducer, I don't think anyone can do anything. Really a video does nothing except show the bug. We need to know how to trigger the bug... <abbe__>Well, I don't get the remounting root message which you claim to see <abbe__>In my case only /home gets unmounted for which I see a message <abbe__>I guess it's not getting invoked in my scenario <abbe__>I'll share it when I've a minimal test case