Thank you Rutherther and Simon,
I was able to create a Guix system installation on the VPS using a
debian 12 bootstrap and the 1.5.0rc1 tarball. If desired my notes are
on codeberg at
https://codeberg.org/ghiknt/notebook-whk-name/src/branch/wip-org-mode-conversion/cookbook/debian-to-guix/index.org
whk via<[email protected]> writes:
Updating channel 'guix' from Git repository at
'https://git.guix.gnu.org/guix.git'...
guix pull: error: Git error: failed to connect to
git.guix.gnu.org: Operation timed out
On 12/30/25 10:11, Simon Josefsson wrote:
Isn't that just a temporary network issue? Codeberg has network issues
sometimes (although less often than Savannah).
On 12/30/25 09:17, Rutherther wrote:
Codeberg has been struggling in the last few days, so to me it looks
like you just hit the case when it did struggle. Just try it again. In
case it persists further, report back. Or did you already do it multiple
times? It's not really clear from your message.
You can also try `wgethttps://codeberg.org` and `wget
https://git.guix.gnu.org` to see if something is wrong with network.
This turned out to be primarily a VPS and user error.
* The VPS is blocking all outgoing IPV4 TCP. I will be submitting a
ticket to them
* The VPS provided Debian had static config for ipv4 and ipv6
* I used dhcpcd for Guix which received correct information for ipv4
but not for ipv6
Switching to a static config with only ipv6 routes being dynamic using
ra works for me.
I need to spend some time figuring out how to correctly proxy 'guix
pull' and 'guix system reconfigure'. Since I could ssh into the machine
I tried to use both http/https proxy and socks5 via ssh but couldn't get
either command to work with a just init'd system that hadn't done a
'guix pull' yet.
* guix --version on generated system returns 1.4.0-47.21ce6b3 rather
than the 1.5.0rc1 that was used to generate it
Simon Josefsson wrote:
That is the normal "when I install a guix version X system I get guix
version X-n" problem, and while surprising I think it is intentional.
You need to 'guix pull' in the newly installed guix version X-n to bring
it up to version X (or more likely a later version X+a at the time you
run 'guix pull').
Rutherther wrote:
This is expected in the way you created the system. When the 1.5.0
binary tarball comes out, the guix package its going to point to is the
one that was bumped previously. So when you do guix system init with a
configuration with %base-services, you will end up with an older guix.
(`guix show guix` is the one you end up with) You could change the guix
in guix-service-type to (current-guix) in case you wanted to end up with
the same guix as you're using. See this as an example
https://codeberg.org/guix/guix/src/branch/master/gnu/system/examples/vm-image.tmpl#L136.
I used the guix-current configuration and did a pull so I believe my
produced system is a derivative of 1.5.0rc1 now and will continue
testing other things. But this did highlight that since I am very
interested in the reproducibility aspects for Guix that I need to spend
time with the manual getting a better understanding of the version of...
* guix command, guix-daemon, and the guix builder accounts
* packages used under a specific profile
* the packages used to build the current used packages
o Installer required newgidmap which was not installed. Installed
with apt install rootlesskit
Simon Josefsson wrote:
The 'newgidmap' tool is from Shadows and you only need to install the
'uidmap' package, not rootlesskit, this is now in the manual:
https://guix.gnu.org/manual/devel/en/html_node/Binary-Installation.html
"The Guix project also provides a shell script, guix-install.sh, which
automates the binary installation process without use of a foreign
distro package manager5. Use of guix-install.sh requires Bash, GnuPG,
GNU tar, wget, and Xz. On systems where systemd is detected, the tool
newgidmap from the uidmap package is also required."
I switched to installing uidmap instead.
Cheers,
W
