Brian Woodcox <b...@inskydata.com> 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 g1@sysi53 ~$ 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 <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. >>>>