On Tue, Apr 23, 2013 at 07:26:21PM +0200, Simon Chopin wrote:
Quoting Toshio Kuratomi (2013-04-23 18:58:14)
> On Tue, Apr 23, 2013 at 04:20:07PM +0200, Simon Chopin wrote:
> > The locales weren't named in a consistent fashion, which makes it a pain
> > when generating them for automatic testing.
> > This patch renames the locales consistently, although I'm not sure for
> > the ISO variant.
> >
> Does it matter what spelling is used or is it simply that you need them to
> be consistent? There's some incosistencies in the tools I'm using to
lookup
> what locales should look like:
>
> locale -m lists UTF-8 and ISO-8859-1
>
> locale -a has things in the form en_US.utf8 and en_US.iso88591
>
> I suspect that glibc has internal handling to canonicalize both forms but I
> kinda lean towards the latter if standardizing on that form will work for
> you.
>
> Also, what's the automated testing thing you mention? I'd like to
> understand what the use case is that this breaking so I don't do it
> intentionally :-)
I'm packaging kitchen for Debian as it is a dependency for fedmsg, which
is the object of my GSoC proposal. We have for policy to run test suites
when available, and since the packages are built in a minimal
environment I simply build the locales manually, which means that I
don't get to use the glibc canonicalization stuff (which is probably at
generation time).
I don't particularly care about which form we use, utf8 or UTF-8, as
long as all tests use it, which is currently not the case.
After checking, I have the same results as you do (and the dpkg
configuration screen for locales also give another variant, UTF8). Yay
for consistency ;-)
Applied with the changes mentioned:
http://bzr.fedorahosted.org/bzr/kitchen/devel/revision/444
and for the beta level python3 port:
http://bzr.fedorahosted.org/bzr/kitchen/py3port/revision/449
Feel free to let me know if you encounter any other problems.
If you need a new release let me know, otherwise it'll probably just hang
out in the bzr repo for a while.
-Toshio