On Thu, 2019-09-05 at 18:19 +0100, Daniel P. Berrangé wrote: > On Thu, Sep 05, 2019 at 07:08:27PM +0200, Fabiano Fidêncio wrote: > > It seems to happen because both debian & fedora (30+) containers do > > not have the required locale. > > I'd like to ask your suggestion on how to proceed here: > > - Shall we explicitly include glibc-langpack-en as part of the base packages? > > - Its dependencies are: glibc, glibc-commonl > > - Its size is: 6.0 M (on Fedora 30); > > - Shall we work around osinfo-db tests in a way that we can make it > > work without setting the locale? > > In theory C.UTF-8 is our desired locale, but that is a non-standard > concept that is only carried as a downstream patch by certain distros. > Upstream glibc has not accepted it. It doesn't exist at all on *BSD. > Thus we picked en_US.UTF-8 as the only option that gives us UTF-8 > which is portable across all known operating systems. > > If you can't set the locale, the only option is to mandate python > 3.7 as the minimum python version, which I think is too strict. > > IOW, we shoud just intall the langpack. Sounds like a reasonable enough explanation to me. > FWIW, I'm proposing the exact same en_US.UTF-8 env var for libvirt > python code, so we'll need to deal with the same problem shortly > there too. When talking to Fabiano about this, I suggested we might want to add the locale to the 'base' pseudo-project along with tools like git and patch, and reading the above seems to confirm that's indeed the direction we should go. -- Andrea Bolognani / Red Hat / Virtualization _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
