Pierre Habouzit wrote:
> The point is, there is an RFC, and we put a patch so that admins can
> disable it using gai.conf.
"There is an RFC" is not always a good excuse for breaking existing systems.
"Admins can disable it" is not a good argument when one common class of
the breakage is all the
On Fri, Sep 07, 2007 at 12:34:10AM +0200, Pierre Habouzit wrote:
> the Ctte may want to read:
> - http://udrepper.livejournal.com/16116.html
> - http://people.redhat.com/drepper/linux-rfc3484.html
The first one makes a point to which I party agree, but also disagree.
It's atleast in the spi
FYI: The status of the tzdata source package
in Debian's testing distribution has changed.
Previous version: 2007f-12
Current version: 2007g-1
--
This email is automatically generated; [EMAIL PROTECTED] is responsible.
See http://people.debian.org/~henning/trille/ for more information.
--
On Thu, Sep 06, 2007 at 10:04:23PM +, Kurt Roeckx wrote:
> Hi,
>
> I'm not agreeing with the glibc maintainer(s) about wether getaddrinfo()
> should sort the results or not. I think the current way it sorts things
> does not work at all in IPv4, and I think it hurts more than it does
> good.
Processing commands for [EMAIL PROTECTED]:
> reopen 438179
Bug#438179: Please provide a way to override RFC3484
'reopen' may be inappropriate when a bug has been closed with a version;
you may need to use 'found' to remove fixed versions.
Bug reopened, originator not changed.
> reassign 438179 te
Hi,
I'm not agreeing with the glibc maintainer(s) about wether getaddrinfo()
should sort the results or not. I think the current way it sorts things
does not work at all in IPv4, and I think it hurts more than it does
good.
I'm seeking input from the tech-ctte on how to handle this.
Kurt
si
* Fri, 3 Aug 2007 09:16:56 -0400, Leon Bottou:
>
[]
> This segfault is a little bit freaky.
> The value 9.9991e-05 is important.
> If you take 10e-5, no segfault.
> A debug trace suggests that printf calls wmemset
> with incorrect arguments. I'll try to learn more.
Message-ID: <[EMAIL
Package: locales
Version: 2.6.1-1
In fi_FI locale, grep does odd things:
echo "w" | grep "[a-z]"
produces nothing, but
echo "a" | grep "[a-z]"
yiels a as it should. All letters except v and w work correctly. This has
been reported in #440813. But I found out that patching
/usr/share/i18n/local
8 matches
Mail list logo
