Small documentation improvements

Small documentation improvements

[Martin H.]

Hi,

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.

Best
Martin

Re: Small documentation improvements

[Ludovic Courtès]

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!

Ludo’.

Re: Small documentation improvements

[Martin H.]

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.

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?

So the documentation change should probably immediately be reverted.

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.


Best
Martin

Re: Small documentation improvements

[Leo Famulari]

[-- 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 --]

Re: Small documentation improvements

[Ludovic Courtès]

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’.