bug#66472: Wrong ‘glibc-utf8-locales’ package used on GNU/Hurd

[Janneke Nieuwenhuizen]

Ludovic Courtès writes:

> Hi,
>
> Janneke Nieuwenhuizen <janneke@gnu.org> skribis:
>
>>> starting phase `remove-tests'
>>> error: in phase 'remove-tests': uncaught exception:
>>> decoding-error "decode-char" "input decoding error" 1073741930
>>> #<input: tests/misc/ls-misc.pl 15>
>
> [...]
>
>> Hmm.  I've briefly looked at this but failed to reproduce it.  I've
>> tried building coreutils, and coreutils-final in a childhurd created
>> from "a recent" hurd-team branch.
>>
>> root@guixydevel ~/src/guix/hurd-team [env]# ./pre-inst-env guix
>> build --keep-failed -e '(@@ (gnu packages commencement)
>> coreutils-final)' --without-tests=coreutils
>> [..]
>> environment variable `GUIX_LOCPATH' set to
>> `/gnu/store/sq6w1nfi59askjfq6b1nqq6z8ld5zh1l-glibc-utf8-locales-2.35/lib/locale'
>> [..]
>> phase `unpack' succeeded after 10.4 seconds
>> starting phase `remove-tests'
>> phase `remove-tests' succeeded after 0.5 seconds
>
> Maybe something differs on ‘hurd-team’?

Well, yeah.  I've been building in a childhurd created from
gnu/system/examples/devel-hurd.tmpl, which currently has

    (locale-libcs (if (system-hurd?)
                      (list glibc/hurd)
                      %default-locale-libcs))

> For me it’s 100% reproducible
> on ‘master’, even though my childhurd has
> /run/current-system/locale/2.37 (I thought this could interfere but
> luckily it doesn’t.)
>
> Anyway, in both cases the core issue remains: we’re building packages
> with the wrong locale data.
>
> The mismatch comes from the fact that ‘glibc-utf8-locales’ is a
> system-independent package: you get 2.35 regardless of the system you’re
> targeting.

Right.  Is that easy, difficult, or impossible to change?

Greetings,
Janneke

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