Bug#632720: tzdata: fails to install when setting debconf values beforehand
Package: tzdata Version: 2011h-3 Severity: normal Hi, this problem was present since 2011h-1 and while I can install tzdata again since bug #631878 is fixed, I still get the exact same error as described in that bug report when using debconf-set-selections before package installation: Setting up tzdata (2011h-3) ... dpkg: error processing tzdata (--configure): subprocess installed post-installation script returned error exit status 10 Errors were encountered while processing: tzdata This is how to reproduce the problem: $ sudo multistrap -f multistrap.conf multistrap.conf: -%-- [General] arch= directory=debian-sid-multistrap cleanup=true debootstrap=Debian aptsources=Debian debconfseed=tzdata.debconf [Debian] packages=apt source=http://cdn.debian.net/debian keyring=debian-archive-keyring suite=sid -%-- tzdata.debconf: -%-- tzdata tzdata/Zones/Europe select Berlin tzdata tzdata/Areasselect Europe -%-- To not encounter the problem, either comment the debconfseed line in multistrap.conf or the lines in tzdata.debconf. Multistrap will run fine then. cheers, josch -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110705103931.17414.2957.reportbug@hoothoot
Bug#629819: libc6-dev: moving crt1.o crti.o etc. to /usr/lib/triplet breaks external multiarch unaware applications
Hallo! On Wed, 08 Jun 2011 17:41:58 +0200, Andreas Beckmann deb...@abeckmann.de wrote: the moving of crt1.o, crti.o, ... from /usr/lib to /usr/lib/triplet breaks external applications that are not aware of the new multiarch paths. One such application is GCC from SVN, which now fails to compile with this error: /usr/bin/ld: cannot find crti.o: No such file or directory (seems to happen the first time the stage1 compiler is used to link something). Testing something with gcc-trunk (and eventually bisecting gcc) is something I do quite regularily. In general I like the multiarch idea and don't want to go the road back. So a possible solution I see to make such external applications work again could be the introduction of a libc6-dev-compat package that ships the links /usr/lib/*.o - /usr/lib/triplet/*.o. This package should not be installed by default, but only by the admin knowing what he does. What's the route forward here? (Or has everyone manually added symlinks to /usr/lib/ by now? Grüße, Thomas pgpPdjr6tsREX.pgp Description: PGP signature
Bug#629819: libc6-dev: moving crt1.o crti.o etc. to /usr/lib/triplet breaks external multiarch unaware applications
Hi! Thomas Schwinge wrote: What's the route forward here? (Or has everyone manually added symlinks to /usr/lib/ by now? On this machine, /usr/share/doc/libc6/NEWS.Debian.gz says: | Starting with the eglibc package version 2.13-5, the libraries are | shipped in the multiarch directory /lib/$arch instead of the more | traditional /lib. | | The toolchain in Debian has been updated to cope with that, and most | build systems should be unaffected. If you are using a non-Debian | toolchain to build your software and it is not able to cope with | multiarch, you might try to pass the following options to your | compiler: | | -I/usr/include/$arch --sysroot /usr/lib/$arch I haven't tried it, but maybe that can help. If that doesn't work well, it could be worth tweaking the libc6-dev package or introducing a package with symlinks to help with the transition (reports on experiments in that vein would also be very welcome). -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110705163039.GA28864@elie
Bug#632720: tzdata: fails to install when setting debconf values beforehand
On Tue, Jul 05, 2011 at 12:39:31PM +0200, Johannes Schauer wrote: Package: tzdata Version: 2011h-3 Severity: normal Hi, this problem was present since 2011h-1 and while I can install tzdata again since bug #631878 is fixed, I still get the exact same error as described in that bug report when using debconf-set-selections before package installation: Setting up tzdata (2011h-3) ... dpkg: error processing tzdata (--configure): subprocess installed post-installation script returned error exit status 10 Errors were encountered while processing: tzdata This is how to reproduce the problem: $ sudo multistrap -f multistrap.conf multistrap.conf: -%-- [General] arch= directory=debian-sid-multistrap cleanup=true debootstrap=Debian aptsources=Debian debconfseed=tzdata.debconf [Debian] packages=apt source=http://cdn.debian.net/debian keyring=debian-archive-keyring suite=sid -%-- tzdata.debconf: -%-- tzdata tzdata/Zones/Europe select Berlin tzdata tzdata/Areasselect Europe -%-- To not encounter the problem, either comment the debconfseed line in multistrap.conf or the lines in tzdata.debconf. Multistrap will run fine then. The other option is to not use spaces between Berlin or Europe. With your current file, the preseeded values are Berlin and Europe, which of course are not known to tzdata. It doesn't seems to be a tzdata problem, it's either a problem in your preseeding file or in multistrap. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110705210456.ga22...@hall.aurel32.net
Bug#632795: glibc-doc-reference: Information about LANGUAGE is incorrect
Package: glibc-doc-reference Version: 2.13-1 Severity: normal The libc manual (libc.info.gz) says: 8.2.1.6 User influence on `gettext' [...] The LOCALE component is computed based on the category used. Just like for the `setlocale' function here comes the user selection into the play. Some environment variables are examined in a fixed order and the first environment variable set determines the return value of the lookup process. In detail, for the category `LC_xxx' the following variables in this order are examined: `LANGUAGE' `LC_ALL' `LC_xxx' `LANG' However, this is incorrect, and the way it is done is more complex, as shown below: ypig% LANGUAGE=fr_FR LC_ALL=en_US cp cp: opérande fichier manquant Saisissez « cp --help » pour plus d'informations. ypig% LANGUAGE=fr_FR LC_ALL=C cp cp: missing file operand Try `cp --help' for more information. According to bug 591334, this is the manual that is incorrect. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/8 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages glibc-doc-reference depends on: ii dpkg 1.16.0.3 Debian package management system ii install-info 4.13a.dfsg.1-6 Manage installed documentation in glibc-doc-reference recommends no packages. glibc-doc-reference suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110706001847.ga32...@ypig.lip.ens-lyon.fr
Bug#632798: libc6: broken LANGUAGE design
Package: libc6 Version: 2.13-10 Severity: normal The current LANGUAGE design is broken. Here an example: ypig% locale LANG=POSIX LANGUAGE= LC_CTYPE=en_US.ISO8859-1 LC_NUMERIC=POSIX LC_TIME=en_DK LC_COLLATE=POSIX LC_MONETARY=POSIX LC_MESSAGES=fr_FR LC_PAPER=POSIX LC_NAME=POSIX LC_ADDRESS=POSIX LC_TELEPHONE=POSIX LC_MEASUREMENT=POSIX LC_IDENTIFICATION=POSIX LC_ALL= ypig% cp cp: opérande fichier manquant Saisissez « cp --help » pour plus d'informations. ypig% ssh localhost locale Connected to ypig (from ::1) LANG=POSIX LANGUAGE=en_US:en LC_CTYPE=en_US.ISO8859-1 LC_NUMERIC=POSIX LC_TIME=en_DK LC_COLLATE=POSIX LC_MONETARY=POSIX LC_MESSAGES=fr_FR LC_PAPER=POSIX LC_NAME=POSIX LC_ADDRESS=POSIX LC_TELEPHONE=POSIX LC_MEASUREMENT=POSIX LC_IDENTIFICATION=POSIX LC_ALL= ypig% ssh localhost cp Connected to ypig (from ::1) cp: missing file operand Try `cp --help' for more information. The problem is that the system sets LANGUAGE in the user's back, so that the standard user's choice (LC_MESSAGES=fr_FR) is no longer taken into account. The best solution would be to make the standard locale system override LANGUAGE, which could just be used as a fallback. Said otherwise, it is equivalent to internally prepend the current LC_MESSAGES setting (possibly coming from LANG or LC_ALL) to the LANGUAGE value. Alternatively the system that sets LANGUAGE could be smarter (but it's difficult to know what the user expects, in particular if SSH doesn't transmit LANGUAGE). -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/8 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libc-bin 2.13-10Embedded GNU C Library: Binaries ii libgcc1 1:4.6.1-2 GCC support library libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.40 Debian configuration management sy ii glibc-doc 2.13-10Embedded GNU C Library: Documentat ii locales 2.13-10Embedded GNU C Library: National L -- debconf information: glibc/upgrade: true glibc/disable-screensaver: glibc/restart-failed: * glibc/restart-services: exim4 cups cron atd apache2 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110706005459.ga1...@ypig.lip.ens-lyon.fr
Bug#591334: Processed: [bts-link] source package eglibc
On 2011-05-23 18:12:28 +, Debian Bug Tracking System wrote: tags 591334 + upstream wontfix Bug #591334 [libc6] libc6: LANGUAGE not taken into account unless LC_MESSAGES is set Added tag(s) wontfix. [...] I agree with the reason given by upstream, but this is not the behavior described in the manual. So, I assume that this is a bug in the manual and I've reported bug 632795 against glibc-doc-reference on this point. There are still potential problems due to the way it is implemented. One at least occurs under Debian, see bug 632798. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110706011417.ga13...@prunille.vinc17.org
Processed: Re: glibc-doc-reference: Information about LANGUAGE is incorrect
Processing commands for cont...@bugs.debian.org: tags 632795 upstream Bug #632795 [glibc-doc-reference] glibc-doc-reference: Information about LANGUAGE is incorrect Added tag(s) upstream. forwarded 632795 http://sourceware.org/bugzilla/show_bug.cgi?id=12963 Bug #632795 [glibc-doc-reference] glibc-doc-reference: Information about LANGUAGE is incorrect Set Bug forwarded-to-address to 'http://sourceware.org/bugzilla/show_bug.cgi?id=12963'. End of message, stopping processing here. Please contact me if you need assistance. -- 632795: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632795 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.130991740927690.transcr...@bugs.debian.org
Bug#632798: libc6: broken LANGUAGE design
Hi Vincent, Vincent Lefevre wrote: LANGUAGE= [...] LC_MESSAGES=fr_FR [...] ypig% ssh localhost locale Connected to ypig (from ::1) LANG=POSIX LANGUAGE=en_US:en [...] LC_MESSAGES=fr_FR [...] LC_ALL= [...] The problem is that the system sets LANGUAGE in the user's back, so that the standard user's choice (LC_MESSAGES=fr_FR) is no longer taken into account. I agree that this is not very good. Before deciding how to fix it, let's describe the mechanism. 1. On my local machine, I could not reproduce the same effect. That's probably because no default locale is configured here. After making the default locale de_DE.UTF-8 using dpkg-reconfigure -plow locales, /etc/environment is empty and /etc/default/locale looks like this # File generated by update-locale LANG=de_DE.UTF-8 #LANGUAGE=en_US and ssh localhost locale still shows LANGUAGE=. Any idea what's different between your setup and mine? 2. openssh-server has the following in its default sshd/config: AcceptEnv LANG LC_* That is unfortunate. Independently of everything else, this list ought to be expanded to include LANGUAGE. 3. The locale C.UTF-8 does not work like C for the sake of this feature: $ LC_ALL=C LANGUAGE=de_DE cp cp: missing file operand Try `cp --help' for more information. $ LC_ALL=C.UTF-8 LANGUAGE=de_DE cp cp: Fehlendes Dateioperand „cp --help“ gibt weitere Informationen. If I understand the purpose of C.UTF-8 correctly, that's another bug (independent, though). 4. Despite what the gettext manual[*] says, setting LANG does not cause LANGUAGE to take effect. This is another bug, as far as I can tell. $ LANG=en_US LANGUAGE=de_DE cp cp: missing file operand Try `cp --help' for more information. 5. As you mentioned, when LANGUAGE has an effect, it takes precedence over LC_MESSAGES. The principle of least surprise might indicate that the locale in LC_MESSAGES should be used in preference to LANGUAGE, but that would make it impossible to express something like what is currently meant by LANGUAGE=fr:de LC_MESSAGES=de on an installation where most programs are translated to German. (It means: programs using catgets should use German, while programs using gettext should prefer French if possible. Intent: I'd prefer French, but barring that, please give me German instead of English). If one is willing to break with 10 years of gettext behavior, it should be possible to change this without that downside by prepending $LC_MESSAGES to LANGUAGE when and only when it is not already an item in $LANGUAGE. A nice side-effect would be the ability to partially work around (2), as you mentioned. What do you think? What pieces does the above description miss? Thanks for your attention to detail. Jonathan [*] http://www.gnu.org/software/gettext/manual/gettext.html#The-LANGUAGE-variable -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110706032251.GC10015@elie
Bug#591334: marked as done (libc6: LANGUAGE not taken into account unless LC_MESSAGES is set)
Your message dated Wed, 6 Jul 2011 07:54:14 +0200 with message-id 20110706055414.gd22...@hall.aurel32.net and subject line Re: Bug#591334: Processed: [bts-link] source package eglibc has caused the Debian Bug report #591334, regarding libc6: LANGUAGE not taken into account unless LC_MESSAGES is set to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 591334: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591334 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: libc6 Version: 2.11.2-2 Severity: normal The LANGUAGE environment variable isn't taken into account for translations, unless LC_MESSAGES is set. Here's an example: ypig% unset LC_MESSAGES ypig% LANGUAGE=fr_FR:fr cp cp: missing file operand Try `cp --help' for more information. ypig% LANGUAGE=fr_FR:fr LC_MESSAGES=en_US.ISO8859-1 cp cp: opérande fichier manquant Saisissez « cp --help » pour plus d'informations. Note that I've chosen to set LC_MESSAGES to English to show that LANGUAGE has the precedence, as documented. The bug is that the LC_MESSAGES environment variable must be set, even though its language isn't used. The value of LC_MESSAGES has some importance, though. With POSIX or C, I still get English messages: ypig% LANGUAGE=fr_FR:fr LC_MESSAGES=POSIX cp cp: missing file operand Try `cp --help' for more information. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libc-bin 2.11.2-2 Embedded GNU C Library: Binaries ii libgcc1 1:4.4.4-7 GCC support library libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.33 Debian configuration management sy ii glibc-doc 2.11.2-2 Embedded GNU C Library: Documentat ii locales 2.11.2-2 Embedded GNU C Library: National L -- debconf information excluded ---End Message--- ---BeginMessage--- On Wed, Jul 06, 2011 at 03:14:17AM +0200, Vincent Lefevre wrote: On 2011-05-23 18:12:28 +, Debian Bug Tracking System wrote: tags 591334 + upstream wontfix Bug #591334 [libc6] libc6: LANGUAGE not taken into account unless LC_MESSAGES is set Added tag(s) wontfix. [...] I agree with the reason given by upstream, but this is not the behavior described in the manual. So, I assume that this is a bug in the manual and I've reported bug 632795 against glibc-doc-reference on this point. There are still potential problems due to the way it is implemented. One at least occurs under Debian, see bug 632798. Ok, then given the issues is now tracked in the other bugs, I am closing this one. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net ---End Message---
