* Re: Small documentation improvements
2017-08-06 23:37 ` Martin H.
@ 2017-08-07 18:19 ` Leo Famulari
2017-08-21 15:29 ` Ludovic Courtès
1 sibling, 0 replies; 5+ messages in thread
From: Leo Famulari @ 2017-08-07 18:19 UTC (permalink / raw)
To: maze+guix; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 2753 bytes --]
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Small documentation improvements
2017-08-06 23:37 ` Martin H.
2017-08-07 18:19 ` Leo Famulari
@ 2017-08-21 15:29 ` Ludovic Courtès
1 sibling, 0 replies; 5+ messages in thread
From: Ludovic Courtès @ 2017-08-21 15:29 UTC (permalink / raw)
To: Martin H.; +Cc: guix-devel
Hi Martin,
"Martin H." <maze@strahlungsfrei.de> skribis:
> Am 2017-08-05 23:09, schrieb ludo@gnu.org:
>> Hi,
>>
>> "Martin H." <maze@strahlungsfrei.de> skribis:
>>
>>> I've pulled my hair out because I wasn't able to build any
>>> package. Turns out the following line at "Running Guix Before It Is
>>> Installed"
>>> (https://www.gnu.org/software/guix/manual/html_node/Running-Guix-Before-It-Is-Installed.html#Running-Guix-Before-It-Is-Installed):
>>>
>>> $ sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild
>>>
>>> should rather be
>>>
>>> $ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
>>>
>>> Otherwise the daemon won't have the GUILE_LOAD_PATH set correctly. At
>>> least when running this from a user checkout of Guix on a GuixSD
>>> system.
>>
>> Indeed. I made this change and added a note to explain. Thanks!
>
> 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.
Not sure what happened. Could it be that the daemon you run was using a
different localstatedir that the daemon you previously used? (See
<https://www.gnu.org/software/guix/manual/html_node/The-Store.html> and
<https://www.gnu.org/software/guix/manual/html_node/Requirements.html#Requirements>
for more on ‘localstatedir’.)
> 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).
Correct.
> 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?
No, that would be too inconvenient (you’d have to build everything from
source.)
./pre-inst-env creates an environment that talks to the daemon
listening to the socket in $localstatedir, so typically
/var/guix/daemon-socket/socket and /gnu/store.
Conversely, ./test-env spawns a new guix-daemon instance and everything
uses a separate store, by default under test-tmp/ in the build tree.
> So the documentation change should probably immediately be reverted.
Unless I’m missing something, I think it was fine.
> 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.
The “sudo -E” trick fixes the problem above for most people, because
people typically have GnuTLS in their load path already (or they would
be unable to run many guix commands.)
HTH,
Ludo’.
^ permalink raw reply [flat|nested] 5+ messages in thread