From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6487873561298993152 X-Received: by 10.46.116.16 with SMTP id p16mr67503ljc.0.1510913642643; Fri, 17 Nov 2017 02:14:02 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.4.149 with SMTP id a21ls347403ljf.12.gmail; Fri, 17 Nov 2017 02:14:02 -0800 (PST) X-Google-Smtp-Source: AGs4zMaIG7M5Ds90QnnuaN+YFNID6fT5sHHJr1g5vLkvpGUCbZy7M7tkHiwYOcu4dGFqBZHTkn1e X-Received: by 10.46.77.20 with SMTP id a20mr63439ljb.35.1510913642260; Fri, 17 Nov 2017 02:14:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510913642; cv=none; d=google.com; s=arc-20160816; b=GkWasRd+yK7EB3EFyUIeZVfsKE0oZ8CNlAQ8evMw2IBwu5h+kP5SNXhnQOf8YORuFl uRbND9VmXhlokaHfdWHU1guqtsDVB+COea9MHcWHSuXSkMseAfxim0hTqY6B54H7VOhH p1NpxlzNksECpu1E+vmLsiduZRv+Wr7bQJ5UZfZj3ROdUXnmCJ/Plg+HPSGbRZwgEfTk qCPhW4tjdA5AodmhGSSREccV5WavRrKGDF4Y7MNYx9q7sScelN9o4LNA3qdo0a46iJ1D DWuw33PGDwSQZhTmi895yH/REA4p0qNg4wvGB9f1Npz+b4VKOwAZhyV9S14+pR48oWR7 T0/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:mail-followup-to:message-id :subject:to:from:date:arc-authentication-results; bh=4vuyKQhS7UiMSpbvk9bqmDbtNzXbJDcs0gDajAOuLrw=; b=kgweAK+gOcihZChOcZHgrH7r7+TW09FfWLdlbKfGoS3cFJRd2NTY/4COVI/uk+9GHH eZYTv8i0pwb8gR9Zrc1zpYa/ei9VQ6Ti3wQL/7dyFxHFbfof+cvY/ecJU5nCzu8gq7Zl vQMrSfIdH7HmShWUIptW6jwgPkIms7a0mU97K6t/gQzfAFwYRBwvsbMqp3k1N5IMsVlt k6z4FzoQht/YZtJ1xOysk7B2q+PGSbDGTKJNDptlGbkLEuP+anfv3qZvt75+OnPzgsGT dOU4kwRZR2sOcDl6JMUyA3nAebE5JbkZ7LT6hM+o16s/XQHZGlg9Re0Hu3wTbfiIXmtx PIGg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of christian.storm@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=christian.storm@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id l14si295333lje.1.2017.11.17.02.14.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 02:14:02 -0800 (PST) Received-SPF: pass (google.com: domain of christian.storm@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 christian.storm@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=christian.storm@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 vAHAE1i1032442 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 17 Nov 2017 11:14:01 +0100 Received: from localhost ([139.25.69.251]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTPS id vAHAE1xd005319 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 17 Nov 2017 11:14:01 +0100 Date: Fri, 17 Nov 2017 11:12:47 +0100 From: Christian Storm To: isar-users@googlegroups.com Subject: Re: [PATCH] build.sh: Fix perl complaints about locale Message-ID: <20171117101247.dnpqredxybd6oqjx@MD1KR9XC.ww002.siemens.net> Mail-Followup-To: isar-users@googlegroups.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5e5c4544-67ae-7870-10ca-bd91457efd96@ilbers.de> User-Agent: Mutt/20170113 (1.7.2) X-TUID: YUIfDY7zhWwf > >>>>> [...] > >>>>> > >>>>> 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'. Ah, that would explain why an explicit *re*-configuration in configscript.sh helps in this case... Thanks for digging deeper! > [...] > > 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. Agreed. > 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. Yes. However, I do not have double-checked whether this is the only point where this has to be inserted... > 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. Hm, I'm indecisive whether this is a good idea or not. English is the lingua franca and hence makes it easy to Google for errors if you don't understand the error message, potentially yielding more results than localized Googling. That said, I'm not against the idea, it would just have a close to none priority for me :) Kind regards, Christian -- Dr. Christian Storm Siemens AG, Corporate Technology, CT RDA ITP SES-DE Otto-Hahn-Ring 6, 81739 M�nchen, Germany