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

[Alexander Smirnov <asmirnov@ilbers.de>]

On 11/13/2017 08:06 PM, Henning Schild wrote:
> Am Mon, 13 Nov 2017 19:50:01 +0300
> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> 
>> Hi,
>>
>> On 11/13/2017 07:10 PM, Henning Schild wrote:
>>> Am Mon, 13 Nov 2017 16:24:01 +0100
>>> schrieb "[ext] Christian Storm" <christian.storm@siemens.com>:
>>>    
>>>>>>>>>>> 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
>>>>>>>>>>>      
>>>>>>>>>>
>>>>>>>>>> There is code that should setup locales for current
>>>>>>>>>> buildchroot:
>>>>>>>>>>
>>>>>>>>>> https://github.com/ilbers/isar/blob/master/meta/recipes-devtools/buildchroot/files/configscript.sh#L8
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So it would be nice to fix this globally instead of local
>>>>>>>>>> solution.
>>>>>>>>>
>>>>>>>>> Sure, but this alone doesn't solve the problem as you have to
>>>>>>>>> put the locale into every (sudo) environment. Then, what
>>>>>>>>> about
>>>>>>>>
>>>>>>>> Hmm, it works as it is for archs different from host machine.
>>>>>>>> I've attached 3 build logs for hello application in Stretch:
>>>>>>>> amd64, arm and i386 and only *amd64* has locale flood. The
>>>>>>>> others are OK. So that's why I think it's rather bug in
>>>>>>>> configscript.
>>>>>>>
>>>>>>> Working on PRoot I've found the following multistrap option:
>>>>>>>
>>>>>>> "ignorenativearch=true"
>>>>>>>
>>>>>>> Probably it could somehow help here...
>>>>>>
>>>>>> Hm, this sounds unrelated to me at first sight. I did a quick
>>>>>> local
>>>>>
>>>>> If I understand it correctly, that's the source of your issue. If
>>>>> multisrtap detects that target architecture is similar to host,
>>>>> then it tries to run in native mode and configscript doesn't work
>>>>> correctly.
>>>>>
>>>>> So the following patch fixes the issue for me:
>>>>>
>>>>> diff --git
>>>>> a/meta/recipes-devtools/buildchroot/files/multistrap.conf.in
>>>>> b/meta/recipes-devtools/buildchroot/files/multistrap.conf.in index
>>>>> 7e88608..28f2ee0 100644 ---
>>>>> a/meta/recipes-devtools/buildchroot/files/multistrap.conf.in +++
>>>>> b/meta/recipes-devtools/buildchroot/files/multistrap.conf.in @@
>>>>> -4,6 +4,7 @@ [General]
>>>>>     noauth=true
>>>>>     unpack=true
>>>>> +ignorenativearch=true
>>>>>     bootstrap=##DISTRO##
>>>>>     aptsources=##DISTRO##
>>>>>     configscript=##CONFIG_SCRIPT##
>>>>>
>>>>> Could you please try it?
>>>>
>>>> Done, and it fixes the problem as well.
>>>
>>> Not sure what "ignorenativearch" does, but "sed /etc/locale.gen &&
>>> locale-gen" is clearer and probably free of side-effects. Are we
>>> sure about all implications of ignorenativearch?
>>
>> To be honest, I don't exactly know what multistrap does in native
>> mode (to be investigated), but with "ignorenativearch=true" we can
>> guarantee that Isar has the same build flow for *all* the
>> architectures. Otherwise we will have 2 possible flows: for native
>> arch and for foreign archs, what could be the source of potential
>> bugs like we have now with locales.
> 
> True, but without that knowledge and looking at the one issue, i would
> prefer that patch that i understand ;).
> 

Yeah, but on the other hand:
  - There is dedicated code which should setup locales, seems it's 
broken in master for native builds now.
  - Instead of fixing it, yet another locale setup is proposed.
  - This new locale setup affects already working builds.
  - Old locale stays in the tree.

So, for me it would be better to spend a few hours to understand 
'ignorenativearch' option before taking any decision. I'd happy to this :-)

Alex

>>>>>> clean run with the following patch and it resolved the issue, for
>>>>>> me at least. Could you please also try a run with the patch
>>>>>> applied for all the arches? If it solves the issue I'll send a
>>>>>> proper patch. Thanks!
>>>>>>
>>>>>> ```
>>>>>> diff --git
>>>>>> a/meta/recipes-devtools/buildchroot/files/configscript.sh
>>>>>> b/meta/recipes-devtools/buildchroot/files/configscript.sh old
>>>>>> mode 100644 new mode 100755 index 9813c9a..1fd2061
>>>>>> --- a/meta/recipes-devtools/buildchroot/files/configscript.sh
>>>>>> +++ b/meta/recipes-devtools/buildchroot/files/configscript.sh
>>>>>> @@ -32,6 +32,9 @@ locales locales/locales_to_be_generated
>>>>>> multiselect en_US.UTF-8 UTF-8 locales
>>>>>> locales/default_environment_locale select en_US.UTF-8 END
>>>>>>     
>>>>>> +sed -i 's/^# en_US.UTF-8 UTF-8/en_US.UTF-8
>>>>>> UTF-8/g' /etc/locale.gen +dpkg-reconfigure
>>>>>> --frontend=noninteractive locales +
>>>>>>     #set up non-interactive configuration
>>>>>>     export DEBIAN_FRONTEND=noninteractive
>>>>>> DEBCONF_NONINTERACTIVE_SEEN=true export LC_ALL=C LANGUAGE=C
>>>>>> LANG=C ```
>>>>>>       
>>>>>
>>>>> For sure I'll try this patch, but first I'd like to clarify why
>>>>> dedicated code in configscript doesn't work.
>>>>
>>>> OK. I'll look forward to it. The perl errors are distractingly
>>>> annoying.. The manpage of multistrap has some words on it as
>>>> well...
>>>>
>>>>   
>>>>> P.S. am I right that you build target with the same arch as your
>>>>> host?
>>>>
>>>> Yes, as said, both x86_64.
>>>>
>>>>
>>>>
>>>> Besten Gruß,
>>>>      Christian
>>>>   
>>>    
>>
> 

-- 
With best regards,
Alexander Smirnov

ilbers GmbH
Baierbrunner Str. 28c
D-81379 Munich
+49 (89) 122 67 24-0
http://ilbers.de/
Commercial register Munich, HRB 214197
General manager: Baurzhan Ismagulov