successful installation, but problems updating

successful installation, but problems updating

[Marco van Hulten]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

Hello,

I installed GuixSD 0.13.0 with success!  But I still have a couple
of issues and questions concerning updating the system and installing
packages.  I followed the [installation guide][1].

[1]:
https://www.gnu.org/software/guix/manual/html_node/Proceeding-with-the-Installation.html


'guix pull' ends with a compilation error:

> guix pull: error: build failed: build of
> `/gnu/store/*-guix-latest.drv' failed


After this I should execute this command.

> $ guix system reconfigure
> guix system: error: wrong number of arguments for action 'reconfigure'

I expected this not to work properly anyway because 'guix pull' did not
succeed, but this seems like a syntax error that would have come up
also after a correct 'guix pull' (except, of course, if 'guix pull'
would provide files that account for the right number of arguments —
but I don't understand Guix well enough to make any good presumptions
about it).


Finally, have two more general questions (possibly related) about
Guix.

Firstly, it often says that I need to use '--fallback'.  Is that
because the binary is not available?

Secondly, I noted that with, e.g., 'guix package -i kodi' software gets
compiled.  I understood that GNU Guix is capable of both binary and
source packages.  Which should I typically expect?  Can I choose?


I attached my 'config.scm' (sadly, the paste.lisp.org service has just
been disabled).  This is what I understand as the single most important
configuration file of any GuixSD installation.

-Marco

[-- Attachment #2: config.scm --]
[-- Type: text/x-scheme, Size: 2237 bytes --]

;; This is an operating system configuration template
;; for a "desktop" setup.

(use-modules (gnu) (gnu system nss))
(use-service-modules desktop ssh)
(use-package-modules wm ratpoison certs suckless gnome)

(operating-system
  (host-name "watson")
  (timezone "Europe/Oslo")
  (locale "en_US.utf8")

  ;; Assuming /dev/sda is the target hard disk, and "my-root"
  ;; is the label of the target root file system.
  (bootloader (grub-configuration (device "/dev/sda")))

  (file-systems (cons* (file-system
                        (device "my-root")
                        (title 'label)
                        (mount-point "/")
                        (type "ext4"))
                      (file-system
                        (device "my-home")
                        (title 'label)
                        (mount-point "/home")
                        (type "ext4"))
                      %base-file-systems))

  (users (cons* (user-account
                (name "kodi")
                (comment "mediacenter")
                (group "users")
                (supplementary-groups '("wheel" "netdev"
                                        "audio" "video"))
                (home-directory "/home/kodi"))
               (user-account
                (name "marco")
                (comment "Marco van Hulten")
                (group "users")
                (supplementary-groups '("wheel" "netdev"
                                        "audio" "video"))
                (home-directory "/home/marco"))
               %base-user-accounts))

  ;; Add a bunch of window managers; we can choose one at
  ;; the log-in screen with F1.
  (packages (cons* ratpoison i3-wm i3status dmenu ;window managers
                   nss-certs                      ;for HTTPS access
                   gvfs              ;for user mounts
                   %base-packages))

  ;; Add GNOME and/or Xfce---we can choose at the log-in
  ;; screen with F1.  Use the "desktop" services, which
  ;; include the X11 log-in service, networking with Wicd,
  ;; and more.
  (services (cons* (xfce-desktop-service)
                   %desktop-services))

  ;; Allow resolution of '.local' host names with mDNS.
  (name-service-switch %mdns-host-lookup-nss))

Re: successful installation, but problems updating

[Carlo Zancanaro]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

Hello!

On Mon, Nov 06 2017, Marco van Hulten wrote:
> I installed GuixSD 0.13.0 with success!

Excellent! That's great to hear!

> 'guix pull' ends with a compilation error:
>
>> guix pull: error: build failed: build of
>> `/gnu/store/*-guix-latest.drv' failed

This isn't enough to tell me what's happened, unfortunately. I'm not
sure what the common failure cases are for this, but hopefully someone
else will know.

> After this I should execute this command.
>
>> $ guix system reconfigure
>> guix system: error: wrong number of arguments for action
>> 'reconfigure'

The reconfigure command requires you to pass it a configuration file
(ie. config.scm). You can see the details in the manual[1].

> Finally, have two more general questions (possibly related) about
> Guix.
>
> Firstly, it often says that I need to use '--fallback'.  Is that
> because the binary is not available?

I'm not sure the exact circumstances for when this is necessary, but it
is when there is some sort of a problem with the binary substitutes. The
manual[2] describes it as "When substituting a pre-built binary fails,
fall back to building packages locally."

> Secondly, I noted that with, e.g., 'guix package -i kodi' software gets
> compiled.  I understood that GNU Guix is capable of both binary and
> source packages.  Which should I typically expect?  Can I choose?

This depends on a few factors, but most particularly how up-to-date the
build farms are. I'm not sure what you should expect most of the time,
but I usually expect that I'll have to build at least something during
my installations.

You can use the "--no-substitutes" flag for most commands (which you can
read about in the manual[2]) if you'd like to build everything locally.

Carlo

[1]: https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-system.html
[2]: https://www.gnu.org/software/guix/manual/html_node/Common-Build-Options.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: successful installation, but problems updating

[Thomas Sigurdsen]

Hello, sadly I can't help with the guix pull error, don't know a lot
about it unfortunately. I do have some comments on the other questions.

On Mon, 06 Nov 2017 09:16:56 +0100
Marco van Hulten <marco@hulten.org> wrote:

> After this I should execute this command.
> 
> > $ guix system reconfigure
> > guix system: error: wrong number of arguments for action 'reconfigure'  
>

reconfigure (and some (maybe all?) of the other system commands) require a
config file. So 'guix system reconfigure /path/to/config.scm' should work.

> 
> I expected this not to work properly anyway because 'guix pull' did not
> succeed, but this seems like a syntax error that would have come up
> also after a correct 'guix pull' (except, of course, if 'guix pull'
> would provide files that account for the right number of arguments —
> but I don't understand Guix well enough to make any good presumptions
> about it).
> 
> 
> Finally, have two more general questions (possibly related) about
> Guix.
> 
> Firstly, it often says that I need to use '--fallback'.  Is that
> because the binary is not available?
>

'--fallback' means that guix will fall back to compiling from source if
it can't download binaries (also called substitutes). By default guix
tries to download substitutes from the build farm (hydra).

> 
> Secondly, I noted that with, e.g., 'guix package -i kodi' software gets
> compiled.  I understood that GNU Guix is capable of both binary and
> source packages.  Which should I typically expect?  Can I choose?
> 

It seems to me I usually get core and common packages as substitutes
(binaries). There is the ‘--no-substitutes’ command line flag to disable
substitutes and always build from source. I can't see a flag for
disabling source builds.

You'll find this information in the guix info pages, specifically under
"common build options" and "invoking guix system".

> -Marco

Thomas

Re: successful installation, but problems updating

[Marco van Hulten]

[-- Attachment #1: Type: text/plain, Size: 1917 bytes --]

Hello,

Thank you Carl and Thomas for the clear explanation.

Still one issue remains.

Op 06 nov 20:43 schreef Carlo Zancanaro:
> > 'guix pull' ends with a compilation error:
> >  
> >> guix pull: error: build failed: build of
> >> `/gnu/store/*-guix-latest.drv' failed  
> 
> This isn't enough to tell me what's happened, unfortunately. I'm not
> sure what the common failure cases are for this, but hopefully someone
> else will know.

This was a bit meager description.  This is the full output on the
terminal:

```
root@watson ~# guix pull

Starting download of /tmp/guix-file.F5p3in
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 ….tar.gz                                   2.3MiB/s 00:06 | 13.8MiB transferred
unpacking '/gnu/store/5qcf02fjmi4y4chh3c07ardvjlw355gw-guix-latest.tar.gz'...
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
The following derivation will be built:
   /gnu/store/nd19z0mxhj81p1pc5f86ahxkzih6z2mg-guix-latest.drv
updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%g'...   0.0%
copying and compiling to '/gnu/store/4gs1fivs32qw3xrn5z1dq3hr9xmblv18-guix-latest' with Guile 2.2.2...
loading...       26.0% of 646 filesrandom seed for tests: 1509990307
compiling...     75.2% of 646 filesbuilding of `/gnu/store/nd19z0mxhj81p1pc5f86ahxkzih6z2mg-guix-latest.drv' timed out after 3600 seconds of silence
guix pull: error: build failed: build of `/gnu/store/nd19z0mxhj81p1pc5f86ahxkzih6z2mg-guix-latest.drv' failed
root@watson ~# echo $?
1
```

After some time during the compilation process, my system freezes for a
long time (CapsLock doesn't light up, cannot move mouse cursor, cannot
switch to vc...).  After about an hour the system is responsive again.

- Marco

[-- Attachment #2: OpenPGP digitale handtekening --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: successful installation, but problems updating

[Ludovic Courtès]

Hi Marco,

Marco van Hulten <marco@hulten.org> skribis:

> root@watson ~# guix pull
>
> Starting download of /tmp/guix-file.F5p3in
> From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
>  ….tar.gz                                   2.3MiB/s 00:06 | 13.8MiB transferred
> unpacking '/gnu/store/5qcf02fjmi4y4chh3c07ardvjlw355gw-guix-latest.tar.gz'...
> substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
> substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
> The following derivation will be built:
>    /gnu/store/nd19z0mxhj81p1pc5f86ahxkzih6z2mg-guix-latest.drv
> updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%g'...   0.0%
> copying and compiling to '/gnu/store/4gs1fivs32qw3xrn5z1dq3hr9xmblv18-guix-latest' with Guile 2.2.2...
> loading...       26.0% of 646 filesrandom seed for tests: 1509990307
> compiling...     75.2% of 646 filesbuilding of `/gnu/store/nd19z0mxhj81p1pc5f86ahxkzih6z2mg-guix-latest.drv' timed out after 3600 seconds of silence
> guix pull: error: build failed: build of `/gnu/store/nd19z0mxhj81p1pc5f86ahxkzih6z2mg-guix-latest.drv' failed

Ouch, I’ve never seen reports for this kind of failure before.

It is 100% reproducible every time you run ‘guix pull’?

Thanks,
Ludo’.

Re: successful installation, but problems updating

[Marco van Hulten]

Ludovic-

Op 07 nov 10:20 schreef Ludovic Courtès:
> Marco van Hulten <marco@hulten.org> skribis:
> 
> > root@watson ~# guix pull
> >
> > Starting download of /tmp/guix-file.F5p3in
> > From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
> >  ….tar.gz                                   2.3MiB/s 00:06 | 13.8MiB transferred
> > unpacking '/gnu/store/5qcf02fjmi4y4chh3c07ardvjlw355gw-guix-latest.tar.gz'...
> > substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
> > substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
> > The following derivation will be built:
> >    /gnu/store/nd19z0mxhj81p1pc5f86ahxkzih6z2mg-guix-latest.drv
> > updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%g'...   0.0%
> > copying and compiling to '/gnu/store/4gs1fivs32qw3xrn5z1dq3hr9xmblv18-guix-latest' with Guile 2.2.2...
> > loading...       26.0% of 646 filesrandom seed for tests: 1509990307
> > compiling...     75.2% of 646 filesbuilding of `/gnu/store/nd19z0mxhj81p1pc5f86ahxkzih6z2mg-guix-latest.drv' timed out after 3600 seconds of silence
> > guix pull: error: build failed: build of `/gnu/store/nd19z0mxhj81p1pc5f86ahxkzih6z2mg-guix-latest.drv' failed  
> 
> Ouch, I’ve never seen reports for this kind of failure before.
> 
> It is 100% reproducible every time you run ‘guix pull’?

It happens every time.  Whether the terminal output is identical (e.g.,
timing out at 75.2%, but not the hash) I plan check in about half a day.

-Marco

Re: successful installation, but problems updating

[Marco van Hulten]

Ludovic-

This is the second time I tried a `guix pull':

```
root@watson ~# time guix pull

Starting download of /tmp/guix-file.x2AvJM
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 ….tar.gz                                   2.3MiB/s 00:06 | 13.8MiB transferred
unpacking '/gnu/store/5sgb93jdacr36xv0xm67zr7dmlr1yyb0-guix-latest.tar.gz'...
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
The following derivations will be built:
   /gnu/store/s71rww59a0avvk9di4rkq3j5f9zvr62k-guix-latest.drv
   /gnu/store/6gxf5snkl5him1iqg6aqmpyn5ggijhx5-module-import-compiled.drv
   /gnu/store/fxnbl74nxjzzm44f1j25glsb3gav4k6b-module-import.drv
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
copying and compiling to '/gnu/store/z8zygkj1c97xskgzxhwy4ys2b0x6shwm-guix-latest' with Guile 2.2.2...
loading...       26.0% of 646 filesrandom seed for tests: 1510087321
compiling...     75.2% of 646 filesGC Warning: Failed to expand heap by 8388608 bytes
building of `/gnu/store/s71rww59a0avvk9di4rkq3j5f9zvr62k-guix-latest.drv' timed out after 3600 seconds of silence
guix pull: error: build failed: build of `/gnu/store/s71rww59a0avvk9di4rkq3j5f9zvr62k-guix-latest.drv' failed

real    142m53.606s
user    0m3.098s
sys     0m1.369s
```

It took over 2 hours before I had control back over the system.  It is
very similar to the first `git pull' (even for the transfer speeds and
the percentage where `guix pull' hangs).  Of course, file/directory
checksums are different.  Also, it now tries to build three
`derivations' instead of one.  There is also a warning on about an
environment variable this time.

- Marco

Re: successful installation, but problems updating

[Marco van Hulten]

Ludo'-

Minor additional info below.

Op 08 nov 02:37 schreef Marco van Hulten:
> Set the environment
> variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> program to get more information.

I tried with this suggestion, and actually got less information with
this (no "failed to expand heap"):

```
kodi@watson ~$ GUILE_WARN_DEPRECATED="detailed" guix pull

Starting download of /tmp/guix-file.BDW8Cd
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 ….tar.gz                                   3.4MiB/s 00:04 | 13.8MiB transferred
unpacking '/gnu/store/kd7k7ndc31hp73liwm93vpjpx9wb47k7-guix-latest.tar.gz'...
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
The following derivation will be built:
   /gnu/store/15zzkryzyx984h4yz2rbzgm2rax2c1i8-guix-latest.drv
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
copying and compiling to '/gnu/store/s1gx4pamdwsqmgxqjz86c2g2pisxm14k-guix-latest' with Guile 2.2.2...
loading...	 26.0% of 646 filesrandom seed for tests: 1510124252
compiling...	 75.2% of 646 filesbuilding of `/gnu/store/15zzkryzyx984h4yz2rbzgm2rax2c1i8-guix-latest.drv' timed out after 3600 seconds of silence
guix pull: error: build failed: build of
`/gnu/store/15zzkryzyx984h4yz2rbzgm2rax2c1i8-guix-latest.drv' failed
```

Do you have any tips for stressing hd, memory, cpu, to try to exclude
hardware issues?  I can install packages in GuixSD with success.

-Marco

Re: successful installation, but problems updating

[Ludovic Courtès]

Hi,

Marco van Hulten <marco@hulten.org> skribis:

> The following derivations will be built:
>    /gnu/store/s71rww59a0avvk9di4rkq3j5f9zvr62k-guix-latest.drv
>    /gnu/store/6gxf5snkl5him1iqg6aqmpyn5ggijhx5-module-import-compiled.drv
>    /gnu/store/fxnbl74nxjzzm44f1j25glsb3gav4k6b-module-import.drv
> substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
> substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
>
> Some deprecated features have been used.  Set the environment
> variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> program to get more information.  Set it to "no" to suppress
> this message.
>
> Some deprecated features have been used.  Set the environment
> variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> program to get more information.  Set it to "no" to suppress
> this message.
> copying and compiling to '/gnu/store/z8zygkj1c97xskgzxhwy4ys2b0x6shwm-guix-latest' with Guile 2.2.2...
> loading...       26.0% of 646 filesrandom seed for tests: 1510087321
> compiling...     75.2% of 646 filesGC Warning: Failed to expand heap by 8388608 bytes
> building of `/gnu/store/s71rww59a0avvk9di4rkq3j5f9zvr62k-guix-latest.drv' timed out after 3600 seconds of silence
> guix pull: error: build failed: build of `/gnu/store/s71rww59a0avvk9di4rkq3j5f9zvr62k-guix-latest.drv' failed
>
> real    142m53.606s
> user    0m3.098s
> sys     0m1.369s

How many CPUs and how much RAM does this machine have?  Does it help in
any way to run “guix pull --cores=2”, thereby limiting CPU usage to two
cores?

Ludo’.

Re: successful installation, but problems updating

[Marco van Hulten]

Ludo'-

Op 09 nov 14:19 schreef Ludovic Courtès:
> How many CPUs and how much RAM does this machine have?  Does it help in
> any way to run “guix pull --cores=2”, thereby limiting CPU usage to two
> cores?

I have two processors, so I tried to run it on one, and it worked:

```
root@watson ~# time guix pull --cores=1                                                                                      

Starting download of /tmp/guix-file.kQQ8AM
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 ….tar.gz                                   2.8MiB/s 00:05 | 13.8MiB transferred
unpacking '/gnu/store/v1zs6bfaam79wp9pf1ja9k8ys4f3dm2s-guix-latest.tar.gz'...
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
The following derivation will be built:
   /gnu/store/5admrckcwdqgqix1d7hfj23fczk2k7ss-guix-latest.drv
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
copying and compiling to '/gnu/store/pmk3b4sqqnizkhmrxx7cdyj4as0ym6r4-guix-latest' with Guile 2.2.2...
loading...       26.1% of 647 filesrandom seed for tests: 1510251772
compiling...    100.0% of 647 files

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
updated GNU Guix successfully deployed under `/root/.config/guix/latest'

real    37m0.478s
user    0m2.963s
sys     0m0.508s
```

Right now I'm updating packages, and things are looking up.

Do you have any idea what went wrong when using both cores?

I am conflating cores and processors right now.  I think these are
equal for this system, but I'm not sure.  I have an Intel Core2 Duo.
/proc/cpuinfo shows two processes.  Furthermore, I presume that
`--cores N` actually means that guix spawns N processes.

-Marco

Re: successful installation, but problems updating

[Marco van Hulten]

Hello,

Op 09 nov 20:27 schreef Marco van Hulten:
> Right now I'm updating packages, and things are looking up.

Well... concerning the root user.  As the manual states that one needs
to do a `guix pull' for any user for whom you want to upgrade the
packages, I did that here, but it failed:

```
kodi@watson ~$ export GUILE_WARN_DEPRECATED="detailed"
kodi@watson ~$ time guix pull --cores=1

Starting download of /tmp/guix-file.vAOlZl
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 ….tar.gz                                   1.8MiB/s 00:07 | 13.8MiB transferred
unpacking '/gnu/store/3kh26avmdfz01gmfdd88692bv0cm5ic5-guix-latest.tar.gz'...
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
The following derivation will be built:
   /gnu/store/499sa14r2f940asrwrflkwgj85iih67m-guix-latest.drv
copying and compiling to '/gnu/store/hqzlhmjqyip7qys36fjligi7p4zavhhp-guix-latest' with Guile 2.2.2...
loading...	 20.4% of 647 filesBacktrace:
In ice-9/boot-9.scm:
  2879:24 19 (_)
   230:29 18 (map1 _)
   230:29 17 (map1 _)
   230:29 16 (map1 _)
   230:29 15 (map1 _)
   230:29 14 (map1 _)
   230:29 13 (map1 _)
   230:29 12 (map1 _)
   230:17 11 (map1 (((gnu packages linux)) ((gnu packages ncurses))))
  2792:17 10 (resolve-interface (gnu packages linux) #:select _ # _ # ?)
  2718:10  9 (_ (gnu packages linux) _ _ #:ensure _)
  2986:16  8 (try-module-autoload _ _)
   2316:4  7 (save-module-excursion _)
  3006:22  6 (_)
In unknown file:
           5 (primitive-load-path "gnu/packages/linux" #<procedure 3?>)
In ice-9/eval.scm:
    619:8  4 (_ #f)
   626:19  3 (_ #<directory (gnu packages linux) 6cc5780>)
   173:55  2 (_ #<directory (gnu packages linux) 6cc5780>)
   223:20  1 (proc #<directory (gnu packages linux) 6cc5780>)
In unknown file:
           0 (%resolve-variable (7 . %intel-compatible-systems) #<di?>)

ERROR: In procedure %resolve-variable:
ERROR: Unbound variable: %intel-compatible-systems

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
builder for `/gnu/store/499sa14r2f940asrwrflkwgj85iih67m-guix-latest.drv' failed with exit code 1
guix pull: error: build failed: build of `/gnu/store/499sa14r2f940asrwrflkwgj85iih67m-guix-latest.drv' failed

real	1m49.870s
user	0m2.869s
sys	0m0.434s
```

The message here, together with the fact that --cores=1 worked (see
previous message in thread), suggests that /proc/cpuinfo may be useful:

https://paste.debian.net/994931/

-Marco

Re: successful installation, but problems updating

[Mathieu Othacehe]

> ERROR: In procedure %resolve-variable:
> ERROR: Unbound variable: %intel-compatible-systems

My bad, this has been fixed by Efraim in
d8f075c3a3daba93ff4420bbe0b1833712aaa0e9.

You may want to guix pull again !

Sorry,

Mathieu

Re: successful installation, but problems updating

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

Thomas Sigurdsen <thomas.sigurdsen@gmail.com> writes:

>> Firstly, it often says that I need to use '--fallback'.  Is that
>> because the binary is not available?
>>
>
> '--fallback' means that guix will fall back to compiling from source if
> it can't download binaries (also called substitutes). By default guix
> tries to download substitutes from the build farm (hydra).
>
>> 
>> Secondly, I noted that with, e.g., 'guix package -i kodi' software gets
>> compiled.  I understood that GNU Guix is capable of both binary and
>> source packages.  Which should I typically expect?  Can I choose?
>> 
>
> It seems to me I usually get core and common packages as substitutes
> (binaries). There is the ‘--no-substitutes’ command line flag to disable
> substitutes and always build from source. I can't see a flag for
> disabling source builds.
>
> You'll find this information in the guix info pages, specifically under
> "common build options" and "invoking guix system".

Anecdotally, I swear I've seen guix build some things from source even
when I did not specify --fallback.  Has anybody else seen that occur?

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: successful installation, but problems updating

[Carlo Zancanaro]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]


On Fri, Nov 10 2017, Chris Marusich wrote:
> Anecdotally, I swear I've seen guix build some things from source even
> when I did not specify --fallback.  Has anybody else seen that occur?

Yeah, I've definitely seen that. My assumption was that this is what's
meant to happen when substitutes aren't available. So if I write a
custom package and install it (with "guix package -f") it will build it
locally, even without --fallback.

I assume that --fallback builds the package if the substitute exists,
but fails to download for some reason (network error, etc.).

Carlo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: successful installation, but problems updating

[Marco van Hulten]

Op 09 nov 21:53 schreef Mathieu Othacehe:
> My bad, this has been fixed by Efraim in
> d8f075c3a3daba93ff4420bbe0b1833712aaa0e9.
> 
> You may want to guix pull again !

This work again — thanks for the quick response.

However, now I get the freeze again at around 75 %:

```
kodi@watson ~$ time guix pull --cores=1

Starting download of /tmp/guix-file.MgDQxo
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 ….tar.gz                                   3.2MiB/s 00:04 | 13.8MiB transferred
unpacking '/gnu/store/r3740b6bil3vcign3wj2izw9hb3c4gpg-guix-latest.tar.gz'...
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
The following derivation will be built:
   /gnu/store/gk5chb0dwpsq3na7b4gn1hd7h0h2b63h-guix-latest.drv
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
copying and compiling to '/gnu/store/b4rs2nl3q1hb3ckbgzg98s23q44bcys4-guix-latest' with Guile 2.2.2...
loading...	 26.1% of 647 filesrandom seed for tests: 1510261509
compiling...	 75.4% of 647 filesbuilding of `/gnu/store/gk5chb0dwpsq3na7b4gn1hd7h0h2b63h-guix-latest.drv' timed out after 3600 seconds of silence
kguix pull: error: build failed: build of `/gnu/store/gk5chb0dwpsq3na7b4gn1hd7h0h2b63h-guix-latest.drv' failed

real	609m30.245s
user	0m3.125s
sys	0m0.875s
```

This command did work last time as root.  It only worked once.
Special things to note this time:

- it hangs at 75.4 % instead of 75.2 %;
- it took over 10 h to give me back control, whereas this used to be
  a bit over 2 h in previous tries;
- using only one core did not help this time.

What is Guix doing between 75.2 and 75.4 %?

-Marco

Re: successful installation, but problems updating

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 2509 bytes --]

> Thomas Sigurdsen <thomas.sigurdsen@gmail.com> writes:
> 
> >> Secondly, I noted that with, e.g., 'guix package -i kodi' software gets
> >> compiled.  I understood that GNU Guix is capable of both binary and
> >> source packages.  Which should I typically expect?  Can I choose?

Guix is a build-from-source system that can transparently download
pre-compiled binary "substitutes" when they are available, and when this
substitution method has been authorized by the user. On GuixSD, it's
authorized by default. Here's the documentation of substitution:

https://www.gnu.org/software/guix/manual/guix.html#Substitutes

If your Guix is relatively up to date [0], you've authorized a
substitute server, and you can connect to the European internet, then
most things will be substituted. But usually there will be a few things
to build from source anyways.

You can choose to never use substitutes by de-authorizing all substitute
signing keys [1] or by passing --no-substitutes to the guix-daemon or
any of the commands that build things [2].

Since Guix is ultimately a build-from-source system, there is currently
no way to disable building from source.

[...]

On Thu, Nov 09, 2017 at 09:58:30PM -0800, Chris Marusich wrote:
> Anecdotally, I swear I've seen guix build some things from source even
> when I did not specify --fallback.  Has anybody else seen that occur?

That's expected. If substitutes are enabled, when running a command that
builds things, Guix asks the substitute servers what can be substituted.
If some thing is not available as a substitute, Guix will build it.

However, if a substitute is reported to be available, but then the
substitution fails for any reason, Guix will stop.

'--fallback' is relevant in this case, and is meant to work around flaky
substitute servers, network connections, etc. The documentation says:
"When substituting a pre-built binary fails, fall back to building
packages locally." [2]

Substition is considered to fail when Guix is expecting a substitute but
the server returns 404, 504, or some other unexpected problem occurs. It
is not considered to fail if the server initially reports that no
substitute is available.

[0] Not more than a few months behind, I'd guess.

[1]
https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-archive.html

[2] --no-substitutes and --fallback are "common build options":
https://www.gnu.org/software/guix/manual/html_node/Common-Build-Options.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: successful installation, but problems updating

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

On Fri, Nov 10, 2017 at 08:26:12AM +0100, Marco van Hulten wrote:
> kodi@watson ~$ time guix pull --cores=1

[...]

> compiling...	 75.4% of 647 filesbuilding of `/gnu/store/gk5chb0dwpsq3na7b4gn1hd7h0h2b63h-guix-latest.drv' timed out after 3600 seconds of silence

[...]

> real	609m30.245s
> user	0m3.125s
> sys	0m0.875s

This is terrible, but you can work around it by passing a large value to
the --max-silent-time "common build option":
     
--max-silent-time=seconds

    When the build or substitution process remains silent for more than seconds, terminate it and report a build failure.

https://www.gnu.org/software/guix/manual/html_node/Common-Build-Options.html

Out of curiosity, what kind of machine are you using? A full hour with
no output at all indicates that something is happening very slowly! Is
it swapping?

> - it took over 10 h to give me back control, whereas this used to be
>   a bit over 2 h in previous tries;

Do you mean that the computer becomes unresponsive?

> What is Guix doing between 75.2 and 75.4 %?

I don't know exactly, but during `guix pull` Guix is built from source
with the Guile compiler.

There are some bugs in the current version of the Guile compiler that
cause it to require way more memory than expected. This is terrible on
memory-constrained systems because it forces the use of swap, which is
typically super slow. Hopefully we can deploy a fix soon.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: successful installation, but problems updating

[Chris Marusich]

[-- Attachment #1.1: Type: text/plain, Size: 761 bytes --]

Hi Leo,

Leo Famulari <leo@famulari.name> writes:

> Substition is considered to fail when Guix is expecting a substitute but
> the server returns 404, 504, or some other unexpected problem occurs. It
> is not considered to fail if the server initially reports that no
> substitute is available.

Thank you for the clarification.  This is what I did not understand.  I
read the manual and got the impression that when --fallback has not been
given, if a given substitute cannot be found (regardless of whether or
not a substitute server claimed to provide one), then Guix will not
build it.  I see now that my understanding was mistaken.

I've attached a patch which tries to clarify this in the manual.  What
do you think of it?

-- 
Chris

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-doc-Clarify-the-fallback-option.patch --]
[-- Type: text/x-patch, Size: 1336 bytes --]

From ce8c53bffa2f79f680f9b27bcb494a4fadb4038c Mon Sep 17 00:00:00 2001
From: Chris Marusich <cmmarusich@gmail.com>
Date: Fri, 10 Nov 2017 15:19:16 -0800
Subject: [PATCH] doc: Clarify the --fallback option.

* doc/guix.texi (Common Build Options): Describe --fallback in more detail.
  In particular, call out the fact that local builds can still happen even
  when --fallback is omitted.
---
 doc/guix.texi | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index b7f4f88f9..40705c4b8 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -5159,7 +5159,13 @@ Do not build the derivations.
 
 @item --fallback
 When substituting a pre-built binary fails, fall back to building
-packages locally.
+locally.  This affects behavior only when substitutes are enabled and
+Guix is building a derivation for which a substitute is known.  When
+@code{--fallback} is omitted, the build will fail if substitution fails.
+However, when @code{--fallback} is given, Guix will try to build the
+derivation locally if substitution fails.  When substitutes are not
+enabled or Guix is building a derivation for which a substitute is not
+known, a local build will always be performed.
 
 @item --substitute-urls=@var{urls}
 @anchor{client-substitute-urls}
-- 
2.14.2


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: successful installation, but problems updating

[myglc2]

On 11/10/2017 at 15:30 Chris Marusich writes:

> Hi Leo,
>
> Leo Famulari <leo@famulari.name> writes:
>
>> Substition is considered to fail when Guix is expecting a substitute but
>> the server returns 404, 504, or some other unexpected problem occurs. It
>> is not considered to fail if the server initially reports that no
>> substitute is available.

Hi Leo, this is a wonderful clarification of behavior that has confused
me for 1.5 years!
>
> Thank you for the clarification.  This is what I did not understand.  I
> read the manual and got the impression that when --fallback has not been
> given, if a given substitute cannot be found (regardless of whether or
> not a substitute server claimed to provide one), then Guix will not
> build it.  I see now that my understanding was mistaken.

I had this mistaken impression too.
>
> I've attached a patch which tries to clarify this in the manual.  What
> do you think of it?

Hey Chris,

How about saying what Leo said right up front in the substitutes
section. This allows the --fallback addition to be more brief.

Rough draft below.

WDYT? - George

1 file changed, 9 insertions(+), 2 deletions(-)
doc/guix.texi | 11 +++++++++--

modified   doc/guix.texi
@@ -2120,6 +2120,13 @@ server.  We call these pre-built items @dfn{substitutes}---they are
 substitutes for local build results.  In many cases, downloading a
 substitute is much faster than building things locally.
 
+When substitutes are enabled (the default) and a substitute is not
+available the build will take place locally. If a substitute is
+available but substitution fails, e.g., the substitute server returns
+404, 504, times out, or some other unexpected problem occurs, guix stops
+and reports an error unless --fallback or --keep-going options are
+specified.
+
 Substitutes can be anything resulting from a derivation build
 (@pxref{Derivations}).  Of course, in the common case, they are
 pre-built package binaries, but source tarballs, for instance, which
@@ -5192,8 +5199,8 @@ derivations has failed.
 Do not build the derivations.
 
 @item --fallback
-When substituting a pre-built binary fails, fall back to building
-packages locally.
+Attempt to build locally instead of issuing an error when substitutes
+are enabled and the substitution of a pre-built binary fails.
 
 @item --substitute-urls=@var{urls}
 @anchor{client-substitute-urls}

Re: successful installation, but problems updating

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]

myglc2 <myglc2@gmail.com> writes:

> On 11/10/2017 at 15:30 Chris Marusich writes:
>
>> Hi Leo,
>>
>> Leo Famulari <leo@famulari.name> writes:
>>
>>> Substition is considered to fail when Guix is expecting a substitute but
>>> the server returns 404, 504, or some other unexpected problem occurs. It
>>> is not considered to fail if the server initially reports that no
>>> substitute is available.
>
> Hi Leo, this is a wonderful clarification of behavior that has confused
> me for 1.5 years!
>>
>> Thank you for the clarification.  This is what I did not understand.  I
>> read the manual and got the impression that when --fallback has not been
>> given, if a given substitute cannot be found (regardless of whether or
>> not a substitute server claimed to provide one), then Guix will not
>> build it.  I see now that my understanding was mistaken.
>
> I had this mistaken impression too.
>>
>> I've attached a patch which tries to clarify this in the manual.  What
>> do you think of it?
>
> Hey Chris,
>
> How about saying what Leo said right up front in the substitutes
> section. This allows the --fallback addition to be more brief.
>
> Rough draft below.
>
> WDYT? - George
>
> 1 file changed, 9 insertions(+), 2 deletions(-)
> doc/guix.texi | 11 +++++++++--
>
> modified   doc/guix.texi
> @@ -2120,6 +2120,13 @@ server.  We call these pre-built items @dfn{substitutes}---they are
>  substitutes for local build results.  In many cases, downloading a
>  substitute is much faster than building things locally.
>  
> +When substitutes are enabled (the default) and a substitute is not
> +available the build will take place locally. If a substitute is
> +available but substitution fails, e.g., the substitute server returns
> +404, 504, times out, or some other unexpected problem occurs, guix stops
> +and reports an error unless --fallback or --keep-going options are
> +specified.
> +
>  Substitutes can be anything resulting from a derivation build
>  (@pxref{Derivations}).  Of course, in the common case, they are
>  pre-built package binaries, but source tarballs, for instance, which
> @@ -5192,8 +5199,8 @@ derivations has failed.
>  Do not build the derivations.
>  
>  @item --fallback
> -When substituting a pre-built binary fails, fall back to building
> -packages locally.
> +Attempt to build locally instead of issuing an error when substitutes
> +are enabled and the substitution of a pre-built binary fails.
>  
>  @item --substitute-urls=@var{urls}
>  @anchor{client-substitute-urls}

I think I like the way you wrote it better.  I'm fine with that.  I was
hoping not to add to the already-voluminous paragraphs about Substitutes
at the top of section 3.3, but honestly as long as this info is in the
manual, I'm happy.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: successful installation, but problems updating

[myglc2]

On 11/11/2017 at 09:05 Chris Marusich writes:

> myglc2 <myglc2@gmail.com> writes:
>
>> On 11/10/2017 at 15:30 Chris Marusich writes:
>>
>>> Hi Leo,
>>>
>>> Leo Famulari <leo@famulari.name> writes:
>>>
>>>> Substition is considered to fail when Guix is expecting a substitute but
>>>> the server returns 404, 504, or some other unexpected problem occurs. It
>>>> is not considered to fail if the server initially reports that no
>>>> substitute is available.
>>
>> Hi Leo, this is a wonderful clarification of behavior that has confused
>> me for 1.5 years!
>>>
>>> Thank you for the clarification.  This is what I did not understand.  I
>>> read the manual and got the impression that when --fallback has not been
>>> given, if a given substitute cannot be found (regardless of whether or
>>> not a substitute server claimed to provide one), then Guix will not
>>> build it.  I see now that my understanding was mistaken.
>>
>> I had this mistaken impression too.
>>>
>>> I've attached a patch which tries to clarify this in the manual.  What
>>> do you think of it?
>>
>> Hey Chris,
>>
>> How about saying what Leo said right up front in the substitutes
>> section. This allows the --fallback addition to be more brief.
>>
>> Rough draft below.
>>
>> WDYT? - George
>>
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>> doc/guix.texi | 11 +++++++++--
>>
>> modified   doc/guix.texi
>> @@ -2120,6 +2120,13 @@ server.  We call these pre-built items @dfn{substitutes}---they are
>>  substitutes for local build results.  In many cases, downloading a
>>  substitute is much faster than building things locally.
>>  
>> +When substitutes are enabled (the default) and a substitute is not
>> +available the build will take place locally. If a substitute is
>> +available but substitution fails, e.g., the substitute server returns
>> +404, 504, times out, or some other unexpected problem occurs, guix stops
>> +and reports an error unless --fallback or --keep-going options are
>> +specified.
>> +
>>  Substitutes can be anything resulting from a derivation build
>>  (@pxref{Derivations}).  Of course, in the common case, they are
>>  pre-built package binaries, but source tarballs, for instance, which
>> @@ -5192,8 +5199,8 @@ derivations has failed.
>>  Do not build the derivations.
>>  
>>  @item --fallback
>> -When substituting a pre-built binary fails, fall back to building
>> -packages locally.
>> +Attempt to build locally instead of issuing an error when substitutes
>> +are enabled and the substitution of a pre-built binary fails.
>>  
>>  @item --substitute-urls=@var{urls}
>>  @anchor{client-substitute-urls}
>
> I think I like the way you wrote it better.  I'm fine with that.  I was
> hoping not to add to the already-voluminous paragraphs about Substitutes
> at the top of section 3.3, but honestly as long as this info is in the
> manual, I'm happy.

I agree w/you Substitutes is overwhelming ;-) 

Meanwhile, so will you submit the patch, or do you want me to?

TIA - George

Re: successful installation, but problems updating

[Marco van Hulten]

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

Leo-

Op 10 nov 11:35 schreef Leo Famulari:
> On Fri, Nov 10, 2017 at 08:26:12AM +0100, Marco van Hulten wrote:
> > kodi@watson ~$ time guix pull --cores=1  
> 
> [...]
> 
> > compiling...	 75.4% of 647 filesbuilding of `/gnu/store/gk5chb0dwpsq3na7b4gn1hd7h0h2b63h-guix-latest.drv' timed out after 3600 seconds of silence  
> 
> [...]
> 
> > real	609m30.245s
> > user	0m3.125s
> > sys	0m0.875s  
> 
> This is terrible, but you can work around it by passing a large value to
> the --max-silent-time "common build option": [...]

Hmm, but the time-out is now after 1 hour of silence, and the whole
process takes over 10 hours before crashing.  This option may be useful
if I set a very short time, though it remains to be seen if this ends
guix quickly.  I will play around with it.

Right now a `guix pull' results in a `dispatch-exception' in procedure
`struct_vtable: Wrong type argument in position 1 (expecting struct):
#<pointer 0x0>'.  It seems that GuixSD (or components) is strongly in
flux right now, so I will try again later and do a proper bug report if
problems persist.

> Out of curiosity, what kind of machine are you using? A full hour with
> no output at all indicates that something is happening very slowly! Is
> it swapping?

I'd like to test if it is swapping.  I have 2 GiB of RAM in a 2-core
machine (Intel Core 2 Duo).  I did notice that swap was not enabled yet
on my system, and that (during last `guix pull') around 95% of RAM was
used.

> > - it took over 10 h to give me back control, whereas this used to be
> >   a bit over 2 h in previous tries;  
> 
> Do you mean that the computer becomes unresponsive?

Yes.

> > What is Guix doing between 75.2 and 75.4 %?  
> 
> I don't know exactly, but during `guix pull` Guix is built from source
> with the Guile compiler.
> 
> There are some bugs in the current version of the Guile compiler that
> cause it to require way more memory than expected. This is terrible on
> memory-constrained systems because it forces the use of swap, which is
> typically super slow. Hopefully we can deploy a fix soon.

Is 2 GiB considered "memory-constrained"?

-Marco

[-- Attachment #2: OpenPGP digitale handtekening --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: successful installation, but problems updating

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]

On Sat, Nov 11, 2017 at 11:23:00PM +0100, Marco van Hulten wrote:
> > This is terrible, but you can work around it by passing a large value to
> > the --max-silent-time "common build option": [...]
> 
> Hmm, but the time-out is now after 1 hour of silence, and the whole
> process takes over 10 hours before crashing.  This option may be useful
> if I set a very short time, though it remains to be seen if this ends
> guix quickly.  I will play around with it.

You can also increase the timeout with the --timeout option.  However,
if it crashes no matter how long you let it run, that's a different
problem.

> Right now a `guix pull' results in a `dispatch-exception' in procedure
> `struct_vtable: Wrong type argument in position 1 (expecting struct):
> #<pointer 0x0>'.  It seems that GuixSD (or components) is strongly in
> flux right now, so I will try again later and do a proper bug report if
> problems persist.

This is definitely not supposed to happen. Hopefully it's already been
fixed but otherwise a bug report is welcome!

> I'd like to test if it is swapping.  I have 2 GiB of RAM in a 2-core
> machine (Intel Core 2 Duo).  I did notice that swap was not enabled yet
> on my system, and that (during last `guix pull') around 95% of RAM was
> used.
> 
> > > - it took over 10 h to give me back control, whereas this used to be
> > >   a bit over 2 h in previous tries;  
> > 
> > Do you mean that the computer becomes unresponsive?
> 
> Yes.

I have a Core 2 Duo system with 3 GiB RAM and `guix pull` takes less
than an hour and doesn't swap.

> Is 2 GiB considered "memory-constrained"?

I'd argue that it should not be, but due to the Guile bug it is. It may
not be enough to run `guix pull` — I don't know exactly how much memory
is required.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: successful installation, but problems updating

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

On Sat, Nov 11, 2017 at 10:29:30AM -0500, myglc2 wrote:
> On 11/10/2017 at 15:30 Chris Marusich writes:
> > Thank you for the clarification.  This is what I did not understand.  I
> > read the manual and got the impression that when --fallback has not been
> > given, if a given substitute cannot be found (regardless of whether or
> > not a substitute server claimed to provide one), then Guix will not
> > build it.  I see now that my understanding was mistaken.
> 
> I had this mistaken impression too.

It's important to remember that Guix is a build-from-source system. The
use of pre-compiled binaries is an optimization made possible by the
functional package model.

> +When substitutes are enabled (the default) and a substitute is not
> +available the build will take place locally. If a substitute is
> +available but substitution fails, e.g., the substitute server returns
> +404, 504, times out, or some other unexpected problem occurs, guix stops
> +and reports an error unless --fallback or --keep-going options are
> +specified.

To clarify, the default status of substitutes is different for Guix
(default disabled) and GuixSD (default enabled).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: successful installation, but problems updating

[myglc2]

On 11/11/2017 at 20:29 Leo Famulari writes:

> On Sat, Nov 11, 2017 at 10:29:30AM -0500, myglc2 wrote:
>> On 11/10/2017 at 15:30 Chris Marusich writes:
>> > Thank you for the clarification.  This is what I did not understand.  I
>> > read the manual and got the impression that when --fallback has not been
>> > given, if a given substitute cannot be found (regardless of whether or
>> > not a substitute server claimed to provide one), then Guix will not
>> > build it.  I see now that my understanding was mistaken.
>> 
>> I had this mistaken impression too.
>
> It's important to remember that Guix is a build-from-source system. The
> use of pre-compiled binaries is an optimization made possible by the
> functional package model.

Yes, but ... the average bear using GuixSD, having internalized Guix'
assurances that substitutes are reliably the same as what they could
build-from-source locally, naturally assumes that substitutes will be
used.

Unfortunately the current "hot rolling" of updates into origin/master
means that hydra has no way to get reliably "100% ahead" of users who
update frequently. Further hydra does not keep a "deep set" of previous
builds, so a user may well find themselves building old stuff. This
treats our users to a baffling, herky-jerky experience, with local
builds seeming to occur at random. 

With improvements to the way changes are rolled in and to hydra, et al.,
the "substitution fraction" that users experiences should increase, but
will most likely never reach 100% and will remain variable.  So a user
coming from something like debian encounters a different user experience
that may well be disconcerting. This makes it important to find a way of
explaining substitutes, what is happening, and what to expect, so that
our users will feel be confident that everything is OK.

Personally I prefer herky-jerky + "total source artistic control" +
reliable roll-back to speedy binary-only update + unknown provenance +
no roll back. In other words, "I drank the kool aid". I also have a
couple speedy servers so the GuixSD builds don't interrupt my work flow.

But I feel for the noobs on IRC whose machines have been kidnapped by
GuixSD for huge, unpredictable, chunks of time.

>> +When substitutes are enabled (the default) and a substitute is not
>> +available the build will take place locally. If a substitute is
>> +available but substitution fails, e.g., the substitute server returns
>> +404, 504, times out, or some other unexpected problem occurs, guix stops
>> +and reports an error unless --fallback or --keep-going options are
>> +specified.
>
> To clarify, the default status of substitutes is different for Guix
> (default disabled) and GuixSD (default enabled).

Oh, WOW! Does the doc say that?

And, why is it different?

Re: successful installation, but problems updating

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 3077 bytes --]

On Sat, Nov 11, 2017 at 10:36:26PM -0500, myglc2 wrote:
> Yes, but ... the average bear using GuixSD, having internalized Guix'
> assurances that substitutes are reliably the same as what they could
> build-from-source locally, naturally assumes that substitutes will be
> used.
> 
> Unfortunately the current "hot rolling" of updates into origin/master
> means that hydra has no way to get reliably "100% ahead" of users who
> update frequently. Further hydra does not keep a "deep set" of previous
> builds, so a user may well find themselves building old stuff. This
> treats our users to a baffling, herky-jerky experience, with local
> builds seeming to occur at random. 
> 
> With improvements to the way changes are rolled in and to hydra, et al.,
> the "substitution fraction" that users experiences should increase, but
> will most likely never reach 100% and will remain variable.  So a user
> coming from something like debian encounters a different user experience
> that may well be disconcerting. This makes it important to find a way of
> explaining substitutes, what is happening, and what to expect, so that
> our users will feel be confident that everything is OK.
> 
> Personally I prefer herky-jerky + "total source artistic control" +
> reliable roll-back to speedy binary-only update + unknown provenance +
> no roll back. In other words, "I drank the kool aid". I also have a
> couple speedy servers so the GuixSD builds don't interrupt my work flow.
> 
> But I feel for the noobs on IRC whose machines have been kidnapped by
> GuixSD for huge, unpredictable, chunks of time.

All good points! Maintaining the build farm is one of really hard parts
of developing Guix, from what I've seen. I'm hopeful that we will
improve it in the next year.

> >> +When substitutes are enabled (the default) and a substitute is not
> >> +available the build will take place locally. If a substitute is
> >> +available but substitution fails, e.g., the substitute server returns
> >> +404, 504, times out, or some other unexpected problem occurs, guix stops
> >> +and reports an error unless --fallback or --keep-going options are
> >> +specified.
> >
> > To clarify, the default status of substitutes is different for Guix
> > (default disabled) and GuixSD (default enabled).
> 
> Oh, WOW! Does the doc say that?

Yes, the installation instructions for Guix mention authorizing the
substitute signing key in step 7 [0]. So, I think it's clear that they
are not enabled otherwise.

> And, why is it different?

I don't know if there is a design choice here, but the steps required to
authorize substitutes for Guix on another distro require root. So, we
can't make it "just work" without the user elevating their privileges.
It's not the only part of our installation guide that requires root,
however.

On GuixSD, we can control the entire system during installation, so we
enable substitutes by default.

[0]
https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: successful installation, but problems updating

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

Hi Leo and George,

I've taken a stab at improving the "Substitutes" section.  Please let me
know if you have any concerns by replying to the patch email submission:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29271

I think the existence of this email thread proves that the question of
"Are substitutes enabled by default?" does not have an obvious answer.
I also think that the existence of this email proves that the behavior
of the --fallback command is not obvious, so it requires a very careful
explanation in the manual to eliminate any risk of misinterpretation.

Please do not reply to this email with feedback on the patch series;
please respond to the patch email if you have feedback on the patch.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]