Hi,
Thank you both.
One thing that could be fixed quite quickly is fixing the few
remaining official buildd workers that does not yet run with an UTF-8 locale.
If one is unlucky the build will mysteriously fail.
Adding export {LC_ALL|LANG|LC_CTYPE}=C.UTF-8
in every single d/rules by fear of this seems overkill.
Greetings
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074586
https://buildd.debian.org/status/package.php?p=xrayutilities
Le mar. 2 juil. 2024 à 14:37, Guillem Jover <guil...@debian.org> a écrit :
>
> Hi!
>
> On Tue, 2024-07-02 at 09:52:05 +0100, Simon McVittie wrote:
> > On Tue, 02 Jul 2024 at 03:47:29 +0200, Guillem Jover wrote:
> > > On Fri, 2024-06-07 at 15:40:07 +0200, Alexandre Detiste wrote:
> > > > Maybe a compromise would be to at least mandate some UTF-8 locale.
> > >
> > > dpkg-buildpackage: Require an UTF-8 (or ASCII) locale when
> > > building packages
> >
> > Allowing ASCII seems counterproductive: that puts us in the code path
> > where various tools and runtimes (especially Python) will refuse to
> > process or output anything outside the 0-127 range, which I believe is
> > exactly the problem that debhelper aims to solve by using C.UTF-8 for
> > some categories of package (in particular those that build with Meson).
> >
> > To get what Alexandre suggested, we'd need to allow UTF-8 but not allow
> > ASCII (so for example fr_FR.UTF-8 or C.UTF-8 is fine, but in particular
> > the C locale is not).
>
> But, I guess I can at least unconditionally set LC_CTYPE=C.UTF-8 when
> using --sanitive-env, right away though.
>
> Thanks,
> Guillem
>
