On Sat, Nov 11, 2017 at 11:23:00PM +0100, Marco van Hulten wrote:
> > This is terrible, but you can work around it by passing a large value to
> > the --max-silent-time "common build option": [...]
> 
> Hmm, but the time-out is now after 1 hour of silence, and the whole
> process takes over 10 hours before crashing.  This option may be useful
> if I set a very short time, though it remains to be seen if this ends
> guix quickly.  I will play around with it.

You can also increase the timeout with the --timeout option.  However,
if it crashes no matter how long you let it run, that's a different
problem.

> Right now a `guix pull' results in a `dispatch-exception' in procedure
> `struct_vtable: Wrong type argument in position 1 (expecting struct):
> #<pointer 0x0>'.  It seems that GuixSD (or components) is strongly in
> flux right now, so I will try again later and do a proper bug report if
> problems persist.

This is definitely not supposed to happen. Hopefully it's already been
fixed but otherwise a bug report is welcome!

> I'd like to test if it is swapping.  I have 2 GiB of RAM in a 2-core
> machine (Intel Core 2 Duo).  I did notice that swap was not enabled yet
> on my system, and that (during last `guix pull') around 95% of RAM was
> used.
> 
> > > - it took over 10 h to give me back control, whereas this used to be
> > >   a bit over 2 h in previous tries;  
> > 
> > Do you mean that the computer becomes unresponsive?
> 
> Yes.

I have a Core 2 Duo system with 3 GiB RAM and `guix pull` takes less
than an hour and doesn't swap.

> Is 2 GiB considered "memory-constrained"?

I'd argue that it should not be, but due to the Guile bug it is. It may
not be enough to run `guix pull` — I don't know exactly how much memory
is required.