Adding a C.UTF-8 locale to our glibc packages

[Carlos O'Donell]

On 09/16/2015 09:55 AM, Mike FABIAN wrote:
> 
> This patch adds a C.UTF-8 locale as a folder /usr/lib/locale/C.utf8/
> to our glibc packages.

The patch looks good to me, but I don't see the changes where you
add this to /usr/lib/locale/C.utf8? Did you miss adding a patch?

Thanks again for all the help Mike.

Note that on old systems where /usr is not pre-mounted, you won't have
this locale, or any locales available. That's fine and expected, but
just a point I wanted to make, and that we should keep in mind for
non-builtin locales.

> But unfortunately it does not work like that in glibc, which is probably
> a bug.

Please file a placeholder bug upstream for this, since it should work.

Please also file a bug for adding C.UTF-8 to upstream glibc, so we can
reference this bug when doing the upstream port. Do not suggest an
implemetnation though. When we push upstream we'll show that our implementation
is simply to build another locale and install it.

Lastly, file a bug stating that the C and POSIX locales are not conforming
because they include more than <space> and <tab> in <blank>. This is to
cover our own work here, and show that it is an existing bug that more than
these are in blank. I would also suggest the bug say "Alternatively we can
file an issue with the Austin Group to adjust the text not to forbid more
characters being included in blank."

> I tried to look at the code to find out why UNDEFINED does not work as
> specified in the standard but could not figure it out yet.
> 
> (UNDEFINED currently does not work at all as specified, most locale
> sources have UNDEFINED somewhere, but the characters not specified
> explicitly do not get inserted where UNDEFINED is but instead right at
> the top (before all other charcters).

Cheers,
Carlos.