Processed: reassign 341675 to cppunit, reassign 342545 to 4.0.2-5, reassign 2 to 4.0.2-5
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.10 # whoops, reassign the right one reassign 341675 cppunit 1.10.2-5 Bug#341675: cppunit: FTBFS on hppa Bug reassigned from package `libgcc2' to `cppunit'. reassign 342545 4.0.2-5 Bug#342545: qt-x11-free build fails Warning: Unknown package '4.0.2-5' Bug reassigned from package `libc6' to `4.0.2-5'. reassign 2 4.0.2-5 Bug number 2 not found. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Flawless Sildenafil/Tadalafil Support ta
We are your One Stop Shop for Astronomical ST-\/[EMAIL PROTECTED] Savings http://uk.geocities.com/GraceMcbride4281/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343853: Bug in glibc: setrlimit
On Mon, Dec 19, 2005 at 01:54:52AM -0500, Gene Cooperman wrote: Perhaps my description was not clear enough, but this would be a very strange feature. When setrlimit() is called in the original process as specified, then after that, pthread_create() continues to succeed in the original process. _However_, if the original process creates a child process, and if the child process calls pthread_create(), then pthread_create() will fail with a non-zero error code. Yes, that was what I meant by this happens during program initialization: glibc calls getrlimit() before main() to set the default stack size, which then does not change for the life of the program. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343853: Bug in glibc: setrlimit
Please use group reply, so that you do not drop the bug tracking system from CC. On Mon, Dec 19, 2005 at 10:28:23AM -0500, Gene Cooperman wrote: I'd like to repeat this in my own words, to see if I understand your point. You seem to be saying that: A. The parent process begins with the user's default stack size B. The parent calls setrlimit to change the limit on the stack size. However, this does not change the actual stack size of the process. It only affects how big it can grow. C. The parent calls pthread_create(), which receives a copy of the current stack size. D. The child is created, and its stack size is set to the soft limit of the parent's stack size, and not to the parent's current stack size. E. When the child calls pthread_create(), it tries to create a second stack of that size, and fails. 'The user's default stack size' doesn't mean anything. There are two stack sizes: those used by the kernel when creating a new process, and those used by the thread manager when creating a new thread. The thread manager initializes its default stack size, based on the rlimits, when the process is first created. This is used for pthread_create if the application doesn't specify its own stack size. If the above is correct, then here is what doesn't make sense to me: 1. If we execute with the debugging version of glibc: LD_LIBRARY_PATH=/usr/lib/debug ./a.out then step D above is different: the child is apparently created with some stack size that is strictly smaller than the soft limit of the parent's stack size. One of these glibcs is NPTL, the other (in /usr/lib/debug) LinuxThreads. They behave slightly differently. They implement roughly the same thing, but the details do vary. I vaguely recall that one of them caps at an arbitrary limit and the other does not. 2. If the parent's hard limit is not RLIM_INFINITY, but something slightly smaller, then step D above is different: the child is apprently created with some stack size that is strictly smaller than either the soft limit or the hard limit of the parent's stack size. Why should the child have its stack initialized the soft limit of the parent _only_ if the parent has a hard limit less than RLIM_INFINITY, and _only_ if we don't use the libc.so library with debugging symbols retained? If steps A through E are a feature, then shouldn't the feature continue to work _even_ if we are using a debugger and debugging libraries? Also what is the motivation for enabling this feature only when the hard limit is RLIM_INFINITY? I understand that RLIM_INFINITY implies that the O/S may turn off error checking, but why does that imply that the O/S should turn on this feature? Glibc doesn't care about the hard limit. It never checks it. Your observations must be reflecting something different. I suggest you take a glibc source tree and look for the places where NPTL and LinuxThreads consult the stack rlimit, if you need to understand what is happening any more precisely than I've explained it. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
At Thu, 15 Dec 2005 17:13:25 -0800, Edward Buck wrote: I guess the problem then is in the ipv6 support and how it implements domains in the search path. Instead of doing ipv6, then ipv4 for mx1.hotmail.com, it runs through all possible ipv6 queries, including exhausting all domains in the search path, before ipv4 queries are attempted. That seems (is) really inefficient. As a result of ipv6 supports, DNS queries have tripled on systems with two domains in their search path. Okay, perhaps this isn't a bug. It's just ipv6 hell. Okay, I close it. If you think there's bugs in libc, please tell me about it. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
At Thu, 15 Dec 2005 17:13:25 -0800, Edward Buck wrote: I guess the problem then is in the ipv6 support and how it implements domains in the search path. Instead of doing ipv6, then ipv4 for mx1.hotmail.com, it runs through all possible ipv6 queries, including exhausting all domains in the search path, before ipv4 queries are attempted. That seems (is) really inefficient. As a result of ipv6 supports, DNS queries have tripled on systems with two domains in their search path. Okay, perhaps this isn't a bug. It's just ipv6 hell. I guess the answer to this problem for you is to just disable ipv6 (unless you need it) - blacklisting the kernel module(s) ought to do it, although there may be some other parts I am unaware of. HTH, and take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#149902: Australian time zones
At Fri, 9 Dec 2005 16:43:48 +1100, [EMAIL PROTECTED] wrote: The official list of timezones for Australia, as provided by the Australian Government, does not include EST anywhere on the page. AEST is the correct abbreviation. quote url=http://www.australia.gov.au/about-australia-13time; There are three times zones in Australia - * Australian Eastern Standard Time (AEST): Greenwich Mean Time (GMT) plus 10 hours for standard time and 11 hours for daylight savings time. AEST is followed in these regions: o New South Wales o Victoria o Queensland o Tasmania o Australian Capital Territory * Australian Central Standard Time (ACST): GMT plus 9 ½ hours for standard time and 10 ½ hours for daylight savings time. ACST is followed in these regions: o South Australia o Northern Territory * Australian Western Standard Time (AWST): GMT plus 8 hours. AWST is followed in these regions: o Western Australia /quote This should be re-opened as a bug. Timeanddate.com do not have the most correct timezone information on their website, the Australian Government do. Note that you probably want to know why AEST vs EST is long-standing problem: the short summary is available in glibc source tree timezone/australasia. Not only one governmental page but also showing another information source would be nice idea to change time zone maintainers. -- gotom
Bug#340147: /etc/init.d/glibc.sh must use ': exit 0' instead of 'exit 0'
At Mon, 21 Nov 2005 10:42:14 +0100, Petter Reinholdtsen wrote: 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. I've modified it as your request. -- gotom
r1067 - in glibc-package/trunk/debian: . local/etc_init.d
Author: gotom Date: 2005-12-20 01:07:01 + (Tue, 20 Dec 2005) New Revision: 1067 Modified: glibc-package/trunk/debian/changelog glibc-package/trunk/debian/local/etc_init.d/glibc.sh Log: * debian/local/etc_init.d/glibc.sh: Change the last 'exit 0' to ': exit 0' to not block sourcing. (Closes: #340147) Modified: glibc-package/trunk/debian/changelog === --- glibc-package/trunk/debian/changelog2005-12-17 15:44:47 UTC (rev 1066) +++ glibc-package/trunk/debian/changelog2005-12-20 01:07:01 UTC (rev 1067) @@ -1,3 +1,11 @@ +glibc (2.3.5-10) unstable; urgency=low + + [ GOTO Masanori ] + * debian/local/etc_init.d/glibc.sh: Change the last 'exit 0' to +': exit 0' to not block sourcing. (Closes: #340147) + + -- GOTO Masanori [EMAIL PROTECTED] Tue, 20 Dec 2005 09:51:34 +0900 + glibc (2.3.5-9) unstable; urgency=low [ Daniel Jacobowitz ] @@ -115,7 +123,7 @@ * debian/sysdeps/powerpc.mk: Enable PowerPC NPTL. (Closes: #246689, #307984) -* debian/FAQ: Add the description about dropping __ctype_* symbol support +* debian/README: Add the description about dropping __ctype_* symbol support of static linked application/libraries in etch. (Closes: #324526) * debian/sysdeps/linux.mk: Check SETNJOBS environment variable to specify Modified: glibc-package/trunk/debian/local/etc_init.d/glibc.sh === --- glibc-package/trunk/debian/local/etc_init.d/glibc.sh2005-12-17 15:44:47 UTC (rev 1066) +++ glibc-package/trunk/debian/local/etc_init.d/glibc.sh2005-12-20 01:07:01 UTC (rev 1067) @@ -15,4 +15,4 @@ # glibc kernel version check: KERNEL_VERSION_CHECK fi -exit 0 +: exit 0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339110: [INTL:pt] Portuguese translation for glibc (Debconf)
At Mon, 14 Nov 2005 23:26:04 +, Rui Branco wrote: Portuguese translation for glibc's debconf messages by Simão Pedro Cardoso [EMAIL PROTECTED] Feel free to use it. For translation updates please contact last translator and/or CC the Portuguese translation team traduz _at_ debianpt.org Thanks for your work, but I have a question: there's already pt_BR.po in libc6 files. Is your pt.po different from pt_BR.po? Or is it just updates from pt_BR.po (so your file should be renamed from pt.po to pt_BR.po)? -- gotom
Bug#339318: marked as done (Bug in fesetenv() [LIBC6.1])
Your message dated Tue, 20 Dec 2005 10:30:13 +0900 with message-id [EMAIL PROTECTED] and subject line Bug#339318: Bug in fesetenv() [LIBC6.1] has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 15 Nov 2005 13:50:55 + From [EMAIL PROTECTED] Tue Nov 15 05:50:55 2005 Return-path: [EMAIL PROTECTED] Received: from post.rzg.mpg.de ([130.183.7.21]) by spohr.debian.org with esmtp (Exim 4.50) id 1Ec1D4-To-US for [EMAIL PROTECTED]; Tue, 15 Nov 2005 05:50:55 -0800 Received: from mpq3p32.mpq.mpg.de (mpq3p32.mpq.mpg.de [130.183.93.32]) by post.rzg.mpg.de (8.9.2/8.9.2) with ESMTP id OAA3010604 for [EMAIL PROTECTED]; Tue, 15 Nov 2005 14:50:51 +0100 X-Envelope-To: [EMAIL PROTECTED] Subject: Bug in fesetenv() [LIBC6.1] From: Juan Jose Garcia Ripoll [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain Date: Tue, 15 Nov 2005 14:49:57 +0100 Message-Id: [EMAIL PROTECTED] Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 Package:libc6.1 Version:2.2.5-11.5 Summary:Under some circumstances, invoking fesetenv() results in a floating point exception being raised. Description: I have a piece of code which may result in underflows. I enclose the code in between fenv_t env; feholdexcept(env); ... fesetenv(env); Now the code in [...] is reading floating point numbers which may be very small and result in underflow floating point signals. However, since we have used feholdexcept() the signals should not be produced. And indeed they are not, until we reach fesetenv() where the signal is raised. If you read the manual of LIBC for fesetenv() The fesetenv function restores the floating point environ- ment from the object *envp. This object must be known to be valid, e.g., the result of a call to fegetenv or feholdexcept or equal to FE_DFL_ENV. This call does not raise exceptions. it says no exception should be raised. --- Received: (at 339318-done) by bugs.debian.org; 20 Dec 2005 01:30:14 + From [EMAIL PROTECTED] Mon Dec 19 17:30:14 2005 Return-path: [EMAIL PROTECTED] Received: from omega.webmasters.gr.jp ([218.44.239.78] helo=webmasters.gr.jp) by spohr.debian.org with esmtp (Exim 4.50) id 1EoWKU-gW-Mp for [EMAIL PROTECTED]; Mon, 19 Dec 2005 17:30:14 -0800 Received: from omega.webmasters.gr.jp (localhost [127.0.0.1]) by webmasters.gr.jp (Postfix) with ESMTP id EF47DDEB1B; Tue, 20 Dec 2005 10:30:13 +0900 (JST) Date: Tue, 20 Dec 2005 10:30:13 +0900 Message-ID: [EMAIL PROTECTED] From: GOTO Masanori [EMAIL PROTECTED] To: Juan Jose Garcia Ripoll [EMAIL PROTECTED], Daniel Jacobowitz [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Bug#339318: Bug in fesetenv() [LIBC6.1] In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] User-Agent: Wanderlust/2.11.30 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - Maruoka) Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 At Sun, 20 Nov 2005 12:08:45 -0500, Daniel Jacobowitz wrote: On Tue, Nov 15, 2005 at 02:49:57PM +0100, Juan Jose Garcia Ripoll wrote: Package:libc6.1 Version:2.2.5-11.5 That's a very old glibc version. It's likely that we can't help you with it. However, could you post a standalone testcase? Then we can at least check whether it is fixed in later versions. I close this bug because there's no responce from the submitter. Juan, if you still see your bugs in the recent glibc version (ex: sarge or sid), please reopen this bug or just report it to us. It seems you run on ia64 or alpha - so it probably the actual bug, but we need to
Bug#339827: linuxthreads crashes when using user stacks
At Sun, 20 Nov 2005 14:22:22 -0500, Daniel Jacobowitz wrote: Steve Langasek agreed. I am planning to bump the requirement up from 2.2.whatever to 2.4.0 for i486 and powerpc; i486 in order to enable floating stacks, and powerpc because we've been getting bug reports that indicate that static binaries are already broken there under 2.2, and no one wants to debug it. Any objections before I do this? Is it already done? If it's pended, I'll ask it to [EMAIL PROTECTED] The security support for 2.2 series was finished, we have no reason to support 2.2 kernel. Note that the current status of the support kernel versions are: amd64 2.6.0 i386(i686) 2.6.0 i386(amd64) 2.6.0 *(nptl) 2.6.0 ppc64 2.6.0 s390x 2.4.1 sparc64 2.4.18 sparcv9 2.4.18 sparcv9b2.4.18 others 2.2.0 They'll be changed to: i386(i486) 2.4.1 powerpc 2.4.1 (?) BTW, note that some architectures like m68k could not compile the recent glibc with kernel 2.4.x or 2.6.x. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344105: libc6: [powerpc] _dl_map_object_from_fd removes data segment execute permission
Package: libc6
Version: 2.3.5-9
Severity: normal
Tags: patch
When using a kernel with a 64kB page size we noticed a glibc issue where
execute permission can be removed from the GOT. Since the GOT needs to be
executable we then die (it uses a trick with a blrl instruction in
order to find the GOT address).
Details of this bug can be found at:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1346
The upstream fix, rediffed and tested against 2.3.5-9 is below.
2005-09-20 Roland McGrath [EMAIL PROTECTED]
[BZ #1346]
* elf/dl-load.c (_dl_map_object_from_fd) [HAVE_Z_RELRO]: Do relro
magic on __stack_prot only if [SHARED]. Skip mprotect if __stack_prot
lies outside the page-rounded-down relro region.
--- elf/dl-load.c~ 2005-12-14 22:27:00.0 -0600
+++ elf/dl-load.c 2005-12-14 22:35:59.0 -0600
@@ -1314,22 +1314,36 @@
if (__builtin_expect ((stack_flags ~ GL(dl_stack_flags)) PF_X, 0))
{
+ if (__builtin_expect (__check_caller (RETURN_ADDRESS (0), allow_ldso),
+ 0) != 0)
+ {
+ errstring = N_(invalid caller);
+ goto call_lose;
+ }
+
/* The stack is presently not executable, but this module
requires that it be executable. We must change the
protection of the variable which contains the flags used in
the mprotect calls. */
-#ifdef HAVE_Z_RELRO
+#if defined HAVE_Z_RELRO defined SHARED
if (mode __RTLD_DLOPEN)
{
- uintptr_t p = ((uintptr_t) __stack_prot) ~(GLRO(dl_pagesize) - 1);
- size_t s = (uintptr_t) __stack_prot - p + sizeof (int);
+ const uintptr_t p = (uintptr_t) __stack_prot -GLRO(dl_pagesize);
+ const size_t s = (uintptr_t) (__stack_prot + 1) - p;
- __mprotect ((void *) p, s, PROT_READ|PROT_WRITE);
- if (__builtin_expect (__check_caller (RETURN_ADDRESS (0),
- allow_ldso|allow_libc) == 0,
- 0))
+ struct link_map *const m = GL(dl_rtld_map);
+ const uintptr_t relro_end = ((m-l_addr + m-l_relro_addr
+ + m-l_relro_size)
+ -GLRO(dl_pagesize));
+ if (__builtin_expect (p + s = relro_end, 1))
+ {
+ /* The variable lies in the region protected by RELRO. */
+ __mprotect ((void *) p, s, PROT_READ|PROT_WRITE);
+ __stack_prot |= PROT_READ|PROT_WRITE|PROT_EXEC;
+ __mprotect ((void *) p, s, PROT_READ);
+ }
+ else
__stack_prot |= PROT_READ|PROT_WRITE|PROT_EXEC;
- __mprotect ((void *) p, s, PROT_READ);
}
else
#endif
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-rc6-gdf7addbb
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339827: linuxthreads crashes when using user stacks
On Tue, Dec 20, 2005 at 10:38:47AM +0900, GOTO Masanori wrote: At Sun, 20 Nov 2005 14:22:22 -0500, Daniel Jacobowitz wrote: Steve Langasek agreed. I am planning to bump the requirement up from 2.2.whatever to 2.4.0 for i486 and powerpc; i486 in order to enable floating stacks, and powerpc because we've been getting bug reports that indicate that static binaries are already broken there under 2.2, and no one wants to debug it. Any objections before I do this? Is it already done? If it's pended, I'll ask it to [EMAIL PROTECTED] The security support for 2.2 series was finished, we have no reason to support 2.2 kernel. No, it isn't :-( I didn't get around to it; if you could, that would be great. Note that the current status of the support kernel versions are: amd64 2.6.0 i386(i686) 2.6.0 i386(amd64) 2.6.0 *(nptl) 2.6.0 ppc64 2.6.0 s390x 2.4.1 sparc64 2.4.18 sparcv9 2.4.18 sparcv9b2.4.18 others 2.2.0 They'll be changed to: i386(i486) 2.4.1 powerpc 2.4.1 (?) BTW, note that some architectures like m68k could not compile the recent glibc with kernel 2.4.x or 2.6.x. Might want to check with the s390x and sparc porters, too. If 2.4 is dead for those architectures, we don't need to carry it around. ARM could probably use a bump, but I'm not sure to what. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
Stephen Gran wrote: At Thu, 15 Dec 2005 17:13:25 -0800, Edward Buck wrote: I guess the problem then is in the ipv6 support and how it implements domains in the search path. Instead of doing ipv6, then ipv4 for mx1.hotmail.com, it runs through all possible ipv6 queries, including exhausting all domains in the search path, before ipv4 queries are attempted. That seems (is) really inefficient. As a result of ipv6 supports, DNS queries have tripled on systems with two domains in their search path. Okay, perhaps this isn't a bug. It's just ipv6 hell. I guess the answer to this problem for you is to just disable ipv6 (unless you need it) - blacklisting the kernel module(s) ought to do it, although there may be some other parts I am unaware of. I did try commenting out: #alias net-pf-10 ipv6 in /etc/modprobe.d/aliases. Unfortunately, that doesn't keep the resolver from doing ipv6 queries. The behavior is the same regardless of whether the ipv6 kernel module is loaded (rebooted after the change and lsmod shows no ipv6 module). Is there another way to disable ipv6 queries by the resolver? I'm probably missing something simple but couldn't find anything in the docs. Thanks. Regards, Ed HTH, and take care, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#149902: Australian time zones
On Tue, Dec 20, 2005 at 09:47:56AM +0900, GOTO Masanori wrote: Note that you probably want to know why AEST vs EST is long-standing problem: the short summary is available in glibc source tree timezone/australasia. Not only one governmental page but also showing another information source would be nice idea to change time zone maintainers. Wow, this is a bug come back from the dead. I read the summary in glibc and think it's wierd. For example, the counts supposedly showing Eastern Standard Time to be more popular than Australia Eastern Standard Time are bogus. The first search is obviously going to include the results of the second. A simple calculation shows that even then the prefix was four times as common as without. Current figures from Google: Australian Eastern Standard Time site:.au 155000 Eastern Standard Time site:.au206000 Eastern Standard Time -Australian Eastern Standard Time site:.au 5 But in my mind the argument is simple: EST is ambiguous, AEST is not. The issue I had has to do with input, not output. Saying 9:00 EST is ambiguous, but 9:00 AEST is not even recognised as a valid date. Obviously you can't remove all ambiguity, but it's certainly worth removing whenever possible. There is still no way to specify an Australian timezone to date, which I suppose is the real bug. Yes, you can affect it with environment variables, but still... $ date --date='9:00 Australia/Sydney' date: invalid date `9:00 Australia/Sydney' $ date --date='9:00 EST' Tue Dec 20 15:00:00 CET 2005 --- ??? Not european time. What is it? $ date --date='9:00 AEST' date: invalid date `9:00 AEST' Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgpB3BlK4mdlT.pgp Description: PGP signature
