Re: Bug#842796: libc recently more aggressive about pthread locks in stable ?
[Jeff Epler] > I believe that similar bugs have been afflicting hurd and kfreebsd > debian ports for some time. In retrospect, it's too bad these reports > weren't given more attention, because it could have made things better > for Linux platforms as well. :-/ Yeah, too bad. :/ On the other hand, it make me glad to have yet another example of the value of the less popular architectures. :) Does this mean that running the autopkgtest scripts on hurd or kfreebsd would expose these problems? Do we have any idea how widespread the problem is? -- Happy hacking Petter Reinholdtsen
Re: Bug#842796: libc recently more aggressive about pthread locks in stable ?
[Henrique de Moraes Holschuh] > And what should we do about Debian stretch, then? I believe a good start would be to add an assert() in a test version of glibc and then run all the autopkgtest scripts on the packages in the archive to see how widespread the problem is. It will not cover all packages, but at least a significant portion of the archive. I suspect we are too close to the Stretch freeze to try to modify all the packages affected by the problem, and if so we should probably disable the more strict code for Stretch too, and make it an RC issue in unstable after the freeze in February. A problem is that it will be hard to test all the packages in time, as such locking issue might not trigger on every run. Is there already, or can you create, a wiki page to collect the details on this problem? You seem to have more grasp of the issue than me, otherwise I would have started one myself. I assume other distributions are affected too. What are they doing to handle it? -- Happy hacking Petter Reinholdtsen
Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed
[Richard Laager] > For example, if you want to use the low 32-bits of /etc/machine-id, > that would work too. It'd mean carrying a patch on Debian, but if the > pain of a patch and different behavior is less than the benefits of > the change, go for it. I guess we would have to verify that /etc/machine-id is available in the initrd for this to work with / in zfs. But I guess that is a problem with /etc/hostid too for gethostid(). :) While researching this topic I came across http://stackoverflow.com/questions/9258228/how-to-prevent-gethostid-from-doing-dns-lookups-on-linux > which report that gethostid() might lock up a program if the DNS server become unavailable. A scary scenario just to get the machine ID. I also came across http://0pointer.de/blog/projects/ids.html >, which provide a very useful list of possible IDs to use in addition to the gethostid() value. It agrees that gethostid() have unclear sematics. :) -- Happy hacking Petter Reinholdtsen
Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed
[Aurelien Jarno] > In any case it looks to me we should not reinvent the wheel. We > already ended-up with two implementations of a unique machine ID, one > in dbus and one for systemd (which fortunately now try to just copy > the other one if it already exists), I am not sure we want a third > one. Could we just copy (part) of this ID if it exists, otherwise > generate a random number? Or even point the current gethostid() to > /etc/machine-id if it exists? Peeking at the dbus and systemd UUID (and perhaps preferring them over the DMI UUID) seem like a good idea, as long as /etc/hostid is updated once during installation. Perhaps glibc is the wrong place to do this. Perhaps a debian-installer udeb is a better place? It will of course miss out chroots, which is unfortunate. We have /etc/machine-id from systemd, /var/lib/dbus/machine-id from dbus and /sys/class/dmi/id/product_uuid from DMI which all contain 128 bits coded as hexadecimal numbers. I guess using the lower 32 bits for gethostid() is as good as any of the other options. > I am not even sure it's a good idea to fix this, it might be better to > just mark this function as deprecated, and encourage existing users of > this function (including hostid) to use something much longer than > 32-bit to avoid collisions. Mentioning alternatives with more bits in the gethostid() manual page definitely sound like a good idea. > One thing is sure however, if we change the current behaviour, it will > change the hostid on many systems, including ones which do not return > 007f0101. I agree what it should not be done automatically on existing installation. This is why I propose to set a value in /etc/hostid only on first time installation of libc6, and document in the manual page how to set it for those that want to modify an existing installation. -- Happy hacking Petter Reinholdtsen
Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed
[Michael Stone] > Other platforms have deprecated gethostid, that's the best way forward for > linux, IMO. Which platforms is this? I find FreeBSD recommend to use sysctl and KERN_HOSTID to get the hostid integer directly from the kernel instead of using gethostid(), which isn't really depricating the feature, only the way to get access to it. A quick search did not show any other platforms depricating the function and feature, so I am curious to learn what those are. > This proposal doesn't fix the problem generally and actually changes > the semantics of the call. (It was originally expected that the value > would remain constant independent of a particular OS installation, > which is not a property of a value stored on disk.) My proposal is to use the DMI info which should stay the same independent of OS installation. > The main users of hostid (that I'm aware of) tended to be commercial > software vendors locking licenses to systems--and they typically > didn't use gethostid on linux because it was useless for the > purpose. So I'm not aware of a userbase for this call on linux, and > nobody should be using it for new development. The users I am aware of is zfs-linux and the tools we wrote at work to detect when a Linux machine was reinstalled or had its hardware changed. The use case of zfs-linux require the ID to be unique among the machines sharing a storage solution, and not globally unique. A search in the source of all Debian packages[1] show this list of 148 packages mentioning the string 'gethostid': actiona alpine amanda apcupsd aplus-fsf arpwatch ats-lang-anairiats audit bacula bareos bluefish bsdgames burp busybox casacore cde cdrdao cdrkit chromium-browser cl-irc clisp cmucl condor coreutils ctwm cython dc3dd dcmtk deheader deja-dup dicom3tools dietlibc dist dmtcp dx e17 eclipse-titan edk2 emscripten erlang facter fpc frama-c freebsd-utils freetds fs-uae ga gcc-h8300-hms gdb ghc glibc gnucash gnulib gnustep-netclasses golang golang-1.6 golang-1.7 golang-golang-x-sys hercules highlight hugs98 hurd iputils isdnutils ivtools kfreebsd-10 krb5 ksh latrace ldc libcanberra libconvert-binary-c-perl libdata-uuid-perl libexplain libpam-tacplus libpcap libposix-2008-perl linux linux-grsec ltrace lua-posix manpages manpages-de manpages-es manpages-fr manpages-ja manpages-pl metview minc-tools mingw-w64 mono mono-reference-assemblies musl nam ncbi-tools6 netatalk newlib nim nmap nordugrid-arc ns2 ntirpc nwchem open-iscsi open-vm-tools openafs openmpi otp pidgin pidgin-nateon pimd polygraph praat prayer pulseaudio python-ptrace qemu radare2 rat roaraudio samhain sbcl silo-llnl sipxtapi slirp smlnj sniffit spl-linux splint strace talksoup.app tau tcpdump tcpslice tkrat topal trinity tripwire uclibc uclmmbase uhd uw-imap vde2 xfsdump yap zephyr zfs-fuse zfsutils. I do not know what they use gethostid() for. :) [1] curl -s https://codesearch.debian.net/results/2308ff3051ed55cc/packages.json | jq -r '.Packages[]' -- Happy hacking Petter Reinholdtsen
Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed
[Florian Weimer] > That's not very different from /etc/machine-id, isn't it? Ah, thank you very much for bringing this systemd setting to my attention. I was not aware of it. I agree that it seem very similar in purpose and implementation. Will it be available on non-linux Debian architectures too? >> We need to figure out how to transform the UUID to a 32 bit integer, >> of course. > > And I think this is the crux of the problem. Whatever we do, with > today's cluster sizes it's just not reliably unique. Well, for the set of machines we have available at work (ca. 3000) it would be sufficiently unique. For most sites it would make the return value from gethostid() unique. In most use cases it do not need need to globally unique. Like the ZFS use case, it just need to be unique among the hosts sharing the storage system. In another use case at work, it should be unique across the entire stock of linux machines. > You could use /etc/machine-id instead. Some effort goes into that to > make it actually unique. I will definitely put this systemd value in my tool box. Again, thank you very much for mentioning it. :) > DMI data seems risky because it depends on firmware, and there are so > many firmware bugs out there. I did not quite understand what you mean here. Do you mean the DMI value in your experience isn't unique? > It would also not address the matter of changing host IDs as the > result of host migrations. As far as I can tell, host migration could be solved by storing the wanted hostid in /etc/hostid when migrating. On an related note, I had a look at the POSIX definition for gethostuid()[1], and its "Upon successful completion, gethostid() shall return an identifier for the current host" is definitely very vague. So glibc is sure not violating POSIX by changing the value when the host changes IP address or commonly returning identical IDs on different machines, but real world applications on the other hand expect the hostid value to be reasonably unique and fixed across IP changes and reboots. [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/gethostid.html -- Happy hacking Petter Reinholdtsen
Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed
Control: reassign -1 libc6 Control: found -1 2.19-18 Control: The value from gethostid() should be more unique and not change when the host IP changes Reassigning to glibc as that is the source of gethostid() where the problem with the missing unique identifier originates. Using the version number in stable, but the issue have been around before that. In my work as a system administrator for tens of thousand of machines, I have often had the need to get some semi-unique identifier out of the operating system. On all other Unix like operating systems, hostid and gethostid() will provide this, but not on Linux. I find this rather sad, and have had to spend time generating our own solution to the problem because gethostid() is useless on Linux. Because of this, and to spare future system administrators to share that pain, I fully support the request from Martin Kraft to extend Debian to make sure the gethostid() value return something sensible. The described approach from FreeBSD, using /etc/hostid, /sys/class/dmi/id/product_uuid or a random value (in that order) seem like a sensible one. It might make sense to use other sources too, but the goal should be to pick a value that will stay the same until the hardware is replaced, and pick a value that will stay the same as long as the operating system isn't reinstalled if such hardware dependent value do not exist. To avoid changing the ID on running systems I believe it should only be done when libc6 is installed for the first time. Those willing to change their hostid at runtime should be provided a simple script to do so instead of doing it automatically. It will fix the issue for future installations. I am not sure how to sensibly fix it for existing installations without ending up with a lot of machines with the same hostid as 7f0100 is a very common hostid on Linux already, and everyone with a private IP address like those on 192.168.* will have collisions. But then again a 32 bit number can only provide 4.294.967.296 unique IDs and with the amount of Linux machines in the world there are going to be collisions anyway. We just should reduce the chance to a more sensible number. Something like this should work, I guess: if [ ! -f /etc/hostid ]; then if [ -e /sys/class/dmi/id/product_uuid ]; then sethostidfromuuid $(cat /sys/class/dmi/id/product_uuid) else dd if=/dev/urandom bs=1 count=4 of=/etc/hostid 2>/dev/null fi fi We need to figure out how to transform the UUID to a 32 bit integer, of course. -- Happy hacking Petter Reinholdtsen
Bug#705900: check_ping fail if host do not have IPv6 address
reassign 705900 libnss-myhostname thanks [Joachim Breitner] > just uploaded to unstable. I have never done a stable update, but I > guess I’ll have to wait for it to enter jessie (i.e. wait 10 days), > and then talk to the release team. Actually, I believe the correct approach is to file a pu reqest right now like the one I got in #706762, and use it to coordinate the upload to stable. I have not done it myself for a long time, so I am not quite sure, but one of the release managers said it was the correct first step. -- Happy hacking Petter Reinholdtsen -- 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/20130521181745.gt15...@ulrik.uio.no
Bug#705900: check_ping fail if host do not have IPv6 address
[Joachim Breitner] > I modified it to use a libc-provided macro to detect > link-local-addresses. It works here, but would you mind testing it in > your setup: > http://git.nomeata.de/?p=libnss-myhostname.git;a=summary It seem to work just fine when I test it too. :) I hope the fix will make it into Wheezy soon. :) -- Happy hacking Petter Reinholdtsen -- 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/20130513231413.gn13...@ulrik.uio.no
Bug#705900: check_ping fail if host do not have IPv6 address
So, to summarize: 1) 'check_ping $(hostname)' in Nagios fail when libnss-myhostname is active, because glibc return the IPv6 link local address when looking up the IP address of the local host. 2) ping6 can not ping the IPv6 link local address without an network interface specifier. The same happen with any IPv6 capable program. 3) I've provided a patch for libnss-myhostname to not return IPv6 link local addresses. 4) Upstream believe the patch should not be used, and claim libnss-myhostname is doing everything correct and the bug is in glibc and/or ping6. 5) The ping6 maintainer claim there is no bug in ping6 and glibc, as their handling of addresses in getaddrinfo() is according to the specification and work the same on Linux and FreeBSD. And thus we are left with a libnss-myhostname package that break any IPv6 capable program trying to connect to the local host name. Joachim, perhaps time to use the patch I provided in the Debian package, while we wait for these lofty old wizards to fight out their world view dispute? I fail to see the advantage of having libnss-myhostname, which is intended to make sure it is possible to look up the local host name and always get a working IP address, return an IPv6 address that can't be used to ping, connect or pass on. -- Happy hacking Petter Reinholdtsen -- 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/20130512060231.gg13...@ulrik.uio.no
Bug#657511: locales: Correct transliteration rules for nb_NO and nn_NO locales
[Aurelien Jarno] > Do you have a pointer to the original commit? The only things I have > been able to find is you submitting the patch on the upstream > mailing list, but no trace of a commit. Thank you for the heads up. I must have been looking at the wrong repository. when I visist http://repo.or.cz/w/glibc.git/blob/HEAD:/localedata/locales/nb_NO >, I see that this too is lacking correct transliteration for æøå. Do you have an idea how I can get correct transliteration for æøå into eglibc? -- Happy hacking Petter Reinholdtsen -- 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/20120128224145.gg17...@login2.uio.no
Bug#657511: locales: Correct transliteration rules for nb_NO and nn_NO locales
Package: locales Version: 2.11.2-10 Tags: patch Severity: important User: debian-...@lists.debian.org Usertags: debian-edu I discovered this while investigating a solution for #657086. The problem is that the transliteration rules for nb_NO (and perhaps also the general rules are incomplete and wrong. This causes bogus gecos and user names to be generated in GOsa. This is what I get at the moment: % echo ÆØÅæøå | iconv -t ASCII//TRANSLIT AE?Aae?a % This is what I expect: % echo ÆØÅæøå | iconv -t ASCII//TRANSLIT AeOeAaaeoeaa % In /usr/share/i18n/locales/nb_NO, I find this block: translit_start include "translit_combining";"" translit_end This surprised me, as the original nb_NO locale in GNU libc look like this and I knew this from when I worked on glibc locales: translit_start include "translit_combining";"" % Norwegian transliteration % LATIN CAPITAL LETTER A WITH RING ABOVE -> "Aa" "";"" % LATIN SMALL LETTER A WITH RING ABOVE -> "aa" "";"" % LATIN CAPITAL LETTER O WITH STROKE -> "Oe" "";"" % LATIN SMALL LETTER O WITH STROKE -> "oe" "";"" % LATIN CAPITAL LETTER AE -> "Ae" "" % LATIN SMALL LETTER AE -> "ae" "" translit_end This adjustment to the transliteration rules seem to have been lost when switching from glibc to eglibc. Please apply this patch to the nb_NO locale, to at least get correct transliteration with nb_NO and nn_NO locales. --- /usr/share/i18n/locales/nb_NO 2011-01-23 21:25:44.0 +0100 +++ /tmp/nb_NO.new 2012-01-26 19:04:18.0 +0100 @@ -127,6 +127,21 @@ translit_start include "translit_combining";"" + +% Norwegian transliteration +% LATIN CAPITAL LETTER A WITH RING ABOVE -> "Aa" + "";"" +% LATIN SMALL LETTER A WITH RING ABOVE -> "aa" + "";"" +% LATIN CAPITAL LETTER O WITH STROKE -> "Oe" + "";"" +% LATIN SMALL LETTER O WITH STROKE -> "oe" + "";"" +% LATIN CAPITAL LETTER AE -> "Ae" + "" +% LATIN SMALL LETTER AE -> "ae" + "" + translit_end END LC_CTYPE -- Happy hacking Petter Reinholdtsen -- 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/2fl39b2nxhb@diskless.uio.no
Bug#496915: Modifications related to GSoC project PamNssInstaller
Thank you for the feedback. [Aurelien Jarno] > Like any wishlist bug this bug will stay out of the radar until we > have some more manpower. > > I haven't tested the patch, but the main problem I see is that this > is a perl script. We certainly don't want to make libc6 or libc-bin > depends on perl, which will introduce another dependency loop. Also > it's probably not a good choice while people are trying to remove > the usage of perl in the base system. Perhaps it is better to move this feature to a separate package, like the update-inetd package? Seem a bit overkill to create a new package for a simple perl script, but it might be the best way to do this. Happy hacking, -- Petter Reinholdtsen -- 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/20100530102257.gh5...@login1.uio.no
Bug#496915: Modifications related to GSoC project PamNssInstaller
Any hope of having this system for handling /etc/nsswitch.conf integrated into Debian any time soon? It would be very nice to have this in place before Squeeze. With pam-auth-update in place, the need for automatic configuration of nsswitch.conf is even more pressing when wanting to configure PAM and NSS out of the box. :) Happy hacking, -- Petter Reinholdtsen -- 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/20100529155840.gc5...@login1.uio.no
Bug#485282: nscd: Change default cache setting to work better with roaming laptops
According to the glibc developer Ulrich Drepper, nscd should be able to handle disconnected operations. See https://bugzilla.redhat.com/show_bug.cgi?id=145044 > and http://sources.redhat.com/bugzilla/show_bug.cgi?id=2132 > for background information. An alternative solution is to get sssd into Debian, but its WNPP request (#579593) is still not acted on. Besides, I have problems getting sssd to work, but suspect that is only because I do not yet know how to configure it properly. Happy hacking, -- Petter Reinholdtsen -- 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/20100504112440.gd14...@login1.uio.no
Bug#485282: nscd: Change default cache setting to work better with roaming laptops
[Petter Reinholdtsen] > If increased timeout is left out from the default configuration, > please implement support for sourcing /etc/default/nscd and allow a > policy compliant mechanism to replace the configuration file used by > nscd. Something like this would make that possible, as long as the /etc/default/nscd fil is not included in the nscd package. --- nscd.orig 2010-05-02 09:18:23.770594050 +0200 +++ nscd2010-05-02 09:23:22.494799709 +0200 @@ -21,10 +21,15 @@ DESC="Name Service Cache Daemon" DAEMON="/usr/sbin/nscd" PIDFILE="/var/run/nscd/nscd.pid" +CONFFILE=/etc/nscd.conf +OPTIONS # Sanity checks. umask 022 -[ -f /etc/nscd.conf ] || exit 0 + +if [ -r /etc/default/nscd ]; then . /etc/default/nscd ; fi + +[ -f "$CONFFILE" ] || exit 0 [ -x "$DAEMON" ] || exit 0 [ -d /var/run/nscd ] || mkdir -p /var/run/nscd . /lib/lsb/init-functions @@ -34,7 +39,7 @@ # Return # 0 if daemon has been started or was already running # 2 if daemon could not be started - start-stop-daemon --start --quiet --pidfile "$PIDFILE" --exec "$DAEMON" || return 2 + start-stop-daemon --start --quiet --pidfile "$PIDFILE" --exec "$DAEMON" -- $OPTIONS || return 2 } stop_nscd() Happy hacking, -- Petter Reinholdtsen -- 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/20100502072536.gk12...@login2.uio.no
Bug#485282: nscd: Change default cache setting to work better with roaming laptops
Great to have more feedback on this issue. :) I hope someone with knowledge and experience on offline operation of a networked laptop can share their view. :) [Marco d'Itri] > And what about the increased memory usage on large systems? What increased memory usage? I got nscd running on a laptop connected to the university of Oslo with ~6 users and ~6000 groups, and do not see large memory usage by nscd. > I am not persuaded at all that this change is appropriate for the > default configuration. I'd even say that supporting offline nscd > lookups is a corner case that does not justify the possible negative > effects for everybody else. Well, at least here at the university, laptops are becoming the normal setup, and having offline authentication and operation work is becoming a vital requirement. :) If bugs #485282, #566718 and #568577 are solved, it would be a simple matter of installing nscd and libpam-ccreds to get it in Debian. :) > What about deleted user? Deleted users still existing for 30 days > could be a nasty security issue. You seem to be arguing only against the increased positive time to live. Is that the case? For offline operation, I suspect the "reload-count unlimited" setting is the most important one. If increased timeout is left out from the default configuration, please implement support for sourcing /etc/default/nscd and allow a policy compliant mechanism to replace the configuration file used by nscd. Happy hacking, -- Petter Reinholdtsen -- 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/20100502071020.gj12...@login2.uio.no
Bug#485282: nscd: Change default cache setting to work better with roaming laptops
[Clint Adams] > Is the danger of the cache being 30 days out-of-date not a worry in > practice? It depends, I guess. I suspect those worring about that will just deinstall nscd to avoid it. The most worrying part for a roaming laptop is the fact that entries in the cache disappear after a while. When one is on a reseach trip for several weeks, one do not want to be locked out of ones laptop because the cache was purged. How often will the cache content be verified with the default and the 30 day time-to-live? I would like the content to be verified when the laptop is able to connect to LDAP, and never disappears when the laptop is unable to connect to LDAP. I do not understand all aspects of the setting for roaming laptops, so I very much welcome input on my proposed settings, which were based on a working setup for disconnected operation. Happy hacking, -- Petter Reinholdtsen -- 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/20100429171406.ga32...@login2.uio.no
Bug#485282: nscd: Change default cache setting to work better with roaming laptops
found 485282 2.10.2-6 tag 485282 + patch userdebian-...@lists.debian.org usertags 485282 + debian-edu As described earlier, for nscd to work properly with laptops using a remote directory service like LDAP, the nscd cache values need to be tuned a bit. Based on the recipe available from http://www.flyn.org/laptopldap/>, it is possible to configure nscd to work while offline by allowing it to cache values longer, and to not require a reload when a value has been used for a few times. To allow disconnected operations to be working out of the box in Debian by installing the libpam-ccreds and nscd packages, I propose to apply this change to the default nscd.conf settings. The positive-time-to-live value is 30 days in seconds. --- a/nscd.conf +++ b/nscd.conf @@ -36,12 +36,12 @@ # server-user nobody # stat-user somebody debug-level 0 -# reload-count5 + reload-countunlimited paranoiano # restart-interval3600 enable-cachepasswd yes - positive-time-to-live passwd 600 + positive-time-to-live passwd 2592000 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes @@ -51,7 +51,7 @@ auto-propagate passwd yes enable-cachegroup yes - positive-time-to-live group 3600 + positive-time-to-live group 2592000 negative-time-to-live group 60 suggested-size group 211 check-files group yes @@ -72,7 +72,7 @@ max-db-size hosts 33554432 enable-cacheservicesyes - positive-time-to-live services28800 + positive-time-to-live services2592000 negative-time-to-live services20 suggested-size services211 check-files servicesyes Happy hacking, -- Petter Reinholdtsen -- 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/2flwrvqbfbs@login1.uio.no
Bug#541492: nscd: Missing init.d dependency on $syslog
Package: nscd Version: 2.3.5-8 Severity: important Tags: patch User: initscripts-ng-de...@lists.alioth.debian.org Usertags: incorrect-dependency With dependency based boot sequencing, I discovered what I believe is a slight bug in the init.d script. The dependencies are not correct. The daemon seem to log to syslog, and thus should depend on $syslog. This will make nscd start before the syslog implementation, and the first syslog messages logged might be lost. http://refspecs.freestandards.org/LSB_2.1.0/LSB-generic/LSB-generic/initscrcomconv.html > documents the LSB header format. Some debian notes are available from http://wiki.debian.org/LSBInitScripts >. This patch should solve the issue. Without it, the init.d will start to early in the boot sequence. diff -ur eglibc-2.9/debian/debhelper.in/nscd.init eglibc-2.9-pere/debian/debhelper.in/nscd.init --- eglibc-2.9/debian/debhelper.in/nscd.init2009-08-14 18:42:13.0 +0200 +++ eglibc-2.9-pere/debian/debhelper.in/nscd.init 2009-08-14 18:40:00.0 +0200 @@ -1,8 +1,8 @@ #!/bin/sh ### BEGIN INIT INFO # Provides: nscd -# Required-Start:$remote_fs -# Required-Stop: $remote_fs +# Required-Start:$remote_fs $syslog +# Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Starts the Name Service Cache Daemon Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#485282: nscd: Allow install time configuration of disconnected operation
[Petter Reinholdtsen] > One approach would be to change the default configuration in > /etc/nscd.conf to use a longer timeout for the cache values. For > example these values to get 30 days timeout: > > positive-time-to-live passwd 2592000 > positive-time-to-live group 2592000 > positive-time-to-live hosts 2592000 Another approach is to set the reload-count value to 'unlimited'. I am not sure if this should be done in addition to or just instead of increasing the ttl values. Until it is well known how to configure laptops for disconnected operation, I suspect it is best to provide a simple way to replace nscd.conf instead of changing the default values. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485282: nscd: Allow install time configuration of disconnected operation
Package: nscd Version: 2.3.6.ds1-13 According to documentation on how to set up Linux laptops for disconnected operations with LDAP and Kerberos, one key configuration setting to update is the nscd caching time. The other part is using libpam_ccreds to cache the user password for disconnected authentication. See http://www.flyn.org/laptopldap/laptopldap.html >, http://fedoraproject.org/wiki/Features/DisconnectedOperation > and http://www.builderau.com.au/program/linux/soa/Authentication-caching-with-nscd/0,339028299,339285682,00.htm> for background information. The default TTL for NSS entries is 1 hour at the moment, while it need to be a lot more for this to work with disconnected operations. I would like to be able to configure this automatically at install time for Debian Edu, and I see two obvious approaches to do this in a policy compliant way. The issue here is that /etc/nscd.conf is a conffile, and policy require that any editing need to be done by the nscd package. One approach would be to change the default configuration in /etc/nscd.conf to use a longer timeout for the cache values. For example these values to get 30 days timeout: positive-time-to-live passwd 2592000 positive-time-to-live group 2592000 positive-time-to-live hosts 2592000 An alternative is to make it possible to switch to a different nscd.conf file at install time, by changing /etc/init.d/nscd to allow a configuration option to be provided in a non-conffile we can provide in Debian Edu (for example by reading a list of extra options to use from /etc/default/nscd and not include that file in the nscd package). This way we could add that file with content like OPTIONS="-f /etc/nscd.conf-debian-edu" and provide the longer timeout values in this file. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#464022: nscd: Incorrect init.d script dependencies
Package: nscd Version: 2.7-6 Severity: important Tags: patch User: [EMAIL PROTECTED] Usertags: incorrect-dependency When testing dependency based boot sequencing, I discovered what I believe is a bug in the init.d/nscd script. It need a mounted /usr/, but do not depend on $remote_fs which is the dependency required for scripts needing /usr/. I am working on a system to update the boot sequence based on these dependencies, and would like see this as the default in Lenny. Because of this, it is nice if the dependencies was updated quickly. http://refspecs.freestandards.org/LSB_2.1.0/LSB-generic/LSB-generic/initscrcomconv.html> documents the LSB header format. Some debian notes are available from http://wiki.debian.org/LSBInitScripts>. This patch should solve the issue. Without it, nscd is started too early and stopped to late when dependency based boot sequencing is enabled. --- /etc/init.d/nscd2008-01-12 21:21:53.0 +0100 +++ /tmp/nscd 2008-02-04 20:22:22.0 +0100 @@ -1,8 +1,8 @@ #!/bin/sh ### BEGIN INIT INFO # Provides: nscd -# Required-Start:$local_fs -# Required-Stop: $local_fs +# Required-Start:$remote_fs +# Required-Stop: $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Starts the Name Service Cache Daemon Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457661: nscd: Please use lsb output functions in init.d/nscd
[Clint Adams] > Please try the attached file and see if that does what you want. It does. I tested, and both the start, stop and restart functions worked as I want. :) I did not test any error reporting. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457661: nscd: Please use lsb output functions in init.d/nscd
Package: nscd Version: 2.7-5 When using nscd with the progress bar and console in usplash, no message show up when nscd is started. The reason is that the init.d script do not use the output functions in /lib/lsb/init-functions, but uses echo directly. usplash override the functions in /lib/lsb/init-functions to feed the text into the graphical boot screen, and thus depend on the use of the lsb output functions. Please change the init.d script to use the lsb output functions. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340147: /etc/init.d/glibc.sh must use ': exit 0' instead of 'exit 0'
Package: libc6 Version: 2.3.5-5 Severity: serious The script /etc/init.d/glibc.sh can not be sourced, as it contain 'exit 0' at the end of the script. This is against policy, specifying that all .sh scripts in /etc/rcS.d/ will be sourced. I discovered this while fixing sysv-rc (bug #339955), as the boot started to fail because glibc.sh terminated the script running the files in /etc/rcS.d/. Changing 'exit 0' to ': exit 0' solved the issue. Setting severity serious, as this Debian Policy §9.3.1 require .sh scripts in runlevel S to be sourced, and this is impossible as long as this bug is open.
Bug#335343: nscd: Please add LSB formatted dependency info in init.d script
Package: nscd1 Version: 2.3.2.ds1-22 Severity: wishlist To be able to check boot script order, and also to be able to start boot scripts in parallel, it is important to know the dependencies of the various boot scripts. The Linux Software Base specifies a init.d header file format useful for this purpose, and adding such header to the init.d scripts would make it possible for me to use this information to check the current sequence and speed up the debian boot. http://refspecs.freestandards.org/LSB_2.1.0/LSB-generic/LSB-generic/initscrcomconv.html> documents the LSB header format. Some debian notes are available from http://wiki.debian.org/?LSBInitScripts>. Here is a proposed dependency header to document the dependencies of nscd. It is slightly tested using the insserv package and the new parallell booting support in sysvinit. ### BEGIN INIT INFO # Provides: nscd # Required-Start:$syslog # Required-Stop: $syslog # Should-Start: $network slapd $named # Should-Stop: $network slapd $named # Default-Start: 2 3 4 5 # Default-Stop: S 0 1 6 ### END INIT INFO -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335308: glibc: Please add LSB formatted dependency info in init.d script
Package: libc6 Version: 2.3.5-7 Severity: wishlist To be able to check boot script order, and also to be able to start boot scripts in parallel, it is important to know the dependencies of the various boot scripts. The Linux Software Base specifies a init.d header file format useful for this purpose, and adding such header to the init.d scripts would make it possible for me to use this information to check the current sequence and speed up the debian boot. http://refspecs.freestandards.org/LSB_2.1.0/LSB-generic/LSB-generic/initscrcomconv.html> documents the LSB header format. Some debian notes are available from http://wiki.debian.org/?LSBInitScripts>. Here is a proposed dependency header to document the dependencies of glibc.sh. It is slightly tested using the insserv package and the new parallell booting support in sysvinit. ### BEGIN INIT INFO # Provides: glibc # Required-Start: # Required-Stop: # Default-Start: S # Default-Stop: ### END INIT INFO -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320515: BITS_PER_LONG used unconditionally but defined only if __KERNEL__ is defined
This problem affect clanlib as well. I'm trying to prepare an NMU to get it to use the new C++ ABI, and ran into this compile error: Compiling Sources/Display/Input/X11/joystick_linux.cpp In file included from Sources/Display/Input/X11/joystick_linux.h:45, from Sources/Display/Input/X11/joystick_linux.cpp:25: /usr/include/linux/joystick.h:142:2: error: #error Unexpected BITS_PER_LONG make: *** [Libs/Intermediate/joystick_linux.o] Error 1 The propsed patch solved the compile problem of Sources/Display/Input/X11/joystick_linux.cpp. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BoF at Debconf5 about glibc locale file format
[Denis Barbier] > I will be very glad to share this presentation with anyone involved > in glibc locales, please drop me a note if you are interested. I'm interested. Should we tell this to libc-locales@ as well, in case someone there want to join? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#231748: libc6-dev: programs using HUGE_VAL will issue a warning when compiled with -pedantic on the g++-3.3
Followup-For: Bug #231748 Package: libc6-dev Version: 2.3.2.ds1-20 I ran into the same problem when trying to compile mapserver with -pedantic using gcc 3.3.5. Not sure how to solve the problem, but this bug make it hard to convince the mapserver developers to use -pendantic. I want to convince them to add more warnings flags in a try to get the code ready for all the archs in Debian, and it gets harder when bogus warnings are emited from the compiler. :/ -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.26-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libc6-dev depends on: ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii linux-kernel-headers 2.5.999-test7-bk-17 Linux Kernel Headers for developme -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: locale ([EMAIL PROTECTED]) generation bug in sarge
[GOTO Masanori] > I got the report from Pasi, he said [EMAIL PROTECTED] locale could be choosed > via (I guess) language-chooser (or country-chooser?) in > debian-installer. However, debian glibc locales packages does not > have [EMAIL PROTECTED] So when he upgraded locales package, installation > was stopped because [EMAIL PROTECTED] is not existed in locales. > > Debian-boot guys, is it debian-installer bug? Yes, it is a bug in languagechooser or countrychooser. They are not supposed to select locales which are missing in the SUPPORTED list. Christian is looking into the issue. But should the locales package fail to upgrade even if there is garbage in /etc/locale.gen? That sounds like a bug in the locales package to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#272265: libc6: Programs should reload /etc/resolv.conf when it changes
Package: libc6
Version: 2.3.2.ds1-16
Tags: patch
Severity: wishlist
The current DNS resolver in glibc only read the content of
/etc/resolv.conf when a program starts (or during the first call to
one of the resolver function). This is a problem for long-lasting
programs on for example laptops, where the content of the file may
change when a new IP configuration is fetched using DHCP. A
workaround is to use nscd and call 'nscd -i hosts' when the file
changes, but it would be better if the content of the file was reread
automatically when it changes.
The following patch by Torstein Kukuk from
http://sources.redhat.com/ml/libc-alpha/2004-09/msg00130.html>
fixes this problem, by making sure the timestamp of the file is
checked every time a DNS lookup is done.
Please include this patch in the default glibc used in Debian. It
would make it so much useful on machines with changing IP
configuration.
--- resolv/res_libc.c 6 Aug 2004 17:52:53 - 1.20
+++ resolv/res_libc.c 9 Aug 2004 15:14:47 -
@@ -22,7 +22,7 @@
#include
#include
#include
-
+#include
/* The following bit is copied from res_data.c (where it is #ifdef'ed
out) since res_init() should go into libc.so but the rest of that
@@ -100,8 +100,17 @@ res_init(void) {
int
__res_maybe_init (res_state resp, int preinit)
{
- if (resp->options & RES_INIT) {
- if (__res_initstamp != resp->_u._ext.initstamp) {
+ static time_t last_mtime;
+ struct stat statbuf;
+ int ret;
+
+
+ if (resp->options & RES_INIT) {
+ ret = stat (_PATH_RESCONF, &statbuf);
+ if (__res_initstamp != resp->_u._ext.initstamp
+ || (ret == 0) && (last_mtime != statbuf.st_mtime))
+ {
+ last_mtime = statbuf.st_mtime;
if (resp->nscount > 0) {
__res_nclose (resp);
for (int ns = 0; ns < MAXNS; ns++) {
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#260377: libc6: strtold() fail on number with many fraction digits
A patch to fix it is available from http://sources.redhat.com/ml/libc-hacker/2004-07/msg00042.html>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#260377: libc6: strtold() fail on number with many fraction digits
A patch to fix it is available from http://sources.redhat.com/ml/libc-hacker/2004-07/msg00042.html>.
Bug#260377: libc6: strtold() fail on number with many fraction digits
This problem is now reported upstream into glibc bugzilla as http://sources.redhat.com/bugzilla/show_bug.cgi?id=274 >.
Bug#260377: libc6: strtold() fail on number with many fraction digits
This problem is now reported upstream into glibc bugzilla as http://sources.redhat.com/bugzilla/show_bug.cgi?id=274 >. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#260377: libc6: strtold() fail on number with many fraction digits
Package: libc6
Version: 2.3.2.ds1-13
I came across a bug report on the glibc-bug mailing list, and decided
to test the example code in Debian/Unstable. IT seem to fail there
too, so I guess the problem isn't fixed in glibc yet.
This is the output from the program:
String '42.001' converts to long double
42.
String '42.0001' converts to long double
0.
String '42.01' converts to long double
0.
I expected the last two conversions to end up as 42.0, not 0.0. Am I
mistaken?
Here is the source.
/*
* Demonstrate bug in strtold() in glibc. The last two number strings
* converts to 0, not 42 as it should.
* Based on code from Ivano Primi and modified by Petter Reinholdtsen.
*/
#include
#include
#include
extern int errno;
extern long double strtold(const char *nptr, char **endptr);
int main (void)
{
char *numbers[] = {
"42.001",
"42.0001",
"42.01",
};
char* endptr;
long double x;
int i;
errno = 0;
for (i = 0; i < 3; i++) {
x = strtold (numbers[i], &endptr);
if ( endptr == numbers[i] && x == 0 )
{
fprintf (stderr, " *** Unagreable input\n");
return 1;
}
else if ( errno != 0 )
{
if ( x == 0 )
fprintf (stderr, " *** Underflow\n");
else
fprintf (stderr, " *** Overflow\n");
return 2;
}
else
{
printf ("String '%s' converts to long double %.20Lf\n", numbers[i], x);
}
}
return 0;
}
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1-686
Locale: LANG=C, LC_CTYPE=C
Versions of packages libc6 depends on:
ii libdb1-compat 2.1.3-7The Berkeley database routines [gl
-- no debconf information
Bug#260377: libc6: strtold() fail on number with many fraction digits
Package: libc6
Version: 2.3.2.ds1-13
I came across a bug report on the glibc-bug mailing list, and decided
to test the example code in Debian/Unstable. IT seem to fail there
too, so I guess the problem isn't fixed in glibc yet.
This is the output from the program:
String '42.001' converts to long double 42.
String '42.0001' converts to long double 0.
String '42.01' converts to long double 0.
I expected the last two conversions to end up as 42.0, not 0.0. Am I
mistaken?
Here is the source.
/*
* Demonstrate bug in strtold() in glibc. The last two number strings
* converts to 0, not 42 as it should.
* Based on code from Ivano Primi and modified by Petter Reinholdtsen.
*/
#include
#include
#include
extern int errno;
extern long double strtold(const char *nptr, char **endptr);
int main (void)
{
char *numbers[] = {
"42.001",
"42.0001",
"42.01",
};
char* endptr;
long double x;
int i;
errno = 0;
for (i = 0; i < 3; i++) {
x = strtold (numbers[i], &endptr);
if ( endptr == numbers[i] && x == 0 )
{
fprintf (stderr, " *** Unagreable input\n");
return 1;
}
else if ( errno != 0 )
{
if ( x == 0 )
fprintf (stderr, " *** Underflow\n");
else
fprintf (stderr, " *** Overflow\n");
return 2;
}
else
{
printf ("String '%s' converts to long double %.20Lf\n", numbers[i], x);
}
}
return 0;
}
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1-686
Locale: LANG=C, LC_CTYPE=C
Versions of packages libc6 depends on:
ii libdb1-compat 2.1.3-7The Berkeley database routines [gl
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#248377: locales: Wrong thousands_sep value in fr_FR locale
[GOTO Masanori] > At Mon, 10 May 2004 22:33:51 +0200, > Sebastien Bacher wrote: > > $ grep ^thous /usr/share/i18n/locales/fr_FR > > thousands_sep "" > > > > But the french separator for thousands is a space and not empty > > Petter, Denis, should this be fixed? Note that glibc uses fr_FR > defined by ISO sample locale file. I have no idea if it is wrong or not. I notice that the monetary formatting in fr_FR uses grouping and space as separator, while numeric formating does not. I suggest registering the issue at http://sources.redhat.com/bugzilla/>. Collecting a comment from the original locale author, Keld Simonsen, is probably a good idea as well.
Bug#248377: locales: Wrong thousands_sep value in fr_FR locale
[GOTO Masanori] > At Mon, 10 May 2004 22:33:51 +0200, > Sebastien Bacher wrote: > > $ grep ^thous /usr/share/i18n/locales/fr_FR > > thousands_sep "" > > > > But the french separator for thousands is a space and not empty > > Petter, Denis, should this be fixed? Note that glibc uses fr_FR > defined by ISO sample locale file. I have no idea if it is wrong or not. I notice that the monetary formatting in fr_FR uses grouping and space as separator, while numeric formating does not. I suggest registering the issue at http://sources.redhat.com/bugzilla/>. Collecting a comment from the original locale author, Keld Simonsen, is probably a good idea as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#246170: locales: no_NO ISO-8859-1 missing ?
[Denis Barbier] > to locale.alias, but IIRC Petter would like real locales and not > aliases because otherwise gettext won't process no.po files. The missing no_NO ISO-8859-1 is a bug. I want to have both no_NO and nb_NO listed while we complete the move to nb_NO. % grep n._NO /usr/share/i18n/SUPPORTED nb_NO.UTF-8 UTF-8 nb_NO ISO-8859-1 no_NO.UTF-8 UTF-8 nn_NO.UTF-8 UTF-8 nn_NO ISO-8859-1 % It should list "no_NO ISO-8859-1" as well. It used to be there before the SUPPORTED list was updated from glibc CVS. It should be reinserted.
Bug#245657: ro_RO ISO-8859-2 generation broken
[GOTO Masanori] >> glibc CVS together with the files in localedata/. > > What does this mean? I am thinking about the script used to generate 11_cvs_locales.dpatch. It is probably a good idea include locale/iso-3166.def as well.
Bug#246170: locales: no_NO ISO-8859-1 missing ?
[Denis Barbier] > to locale.alias, but IIRC Petter would like real locales and not > aliases because otherwise gettext won't process no.po files. The missing no_NO ISO-8859-1 is a bug. I want to have both no_NO and nb_NO listed while we complete the move to nb_NO. % grep n._NO /usr/share/i18n/SUPPORTED nb_NO.UTF-8 UTF-8 nb_NO ISO-8859-1 no_NO.UTF-8 UTF-8 nn_NO.UTF-8 UTF-8 nn_NO ISO-8859-1 % It should list "no_NO ISO-8859-1" as well. It used to be there before the SUPPORTED list was updated from glibc CVS. It should be reinserted. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#245657: ro_RO ISO-8859-2 generation broken
[GOTO Masanori] >> glibc CVS together with the files in localedata/. > > What does this mean? I am thinking about the script used to generate 11_cvs_locales.dpatch. It is probably a good idea include locale/iso-3166.def as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#245657: ro_RO ISO-8859-2 generation broken
It is probably a good idea to update locale/iso-3166.def from the glibc CVS together with the files in localedata/.
Bug#245657: ro_RO ISO-8859-2 generation broken
It is probably a good idea to update locale/iso-3166.def from the glibc CVS together with the files in localedata/. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#208238: marked as done (locales: wrong charset for et_EE)
[Denis Barbier] > The attached dpatch was used to close this bug. But its comment is not > accurate, this dpatch adds a et_EE.ISO-8859-15 locale (and is then > identical to upstream fix) whereas bug log and dpatch comment seem > to imply that et_EE charset was changed from ISO-8859-1 to ISO-8859-15. > > Denis > [2 locale-et_EE.dpatch ] > #! /bin/sh -e > > # All lines beginning with `# DP:' are a description of the patch. > # DP: Description: List et_EE with charset ISO-8859-15 as a supported locale I do not quite understand how you interpret "List et_EE with charset ISO-8859-15 as a supported locale" to mean that the charset was changed. [GOTO Masanori] > "Change default charset for et_EE locale from ISO-8859-1 to > ISO-8859-15." is acceptable? Well, it didn't really change. The fix accepted by upstream is to add an extra entry for et_EE with ISO-8859-15 charset. Ulrich didn't accept to change the default charset.
Re: Bug#208238: marked as done (locales: wrong charset for et_EE)
[Denis Barbier] > The attached dpatch was used to close this bug. But its comment is not > accurate, this dpatch adds a et_EE.ISO-8859-15 locale (and is then > identical to upstream fix) whereas bug log and dpatch comment seem > to imply that et_EE charset was changed from ISO-8859-1 to ISO-8859-15. > > Denis > [2 locale-et_EE.dpatch ] > #! /bin/sh -e > > # All lines beginning with `# DP:' are a description of the patch. > # DP: Description: List et_EE with charset ISO-8859-15 as a supported locale I do not quite understand how you interpret "List et_EE with charset ISO-8859-15 as a supported locale" to mean that the charset was changed. [GOTO Masanori] > "Change default charset for et_EE locale from ISO-8859-1 to > ISO-8859-15." is acceptable? Well, it didn't really change. The fix accepted by upstream is to add an extra entry for et_EE with ISO-8859-15 charset. Ulrich didn't accept to change the default charset. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#207199: locales: locale-gen should complain about malformed /etc/locale.gen files
tags 207199 + patch
thanks
Here is a patch to fix this problem. It teaches the script to ignore
empty lines, and to write an error if the line don't have at least two
words.
This is the output when I tested it
Generating locales...
error: Bad entry 'en_US.ISO-8859-1 '
error: Bad entry 'en_US.UTF-8 '
Generation complete.
--- /usr/sbin/locale-gen2003-10-28 23:07:31.0 +
+++ /tmp/locale-gen 2004-04-17 22:20:41.0 +
@@ -17,10 +17,19 @@
umask 022
+is_entry_ok() {
+ if [ -n "$locale" -a -n "$charset" ] ; then
+true
+ else
+echo "error: Bad entry '$locale $charset'"
+false
+ fi
+}
+
echo "Generating locales..."
while read locale charset; do \
- case $locale in \#*) continue;; esac; \
- [ -n "$locale" -a -n "$charset" ] || continue
+ case $locale in \#*) continue;; "") continue;; esac; \
+ is_entry_ok || continue
echo -n " `echo $locale | sed 's/\([EMAIL PROTECTED]).*/\1/'`"; \
echo -n ".$charset"; \
echo -n `echo $locale | sed 's/\([EMAIL PROTECTED])\([EMAIL
PROTECTED])*/\2/'`; \
Bug#207199: locales: locale-gen should complain about malformed /etc/locale.gen files
tags 207199 + patch
thanks
Here is a patch to fix this problem. It teaches the script to ignore
empty lines, and to write an error if the line don't have at least two
words.
This is the output when I tested it
Generating locales...
error: Bad entry 'en_US.ISO-8859-1 '
error: Bad entry 'en_US.UTF-8 '
Generation complete.
--- /usr/sbin/locale-gen2003-10-28 23:07:31.0 +
+++ /tmp/locale-gen 2004-04-17 22:20:41.0 +
@@ -17,10 +17,19 @@
umask 022
+is_entry_ok() {
+ if [ -n "$locale" -a -n "$charset" ] ; then
+true
+ else
+echo "error: Bad entry '$locale $charset'"
+false
+ fi
+}
+
echo "Generating locales..."
while read locale charset; do \
- case $locale in \#*) continue;; esac; \
- [ -n "$locale" -a -n "$charset" ] || continue
+ case $locale in \#*) continue;; "") continue;; esac; \
+ is_entry_ok || continue
echo -n " `echo $locale | sed 's/\([EMAIL PROTECTED]).*/\1/'`"; \
echo -n ".$charset"; \
echo -n `echo $locale | sed 's/\([EMAIL PROTECTED])\([EMAIL
PROTECTED])*/\2/'`; \
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#226047: libc6: Bad strfmon() formatting should be fixed (patch in upstream CVS)
Here is a dpatch file to implement the code change. With these
changes, it at the moment should be safe to just copy all changes from
localedata/ directly from glibc CVS.
#! /bin/sh -e
# All lines beginning with `# DP:' are a description of the patch.
# DP: Description: Correct strfmon() formatting
# DP: Related bugs: @226047
# DP: Author: Petter Reinholdtsen
# DP: Upstream status: In CVS
# DP: Status Details:
# DP: Date: 2004-03-21
# DP: 2004-01-01 Petter Reinholdtsen <[EMAIL PROTECTED]>
# DP:
# DP: * stdlib/strfmon.c: Make formatting of left-justified currency
# DP: values match the POSIX standard. When using format string
# DP: "[%-14#5.4n]" to print -123.45, the result should be
# DP: "[-$ 123.4500 ]", not "[-$123.4500 ]".
# DP:
# DP: 2003-11-30 Petter Reinholdtsen <[EMAIL PROTECTED]>
# DP:
# DP: * stdlib/strfmon.c: Correct formatting of international currency
# DP: values. The international currency formatting should prefer the
# DP: int_* values if they are set for a locale, and use the domestic
# DP: values if the int_* values are unset.
if [ $# -ne 2 ]; then
echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
exit 1
fi
case "$1" in
-patch) patch -d "$2" -f --no-backup-if-mismatch -p1 < $0;;
-unpatch) patch -d "$2" -f --no-backup-if-mismatch -R -p1 < $0;;
*)
echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
exit 1
esac
exit 0
# append the patch here and adjust the -p? flag in the patch calls.
Index: stdlib/strfmon.c
===
RCS file: /cvs/glibc/libc/stdlib/strfmon.c,v
retrieving revision 1.23
retrieving revision 1.25
diff -u -3 -p -u -r1.23 -r1.25
--- stdlib/strfmon.c3 Aug 2002 06:29:57 - 1.23
+++ stdlib/strfmon.c2 Jan 2004 00:58:19 - 1.25
@@ -1,5 +1,5 @@
/* Formatting a monetary value according to the current locale.
- Copyright (C) 1996-2001, 2002 Free Software Foundation, Inc.
+ Copyright (C) 1996-2001, 2002, 2003, 2004 Free Software Foundation, Inc.
This file is part of the GNU C Library.
Contributed by Ulrich Drepper <[EMAIL PROTECTED]>
and Jochen Hein <[EMAIL PROTECTED]>, 1996.
@@ -128,6 +128,7 @@ __strfmon_l (char *s, size_t maxsize, __
__long_double_t ldbl;
}
fpnum;
+ int int_format;
int print_curr_symbol;
int left_prec;
int left_pad;
@@ -172,6 +173,7 @@ __strfmon_l (char *s, size_t maxsize, __
}
/* Defaults for formatting. */
+ int_format = 0; /* Use international curr. symbol */
print_curr_symbol = 1; /* Print the currency symbol. */
left_prec = -1; /* No left precision specified. */
right_prec = -1; /* No right precision specified. */
@@ -233,13 +235,6 @@ __strfmon_l (char *s, size_t maxsize, __
break;
}
- /* If not specified by the format string now find the values for
-the format specification. */
- if (p_sign_posn == -1)
- p_sign_posn = *_NL_CURRENT (LC_MONETARY, P_SIGN_POSN);
- if (n_sign_posn == -1)
- n_sign_posn = *_NL_CURRENT (LC_MONETARY, N_SIGN_POSN);
-
if (isdigit (*fmt))
{
/* Parse field width. */
@@ -305,31 +300,27 @@ __strfmon_l (char *s, size_t maxsize, __
}
/* Handle format specifier. */
+ char int_symbol[4];
switch (*fmt++)
{
- case 'i': /* Use international currency symbol. */
- currency_symbol = _NL_CURRENT (LC_MONETARY, INT_CURR_SYMBOL);
+ case 'i': { /* Use international currency symbol. */
+ const char *int_curr_symbol;
+
+ int_curr_symbol = _NL_CURRENT (LC_MONETARY, INT_CURR_SYMBOL);
+ strncpy(int_symbol, int_curr_symbol, 3);
+ int_symbol[3] = '\0';
+
currency_symbol_len = 3;
- space_char = currency_symbol[3];
- if (right_prec == -1)
- {
- if (*_NL_CURRENT (LC_MONETARY, INT_FRAC_DIGITS) == CHAR_MAX)
- right_prec = 2;
- else
- right_prec = *_NL_CURRENT (LC_MONETARY, INT_FRAC_DIGITS);
- }
+ currency_symbol = &int_symbol[0];
+ space_char = int_curr_symbol[3];
+ int_format = 1;
break;
+ }
case 'n': /* Use national currency symbol. */
currency_symbol = _NL_CURRENT (LC_MONETARY, CURRENCY_SYMBOL);
currency_symbol_len = strlen (currency_symbol);
space_char = ' ';
- if (right_prec == -1)
- {
- if (*_NL_CURRENT (LC_MONETARY, FRAC_DIGITS) == CHAR_MAX)
- right_prec = 2;
- else
-
Bug#231972: lkh: /usr/include/linux/ptrace.h buggy
Here is more info on the problem.
The issue is that 'struct user' in on s390 need 'struct
user_regs_struct' from , and this need type
's390_fp_regs' which need type 'freq_t' which need type '__u64' which
is unavailable when compiling with -ansi. The reason the '__u64' type
is mising is that ANSI C do not define 'long long'. (Hm, is this fixed
in later versjons of ANSI C?). So the result is that is
impossible to include in a program compiled with '-ansi' on
linux/s390.
The reason this work on other archs seem to be that 'struct user' do
not depend on a 64-bit integer type on these archs.
I assume that all glibc headers should be compilable when using 'gcc
-ansi'.
It seem hard to avoid the dependency on the 64-bit value for
on s390. Could it be an idea to make sure there is a
64-bit type available using a packed struct?
#if !defined(__s390x__) && !(defined(__GNUC__) && !defined(__STRICT_ANSI__))
typedef struct {
long first_part;
long last_part;
} __u64;
#endif
This will of course break on all code _using_ variables with this
type, but might hide the problem in programs which only need a
includable to access the members available on all archs.
Bug#231972: lkh: /usr/include/linux/ptrace.h buggy
I had a look at this on raptor.debian.org (dchroot unstable). The
triggering code seem to be in in /usr/include/asm/types.h:
#ifndef __s390x__
#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
typedef __signed__ long long __s64;
typedef unsigned long long __u64;
#endif
#else /* __s390x__ */
typedef __signed__ long __s64;
typedef unsigned long __u64;
#endif
It fail to provide the type __u64 when the --ansi compile option is
used. Here is an example demonstrating the problem:
% uname -a
Linux raptor 2.4.21-debian02-1 #1 SMP Wed Jan 28 20:45:17 CET 2004
s390 GNU/Linux
% cat > sys-user-test.c
#include
int main() { return 0; }
% gcc sys-user-test.c
% gcc -ansi sys-user-test.c
In file included from /usr/include/linux/ptrace.h:49,
from /usr/include/asm/user.h:13,
from /usr/include/sys/user.h:22,
from sys-user-test.c:1:
/usr/include/asm/ptrace.h:193: error: syntax error before "__u64"
/usr/include/asm/ptrace.h:199: error: syntax error before '}' token
/usr/include/asm/ptrace.h:204: error: syntax error before "freg_t"
/usr/include/asm/ptrace.h:448: error: syntax error before "s390_fp_regs"
/usr/include/asm/ptrace.h:457: error: syntax error before '}' token
In file included from /usr/include/sys/user.h:22,
from sys-user-test.c:1:
/usr/include/asm/user.h:55: error: field `regs' has incomplete type
%
I'm not sure how to best solve the problem. Changing the includes in
might be the best solution, but I am not sure if that is
safe to do. Building kdebase without -ansi is an option too, but not
a good one. :/
Bug#231972: lkh: /usr/include/linux/ptrace.h buggy
Here is more info on the problem.
The issue is that 'struct user' in on s390 need 'struct
user_regs_struct' from , and this need type
's390_fp_regs' which need type 'freq_t' which need type '__u64' which
is unavailable when compiling with -ansi. The reason the '__u64' type
is mising is that ANSI C do not define 'long long'. (Hm, is this fixed
in later versjons of ANSI C?). So the result is that is
impossible to include in a program compiled with '-ansi' on
linux/s390.
The reason this work on other archs seem to be that 'struct user' do
not depend on a 64-bit integer type on these archs.
I assume that all glibc headers should be compilable when using 'gcc
-ansi'.
It seem hard to avoid the dependency on the 64-bit value for
on s390. Could it be an idea to make sure there is a
64-bit type available using a packed struct?
#if !defined(__s390x__) && !(defined(__GNUC__) && !defined(__STRICT_ANSI__))
typedef struct {
long first_part;
long last_part;
} __u64;
#endif
This will of course break on all code _using_ variables with this
type, but might hide the problem in programs which only need a
includable to access the members available on all archs.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#231972: lkh: /usr/include/linux/ptrace.h buggy
I had a look at this on raptor.debian.org (dchroot unstable). The
triggering code seem to be in in /usr/include/asm/types.h:
#ifndef __s390x__
#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
typedef __signed__ long long __s64;
typedef unsigned long long __u64;
#endif
#else /* __s390x__ */
typedef __signed__ long __s64;
typedef unsigned long __u64;
#endif
It fail to provide the type __u64 when the --ansi compile option is
used. Here is an example demonstrating the problem:
% uname -a
Linux raptor 2.4.21-debian02-1 #1 SMP Wed Jan 28 20:45:17 CET 2004
s390 GNU/Linux
% cat > sys-user-test.c
#include
int main() { return 0; }
% gcc sys-user-test.c
% gcc -ansi sys-user-test.c
In file included from /usr/include/linux/ptrace.h:49,
from /usr/include/asm/user.h:13,
from /usr/include/sys/user.h:22,
from sys-user-test.c:1:
/usr/include/asm/ptrace.h:193: error: syntax error before "__u64"
/usr/include/asm/ptrace.h:199: error: syntax error before '}' token
/usr/include/asm/ptrace.h:204: error: syntax error before "freg_t"
/usr/include/asm/ptrace.h:448: error: syntax error before "s390_fp_regs"
/usr/include/asm/ptrace.h:457: error: syntax error before '}' token
In file included from /usr/include/sys/user.h:22,
from sys-user-test.c:1:
/usr/include/asm/user.h:55: error: field `regs' has incomplete type
%
I'm not sure how to best solve the problem. Changing the includes in
might be the best solution, but I am not sure if that is
safe to do. Building kdebase without -ansi is an option too, but not
a good one. :/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#226047: libc6: Bad strfmon() formatting should be fixed (patch in upstream CVS)
Package: libc6
Version: 2.3.2.ds1-10
Severity: normal
The current strfmon() in glibc do not format currency correctly and in
accordence with the POSIX standard. This has been fixed in glibc CVS.
These are the relevant patches:
(libc/)
2004-01-01 Petter Reinholdtsen <[EMAIL PROTECTED]>
* stdlib/strfmon.c: Make formatting of left-justified currency
values match the POSIX standard. When using format string
"[%-14#5.4n]" to print -123.45, the result should be
"[-$ 123.4500 ]", not "[-$123.4500]".
2003-11-30 Petter Reinholdtsen <[EMAIL PROTECTED]>
* stdlib/strfmon.c: Correct formatting of international currency
values. The international currency formatting should prefer the
int_* values if they are set for a locale, and use the domestic
values if the int_* values are unset.
(libc/localedata)
2004-01-01 Petter Reinholdtsen <[EMAIL PROTECTED]>
* tst-fmon.data: Add simple test to check left justified currency
values in the C locale.
2003-11-30 Petter Reinholdtsen <[EMAIL PROTECTED]>
* tst-fmon.sh: Allow quotes around the result string, to make it
easier to see important whitespace.
* tst-fmon.data: Likewise.
* tst-fmon.sh: Clean up output, unify capitalization and output order.
* tst-fmon.c: Likewise.
* tst-fmon.data: Add test for international currency formatting.
* tst-fmon-locales/tstfmon_n01y12: Add definitions for int_* fields.
* tst-fmon-locales/tstfmon_n02n40: Likewise.
* tst-fmon-locales/tstfmon_n10y31: Likewise.
* tst-fmon-locales/tstfmon_n11y41: Likewise.
* tst-fmon-locales/tstfmon_n12y11: Likewise.
* tst-fmon-locales/tstfmon_n20n32: Likewise.
* tst-fmon-locales/tstfmon_n30y20: Likewise.
* tst-fmon-locales/tstfmon_n41n00: Likewise.
* tst-fmon-locales/tstfmon_y01y10: Likewise.
* tst-fmon-locales/tstfmon_y02n22: Likewise.
* tst-fmon-locales/tstfmon_y22n42: Likewise.
* tst-fmon-locales/tstfmon_y30y21: Likewise.
* tst-fmon-locales/tstfmon_y32n31: Likewise.
* tst-fmon-locales/tstfmon_y40y00: Likewise.
* tst-fmon-locales/tstfmon_y42n21: Likewise.
* locales/en_US: Correct spacing for international
currency formatting, now that strfmon() works better.
* locales/ja_JP: Correct currency position and
spacing now that strfmon() work better.
2003-06-15 Petter Reinholdtsen <[EMAIL PROTECTED]>
* tst-fmon.c (main): Remove unused variable 'monval'.
* tst-fmon.sh: Make sure all tests are executed before an error
code is reported to make.
* tst-numeric.sh: Likewise.
2003-04-30 Petter Reinholdtsen <[EMAIL PROTECTED]>
* tst-fmon.c: Report name of locale if setlocale() fails.
* tst-numeric.c: Likewise.
* tst-fmon.sh: Ignore lines starting with hash '#' in the data file.
* tst-numeric.sh: Likewise.
Please include these patches in the Debian version of glibc. I assume
you are able to extract the patches from CVS, but let me know if you
want me to do it and submit the patch here.
Bug#226047: libc6: Bad strfmon() formatting should be fixed (patch in upstream CVS)
Package: libc6
Version: 2.3.2.ds1-10
Severity: normal
The current strfmon() in glibc do not format currency correctly and in
accordence with the POSIX standard. This has been fixed in glibc CVS.
These are the relevant patches:
(libc/)
2004-01-01 Petter Reinholdtsen <[EMAIL PROTECTED]>
* stdlib/strfmon.c: Make formatting of left-justified currency
values match the POSIX standard. When using format string
"[%-14#5.4n]" to print -123.45, the result should be
"[-$ 123.4500 ]", not "[-$123.4500]".
2003-11-30 Petter Reinholdtsen <[EMAIL PROTECTED]>
* stdlib/strfmon.c: Correct formatting of international currency
values. The international currency formatting should prefer the
int_* values if they are set for a locale, and use the domestic
values if the int_* values are unset.
(libc/localedata)
2004-01-01 Petter Reinholdtsen <[EMAIL PROTECTED]>
* tst-fmon.data: Add simple test to check left justified currency
values in the C locale.
2003-11-30 Petter Reinholdtsen <[EMAIL PROTECTED]>
* tst-fmon.sh: Allow quotes around the result string, to make it
easier to see important whitespace.
* tst-fmon.data: Likewise.
* tst-fmon.sh: Clean up output, unify capitalization and output order.
* tst-fmon.c: Likewise.
* tst-fmon.data: Add test for international currency formatting.
* tst-fmon-locales/tstfmon_n01y12: Add definitions for int_* fields.
* tst-fmon-locales/tstfmon_n02n40: Likewise.
* tst-fmon-locales/tstfmon_n10y31: Likewise.
* tst-fmon-locales/tstfmon_n11y41: Likewise.
* tst-fmon-locales/tstfmon_n12y11: Likewise.
* tst-fmon-locales/tstfmon_n20n32: Likewise.
* tst-fmon-locales/tstfmon_n30y20: Likewise.
* tst-fmon-locales/tstfmon_n41n00: Likewise.
* tst-fmon-locales/tstfmon_y01y10: Likewise.
* tst-fmon-locales/tstfmon_y02n22: Likewise.
* tst-fmon-locales/tstfmon_y22n42: Likewise.
* tst-fmon-locales/tstfmon_y30y21: Likewise.
* tst-fmon-locales/tstfmon_y32n31: Likewise.
* tst-fmon-locales/tstfmon_y40y00: Likewise.
* tst-fmon-locales/tstfmon_y42n21: Likewise.
* locales/en_US: Correct spacing for international
currency formatting, now that strfmon() works better.
* locales/ja_JP: Correct currency position and
spacing now that strfmon() work better.
2003-06-15 Petter Reinholdtsen <[EMAIL PROTECTED]>
* tst-fmon.c (main): Remove unused variable 'monval'.
* tst-fmon.sh: Make sure all tests are executed before an error
code is reported to make.
* tst-numeric.sh: Likewise.
2003-04-30 Petter Reinholdtsen <[EMAIL PROTECTED]>
* tst-fmon.c: Report name of locale if setlocale() fails.
* tst-numeric.c: Likewise.
* tst-fmon.sh: Ignore lines starting with hash '#' in the data file.
* tst-numeric.sh: Likewise.
Please include these patches in the Debian version of glibc. I assume
you are able to extract the patches from CVS, but let me know if you
want me to do it and submit the patch here.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#218424: locales: Should list nb_NO in SUPPORTED file
This patch was commited to the glibc CVS 2003-11-04. A newer version of the glibc source should include the fix.
Bug#218424: locales: Should list nb_NO in SUPPORTED file
This patch was commited to the glibc CVS 2003-11-04. A newer version of the glibc source should include the fix. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#208238: [PATCH] Change et_EE charset to ISO-8859-15
tags 208238 + patch thanks [Indrek Hein] > Yes, Meelis Roos is absolutely correct. As soon as ISO 8859-15 > became official, Estonian locale data switched over to it. Solaris > and the BSD family have already followed the suit. You seem to have > the correct pointer to the recent standard web pages at > http://www.eki.ee/itstandard/contents.html. Don't pay attention to > the 'not official' tag, it is there to quieten my consciense. You > may order the official printed version from the Estonian Standards > Board, but it has exactly the same contents, only with a new title > page. > > The previous standard tried to mix ISO 8859-1 with home-brewn and > now obsolete methods to use s and z with caron. Both characters are > essential to Estonian, much more so than in the closest related > language, Finnish. Still, if I'm not mistaken, the demand to use > 8859-15 is now official in Finland too. > > Curiously enough, the "Baltic" set of code pages has never been > official in Estonia and now that 8859-15 is the standard, never > will. Sounds good to me. The author of the locale asked us to talk to Indrek, and Indrek verifies the change. Here is a patch to do the change. Another alternative is to add '[EMAIL PROTECTED]/ISO-8859-15 to the SUPPORTED file. I'm not sure if that is better then just changing the charset. 2004-01-01 Petter Reinholdtsen <[EMAIL PROTECTED]> * SUPPORTED: Change default charset for et_EE locale from ISO-8859-1 to ISO-8859-15, to reflect the content of http://www.eki.ee/itstandard/contents.html>. Based on input from Indrek Hein and Meelis Roos. * locales/et_EE: Likewise. Index: localedata/SUPPORTED === RCS file: /cvs/glibc/libc/localedata/SUPPORTED,v retrieving revision 1.65 diff -u -3 -p -u -r1.65 SUPPORTED --- localedata/SUPPORTED6 Dec 2003 08:11:02 - 1.65 +++ localedata/SUPPORTED1 Jan 2004 22:06:53 - @@ -87,7 +88,7 @@ es_SV/ISO-8859-1 \ es_US/ISO-8859-1 \ es_UY/ISO-8859-1 \ es_VE/ISO-8859-1 \ -et_EE/ISO-8859-1 \ +et_EE/ISO-8859-15 \ eu_ES/ISO-8859-1 \ [EMAIL PROTECTED]/ISO-8859-15 \ fa_IR/UTF-8 \ Index: localedata/locales/et_EE === RCS file: /cvs/glibc/libc/localedata/locales/et_EE,v retrieving revision 1.11 diff -u -3 -p -u -r1.11 et_EE --- localedata/locales/et_EE6 Dec 2003 07:40:37 - 1.11 +++ localedata/locales/et_EE1 Jan 2004 22:06:54 - @@ -17,7 +17,7 @@ comment_char % % Application: general % Users: general % Repertoiremap: mnemonic.ds -% Charset: ISO-8859-1 +% Charset: ISO-8859-15 % Distribution and use is free, also % for commercial purposes.
Bug#208238: [PATCH] Change et_EE charset to ISO-8859-15
tags 208238 + patch thanks [Indrek Hein] > Yes, Meelis Roos is absolutely correct. As soon as ISO 8859-15 > became official, Estonian locale data switched over to it. Solaris > and the BSD family have already followed the suit. You seem to have > the correct pointer to the recent standard web pages at > http://www.eki.ee/itstandard/contents.html. Don't pay attention to > the 'not official' tag, it is there to quieten my consciense. You > may order the official printed version from the Estonian Standards > Board, but it has exactly the same contents, only with a new title > page. > > The previous standard tried to mix ISO 8859-1 with home-brewn and > now obsolete methods to use s and z with caron. Both characters are > essential to Estonian, much more so than in the closest related > language, Finnish. Still, if I'm not mistaken, the demand to use > 8859-15 is now official in Finland too. > > Curiously enough, the "Baltic" set of code pages has never been > official in Estonia and now that 8859-15 is the standard, never > will. Sounds good to me. The author of the locale asked us to talk to Indrek, and Indrek verifies the change. Here is a patch to do the change. Another alternative is to add '[EMAIL PROTECTED]/ISO-8859-15 to the SUPPORTED file. I'm not sure if that is better then just changing the charset. 2004-01-01 Petter Reinholdtsen <[EMAIL PROTECTED]> * SUPPORTED: Change default charset for et_EE locale from ISO-8859-1 to ISO-8859-15, to reflect the content of http://www.eki.ee/itstandard/contents.html>. Based on input from Indrek Hein and Meelis Roos. * locales/et_EE: Likewise. Index: localedata/SUPPORTED === RCS file: /cvs/glibc/libc/localedata/SUPPORTED,v retrieving revision 1.65 diff -u -3 -p -u -r1.65 SUPPORTED --- localedata/SUPPORTED6 Dec 2003 08:11:02 - 1.65 +++ localedata/SUPPORTED1 Jan 2004 22:06:53 - @@ -87,7 +88,7 @@ es_SV/ISO-8859-1 \ es_US/ISO-8859-1 \ es_UY/ISO-8859-1 \ es_VE/ISO-8859-1 \ -et_EE/ISO-8859-1 \ +et_EE/ISO-8859-15 \ eu_ES/ISO-8859-1 \ [EMAIL PROTECTED]/ISO-8859-15 \ fa_IR/UTF-8 \ Index: localedata/locales/et_EE === RCS file: /cvs/glibc/libc/localedata/locales/et_EE,v retrieving revision 1.11 diff -u -3 -p -u -r1.11 et_EE --- localedata/locales/et_EE6 Dec 2003 07:40:37 - 1.11 +++ localedata/locales/et_EE1 Jan 2004 22:06:54 - @@ -17,7 +17,7 @@ comment_char % % Application: general % Users: general % Repertoiremap: mnemonic.ds -% Charset: ISO-8859-1 +% Charset: ISO-8859-15 % Distribution and use is free, also % for commercial purposes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#215466: fi_FI locale doesn't contain first_weekday
The patch for week- and workday in fi_FI was commited to upstream CVS 2003-11-26. This problem should thus be fixed in the next release of glibc.
Bug#215466: fi_FI locale doesn't contain first_weekday
The patch for week- and workday in fi_FI was commited to upstream CVS 2003-11-26. This problem should thus be fixed in the next release of glibc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#206474: locales: nb_NO should be a real locale, not an alias
The nb_NO locale was just added to the glibc CVS. This is good. :) Unfortunately, it was added by renaming the no_NO locale. Renaming the locale is the most painful way to fix this, as this will make all translations using the 'no' language code inaccessable by gettext. Because of this, I urge Debian to keep the no_NO locale around for a year or two, while the bokmål translation team track down and fix all source packages using the 'no' language code instead of the 'nb' locale code. Keeping both around make it possible to access both translations named no.po and nb.po using the environment variable LANGUAGES. I suggest that you update the patch to use the locale from the glibc CVS for nb_NO, and to keep the old no_NO locale around. The alias file need to be updated as well, to not list no_NO as an alias. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#214107: locales: en_US.UTF-8 treats [ as a space char
When I test the same using woody with locales version 2.2.5-11.5, it work as it should. minerva:~# grep en_US /etc/locale.gen en_US UTF-8 minerva:~# locale-gen Generating locales... [...] en_US.UTF-8... done [...] Generation complete. minerva:~# echo '[' | LANG=en_US.UTF-8 egrep '^[^[:space:]]+$' [ minerva:~# echo '[' | LANG=en_US egrep '^[^[:space:]]+$' [ minerva:~# echo '[' | LANG=C egrep '^[^[:space:]]+$' [ minerva:~# Comparing the en_US locale, there are no changes. But both include the i18n "locale", and this changed between the versions. It was updated to use Unicode version 3.2 form version 3.0 I do not know the CTYPE part of the locale well enough to say if the changes are relevant or not. I found nothing in the change modifying the behaviour of , which I believe is the value for '['. Could it be some regex error in glibc? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#218424: locales: Should list nb_NO in SUPPORTED file
Package: locales Version: 2.3.2-9 Severity: minor Tags: patch I forgot a minor thing in my patch to add nb_NO as a real locale. It should also be listed in the SUPPORTED file, to make it possible to select it at install time. Here is a patch to fix it. --- SUPPORTED.orig 2003-10-31 08:47:26.0 + +++ SUPPORTED 2003-10-31 08:47:37.0 + @@ -126,6 +126,7 @@ mr_IN.UTF-8 UTF-8 ms_MY ISO-8859-1 mt_MT ISO-8859-3 +nb_NO ISO-8859-1 nl_BE ISO-8859-1 [EMAIL PROTECTED] ISO-8859-15 nl_NL ISO-8859-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#211607: Bad catalan locale currency format
This bug is fixed in upstream CVS. This is the changelog entry from libc/localedata/: 2003-09-21 Jordi Mallach <[EMAIL PROTECTED]> * locales/ca_ES: Fix mon_grouping, int_frac_digits and frac_digits values. * locales/eu_ES: Fix int_frac_digits and frac_digits values. * locales/gl_ES: Likewise. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#26306: routines checking hosts.equiv do not check netgroups
[Harry Edmon]
> It interprets it as a host name (see the code for __ivaliduser).
I checked the current glibc source for this function, and was able to
locate it in inet/rcmd.c:
/*
* XXX
* Don't make static, used by lpd(8).
*
* This function is not used anymore. It is only present because lpd(8)
* calls it (!?!). We simply call __invaliduser2() with an illegal rhost
* argument. This means that netgroups won't work in .rhost/hosts.equiv
* files. If you want lpd to work with netgroups, fix lpd to use ruserok()
* or PAM.
* Returns 0 if ok, -1 if not ok.
*/
int
__ivaliduser(hostf, raddr, luser, ruser)
FILE *hostf;
u_int32_t raddr;
const char *luser, *ruser;
{
struct sockaddr_in ra;
memset(&ra, '\0', sizeof(ra));
ra.sin_family = AF_INET;
ra.sin_addr.s_addr = raddr;
return __validuser2_sa(hostf, (struct sockaddr *)&ra, sizeof(ra),
luser, ruser, "-");
}
Perhaps the failing application should be changed?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#206531: Problems building d-i after upgrading Sid chroot
Package: libc6-pic Version: 2.3.2-3 Severity: serious After upgrading my Sid chroot, the cdrom floppy built by d-i is unable to boot properly. These are the last messages printed when booting the floppy: RAMDISK: Compressed image found at block 0 Freeing initrd memory: 1441k freed VFS: Mounted root (ext2 filesystem). Mounted devsf on /dev VFS: Mounted root (ext2 filesystem). Trying to move old root to /initrd .. failed Unmounting old root Trying to free ramdisk memory ... failed Mounted devfs on /dev Freeing unused kernel memory: 72k freed I upgraded these packages: The following NEW packages will be installed: libbz2-1.0 python2.3 The following packages will be upgraded apt apt-utils base-files binutils build-essential console-common console-data console-tools coreutils cpp cpp-3.3 debconf debconf-i18n debconf-utils debhelper devscripts discover-data e2fslibs e2fsprogs file fileutils g++ g++-3.3 gcc gcc-3.3 gcc-3.3-base libblkid1 libc6 libc6-dev libc6-pic libcomerr2 libconsole libcurl2 libdb4.1 libdebconfclient0 libdebconfclient0-dev libgcc1 libmagic1 libsasl2 libss2 libstdc++5 libstdc++5-3.3-dev libuuid1 locales man-db modutils nano netbase passwd perl perl-base perl-modules python python2.2 shellutils tasksel textutils We suspect the upgraded libc provoked the problem. That is why I report it against libc6-pic. More info will be provided when we know more. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#206474: locales: nb_NO should be a real locale, not an alias
Package: locales Version: 2.3.2-3 Severity: wishlist Tags: patch The locale for Norwegian Bokmål should be nb_NO, and translation files and programs should use this instead of the old and inaccurate no_NO. A patch to fix this is available from http://sources.redhat.com/ml/libc-alpha/2003-06/msg00133.html >. This bug is reported to glibc as libc/2981 and RedHat at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83276>. More info on the topic is available from http://i18n.skolelinux.no/localekoder.txt>. (Currently Norwegian only). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#194289: please add support for Aragonese
A locale for Aragonese was added as an_ES to the glibc CVS 2003-06-16. It will be included in the next release of glibc.
Bug#194289: please add support for Aragonese
A locale for Aragonese was added as an_ES to the glibc CVS 2003-06-16. It will be included in the next release of glibc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#37012: gconv-modules: iconv fails if it cannot map between charsets
[Jeff Bailey] > Please provide a testcase to show that this bug still occurs. The problem still exists: The letter ø (Octal 370) is not a valid UTF-8 sequence: % echo -e 'hei \370 foo' | /usr/bin/iconv -f utf-8 -t iso-8859-1//TRANSLIT hei /usr/bin/iconv: illegal input sequence at position 4 % As you can see, iconv stops after printing 'hei ', and never prints ' foo'. And the //TRANSLIT options is not mentioned when I use 'iconv --help', and the manual page is just as silent about the posibility.
Bug#115536: shellutils: date display for de_DE is wrong
The abday values for de_DE is changed in the latest CVS version of glibc. CVS was changed 2003-05-06, and the corrected version should be included in the next glibc version.
Bug#188589: locale de_CH: unknown character in field `d_t_fmt'
The bug is present in Woody, glibc 2.2.5-11.2, and is fixed in Sid, glibc 2.3.1-16. I'm not sure which version was the first fixed version.
Bug#160040: locales: sr_YU.ISO-8859-2...LC_MONETARY error
The locales ar_SD and sr_YU (and es_EC and [EMAIL PROTECTED]) are now fixed in the GNU libc CVS. This bug should be fixed in the next release of glibc (the one after v2.3.3). This is the changelog entries from localedata/ChangeLog: 2003-04-15 Petter Reinholdtsen <[EMAIL PROTECTED]> * locales/ar_SD [LC_MONETARY]: Use international currency symbol 'SDD' for Sudan. * locales/es_EC [LC_MONETARY]: Use international currency symbol 'USD' for Ecuador. Source is CIA World Fact book. 2003-04-05 Petter Reinholdtsen <[EMAIL PROTECTED]> * locales/sr_YU [LC_MONETARY]: Change int_curr_symbol from 'YUN' to 'YUM' to match changes commited to ISO-4217 2002-02-13 and get the locale building again. * locales/[EMAIL PROTECTED]: Likewise.
Bug#139879: nscd reverse-lookup exploit (bug 120059 revisited)
The glibc developer Ulrich Drepper claims that this security problem is fixed in later versions of glibc. See http://sources.redhat.com/ml/libc-alpha/2003-04/msg00124.html>. I'm not sure in which version this was fixed.
Bug#180763: libc6: NSS compat setting should support non-NIS directory
Package: libc6 Version: 2.2.5-11.2 Severity: wishlist On solaris, it is possible to use the 'compat' mode in NSS with LDAP directories. Now that the libnss-ldap package start to support netgroups, the compat module should support using netgroups and user info from LDAP. See http://www.sunmanagers.org/pipermail/summaries/2002-January/002093.html> for an exampple on how this is done no Solaris. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#166979: Locales simply wont work
It is safer to test using 'date', as this do not require external translation files. # locale-gen Generating locales... en_US.ISO-8859-1... done en_US.UTF-8... done es_ES.ISO-8859-1... done [EMAIL PROTECTED] done Generation complete. # date; LC_ALL=en_US date; LC_ALL=es_ES date Fri Nov 15 17:16:43 CET 2002 Fri Nov 15 17:16:43 CET 2002 vie nov 15 17:16:43 CET 2002 This is using Debian/Woody, glibc 2.2.5-11.2. But rm works just fine for me: % rm; LC_ALL=en_US rm; LC_ALL=es_ES rm rm: too few arguments Try `rm --help' for more information. rm: too few arguments Try `rm --help' for more information. rm: número de argumentos insuficiente Pruebe `rm --help' para más información.
Bug#86761: locale.alias refers to non-generated locales
The problem with 'locale -a' listing nonexisting locales was fixed in upstream CVS 2002-08-26. It made into release 2.3.1.
Bug#151631: en_CA: LC_IDENTIFICATION: unknown character in field `address'
[David B Harris] > Hey ho :) Following log should cover it, I think: > Setting up locales (2.2.5-7) ... > Generating locales... > en_CA.ISO8859-1.../usr/share/i18n/locales/en_CA:27: > LC_IDENTIFICATION: unknown character in field `address' > done > Generation complete. It works if I use 'en_CA ISO-8869-1' instead of en_CA ISO8859-1' in /etc/locale.gen. Where did you get the charset name ISO8859-1 from? It is not listed in /usr/share/i18n/charmaps/.
Bug#166979: Locales simply wont work
It is safer to test using 'date', as this do not require external translation files. # locale-gen Generating locales... en_US.ISO-8859-1... done en_US.UTF-8... done es_ES.ISO-8859-1... done [EMAIL PROTECTED] done Generation complete. # date; LC_ALL=en_US date; LC_ALL=es_ES date Fri Nov 15 17:16:43 CET 2002 Fri Nov 15 17:16:43 CET 2002 vie nov 15 17:16:43 CET 2002 This is using Debian/Woody, glibc 2.2.5-11.2. But rm works just fine for me: % rm; LC_ALL=en_US rm; LC_ALL=es_ES rm rm: too few arguments Try `rm --help' for more information. rm: too few arguments Try `rm --help' for more information. rm: número de argumentos insuficiente Pruebe `rm --help' para más información. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#86761: locale.alias refers to non-generated locales
The problem with 'locale -a' listing nonexisting locales was fixed in upstream CVS 2002-08-26. It made into release 2.3.1. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#151631: en_CA: LC_IDENTIFICATION: unknown character in field `address'
[David B Harris] > Hey ho :) Following log should cover it, I think: > Setting up locales (2.2.5-7) ... > Generating locales... > en_CA.ISO8859-1.../usr/share/i18n/locales/en_CA:27: > LC_IDENTIFICATION: unknown character in field `address' > done > Generation complete. It works if I use 'en_CA ISO-8869-1' instead of en_CA ISO8859-1' in /etc/locale.gen. Where did you get the charset name ISO8859-1 from? It is not listed in /usr/share/i18n/charmaps/. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#168345: locales: impossible to configure noninteractive on first time install
Package: locales
Version: 2.2.5-14
At the moment it is impossible to preconfigure fthe locales package
for the first time install.
I would like to supply a debconf value in the
locales/locales_to_be_generated variable, and get the locales package
to create /etc/locale.gen based on the content of this debconf answer.
This fail, because locales.config will reset the value to '' before
asking debconf for the answer. The following patch fixes the
situation for the first time install, while still using the content of
/etc/locale.gen if it exists.
Please fix this in Woody too. The Skolelinux distribution needs it.
--- locales.config.orig Fri Nov 8 20:25:40 2002
+++ locales.config Fri Nov 8 20:26:09 2002
@@ -175,6 +175,7 @@
if test -f /etc/locale.gen; then
LG=/etc/locale.gen
SELECTED_LOCALES=$(egrep -v "^#|^$" $LG | tr "\n" "," | sed -e "s/,/, /g" -e
"s/, *$//")
+ db_set locales/locales_to_be_generated "${SELECTED_LOCALES}"
else
LG=/dev/null
fi
@@ -184,7 +185,6 @@
. /usr/share/debconf/confmodule
db_version 2.0
-db_set locales/locales_to_be_generated "${SELECTED_LOCALES}"
db_subst locales/locales_to_be_generated locales "${SUPPORTED_LOCALES}"
db_capb multiselect
db_input medium locales/locales_to_be_generated || true
Bug#168345: locales: impossible to configure noninteractive on first time install
Package: locales
Version: 2.2.5-14
At the moment it is impossible to preconfigure fthe locales package
for the first time install.
I would like to supply a debconf value in the
locales/locales_to_be_generated variable, and get the locales package
to create /etc/locale.gen based on the content of this debconf answer.
This fail, because locales.config will reset the value to '' before
asking debconf for the answer. The following patch fixes the
situation for the first time install, while still using the content of
/etc/locale.gen if it exists.
Please fix this in Woody too. The Skolelinux distribution needs it.
--- locales.config.orig Fri Nov 8 20:25:40 2002
+++ locales.config Fri Nov 8 20:26:09 2002
@@ -175,6 +175,7 @@
if test -f /etc/locale.gen; then
LG=/etc/locale.gen
SELECTED_LOCALES=$(egrep -v "^#|^$" $LG | tr "\n" "," | sed -e "s/,/, /g" -e
"s/, *$//")
+ db_set locales/locales_to_be_generated "${SELECTED_LOCALES}"
else
LG=/dev/null
fi
@@ -184,7 +185,6 @@
. /usr/share/debconf/confmodule
db_version 2.0
-db_set locales/locales_to_be_generated "${SELECTED_LOCALES}"
db_subst locales/locales_to_be_generated locales "${SUPPORTED_LOCALES}"
db_capb multiselect
db_input medium locales/locales_to_be_generated || true
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
