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

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

[Brian Woodcox]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

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

So are there any work arounds to disable the tests for guile-2.2.x so I can get this operating system operational?

Otherwise I am afraid that it is impossible to do a fresh install of GuixSD from berlin.guixsd.org <http://berlin.guixsd.org/>.

Guix version 0.15.0-1.4876bc8
herd version 0.4.0

P.S. I am installing this in VirtualBox on OSX with the download 0.15.0 iso file, which should not make a difference

Thanks for any help.

[-- Attachment #2: Type: text/html, Size: 1530 bytes --]

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

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

Hi Brian,

Can you share the exact command you are running that does not work?

On Wed, Oct 31, 2018 at 09:42:25AM -0600, Brian Woodcox wrote:
> 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 <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).
> 
> So are there any work arounds to disable the tests for guile-2.2.x so I can get this operating system operational?
> 
> Otherwise I am afraid that it is impossible to do a fresh install of GuixSD from berlin.guixsd.org <http://berlin.guixsd.org/>.
> 
> Guix version 0.15.0-1.4876bc8
> herd version 0.4.0
> 
> P.S. I am installing this in VirtualBox on OSX with the download 0.15.0 iso file, which should not make a difference
> 
> Thanks for any help.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Brian Woodcox]

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

Sure the command is:

guix system init —substitute-urls=“https://berlin.guixsd.org <https://berlin.guixsd.org/>” /mnt/etc/config.scm /mnt


> On Oct 31, 2018, at 11:41 AM, Leo Famulari <leo@famulari.name> wrote:
> 
> Hi Brian,
> 
> Can you share the exact command you are running that does not work?
> 
> On Wed, Oct 31, 2018 at 09:42:25AM -0600, Brian Woodcox wrote:
>> 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 <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).
>> 
>> So are there any work arounds to disable the tests for guile-2.2.x so I can get this operating system operational?
>> 
>> Otherwise I am afraid that it is impossible to do a fresh install of GuixSD from berlin.guixsd.org <http://berlin.guixsd.org/>.
>> 
>> Guix version 0.15.0-1.4876bc8
>> herd version 0.4.0
>> 
>> P.S. I am installing this in VirtualBox on OSX with the download 0.15.0 iso file, which should not make a difference
>> 
>> Thanks for any help.


