Re: audacious/audacious-plugins diff (Was: update sysutils/conky...)
On 20/04/11 9:37 AM, David Coppa wrote: On Wed, 20 Apr 2011, Pascal Stumpf wrote: On Wed, Apr 20, 2011 at 12:27:42PM +0200, David Coppa wrote: It's set up as SHARED_ONLY, I think because there aren't consumers for those libraries atm. No. Its because audacious won't work on a system that doesn't support shared libraries since it uses plugins. So the removal of SHARED_ONLY and adding PFRAG.shared is wrong. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
patch for math/py-numpy
Hi,
This patch is needed for py-numpy to work with Python 2.7.
Before adding this patch, I want to be sure that it works perfectly with Python
2.6 (and others...).
Are you ok ?
Thanks,
Remi.
Index: Makefile
===
RCS file: /cvs/openbsd/ports/math/py-numpy/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile22 Nov 2010 09:30:38 - 1.29
+++ Makefile24 Apr 2011 20:24:50 -
@@ -5,7 +5,7 @@ COMMENT=fast array and numeric program
MODPY_EGG_VERSION= 1.3.0
DISTNAME= numpy-${MODPY_EGG_VERSION}
PKGNAME= py-${DISTNAME}
-REVISION = 6
+REVISION = 7
CATEGORIES=math devel
HOMEPAGE= http://numpy.scipy.org/
Index: patches/patch-numpy_distutils_ccompiler_py
===
RCS file: patches/patch-numpy_distutils_ccompiler_py
diff -N patches/patch-numpy_distutils_ccompiler_py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-numpy_distutils_ccompiler_py 24 Apr 2011 20:24:50 -
@@ -0,0 +1,25 @@
+$OpenBSD$
+# Source : http://projects.scipy.org/numpy/changeset/8260
+--- numpy/distutils/ccompiler.py.orig Sun Mar 29 13:24:21 2009
numpy/distutils/ccompiler.py Mon Apr 25 00:05:05 2011
+@@ -2,15 +2,19 @@
+ import os
+ import sys
+ import new
++from copy import copy
+
+ from distutils.ccompiler import *
+ from distutils import ccompiler
++from distutils.errors import DistutilsExecError, DistutilsModuleError, \
++ DistutilsPlatformError
+ from distutils.sysconfig import customize_compiler
+ from distutils.version import LooseVersion
+
+ from numpy.distutils import log
+ from numpy.distutils.exec_command import exec_command
+-from numpy.distutils.misc_util import cyg2win32, is_sequence, mingw32,
quote_args, msvc_on_amd64
++from numpy.distutils.misc_util import cyg2win32, is_sequence, mingw32, \
++ quote_args, msvc_on_amd64
+
+ # hack to set compiler optimizing options. Needs to integrated with something.
+ import distutils.sysconfig
Re: ld.so speedup for large binaries with many shared libraries
from http://www.feyrer.de/NetBSD/bx/blosxom.cgi/index.front?-tags=arm http://mail-index.netbsd.org/tech-userlevel/2010/02/24/msg003325.html it will help Chrome, Firefox, Webkit, GNOME, KDE, LibreOffice, vlc (and similar monsters like those) On Sun, Apr 24, 2011 at 4:53 AM, Antti Harri wrote: > Hi, > > seems to work on amd64. Not sure if it made things quicker, but it sure didn't > make them slower either. > > -- > Antti Harri > >
Re: Samba nmbd throwing errors and exiting
On Sun, Apr 24, 2011 at 12:49:46PM +0100, Stuart Henderson wrote:
> On 2011/04/24 10:42, Claudio Jeker wrote:
> > On Sat, Apr 23, 2011 at 08:58:12PM +, Stuart Henderson wrote:
> > > On 2011-04-23, Henning Brauer wrote:
> > > > * Stuart Henderson [2011-04-23 14:41]:
> > > >> Should we do this or should we rethink allowing sockets to be
> > > >> bound to broadcast IP addresses?
> > > >
> > > > i have no idea. and that seems to be common for all of us. i really
> > > > dunno. anybody?
> > > >
> > >
> > > Unless there are objections I'll commit my samba diff tomorrow,
> > > it can always come out again if anything else changes.
> >
> > What is this socket used for? You can not send a packet out of that
> > socket. I guess it is a UDP socket that should pickup the broadcast hellos
> > that flood windows infested networks.
>
> Yes, exactly.
>
> > Our network stack will deliver broadcast datagram to all IP RAW and all
> > UDP dgram sockets that match and are bound to 0.0.0.0 or ::.
> >
> > /*
> > * Deliver a multicast or broadcast datagram to *all* sockets
> > * for which the local and remote addresses and ports match
> > * those of the incoming datagram. This allows more than
> > * one process to receive multi/broadcasts on the same port.
> >
> > Now there is this bit of code in the loop as well:
> > if (inp->inp_laddr.s_addr != INADDR_ANY) {
> > if (inp->inp_laddr.s_addr != ip->ip_dst.s_addr)
> > continue;
> > }
> >
> > So it may make sense to bind to a specific broadcast addr for SOCK_DGRAM
> > and SOCK_RAW AF_INET socks. In that case you only receive packets that are
> > sent to the network specific broadcast (this does not work for
> > packets sent to 255.255.255.255 on that LAN segment)
>
> That would look something like this horror..
>
> Index: in_pcb.c
> ===
> RCS file: /cvs/src/sys/netinet/in_pcb.c,v
> retrieving revision 1.116
> diff -u -p -r1.116 in_pcb.c
> --- in_pcb.c 19 Apr 2011 03:47:29 - 1.116
> +++ in_pcb.c 24 Apr 2011 11:31:56 -
> @@ -276,8 +276,12 @@ in_pcbbind(v, nam, p)
> } else if (sin->sin_addr.s_addr != INADDR_ANY) {
> sin->sin_port = 0; /* yech... */
> if (!(so->so_options & SO_BINDANY) &&
> - in_iawithaddr(sin->sin_addr,
> - inp->inp_rtableid) == NULL)
> + (ifa_ifwithaddr(sintosa(&sin),
> + inp->inp_rtableid) == NULL) &&
> + (so->so_type != SOCK_DGRAM) &&
> + (so->so_type != SOCK_RAW) &&
> + (in_iawithaddr(sin->sin_addr,
> + inp->inp_rtableid) == NULL))
> return (EADDRNOTAVAIL);
> }
> if (lport) {
I would prefer to split this monstrosity into multiple if statements.
Since this is totaly unreadable but I guess we want something like this.
We could call in_broadcast(sin->sin_addr, NULL) instead of in_iawithaddr()
to make the code more clear.
--
:wq Claudio
Re: Samba nmbd throwing errors and exiting
On 2011/04/24 10:42, Claudio Jeker wrote:
> On Sat, Apr 23, 2011 at 08:58:12PM +, Stuart Henderson wrote:
> > On 2011-04-23, Henning Brauer wrote:
> > > * Stuart Henderson [2011-04-23 14:41]:
> > >> Should we do this or should we rethink allowing sockets to be
> > >> bound to broadcast IP addresses?
> > >
> > > i have no idea. and that seems to be common for all of us. i really
> > > dunno. anybody?
> > >
> >
> > Unless there are objections I'll commit my samba diff tomorrow,
> > it can always come out again if anything else changes.
>
> What is this socket used for? You can not send a packet out of that
> socket. I guess it is a UDP socket that should pickup the broadcast hellos
> that flood windows infested networks.
Yes, exactly.
> Our network stack will deliver broadcast datagram to all IP RAW and all
> UDP dgram sockets that match and are bound to 0.0.0.0 or ::.
>
> /*
> * Deliver a multicast or broadcast datagram to *all* sockets
> * for which the local and remote addresses and ports match
> * those of the incoming datagram. This allows more than
> * one process to receive multi/broadcasts on the same port.
>
> Now there is this bit of code in the loop as well:
> if (inp->inp_laddr.s_addr != INADDR_ANY) {
> if (inp->inp_laddr.s_addr != ip->ip_dst.s_addr)
> continue;
> }
>
> So it may make sense to bind to a specific broadcast addr for SOCK_DGRAM
> and SOCK_RAW AF_INET socks. In that case you only receive packets that are
> sent to the network specific broadcast (this does not work for
> packets sent to 255.255.255.255 on that LAN segment)
That would look something like this horror..
Index: in_pcb.c
===
RCS file: /cvs/src/sys/netinet/in_pcb.c,v
retrieving revision 1.116
diff -u -p -r1.116 in_pcb.c
--- in_pcb.c19 Apr 2011 03:47:29 - 1.116
+++ in_pcb.c24 Apr 2011 11:31:56 -
@@ -276,8 +276,12 @@ in_pcbbind(v, nam, p)
} else if (sin->sin_addr.s_addr != INADDR_ANY) {
sin->sin_port = 0; /* yech... */
if (!(so->so_options & SO_BINDANY) &&
- in_iawithaddr(sin->sin_addr,
- inp->inp_rtableid) == NULL)
+ (ifa_ifwithaddr(sintosa(&sin),
+ inp->inp_rtableid) == NULL) &&
+ (so->so_type != SOCK_DGRAM) &&
+ (so->so_type != SOCK_RAW) &&
+ (in_iawithaddr(sin->sin_addr,
+ inp->inp_rtableid) == NULL))
return (EADDRNOTAVAIL);
}
if (lport) {
Re: changes to faq/ports/testing.html
On 2011-04-22, Amit Kulkarni wrote: > man bsd.port.mk has gazillion options, which are the best and minimum > options to highlight while porting (not a comprehensive list) is what > I am looking for in this checklist page. Well you mostly work from Makefile.template when you're writing a new port, so IMO the list of options you typically need to look at is already there doesn't really need duplicating in the faq. What would be useful is a bit more flesh to port-modules(5) and maybe some description in the faq about some of those...
Re: ld.so speedup for large binaries with many shared libraries
Hi, seems to work on amd64. Not sure if it made things quicker, but it sure didn't make them slower either. -- Antti Harri
Re: Samba nmbd throwing errors and exiting
On Sat, Apr 23, 2011 at 08:58:12PM +, Stuart Henderson wrote:
> On 2011-04-23, Henning Brauer wrote:
> > * Stuart Henderson [2011-04-23 14:41]:
> >> Should we do this or should we rethink allowing sockets to be
> >> bound to broadcast IP addresses?
> >
> > i have no idea. and that seems to be common for all of us. i really
> > dunno. anybody?
> >
>
> Unless there are objections I'll commit my samba diff tomorrow,
> it can always come out again if anything else changes.
What is this socket used for? You can not send a packet out of that
socket. I guess it is a UDP socket that should pickup the broadcast hellos
that flood windows infested networks.
Our network stack will deliver broadcast datagram to all IP RAW and all
UDP dgram sockets that match and are bound to 0.0.0.0 or ::.
/*
* Deliver a multicast or broadcast datagram to *all* sockets
* for which the local and remote addresses and ports match
* those of the incoming datagram. This allows more than
* one process to receive multi/broadcasts on the same port.
Now there is this bit of code in the loop as well:
if (inp->inp_laddr.s_addr != INADDR_ANY) {
if (inp->inp_laddr.s_addr != ip->ip_dst.s_addr)
continue;
}
So it may make sense to bind to a specific broadcast addr for SOCK_DGRAM
and SOCK_RAW AF_INET socks. In that case you only receive packets that are
sent to the network specific broadcast (this does not work for
packets sent to 255.255.255.255 on that LAN segment)
--
:wq Claudio
Re: [wip] Python 2.7.1
On Sat, Apr 23, 2011 at 10:27:33PM +0200, Remi Pointel wrote: > On Sat, 23 Apr 2011 21:40:31 +0200 > Remi Pointel wrote: > > On Thu, 14 Apr 2011 02:31:40 +0100 > > Federico Schwindt wrote: > > > Hi, > > > > Hello, thanks for your response. > > > > > I just checked my logs and it was hanging as well, apologies for the > > > initial > > > confusion. > > > Makefile.inc looks good but I wouldn't link 2.7 to the tree yet (the > > > Makefile bit). > > > A few comments: > > > > > > * add the fix for CVE-2011-1521. This should be applied to the other > > > versions; I've mailed some people about it as I cannot provide diffs atm. > > I added 3 patches, please verify it's ok: > > - patch-Lib_test_test_urllib2_py > > - patch-Lib_urllib2_py > > - patch-Lib_test_test_urllib_py > > These patches were not correct. > This is the correct tarball with the 4 patches (upstream): > - patch-Lib_urllib2_py > - patch-Lib_urllib_py > - patch-Lib_test_test_urllib2_py > - patch-Lib_test_test_urllib_py > > Sorry for the noise. > > So please test, it would be good to have this version in ports tree. ok to import, it can still be polished in-tree before 1) linking it the the build 2) making it the default python Landry
