GNU bug report logs - #44735
gilbc of the running system got wiped while building a package, system broken

Previous Next

Package: guix;

Reported by: Stefan <stefan-guix <at> vodafonemail.de>

Date: Thu, 19 Nov 2020 08:04:02 UTC

Severity: normal

Tags: notabug

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Stefan <stefan-guix <at> vodafonemail.de>
Cc: 44735 <at> debbugs.gnu.org
Subject: bug#44735: gilbc of the running system got wiped while building a package, system broken
Date: Sat, 21 Nov 2020 12:00:49 +0100
Hi Stefan,

Stefan <stefan-guix <at> vodafonemail.de> skribis:

> That doesn’t seem to be so bad. :-)

Heh, good.

>> ./configure warns or errors out and the manual warns in a couple of
>> places too, but evidently it remains too easy to shoot oneself in the
>> foot.
>
> It warns in the chapter “2 Requirements”. It doesn’t warn in chapter ”14.1 Building from Git”.
>
> Anyway, it was just a typo. Even if I would have known about that warning, this would have happened. 

Yeah, we could always duplicate the warning in the manual, but it can
still be overlooked.

> checking the current installation's localstatedir... /var
> configure: WARNING: chosen localstatedir '/vaar' does not match that of the existing installation '/var'
> configure: WARNING: installing may corrupt /gnu/store!

[...]

> Indeed, there in all that pages of output, luckily on the last page, there is a warning. I could have noticed it. But I did’t. Red colour could have helped. :-)

Heh OK.  At least it’s there.  :-)

Note that it would have been an error if you had not passed an explicit
‘--localstatedir’ (see guix.m4).  The assumption here is that, since you
explicitly passed ‘--localstatedir’, you “know what you’re doing”, hence
a mere warning.

>> Also, why did you run guix-daemon from your checkout?  This is only
>> necessary if you’re actually hacking on the daemon, but perhaps the
>> manual is misleading.  (Hadn’t you run guix-daemon from the checkout,
>> the problem would not have occurred, even with a wrong
>> ‘--localstatedir’.)
>
> I was trying to add a build side module into guix/build. This failed all the time with an error “no code for module”. As neither #:modules nor #:imported-modules are documented (see also http://debbugs.gnu.org/cgi/bugreport.cgi?bug=44758), I was a bit clueless. Then I found out, that I have to add the module into Makefile.am and have to run configure. And there the typo happened. But still this was’t working and I thought that I may need to start the daemon with pre-inst-env to have the GUILE_LOAD_PATH properly point to guix/build. Well, and so the disaster happened.

OK.  You definitely do not need to run guix-daemon from the checkout
to test this kind of changes.

Commit 9022861dc028e99fab930721fe991a682c497bbb clarified that
guix-daemon does not have to be launched from the checkout, but if you
can think of other places that need clarification, please let me know!

In the meantime, I’m closing this issue.  Glad you recovered your store!

Thanks,
Ludo’.




This bug report was last modified 4 years and 217 days ago.

Previous Next


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