Hi,
Sorry for the late reply.
On mer., 20 déc. 2023 at 14:02, Aleksandr Vityazev wrote:
> Is it possible to make the build continue locally after several
> unsuccessful attempts?
That’s a feature I also would like. :-) Some pointers for the
interested reader:
bug#24496: offloading should
On 2023-12-20 17:19, Saku Laesvuori wrote:
>> Hello.
>>
>> I have a configured build machine. From time to time it is not available
>> and guix build gets stuck in an endless loop of:
>>
>> guix offload: error: failed to connect to : No route to host
> Hello.
>
> I have a configured build machine. From time to time it is not available
> and guix build gets stuck in an endless loop of:
>
> guix offload: error: failed to connect to : No route to host
> process 13902 acquired build slot
> guix offload: error: failed to
On 2023-12-20 13:29, Reza Housseini wrote:
> On 12/20/23 12:02, Aleksandr Vityazev wrote:
>> Hello.
>> I have a configured build machine. From time to time it is not
>> available
>> and guix build gets stuck in an endless loop of:
>> guix offload: error: failed
On 12/20/23 12:02, Aleksandr Vityazev wrote:
Hello.
I have a configured build machine. From time to time it is not available
and guix build gets stuck in an endless loop of:
guix offload: error: failed to connect to : No route to host
process 13902 acquired build slot
guix offload: error
Hello.
I have a configured build machine. From time to time it is not available
and guix build gets stuck in an endless loop of:
guix offload: error: failed to connect to : No route to host
process 13902 acquired build slot
guix offload: error: failed to connect to : No route to host
process
/gnu/store/hknqainda0ardh1ch1grrazislmmm1js-module-import-compiled.drv
/gnu/store/w9lgwyp9a9v12x0bja3brhqj5ilb6l93-hello-2.10.tar.gz.drv
process 22691 acquired build slot '/var/guix/offload/192.168.1.28:22/0'
normalized load on machine '192.168.1.28' is 0.02
building
/gnu/store/w9lgwyp9
Mikael Djurfeldt writes:
> Hi,
>
> I just installed guix on top of Debian Buster using the installation script
> at guix.gnu.org. I did this on two machines, hat and wand, with the hope
> that I could offload compilation to wand.
>
> This is what I get:
>
> root@hat:~
Hi,
I just installed guix on top of Debian Buster using the installation script
at guix.gnu.org. I did this on two machines, hat and wand, with the hope
that I could offload compilation to wand.
This is what I get:
root@hat:~# guix offload test
guile: warning: failed to install locale
hint
> Did you eventually find out?
I tried looking through the strace output but didn't come right with
that.
In the end I just built another box. Was easier to resolve.
Hi Divan,
Did you eventually find out?
Divan Santana skribis:
> Not sure how to further troubleshoot it:
>
> ~ sudo guix offload test
> guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
> guix offload: Guix is usable on 'cp3.santanas.
Hi All :)
So my guix offload to my build box used to work, no troubles.
As of late it fails. Perhaps due to an update, or because I renamed the
user account on the remote box.
I think all is correct in terms of configuration but still fails with
the below.
Not sure how to further troubleshoot
Hallå
No. Not yet at least. See http://lists.gnu.org/archive/
> html/guix-devel/2018-06/msg00316.html where I also proposed a change to
> guix pull which makes it do the least cpu intensive update by default.
>
Interesting. So how do you find a commit that have the least cpu intensive
update?
20
Hej 😀
On June 28, 2018 6:36:57 PM GMT+02:00, Fredrik Salomonsson
wrote:
>Hi
>
>1) the new possibility of picking a commit that hydra already built
>thus
>> avoiding the compilation of guix locally?
>
>Didn't know that. Is that some sort of combination with "guix weather"
>and
>"guix pull --commi
Hi
1) the new possibility of picking a commit that hydra already built thus
> avoiding the compilation of guix locally?
Didn't know that. Is that some sort of combination with "guix weather" and
"guix pull --commit"?
> 2) the ability to control the cpu frequency via a governor or the program
>
On June 28, 2018 8:09:14 AM GMT+02:00, Fredrik Salomonsson
wrote:
>Hi,
>
>got inspired by this thread to try and setup offloading for my laptop.
>As
>everytime I run guix pull my laptop sounds like it's preparing to take
>off.
>
Hi.
Are you aware of
1) the new possibility of picking a commit
Hi,
got inspired by this thread to try and setup offloading for my laptop. As
everytime I run guix pull my laptop sounds like it's preparing to take off.
But running into problems similar to what Matthew described. I.e. it just
get stuck.
> $ guix offload test
>
guix offload: test
It seems to be working now, for some reason.
I updated guix in the user and root accounts on the build machine again, and
double-checked the .bashrc configs since one of them said I needed to add
".config/guix/current/bin" to the path (even though I swear I did that the
other day, but it wasn't
I'm trying to get my desktop computer to do the actual building, since my
laptop is fairly low spec.
I think I've gotten everything set up (following the directions at
"https://www.gnu.org/software/guix/manual/html_node/Daemon-Offload-Setup.html";),
but when I run "gu
Hello Guix!
I've invested a couple nights this week attempting to make 'guix
offload' work on a second machine I have, but have so far failed.
Here are the different issues I've encountered.
1. It was very difficult to understand what I had to do in order to
alter the PATH
ansaction. From
> this I guessed that the calling guile instance had closed the connection
> because it wasn’t able to grok the output being returned by the guix-daemon,
> and that made me remember that I had recently enabled the guix-daemon --debug
> flag. I then restarted the guix-daemon without the --debug flag, and “guix
> offload test” now works again!
Oh OK, so it does have something to do with --debug.
Thanks,
Ludo'.
...
>> scheme@(guile-user)> (begin
>>(use-modules (guix))
>>(with-store store
>> (add-text-to-store store "test"
>> "Hello, build machine!")))
>> ERROR: In procedure display:
Hello Michael,
"Brantley, Michael" skribis:
> As this is my debut posting I just wanted to start by thanking the GUIX
> community for all your hard work! :-)
Thank you!
> $ sudo -u guixuser guix environment
> [guixuser@guixbuild03 guix]$ bash -c "nohup guile --listen=37146 0<&-
> &>/dev/nul
that "guix offload test" no longer worked for me. It is now
failing as shown below, and notably it fails with a different error message on
the first attempt than the latter ones:
$ guix offload test /etc/guix/machines.scm guixbuild03.foo.bar.com
guix offload: testing 1 build machines d
? Looking at
>> guix/scripts/offload.scm:551 suggests the result is not a string.
>>
>> $ guix offload test
>> guix offload: testing 2 build machines defined in '/etc/guix/machines.scm'...
>> guix offload: 'host1.mydomain.co.uk' is running guile (GNU Gu
not a string.
>
> $ guix offload test
> guix offload: testing 2 build machines defined in '/etc/guix/machines.scm'...
> guix offload: 'host1.mydomain.co.uk' is running guile (GNU Guile) 2.0.13
> guix offload: 'host2.mydomain.co.uk' is running guile (GNU Guile) 2.0.1
Hello,
Two hosts, setup the same as far as I can see, behave differently when
trying to offload builds, any idea how I can get more information on
what the # might indicate? Looking at
guix/scripts/offload.scm:551 suggests the result is not a string.
$ guix offload test
guix offload: testing 2
27 matches
Mail list logo
