Summary: | Can't create en_GB/ISO8859-1 locale with glibc-2.3.4.20050125-r1 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Peter Humphrey <peter> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | VERIFIED WORKSFORME | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Peter Humphrey
2005-03-20 12:26:23 UTC
It could well be. I don't know why it didn't appear when I searched for existing bugs though. Today I found I had a new version of linux26-headers, so I remerged glibc at version glibc-2.3.4.20050125-r1. Still no en_GB/ISO8859-1 or en_GB/ISO8859-15: locale -a C POSIX en_GB en_GB.utf8 Output of localedef --help includes: System's directory for character maps : /usr/share/i18n/charmaps repertoire maps: /usr/share/i18n/repertoiremaps locale path : /usr/lib/locale:/usr/share/i18n ls /usr/share/i18n/charmaps ... ISO_8859-1,GL.gz ISO_8859-SUPP.gz ... Note the comma, which is the only one in the directory. ls /usr/share/i18n/locales shows about 212 base locales. localedef --list-archive gives a null reply. I'm out of ideas now. Over the last few days I've started again and built a 2005.0 system from scratch, using the proper installation ISO, stage and portage snapshot. I still can't build en_GB.ISO-8859-1 or -15 with glibc. I still have to follow the instructions in the localisation guide to create them at the command prompt: "localedef -c -i en_GB -f ISO-8859-15 en_GB.ISO-8859-15" works, so perhaps I must be content with that. It would be useful, if this is the recommended way of creating one's own locale, to have it included in the installation guide, since (I assume) it needs doing at a fairly early stage in the build process so that the locales are available to the programs that need them. Still an issue with newer versions of glibc? Yes, I still cannot create these locales simply by emerging glibc. I still have to run localedef as before. Here's an up-to-date info: $ emerge --info Portage 2.0.53 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r0,glibc-2.3.5-r3, 2.6.14-gentoo-r4 x86_64) ================================================================= System uname: 2.6.14-gentoo-r4 x86_64 AMD Opteron(tm) Processor 246 Gentoo Base System version 1.12.0_pre11 ccache version 2.4 [enabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.11, 1.2.17 sys-devel/autoconf: 2.13, 2.59-r6, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10, 2.16.1-r1 sys-devel/libtool: 1.5.18-r1, 1.5.20-r1 virtual/os-headers: 2.6.11-r2, 2.6.11-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="no" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=opteron -mtune=opteron" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/X11/xdm/Xservers /etc/fonts /etc/gconf /etc/rc.d /etc/rsync /etc/terminfo /etc/wget /etc/env.d" CXXFLAGS="-O2 -march=opteron -mtune=opteron" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg ccache distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk http://ftp.easynet.nl/mirror/gentoo http://trumpetti.atm.tut.fi/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo"LANG="en_GB.ISO-8859-15" LC_ALL="en_GB.ISO-8859-15" LINGUAS="en_GB" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://gaia.home/gentoo-portage" [a local rsync box on my network] USE="amd64 X alsa audiofile avi bash-completion berkdb bitmap-fonts bzip2 cdr crypt cups directfb dvd eds emboss encode expat fbcon foomaticdb fortran gif gimp gimpprint glut gphoto2 gpm gstreamer gtk gtk2 imlib ipv6 ithreads jpeg kdeenablefinal lcms libcaca lzw lzw-tiff mng mp3 mpeg ncurses nls nptl nptlonly nsplugin nvidia ogg opengl pam pdflib perl png ppds python qt quicktime readline scanner sdl sox spell ssl tcpd tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales vorbis wmf xml2 xpm xprint xv zlib linguas_en_GB userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS $ cat /etc/locales.build en_GB/ISO-8859-1 en_GB/ISO-8859-15 en_GB.UTF-8/UTF-8 first off, your second entry there is invalid ... you should actually be using: en_GB/ISO-8859-1 en_GB.ISO-8859-15/ISO-8859-15 en_GB.UTF-8/UTF-8 second, i just tested glibc-2.4 and it works for me: $ locale -a ... de_DE@euro en_GB en_GB.iso885915 en_GB.utf8 en_US ... Now I get this: # cat /etc/locale.gen en_GB/ISO-8859-1 en_GB.ISO-8859-15/ISO-8859-15 en_GB.UTF-8/UTF-8 # locale-gen * Generating 1 locales (this might take a while) with 1 jobs * (1/1) Generating en_GB/ISO-8859-1 ... character map file `en_GB.ISO-8859-15/ISO-8859-15' not found: No such file or directory cannot open locale definition file `en_GB/ISO-8859-1': Not a directory [ !! ] * Bad entry in locale.gen: 'en_GB.UTF-8/UTF-8 '; skipping * Generation complete Never mind - I'm fed up with it. I'll just use what I have. that syntax is incorrect for locale.gen you should be using: en_GB.UTF-8 UTF-8 en_GB ISO-8859-1 en_GB.ISO-8859-15 ISO-8859-15 $ cat /etc/locale.gen en_GB.UTF-8 UTF-8 en_GB ISO-8859-1 en_GB.ISO-8859-15 ISO-8859-15 $ sudo locale-gen * Generating 3 locales (this might take a while) with 1 jobs * (1/3) Generating en_GB.UTF-8 ... [ ok ] * (2/3) Generating en_GB.ISO-8859-1 ... [ ok ] * (3/3) Generating en_GB.ISO-8859-15 ... [ ok ] * Generation complete $ locale -a C en_GB en_GB.iso885915 en_GB.utf8 POSIX Where is en_GB.iso88591? If I comment-out the ISO-8859-15 line in /etc/locale.gen, leaving the ISO-8859-1 line intact, running locale-gen again simply removes en_GB.iso885915 (I thought it might be overwriting en_GB.iso88591 - clutching at straws). Perhaps en_GB is really en_GB.iso88591 under a different name? yes, the name displayed in `locale -a` is the first item in locale.gen so "en_GB" corresponds to "en_GB ISO-8859-1" Wouldn't it be nice if things were what they say they are? Thanks for the help - I'm glad to have got that settled at last. |