IRC channel logs
2025-06-13.log
back to list of logs
<ieure>It's a good tool if you live in a repressive regime, like the United States of America. <meaty>ghodawalaaman_xm: we have Tuba <meaty>I looked into packageing Tokodon but our KDE stuff is all too old it seems <meaty>goggles-bot: is your guix old? <meaty>we have a (gnu packages fediverse) module <meaty>oh, yes, that version is from years ago <ghodawalaaman_xm>okay, let me update my system, but I am on cellular data so probably can't update it right now <tomenzgg>ghodawalaaman_xm: you already figured out that you're on an old version so this explanation won't be surprising but Tootle was the original name of the Tuba client; so that checks out. <apteryx>I'm curious; what happens when we change our email address w.r.t. to copyright notices? Do we sed all the past addresses to the new one? <efraim>apteryx: there's the .mailmap file for associating old email addresses with new email addresses or new names <efraim>but yeah, I think we do just update all the headers <futurile>apteryx: heh heh yeah, the runbox folk saw one of my posts and asked if they could add it to their help pages, which is cool :-) <postroutine>Hello. When I run the command `guix pull`, SELinux block write access to `/gnu/store` despite having applied the SELinux policy and restore the labels of `/gnu/store`. Do you have any idea how I can fix it ? <futurile>postroutine: hmm, what distribution are you using Guix on? <ruther>postroutine: so you've installed the cil file under /var/guix/profiles/per-user/root/current-guix, is that correct? <postroutine>> postroutine: so you've installed the cil file under /var/guix/profiles/per-user/root/current-guix, is that correct? <postroutine>To found the .cil file, I used this command: `find /gnu/store/ -name "guix-daemon.cil"` <ruther>postroutine: don't do that, that might find wrong one... <ruther>the file will allow specific guix-daemon executable. If that executable is not the one used, it will not work <ruther>futurile: but the cil file already contains what is on that SO answer, so it seems outdated to me <ruther>postroutine: that's old manual, use devel manual <ruther>postroutine: what file is specified in the guix-daemon.service under Exec option? <lockbox____>The installer pulls down 1.4 which is really old, my usual process is to su to root then guix pull to grab a new daemon, and then mount, relabel, restart the daemon <lockbox____>I don't think the 1.4 cil actually works for 1.4 (at least selinux has never played nice and I always have to setenforce 0 for a bit) but after updating the guix daemon its fine <ruther>lockbox____: yeah, I think that 1.4 won't contain the remount allow option <postroutine>> postroutine: what file is specified in the guix-daemon.service under Exec option? <postroutine>ExecStart=/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon \ <ruther>postroutine: actually sorry, seems that the file points to both a specific guix-daemon in store and also to a regex, so basically any updated cil file should be okay, from latest version of guix, not 1.4 <ruther>postroutine: then you can find the associated cil file under there in /var/guix/profiles/per-user/root/current-guix/share/selinux <ruther>postroutine: generally it's not good to try to find files under store using find, you never know when those files will disappear upon next gc. But I suppose here it's not much of an issue as it probably copies the contents of the file somewhere <postroutine>`guix --version` give me `a21688a9d1b2d2f56babc6df3fdba2eb3c7e50b7`. <postroutine>So, either the install scripts installed this version or either I have run a guix pull after set SELinux to permissive temporarly. <ruther>postroutine: yes, the install script installs old version, you need to pull to get latest <postroutine>The guix version I have is the one installed by the install script ? <postroutine>Ok, I have followed the devel manual page about SELinux and it work. Thank you very much. <ruther>postroutine: the commit you are on is quite recent, so something must've already done initial pull <ruther>but I think the cil file you found under store was probably for the 1.4 version and that's why it didn't work <jlambda>When offloading a build to a machine running a foreign distro, is there a way to permanently configure the authorized-keys? The manual says to use 'guix archive --authorize < master-public-key.txt', but that replaces the symbolic link with a file, so upon reboot the file is replaced with the symbolic link again, which doesn't contain the master-public-key. <ruther>jlambda: so you're running thatguix archive authorize on foreign distro, is that right? <jlambda>yes. The offloading works, until the foreign distro is rebooted. <ruther>jlambda: hm. I don't know why the acl file would be replaced by a symlink on foreign distros. On Guix System there is an activation service for that, but that is of course only for Guix System <jlambda>ruther: Yeah, ideally I'd change the build machine to GuixSD, but that is not practical right now. It seems this situation hasn't been worked on (being niche?). Is there something I could hack together to get around this issue without breaking guix? <ruther>jlambda: I would start by finding out what makes this symlink. It shouldn't be guix/guix-daemon itself, so probably a systemd service does that or something like that <jlambda>It's guix running on NixOS, so there is a systemd service created by the nixos configuration. <jlambda>It seems that the aclFile is 'hardcoded' by the NixOS guix service, but I might be able to override it. Thanks for the help, ruther! <ruther>jlambda: so then NixOS manages it and you chnge it with services.guix.substituters.authorizedKeys <jlambda>ruther: Well, that's much more straightforward than what I was coming up with. Thank you so much for catching that; I completely missed that configuration option... sorry for such a trivial issue! <sneek>zimoun, apteryx says: I think we need a blog post about the new GCD process, to dissiminate the information more widely. I know it's been a tough time for your recently (sending warm thoughts!), but when you feel like you have the energy/bandwidth, is this something that you could draft? I'd be happy to review it. <zimoun>apteryx: Well, I’m reading your message about a GCD blog post. Sorry, I’m very late to the party. Do you think it’s still worth? <apteryx>It'd be nice in the interest of newcomers, but for the people part of teams, they probably already know by now. <apteryx>so if your energy level/time allows for it, it could be nice, but otherwise, it's not that big of a deal <jakef>can we get the build to keep the source's .git? <ieure>This is almost always a bad idea and not what you want. <ieure>jakef, If you have the whole repo, the build can do things like reset to a commit other than the one in the package, leading to unreproducable builds. <jakef>it's just for the tests. they do some git things. <jakef>might be part of the "almost" always <identity>jakef: then you probably want to disable those tests <jakef>im trying with git init before the tests and its looking promising <ruther>tusharhero: because %desktop-services contains gdm service type. You need to remove it