GNU bug report logs - #35874
guix-daemon from "guix pull" does not honor user settings

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
Cc: 35874 <at> debbugs.gnu.org
Subject: bug#35874: “guix pull” fails on setlocale
Date: Fri, 24 May 2019 15:49:01 +0200

Hello Ricardo,

Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:

> This is a store corruption bug.
>
> The problem appears to be that I accidentally ran the daemon with the
> wrong GUIX_DATABASE_DIRECTORY.  The localstatedir is /gnu/var, not /var.

Ouch.  :-/

> 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?

> 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.

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

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.