From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marco van Hulten Subject: Re: successful installation, but problems updating Date: Sat, 11 Nov 2017 23:23:00 +0100 Message-ID: <20171111232300.513d67fb@graviton.instanton> References: <20171106091656.6e775deb@graviton.instanton> <87vainu4h3.fsf@zancanaro.id.au> <20171106210540.0271775c@jasniac.instanton> <87tvy6bg2y.fsf@gnu.org> <20171108023730.6756d899@jasniac.instanton> <877euzio7k.fsf@gnu.org> <20171109202737.19fd288b@jasniac.instanton> <20171109214624.2cc2d152@jasniac.instanton> <87efp7maw8.fsf@gmail.com> <20171110082612.502198ae@jasniac.instanton> <20171110163539.GB11031@jasmine.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Er46RPFrkEi=MK1.FHBYsnz"; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDeBG-0003eU-0A for help-guix@gnu.org; Sat, 11 Nov 2017 17:23:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDeBB-00029v-2q for help-guix@gnu.org; Sat, 11 Nov 2017 17:23:13 -0500 Received: from eterpe-smout.broadpark.no ([80.202.8.16]:48013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDeBA-00029Q-Ro for help-guix@gnu.org; Sat, 11 Nov 2017 17:23:09 -0500 Received: from bgo1cloudm2.nextgentel.net ([80.202.8.59]) by eterpe-smout.broadpark.no (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTP id <0OZ900BT8Y62TS30@eterpe-smout.broadpark.no> for help-guix@gnu.org; Sat, 11 Nov 2017 23:23:08 +0100 (CET) In-reply-to: <20171110163539.GB11031@jasmine.lan> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Leo Famulari Cc: help-guix@gnu.org --Sig_/Er46RPFrkEi=MK1.FHBYsnz Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Leo- Op 10 nov 11:35 schreef Leo Famulari: > On Fri, Nov 10, 2017 at 08:26:12AM +0100, Marco van Hulten wrote: > > kodi@watson ~$ time guix pull --cores=3D1 =20 >=20 > [...] >=20 > > compiling... 75.4% of 647 filesbuilding of `/gnu/store/gk5chb0dwpsq3na= 7b4gn1hd7h0h2b63h-guix-latest.drv' timed out after 3600 seconds of silence = =20 >=20 > [...] >=20 > > real 609m30.245s > > user 0m3.125s > > sys 0m0.875s =20 >=20 > 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. Right now a `guix pull' results in a `dispatch-exception' in procedure `struct_vtable: Wrong type argument in position 1 (expecting struct): #'. 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. > Out of curiosity, what kind of machine are you using? A full hour with > no output at all indicates that something is happening very slowly! Is > it swapping? 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; =20 >=20 > Do you mean that the computer becomes unresponsive? Yes. > > What is Guix doing between 75.2 and 75.4 %? =20 >=20 > I don't know exactly, but during `guix pull` Guix is built from source > with the Guile compiler. >=20 > There are some bugs in the current version of the Guile compiler that > cause it to require way more memory than expected. This is terrible on > memory-constrained systems because it forces the use of swap, which is > typically super slow. Hopefully we can deploy a fix soon. Is 2 GiB considered "memory-constrained"? -Marco --Sig_/Er46RPFrkEi=MK1.FHBYsnz Content-Type: application/pgp-signature Content-Description: OpenPGP digitale handtekening -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSduGbl1Xx4OBVOmG+kCiXhgsb+zAUCWgd4RAAKCRCkCiXhgsb+ zJ7NAJ9kPe7Cd6YxGPLvW1cgzPpjhlNGVQCgj/DXTwfhGpkJWzTkMMyeDcT61xM= =iVQj -----END PGP SIGNATURE----- --Sig_/Er46RPFrkEi=MK1.FHBYsnz--