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 <myg...@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 <b...@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 <m...@netris.org> wrote: >>> >>> Brian Woodcox <b...@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. >>>