IRC channel logs
2026-09-28.log
back to list of logs
<nckx>-crypt is extremely obsolete, use -6 (for SHA512) or so. See the openssl-passwd man page (e.g.: guix shell openssl:doc man-db -- man openssl-passwd). <avalenn>lechner: /bin/sh is useful too, but /usr/bin/env could really be added by default, at the little price of coreutils dependency everywhere <spiderbit>nckx but does guix config support that is the doku on the website outdated because there nothing mentioned sha512 <nckx>I'm not familiar with the doku on the website. Guix config doesn't have to support anything, (password …) takes a single string and nothing else—e.g., (password "$6$myhash"), the output of whatever openssl produces with your chosen hash function. <spiderbit>;; Specify a SHA-512-hashed initial password. <spiderbit> (password (crypt "InitialPassword!" "$6$abc"))) <nckx>You wanted to use openssl, not (crypt …). <nckx>Using both makes no sense. <nckx>(crypt …) is a helper to include a plaintext password in your configuration. <nckx>(crypt "my literal password that I will type to log in" "$6$somesalt") <nckx>produces a string that is similar to what running openssl passwd -6 produces. Both can be assigned to the (password …) field. <spiderbit>ohh it is... well then I find the docu very very confusing... <spiderbit>I thought that is to setup the encrypted password :) <nckx>ACTION , having now read it, agrees that (guix)User Accounts is not very clear on this. <nckx>Not relevant to you since you're using the Web version but the link to (libc)Passphrase Storage is also broken on my system despite having glibc installed. <lechner>ACTION also sees "Info-find-file: Info file ‘libc’ does not exist; consider installing it" <Guest86>Hey there, I use guix deploy for many of my machines and I'm wondering if there is a way to avoid running guix pull on the target machine if I want to do a one-off guix package -i or guix shell with the version of guix that was used to deploy to the machine. <Guest86>i.e. it would be nice if guix deploy had an option or something to update the guix version for a specified list of users <lechner>Guest86: I also use guix deploy exclusively and use your strategy for the root users, although you could employ it for other users, as well. Just remove any traces of that user's individialized guix installation. They will use the system guix instead. That's the updated with guix deploy. It's rm ~/.config/guix/current and rm /var/guix/profiles/per-user/root/*. My suggestion for a <lechner>magic cookie like ~/.config/guix/use-system-only to prevent future pulls hasn't caught on yet. <Guest86>lechner: Thanks for the reply :) I didn't know user's fell back on the system guix like that. So if I'm understanding correctly: deploy updates the system guix and if I remove those per user guix files for <my-user> then <my-user> can run guix shell (or whatnot) using the system guix version. <lechner>Guest86: Yes, for space reason, I also recommend removing the Git checkouts at ~/.cache/guix/checkouts <lechner>Guest86: I only use this feature to make sure root doesn't use an ancient Guix version if I ever need to roll back <Guest86>Thanks! I like your cookie idea or some other equivalent way to do this without relying on a fallback. Maybe an CLI flag to pass to various guix commands that allows us to use the system guix? <lechner>Guest86: Actually, I envision the fallback to work without a cookie. The latter would exist to prevent a future pull, which in my case could end up being several years old even though the system has been updated in the meantime <Guest86>My main use case is for the desktop system I deploy to. I want my users to be able to install stuff or enter guix shells with packages that are up to date with the system <lechner>Guest86: Those policies are useful, but from what I remember they are also hard to enforce. Freedom is hard to take back, and a lot of documentation tells people to pull. Better buy a big hard drive! <Guest86>Yes, in my case too (their user guix version is over a year old). Normally users aren't pulling as they get updates via deploy. But from time to time they (or I) need to install things in a one-off kind of way. <lechner>So the magic cookie, which would be voluntary, might also be helpful for you. <lechner>Guest86: Thank you for using Guix! I hope your users appreciate the sophistication of this beautiful operating system. My wife doesn't. <Guest86>lechner: Haha, I love Guix! Can't imagine using anything else these days. Coming from traditional distros it just has so many upsides. I deploy my servers but also my home machines, including my non-technical wife and shared machines. Administering them with declarative config + deploy makes it so easy to manage many machines <apteryx>How do I compose `modify-inputs' with a conditional package (e.g. via (if (package-supported? p) ...))? Do I have to resort to adding manual labels? <Guest86>Eventually I'll figure out how to write a guix config for a router (that actually works as good as the dedicated router GNU/Linux or BSD distros). I think declarative scheme config would be a nice step forward in the FOSS router world. I think some people have done it but I'm not there yet. <apteryx>this could have been a way, but I don't think it works because #f will probably cause an error: (modify-inputs native-inputs (append lief (and (supported-package? temporal-capi) temporal-capi))) <apteryx>the issue is that modify-inputs returns a sanitized list of inputs with labels already <apteryx>so you can't (cons some-package (modify-inputs ...)) <lechner>Guest86: I agree! Unfortunately, I discussed that with an experienced person at OpenWRT who is probably vested in the current setup. He told me there were some big challenges, but I forget which. <Guest86>Hopefully one day someone will solve them and I can just hitch a ride haha <ed`>Hi folks! Fell in love with emacs and exwm on arch, wanted a fresh start, thought i would give guix a shot. My first impressions? I've thought of giving up sooo many times during the last 5-or-so hours while i've been sitting around waiting for the first pull+reconfigure to finish. Im here for reassurance! Help! <switchy>5 hours? have you got substitutes set up correctly or is it building everything? <ed`>should be set up by default, no? <ed`>but it did build three different openjkds for some reason <ed`>just that was like 3 hours <csantosb>Hi Guix ! This is just me, or evaluations are gone ? <cbaines>apteryx, QA doesn't do any patch testing currently, just branches, and that's in a bit of a inbetween state <jlicht>ed`: we have vms, or guix-as-a-package-manager as well, in case that reduces the friction/boredom a bit <civodul>csantosb: the VM behind pulls.ci was restarted unexpectedly ~10h ago so it so previous PR jobsets were forgotten <civodul>(and before that it was restarted for the Cuirass upgrade)