<benny>I don't know if the hash has to be something specific, I can tell you that commit 4564782c3dac66c9a8a764a696d8bbfb1f33e1ff on my system has the dirname pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq
<benny>I don't know how if that would work but depending on your guix gc usage maybe you can just change the symlink from ~/.config/guix/latest to a different guix-latest in the store which doesn't have that bug
<vagrantc>what took so long is a chain of events to get to something i could cut-and-paste from ... w3m apparently is hard-coded to use /usr/bin/vi or something
<vagrantc>gah. "sudo guix pull" complained about "guile-git" missing. ok. "sudo guix package --install=guile-git" downloads and builds a bunch of stuff. then running "sudo guix pull" complains about "guile-git" missing.
<adfeno>Shion: Hm... Interesting one... I wonder if we could add in the README file an email address or some page having plain text and easy access to it... so that people not using GitHub can also send patches.
<lfam>Re: the discussion of how to use `su` and `sudo`, I recommend reading their documentation! The first page of the su manpage says "The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the superuser."
<adfeno>vagrantc: Could you share the backtrace/output?
<lfam>So, you have to use `su --login` in order for it do the right thing. Even on old-school systems that use '/usr', plain `su` rarely does the right thing
<lfam>If using `sudo`, you have to do `sudo --login` if you want to actually work as root
<vagrantc>ACTION hardly ever uses "su" in the last decade or so
<lfam>Same here, but I've seen people have this issue here before
<vagrantc>adfeno: i posted the backtrace a while back... i'll dig it up from backscroll
<adfeno>complementing lfam's last message (about sudo --login), -i is also shorthand for --login.
<lfam>Sometimes Guix is trying to download a source file that is brand new, and may not be available on all the upstream mirrors yet. The HTTP/S links fail quickly, but the FTP links take a looooong time before giving up
<lfam>I think I'm gonna put the FTP links closer to end of the mirror lists
<civodul>lfam: there are (normally) connection timeouts for FTP and HTTP
<civodul>but maybe it's hanging after a successful connection?
<civodul>would be good to see if there are timeouts we could add
<lfam>The FTP timeouts seem to be longer than the HTTP timeouts
<lfam>But I'll take a closer look to see if it's just a particular server
<lfam>It feels like whenever I notice a source download "hanging", it seems to be FTP
<civodul>in (guix build download) it's 10s for both
<civodul>but again, it's only a connection timeout
<civodul>so if the connection succeeds, then there's no timeout
<civodul>i don't know if i have anything badly configured here, but i can reproduce the problem :-)
<mb[m]1>FTP is weird :) Many servers only accept "active" FTP, in which case the server initiates the data connection to the client, after the initial establishment of the "control" channel (from client to server).
<lfam>I could use a boilerplate response for questions about "guile: warning: failed to install locale"
<mb[m]1>"Remember to export GUIX_LOCPATH for the daemon and the invoking user"
<vagrantc>after some guix operations, i've often seen things suggest to export some variable or another ... does that mean just in the local session? would logging out and logging back in again fix it? or do i need to add it to /etc/environment or /etc/profile or something?