IRC channel logs
2026-09-12.log
back to list of logs
<Heterochromium>When I need to upgrade everything on my Guix installation, what should I do? <Heterochromium>Specifically, I'm curious about `guix pull`. Apparently it works on a per-user basis. So, do I need to upgrade twice, one for my user, and one for root? <lechner>For me, it's the system an a user minimum, plus maybe root <Heterochromium>Oh, right. I forgot that the system is different from the root user for a moment. <Heterochromium>I'm not sure. I'm using Guix System. Maybe? I thought I heard that Guix Home works automatically on Guix System. <lechner>how do you install packages for your user? <lechner>home works well with system but it's not automatic <Heterochromium>Usually `guix install <package>`. After I find what I need, I try to put it into my `(specifications->packages ...` list so I don't forget. <lechner>run guix home reconfigure on your spec <lechner>You may be able to skip root if your sudo works. for me that means no encrypted home folder <Heterochromium>I have a file that describes all software packages to be installed for my user, declares some Bash aliases, and declares some environment variables. Also, I've invoked `guix home reconfigure <config file>.scm` before. Isn't all that Guix Home? <PotentialUser-83>lechner lechner_ bad news: I added console=tty2 to my kernel parameters but nothing changes and the displayed tty after boot is tty1 <PotentialUser-83>now the question is: are the log messages still going on tty1? why is the displayed tty not tty2 as per our previous discussion? If I disconnect, please feel free to reply because I will check the logs; might go to sleep soon <lechner>PotentialUser-83: I believe the console parameter redirects the messages but does not change the vt you see <Heterochromium>Does anyone know potential reasons why the Guix installer can hang forever after starting the installation? <Heterochromium>I've been trying to install Guix inside a QEMU VM all day. After the the 3 services (user-homes, guix-ownership, guix-daemon) restart on the black screen, nothing happens for more than 20 minutes. <PuercoPop>Heterochromium: Yes, there is a bug about it. It has to do with the latest guile release <Heterochromium>Does this bug affect anything besides the installer? My networking completely died earlier today (even Ethernet), which was highly bizarre. An old configuration got it working again. <civodul>hako: hi! i’ll let you revert the Guile-Git upgrade, sounds good? <chungy>`guix pull` doesn't work in this instance <chungy>nevermind, I figured out I can just run an older guix-command directly. <jayq>Hello! I haven't pulled in a while. When I now guix pulled, I get an error "cannot link <jayq>"cannot link /gnu/store/.tmp-link-<BLAH> to /gnu/store/.links/<BLEH>: Operation not permitted" <jayq>I note that the path /gnu/store/.links/<BLEH> is owned root:root, should it be owned by guix-builder? In general, should everything in /gnu/store be owned by guix-builder? <jayq>I have a small number of objects under /gnu/store owned by root:root, is that seem correct? <bdunahu>I don't know, but all my /gnu/store/.links/ are owned by root:root <bdunahu>everything in my store seems to be owned by root as well <jayq>are you on guix system? I am a foreign distro and running with the new unpriviledged (?) daemon setup <bdunahu>okay that makes sense, I am on guix system and haven't looked into how a setup like yours differs <jayq>I have a feeling everything should be owned by guix-builder, I wonder how the root owned objects have snuck their way in <jayq>I'm tempted to just chown -R, this is more or less a lab machine....... <mfg>jayq, you can either run the daemon as root, which was the only option for a long time and afaik is still the default. <mfg>If you have that then everything in the store must be owned by root <mfg>I'd also advise to never manually alter store items in any way <jayq>I've explicitly set it up as running as it's own user, per the new install script <mfg>There is a guix-ownership (if that's the correct name?) one-shot service that runs and may not have finished yet <mfg>or may have been interrupted and needs to run again <mfg>the service is called guix-ownership <jayq>I wonder if that exists for a foreign distro setup? I saw that mentioned in some mailing list archives <mfg>Ah yes, sry. On a foreign distro I'm unsure. <mfg>Don't know who/where this service should run <mfg>since shepherd can run as a user daemon, it may be necessary to run one for root and then start this service? because manually running chown seems wrong to me <jayq>yeah I definitely shouldn't need to be doing that <jayq>but I did it, and now guix pull is running.... <jayq>This is why I have a test machine :D <jayq>It might be remnants from installing, I disected guix-install.sh and implemented it in ansible. This machine is the result of developing that ansible script, which involved manual screwery.... so I wouldn't be surprised ifthere is weird remnants of the install process <mfg>But why use ansible (besides familiarity)? guix deploy may serve the purpose 🤔 <stephen0>So, my atheros pci card arrived and my t480 now has internal wifi working under guix. Same card might have bluetooth. But I dont see a packe with hciconfig or anything else I'm familiar with via guix search. <stephen0>Oh, I see a message about patch file not found and firmware missing. <rovanion>I just wanted to say thank you to those who have worked out the new texlive packaging. I can now pull in the groups of packages I need without trying to pick out single packages or giving up and pulling down half the universe's PDF documentation. <jayq>mfg, again I'm only foreign distro so I dont think I can guix deploy - isn't guix deploy for delivering a new configuration to a guix system? With ansible I can set up my laptop/workstation in more or less one command, and since everything else is coming with ansible I might as well use that to deliver guix daemon as well <nv_el_>jayq, i might be doing something of note relating to that, i'm moving from a foreign (debian) distro lxc to a guixsd lxc, and i plan to move to a guixsd install later down the line <nv_el_>might it be of use to you as well? <nv_el_>new to the guix world so this is all very liekly impossible for a bunch of reasons but still trying to figure it out <jayq>so you want to pivot debian into guixsd? That sounds wild :D <nv_el_>yeah, doing this because i wanna try out a full guixsd env before moving to it, since my main machine is a chromebook and that comes with its own set of quirks <jayq>guix on a foreign distro fits my needs perfectly, so I'm not looking to go to guixsd. I've had a guixsd laptop setup once, it was pretty sweet <postroutine>But the latest test fail. I run the Guix package manager on Fedora 44. <eikcaz>postroutine: Are you trying to run the daemon currently on your machine? Since you are on foriegn distro, guix pull probably does not update guix-daemon. To set the guix daemon version on your current system, I think you'd need to edit the binary path in the related systemd service file in /var/lib/systemd or similar. <postroutine>eikcaz, I have followed this steps: 1) Run the command `sudo --login guix pull --no-substitutes`, 2) updated the SELinux policy and 3) run the command `sudo systemctl restart guix-daemon.service` <postroutine>I forget: Before running `guix pull`, I had to set SELinux to permissive. Otherwise, impossible to build a package. (I don't remember which one) <jayq>Atleast in the systemd unit on my machine that came with the guix installer starts "guix-daemon" from /var/guix/profiles/per-user/root/current-guix - so guix pull (as root) will update the daemon <eikcaz>Find that guix-daemon service with `find /etc/systemd/system | grep guix-daemon`, then look at the contents. Does it point to /root/.config/guix/current/bin/guix-daemon, or some fedora path like /bin/guix-daemon? If it points to some fedora path, then sudo -E guix pull won't help. <j_importer>nv_el_: that's about where i'm at too. trying guix out in a VM to see if i can switch my home server over from ubuntu <jayq>"systemctl cat guix-daemon" is an easier way to get the contents of the systemd unit <postroutine>eikcaz, the file `/etc/systemd/system/guix-daemon.service` point to `/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon`. <eikcaz>cool. I had that problem on foreign distro long ago. Guess it got fixed. <nv_el>PotentialUser-21, i also encountered the link issue you described yesterday <postroutine>In the script execution log, there is an error: `fatal: unable to access '...': server certificate verification failed. CAfile: none CRLfile: none`. <postroutine>I know that Fedora changed things about certificates in recent OS version. <postroutine>Is I'm very now to Scheme and Guix, I do not know what to do to pass the last test of the test script. <postroutine>I would love to be able to successfully pass the last test, so I could use Guix again on my distro. <eikcaz>postroutine: by "Fedora changed things about certificates" do you mean they changed the cert path? I assume the environment from which systemd launches services would be updated accordingly, but you could try updating the guix-daemon.service to set SSL_CERT_DIR=... <eikcaz>in fact, you could set it to the result of 'echo $(guix build nss-certs)/etc/ssl/certs' <eikcaz>In that case, finding CAfile and CRLfile should be mostly independent of Fedora <Guest39>hello world :) l'm thinking of trying out guix again because i've already bounced off it twice :'( <Guest39>i'm looking for something with less llm code in it. at the moment i'm on opensuse because it's european. i've also looked at netbsd which seems interesting :) <postroutine>But running the test script fail on the last test with the same error messages. <noxi>I've seen this list passef around. I wish someone made a better one, it's incredibly unhelpfully organized