IRC channel logs
2025-04-06.log
back to list of logs
<Aurora_v_kosmose>Hm, the initial cloning & indexing of the repo has become pretty lengthy. <Aurora_v_kosmose>It seems I'm bottlenecked by CPU core performance, in this particular case. As the disk is mostly idle. <libretics>I am starting in Guix, I want to start the *libvirt* service to be able to work with Quemu/VirtManager. <ieure>So I fairly regularly need to build and test librewolf packages. Ideally, I want a setup which uses cuirass to build a branch of Guix with the updated packages, and an easy way to test those. Is it a bad idea to have two Guix channels in my channels.scm, one with master, one with librewolf-updates? <ieure>I've been doing the updates in my personal channel prior to sending patches to guix, but this means I'm not testing the exact patches being sent upstream; and since LW can update multiple times a month, it's irksome to translate the changes between channels. <hiecaq>Hi guix, my / has a .lastweek file and catting it shows "Password:\n" and a number, what is this file for and can I just delete it? <ieure>hiecaq, Huh. I also have one of these. <hiecaq>I only found #57268 that seems relevant <ieure>Checked another machine, it also has one. Different number under "Password: " <ieure>What a bizarre thing to happen. <ieure>Well, I think this should be fixed, since Shepherd is doing log rotation now. <ieure>I deleted it off this machine. <hiecaq>Yeah, that's what I'd guess, so I hope we can conclude that it can be just deleted. <nigko>sneek: later tell lfam: Thanks for the explanation. In fact, I wasn't aware of the practice of saving entropy to a file on disk for using it as a seed for urandom on next boot. Useful to know. It seems to be important, e.g., for cryptography. <sneek>Welcome back nigko, you have 1 message! <sneek>nigko, lfam says: I created a Guix VM image based on the bare-bones template, but I added some "printf-style" tracing to the urandom-seed-service. When halting and rebooting this VM, I see that my final tracing message is printed to /var/log/messages, and that is printed after the seed is refreshed before the system is stopped. But I still see the warning that the service might have failed to stop. So I think the warning is misleading, but <vhns>Sorry to be annoying, but I've had #76274 , #76378 and #76419 open for quite a while now (over a month) with no feed back whatsoever, the latter one being a simple inclusion of a missing dependency to a package such that it works properly on Wayland. <jlicht>vhns: on my phone now, but the last patch seems to need a commit message in our changelog format <jlicht>there also seem to be many (formatting?) changes that shouldn’t happen, or should be listed in the commit message, or (imho best option) be part of a separate patch <nigko>Rutherther: I have followed all the services from the output of 'sudo herd status' (with tlp disabled) as you suggested. The following services are absent in the 'reboot log': (loopback nftables root root-file-system system-log udev). Interestingly, during the lengthy process of stopping NetworkManager, nscd service is started 1 time and stopped 2 times, user-homes service is started 1 time and did not stop, if I read the log <nigko>correctly. log-cleanup timer is stopped, but log-rotation timer is absent in the log. One-shot services (host-name kernel-module-loader sysctl x11-socket-directory) are absent in the log. <Rutherther>nigko: thanks for checking that. I think one shot services aren't supposed to be stopped by shepherd on halt,so that is fine <yelninei>sneek later tell janneke: I tried reverting the glibc update to 2.41 back to 2.40 and to try to narrow down the cause. the 4 gnulib tests are passing again and bison is working as well. So either a regression in glibc or something wrong with some of the patches <Rutherther>nigko: that udevd not stopping seems a bit concerning to me. Also it'sstrange the service is starting again, the newer shepherd should have inhibition enabled so that services do no start anymore when you issue a reboot/halt 🤔 <attila_lendvai>i'm confused. if i guix pull with a user, then from that point on that user will have its own guix binary, right? and it's only updated when i guix pull again with that user. is there a way to revert that initial guix pull, so that the user inherits the system's guix pull generation? <nigko>Rutherther: Could it be relevant that I reboot with 'loginctl reboot' and not 'sudo reboot'? <nigko>Rutherther: Concerning starting services in reboot phase, I have the impression that a new instances of these services (does it makes sense?) are started by NetworkManager when it is stopping. <attila_lendvai>i think the answer for my Q is to manually delete ~/.guix-profile and maybe some more under /var/guix/profiles/per-user/ <Rutherther>nigko: I don't think loginctl reboot should be concerning in any way (I reboot like that as well btw) <Rutherther>nigko: I have looked through NetworkManager and nscd and I am not really sure why that would happen in the way you're describing, but I might be missing something <Rutherther>attila_lendvai: your ~/.guix-profile usually shouldn't have guix executable in it. It should be ~/.config/guix/current. And I think that in this case you will have to remove it manually indeed, because guix pull --delete-generations won't allow you to delete your current generation. Only older ones. So you will still be stuck with that one. <Rutherther>attila_lendvai: but the commands don't really do much more than deleting, so it's fine to just manually remove the files - ~/.config/guix/current and under /var/guix/profiles/per-user/$USER current-guix* <attila_lendvai>thanks Rutherther! i think i've removed the user specific stuff, and guix gc also seems to have removed some more store items. <lechner>vhns / the acceptance rate of a patch could be two years, or never. for some reason, committers are often not willing to make on-the-fly corrections to things like commit messages <vhns>That has been the vibe I've been getting from looking at other patches, yes. <vhns>My pet peeve was mainly the patch being ignored altogether, I'm fine with someone screaming over the fence at what needs to be fixed. <vhns>Which jlicht did earlier, so now I sort of know what to fix. <attila_lendvai>ACTION is rather disappointed by the discrepancy between the amount of value he thinks he had provided to guix and how much of that ended up in the repos <jlicht>reviewing patches (and making the ‘on-the-fly corrections’) would go a long way towards committers being able to git am the patches <jlicht>and of course sending patches to a specific team helps, although we have quite some gaps still, as well as understaffed teams in general <jlicht>not directed to anyone in particular, and most certainly not attila_lendvai specifically :) <futurile>cbaines: hey hey, how was the in-person Guix social? <cbaines>I think I missed it, I was away for the last week and a bit <futurile>oh heh - it was literally on the day before I got to London <futurile>cbaines: when you're reviewing a patch series, do you check whether each one builds 'in order', or just that all the patches in the series build? <futurile>cbaines: so the series I'm looking at, some of the earlier ones depend on later git commits <futurile>ok - phew, cos that's been driving me a bit mad <cbaines>each commit being a good state is a nice to have, but it's often too costly to check <cbaines>it is worth considering if changes that are interdependent should be in the same commit though <futurile>yeah, so that's also interesting. Here the changes are saying adding a package AND doing an inheritance for another package in the same commit. I just went back and reread the manual - seems like this is OK (previously I've always done them separately). <cbaines>that sounds a little odd, but generally it's a balancing act so it's a little hard to give strict guidance for how to structure commits <futurile>maybe I'm unclear: so add rust-blah-0.10, and then in rust-blah-0.9 do an 'inherit rust-blah-0.10' <cbaines>right, since it's all about different versions of rust-blah, that seems fine <cbaines>but if you were adding a different package, then that should probably go in a separate commit <Kabouik>How can I know which package provides a file? I want $HOME/.guix-profile/share/X11/locale/en_US.UTF-8/Compose which I need to customize dead keys on my machine (even though I am on Wayland). I managed to do the customizations I wanted on another machine and this depends on this file, but I cannot remember where I got it. <Kabouik>I guess libx11. Will try. Sorry for the noise. <attila_lendvai>Kabouik, for binaries i usually use ls -l `which ls`. it shows the symlink to /gnu/store <attila_lendvai>Kabouik, for other files i just wait for the output of stuff like `find /gnu/store/*llvm* | grep X86RegisterInfo.td` <attila_lendvai>Kabouik, not sure i follow, but can't you just `ls -l $HOME/.guix-profile/share/X11/locale/en_US.UTF-8/Compose` and see where the symlink points to? <hako>you can use `realpath <file>` too <lfam>I'm looking in to the fact that the urandom-seed-service-type "might have failed" when stopping. I checked and it definitely performs it's stop action correctly, but then it returns #t, and that seems to be the wrong thing. Is my understanding correct that service stop actions should return #f when they succeed? <sneek>lfam, nigko says: Thanks for the explanation. In fact, I wasn't aware of the practice of saving entropy to a file on disk for using it as a seed for urandom on next boot. Useful to know. It seems to be important, e.g., for cryptography. <lfam>sneek: later tell nigko: Yeah, for the way that the kernel generates a source of randomness (using a CSPRNG), it's considered somewhat important to preserve some entropy across boots, because otherwise you don't have much entropy available when booting <lfam>It's a gray area, but this method is considered best practice for Linux <Rutherther>lfam: how does this work with guix system live iso? <Rutherther>I noticed I have full entropy on boot of live iso <lfam>Rutherther: How do you notice that? <Rutherther>cat /proc/sys/kernel/random/entropy_avail shows 256 <Rutherther>to clarify I didn't mean actually during the boot, I meant like right after I get to a tty <lfam>Well, the kernel developers are always finding new sources of entropy to add to the pool, and it seems like the understanding of cryptographic security has improved a lot in the last decade. <lfam>It's been several years since I paid attention to this in Guix so I don't remember exactly what we did in this area, but we did at least think about it <lfam>The thing with the live ISO: that is the worst possible case for this. There's no way to offer a pre-made live ISO with a known hash that can address this problem <lfam>Otherwise we could bake them on-demand with a random seed inserted <lfam>If you are booting the ISO in QEMU, then QEMU sets up a mechanism where the VM's /dev/hwrng is connected to the host machine's /dev/urandom, so you have an unlimited source of (probably) strong entropy <lfam>In the last few years that I referred to, the entropy calculation was observed to be... not a real thing <lfam>I don't know if they nerfed it or not <lfam>They were also able to extract entropy from timing of CPU interrupts, things like that. It's a new frontier of finding sources of randomness to feed to the CSPRNG <lfam>I think they also use on-chip RNGs now, which they previously did not trust <lfam>lwn.net periodically covers the development in this area, if you want to read something that goes beyond "I think" and "I don't know if" <lfam>The way that Linux handled this stuff from the beginning to like 10 years ago was determined to be unsound and basically made up. They got some real cryptographic advice and overhauled the system <lfam>It's understandable because cryptography only became a public field of endeavour in that timeframe <lfam>So back to my original question about services and Shepherd :) <lfam>I'm looking in to the fact that the urandom-seed-service-type "might have failed" when stopping. I checked and it definitely performs it's stop action correctly, but then it returns #t, and that seems to be the wrong thing. Is my understanding correct that service stop actions should return #f when they succeed? <Rutherther>quoting the shepherd manual: "Its return value will again be stored as the running value, so it should return ‘#f’ if it is now possible again to start the service at a later point." <redacted>When doing guix deploy, the ssh connection appears to drop if the copied store items are too big <redacted>I can work around by using guix time-machine to do updates very incrementally <redacted>I'm getting: Throw to key `guile-ssh-error' with args `("write_to_channel_port" "Parent session is not connected" <Kabouik>I don't see an package or open issue for github.com/LizardByte/sunshine, would it be very hard to package? I generally don't know where to start when there's no importer vailable. Sunshine (or better yet, its fork Apollo) could be very useul not only for gaming, but for desktop streaming in general. <Rutherther>that someone has managed to run it on a guix system doesn't necessarily mean they packaged it via guix <futurile>looks like it's available as a flatpak, so maybe via that <Kabouik>Good point, that may be it. I would be interested in tring but that sounds out of my league. <meaty>why are guix-managed emacs packages listed twice in emacs' package list interface <Kabouik>Do we have anything providing lmfx? I'm this close to having a Sunshine package definition actually building, but it fails at 100% compilation at the linking phrase: `ld: cannot find -lmfx` <jA_cOp_>Kabouik: maybe the mediasdk package? or you might be able to use a configure flag or CMake option or something to disable libmfx support