Re: error: corrupt input while restoring archive from socket

[Mikhail Kryshen]

Mikhail Kryshen  writes:

> Mikhail Kryshen  writes:
>
>> Fulbert  writes:
>>
>>> Hello Guixers,
>>>
>>> For the past few days… maybe a couple of weeks (not sure when
>>> it started exactly), I have had frequent errors with
>>> substitutions. Those errors are not [always] reproducible as
>>> another [or more] installation attempt succeed on the same [set of]
>>> file[s].
>>>
>>> My computers (hardware/software) does not seem to be the
>>> cause as I have experienced the same problem on 2 PC's (not
>>> sharing the exact same guix configurations).
>>>
>>> Attached, 2 files with such an error. Note that I have
>>> translated the messages back to english (from french)… just in
>>> case you find some typos and wonder how guix could mistype… ^^
>>>
>>> The error message common to all those recent failures is :
>>>   error: corrupt input while restoring archive from socket
>>
>> I'm seeing this too, but only when guix tries to download from my own
>> local substitute server, which runs current guix-publish exposed
>> directly to the network without reverse proxy.
>
> I experimented for a bit with my substitute server and noticed that
> downloads fail only when compressed substitutes are not yet available in
> the guix publish cache or if caching is disabled.  This is likely a bug
> in Guix.

After further experimentation, this does not appear to be related to
caching.  When guix tries to download more than one substitute from my
server, it fails on the second download.

