Hello, Diego Nicola Barbato <dnbarb...@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’.
