Ludovic Courtès writes: > Hi, > > Janneke Nieuwenhuizen <jann...@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 <jann...@gnu.org> | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com