bug#31085: Unexpected behaviour when running `guix build lilypond'

[ludo@gnu.org (Ludovic Courtès)]

Hello,

Diego Nicola Barbato <dnbarbato@posteo.de> skribis:

> I have experienced some unexpected behaviour when running `guix build
> lilypond':
> After verifying that there was a substitute available with `guix weather
> -m m.scm' (Where m.scm evaluates to a manifest containing only lilypond)
> I ran `guix build lilypond --dry-run' which claimed that a substitute
> would be downloaded.  I then ran `guix build lilypond' which proceeded
> to build lilypond from source (instead of downloading the substitute).
>
> Upon explaining this on IRC it was suggested that I try running `guix
> build --no-grafts lilypond' (which actually downloaded the substitute)
> then deleting the locally built lilypond with `guix gc --delete
> /gnu/store/...' and finally running `guix build lilypond' again (which,
> this time, grafted the substituted lilypond instead of building it from
> source again).  While this fixed the issue I was told that this
> behaviour was indeed unexpected.

We’d have to see if this is still reproducible, but I have a plausible
explanation.

Substitute info is cached locally.  guix-daemon caches it under
/var/guix/substitute/cache, but ‘guix weather’ caches it under
~/.cache/guix/substitute (that’s because it needs fine-grain control
over substitute info and thus cannot simply use the
‘substitutable-path-info’ daemon RPC.)  Each cached entry has a
time-to-live (TTL).

What could have happened is that /var/guix/substitute/ had a
not-expired-yet entry saying that there’s no substitute for LilyPond
(which is why ‘guix build’ ended up building from source), whereas ‘guix
weather’ was run at a point when there was a substitute.

If that happens again, I’d suggest capturing immediately the two cached
entries so we can see whether this explanation holds.

Thanks,
Ludo’.