<div dir="ltr"><div class="gmail_extra">On 14 July 2016 at 19:58, Mark Hatle <span dir="ltr">&lt;<a href="mailto:mark.hatle@windriver.com" target="_blank">mark.hatle@windriver.com</a>&gt;</span> wrote:</div><div class="gmail_extra"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">Patching glibc to use the host system as a backup for the locales makes sense to<br></span><span style="font-size:13px">me as well.  However it is definitely more work and may not be worth it...</span></blockquote><div><br></div><div>Agreed and agreed, which is why I went with this patch.</div><div> </div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":13x" class="">In the buildtools case, do any of the other components we ship actually have<br>
localized content?  If we&#39;re shipping message catalogs for non-english systems<br>
-- then we definitely need non-english locale to work.  But if we&#39;re only<br>
shipping english -- C.utf-8 might be enough.</div></blockquote></div><br>The problem for buildtools shipping just C.UTF-8 is that the moment you have a system that needs buildtools and use them, you&#39;re forced into using C.UTF-8 for everything in that session unless you keep that terminal for just bitbake invocations.  If you&#39;re like me and often run git/emacs/meld/etc in the same terminal as bitbake and don&#39;t speak English then your experience is going to suffer.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Ross</div></div>