Re: bug#26608: channels.scm supporting substitutes

[Nome Grey <greynome72@gmail.com>]

On Wed, Dec 4, 2019, 9:33 AM zimoun <zimon.toutoune@gmail.com> wrote:

> From my understanding, when you use "guix install foo", Guix computes
> a derivation and query the substitutes. If the derivation exists on
> the server, it downloads. It does not matter so much from which Guix
> version you run "guix install". On the contrary, too recent version
> (new "guix pull") should not be built by Cuirass yet and so served as
> substitute.
>

It seems the guix version you have is also the version of the set of
packages your system is aware of.  `guix pull` seems to update both.  So
which derivation is computed does depend on your guix version, and that is
why too new versions aren't matched yet on the server.

What is the output of the command: "guix install ungoogled-chromium
> --dry-run" on your machine?
>

So, I did this with the setup I described, but didn't e-mail you yet
because I wanted to try after my `guix pull` of commit 1b6c5e8 completed,
which finished today, but then my system crashed after I forgot to reboot
guix-daemon, and I lost the first output.  So the substitute is actually
now available for me -- selecting that commit worked -- but it wasn't
before.

I also noticed often the substitute is not chosen when the server is having
congestion issues.

$ guix --version
guix (GNU Guix) 1b6c5e803989210720de98862571a7ce1dd8e8dd
Copyright (C) 2019 the Guix authors
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ guix install ungoogled-chromium --dry-run
The following package would be upgraded:
   ungoogled-chromium 74.0.3729.131-0.9e33022 → 78.0.3904.108-0.8f06513
/gnu/store/wcjr5n9ljvbw6ak3705pqs7y6n3fk934-ungoogled-chromium-78.0.3904.108-0.8f06513

The following derivation would be built:
   /gnu/store/akzyrbp4pirvxjss0s41fv3ggpy70a8q-profile.drv
82.1 MB would be downloaded:
   /gnu/store/9aiizpqhpiixds5x52w67q7p3wxsz1db-libcdio-paranoia-10.2+2.0.0
   /gnu/store/ghj6k72hpvilkv53hx2frz5a5qazvrk2-libcdio-2.1.0
   /gnu/store/mpsjsddxbzjncvrxqll59lmwad6yygl0-ffmpeg-4.2.1

 /gnu/store/wcjr5n9ljvbw6ak3705pqs7y6n3fk934-ungoogled-chromium-78.0.3904.108-0.8f06513
The following profile hooks would be built:
   /gnu/store/71fl8l2n2l01yjd2ajqz1qs7a5f0g8ar-gtk-im-modules.drv
   /gnu/store/7nrwf66l0r9vdzcxyl56xzkrm3dj5bhl-gtk-icon-themes.drv
   /gnu/store/f3xpxb5a79xvxxaav7zvmg1lmsslxz8f-xdg-mime-database.drv
   /gnu/store/g1acs7i62984xkwkwshyirinqzvf20xl-glib-schemas.drv
   /gnu/store/k0xp9xvc8njzqzwy7ndj7w5p8kk4ljcv-ca-certificate-bundle.drv
   /gnu/store/n4zwqdspgy8dnfmz7y0sv425mc81mm87-fonts-dir.drv
   /gnu/store/qmb0w52ys35l7hdrbkx3vwbsd2b31nj3-manual-database.drv
   /gnu/store/syspl3xawhbpynvjn6a5n34fyap7awap-xdg-desktop-database.drv
   /gnu/store/vpy3llakmf6kfb2gf93309m8wdrkhjvc-info-dir.drv


( I think that http://berlin.guixsd.org and https://ci.guix.gnu.org
> point to the same build farm.)
>

Yeah, they both resolve to 141.80.181.40 over here.  I think berlin is
maybe left over from when hydra was in use, not sure.  I was kind of
assuming they were the same and may have confused things not clarifying
that.

> By only upgrading to releases with substitutes available, fewer builds
> are required on the local system, which can still be occasionally brought
> up to date.  The user channel filters the official channel, to hide
> releases without substitutes built yet.


I am not sure it works as you think.
>

That is how the specialized channels.scm they were discussing in the bugs
is supposed to work.  Following ludo's lead was how I managed to find this
way to use the substitute for ungoogled-chromium.

But yeah I'm not really sure where the package index is stored to directly
connect it to guix pull's behavior and such.  It's guesswork for me for
sure.

I am checking why Guix claims the substitute is not available for i686
> when it really is.
>

If it's not because the ci server was overloaded, maybe it is that one of
the inputs to the package has been updated, such that a new derivation than
the one built is used now?