reopen 444597
thanks
* Tanaka Akira:
Do you mean 0x7fff is -1 ?
I don't think so.
-1 is 0x, not 0x7fff.
Oops, you a right. This is a real bug, then.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing commands for [EMAIL PROTECTED]:
reopen 444597
Bug#444597: mktime returns 0x7fff for the year 2057
Bug reopened, originator not changed.
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(administrator, Debian
Package: tzdata
Version: 2007g-2
Severity: wishlist
Please provide the tzdata-source binary package with original Olsen
database. My package libdatetime-timezone-perl (possibly others, like
libicu) could use it as build-dep. It would make the synchronizing the
timezone data much simplier for
Anthony Towns writes (Re: getaddrinfo() behaviour):
In my opinion, if this isn't an RC issue, there's no urgency to having
glibc changed prior to the standards changing, and as such, this isn't
the last resort so the tech ctte shouldn't be deciding the issue, let
alone overruling the
Ian Jackson writes (Re: getaddrinfo() behaviour):
Limiting the TC's power to overrule a technical decision to only cases
where the TC believes that the wrong behaviour makes the package
unsuitable for release would eviscerate the only mechanism we have for
dealing with errors by maintainers.
On Mon, Oct 01, 2007 at 04:30:17PM +0100, Ian Jackson wrote:
Ian Jackson writes (Re: getaddrinfo() behaviour):
Limiting the TC's power to overrule a technical decision to only cases
where the TC believes that the wrong behaviour makes the package
unsuitable for release would eviscerate the
--- Additional Comments From drepper at redhat dot com 2007-10-02 04:29
---
The am_ET locale is wrong. The new script must be defined after the copy. This
now works fine.
--
What|Removed |Added
7 matches
Mail list logo
