Bug#620134: locales/locales_to_be_generated is not read when reconfiguring locales
Package: locales Version: 2.11.2-10 Severity: normal hi when i want to reconfigure locales by setting locales_to_be_generated with debconf-set-selections, the new value is never read because locales.config rewrites locales_to_be_generated to languages selected in /etc/locale.gen. so using debconf is unuseful. -- System Information: Debian Release: 6.0 APT prefers squeeze-updates APT policy: (500, 'squeeze-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii libc6 [glibc-2.11-1] 2.11.2-10 Embedded GNU C Library: Shared lib locales recommends no packages. locales suggests no packages. -- debconf information excluded -- 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/20110330131519.28779.94891.report...@gatelse008.gate.cnrs.fr
Bug#620203: [alpha] libc-bin / libc6.1: LEVEL*CACHE* inproperly mixed
Package: libc6.1 Version: 2.11.2-13 Severity: normal I tested both 2.7-18lenny7 and 2.11.2-13 on other machine, result is the same: $ getconf -a | grep LEVEL LEVEL1_ICACHE_SIZE 64 LEVEL1_ICACHE_ASSOC65536 LEVEL1_ICACHE_LINESIZE 2 LEVEL1_DCACHE_SIZE 64 LEVEL1_DCACHE_ASSOC65536 LEVEL1_DCACHE_LINESIZE 2 LEVEL2_CACHE_SIZE 64 LEVEL2_CACHE_ASSOC 4194304 LEVEL2_CACHE_LINESIZE 1 LEVEL3_CACHE_SIZE LEVEL3_CACHE_ASSOC LEVEL3_CACHE_LINESIZE LEVEL4_CACHE_SIZE LEVEL4_CACHE_ASSOC LEVEL4_CACHE_LINESIZE $ $ cat /proc/cpuinfo cpu : Alpha cpu model : EV6 cpu variation : 7 cpu revision: 0 cpu serial number : system type : Tsunami system variation: Monet system revision : 0 system serial number: AY0 cycle frequency [Hz]: 5 timer frequency [Hz]: 1024.00 page size [bytes] : 8192 phys. address bits : 44 max. addr. space # : 255 BogoMIPS: 994.44 kernel unaligned acc: 24 (pc=fc00010e0748,va=fc00192ca1ea) user unaligned acc : 0 (pc=0,va=0) platform string : COMPAQ Professional Workstation XP1000 cpus detected : 1 L1 Icache : 64K, 2-way, 64b line L1 Dcache : 64K, 2-way, 64b line L2 cache: 4096K, 1-way, 64b line L3 cache: n/a $ As you can see LEVEL2_CACHE_SIZE 64 LEVEL2_CACHE_ASSOC 4194304 LEVEL2_CACHE_LINESIZE 1 should be actually LEVEL2_CACHE_SIZE 4194304 LEVEL2_CACHE_ASSOC 1 LEVEL2_CACHE_LINESIZE 64 for example Both machines are identical. one have lenny installed, one is partially using unstable (for example libc* packages). Both machines runs 2.6.26: Linux a02 2.6.26-2-alpha-generic #1 Thu Jan 27 05:54:49 UTC 2011 alpha GNU/Linux Regards, Witek -- debconf information: glibc/upgrade: true glibc/restart-failed: glibc/restart-services: -- 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/20110331004217.9681.94849.report...@a09.smp.if.uj.edu.pl
Bug#200641: zdump -v on alpha (and other 64-bit archs), and gmtime
Hello all. This message is about bug #412569, but informations are also relevant to issue #200641. I looked deeper into zdump and gmtime issues. And I think there is no error in libc's gmtime or zdump. $ zdump -v /usr/share/zoneinfo/UTC /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL /etc/localtime 9223372036854689407 = NULL /etc/localtime 9223372036854775807 = NULL $ In my opinion it is actually correct output. Documentation of zdump needs to be updated to fully reflect this strange (but correct) behaviour. Why? -9223372036854775808 is smallest possible time_t value on alpha (-2**63), as time_t on alpha is signed long int (64 bits). Next one is one day later. Similary 9223372036854775807 is biggest possible time_t. This corectly follows documentation of zdump -v option. Why such strange output? Because -9223372036854775808, is more than 2*31 years before 1970. And a tm_year field of struct tm, have type int, which on alpha have 32-bits. So oldest year is -2**31 = -2147483648, and in conlusion oldest possible date/time is 01 Jan 00:00:00 -2147483648 UTC, with value of ``seconds after epoch'' equal -67768040609740800 (somwhere beetwen -2**56 and -2**55). This minus one, already cannot be represented in broken-down time format in struct tm. Similary for maxium date. Cearfully inspecting source code, and adding some debuging to zdump, shows also that gmtime properly sets errno to EOVERFLOW, indicateing it cannot convert data to broken-down format. I suppose gmtime_r will behave in exactly same way. This issues will not happen on architectures with sizeof(int) = 8, as tm_year will be big enugh to fit year -300498215812. (slightly more 2**38 years before 1970). So, also #200641 is not a bug. gmtime is behaving properly, because int is 32-bits, even on 64-bit architectures in our cases (not tested on amd64 just now, but AFAIR, int is still 32-bit also there). I checked POSIX standards and it looks that, current behaviour do not violatate this standards. I also think this is same behaviour as under Solaris. Other solution is to have hardcoded string 01 Jan 00:00:00 -2147483648, or display -67768040609740800 as smallest one (it isn't actually smallest, but smalles which can be printed using gmtime). So in both cases zdump documentation will need to be updated. I personally think we should just document current behaviour. PS. Original bug reports of #412569, do not apply anymore. --version option is working. It still loops, but on any 64-bit computer I tested, it exit after about 3 to 9 seconds. And it do not crash anymore in any case. Regards, Witek -- Witold Baryluk JID: witold.baryluk // jabster.pl signature.asc Description: Digital signature
Bug#238786: Not a libc bug
unmerge 238786 reassign 238786 cyrus-imapd-2.4 retitle 238786 cyrus21-imapd: APPEND fails with Invalid date-time, on 64-bit architectures. thanks Previous 'gmtime returns NULL for time_ts larger than 40 bits on Alpha' title was wrong. First it returns NULL only for larger than about 2**58. Second it is not bug, returning NULL is not a bug, it is just error condition conforming to POSIX standards. See my posts to bug #200641. Thus reasigning back to cyrus-imapd Thanks -- Witold Baryluk -- 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/20110331043401.ga20...@smp.if.uj.edu.pl
