On Fri, Jun 22, 2012 at 04:09:17PM -0400, Ted Unangst wrote:
> On Fri, Jun 22, 2012 at 07:58, Jason McIntyre wrote:
> > On Thu, Jun 21, 2012 at 11:31:34PM -0400, Ted Unangst wrote:
> >> some of our man pages are a little heavy with the posix macros, which
> >> expand into a wall of text, especially
On Fri, Jun 22, 2012 at 07:58, Jason McIntyre wrote:
> On Thu, Jun 21, 2012 at 11:31:34PM -0400, Ted Unangst wrote:
>> some of our man pages are a little heavy with the posix macros, which
>> expand into a wall of text, especially when repeated multiple times.
>>
>> here's a diff that cleans up a f
On Fri, Jun 22, 2012 at 08:31:56PM +0200, Marc Espie wrote:
> On Thu, Jun 21, 2012 at 09:15:59AM +0200, Marc Espie wrote:
> > On Wed, Jun 20, 2012 at 06:47:03PM -0400, Brad Smith wrote:
> > >
> > > Please specify the exact ports you're attemtping to fix so that others
> > > can take a look and see
On Thu, Jun 21, 2012 at 09:15:59AM +0200, Marc Espie wrote:
> On Wed, Jun 20, 2012 at 06:47:03PM -0400, Brad Smith wrote:
> >
> > Please specify the exact ports you're attemtping to fix so that others
> > can take a look and see if there is the possibility of doing things in
> > a different / bett
This diff is totally broke. He never even tested it. Stay away
from it.
> So, here's the same diff with shlib glue.
>
> If you think that's slightly insane, blame bsd.lib.mk !
>
> Note: for now, there's only arch/libamd64.
> I don't feel qualified to comment/test/do the other arches if need be
On Fri, Jun 22, 2012 at 2:41 AM, Paul Irofti wrote:
> Tested with the following program and everything seems to work. I've
> also sprinkled some extra printfs in the original diff and both cases
> are found and dealt with in the kernel.
Woot. In it goes!
> The speed benefit comes from switching to a stack mbuf except in the
> case of errors, right?
I have worried about this diff since the first time seeing it. if
anyone ever makes a mistake in this code-path, and sends that mbuf out
into the wild, it will be an "un-managed" mbuf. by managed, i m
On Fri, Jun 22, 2012 at 04:58, Brad Smith wrote:
> On Thu, Mar 01, 2012 at 03:28:13PM +0100, Mike Belopuhov wrote:
>> This is a well-known from thib and dlg originally with a length fix
>> from yours truly, that marginally doubles througput (from 300kpps to
>> 500-600kpps on selected hardware).
>>
Hi,
I have written the patch below, allowing for group based loading of
authpf.rules. This patch won't break current configurations. Would be great if
this can be committed to cvs. As I'm a junior programmer, any comments are
welcome.
In it's current functionality, only the first found authpf.rul
> On Thu, Jun 21, 2012 at 8:31 PM, Ted Unangst wrote:
> > some of our man pages are a little heavy with the posix macros, which
> > expand into a wall of text, especially when repeated multiple times.
> >
> > here's a diff that cleans up a few offenders, by mostly trimming out
> > what i think is
I wrote this after the infamous race condition between ldconfig and ld.so.
Makes sense to share this as reference, most of that information being
available in various manpages.
You can't reach a ports build without having run thru the prepare and depend
stage for that port.
If you run dpb, a p
On Thu, Jun 21, 2012 at 10:55:29PM -0700, Philip Guenther wrote:
> > -The
> > .Fn mktemp
> > -function conforms to
> > -.St -p1003.1-2001 ;
> > -as of
> > -.St -p1003.1-2008
> > -it is no longer a part of the standard.
> > +was marked as a legacy interface in
> > +.St -p1003.1-2001 .
>
> I don't
Hi everybody,
there is code in ether_output() that handles the case that we have to
use a gateway to send the packet. This code does a lookup for the route
required to reach the gateway.
In case there is a gateway for which no direct route exists (surely a
stupid thing, but possible during recon
It seems some asus newer models crap out on _BCL or related AML methods
when dealing with our parser.
Could any of you that have such a model and have to disable acpivideo(4)
or acpivout(4) send the acpidump to bugs@ or me directly?
I plan to look into it during the following hackathon and could
On Wed, Jun 20, 2012 at 11:18:39PM -0700, Philip Guenther wrote:
> On Wed, Jun 20, 2012 at 4:26 AM, Paul Irofti wrote:
> > + SCARG(&bfa, cmd) = F_SETFL;
> > + SCARG(&bfa, arg) = (void *)O_NONBLOCK;
> > + error = sys_fcntl(p, &bfa, retval);
>
> That assu
hmm, on Thu, Jun 21, 2012 at 08:11:19PM +0100, Stuart Henderson said that
> On 2012/06/21 15:52, Daniel Bolgheroni wrote:
> > On Thu, Jun 21, 2012 at 04:21:30PM +0100, Nicholas Marriott wrote:
> > >
> > > I'm afraid tmux defaults are never going to please everyone. Some even
> > > had the gall to h
On Thu, Mar 01, 2012 at 03:28:13PM +0100, Mike Belopuhov wrote:
> This is a well-known from thib and dlg originally with a length fix
> from yours truly, that marginally doubles througput (from 300kpps to
> 500-600kpps on selected hardware).
>
> The idea is to save an IP header and 8 bytes of payl
On Thu, Jun 21, 2012 at 11:31:34PM -0400, Ted Unangst wrote:
> some of our man pages are a little heavy with the posix macros, which
> expand into a wall of text, especially when repeated multiple times.
>
> here's a diff that cleans up a few offenders, by mostly trimming out
> what i think is exc
18 matches
Mail list logo