On Tue, Feb 05, 2002 at 05:30:35AM +0100, Adeimantos wrote: > maze wrote: > > > > Oki ben on verra ca ce soir alors > > merci > > > > On Mon, 4 Feb 2002 08:55:44 +0100 > > "christophe" <[EMAIL PROTECTED]> wrote: > > > > ~|Je pense que ca viens de la MAJ d'hier car j'ai le meme problème avec la > > ~|sid. > > ~|Il faut attendre ce soir que ca soit mis a jour > > ~| > > > Locale ne se met pas à jour tout seul. il faut reconfigurer le > paquetage: > dpkg-reconfigure locales, puis vérifier /etc/environment. Il se peut > qu'en upgradant, dpkg ait proposé de changer le script de locales, mais > je n'en suis pas sûr. Rien de grave de toute façon.
Le problème que vous avez ne vient pas de la génération des locale mais de l'application strict d'un «set -e» dans un script. l'application du patch suivant répare le tout: --- /var/lib/dpkg/info/locales.postinst.old Mon Feb 4 18:32:56 2002 +++ /var/lib/dpkg/info/locales.postinst Mon Feb 4 18:33:10 2002 @@ -46,7 +46,7 @@ db_get locales/default_environment_locale && SELECTED=$RET if [ -n "$SELECTED" ]; then umask 022 - grep -v '^LANG=' /etc/environment > /etc/environment.tmp + grep -v '^LANG=' /etc/environment > /etc/environment.tmp || true test "$SELECTED" = "None" || echo "LANG=$SELECTED" >> /etc/environment.tmp cat /etc/environment.tmp > /etc/environment rm -f /etc/environment.tmp C'est donc à cause du grep qui, lorsqu'il ne matche pas envoie un code de retour différent de 0. Et comme il y a le set -e en début de script celui-ci s'arrête. -- Igor Genibel http://www.alcove.com/ [EMAIL PROTECTED] http://www.tuxfamily.org/ [EMAIL PROTECTED] http://people.debian.org/~igenibel [EMAIL PROTECTED] GPG: 1024D/9D735B4F: 4F61 8D8F 05AC 8D2C 5F92 9B99 C44B 0266 9D73 5B4F