IRC channel logs


back to list of logs

<rekado_>users tell me that "Computing Guix derivation" now takes a very long time
<rekado_>I can confirm this.
<rekado_>it seems quite a bit slower than in the past
<civodul>this is haunting me
<civodul>i've grown the habit of typing "time guix" instead of "guix" and didn't notice anything special, but i think this is quite sensitive
<civodul>for example, there could be a single commit that pulls in 20 more package modules in the base closure
<civodul>"time guix time-machine -- describe" ran in 1m45s just now (i'd usually get ~1m10s, but it depends on many factors)
<rekado_>some people have reported 10m+
<rekado_>I’m running it too and it’s still computing after more than 2 mins
<rekado_>I’m using time guix pull --commit=30289f4d4638452520f52c1a36240220d0d940ff
<rekado_>(because that’s the last commit for which there are Guix substitutes)
<civodul>it's also the last commit, AFAICS
<rekado_>also weird: I don’t get substitutes for the Guix derivations
<civodul>they were all available for me, for this commit
<civodul>most cached, some on-the-fly (you can tell it from the fact that their total size is unknown)
<civodul>the "Computing ..." phase is mostly CPU-bound
<civodul>perhaps a factor that can make it slower is if you're talking to a remote daemon
<civodul>with GUIX_DAEMON_SOCKET
<rekado_>I’ll move the substitutes cache out of the way and restart this
<civodul>the whole thing took... 5m43s on our cluster :-/
<rekado_>it created the cache, but it still wants to build all these thigns
<rekado_>building /gnu/store/q8864sibq2iy882bv833mww8yp6k7y1x-guix-system.drv...
<civodul>are we looking at the same derivations?
<civodul>in the paste above, i had /gnu/store/m6navmpyyz3rbmsds40y0j0r520r7cjv-guix-system.drv -> /gnu/store/g85whfc6lcm44vs4mv2i1np9qq5ffc5d-guix-system
<civodul>(for commit 30289f4d4638452520f52c1a36240220d0d940ff)
<rekado_>here’s my paste:
<rekado_>different derivations
<civodul>i have this:
<civodul>& you?
<civodul>could it be that you have a different %localstatedir or something?
<rekado_>I don’t have that derivation
<rekado_>yes, probably that
<civodul>right, but if you replace it with your own guix-system.drv
<rekado_>localstatedir used to be /gnu/var/guix, and probably still is.
<civodul>(guix self) could be a bit more lax on this
<civodul>ok, confirmed!
<rekado_>so, does this mean I’ll *never* get “guix pull” substitutes?
<rekado_>I wonder how I could safely migrate to using /var/guix as the localstatedir
<civodul>yes (except for things like guix-manual.drv, guix-daemon.drv, etc.)
<civodul>if you have that option, that's great
<rekado_>the new installation already does that, but all the existing “guix” commands in people’s profiles remember the past /gnu/var/guix directory
<civodul>we could tweak (guix self) so you'd still get substitutes though
<civodul>i think this patch would do it:
<rekado_>this would move the variables out of the derivation, right?
<civodul>so they'd still be there at the end, via *config*, but not as a dependency of those derivations
<civodul>because we know they have no impact on the compilation of all these Scheme modules anyway
<civodul>i'm testing it here and will push later today of all goes well
<rekado_>excellent, thank you!
<civodul>that won't fix the "Computing ..." phase slowness though :-/
<civodul>that one will take more time
<civodul>(i also need to fix the OOM you reported...)
<civodul>rekado_: pushed as 27f00963d31636eb94bb7f331989827f4782de78
<civodul>lemme know how it goes!