Package: locales
Version: 2.7-13
Severity: normal
Tags: l10n
/etc/environment has been superceded by /etc/default/locale but
nothing ensures that only one exists on the system or that they match
up, or that locales to support both are generated. If this causes a
problem it is very difficult for the user to find out where the
problem lies and what to do about it.
I think that the old file should probably just be removed (is there a
good reason why not?). If not then the user should be warned if they
do not match up and dpkg-reconfigure locales should adjust both when
run.
Case study of how this caused a problem:
I had a machine generating mail every five minutes (munin cron job) complaining
about
perl being unable to set locale:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_GB:en_US:en_GB:en",
LC_ALL = (unset),
LANG = "en_GB"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
the /etc/environment file looked like this:
LANGUAGE = "en_GB:en_US:en_GB:en"
LANG="en_GB"
the /etc/default/locale file looked like this:
# File generated by update-locale
LANG=en_GB.UTF-8
This all looks reasonable to anyone not intimately familiar with how
the locale stuff works. For some reason the perl scipr run by cron
picked up the settings from /etc/environment
perl run on the cooman-line did not complain - I guess it was using
/etc/default/locale.
I eventually ran dpkg-reconfigure locales to find that
en_GB.iso8859-15 and en_GB.UTF-8 were being generated. That lokoed OK
(I know that en_GB.ISO8859-15 is en_GB.ISO8859-1 plus the euro symbol)
It turns out that LANG="en_GB" actually requires en_GB.ISO8859-1 to be
generated to be satisfied, hecne the complaints from perl and the
torrent of email.
Running dpkg-reconfigure locales did not change the LANG in
/etc/environment to be one that was generated or wanr that it pointed
at one that was not. Nor did it give any clue that the old file might
still be being used and thus might cause problems and should be removed.
Not directly related to this bug:
To add to the fun the mails generated came from "root (Cron Daemon)"
and were forwarded to an offsite email. They were rejected by the
forwarded-to server due to not coming from a valid address, and were
bounced back to an invalid address so they were never seen by anyone
until work's anti-spam filter provider complained that they were
exceeding their 9000 messages/month and needed to pay extra. 8900-odd of
those messages were coming from this bug combined with a stock
installation of munin and an MTA that did not do address rewriting on
cron-generated mail.
I am a reasonably savvy user and it took me most of the day to track
this down and work out what the right fix is. It would help all users,
but especially the less-expert if the old file was tidied-up or
automatically synced and/or warned-about, or had locales generated for it.
thanx
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (600, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages locales depends on:
ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy
ii libc6 [glibc-2.7-1] 2.7-13 GNU C Library: Shared libraries
locales recommends no packages.
locales suggests no packages.
-- debconf information:
* locales/default_environment_locale: en_GB.UTF-8
* locales/locales_to_be_generated: en_GB.UTF-8 UTF-8
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
