You are not logged in.
I'm baffled by this. Have uncommented en_US.UTF-8 in /etc/locale.gen. Archie runs /usr/sbin/locale-gen on startup and LOCALE is set to:
LOCALE=en_US.UTF-8
However, if I try to run sylpheed it bleats about a non-UTF locale:
And when I try to run gajim it get the errors shown in the capture below:
What is causing those two errors in locale -a - is it related?
Offline
Offline
Arch install maybe
might have to run locale-gen before building live cd maybe
mkliveiso makes a Arch based install so... maybe either you run locale set up when booting Archie (may slow it down ;-()
or add to mkliveiso so it runs locales... before building iso
Just a thought
Mr Green
Offline
do you have the directory where all the locales are kept, /usr/share/i18n/locales/ ? Its part of the glibc package.
Offline
Er.... that's my thread, dude...
maybe either you run locale set up when booting Archie
Archie runs /usr/sbin/locale-gen on startup
do you have the directory where all the locales are kept, /usr/share/i18n/locales/ ? Its part of the glibc package.
I assume so. I'm starting to wonder if this isn't all to do with unionfs. We have a problem with gaim whereby it can't detect it's protocols, even though they are there. I wonder if this is the same thing. Maybe, because the locales are generated on the fly into a unionfs mount it can't detect them?
Offline
Maybe, because the locales are generated on the fly into a unionfs mount it can't detect them?
Well, they are all listed there in /usr/share/i18n/locales ok and I discovered that if I set LC_ALL=en_US.UTF-8 gajim works fine. So what is going wrong in normal usage? Is some variable not being set correctly?
LC_MESSAGES etc are not set on my system but locale -a doesn't give an error - what is misconfigured in Archie?
Offline
:oops: :oops: :oops:
Offline
sorry blind drunk at party hic!
checkin' archie now
setting the env its complains about it works ... but locale error C still shows
locales are not uncommented in locales.gen
Mr Green
Offline
dtw wrote:Maybe, because the locales are generated on the fly into a unionfs mount it can't detect them?
Well, they are all listed there in /usr/share/i18n/locales ok and I discovered that if I set LC_ALL=en_US.UTF-8 gajim works fine. So what is going wrong in normal usage? Is some variable not being set correctly?
LC_MESSAGES etc are not set on my system but locale -a doesn't give an error - what is misconfigured in Archie?
The only thing I can think of at this point is some files or directories specified in locale-gen don't exist in archie.
Can you give me the link to the iso? Maybe I can uncover something.
Offline
Hmmm - the LOCALE support I am working on is only in CVS - you'd need to build your own ISO to test it I'm afraid. It's not too hard to do...the spare 2gb partition puts most people off though! :'(
Offline
errr mount it on a loop ?
ie create a 2g image ... & point Archie at it
I got to get back to party YMCA lol
Mr Green
Offline
errr mount it on a loop ?
ie create a 2g image ... & point Archie at it
I got to get back to party YMCA lol
Like he said
Offline
I tried to create archie a few days ago but got stuck when I couldn't get kernel26beyond to boot just for god-damn unionfs
Offline
I tried to create archie a few days ago but got stuck when I couldn't get kernel26beyond to boot just for god-damn unionfs
There is unionfs module for vanilla too!
Offline
Offline
This shows some locale info for reference:
Is there something else set in /etc/profile overwriting rc.conf?
-neri
Offline
do a mklive install arch then check locales-gen in /etc ... prior to building Archie iso ...
I looked at file under Archie it was all hashed out
Mr Green
Offline
Is there something else set in /etc/profile overwriting rc.conf?
-neri
Yup! Spot on. The bash pkg owns /etc/profile and LANG is set to en_US - is that a bug, then? Does it even need to be there as the system default is set at startup anyway?
Also, just so I understand, is /etc/profile being sourced when our archie user is created on the fly at start-up and is that overwriting the other locale settings? Therefore, on my regular system, the contents of /etc/profile is not a problem because isn't ever read for an established user? Surely there should be a sane default then?
So, what is the solution? Comment out that LANG line in /etc/profile?
Offline
neri wrote:Is there something else set in /etc/profile overwriting rc.conf?
-neri
Yup! Spot on. The bash pkg owns /etc/profile and LANG is set to en_US - is that a bug, then? Does it even need to be there as the system default is set at startup anyway?
So, what is the solution? Comment out that LANG line in /etc/profile?
Well, that depends, Arch works in away that it creates an /etc/profile.d/locale.sh at startup which is the sourced by /etc/profile when it sources everything in /etc/profile.d/*
The actual settings in /etc/profile are working only as fallbacks. Now, appearantly, Archies init does not create such a file at startup sp it sticks with the default en_US. If you uncomment it, you prolly end up with no locale at all -> uncool. I dan't know about a simple fix from the top of my head, since I haven't used Archie in a while.
-neri
Offline
Archies init does not create such a file at startup
So are you saying that you think that the /etc/profile.d files are _not_ being sourced when the Archie user is created?
Offline
So change LANG="en_US" to LANG="en_US.utf8" in /etc/profile. It it's falling back to the default, make the default what you want until you find a better solution.
Offline
neri wrote:Archies init does not create such a file at startup
So are you saying that you think that the /etc/profile.d files are _not_ being sourced when the Archie user is created?
Nope, I think the file locales.sh is not created. In ArchLinux it is done by /etc/rc.sysinit -> it parses rc.conf and writes out the file into /etc.profile.d
That's the part I think doesn't happen.
-neri
Offline
I'm pretty sure I found the problem but I don't have time to rebuild the iso and test.
LOCALE=en_US.UTF-8
should be
LOCALE="en_US.UTF-8"
without the double quotes it was setting LANG environment variable to just en_US in /etc/profile.d/locale.sh via sysinit.
The same goes for archie/rc.sysiinit:
[ "$LOCALE" = "" ] && LOCALE=en_US.UTF-8
missing the double quotes.
It takes care of errors from sylpheed and gajim but not the error messages from locale -a...probably not important though.
Offline
nevermind the above post about the double quotes, I looked into it a little deeper and found that couldn't be the problem.
Take a look at /etc/profile. Once it gets executed it sets LANG to en_US. At the end of the script it executes everything in profile.d/* and in locale.sh LANG is set to the correct en_US.UTF-8 but if you do a echo $LANG after a boot it gives you just en_US. WTF? Take a look at the code in /etc/profile to execute them:
# load profiles from /etc/profile.d
# (to disable a profile, just remove execute permission on it)
if [ `ls -A1 /etc/profile.d/ | wc -l` -gt 0 ]; then
for profile in /etc/profile.d/*.sh; do
if [ -x $profile ]; then
. $profile
fi
done
unset profile
fi
must be executable
so...
[root@localhost ~]# ls -la /etc/profile.d/*.sh
-rw-r--r-- 1 root root 146 2006-09-06 00:26 /etc/profile.d/locale.sh
-rwxr-xr-x 1 root root 158 2006-02-05 16:06 /etc/profile.d/mozilla-common.sh
-rwxr-xr-x 1 root root 529 2006-08-05 14:21 /etc/profile.d/xfce4.sh
-rwxr-xr-x 1 root root 358 2006-07-09 10:53 /etc/profile.d/xorg.
locale.sh is the only one not executable.
Offline
Bizarrely we never had this code in the initscripts:
# Flush old locale settings
: >/etc/profile.d/locale.sh
chmod 755 /etc/profile.d/locale.sh
Pretty sure that will be it Thanks very much neri and Penguin. Fixes are commited to CVS.
I even checked to see if there were big differences in the initscripts last night (see ML) - I guess I just overlooked that!
Offline