From: Brian Woodcox <bw@InSkyData.com>
To: George Clemmer <myglc2@gmail.com>
Cc: Mark H Weaver <mhw@netris.org>, help-guix@gnu.org
Subject: Re: *** TRYING TO INSTALL GUIXSD v0.15.0 FOR DAYS ***
Date: Wed, 31 Oct 2018 16:30:54 -0600 [thread overview]
Message-ID: <8246EDA7-82A1-411C-B1D0-967F9ECF9CF6@InSkyData.com> (raw)
In-Reply-To: <cuc4ld14wap.fsf@gmail.com>
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 <myglc2@gmail.com> 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 4xCPU@3.4GHz.
>
> 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 <bw@inskydata.com> 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 <mhw@netris.org> wrote:
>>>
>>> Brian Woodcox <bw@inskydata.com> 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.
>>>
next prev parent reply other threads:[~2018-10-31 22:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-31 15:42 *** TRYING TO INSTALL GUIXSD v0.15.0 FOR DAYS *** Brian Woodcox
2018-10-31 17:41 ` Leo Famulari
2018-10-31 18:23 ` Brian Woodcox
2018-10-31 18:35 ` Mark H Weaver
2018-10-31 18:47 ` Brian Woodcox
2018-11-01 7:35 ` Mark H Weaver
2018-10-31 20:50 ` Brian Woodcox
2018-10-31 21:54 ` George Clemmer
2018-10-31 22:30 ` Brian Woodcox [this message]
2018-10-31 23:44 ` George Clemmer
2018-11-01 2:33 ` Mark H Weaver
2018-11-01 3:35 ` George Clemmer
2018-10-31 22:47 ` Mark H Weaver
2018-10-31 23:57 ` George Clemmer
2018-11-01 0:09 ` George Clemmer
2018-11-06 15:27 ` swedebugia
2018-11-06 18:24 ` George Clemmer
2018-11-07 11:40 ` swedebugia
2018-11-07 13:01 ` George Clemmer
2018-11-07 15:16 ` Christopher Lemmer Webber
2018-11-01 1:35 ` Mark H Weaver
2018-11-01 2:58 ` Brian Woodcox
2018-11-06 5:14 ` Mark H Weaver
2018-11-06 17:08 ` Brian Woodcox
2018-11-06 23:22 ` Brian Woodcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8246EDA7-82A1-411C-B1D0-967F9ECF9CF6@InSkyData.com \
--to=bw@inskydata.com \
--cc=help-guix@gnu.org \
--cc=mhw@netris.org \
--cc=myglc2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.