Re: [PATCH] build.sh: Fix perl complaints about locale

[Alexander Smirnov <asmirnov@ilbers.de>]

On 11/21/2017 09:32 PM, Henning Schild wrote:
> Am Tue, 21 Nov 2017 21:12:35 +0300
> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> 
>> Hi,
>>
>> On 11/21/2017 09:04 PM, Henning Schild wrote:
>>> Am Tue, 21 Nov 2017 11:56:57 +0300
>>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
>>>    
>>>> On 11/21/2017 11:42 AM, Henning Schild wrote:
>>>>> Am Fri, 17 Nov 2017 13:42:05 +0300
>>>>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
>>>>>       
>>>>>> Hi,
>>>>>>
>>>>>> On 11/13/2017 03:21 PM, Christian Storm wrote:
>>>>>>> The log.do_build is flooded by perl's locale complaints:
>>>>>>>
>>>>>>>         perl: warning: Setting locale failed.
>>>>>>>         perl: warning: Please check that your locale settings:
>>>>>>>                 LANGUAGE = (unset),
>>>>>>>                 LC_ALL = "en_US.UTF-8",
>>>>>>>                 LANG = (unset)
>>>>>>>             are supported and installed on your system.
>>>>>>>         perl: warning: Falling back to the standard locale ("C").
>>>>>>>
>>>>>>> Make perl happy by explicitly giving it the C locale.
>>>>>>>
>>>>>>> Signed-off-by: Christian Storm <christian.storm@siemens.com>
>>>>>>> ---
>>>>>>>      meta/recipes-devtools/buildchroot/files/build.sh | 2 +-
>>>>>>>      1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/meta/recipes-devtools/buildchroot/files/build.sh
>>>>>>> b/meta/recipes-devtools/buildchroot/files/build.sh index
>>>>>>> 19d554e..e53d359 100644 ---
>>>>>>> a/meta/recipes-devtools/buildchroot/files/build.sh +++
>>>>>>> b/meta/recipes-devtools/buildchroot/files/build.sh @@ -23,4
>>>>>>> +23,4 @@ for i in configure aclocal.m4 Makefile.am Makefile.in;
>>>>>>> do done
>>>>>>>      # Build the package
>>>>>>> -dpkg-buildpackage
>>>>>>> +LC_ALL=C LANGUAGE=C LANG=C dpkg-buildpackage
>>>>>>>          
>>>>>>
>>>>>> short question, does LC_ALL override LANG value?
>>>>>
>>>>> No. Try "LC_ALL=C locale", as the name says it overrides LC_*. But
>>>>> you are right LC_ALL might be enough to get rid of the warnings.
>>>>
>>>> I'm asking because it's not so clear for me. What I've got from
>>>> various links, LC_ALL overrides LANG:
>>>>
>>>> https://docs.oracle.com/cd/E23824_01/html/E26033/glmbx.html
>>>>
>>>> ...
>>>>     If the LC_ALL environment variable is set, it overrides LANG and
>>>> all the separate locale categories.
>>>> ...
>>>>
>>>> https://www.gnu.org/software/gettext/manual/html_node/Locale-Environment-Variables.html
>>>>
>>>> ...
>>>> LC_ALL is an environment variable that overrides all of these...
>>>> As a user, you therefore have to unset this variable if you want
>>>> to set LANG and optionally some of the other LC_xxx variables.
>>>> ...
>>>>
>>>> https://wiki.archlinux.org/index.php/locale#LC_ALL:_troubleshooting
>>>>
>>>> ...
>>>> The locale set for this variable will always override LANG and all
>>>> the other LC_* variables, whether they are set or not.
>>>> ...
>>>>
>>>> And so on...
>>>>
>>>> I wonder if there is some reference place where it's strictly
>>>> defined whether or not LC_ALL overrides LAND.
>>>
>>> Ah sorry i read it wrong. LC_ALL sets the others, not sure which
>>> one is the strongest. But why does it matter? You control all 3 and
>>> likely setting LC_ALL will mute the warning.
>>
>> The problem is that all variables come from your host environment to
>> chroot. So if host LC_*/LANG variable differs from en_US.UTF-8 - it
>> could be a problem in chroot. So we should override everything that
>> goes from the host.
> 
> Does not bitbake clear the env except for a few well-known variables?
> Or are those on BB_ENV_WHITELIST or otherwise leaking into bitbake?
>

Good point, didn't check this. I tested env by runing chroot manually 
from shell. Will check, thanks!

>> So I'm in doubts whether LC_ALL stronger than LANG or not,
>> documentation frustrates me :-) For sure, I propose to use both LANG
>> and LC_ALL in the patch.
> 
> Even if bitbake inherits them from the host, just set them all to the
> same value. Who cares which "C" wins.
> 

Ok.

Alex

> Henning
>   
>> Alex
>