From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6487873561298993152 X-Received: by 10.28.21.67 with SMTP id 64mr164212wmv.8.1510838261297; Thu, 16 Nov 2017 05:17:41 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.63.20 with SMTP id m20ls266979wma.6.canary-gmail; Thu, 16 Nov 2017 05:17:40 -0800 (PST) X-Google-Smtp-Source: AGs4zMZ/4Z6R5vd7T6avIjzLwtcIvcMhTmwKGzMfurl3YoM3Fdzh4JQh8HJLjamLnvhQJr+LMtLN X-Received: by 10.28.20.11 with SMTP id 11mr201496wmu.29.1510838260935; Thu, 16 Nov 2017 05:17:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510838260; cv=none; d=google.com; s=arc-20160816; b=EwaR/28UMSV0WGsWTw29jfE6ubx6IoJ4+YWvQIY/r+1jLbntXoB11PlxgRj17xlOt+ /yJJEgpNp5a8FoVE4dAAMeCIv8j+Gy32Td3fY1AyA+ymqQT8qPh8sI9WEV+YXZeta6oJ AwfyAT2zVx2SXUDQ2gRIDVFwc/42JuF24OQAqAULzdCuwLJ7UVFq1KFPEUUirF91AsvJ eZfgkJ02nFtxC0KoK93of8v1Wvy9tO/eiYskKFl/sYuJIllJr+y19tqz9K9oobsRddq7 332eTiqjhs08MB91aqnMlyo4yAkiJgygy+XCvMsUka+F94IhnCnQDZlF5Ya/RJ1v2LRG 2Wgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :arc-authentication-results; bh=0jtkKyT2qetP25cfl0UsQWLKqJVS1iRfGwbDeQlSJzc=; b=gP0PKQyI+y8QgNdCDXQBW/2S51PIXO+l0iODuqwfLUVLnYpW5B1hSb9LB+5IR2pn+f axnSbdX7vBcVO6Fpa1+JMw3/HbeluBdfmAQJGRcgk2J267M53F/9bG7tfdfYL63rvV/s hykBpDhIguSyl9abZIEmR3wpcoHLQRhubpuL3TONcYXK/K71/HcFwgJvFDdku81zD+Bq S4+BY8dQQFRtRD1FMpzuWSkeUUmT4Rt1gYsoOXgvNNQoVQEp1sW3R+TMlOL+rFhOW+If AAhAmyIWhajKNm+5QGjMcXAfrErO8MnMmQj7Jx/KbYvUcp4xk270Z0ZrEMeWt6L7sT16 TopQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id l9si95237wrf.4.2017.11.16.05.17.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 05:17:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Received: from [10.0.2.15] ([188.227.110.165]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id vAGDHbGU018546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Nov 2017 14:17:39 +0100 Subject: Re: [PATCH] build.sh: Fix perl complaints about locale To: isar-users@googlegroups.com References: <20171114084152.dc56j6m5witxtn7c@MD1KR9XC.ww002.siemens.net> From: Alexander Smirnov Message-ID: <5e5c4544-67ae-7870-10ca-bd91457efd96@ilbers.de> Date: Thu, 16 Nov 2017 16:17:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171114084152.dc56j6m5witxtn7c@MD1KR9XC.ww002.siemens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: bdVQltdm/fwi Hi, On 11/14/2017 11:41 AM, Christian Storm wrote: >>>>> [...] >>>>> >>>>> 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. > > Well, strictly speaking, it's not yet another locale setup. If you do > the `sed` and `dpkg-reconfigure locale` it's merely an explicit setup, > more of the same so to say. The `dpkg --configure -a` at the bottom of > configscript.sh may not *re-*configure a (wrongly) configured locale > package. Sorry, don't understand why locales could be miss-configured and reconfigure is needed: 1. Here we define the default locale: https://github.com/ilbers/isar/blob/next/meta/recipes-devtools/buildchroot/files/configscript.sh#L8 2. Here is the first dpkg --configure is called: https://github.com/ilbers/isar/blob/next/meta/recipes-devtools/buildchroot/files/configscript.sh#L46 In your case for native arch, there is a bug in Isar, that postinst scripts are run by multistrap before 'configscript.sh'. > >> - This new locale setup affects already working builds. > > Yes, to the extent that after locale setup, a *re-*configure is > explicitly triggered. Shouldn't be a problem but instead intended > behavior as you may have changed the locale in configscript.sh above > this line nonetheless. > >> - Old locale stays in the tree. > > With my commit > ec997ad "isar-image-base: purge locales and installed packages' .deb", > unused locale are purged. Or didn't I get the point here? > >> 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 :-) > > Independently of the issue at hand, this is a very welcome proposal of > yours! I'd like to hear the results... > > That said, from a quick multistrap manpage glimpse, I read > "A native multistrap can be used directly with chroot, so "multistrap" > runs "dpkg --configure -a" at the end of the multistrap process, unless > the ignorenativearch option is set to true in the General section of the > configuration file." > > So, on native multistrap, `dpkg --configure -a` is run if ignorenativearch=false. > Otherwise, if ignorenativearch=true, it's not run. > However, `dpkg --configure -a` is run unconditionally in configscript.sh... > After thinking about this problem I have the following summary: 1. 'ignorenativearch=true' should be used. It prevents multistrap from early postinst scripts execution. That is needed to guarantee that all the architectures are handled in the same way. EFFECT: with this change we have correctly generated locales for en.UTF-8. 2. The initial patch from Christian is needed. AFAIK, chroot by default inherits environment from host system (including LC_* variables). So if user has different locale set on the host (for example de.*), then annoying locale flood in buildchroot will appear again, because in buildchroot only en.UTF-8 is generated. EFFECT: this patch will guarantee, that en.UTF-8 will be used in buildchroot despite on host settings. 3. We should consider the possibility to change locale in buildchroot for users who don't speak English good enough to understand compiler/other tools output. So I propose to define some variable in, for example, local.conf, which will define the default locale for buildchroot and target image: DEFAULT_LOCALE ?= "en.UTF-8" and then 'sed' configscripts.sh script accordingly. Alex