Re: emacs fails to build after switching to 5.3

2013-05-10 Thread Han Boetes
Han Boetes wrote: > I noticed emacs failed to build after switching to 5.3. I > discussed the matter with the emacs devs and they added some > debug code which is triggered by CFLAGS='-g3 -DUNEXELF_DEBUG' So > when it's building the main binary at "Dumping under the name > emacs" I get this output:

Re: emacs fails to build after switching to 5.3

2013-05-10 Thread Jérémie Courrèges-Anglas
Han Boetes writes: > Hi, Hi (again), > I noticed emacs failed to build after switching to 5.3. I > discussed the matter with the emacs devs and they added some debug > code which is triggered by CFLAGS='-g3 -DUNEXELF_DEBUG' So when > it's building the main binary at "Dumping under the name emac

Re: add nl(1)

2013-05-10 Thread Jérémie Courrèges-Anglas
Arto Jonsson writes: > On Fri, May 10, 2013 at 08:04:57AM +0100, Stuart Henderson wrote: >> On 2013/05/10 13:18, Damien Miller wrote: >> > On Wed, 8 May 2013, Ted Unangst wrote: >> > >> > > On Tue, Apr 30, 2013 at 18:57, Arto Jonsson wrote: >> > > > Taken from netbsd with minor modifications. Co

Re: check for device_lookup result in vscsi

2013-05-10 Thread Matthew Dempsky
On Fri, May 10, 2013 at 6:02 AM, Mike Belopuhov wrote: > my intention here is very simple: there's a way you should call > device_lookup and everyone has to fulfill it's part of the contract. > all our devices do, vscsi doesn't. what's the reason for it to be > one of a kind? I'm ok with adding

Re: check for device_lookup result in vscsi

2013-05-10 Thread Mike Belopuhov
On Fri, May 10, 2013 at 10:35 -0700, Matthew Dempsky wrote: > On Fri, May 10, 2013 at 6:02 AM, Mike Belopuhov wrote: > > my intention here is very simple: there's a way you should call > > device_lookup and everyone has to fulfill it's part of the contract. > > all our devices do, vscsi doesn't.

Re: ftpd log address format

2013-05-10 Thread Todd T. Fries
Penned by Ted Unangst on 20130504 0:57.40, we have: | On Sat, May 04, 2013 at 07:26, Martijn van Duren wrote: | > For a lot of cases this isn't a problem. But there are a couple of | > instances where the domain name resolves to something a little to | > generic to be useful to determine it's orig

Re: trunk(4) take MTU from first member port.

2013-05-10 Thread Reyk Floeter
On Fri, May 10, 2013 at 04:53:18PM +0200, Mike Belopuhov wrote: > > if (tr->tr_ac.ac_if.if_mtu != ifp->if_mtu) seems wrong. what about people > > who want to use trunk between two totally different interfaces for failover? > > > > i think the trunk mtu should simply be the lowest common of the grou

Re: trunk(4) take MTU from first member port.

2013-05-10 Thread Reyk Floeter
Hi, the diff is needed - I was running into it quite recently when I was trying some QinQ/svlan configurations on trunk. Comments below, otherwise OK reyk On Fri, May 10, 2013 at 02:11:28PM +0100, Stuart Henderson wrote: > Index: if_trunk.c >

Re: trunk(4) take MTU from first member port.

2013-05-10 Thread Stuart Henderson
On 2013/05/10 16:53, Mike Belopuhov wrote: > On 10 May 2013 16:43, Chris Cappuccio wrote: > > Stuart Henderson [st...@openbsd.org] wrote: > >> On 2013/02/22 12:30, Stuart Henderson wrote: > >> > I thought we already had something for this after the misc@ thread > >> > a few months ago, but clearly

Re: trunk(4) take MTU from first member port.

2013-05-10 Thread Mike Belopuhov
On 10 May 2013 16:43, Chris Cappuccio wrote: > Stuart Henderson [st...@openbsd.org] wrote: >> On 2013/02/22 12:30, Stuart Henderson wrote: >> > I thought we already had something for this after the misc@ thread >> > a few months ago, but clearly not. >> > >> > Adapted from FreeBSD if_lagg.c r17166

