bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#73181: guix-daemon fails when invoking ‘guix authenticate’ on the Hu


From: janneke
Subject: bug#73181: guix-daemon fails when invoking ‘guix authenticate’ on the Hurd
Date: Thu, 31 Oct 2024 20:14:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Ludovic Courtès writes:

Hi!

> Ludovic Courtès <ludovic.courtes@inria.fr> skribis:
>
>> Inside the childhurd, we get:
>>
>> root@childhurd ~# tail -1 /var/log/guix-daemon.log 
>> 2024-09-09 21:09:03 unexpected build daemon error: stoi
>>
>> Last time we got that error was in commit
>> 21deb89e287b5821975544118bf137562a91d4e1: guix-daemon was running with
>> incorrect locale data, and thus ‘std::stoi’ would throw (‘std::stoi’ in
>> guix-daemon is used for the communication with the ‘guix authenticate’
>> process, see ‘readAuthenticateReply’).

[snip some great debugging, phew!]

> That warning comes from libgc and there’s no such warning when LC_ALL is
> left unset, which is why it works in that case.

How about

   0. Unsetting LC_ALL on the Hurd

would that work?

> I see several possible things to do:
>
>   1. Disable GC warnings altogether in Guix by setting ‘GC_warn_proc’.
>
>   2. Make sure guix-daemon discards stderr from agents such as ‘guix
>      authenticate’.
>
>   3. Figure out why those “Repeated allocation” messages are so frequent
>      on i586-gnu and Do Something About It™.
>
> Thoughts?

If 0., which seems easiest, does not work then Obviously(?) 3. is nicer
but (much?) harder than 2., which is nicer than 1.  However, 1. is much
nicer than our current situation of not having offloading to our
childhurds and not having up-to-date substitutes.  How about doing
1. right now but only for the Hurd, until we get 2. or 3.?

Greeting,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com





reply via email to

[Prev in Thread] Current Thread [Next in Thread]