>> Downloading from
>> ci.guix.gnu.org works without errors.  Could this be a race condition
>> related to download rate?
>>
>>> Any idea ? I have not found any recent similar issue on
>>> issues.guix.gnu.org.
>>> downloading from 
>>> https://ci.guix.gnu.org/nar/gzip/qd16lz61f4gn20456h4ri0xb59dfh8kg-cmdliner-1.0.3.tbz...
>>>  cmdliner-1.0.3.tbz  48KiB20.4MiB/s 00:00 [##] 100.0%
>>>
>>> Backtrace:
>>> In guix/ui.scm:
>>>   2164:12 19 (run-guix-command _ . _)
>>> In guix/scripts/substitute.scm:
>>> 633:2 18 (guix-substitute . _)
>>> In unknown file:
>>>   17 (with-continuation-barrier #)
>>> In ice-9/boot-9.scm:
>>>   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
>>> In unknown file:
>>>   15 (apply-smob/0 #)
>>> In ice-9/boot-9.scm:
>>>   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
>>>   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
>>>   1731:15 12 (with-exception-handler # …)
>>> In guix/scripts/substitute.scm:
>>>682:17 11 (_)
>>> 391:7 10 (process-substitution _ "/gnu/store/p0xh0m6xkqfapgv7cy…" …)
>>> In ice-9/boot-9.scm:
>>>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
>>> In guix/scripts/substitute.scm:
>>> 400:9  8 (_)
>>> In ice-9/boot-9.scm:
>>>   1731:15  7 (with-exception-handler # …)
>>>   1669:16  6 (raise-exception _ #:continuable? _)
>>>   1667:16  5 (raise-exception _ #:continuable? _)
>>>   1669:16  4 (raise-exception _ #:continuable? _)
>>>   1764:13  3 (_ #< components: (#<> #<…>)
>>>   1669:16  2 (raise-exception _ #:continuable? _)
>>>   1667:16  1 (raise-exception _ #:continuable? _)
>>>   1669:16  0 (raise-exception _ #:continuable? _)
>>>
>>> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
>>> Bad http-version header component: ¡_¨””8ᗯñÿ
>>>
>>> Backtrace:
>>> In ice-9/boot-9.scm:
>>>   1736:10  4 (with-exception-handler _ _ #:unwind? _ # _)
>>> In unknown file:
>>>3 (apply-smob/0 #)
>>> In ice-9/boot-9.scm:
>>> 718:2  2 (call-with-prompt _ _ #)
>>> In ice-9/eval.scm:
>>> 619:8  1 (_ #(#(#)))
>>> In guix/ui.scm:
>>>   2164:12  0 (run-guix-command _ . _)
>>>
>>> guix/ui.scm:2164:12: In procedure run-guix-command:
>>> Bad http-version header component: ¡_¨””8ᗯñÿ
>>>
>>> substitution of /gnu/store/p0xh0m6xkqfapgv7cy9012mjf2rx720r-cudf-0.9.tar.gz 
>>> failed 
>>> guix package: error: corrupt input while restoring archive from socket
>>> downloading from 
>>> https://ci.guix.gnu.org/nar/lzip/wa2p58gv8fp81dglysnp2c9bffpdcwsr-ghc-blaze-markup-0.8.2.3...
>>>  ghc-blaze-markup-0.8.2.3  124KiB   
>>>  1.4MiB/s 

Re: error: corrupt input while restoring archive from socket

[Mikhail Kryshen]

Mikhail Kryshen  writes:

> Fulbert  writes:
>
>> Hello Guixers,
>>
>> For the past few days… maybe a couple of weeks (not sure when
>> it started exactly), I have had frequent errors with
>> substitutions. Those errors are not [always] reproducible as
>> another [or more] installation attempt succeed on the same [set of]
>> file[s].
>>
>> My computers (hardware/software) does not seem to be the
>> cause as I have experienced the same problem on 2 PC's (not
>> sharing the exact same guix configurations).
>>
>> Attached, 2 files with such an error. Note that I have
>> translated the messages back to english (from french)… just in
>> case you find some typos and wonder how guix could mistype… ^^
>>
>> The error message common to all those recent failures is :
>>   error: corrupt input while restoring archive from socket
>
> I'm seeing this too, but only when guix tries to download from my own
> local substitute server, which runs current guix-publish exposed
> directly to the network without reverse proxy.

I experimented for a bit with my substitute server and noticed that
downloads fail only when compressed substitutes are not yet available in
the guix publish cache or if caching is disabled.  This is likely a bug
in Guix.

> Downloading from
> ci.guix.gnu.org works without errors.  Could this be a race condition
> related to download rate?
>
>> Any idea ? I have not found any recent similar issue on
>> issues.guix.gnu.org.
>> downloading from 
>> https://ci.guix.gnu.org/nar/gzip/qd16lz61f4gn20456h4ri0xb59dfh8kg-cmdliner-1.0.3.tbz...
>>  cmdliner-1.0.3.tbz  48KiB20.4MiB/s 00:00 [##] 100.0%
>>
>> Backtrace:
>> In guix/ui.scm:
>>   2164:12 19 (run-guix-command _ . _)
>> In guix/scripts/substitute.scm:
>> 633:2 18 (guix-substitute . _)
>> In unknown file:
>>   17 (with-continuation-barrier #)
>> In ice-9/boot-9.scm:
>>   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
>> In unknown file:
>>   15 (apply-smob/0 #)
>> In ice-9/boot-9.scm:
>>   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
>>   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
>>   1731:15 12 (with-exception-handler # …)
>> In guix/scripts/substitute.scm:
>>682:17 11 (_)
>> 391:7 10 (process-substitution _ "/gnu/store/p0xh0m6xkqfapgv7cy…" …)
>> In ice-9/boot-9.scm:
>>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
>> In guix/scripts/substitute.scm:
>> 400:9  8 (_)
>> In ice-9/boot-9.scm:
>>   1731:15  7 (with-exception-handler # …)
>>   1669:16  6 (raise-exception _ #:continuable? _)
>>   1667:16  5 (raise-exception _ #:continuable? _)
>>   1669:16  4 (raise-exception _ #:continuable? _)
>>   1764:13  3 (_ #< components: (#<> #<…>)
>>   1669:16  2 (raise-exception _ #:continuable? _)
>>   1667:16  1 (raise-exception _ #:continuable? _)
>>   1669:16  0 (raise-exception _ #:continuable? _)
>>
>> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
>> Bad http-version header component: ¡_¨””8ᗯñÿ
>>
>> Backtrace:
>> In ice-9/boot-9.scm:
>>   1736:10  4 (with-exception-handler _ _ #:unwind? _ # _)
>> In unknown file:
>>3 (apply-smob/0 #)
>> In ice-9/boot-9.scm:
>> 718:2  2 (call-with-prompt _ _ #)
>> In ice-9/eval.scm:
>> 619:8  1 (_ #(#(#)))
>> In guix/ui.scm:
>>   2164:12  0 (run-guix-command _ . _)
>>
>> guix/ui.scm:2164:12: In procedure run-guix-command:
>> Bad http-version header component: ¡_¨””8ᗯñÿ
>>
>> substitution of /gnu/store/p0xh0m6xkqfapgv7cy9012mjf2rx720r-cudf-0.9.tar.gz 
>> failed 
>> guix package: error: corrupt input while restoring archive from socket
>> downloading from 
>> https://ci.guix.gnu.org/nar/lzip/wa2p58gv8fp81dglysnp2c9bffpdcwsr-ghc-blaze-markup-0.8.2.3...
>>  ghc-blaze-markup-0.8.2.3  124KiB
>> 1.4MiB/s 00:00 [##] 100.0%
>>
>> Backtrace:
>> In guix/ui.scm:
>>   2164:12 19 (run-guix-command _ . _)
>> In guix/scripts/substitute.scm:
>> 633:2 18 (guix-substitute . _)
>> In unknown file:
>>   17 (with-continuation-barrier #)
>> In ice-9/boot-9.scm:
>>   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
>> In unknown file:
>>   15 (apply-smob/0 #)
>> In ice-9/boot-9.scm:
>>   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
>>   1736:10 13 (with-exception-handler _

Re: error: corrupt input while restoring archive from socket

[Mikhail Kryshen]

Fulbert  writes:

> Le Thu, Mar 11, 2021 at 04:59:42PM +0300, Mikhail Kryshen a écrit :
>> Fulbert  writes:
>> 
>> > Hello Guixers,
>> >
>> > For the past few days… maybe a couple of weeks (not sure when
>> > it started exactly), I have had frequent errors with
>> > substitutions. Those errors are not [always] reproducible as
>> > another [or more] installation attempt succeed on the same [set of]
>> > file[s].
>> >
>> > My computers (hardware/software) does not seem to be the
>> > cause as I have experienced the same problem on 2 PC's (not
>> > sharing the exact same guix configurations).
>> >
>> > Attached, 2 files with such an error. Note that I have
>> > translated the messages back to english (from french)… just in
>> > case you find some typos and wonder how guix could mistype… ^^
>> >
>> > The error message common to all those recent failures is :
>> >   error: corrupt input while restoring archive from socket
>> 
>> I'm seeing this too, but only when guix tries to download from my own
>> local substitute server, which runs current guix-publish exposed
>> directly to the network without reverse proxy.  Downloading from
>> ci.guix.gnu.org works without errors.  Could this be a race condition
>> related to download rate?
>
> Hello and thanks for your time Mikhail,
>
> I only have a local channel with a couple of local files but no
> subtitute server. All downloads go through ci.gui.gnu.org.
>
>> Downloading from ci.guix.gnu.org works without errors.  Could
>> this be a race condition related to download rate?
>
> I don't know. I'm not even sure what it means and how I could
> check that. Wouldn't this kind of problem be handled on the
> network "layers" ?… Because, as stated, I have not experienced
> other problems besides guix substitutions, whether guix related or
> any other use as a connected "desktop" user.

Ah, sorry for the confusion, my question was meant as a
speculation/suggestion to the Guix developers.

>> > Any idea ? I have not found any recent similar issue on
>> > issues.guix.gnu.org.
>> > downloading from 
>> > https://ci.guix.gnu.org/nar/gzip/qd16lz61f4gn20456h4ri0xb59dfh8kg-cmdliner-1.0.3.tbz...
>> >  cmdliner-1.0.3.tbz  48KiB20.4MiB/s 00:00 [##] 100.0%
>> >
>> > Backtrace:
>> > In guix/ui.scm:
>> >   2164:12 19 (run-guix-command _ . _)
>> > In guix/scripts/substitute.scm:
>> > 633:2 18 (guix-substitute . _)
>> > In unknown file:
>> >   17 (with-continuation-barrier #)
>> > In ice-9/boot-9.scm:
>> >   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
>> > In unknown file:
>> >   15 (apply-smob/0 #)
>> > In ice-9/boot-9.scm:
>> >   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
>> >   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
>> >   1731:15 12 (with-exception-handler # …)
>> > In guix/scripts/substitute.scm:
>> >682:17 11 (_)
>> > 391:7 10 (process-substitution _ "/gnu/store/p0xh0m6xkqfapgv7cy…" …)
>> > In ice-9/boot-9.scm:
>> >   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
>> > In guix/scripts/substitute.scm:
>> > 400:9  8 (_)
>> > In ice-9/boot-9.scm:
>> >   1731:15  7 (with-exception-handler # …)
>> >   1669:16  6 (raise-exception _ #:continuable? _)
>> >   1667:16  5 (raise-exception _ #:continuable? _)
>> >   1669:16  4 (raise-exception _ #:continuable? _)
>> >   1764:13  3 (_ #< components: (#<> #<…>)
>> >   1669:16  2 (raise-exception _ #:continuable? _)
>> >   1667:16  1 (raise-exception _ #:continuable? _)
>> >   1669:16  0 (raise-exception _ #:continuable? _)
>> >
>> > ice-9/boot-9.scm:1669:16: In procedure raise-exception:
>> > Bad http-version header component: ¡_¨””8ᗯñÿ
>> >
>> > Backtrace:
>> > In ice-9/boot-9.scm:
>> >   1736:10  4 (with-exception-handler _ _ #:unwind? _ # _)
>> > In unknown file:
>> >3 (apply-smob/0 #)
>> > In ice-9/boot-9.scm:
>> > 718:2  2 (call-with-prompt _ _ #)
>> > In ice-9/eval.scm:
>> > 619:8  1 (_ #(#(#)))
>> > In guix/ui.scm:
>> >   2164:12  0 (run-guix-command _ . _)
>> >
>> > guix/ui.scm:2164:12: In procedure run-guix-command:
>> > Bad http-version header component: ¡_¨””8ᗯñÿ
>> >
>> > substitution of 
>> >

Re: error: corrupt input while restoring archive from socket

[Mikhail Kryshen]

Fulbert  writes:

> Hello Guixers,
>
> For the past few days… maybe a couple of weeks (not sure when
> it started exactly), I have had frequent errors with
> substitutions. Those errors are not [always] reproducible as
> another [or more] installation attempt succeed on the same [set of]
> file[s].
>
> My computers (hardware/software) does not seem to be the
> cause as I have experienced the same problem on 2 PC's (not
> sharing the exact same guix configurations).
>
> Attached, 2 files with such an error. Note that I have
> translated the messages back to english (from french)… just in
> case you find some typos and wonder how guix could mistype… ^^
>
> The error message common to all those recent failures is :
>   error: corrupt input while restoring archive from socket

I'm seeing this too, but only when guix tries to download from my own
local substitute server, which runs current guix-publish exposed
directly to the network without reverse proxy.  Downloading from
ci.guix.gnu.org works without errors.  Could this be a race condition
related to download rate?

> Any idea ? I have not found any recent similar issue on
> issues.guix.gnu.org.
> downloading from 
> https://ci.guix.gnu.org/nar/gzip/qd16lz61f4gn20456h4ri0xb59dfh8kg-cmdliner-1.0.3.tbz...
>  cmdliner-1.0.3.tbz  48KiB20.4MiB/s 00:00 [##] 100.0%
>
> Backtrace:
> In guix/ui.scm:
>   2164:12 19 (run-guix-command _ . _)
> In guix/scripts/substitute.scm:
> 633:2 18 (guix-substitute . _)
> In unknown file:
>   17 (with-continuation-barrier #)
> In ice-9/boot-9.scm:
>   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>   15 (apply-smob/0 #)
> In ice-9/boot-9.scm:
>   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
>   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
>   1731:15 12 (with-exception-handler # …)
> In guix/scripts/substitute.scm:
>682:17 11 (_)
> 391:7 10 (process-substitution _ "/gnu/store/p0xh0m6xkqfapgv7cy…" …)
> In ice-9/boot-9.scm:
>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/scripts/substitute.scm:
> 400:9  8 (_)
> In ice-9/boot-9.scm:
>   1731:15  7 (with-exception-handler # …)
>   1669:16  6 (raise-exception _ #:continuable? _)
>   1667:16  5 (raise-exception _ #:continuable? _)
>   1669:16  4 (raise-exception _ #:continuable? _)
>   1764:13  3 (_ #< components: (#<> #<…>)
>   1669:16  2 (raise-exception _ #:continuable? _)
>   1667:16  1 (raise-exception _ #:continuable? _)
>   1669:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Bad http-version header component: ¡_¨””8ᗯñÿ
>
> Backtrace:
> In ice-9/boot-9.scm:
>   1736:10  4 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>3 (apply-smob/0 #)
> In ice-9/boot-9.scm:
> 718:2  2 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
> 619:8  1 (_ #(#(#)))
> In guix/ui.scm:
>   2164:12  0 (run-guix-command _ . _)
>
> guix/ui.scm:2164:12: In procedure run-guix-command:
> Bad http-version header component: ¡_¨””8ᗯñÿ
>
> substitution of /gnu/store/p0xh0m6xkqfapgv7cy9012mjf2rx720r-cudf-0.9.tar.gz 
> failed 
> guix package: error: corrupt input while restoring archive from socket
> downloading from 
> https://ci.guix.gnu.org/nar/lzip/wa2p58gv8fp81dglysnp2c9bffpdcwsr-ghc-blaze-markup-0.8.2.3...
>  ghc-blaze-markup-0.8.2.3  124KiB 
>1.4MiB/s 00:00 [##] 100.0%
>
> Backtrace:
> In guix/ui.scm:
>   2164:12 19 (run-guix-command _ . _)
> In guix/scripts/substitute.scm:
> 633:2 18 (guix-substitute . _)
> In unknown file:
>   17 (with-continuation-barrier #)
> In ice-9/boot-9.scm:
>   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>   15 (apply-smob/0 #)
> In ice-9/boot-9.scm:
>   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
>   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
>   1731:15 12 (with-exception-handler # …)
> In guix/scripts/substitute.scm:
>682:17 11 (_)
> 391:7 10 (process-substitution _ "/gnu/store/gs7l81p1xzgdzvxdjc…" …)
> In ice-9/boot-9.scm:
>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/scripts/substitute.scm:
> 400:9  8 (_)
> In ice-9/boot-9.scm:
>   1731:15  7 (with-exception-handler # …)
>   1669:16  6 (raise-exception _ #:continuable? _)
>   1667:16  5 (raise-exception _ #:continuable? _)
>   1669:16  4 (raise-exception _ #:continuable? _)
>   1764:13  3 (_ #< components: (#<> #<…>)
>   1669:16  2 (raise-exception _ #:continuable? _)
>   1667:16  1 (raise-exception _ #:continuable? _)
>   1669:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Bad Read-Header-Line header: #
>
> Backtrace:
> In ice-9/boot-9.scm:
>   1736:10  4 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>3 (apply-smob/0 #)
> In 

Re: Report on environment variable issues

[Mikhail Kryshen]

Tirifto  writes:

> After some investigation, it turned out that GNOME Shell falls back on
> a certain default value when the variable is empty, which already
> contains paths that GNOME Shell needs to function properly. So when the
> user extends the existing value of ‘$XDG_DATA_DIRS’ with another path,
> the variable is no longer empty, so GNOME Shell never gets to fall back
> to the paths it actually needs, and crashes instead.

GNOME does this in accordance with XDG Base Directory Specification, see
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

  "If $XDG_DATA_DIRS is either not set or empty, a value equal to
  /usr/local/share/:/usr/share/ should be used."

-- 
Mikhail


signature.asc
Description: PGP signature

Re: Problem using multiple manifest files

[Mikhail Kryshen]

Chris Marusich  writes:

> Mikhail Kryshen  writes:
>
>> (use-modules (srfi srfi-1)
>>  ((guix ui) #:select (make-user-module)))
>>
>> (define (load-manifest file)
>>   ;; Load manifest file in a fresh module with necessary imports.
>>   (let ((module (make-user-module '((guix profiles) (gnu)
>> (save-module-excursion
>>  (lambda _
>>(set-current-module module)
>>(load (canonicalize-path file))
>
> Neat example!

Thanks! 

> But what is make-user-module doing, and is it necessary?

I looked into the Guix source and reproduced what "guix package -m" does
to load a manifest file.  Make-user-module procedure appear to be used
in Guix to dynamically create modules for running user code.  I could
have simply used "load" here, but then all the files would be loaded in
the same environment and could potentially interfere with each other.

-- 
Mikhail


signature.asc
Description: PGP signature

Re: Problem using multiple manifest files

[Mikhail Kryshen]

Thaddäus Töppen  writes:
> Am I correct in assuming, that only one manifest file can be installed at a
> time, thus all package definitions have to be in one file (or at least
> imported into a main-package-file)?

Yes, but since manifest file is a Guile program, you can implement any
custom logic for constructing the manifest there.

Here is an example of a manifest file that loads multiple manifests and
composes them into one:

--
(use-modules (srfi srfi-1)
 ((guix ui) #:select (make-user-module)))

(define (load-manifest file)
  ;; Load manifest file in a fresh module with necessary imports.
  (let ((module (make-user-module '((guix profiles) (gnu)
(save-module-excursion
 (lambda _
   (set-current-module module)
   (load (canonicalize-path file))

(define (combined-manifest-from-files . files)
  (fold (lambda (file combined)
  (manifest-add combined
(manifest-entries (load-manifest file
(manifest '())
files))

(combined-manifest-from-files
 "emacs.scm"
 "xorg.scm"
 "etc.scm")
--

-- 
Mikhail


signature.asc
Description: PGP signature

Store on NFS (was Re: ~/.config/guix/current)

[Mikhail Kryshen]

Ludovic Courtès  writes:

> Oh right, I thought you were referring to the configuration of the
> master node.

Concerning the master node, is there a way to specify NFS exports in
GuixSD OS configuration?

> The compute nodes would need to be able to mount /gnu/store early at
> boot over NFS, and I think that’s doesn’t work right now on GuixSD.
> I’m not sure exactly what’s missing.

I see in grub.cfg, that the kernel and initrd are loaded from the store,
so it must be available to the bootloader.  Would it be possible to
combine local and remote stores after boot with overlayfs and ensure
that all necessary items are written to the local store at "system
reconfigure" (maybe have a local guix daemon manage the local store for
"system reconfigure")?

-- 
Mikhail


signature.asc
Description: PGP signature

Re: ~/.config/guix/current

[Mikhail Kryshen]

Ludovic Courtès  writes:

>> Btw, is option a) possible on GuixSD?
>
> I think so.  Why wouldn’t it?

It looks like /gnu/store is needed early to boot the system.

Can you hint on how to configure GuixSD with /gnu/store on NFS?

> Yes, we use option a) on a cluster at Inria (and Roel and Ricardo have a
> similar setup at their institutes), and it works pretty well.
>
> From a performance viewpoint, it’s important for the master node to have
> the store on a local file system, so that things like GC and
> deduplication run quickly enough—these would be slow over NFS.  For the
> compute nodes, accessing packages over NFS is good enough.

Thanks!  I think I'll try to experiment with a) a bit first.

-- 
Mikhail


signature.asc
Description: PGP signature

Re: ~/.config/guix/current

[Mikhail Kryshen]

Ludovic Courtès  writes:

>> a) master node running guix-daemon [1]
>>- will "guix gc" destroy guix/current profiles if /home is not
>>mounted on the master node?  What if some users have local
>>home directories and some are on nfs?
>
>> [1] 
>> https://guix-hpc.bordeaux.inria.fr/blog/2017/11/installing-guix-on-a-cluster/
>
> This is what I would recommend, and as the post suggests, you’ll have to
> make sure home directories are visible to guix-daemon, which means
> having them mounted on the master node.
>
> If you don’t do that, there’s a risk that user-pulled Guixes will be
> reclaimed prematurely, simply because the GC won’t see that they are
> still “live.”

But ~root is local on each machine, so root-pulled Guix will still not
be protected from gc.

Btw, is option a) possible on GuixSD?


>> b) guix-daemon on every computer
>>- then /gnu/store and /var/guix/profiles will by local and user
>>profiles can be different on every computer, but
>>~/.config/guix/current will link to nonexistent store item if
>>"guix pull" was invoked by the same user on a different machine.
>
> If this is a cluster, I would definitely recommend option a), which
> provides a single world view, shared storage, etc.

It's for GNU/Linux workstations in university labs.  I want to use Guix
to provide additional software that is not available in required
configuration in the host distro, and also give students an interesting
environment to experiment.

I decided for now to go with the option b) for performance and
reliability.  My previous attempts to deploy large software packages on
NFS (even with FS-Cache enabled) didn't work well.  Also, it may be
possible to somehow exploit immutability of the store items to share and
cache them more efficiently.

The computers periodically run "guix pull" as root and I want to make
the updated Guix automatically available to all users, but
/usr/local/bin/guix can't be linked to
/root/.config/guix/current/bin/guix as the /root directory is normally
not searchable by other users — another reason to keep pulled Guix
profiles in /var.  I workaround this by having the script that runs
"guix pull" to symlink /usr/local/bin/guix directly into the new profile
in /gnu/store.


> I agree it would be useful (the way we do it on GuixSD is by having
> /etc/profile define INFOPATH systematically, for instance), but there’s
> no clear way to have ~/.config/guix/current/etc/profile define them
> directly.

It would be useful to have a similar script included in the guix package
to be symlinked into host distro's /etc/profile.d

Thank you, 
Mikhail


signature.asc
Description: PGP signature

~/.config/guix/current

[Mikhail Kryshen]

Hi,

Is there some reason why "guix pull" keeps profile symlinks in
~/.config/guix instead of under /var/guix/profiles?

I'm looking into installing Guix on multiple computers with shared user
accounts and /home on NFS.  So far the possibilities seem to be:

a) master node running guix-daemon [1]
   - will "guix gc" destroy guix/current profiles if /home is not
   mounted on the master node?  What if some users have local
   home directories and some are on nfs?
   
b) guix-daemon on every computer
   - then /gnu/store and /var/guix/profiles will by local and user
   profiles can be different on every computer, but
   ~/.config/guix/current will link to nonexistent store item if
   "guix pull" was invoked by the same user on a different machine.

Can/should this be fixed?

Another question is why ~/.config/guix/current/etc/profile does not
define all necessary environment variables (PATH is there, but no
INFOPATH, GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH)?  It would be
convenient to source it in .bash_profile the same way as normal
guix-profile instead of defining all necessary variables explicitly.

[1] 
https://guix-hpc.bordeaux.inria.fr/blog/2017/11/installing-guix-on-a-cluster/

-- 
Mikhail


signature.asc
Description: PGP signature

Re: Application Setup on Trisquel

[Mikhail Kryshen]

Ludovic Courtès  writes:

>> Is there a way to make Trisquel's GNOME and its main menu aware of
>> programs installed with Guix?
>
> It should be possible, but I don’t know how.  Anyone?

I don't use Trisquel, but this works for GNOME in Fedora:

  ln -s ~/.guix-profile/share/applications ~/.local/share/applications/guix

You might also want to copy or symlink application icons from
~/.guix-profile/share/icons to ~/.local/share/icons
(don't know how to make them visible to GNOME with a single symlink)

-- 
Mikhail


signature.asc
Description: PGP signature