GNU bug report logs - #37482
Guix fails to build libreoffice

Previous Next

Full log

View this message in rfc822 format

From: Jan <tona_kosmicznego_smiecia <at> interia.pl>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 37482 <at> debbugs.gnu.org
Subject: bug#37482: Guix fails to build libreoffice
Date: Mon, 23 Sep 2019 02:45:35 +0200

On Sun, 22 Sep 2019 19:45:52 +0200
Tobias Geerinckx-Rice <me <at> tobias.gr> wrote:

> 2 GiB of RAM is simply not enough to build many packages these 
> days.  That's the world we live in.  There's nothing Guix can do 
> to change that.

Sad, guess I have to buy more RAM.

> You can restrict the number of parallel builds and jobs by 
> respectively passing --max-jobs=1 and --cores=1 to the daemon. 
> You can make this permanent by setting (extra-options …) in your 
> system configuration.

Cool, didn't know about this option.

> Even then, some complex executables will simply fail to link with 
> so little RAM.
> 
> Your issue is different: the exact same libreoffice might have 
> built fine if you had 4 GiB of RAM, or 3, or 5, or 2 with swap, 
> but only if your weren't also running any (Guix or other) builds 
> at the time, or watching a movie, or had the room thermostat 
> turned up, or use Gnome 3, all beneath a gibbous moon.  All these 
> things, and many more, will cause builds to fail or succeed 
> ‘randomly’.

I actually have a 10GB sized swap file created on an SSD and
defined in the config.scm, but it didn't help. I'm also using Mate, but
I can try without any DE. The only two things running in the background
were Mate, mate terminal, Guix and %desktop-services.

> I personally think the annoyances of ‘helpful’ warnings 
> (=extremely inaccurate guesses) would far outweigh any purported 
> benefit.
> 
> Kind regards,
> 
> T G-R

Is there a way to skip building libreoffice, if the substitute isn't
available?

>Or just how quickly it can destroy an SSD.

Even more fun... Waiting for a powerful libre computer from from the
ground, because running on old ThinkPads forever isn't the right
solution.


Thanks for explanations and help,

Jan Wielkiewicz

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.