Re: trunk(4) take MTU from first member port.

2013-05-10 Thread Chris Cappuccio
Stuart Henderson [st...@openbsd.org] wrote: > On 2013/02/22 12:30, Stuart Henderson wrote: > > I thought we already had something for this after the misc@ thread > > a few months ago, but clearly not. > > > > Adapted from FreeBSD if_lagg.c r171661 (which includes capability > > setting which we al

Re: add nl(1)

2013-05-10 Thread Arto Jonsson
On Fri, May 10, 2013 at 08:04:57AM +0100, Stuart Henderson wrote: > On 2013/05/10 13:18, Damien Miller wrote: > > On Wed, 8 May 2013, Ted Unangst wrote: > > > > > On Tue, Apr 30, 2013 at 18:57, Arto Jonsson wrote: > > > > Taken from netbsd with minor modifications. Comments? > > > > > > I don't t

Re: trunk(4) take MTU from first member port.

2013-05-10 Thread Stuart Henderson
On 2013/02/22 12:30, Stuart Henderson wrote: > I thought we already had something for this after the misc@ thread > a few months ago, but clearly not. > > Adapted from FreeBSD if_lagg.c r171661 (which includes capability > setting which we already do). > http://svnweb.freebsd.org/base/head/sys/net

Re: check for device_lookup result in vscsi

2013-05-10 Thread Mike Belopuhov
On 10 May 2013 14:57, Gerhard Roth wrote: > Mike, > > but it does check in vscsiopen(). Hence no userland program should be > able to call vscsiioctl() for a non-existant device because the open() > already failed. At least that's true as long as vscsi devices can't > disappear during run-time. >

Re: check for device_lookup result in vscsi

2013-05-10 Thread Gerhard Roth
Mike, but it does check in vscsiopen(). Hence no userland program should be able to call vscsiioctl() for a non-existant device because the open() already failed. At least that's true as long as vscsi devices can't disappear during run-time. Gerhard On Fri, 10 May 2013 14:44:39 +0200 Mike Belop

Re: check for device_lookup result in vscsi

2013-05-10 Thread Mike Belopuhov
On Fri, May 03, 2013 at 16:19 +0200, Mike Belopuhov wrote: > hi, > > while looking for the device_unref bugs, i found that > vscsi doesn't check if device_lookup has returned a > valid return value. > > ok? > anyone? > diff --git sys/dev/vscsi.c sys/dev/vscsi.c > index 3da371c..db65642 100644

Re: zskbd_device_lookup is not used anymore

2013-05-10 Thread Mike Belopuhov
Hi, I'll commit it then, if there are no objections. On Sat, May 04, 2013 at 14:09 +0200, Sebastian Reitenbach wrote: > > On Friday, May 3, 2013 17:16 CEST, Mike Belopuhov wrote: > > > hi, > > > > as far as i can tell these functions are not used anymore. > > my sparcbook 3gx seems to be

Unify and document usbd_transfer(9)

2013-05-10 Thread Martin Pieuchot
So this is is one more step in my effort to merge the various code paths to submit an USB transfer. This diff gets rid of the two badly named functions: usbd_bulk_transfer() & usbd_intr_transfer() and makes use of the usbd_setup_xfer(9) + usbd_transfer(9) combination. These functions were badly

Re: add nl(1)

2013-05-10 Thread Arto Jonsson
On Fri, May 10, 2013 at 08:04:57AM +0100, Stuart Henderson wrote: > If we do use this implementation, then pascal@'s version from 2011 added > some fixes from FreeBSD, http://comments.gmane.org/gmane.os.openbsd.tech/25740 I'll take a closer look at this and freebsd's code later today. There's one

Re: add nl(1)

2013-05-10 Thread Stuart Henderson
On 2013/05/10 13:18, Damien Miller wrote: > On Wed, 8 May 2013, Ted Unangst wrote: > > > On Tue, Apr 30, 2013 at 18:57, Arto Jonsson wrote: > > > Taken from netbsd with minor modifications. Comments? > > > > I don't think you've received much feedback. I don't know how other > > developers feel,