unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Stefan <stefan-guix@vodafonemail.de>
Cc: 44735@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	[thread overview]
Message-ID: <87r1onc6u6.fsf@gnu.org> (raw)
In-Reply-To: <78228B3F-FA9D-48C1-B70C-2F0B4CC65446@vodafonemail.de> (Stefan's message of "Fri, 20 Nov 2020 15:35:26 +0100")

Hi Stefan,

Stefan <stefan-guix@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’.




      reply	other threads:[~2020-11-21 11:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-19  8:03 bug#44735: gilbc of the running system got wiped while building a package, system broken Stefan
2020-11-19  8:29 ` Stefan Kuhr
2020-11-19 11:45   ` Stefan
2020-11-19 13:55     ` Stefan
2020-11-20 11:31       ` Ludovic Courtès
2020-11-20 14:35         ` Stefan
2020-11-21 11:00           ` Ludovic Courtès [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r1onc6u6.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=44735@debbugs.gnu.org \
    --cc=stefan-guix@vodafonemail.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).