bug#35874: “guix pull” fails on setlocale

[Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>]

Ludovic Courtès <ludo@gnu.org> writes:

>> When I started the daemon from “guix pull” without having set
>> GUIX_DATABASE_DIRECTORY and I asked Guix to build something I noticed
>> this error message:
>>
>>    guix pull: error: cannot unlink `/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/gconv': Directory not empty
>
> When you do ‘guix pull’, the resulting (guix config) is supposed to
> honor the settings of the calling ‘guix’: %localstatedir, etc.
>
> It seems that it wasn’t the case here?  Could you try again running
> ‘guix pull’ from a ‘guix’ command that has non-default settings and
> check the resulting (guix config) module?

Is (guix config) enough?  What about the daemon?  I’ve had no problem
with “guix” itself when used with a daemon taken from the git checkout.

>> Can we make the daemon detect that its understanding of the site differs
>> from that of the Guix client?
>
> I don’t see how that could be done.  The daemon necessarily assumes that
> its database is authoritative.
>
> This kind of issue was supposed to happen only when building from
> source, but in that case, ./configure tries hard to protect against
> that.  Here it seems that the real issue is that ‘guix pull’ produces a
> ‘guix’ that does not honor your settings.

This is confusing, because I *am* using the “guix” client from whatever
“guix pull” produces.  It’s just the daemon that works against me when I
take it from the same directory as the “guix” client.

So, “guix-daemon” currently runs from the git checkout, and all users
talk to it with “guix” from various runs of “guix pull” (we initially
pulled using the properly configured version from the git checkout).

> Anyway, I hope you managed to recover from it without too much hassle.

Yes, I was able to identify the corrupt store items and copy the
corresponding items from a separate machine.  I was lucky that it
aborted early when trying to delete items, so it seems that it didn’t
get to do all that much damage.

(Curiously, I wasn’t able to run “guix gc --verify=repair,contents”
because Guix claims I don’t have sufficient privileges to repair the
store — I’m running this as root, but who knows how NFS complicates
things…)

--
Ricardo