[-- Attachment #2: Type: text/html, Size: 2310 bytes --]

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

[Mark H Weaver]

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.

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

[Brian Woodcox]

Okay, well thanks for that explanation and additional info.

Just to avoid me having to search, what command would I use to get the tail of the build log file.

I can give you the last message where it hangs on the screen, but only after I run it again, which takes a while, so I will do that shortly.

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

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

[Mark H Weaver]

Brian Woodcox <bw@inskydata.com> writes:
> Just to avoid me having to search, what command would I use to get the
> tail of the build log file.

If you know the file name in /gnu/store of one of the build's outputs,
you can pass that file name, e.g.:

  guix build --log-file /gnu/store/1mr5izrbxwd7cbq8m1xrqm45rzkibpsj-guile-2.2.3

If you know the file name of the derivation (/gnu/store/….drv) of the
build you're looking for, then you can use "guix build --log-file
/gnu/store/….drv".

If you built the package locally, another useful trick is to look for
the newest files in /var/log/guix/drvs/*/*, which you can list by
running "ls -ltr */* | tail" or "ls -ltr */*-guile-* | tail" from
/var/log/guix/drvs.

In some cases, it is sufficient to pass the package name with optional
version, e.g. "guix build --log-file guile@2.2.3", but not always.
Roughly, that command finds the log for the derivation that would have
been built right now if you ran the same command without "--log-file".
Note that this won't be the build you're looking for if you've run "guix
pull" since the relevant build was fresh, if either the package or one
of its transitive dependencies have changed.  Passing a simple package
name also won't work if the derivation you're looking for is a special
variant package which is hidden or not bound to a public variable.

For example, 'guile-final' in gnu/packages/commencement.scm is one such
variant.  It is one of the products of the early bootstrap, and the
Guile variant used to build most of the other packages in Guix.  This is
not the same guile that you get by running "guix build guile".

'guile-final' is a "hidden" package, but it can be specified using the
more general "--expression=<scheme-expression>" syntax:

  guix build --log-file --expression="(@@ (gnu packages commencement) \
                                          guile-final)"

Also note that there is a very simple mapping between build log file
names and derivation file names, perhaps best shown by example:

__/var/log/guix/drvs/wc/47q5cw4b23gy9hzzhxp09b804nippx-guile-2.2.3.drv.bz2
___________/gnu/store/wc47q5cw4b23gy9hzzhxp09b804nippx-guile-2.2.3.drv

       Mark

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

[Brian Woodcox]

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

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

[George Clemmer]

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

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

[Brian Woodcox]

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

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

[George Clemmer]

Brian Woodcox <bw@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 <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.
>>>>

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

[Mark H Weaver]

George Clemmer <myglc2@gmail.com> writes:

> Brian Woodcox <bw@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.

That's during the 'build' phase.  The problem Brian is seeing is during
the 'check' phase, at a place where there is not normally any
significant delay.

I already told you this in my last message, but I guess it wasn't clear.

       Mark

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

[George Clemmer]

Mark H Weaver <mhw@netris.org> writes:

> George Clemmer <myglc2@gmail.com> writes:
>
> That's during the 'build' phase.  The problem Brian is seeing is during
> the 'check' phase, at a place where there is not normally any
> significant delay.
>
> I already told you this in my last message, but I guess it wasn't clear.
>
>        Mark

Oops, my mistake. Sorry for the cross talk. - George

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

[Mark H Weaver]

George Clemmer <myglc2@gmail.com> writes:
> 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.

That's not what's happening here, because this hang is happening during
"make check".  Thanks anyway :)

       Mark

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

[George Clemmer]

Hi Mark,

Mark H Weaver <mhw@netris.org> writes:

> George Clemmer <myglc2@gmail.com> writes:
>> 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.
>
> That's not what's happening here, because this hang is happening during
> "make check".  Thanks anyway :)
>
>        Mark

Well, ISTM 'make check-TESTS' is bootstrapping guile for some reason. I
say that because the fragment quoted by Brian ...

> 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

... matches the log for ...

building /gnu/store/55f2ihxyjyskpv9w0m2c4g0zcinjylif-guile-2.2.3.drv...

... that I have here.

HTH - George

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

[George Clemmer]

George Clemmer <myglc2@gmail.com> writes:

> Hi Mark,
>
> Mark H Weaver <mhw@netris.org> writes:
>
>> George Clemmer <myglc2@gmail.com> writes:
>>> 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.
>>
>> That's not what's happening here, because this hang is happening during
>> "make check".  Thanks anyway :)
>>
>>        Mark
>
> Well, ISTM 'make check-TESTS' is bootstrapping guile for some reason. I
> say that because the fragment quoted by Brian ...
>
>> 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
>
> ... matches the log for ...
>
> building /gnu/store/55f2ihxyjyskpv9w0m2c4g0zcinjylif-guile-2.2.3.drv...
>
> ... that I have here.
>
> HTH - George

And, with the current state of the guix infrastructure, even a 'guix
pull' on a fresh vm-image triggers guile bootstrap. And a guile
bootstrap, on the best of days, displays these symptoms: howling CPUs
and hardly any disk activity.

So, relative to what one expects when installing a distro this feels
hung. Not the most confidence inspiring experience to subject a guix
noob to ;-)

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

[swedebugia]

Hi

On 2018-11-01 01:09, George Clemmer wrote:
snip
> And, with the current state of the guix infrastructure, even a 'guix
> pull' on a fresh vm-image triggers guile bootstrap. And a guile
> bootstrap, on the best of days, displays these symptoms: howling CPUs
> and hardly any disk activity.
>
> So, relative to what one expects when installing a distro this feels
> hung. Not the most confidence inspiring experience to subject a guix
> noob to ;-)
>
I react a little on the wording of you last phrase.
We did not subject anyone to anything.

Trying out beta software like guix (especially when our servers are 
down) and pulling the latest guix commit is in my view (with my earlier 
guix-experience) asking for trouble.

Pulling a commit like the one that points to 0.15 see 
http://git.savannah.gnu.org/cgit/guix.git/tag/?h=v0.15.0 is far better - 
I did that 2 days ago with no trouble. No building locally of the few 
packages I needed on a bare-bone install, berlin had 30-40% of the 
substitutes available.

Thus what we could do to improve the situation is to instruct users to 
NOT pull the latest guix unless they know what they are doing or are 
willing to deal with anything that comes up...

We do a rolling release with NO testing branch currently. So everybody 
who pulls the latest and greatest is a tester willingly or not.

-- 
Cheers
Swedebugia

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

[George Clemmer]

Hello swedebugia,

swedebugia <swedebugia@riseup.net> writes:

> Hi
>
> On 2018-11-01 01:09, George Clemmer wrote:
> snip
>> And, with the current state of the guix infrastructure, even a 'guix
>> pull' on a fresh vm-image triggers guile bootstrap. And a guile
>> bootstrap, on the best of days, displays these symptoms: howling CPUs
>> and hardly any disk activity.
>>
>> So, relative to what one expects when installing a distro this feels
>> hung. Not the most confidence inspiring experience to subject a guix
>> noob to ;-)
>>
> I react a little on the wording of you last phrase.
> We did not subject anyone to anything.

I am sorry this came across as a potshot. That was not my intent.

> Trying out beta software like guix (especially when our servers are
> down) and pulling the latest guix commit is in my view (with my
> earlier guix-experience) asking for trouble.
>
> Pulling a commit like the one that points to 0.15 see
> http://git.savannah.gnu.org/cgit/guix.git/tag/?h=v0.15.0 is far better
> -
> I did that 2 days ago with no trouble. No building locally of the few
> packages I needed on a bare-bone install, berlin had 30-40% of the
> substitutes available.
>
> We do a rolling release with NO testing branch currently. So everybody
> who pulls the latest and greatest is a tester willingly or not.

Yes I know, I have used GuixSD as my daily driver for nearly 3 years ;-)

Please let me restate the key points in hopefully more neutral terms:

The fact that Guix can build anything from source means that a new user
may think the Guix install is hung when it is, in fact, working as
designed.  This may cause failure to recruit new users.

Commentary:

It is not typical of a key product feature that when it works it feels
broken ;-). IMO this presents unique documentation, marketing, and
support issues that will need to be addressed to grow GuixSD beyond the
current user base.

> Thus what we could do to improve the situation is to instruct users to
> NOT pull the latest guix unless they know what they are doing or are
> willing to deal with anything that comes up...

Do you mean we should tell users specific commits to pull? Or 'guix
pull' should not pull from the latest commit?  Or something else?

Best,
- George

PS: Maybe further discussion should be taken off the bug?

PPS: Mark pointed out elsewhere that I may misunderstand Brian's
problem. IMO that doesn't undermine the points above.

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

[swedebugia]

Hi

On 2018-11-06 19:24, George Clemmer wrote:
> Hello swedebugia,
>
> swedebugia <swedebugia@riseup.net> writes:
>
>> Hi
>>
>> On 2018-11-01 01:09, George Clemmer wrote:
>> snip
>>> And, with the current state of the guix infrastructure, even a 'guix
>>> pull' on a fresh vm-image triggers guile bootstrap. And a guile
>>> bootstrap, on the best of days, displays these symptoms: howling CPUs
>>> and hardly any disk activity.
>>>
>>> So, relative to what one expects when installing a distro this feels
>>> hung. Not the most confidence inspiring experience to subject a guix
>>> noob to ;-)
>>>
>> I react a little on the wording of you last phrase.
>> We did not subject anyone to anything.
> I am sorry this came across as a potshot. That was not my intent.

Ok, no worries, thanks for clarifying.


>> Trying out beta software like guix (especially when our servers are
>> down) and pulling the latest guix commit is in my view (with my
>> earlier guix-experience) asking for trouble.
>>
>> Pulling a commit like the one that points to 0.15 see
>> http://git.savannah.gnu.org/cgit/guix.git/tag/?h=v0.15.0 is far better
>> -
>> I did that 2 days ago with no trouble. No building locally of the few
>> packages I needed on a bare-bone install, berlin had 30-40% of the
>> substitutes available.
>>
>> We do a rolling release with NO testing branch currently. So everybody
>> who pulls the latest and greatest is a tester willingly or not.
> Yes I know, I have used GuixSD as my daily driver for nearly 3 years ;-)

Wow, I tried multiple times during the last few years to use it on bare 
metal daily but eventually ended up not coping with the brittleness and 
lacked a basic understanding of guile and scheme to avoid the potholes 
and get things done.

GuixSD has matured a lot since I first installed 0.9 and now I 
understand way more scheme compared to then.

Having the beta-GuixSD contained in a VM is quite nice as I get to hack 
and submit patches and still have a stable Antergos/Parabola on bare 
metal that I can handle.

> Please let me restate the key points in hopefully more neutral terms:
Thanks for taking the time to do this :)
>
> The fact that Guix can build anything from source means that a new user
> may think the Guix install is hung when it is, in fact, working as
> designed.  This may cause failure to recruit new users.

I agree that the casual user expects to be able to visually see when 
their PC is working on something.

(Windows did this by changing the icon of the pointer, others do this 
with progress bars or moving stuff that enables a casual user to 
distinguish a hung versus a working state of a program)

>> Thus what we could do to improve the situation is to instruct users to
>> NOT pull the latest guix unless they know what they are doing or are
>> willing to deal with anything that comes up...
> Do you mean we should tell users specific commits to pull? Or 'guix
> pull' should not pull from the latest commit?  Or something else?

Yeah my personal opinion is both actually.

Newcomers should refrain from pulling other commits than what was tested 
(e.g. release commits) until they feel confident about the workings of guix.

If they need a package not yet available in the latest release I propose 
to instruct them to make their own package e.g. via $GUIX_PACKAGE_PATH.

For this to work we should probably release more often than now.

> PS: Maybe further discussion should be taken off the bug?
We are to my knowledge posting to the help-guix list.

-- 
Cheers
Swedebugia

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

[George Clemmer]

swedebugia <swedebugia@riseup.net> writes:

> Hi
>
> On 2018-11-06 19:24, George Clemmer wrote:
>> Hello swedebugia,

>> Yes I know, I have used GuixSD as my daily driver for nearly 3 years ;-)

> Wow, I tried multiple times during the last few years to use it on
> bare metal daily but eventually ended up not coping with the
> brittleness and lacked a basic understanding of guile and scheme to
> avoid the potholes and get things done.
>
> GuixSD has matured a lot since I first installed 0.9 and now I
> understand way more scheme compared to then.
>
> Having the beta-GuixSD contained in a VM is quite nice as I get to
> hack and submit patches and still have a stable Antergos/Parabola on
> bare metal that I can handle.

I had a safety net. My desktops are macOS, so I didn't depend on GuixSD
to make them work and I have two identical servers, originally with
Debian. 3 years ago I put GuixSD on one of them. So I could always fall
back to the Debian server. Lately I am contemplating switching the 2nd
one to GuixSD.

>> PS: Maybe further discussion should be taken off the bug?
> We are to my knowledge posting to the help-guix list.

Oops... faulty context switch ;-)

- George

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

[Christopher Lemmer Webber]

Mark H Weaver writes:

> George Clemmer <myglc2@gmail.com> writes:
>> 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.
>
> That's not what's happening here, because this hang is happening during
> "make check".  Thanks anyway :)
>
>        Mark

FWIW I had Guile building in Guix hang recently, and Wingo told me that
it may be because there's a test that probabalistically appears to not
complete sometimes.  I don't remember what the test was though and don't
have that conversation logged.

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

[Mark H Weaver]

Hi Brian,

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

Thanks.  These last messages were printed by the 'check-guile' script,
just before it passes control to test-suite/guile-test, which runs the
tests in test-suite/tests/*.test.  I guess it's getting stuck during the
initialization of 'guile-test', because it prints a message before
running each test.

At this point, I see a few possible next steps, from easy to harder:

(1) You could wait until hydra.gnu.org comes back online, which I expect
to happen sometime next week.  Hydra has a full set of substitutes for
0.15.0, so you shouldn't need to build Guile at that point.

(2) You could try QEMU instead.  I suspect that Guix has seen far more
testing under QEMU than VirtualBox, because QEMU is in Guix and not
VirtualBox.  If it fails in QEMU, then we will have a test case that
Guix developers can try to reproduce on their own systems.

(3) If you felt like getting your hands dirty and digging deeper to
investigate this problem and find its source, read on:

You could try the same build with "--keep-failed" added to the Guix
command line, and interrupt it after it gets stuck.  At that point, you
should have write access to /tmp/guix-guild-guile-2.2.3.drv-0, and you
can enter that directory and try various experiments.

/tmp/guix-guild-guile-2.2.3.drv-0/environment-variables will contain the
environment variable settings that were passed to the top-level build
commands, including "make check".  In that directory, run:

  env -i `which bash`

or a similar command to clear the environment, and then "source
environment-variables" to load the environment settings.  Then 'cd' into
the guile source directory and run ./check-guile.

Hopefully it will get stuck here as well.  If so, you could use GDB to
attach to the stuck guile process and obtain a backtrace.  It might also
be useful to see the output of "strace -f ./check-guile".

There are many other things that could be tried at this point, such as
removing the "--debug" flag passed to guile at the end of 'check-guile',
inserting debugging print statements at various points in the
'guile-test' script, etc.

Hopefully one of these options is workable.  Sorry for the bother.

     Regards,
       Mark

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

[Brian Woodcox]

Hi Mark,

Thanks for the debugging tips.

I will try your suggestions next and see where it takes me.

> On Oct 31, 2018, at 7:35 PM, Mark H Weaver <mhw@netris.org> wrote:
> 
> Hi Brian,
> 
> 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
> 
> Thanks.  These last messages were printed by the 'check-guile' script,
> just before it passes control to test-suite/guile-test, which runs the
> tests in test-suite/tests/*.test.  I guess it's getting stuck during the
> initialization of 'guile-test', because it prints a message before
> running each test.
> 
> At this point, I see a few possible next steps, from easy to harder:
> 
> (1) You could wait until hydra.gnu.org comes back online, which I expect
> to happen sometime next week.  Hydra has a full set of substitutes for
> 0.15.0, so you shouldn't need to build Guile at that point.
> 
> (2) You could try QEMU instead.  I suspect that Guix has seen far more
> testing under QEMU than VirtualBox, because QEMU is in Guix and not
> VirtualBox.  If it fails in QEMU, then we will have a test case that
> Guix developers can try to reproduce on their own systems.
> 
> (3) If you felt like getting your hands dirty and digging deeper to
> investigate this problem and find its source, read on:
> 
> You could try the same build with "--keep-failed" added to the Guix
> command line, and interrupt it after it gets stuck.  At that point, you
> should have write access to /tmp/guix-guild-guile-2.2.3.drv-0, and you
> can enter that directory and try various experiments.
> 
> /tmp/guix-guild-guile-2.2.3.drv-0/environment-variables will contain the
> environment variable settings that were passed to the top-level build
> commands, including "make check".  In that directory, run:
> 
>  env -i `which bash`
> 
> or a similar command to clear the environment, and then "source
> environment-variables" to load the environment settings.  Then 'cd' into
> the guile source directory and run ./check-guile.
> 
> Hopefully it will get stuck here as well.  If so, you could use GDB to
> attach to the stuck guile process and obtain a backtrace.  It might also
> be useful to see the output of "strace -f ./check-guile".
> 
> There are many other things that could be tried at this point, such as
> removing the "--debug" flag passed to guile at the end of 'check-guile',
> inserting debugging print statements at various points in the
> 'guile-test' script, etc.
> 
> Hopefully one of these options is workable.  Sorry for the bother.
> 
>     Regards,
>       Mark

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

[Mark H Weaver]

Hi Brian,

Earlier, I wrote:
> (1) You could wait until hydra.gnu.org comes back online, which I expect
> to happen sometime next week.  Hydra has a full set of substitutes for
> 0.15.0, so you shouldn't need to build Guile at that point.

hydra.gnu.org is now back up, so this would be a good time to try again.

     Mark

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

[Brian Woodcox]

Hi Mark,

I do have it working now in VirtualBox.

I may try it again down the road, just to see how smooth the experience should be. :)

The only real problem I have with this setup is the fact that the windowing system (XFCE) in VirtualBox is loosing mouse functionality.

The mouse pointer is there, but I can’t always select things graphically.  Mainly happens when I open a window and try to click on the desktop.  Oh well, that’s the cutting edge I guess.

I was also installing GuixSD with QEMU.  That runs a lot slower than the VirtualBox install, but I probably could have given more resources to that build.

At any rate the QEMU install bombed out with an error, so now I am using the hydra site and things are progressing so well that it was up and running in a very short time.

Thanks.

> On Nov 5, 2018, at 10:14 PM, Mark H Weaver <mhw@netris.org> wrote:
> 
> Hi Brian,
> 
> Earlier, I wrote:
>> (1) You could wait until hydra.gnu.org comes back online, which I expect
>> to happen sometime next week.  Hydra has a full set of substitutes for
>> 0.15.0, so you shouldn't need to build Guile at that point.
> 
> hydra.gnu.org is now back up, so this would be a good time to try again.
> 
>     Mark

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

[Brian Woodcox]

I have resolved the mouse selection issue in VirtualBox on Mac OSX High Sierra running GuixSD.

To fix this issue, you have to go to Settings —> Mouse and Touchpad remove the check mark on the Devices tab for Enable this device.

Reboot the computer and this will automatically be re-enabled when the virtual machine boots up again and no more mouse issues when selecting graphical windows and icons on the Xfce 4.12 Desktop

P.S. QEMU does not run fast enough on a mac, but VirtualBox is super fast.


Cheers!



> On Nov 6, 2018, at 10:08 AM, Brian Woodcox <bw@inskydata.com> wrote:
> 
> 
> The only real problem I have with this setup is the fact that the windowing system (XFCE) in VirtualBox is loosing mouse functionality.
> 
> The mouse pointer is there, but I can’t always select things graphically.  Mainly happens when I open a window and try to click on the desktop.  Oh well, that’s the cutting edge I guess.
>