Re: Small documentation improvements

[Ludovic Courtès]

Hi Martin,

"Martin H." <address@hidden> skribis:

> Am 2017-08-05 23:09, schrieb address@hidden:
>> Hi,
>>
>> "Martin H." <address@hidden> 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’.