On Tuesday 16 November 2004 16:32, Frans Pop wrote: > It appears this line was added to /etc/localegen during prebaseconfig, > by calling 'validlocale $LANG' instead of 'validlocale "$LANG"' (and by > not checking the return code of validlocale).
The problem is even more complex (at least on s390). If I manually execute the command from a shell (at the prebaseconfig stage of the installation), this is the result: # chroot /target/ /usr/sbin/validlocale "" locale '' valid and available # chroot /target/ /usr/sbin/validlocale C locale 'C' valid and available # chroot /target/ /usr/sbin/validlocale en_US locale 'en_US' not available Unable to open /usr/share/i18n/SUPPORTED at /usr/sbin/validlocale line 61. (returncode: 2) Checking where this file comes from on my laptop shows: $ dpkg -S i18n/SUPPORTED locales: /usr/share/i18n/SUPPORTED I guess this means validlocale can only be run reliably if the locales package has already been installed (normally, languagechooser's postinst will take care of this by calling 'apt-install locales' when it is run). However, this additional problem is not really a problem as long as we make sure LANG is unset, "" or "C" for s390. Other possible results of calling validlocale (with locales installed): # chroot /target/ /usr/sbin/validlocale Usage: /usr/sbin/validlocale <locale> (returncode: 1) # chroot /target/ /usr/sbin/validlocale en_US locale 'en_US' not available en_US ISO-8859-1 (returncode: 1) Which means that it is currently not possible to detect the difference between "incorrect usage" and "locale not found" from the returncode! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
