guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Small documentation improvements


From: Leo Famulari
Subject: Re: Small documentation improvements
Date: Mon, 7 Aug 2017 14:19:26 -0400
User-agent: Mutt/1.8.3 (2017-05-23)

On Mon, Aug 07, 2017 at 01:37:16AM +0200, Martin H. wrote:
> Actually, it seems this change was totally wrong and broke my system. At
> least that's what happened: I didn't really realize it immediately, but
> after this change and the first successful package compile inside my guix
> checkout I ended up with broken links to libgcc and libstd++. That means I
> couldn't run any command anymore. I had to boot a live cd and fix those
> problems manually the hard way in order to get the system to boot again.

Yikes! I've reverted the change while we investigate.

> The "sudo -E" makes GUILE_LOAD_PATH contain the paths of the development
> guix instance *in addition* to the paths of the system instance (in
> /run/current-system). As far as I understand, that then means two guix
> daemons with different packages sources are partially operating on the same
> store directories. The development checkout should rather only use its own
> store directory, right? Can anyone clear up how it is supposed to work?

When using Guix from the development checkout with the 'pre-inst-env'
script, you can share the store and database if you pass
'--localstatedir=/var' to ./configure, assuming you are using the
default location of the local state directory.

I figure it should be safe to run multiple daemons on the same store as
long as they share the database, but I'm not 100% sure.

However, it's generally not necessary to run a guix-daemon from the
source checkout unless you are testing changes to the daemon, or the
source checkout and the GuixSD-provided guix-daemon are of wildly
different versions of Guix.

> The reason I tried this change in the first place was that each `guix build`
> call ends up with the following error, when the daemon is not started with
> "sudo -E":
> 
> > substitute: ;;; Failed to autoload make-session in (gnutls):
> > substitute: ;;; ERROR: missing interface for module (gnutls)
> > substitute: Backtrace:
> > substitute:            1 (primitive-load
> > "/home/martin/git/guix/scripts/guix")
> > substitute: In guix/ui.scm:
> > substitute:   1331:12  0 (run-guix-command _ . _)
> > substitute:
> > substitute: guix/ui.scm:1331:12: In procedure run-guix-command:
> > substitute: guix/ui.scm:1331:12: In procedure module-lookup: Unbound
> > variable: make-session
> > guix build: error: corrupt input while restoring archive from #<closed:
> > file 1fe3d90>
> 
> There probably has to be a different solution to this problem. I found
> recent threads with similar problems, but this seems to be different.

Those errors indicate that Guix could not find the Guile bindings of
GnuTLS. They can be made available with `guix environment --ad-hoc
guile2.2-gnutls`.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]