<KarlJoad>I am setting up Cuirass by using Guix Deploy to a Guix System server. The server cannot resolve git.savannah.gnu.org to build the hello package. I have nss-certs available, so https should not be an issue. Any ideas?
<nckx>sneek: later tell c0x0o: Depends on whether it's your first mail to any Guix list. If it is, there's no telling when it will arrive. Otherwise, it should be <15 minutes.
<KarlJoad>My pings work, but traceroute eventually dies.
<nckx>atka: It means to make sure that the shell is looking for the guix binary in the right place. By default, bash searches $PATH, but it will also remember (hash) which guix it found last time. When you run ‘guix pull’ for the first time, the location of guix changes, but bash will keep using the old one. ‘hash guix’ makes bash forget that and search $PATH again the next time you run ‘guix’.
<nckx>‘hash guix’ is not supposed to print anything. ‘which’ is not relevant here.
<nckx>‘which guix’ just searches $PATH for guix, it has no idea which (hah) guix will actually be run when you type ‘guix’. It's just a guess.
<nckx>KarlJoad: How can you ping the server if it never resolved?
<KarlJoad`>nckx: On the web interface, all job specifications are marked as "Aborted".
<nckx>And the logs mention git.savannah…? What does it say?
<atka>one more unrelated question regarding general system administration, when would one run guix pull and guix system reconfigure as the root user? would this be needed for general laptop use? what about server use?
<nckx>atka: In the general case, you never run guix pull as root, ever. You ‘guix pull && sudo guix system reconfigure’ as you.
<nckx>If you prefer, you can ‘su’ to root and run ‘guix pull && guix system reconfigure’, but most people don't ever log in as root like that. What's much worse is running ‘sudo guix pull’. That can create root-owned files in your $HOME, which is bad, you'll get permission errors next time you ‘guix pull’ as yourself.
<KarlJoad`>nckx: I specify git.savannah.gnu.org manually using a url field in the channel part of the specification. I wanted to test building something custom. The cuirass log just states that git could not connect to the gnu servers.
<KarlJoad`>nckx: It should not be networking troubles, because I can browse, clone, and work with the files from a laptop on the same LAN.
***iyzsong-www is now known as iyzsong-w
<nckx>KarlJoad`: Thing is you're being a bit vague (sorry) and not sharing the exact error message, and I'm tired, so that's not the best match right now. It's 5:30. I need to sleep. I hope somebody can help you, or you find the answer yourself.
<KarlJoad`>No worries. The error itself is vague. The cuirass.log just says that Git could not resolve the address, and that's it.
<atka>on guix system I just installed a few packages in a single guix install command, some programs I could use right away but some programs like powertop and iotop I had to log out and back in for them to show up. why is that?
<iyzsong-w>atka: where are the newly installed programs expected to show up? is it a desktop launcher or menu? usually in terminal you can run them by command line directly.
<atka>I mean on the commandline, I installed mpv alsa-utils powertop iotop iftop
<allana>Hi guix. Is anyone here using "guix system" to build docker images? I am experimenting with it myself, and when using a pretty minimal config.scm (e.g. gnu/system/examples/docker-image.tmpl) I get a few errors, like "error in finalization thread: Success" (?) and "failed to start service 'host-name'". Is this functionality working for others?
<allana>Additionally, when I have a more complex config.scm, I get a variety of other erros, but I wanted to test a baseline and then go from there.
<allana>The container does start and keep running, but I am skeptical because of the error messages.
*allana thinks he figured it out, added "--networking" to the "guix system image" command
<user_oreloznog>allana: hi! "error in finalization thread" is normal. For the "failed to start service 'host-name'", I don't know...
<KarlJoad`>Has anyone ever seen this error before? It happens when using `guix-deploy`. "Throw to key `guile-ssh-error' with args `("channel-open-session" "Channel opening failure: channel 66 error (2) open failed" #<input-output: channel (closed) 7fc070781ba0> #f)'"
<civodul>KarlJoad`: not specifically; could you paste the full backtrace?
<apteryx>civodul: Great! Getting the build farm in order has stolen my attention lately, but it seems like we're converging on something
<civodul>apteryx: thumbs up for all your efforts on this; much appreciated
<civodul>KarlJoad`: so it would seem that the remote peer closed the connection early on
<KarlJoad`>civodul: It is actually later in the deploy process. The local peer has gone through several rounds of "sending X store items to <IP>". It is the last round (the one with grub.cfg) that fails.
***iyzsong- is now known as iyzsong
<KarlJoad`>civodul: I tried deploying again, but plugged into the network with an Ethernet cable, and it worked. Must be something with WiFi...
<verkty[m]>does anyone know why i can't start my shepherd user services?
<verkty[m]>even after a reconfigure it starts my services then it says exiting shepherd after
<phf-1>So, I would have all the Guix packages' definitions and all the associated source code in the same git directory. If that the case then Cuirass would pull the source code twice : once in the store and once when cloning the git directory where the channel is colocated with the source code.
<KarlJoad`>It appears that Cuirass is only using 2 threads at a time to build the hello package, which is taking a long time, particularly because of mesboot. Is there a way to raise the number of threads a build can use? Or does Cuirass use as many as it wants/can?
<civodul>KarlJoad`: you might want to enable substitutes: you shouldn't need to build *mesboot packages
<civodul>you can specify the number of cores and jobs globally with the --cores and --max-jobs options of guix-daemon
<civodul>phf-1: are you talking about the guix.git repo specifically, or about some other channel?
<phf-1>civodul, is it << better >> to have a git dir tracking the channel and its guix package definitions separated from the source code, or is it << better >> to make it live under the same directory as the source code these packages refer to?
<KarlJoad`>civodul: I thought I had. `guix shell` on the server uses substitutes. Can I specify the cores/max-jobs options through a guix-service-type modification?
<KarlJoad`>I am definitely building all the mesboot tools (although I may be downloading them, Cuirass does not tell me).