locales problems with edgy libc6

Yup, known bug. Will fix shortly.

I think it is still broken in libc6_2.4-1ubuntu4_i386

I have problem with perl showing :
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "fr_BE.UTF-8",
        LC_ALL = (unset),
        LANG = "fr_BE.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

If I type locale :
locale: Impossible de configurer LC_ALL à la langue par défaut: Aucun fichier ou répertoire de ce type
LANG=fr_BE.UTF-8
LANGUAGE=fr_BE.UTF-8
LC_CTYPE="fr_BE.UTF-8"
LC_NUMERIC="fr_BE.UTF-8"
LC_TIME="fr_BE.UTF-8"
LC_COLLATE="fr_BE.UTF-8"
LC_MONETARY="fr_BE.UTF-8"
LC_MESSAGES="fr_BE.UTF-8"
LC_PAPER="fr_BE.UTF-8"
LC_NAME="fr_BE.UTF-8"
LC_ADDRESS="fr_BE.UTF-8"
LC_TELEPHONE="fr_BE.UTF-8"
LC_MEASUREMENT="fr_BE.UTF-8"
LC_IDENTIFICATION="fr_BE.UTF-8"
LC_ALL=

Neither a dpkg-reconfigure or an apt-get install --reinstall locales language-pack-fr-base language-pack-fr did the trick.

allcolor it still is broken they are working on fixing it. i would give it maybe 2 more days at least before the fix is uploaded. but seeing as its of high importance i imagine it will be done by mid week. Welcome to life of testing ;)

Yup, I've spent a couple days on it and am running more builds now to test fixes for the problem. As always it's impossible to promise a fix time, but this is the only bug I'm working on right now.

take your time lol other than being annoying i cant see anything it really messes up atm. and people using edgy at this point should relize its gonna be a bit unstable.

No worries, Jeff, take your time. I realized something like this was pretty likely to happen when upgrading to edgy;-)

I just reported this so that this strange occurance is documented.

This locale issue does cause some problems: eclipse crashes due to some locale issue occassionally, my own software behaves a bit unpredictable, apt-listchanges does not like this at all and just quits, etc. Nothing mayor jet, but it is more than annoying. Just mentioning... maybe it will stop somebody from filing bugs on the symptoms of this one.

On Tue, 2006-06-13 at 13:06 +0000, John Vivirito wrote:
> i cant see anything it really messes up atm.

Well it messes up python programs. For instance, Listen bails on me cos
it can't set the locale.

On Tue, 2006-06-13 at 13:06 +0000, John Vivirito wrote:
> i cant see anything it really messes up atm.

Well it messes up python programs. For instance, Listen bails on me cos
it can't set the locale.

it messes up more than that but i dont concider it a "showstopper" atm. i wouldnt use a pre alpha for work reasons anyway. but my opinion

Hum I posted this only because it was hard to relate the given error messages about locales to a broken libc (while here I don't know what is broken in it, could I have a hint ?). Now it will be indexed by search engine I hope ,)

Anyway it was not meant as an "hurry up" message ;) I know edgy is the unstable version and that's why I have it. I know things get broken, but if launchpad is correctly filled with symptoms about a bug, people will have easier to find a solution to their problems (in this case, simply being patient will suffice).

Sure. When doing locales work, there are three pieces:

 * setlocale - sets up the system to use either a locale you choose, or retrieve it from the environment.

 * bindtextdomain - Tells glibc where to find the message files.

 * dcgettext - Actually looks up the localised message in the .mo file and returns it.

In glibc, they delay initialisation as long as possible (until the first dcgettext call). However, for some reason dcgettext isn't actually causing the message to be retrieved. It's not even openning the message file.

I've spent a couple full days with strace and ltrace and trying a few patches, but the problem is deeper than I originally suspected. My next encounter is a date with gdb and step.

Hope that helps. =)

Tks,
Jeff Bailey

Doing an strace on locale, it looks like it is trying to load files from a directory "/usr/lib/locale:/usr/share/locale-langpack/{charset}/LC_COLLATE"

Which is incorrect, creating a directory "locale:" under /usr/lib and creating a link on /usr in it will throw away "-1 ENOENT (No such file or directory)" from the systrace (so the loading succeed) while it does not resolve anything.

What is strange, I don't know which manipulation I did, but I have localised text with locale now but still perl does not like and other programs too.

When I first encounter the problem I couldn't enter accentued letter in a terminal... now I can.

Also why locales are spread between /usr/lib/locale /usr/share/locale /usr/share/locale-langpack ?

Thank you

