Test attached, better to test with more countries.
--
Dios, gracias por tu amor infinito.
--
Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/
http://www.pasosdejesus.org/dominio_publico_colombia.html
diff -u src55-orig/regress/lib/libc/locale/Makefile
src/regress/lib/libc/locale/M
Most of the attached numeric locales come from FreeBSD, I didn't include
others with encodings that I don't see in /usr/share/locale (like
eucJP, eucCN, eucKR, PT154, ISCII-DEV, CP1131, CP866, CP949, Big5,
Big5HKSCS, GB18030, GB2312, GBK, SJIS).
Again tried to minimize space of /usr/share/local
In the attached patch is an implementation of LC_NUMERIC in libc
(adapted from FreeBSD). Big portion of it, is change to the
function __vfprintf to support the flag ' (See
http://pubs.opengroup.org/onlinepubs/95399/functions/printf.html )
The function __category_filename in ldpart.c tries t
Since some confusion was expressed to me about the recent lib/csu/*/crt0.c
changes, I figured I should explain more broadly what that code does (or
is supposed to do) and why.
It's a bit obscure, but we can use more people understanding this stuff.
For example, it would be nice if someone loo
On 2013/11/11 19:54, Kenta Suzumoto wrote:
> Hi. When are we planning on fully replacing Apache with nginx?
> What can we do to help speed up this process?
Help identify which ports currently rely on Apache from base, work out
which ones can use nginx and move them across (updating READMEs etc whe
Hi. When are we planning on fully replacing Apache with nginx?
What can we do to help speed up this process? I think it's
been long enough that people can migrate.
The patch extends the structure lconv returned by localeconv(3)
by including fields added in C99, see:
http://pubs.opengroup.org/onlinepubs/009695399/functions/localeconv.html
--
Dios, gracias por tu amor infinito.
--
Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/
http://www.pasos
On Mon, Nov 11, 2013 at 05:21:26PM +0100, J??r??mie Courr??ges-Anglas wrote:
> Mark Kettenis writes:
>
> >> From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=)
> >> Date: Mon, 11 Nov 2013 16:31:08 +0100
> >>
> >> Today I heard someone struggling while trying to understand
Mark Kettenis writes:
>> From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=)
>> Date: Mon, 11 Nov 2013 16:31:08 +0100
>>
>> Today I heard someone struggling while trying to understand the meaning
>> and possible uses of the -d ping(8) flag. Looking at the code it seems
>
> From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=)
> Date: Mon, 11 Nov 2013 16:31:08 +0100
>
> Today I heard someone struggling while trying to understand the meaning
> and possible uses of the -d ping(8) flag. Looking at the code it seems
> that SO_DEBUG has no effect
Today I heard someone struggling while trying to understand the meaning
and possible uses of the -d ping(8) flag. Looking at the code it seems
that SO_DEBUG has no effect on a raw socket (right?), so I thought that
it would be better to document that.
ok?
Index: ping.8
=
On Mon, Nov 11, 2013 at 1:00 PM, Stuart Henderson wrote:
>> On 2013/11/11 12:15, Alexey Suslikov wrote:
>> > I see different inbound packet distribution on trunk on-top of em(4)s
>> > and on trunk on top of bnx(4)s -
>> > that's the real problem.
>>
> On 2013/11/11 10:43, I wrote:
>> The trunk dri
> On 2013/11/11 12:15, Alexey Suslikov wrote:
> > I see different inbound packet distribution on trunk on-top of em(4)s
> > and on trunk on top of bnx(4)s -
> > that's the real problem.
>
On 2013/11/11 10:43, I wrote:
> The trunk driver can't influence inbound packet distribution, that is
> down t
On Mon, Nov 11, 2013 at 12:43 PM, Stuart Henderson wrote:
> On 2013/11/11 12:15, Alexey Suslikov wrote:
>> On Mon, Nov 11, 2013 at 11:42 AM, Stuart Henderson
>> wrote:
>> > "master" on em0/em1/bnx0 is nothing to do with trunk, it is about the
>> > gigabit ethernet clocking source.
>>
>> ok, but
On 2013/11/11 12:15, Alexey Suslikov wrote:
> On Mon, Nov 11, 2013 at 11:42 AM, Stuart Henderson
> wrote:
> > "master" on em0/em1/bnx0 is nothing to do with trunk, it is about the
> > gigabit ethernet clocking source.
>
> ok, but it is obvious: documentation is unclear (silent) about that.
Why
On Mon, Nov 11, 2013 at 12:19 PM, Janne Johansson wrote:
> I'm not sure if I am misunderstanding your direction of "inbound", but that
> would be an effect of what the switch does, would it not?
> If the switch isn't configured for LACP correctly, then it would send the
> traffic to one of them, o
Here's the other part of the diff, touching drivers in mvme68k, mvme88k
sparc and vax.
Index: arch/mvme68k/dev/if_ie.c
===
RCS file: /cvs/src/sys/arch/mvme68k/dev/if_ie.c,v
retrieving revision 1.41
diff -u -p -r1.41 if_ie.c
--- arch/m
I'm still looking for tests/oks for the driver changed in the diff
below.
Here's what I said on Oct 17th:
> Diff below converts the remaining drivers in our tree that still compare
> the low and high value of their Ethernet multicast ranges to set the
> IFF_ALLMULTI flag to use "ac->ac_multirange
I'm not sure if I am misunderstanding your direction of "inbound", but that
would be an effect of what the switch does, would it not?
If the switch isn't configured for LACP correctly, then it would send the
traffic to one of them, only.
2013/11/11 Alexey Suslikov
> On Mon, Nov 11, 2013 at 11:
On Mon, Nov 11, 2013 at 11:42 AM, Stuart Henderson wrote:
> "master" on em0/em1/bnx0 is nothing to do with trunk, it is about the gigabit
> ethernet clocking source.
ok, but it is obvious: documentation is unclear (silent) about that.
>
> lacp hashing policy is the same as for loadbalance, see
"master" on em0/em1/bnx0 is nothing to do with trunk, it is about the gigabit
ethernet clocking source.
lacp hashing policy is the same as for loadbalance, see the manpage and confirm
in trunk_hashmbuf().
21 matches
Mail list logo
