IRC channel logs
2025-05-10.log
back to list of logs
<JodiJodington>hi! I started using the unpriveleged guix daemon (on a Guix OS system) and ive noticed one problem: /var/guix/gcroots/auto is owned by the guix-daemon user and runnin guix gc always fails because my user does not have permision to write to that directory (and neither does root0 <lechner>JodiJodington / Hi, I'm not sure that bug is known, but there have been similar ones in the past week <aidansw>Hi, is savannah having issues? I'm getting a HTTP 502 status code when trying to reconfigure <podiki>yes, it has been having issues a lot lately <sturm>meaty: if you see that config I pasted, I'm only providing the public key, which works fine <lispmacs>hi, gdm is broken on my system (gfx card too old...?) so I am trying to switch to slim + mate <lispmacs>but when I try to reconfigure system, I get error: service 'xorg-server' provided more than once <sturm>JodiJodington: I'm not sure if it's the right thing to do, but I had to manually chown some of those directories, /gnu/store, /etc/guix, /var/guix/ etc to fix issues with wifi. <lispmacs>could somebody tell me how I need to adjust the services section to make this work? <ruther>sturm: could you remember what directories you had to change and to what owner? <ruther>lispmacs: set-xorg-configuration brings gdm-service-type. So remove set-xorg-configuration and put your xorg configuration to xorg-configuration field of slim-configuration instead. <euouae>Hello how does Guix do with Rust? Is it well supported? Rust packages, etc <sneek>Welcome back euouae, you have 1 message! <sneek>euouae, ArneBab_ says: I did not see your response. <euouae>I wish sneek would give a date too ... <ruther>euouae: rust is supported, there are a lot of rust packages. Recently there has been an overhaul of the whole Rust build system, but not yet merged to master. <ruther>it's much more pleasant to use the new build system imo <ruther>And it doesn't mean you cannot use it if you have git deps in the crates, it's just that you have to package them manually instead of getting them just with guix import. <ruther>The previous build system had issues with dependencies, as if you guix import'ed, you could get some deps of incompatible versions, because the ones in Guix channel are used if it's just minor version that differs. <ruther>Note that the build system doesn't support 32bit architectures though <euouae>I'm rewriting GNU m4 in Python. There was not a lot of excitement about Rust when I mentioned Rust in the mailing lists <euouae>Something about how GNU and Rust are going separate ways. I just thought I'd ask what Guix does, maybe there's some wisdom there <ruther>euouae: I don't know much about the gnu or rust 'politics' or how to call that, so I cannot comment on that. <euouae>wait what? rust static links only? I don' tthink that's true <ruther>It is like that with crate dependencies, yes <euouae>It just depends on the programmers doing the right thing <euouae>I guess most people are lazy when they write libraries <ruther>YOu're talking about linking external libraries not written in Rust <euouae>Not necessarily, --crate-type=dylib is for Rust libraries <ruther>Or wait... maybe it really does support it somehow? <euouae>It's just that people don't use the dylib feature <ruther>Hm, haven't even heard about it till now <euouae>Honestly that /probably/ should be up to the maintainers of distros <euouae>Well that blog post is from 2021 not sure when dylib was added <ruther>my bad then. Seems it supports it, thanks for letting me now. <hako>But doing this within Guix will require heavy patching and much more effort that what's currently done on master. <euouae>Doing it within Guix would mean to read the manifest of the entire OS and figure out the minimal number of dylibs needed to support deps and crazy stuff like that? <euouae>I don't even know how Guix supports dynamic libraries in the first place. I don't know a lot about what Guix does behind the scenes. <ruther>euouae: each package gets the libraries in inputs and then the dynamic linker looks for them (through an env var LIBRARY_PATH that is set according to the inputs) and the linker just puts in the full path to the library. <euouae>so you install a gazillion versions of the dynamic library? <euouae>e.g. if foo needs libx.so.1.2.3 and bar needs libx.1.2.4 then do both get installed? <ruther>euouae: depends. There is usually just one or a few in a specific guix channel revision. But if you use more guix versions, then yeah, you can end up with a lot of them. <ruther>euouae: if it was like that, yes, but it's not usually like that, the minor versions are usually compatible with each other, so there is usually no reason to introduce more <euouae>right but it's still up to the maintainers to coordinate to use the same versions <ruther>(or not compatible with each other, I meant backward compatible) <euouae>how does the package manager resolve dependencies? I guess it has some reasoning by which it decides the library versions. nevermind I'm dumb <ruther>euouae: in a way, it is, but it's very easy as maintainers just refer to the symbol from other guile module, it's not like that everyone would be introducing a new library package and then coordinating together. <ruther>euouae: there is nothing to decide, Guix is very simple, it just refers to specific packages in the inputs. <ruther>It's not like pip where the package manager finds the compatible closure of dependencies <euouae>but what that means is that there can be incompatible guile modules <euouae>so you need both guile modules e.g.? I guess that's how it goes <euouae>foo needs mod1 and bar needs mod2 because (maybe) bar is outdated and needs old features <ruther>euouae: guile module is just a scheme file exporting variables. They definitely can become incompatible if you do something strange, like a cyclic dependency. But that is probably not what you mean, so I don't understand your objection about guile modules <euouae>I need to get into Guix soon. I have had it installed but removed it for Debian. I keep finding excuses to delay the installation <ruther>euouae: if it's like that, then there will be two symbols defined, usually mod and mod-1, bar will refer to mod and foo to mod-1 <euouae>anyway my main purpose today was to ask about Rust and/or FSF/GNU opinion of Rust <lilyp>Well, Rust is not the easiest thing to package, what with its bootstrap story and packaging model <lilyp>we have a rust-team which is aiming to improve that <lilyp>as far as GNU is concerned, there are efforts of getting a Rust compiler into GCC so that we have a second implementation; one that is under a GNU license at that <euouae>but is there interest in people writing GPLv3+ software in Rust? <euouae>Because I wanted to rewrite m4 in Rust (currently I'm rewriting it in Python) but it doesn't seem to interest some <lilyp>I'd like you to pause for a second and think about what "rewriting in Rust" means <lilyp>there is quite a vocal group that thinks that moving our entire software stack to Rust will magically make everything better, but I fear their hopes are greatly overblown <euouae>Are you saying it's purposeless? I'm doing it for a couple of good reasons. Rust is not the goal, rewriting in a modern way has value. But Rust is the one that I had the most fun in. <lilyp>Well, consider the existing m4 implementation: Is there any issue with it (that Rust can solve)? Would you actually use an m4 implementation (regardless of whether it is Rust-based)? <euouae>There's several issues with the current m4 implementation lilyp yes. <euouae>Rust itself is not what would fix it. A rewrite would fix it. I enjoy Rust the most. <ruther>sturm: okay so you reverted back to privileged daemon. I thought you had a way to fix it for unprivileged one <euouae>I'm not going to address those because I think maybe you're looking for a good ol' fight-chat and I don't have the time <euouae>I don't think it's nice of you to assume that I'm clueless <euouae>and if not, apologies, but like I said, you can never be too sure with people online <ruther>sturm: are you sure that after switching to privileged daemon the guix-ownership one-shot service has been started? It should do the steps you mentioned in the e-mail. <ruther>sturm: or are you on a foreign distro? I assumed Guix System <aldum> euouae wouldn't it be better to make m4 obsolete? <aldum>as in 'autotools delenda est' <euouae>aldum: I don't think autotools is going away soon due to quite a bit of software using it... <euouae>aldum: from my viewpoint I'd like to improve autotools instead <sturm>ruther: I did reboot after reconfiguring back to privileged, but privs were still weird - eg. most files in /gnu/store were user 901, group sshd <sturm>the guix-ownership service seems to be started <ruther>sturm: do you recall who has /gnu/store itself been owned from at that point? Also you say most, were some owned by root then? <sturm>ruther /gnu/store is root:guixbuild - I haven't changed that <euouae>aldum: I'm also going to guess that autodafe works for C/C++ but you can write all sorts of weird concoctions in Autotools for other languages too, in particular GNU Guile <sturm>ruther: hmm, I'm actually not 100% on that - my command would suggest I did change it, but it must have been updated by guix <ruther>sturm: if guix-ownership didn't do its job after reboot, my guess is that you rebooted when it was already working. It decides based on who owns /gnu/store and I am afraid it changes /gnu/store's ownership first. <lilyp>personal opinion: I think we should get Guile into more modern build systems, like meson, rather than rewriting m4 or even Autotools in Rust <sturm>ruther: it's possible, but I didn't discover any wifi issues until perhaps a week after reconfiguring with privileged? #f, so I'm not sure that's the case <lilyp>and yes, the world does need general-purpose build systems like Autotools or Meson <ruther>sturm: did you reboot during that week? <ruther>sturm: also I am not talking about that time, I am talking about the time when you switched back to privileged. <sturm>ruther: oh, yes quite possible I rebooted shortly after after reconfiguring back to privileged <euouae>lilyp: the guile/m4 thing is one issue, another is that m4 doesn't compile on some newer targets <euouae>another is that m4 2.0 went over 100% increase of LoC -- that tells you something <euouae>another is that features have lagged, affecting the rest of Autotools <sturm>ruther: maybe I'll experiment when I get a moment. Presumably `sudo herd status guix-ownership` will tell me whether the service is still running. Doesn't seem to have a log <ruther>sturm: the service will always be started, it just won't do anything when the /gnu/store itself is owned properly <ruther>currently since your /gnu/store is already owned by root, there is nothing to get from herd status of it <sturm>ruther: thanks for your help <ruther>sturm: okay I verified what I said, /gnu/store's ownership is changed after all files in gnu store are changed. So it's strange you encountered issue with wrong ownerships under the store. Still, what I said can happen with /var/guix and /etc/guix, those are changed after /gnu/store itself. I think the service should be changed so that killing it doesn't leave system in wrong state <yelninei>janneke: I tested the 64bit image yesterday and had no issues there as well. Just sent a patch to use the normal mach for both. <sneek>yelninei, you have 1 message! <sneek>yelninei, janneke says: that's good news, chances are good that the 64bit then also works <auk>rust is neat from a technical perspective but I definitely get the impression there's political problems in the rust world. It seems heavily bent against GPL <euouae>auk: I'm trying to determine how much of that is true and I'm not 100% usre <euouae>I do think that rewriting coreutils (with uutils) using Google money + interns who violate the GPL is not cool <auk>i mean i really like rust, and want to code in it. And everything I write is GPL if i have the choice <auk>but on the whole, when i see a rust project it's usually liberally licensed. It's frustrating <euouae>I want to write m4 in GPlv3+ using Rust <euouae>Right now I'm writing it in GPLv3+ with Python <auk>euouae, yeah the ubuntu switching to uutils because it's "memory safe" and completely neglecting to mention the licensing difference is ... yeah <euouae>chekc backlog "the guile/m4 thing is one issue..." <auk>so: support new arch, general code cleanliness/smaller TCB, add new features? <auk>is m4 really that critical? like for bootstrapping or something? <euouae>It's critical for anything that builds with autotools <identity>if something critical for bootstrapping has Rust in it you are going to have a bad day <auk>also, but tangent from the mention of meson. any opinions on pantsbuild? seems quite interesting to me (incidentally, it is also written in ... rust...) <auk>yeah i agree with identity, rust is messy for bootstrapping. Hopefully one day it will be sorted out <auk>euouae, admittedly I don't know much about m4 or autotools but i have a hard time getting excited about a rewrite of them :) <auk>it's neat that guix will suport cargo.lock <euouae>I don't know if m4 is critical for bootstrapping but that doesn't matter <euouae>because the bootstrapping components can (obviously) already use the GNU m4 version written in C <euouae>and re: the support of cargo.lock, nice. I also heard Nix went through a lot of trouble for that <euouae>something about how their packages were bloating up with the Cargo.lock files heh <auk>euouae, i've been brainstorming about a possible `rust-toolchain.lock` <euouae>auk: hmm... count me out of that. I'm too clueless to meaningfully say something <lilyp>re pants: I'm not using any and if I was I'd prefer them not to rust <aldum>>you can write all sorts of weird concoctions in Autotools for other languages too <ekaitz>and then reza sent theirs and in 3 lines said more or less what I needed two emails to say <arvid>Is there a way to configure shepherd services beyond the guix service interface? I want my wireguard service to respawn for example because it fails sometimes on network issues. <ampinga>Hello everyone, does anyone know if there's a terminal command that show the download size of package without downloading? just to check the size. I saw on the size after <ampinga>identity: does it not showing only the size of the packages and dependencies occupied on the disk? I tried it before but it seems the download size when I use "guix install <package-name>" and the size showed on "guix size <package-name>" didn't match. <naran>It's been 24 hours with no updates to the help-guix list archives. And my message from 12 hours ago hasn't appeared there. Is this normal? <JodiJodington>I tried running the daemon rootless and it didn't work too well for me so I switched back but it never reverted the permissions.. really feels like an oversight. Should I just move everything to be owned by root manually? <dariqq>naran: if this is your first message to the list youll need to be manually approved <JodiJodington>actually, is there a way to ask guix to regenerate my entire root directory based on my system config? <JodiJodington>I know I can probably just use the installation usb but id rather avoid that. Any way to do that on-the-fly? <ruther>JodiJodington: what does that mean? most of root is remade when you boot. <naran>dariqq, yes, it is the first message. I'll wait then for the approval. Thanks. <JodiJodington>in this case, /var/guix/ permissions are all messed up. would that be re-generated on reboot? <ruther>just `sudo chown $USER /gnu/store` and `sudo herd restart guix-ownership`, it will take care of it <ruther>do not reboot until the service is finished <JodiJodington>are you sure /gnu/store should be owned by the user? it's all owned by root:root right now <ruther>that is what the guix-ownership is going to ensure. After it's not owned by root. <ruther>No, $USER is going to be substituted for your own user <JodiJodington>not sure I understand then. I'm changing /gnu/store to be owned by my user and then the `guix-ownership` service ensures it's all owned by root? <ruther>yes, it's the trigger condition for the service <ruther>what exactly finished instantly? herd start? <ruther>okay and what is herd status of it? <JodiJodington>it is stopped (one shot). it is enabled. providers: guix-ownershop. requires: user-processes user-homes. Will be respawned. (with periods instead of newlines ofc) <ruther>JodiJodington: and /gnu/store is owned by who now? <ruther>I think there is something wrong with guix-ownership logic then. I don't know what though <ruther>or maybe it's still running, though I would expect the state to be 'starting' if that was the case <JodiJodington>wait no im wrong, /var/guix/ is all owned by root:root, but I still get "store database directory `/var/guix/db` is not writeable: permission denied" when reconfiguring <ruther>JodiJodington: did you reboot / restart the guix-daemon after you reconfigured switching to privileged daemon? <futurile>ekaitz: evening - thanks for the comments on GCD005 - I _will_ reply! <ekaitz>i have a strong tendency to try to look to the broad picture of things, and that sometimes derails discussions <futurile>well it's good to think about whether the underlying framing of a question is worthwhile <futurile>though I do feel like you've set me an exam essay question ;-) <ekaitz>i was mostly looking for what reza mentioned in his email: automation <ekaitz>andreas-e explained very well that it's not the releases what we need but the stability they provide <ekaitz>so there are probably some things we can do to try to be more stable and reduce the complexity of the release process <futurile>generally, I'm in favour of automation, and I do think we should improve our developer tooling (particularly visibility, automation of minor updates) generally. I would not use that to _prevent_ us from trying to do a "better job" at releases. <futurile>don't let the perfect be the enemy of the good etc. <ekaitz>futurile: yes, but one should improve the other. It goes both ways <ekaitz>futurile: a release process would let us find what our tooling needs, and automation would make releases easier to make <luca>Not to downplay how much work goes into testing ISOs and VM images. But it should be less work than testing packages (which in theory should be tested continuously since guix is a rolling release distro) <futurile>ekaitz: true, we're more likely to automate what we do more often - exercising what we do <ekaitz>luca: you have a point there, yeah <futurile>luca: it really depends on what you want, how you think about "quality". Your "in theory ..." isn't true, the archive is too big and people have different interests - I'm looking at a perl package that was updated in 2016 right now <futurile>luca: but sure, yes you could "just" automate and create new artifacts, it would definitely be something. <futurile>luca: it's all going to come down to how much effort, and how regularly does the group want to put into releases. Releases generally don't benefit contributors (they already have Guix), it mostly benefits new users (and kinda benefits you when you do a new install). <luca>To be clear, I didn't mean automate artifacts. While that could also be done, I do see the value in human tested images. Especially if they are "the entrypoint" of new users into guix <futurile>luca: ah got it, yeah so actually because the installer drags in the graphical desktops, you do land-up with a reasonable amount of testing to do. But, your right - pick the priority areas to focus on. <luca>But I do see what you mean, in that some packages are forgotten, and a formalised testing process would bring these issues to light. But I suppose it depends on if you look at it as a new "guix release" or just a "guix iso release", where one entails a lot more testing. Of course each approach has it's benifits <futurile>luca: yeah, so testing the whole of the archive just isn't going to work, so that's why I put forward the 'package sets' idea to try and limit it to the common parts. And efraim has put work into this already, in the reply to reza I reference another thread which is worth reading (if you're curious). <luca>For some background, I believe void linux tests ISO installations of x86_64, i686, aarch64 (and maybe the other arm stuff) on glibc and musl on baremetal and VMs. But I'm pretty sure they don't test all packages, just the install mostly <futurile>musl mmm, I should look at Void at some point! <Guest97>Does anybody know why Emacs 30.1 hasn't been packaged in Guix yet? Is it a technical issue or not enough resources (people/time)? <ruther>It's in the emacs team branch, I think it's pending mostly on QA, other teams are in front of emacs in the queue <identity>you could use emacs-next in the meantime <ruther>I am afraid it's going to be months before it gets merged as there is 6 teams before it in the queue <ruther>looking through the branch issues, I think my initial estimate was wrong, I think it's not going to be months <zuki>I've been setting up guix for the first time slowly been reconfiguring everything, although been running into a few issues... one is that fonts don't look quite right compared to my gentoo install, I've copied some my font config file that sets default fonts but not much else. <zuki>I've been having a small issue of not knowing how to load bash_completion in my bashrc any tips on that would be helpful. <zuki>The other issue i've been having is being unable to disable gdm, which is a pain especially since its been a really buggy and I've had to switch to another tty every boot up. <zuki>thanks for any and all help. <zuki>I've tried disabling gdm but I've done something wrong since its still enabled and I'm very new to lisp and guile so I've probably made a very basic error <ruther>zuki: to remove gdm, remove set-xorg-configuration or set the second argument to your login manager of choice <zuki>ruther: i've removed set-xorg-configuration, about to reboot to see if that works. <JodiJodington>zuki: you shouldn't need to source bash_completion btw, /etc/bashrc should just source it for you <zuki>disabling xorg config disabled gdm as you said thanks <JodiJodington>does anyone know a writeup/explanation of how builds are containerized and sandboxed in guix? Ive been trying to read the guix source code but I can't exactly find where it's implemented <ruther>it's implemented in the nix daemon <JodiJodington>is that the same as nix's? can I just read the original nix paper or did guix change some stuff <ruther>I don't think guix changed that. I am not sure this is part of Eelco's thesis though. <ruther>but there might be more resources on it if you search for nix instead of guix