UTF-8 in BLFS Wiki (was: bash wants en_US locale)

Alexander E. Patrakov patrakov at ums.usu.ru
Thu Feb 9 06:27:46 PST 2006

Randy McMurchy wrote:

> If a package
>+    is not listed here, it does not mean there are no known locale-specific
>+    issues or problems with that package. It only means that this page has not
>+    been updated with the locale-specific information regarding that package.
>+    Please reference the BLFS Wiki page for a particular package for any
>+    additional locale-specific information. </para>
That's much more accurate. Thanks.

As for me using BLFS as a scapegoat and excuse-bed, I understand that I 
am the only source of delays. But do you really expect me to verify all 
packages before the next release? Or is this LFS/BLFS release going to 
be delayed just because of that?

For the Wiki: I was going to add the Lynx page today. But I didn't, and 
won't add anything (because I don't want to call anything tested while 
it really isn't) until I resolve iconv issues in my uClibc-based HLFS 
build or get explicit permission from HLFS developers to ignore this 
configuration. To make long story short (I was going to report it after 
investigaing possible solutions):

echo A | iconv -f UTF-8 -t XXX

For XXX being ISO-8859-{4,5,6,7,8,9} or KOI8-R, the printed result is 
not "A" but "?A" which is incorrect (note: ASCII-only breakage!). This 
means that the core character conversion functionality is broken in 
uClibc-based HLFS (and please don't say "we don't care about converting 
text from UTF-8 encoding" because some packages, e.g. GTK2, work by 
always manipulating UTF-8 text and later converting to locale encoding).

Alexander E. Patrakov

More information about the hlfs-dev mailing list