Right, the : path thing was a separate bug that I have a solution for in hand, but it doesn't solve the second problem, which is that it's never even trying to load coreutils.mo.

If you want to see something amusing, try doing "export LOCPATH=/", and then the : problem that you see there will go away. It treats the default path only like a path where LOCPATH is defined. Otherwise, it sees it as a single block. glibc isn't internally consistant in these cases, which I need to clean up and send upstream.

In practice what we're doing is saying "When the user asks for his/her files in /usr/share/locale, also look in /usr/share/locale-langpack". But even with all our patches removed, it's still not searching for the coreutils.mo file. That was the build that I ran overnight last night. More hacking to come.

Tks,
Jeff Bailey

On Tue, 2006-06-13 at 17:46 +0000, John Vivirito wrote:
> i wouldnt use a pre alpha for work reasons anyway.

That's exactly how I use "pre alpha" - to test it to the fullest
possible degree.

personally speaking i wouldnt use it as a production pc but people will do as they wish.

Well, what about the people who like testing new releases of Ubuntu? I'm now running Edgy (and of course, am bitten by this bug) on my primary use workstation. ie, on a "production system".

Well, we can have this discussion on the Edgy Forum. Malone is for
discussing bugs, not what we do with our computers. Please, don't
clutter up this thread. If you've got something useful to post, please
post it. I'm sorry I sparked this debate.

Please look also at (maybe related) Bug #50363 about gconv_db.c

hmm... I looked at findlocale.c/setlocale.c.

Maybe we must use argz(\0 seperated list) to _nl_default_locale_path
 (use __argz_append(&locpath, &locpath_len, _nl_default_locale_path, sizeof _nl_default_locale_path) to setlocale.c & newlocale.c),
or convert _nl_default_locale_path to argz, inside _nl_find_locale (findlocale.c).

My problem disappeared with first solution
 (and update GLIBC_MAGIC to 20051014 on belocs/locale-gen.conf).

libc6 was in todays updates but its still broken here. jeff this isnt to hurry you i wasnt sure if you uploaded the fix or just trying something.

Nope, the upload today wasn't that fix. We discovered today during the toolchain bof at the development summit that the gcc-4.1 that glibc had been built against was too old, and didn't include the stack smashing protection code. This was essentially a simple rebuild against a newer compiler.

ok thank you

jeff good job it looks like lastnights updates had libc6 libc6-dev and libc6-686 and i see UTF-8 once agian thank you sir

Thanks, glad it's working for you. Closing this bug.

Thanks a lot Jeff for all your hard work! Locales work fine now!

On Sat, 2006-06-24 at 13:16 +0000, Lukas Sabota wrote:
> Thanks a lot Jeff for all your hard work! Locales work fine now!
>
Ditto

Didn't work for me...

Just tried installing the 2.6.17 from edgy today and that picked up libc6 as a dependency. After that, i got the locales problem again. Are there any other packages that need to be upgraded as well (= dependency problem) or is there still a problem with glibc?
My locale's set to en_US.UTF-8 btw...

The locales problem was that text wasn't showing up in other languages. How are you seeing this with en_US.utf-8? =)

I'm seeing the messages posted in the first post in console when running apps (like apt). I know nothing about missing text, but those error messages have been present since the first edgy glibc build...

mephisto make sure your libc6 version is 2.4-1ubuntu6 if not run sudo apt-get update && sudo apt-get dist-upgrade.

yes, that was the version i had installed. i didn't mention it in my post, but i checked if i had the latest before i posted the comment. the system was a pure dapper system with only glibc from edgy (needed that for 2.6.17 kernel...)

mephisto if you are still having this issue i suspect it has alot to do with libc6 (edgy) being used in dapper.

mephisto If this is the case and its still happening please file a bug on libc6 in dapper.

This is not a problem with dapper's libc6, so i can't file it there, since this is not a bug to be fixed in dapper. I think you don't exactly understand my problem. If I update my correctly working up-to-date dapper with only libc6, libc6-i686 and libc6-dev version 2.4-1ubuntu6 (from edgy), i get messages like these:

[mephisto@sumomo ~]$ perl
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en",
        LC_ALL = (unset),
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

And since just about any edgy package depends on this new libc6 version, there isn't really a way not to install it if people don't want to update their entire system, but just want a few edgy packages on their dapper system...

I understand perfectly you are using an edgy main lib on dapper (that is a bad idea) mixing packages is never really normally a good idea since one package depends on another package. If you are going to use edgy libc6 in dapper we really cant do much about it because the problem is with mixing libs.