This issue http://bugs.python.org/issue8852 seems to happen again since python 2.6.6. Same cause, same consequences. Patching Modules/socketmodule.h with the following fixes it:

--- Modules/socketmodule.h.orig 2010-05-09 15:15:40.000000000 +0000             
+++ Modules/socketmodule.h                                                      
@@ -59,6 +59,10 @@ typedef int socklen_t;                                       
 #include <bluetooth.h>                                                         
 #endif                                                                         
                                                                                
+#if defined(__sun)                                                             
+#undef HAVE_NETPACKET_PACKET_H                                                 
+#endif                                                                         
+                                                                               
 #ifdef HAVE_NETPACKET_PACKET_H                                                 
 # include <sys/ioctl.h>                                                        
 # include <net/if.h>

It has been fixed in 2.7.x, not 2.6.x (which is in security fixes-only mode).
Can you try with 2.7.1?

Actually, python 2.6 is the default version in pkgsrc (http://www.netbsd.org/docs/software/packages.html), and the reason why i'm pulling up this bug is that python 2.6 failure on SunOS brings down more than 3000 packages :/ Nevertheless, i'll try a bulk build with python 2.7 as the default version, thanks for the heads up.

> Actually, python 2.6 is the default version in pkgsrc
> (http://www.netbsd.org/docs/software/packages.html), and the reason
> why i'm pulling up this bug is that python 2.6 failure on SunOS brings
> down more than 3000 packages :/ Nevertheless, i'll try a bulk build
> with python 2.7 as the default version, thanks for the heads up.

Well, do you need to ship your own build of Python with pkgsrc?
OpenIndiana and recent Solaris versions should AFAIK ship a system
Python 2.6 by default.

Well, pkgsrc is an independent, portable sources-based packaging system which provides a complete set of packages for many architectures. Python is provided as a package per-se, and we do not yet have the ability to fallback to native python version.
If this patch is not to be pulled up to python 2.6 then we'll provide it as a separate patch to pkgsrc, that's really not a problem, i understand perfectly that python 2.6 is now on a maintenance state.

Thanks for your feedback.

I know this is closed etc... but Plone (the CMS I use) is tied to various versions of Python, in particular 2.6 at this time.  Having it not build on Open[Solaris/Indiana] means I can't install current versions of Plone/Zope on this platform.  Any chance it could be fixed?

> I know this is closed etc... but Plone (the CMS I use) is tied to
> various versions of Python, in particular 2.6 at this time.  Having it
> not build on Open[Solaris/Indiana] means I can't install current
> versions of Plone/Zope on this platform.  Any chance it could be
> fixed?

I would be surprised if Plone/Zope didn't work on 2.7 by the time.
Perhaps you want to ask their mailing-lists.

Plone ships with a "universal installer" which expects particular versions of python (and PIL etc etc) which makes it easy to build on, for example, many Linux distros, but it's just not working on Open[Solaris|Indiana] and also NetBSD (pkgsrc's python2.6 is broken too, but we're working on that).  The only time the installer gets bumped is when new versions of Plone get released, which means that only the bleeding edge might work.  This is a problem for many integrators who are tied to older versions of Plone|Zope that are unlikely to get migrated to more recent releases in any sort of a reasonable timeframe.

Is it really not possible to fix up python2.6 to solve this issue?