help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: *** TRYING TO INSTALL GUIXSD v0.15.0 FOR DAYS ***


From: Brian Woodcox
Subject: Re: *** TRYING TO INSTALL GUIXSD v0.15.0 FOR DAYS ***
Date: Wed, 31 Oct 2018 16:30:54 -0600

I think I’ve had it sitting like that for hours.

The reason I think it’s hung in VirtualBox is the fact that within about 45 
seconds there is no longer any activity on the hard disk icon.

I am currently installing in Qemu and will see how that goes.

> On Oct 31, 2018, at 3:54 PM, George Clemmer <address@hidden> wrote:
> 
> Hi Brian & Leo
> 
> Brian, I believe that what you are experiencing as a "hang" is actually
> the incredibly long time that it takes for guile to bootstrap itself.  I
> started encountering this recently when commissioning new VMs and. At
> first I thought they were "hung" but eventually I discovered that they
> were doing this step, and it takes >30 min on address@hidden
> 
> In my case I do 'guix system vm-image' and then, on the vm, I build
> guix, emacs-guix, and geiser from Git. I don't think this is much
> different than installing the 0.15.0 image on VirtualBox.
> 
> I don't understand why Guile feels the need to bootstrap itself in this
> situation. And this behavior seems to be "new" in recent Guix commits.
> 
> Have you tried just letting it chug away overnight?
> 
> FWIW, I am building vms with Guix v0.15.0-3097-gc16913d34.
> 
> HTH - George
> 
> Brian Woodcox <address@hidden> writes:
> 
>> This is what is displaced on the screen when the hang occurs:
>> 
>> …
>> make  check-TESTS
>> make[3]: Entering directory ‘/tmp/guix-build-guile-2.2.3.drv-0/guile-2.2.3’
>> Testing /tmp/guix-build-guile-2.2.3.drv-0/guile-2.2.3/meta/guile …
>> with GUILE_LOAD_PATH=/tmp/guix-guild-guile-2.2.3.drv-0/guile-2.2.3/test-suite
>> 
>> 
>>> On Oct 31, 2018, at 12:35 PM, Mark H Weaver <address@hidden> wrote:
>>> 
>>> Brian Woodcox <address@hidden> writes:
>>> 
>>>> So I have been trying to install GuixSD 0.15.0 for a few days now.
>>>> 
>>>> My first problem was not setting
>>>> —substitutes-urls=“https://berlin.guixsd.org.  So that fixed one
>>>> problem.
>>>> 
>>>> My other problem is try as I might, I cannot get either guile-2.2.3 or
>>>> guile-2.2.4 to install.
>>>> 
>>>> It always hangs when trying to do the tests after writing all the *.go
>>>> files, (which by the way takes a long time).
>>> 
>>> What are the last messages visible at the point where it gets stuck?
>>> It would be helpful to see the tail of the build log.
>>> 
>>> Since I've not seen other reports of this problem, my first guess is
>>> that the problem is specific to builds done within VirtualBox, for some
>>> reason.  It would be useful to know which test is getting stuck.  Since
>>> VirtualBox requires a non-free compiler for part of its build, I don't
>>> use it myself.  I use QEMU instead.
>>> 
>>> Also, normally you would not need to build Guile, but would simply
>>> download a binary substitute for Guile.  However, our primary build farm
>>> is currently offline due to a recent disk failure, and our newer build
>>> farm (berlin.guixsd.org) unfortunately does not have a complete set of
>>> substitutes for 0.15.0, but only for the most popular or most recently
>>> built ones.
>>> 
>>> So, this is a temporary issue while we wait for the FSF sysadmins to
>>> finish migrating hydra.gnu.org to a new disk array, which will probably
>>> be another few days.  I'm sorry for the inconvenience.
>>> 
>>>> So are there any work arounds to disable the tests for guile-2.2.x so
>>>> I can get this operating system operational?
>>> 
>>> In theory it could be done, but disabling tests would be a change to the
>>> Guile package, and therefore a change to the derivations of all packages
>>> built on top of Guile, which in Guix is *everything* because Guile is
>>> used to execute our build recipes.
>>> 
>>> As a result, if you did this, you would not be able to find *any* binary
>>> substitutes from our official servers, because you'd be asking for
>>> different derivations than the ones built by our build farm.
>>> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]