isc-bind enable-filter-aaaa compile option

2015-07-14 Thread Marcus Andree
Guys, We came into an issue here, where it was needed to activate a not-so-widely-used feature of bind, "filter--on-v4". This functionality needs to be enabled when compiling tha package. A one-liner diff is attached. Can we see this applied to mainstream? thanks. # diff -u -p Makefile.ori

Re: UPDATE: devel/py-serial 2.4 => 2.7 (+ python3 support)

2015-07-14 Thread Fred
On 07/14/15 23:14, Fred wrote: Thanks for the pointers. Yes that's better diff - it's working fine with my arduino on amd64 - will test on i386 with a different serial device. Cheers fred Also tested on i386. Cheers Fred

Re: UPDATE: devel/py-serial 2.4 => 2.7 (+ python3 support)

2015-07-14 Thread Fred
On 07/14/15 22:58, Jérémie Courrèges-Anglas wrote: Fred writes: Hi, Hi, Attached is an update to py-serial I have lightly tested on amd64. Thanks Thanks for your diff. Some comments: - unnecessary whitespace changes in the Makefile - make plist is confused by the fact that ${MODPY_VE

Re: UPDATE: devel/py-serial 2.4 => 2.7 (+ python3 support)

2015-07-14 Thread Jérémie Courrèges-Anglas
Fred writes: > Hi, Hi, > Attached is an update to py-serial I have lightly tested on amd64. > > Thanks Thanks for your diff. Some comments: - unnecessary whitespace changes in the Makefile - make plist is confused by the fact that ${MODPY_VERSION} == ${MODPY_EGG_VERSION}. Since "MODPY_EG

Re: UPDATE: py-peewee

2015-07-14 Thread Jérémie Courrèges-Anglas
Committed, thanks. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

Re: devel/arm-none-eabi/newlib is broken

2015-07-14 Thread Brandon Mercer
Shall I commit the previous "big hammer" fix then? On Tue, Jul 14, 2015, 15:46 Christian Weisgerber wrote: > On 2015-07-13, Dave Vandervies wrote: > > > I went with the bigger hammer to make sure all of the configure overrides > > would get through and not just the one that was observed causing

Re: devel/arm-none-eabi/newlib is broken

2015-07-14 Thread Christian Weisgerber
On 2015-07-13, Dave Vandervies wrote: > I went with the bigger hammer to make sure all of the configure overrides > would get through and not just the one that was observed causing problems > when it got lost. I agree. Also, check how many config.guess files are hiding in subdirectories set MOD

Re: implicit type coercion in dynamic shared library calls?

2015-07-14 Thread Raul Miller
On Tue, Jul 14, 2015 at 1:03 PM, Ted Unangst wrote: > Raul Miller wrote: >> J uses a hack where doubles are passed as long. This works on other >> OSes but not on openbsd. > > This seems suspect. There's no guarantee double and long are the same size. Certainly, they are not. So on 32 bit archite

UPDATE: devel/py-serial 2.4 => 2.7

2015-07-14 Thread Fred
Hi, Attached is an update to py-serial I have lightly tested on amd64. Thanks Fred Index: Makefile === RCS file: /cvs/ports/devel/py-serial/Makefile,v retrieving revision 1.7 diff -u -p -u -r1.7 Makefile --- Makefile11 Mar 20

Re: implicit type coercion in dynamic shared library calls?

2015-07-14 Thread Kurt Miller
On Tue, 2015-07-14 at 08:13 -0400, Raul Miller wrote: > I also wind up spending a fair amount of time in ld.so You can avoid stepping through ld.so by starting your gdb session with LD_BIND_NOW=1 in your environment. This will do all the symbol resolution upfront so you won't need to step through

Re: [update] s-nail-14.8.3

2015-07-14 Thread Jérémie Courrèges-Anglas
Steffen Nurpmeso writes: > Jeremie Courreges-Anglas wrote: [...] > |This release brings an additional executable to perform dot-locking > |against mailboxes. Since by default on OpenBSD /var/mail belongs to > |root:wheel, mode 755 there is no way for that (setgid) executable to > |work, s

Re: implicit type coercion in dynamic shared library calls?

2015-07-14 Thread Ted Unangst
Raul Miller wrote: > J uses a hack where doubles are passed as long. This works on other > OSes but not on openbsd. This seems suspect. There's no guarantee double and long are the same size. > I was under the impression that gcc passes all values on the stack, > not in floating point registers o

implicit type coercion in dynamic shared library calls?

2015-07-14 Thread Raul Miller
Hi, I am working on porting J (see jsoftware.com) to openbsd. I have run into a problem with the interpreter's mechanism for calling routines in dynamically linked shared libraries. J uses a hack where doubles are passed as long. This works on other OSes but not on openbsd. The line of code in