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

[George Clemmer]

Brian Woodcox <address@hidden> writes:

> 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.

Dunno about VirtualBox. But I just did 'guix pull' on a fresh 'guix
system vm-image' running on GuixSD in QEMU. It looks the same: 4 CPUs
howling and the hard drive doing hardly anything.  But I see this in
/tmp

address@hidden ~$ ls /tmp
guix-build-guile-2.2.3.drv-0/

... and BOOTSTRP GUILEC steps are trickling out. So even thought it
feels like it, it's not hung.

>> 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.
>>>>