From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6487873561298993152 X-Received: by 10.28.184.138 with SMTP id i132mr318950wmf.30.1511289104976; Tue, 21 Nov 2017 10:31:44 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.152.145 with SMTP id a139ls442383wme.3.canary-gmail; Tue, 21 Nov 2017 10:31:44 -0800 (PST) X-Google-Smtp-Source: AGs4zMaho77vaQuNS3jad9qdnAePW1o0c2weEIsXrx5u48/EA89h/F4L7LuoRF+Xf2oOTVjP6+0g X-Received: by 10.28.203.142 with SMTP id b136mr281142wmg.3.1511289104535; Tue, 21 Nov 2017 10:31:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511289104; cv=none; d=google.com; s=arc-20160816; b=oI6/bkH4hJj9cpH6cYWoN1gnqRtyl+lSyn/O1Bbd1Q6BrTHTi0BdFZ4K5J3NWim34p QOQVE7flHIq6pWchCNplJqWxj5QqlnI9GiLUVzzNTveJCMs40n+f3pfOlI8HPgTINYp/ Lik+iHKLOU7oZKwCK0r5Xwy00xqxJuMR1kOY+rxvEvJJpeys+ZevUduEMM3ijfuAHdIr koVl0afqcG353mps0g6/z96ubzqcNMFdm3ALCF0GJHfGTxjA+12CTYXdFja/g6x0AqDQ b6Jq6JHaHD+Q1EEX4RjBedVbRTPlIHrWhKN5Je8R7qo016nOrECeJNo1J62jwhPlsn+D 5U6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=oO8FTauN0VeX7GcP+FESTG0hJu4dYuA/Lpi128IdBSU=; b=xhPKEueCSscJ+VcHIc2UI0+BX9HaGRoZu6KQUKi6TT73WXzduw32en3OVD7sXQAS8x VAeFiZKpbt6IMvZxWvv3/ztcBLnf1RooiPO8xdQT/89bJX299ERGP18WEFxe8HswsC4d QC5HWt4WHGij9NwfU8qPBzzFQDiQtftm6Av/Lyex3H8Hxxe4GFf+3deCm45h9L9J+FIT JTdhEO+SLVhZHPfz5EQWUzMosKrXWGn4P8wpkXNhMRZne9a1JSdPkg5ZeoJ/P3i00Ata PwLkt58nxnOpmPk9XWQBHl813yR3ERL9ogYy2hX3Eo5iKGDeb0x+jJS0wTD6dxTPIWPT Lvig== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id t37si1208228wrc.3.2017.11.21.10.31.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 10:31:44 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id vALIVhvR028817 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Nov 2017 19:31:44 +0100 Received: from md1em3qc ([139.25.68.40]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id vALIVhvg003459; Tue, 21 Nov 2017 19:31:43 +0100 Date: Tue, 21 Nov 2017 19:32:01 +0100 From: Henning Schild To: Alexander Smirnov Cc: Subject: Re: [PATCH] build.sh: Fix perl complaints about locale Message-ID: <20171121193201.3d794469@md1em3qc> In-Reply-To: References: <20171113122151.19409-1-christian.storm@siemens.com> <00f7d3a1-8aab-ac7b-6d30-289de2dfa036@ilbers.de> <20171121094213.0f32a817@md1em3qc> <20171121190449.4927caa8@md1em3qc> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: ecLknG6BO6hZ Am Tue, 21 Nov 2017 21:12:35 +0300 schrieb Alexander Smirnov : > Hi, > > On 11/21/2017 09:04 PM, Henning Schild wrote: > > Am Tue, 21 Nov 2017 11:56:57 +0300 > > schrieb Alexander Smirnov : > > > >> On 11/21/2017 11:42 AM, Henning Schild wrote: > >>> Am Fri, 17 Nov 2017 13:42:05 +0300 > >>> schrieb Alexander Smirnov : > >>> > >>>> 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 > >>>>> --- > >>>>> 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? > 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. Henning > Alex