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

[Alexander Smirnov <asmirnov@ilbers.de>]

On 11/21/2017 09:40 PM, Alexander Smirnov wrote:
> 
> 
> 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.
>>

Applied to next.