C.UTF-8 may not be present resulting in failed build

C.UTF-8 may not be present resulting in failed build

[Andrei Borzenkov]

Extra catalogs added in da0d5b3f explicitly require C.UTF-8 locale. This 
locale may not be present (e.g. openSUSE does not have it).

Upstream gettext (and hence en@quot rules) does not use it. Is forcing 
this locale really needed?

Re: C.UTF-8 may not be present resulting in failed build

[Mike Gilbert]

On Mon, Nov 2, 2015 at 1:47 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> Extra catalogs added in da0d5b3f explicitly require C.UTF-8 locale. This
> locale may not be present (e.g. openSUSE does not have it).

I think it is specific to Debian-derived distros actually. We don't
have it on Gentoo either.

Re: C.UTF-8 may not be present resulting in failed build

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

Le 2 nov. 2015 7:48 PM, "Andrei Borzenkov" <arvidjaar@gmail.com> a écrit :
>
> Extra catalogs added in da0d5b3f explicitly require C.UTF-8 locale. This
locale may not be present (e.g. openSUSE does not have it).
>
> Upstream gettext (and hence en@quot rules) does not use it. Is forcing
this locale really needed?
>
>
We use them in tests as an easy alternative to real translations. But we
can generate them without this locale. We could replace y sed command with
bunch of s and use pain C locale
_______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

[-- Attachment #2: Type: text/html, Size: 917 bytes --]

Re: C.UTF-8 may not be present resulting in failed build

[Andrei Borzenkov]

03.11.2015 21:44, Vladimir 'phcoder' Serbinenko пишет:
> Le 2 nov. 2015 7:48 PM, "Andrei Borzenkov" <arvidjaar@gmail.com> a écrit :
>>
>> Extra catalogs added in da0d5b3f explicitly require C.UTF-8 locale. This
> locale may not be present (e.g. openSUSE does not have it).
>>
>> Upstream gettext (and hence en@quot rules) does not use it. Is forcing
> this locale really needed?
>>
>>
> We use them in tests as an easy alternative to real translations. But we
> can generate them without this locale. We could replace y sed command with
> bunch of s and use pain C locale

But it has C.UTF-8 not only for sed, but for all other commands 
invocations. Is it really needed