[issue31562] snakebite.net is not available

[Trent Nelson]

Trent Nelson <tr...@trent.me> added the comment:

Unfortunately the host backing blackhole.snakebite.net and 
whitehole.snakebite.net is no longer available.  I still think the underlying 
test is valuable, though -- are there any PSF boxes/containers that could 
fulfill this role?

(I used pf on FreeBSD to set up the two firewall rules: 
https://github.com/python/cpython/blob/master/Lib/test/test_timeout.py#L183.  
If a new box were to be sourced I presume it would be a Linux instance, so the 
rules would need to be ported to whatever the Linux firewall on the box is.)

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31562>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31562] snakebite.net is not available

[Trent Nelson]

Trent Nelson added the comment:

H, I'll investigate when I get home tomorrow.

Sent from my iPhone

> On Sep 23, 2017, at 13:46, Serhiy Storchaka <rep...@bugs.python.org> wrote:
> 
> 
> New submission from Serhiy Storchaka:
> 
> The testConnectTimeout in test_timeout is skipped since network resources it 
> uses are not available.
> 
> $ ./python -m test -vuall test_timeout
> ...
> testConnectTimeout (test.test_timeout.TCPTimeoutTestCase) ... skipped 
> "Resource 'blackhole.snakebite.net' is not available"
> 
> $ host blackhole.snakebite.net
> ;; connection timed out; no servers could be reached
> $ host whitehole.snakebite.net
> ;; connection timed out; no servers could be reached
> $ host snakebite.net
> ;; connection timed out; no servers could be reached
> 
> Is it temporary or permanent issue?
> 
> --
> components: Tests
> messages: 302793
> nosy: serhiy.storchaka, trent
> priority: normal
> severity: normal
> status: open
> title: snakebite.net is not available
> type: behavior
> 
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue31562>
> ___

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31562>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22919] Update PCBuild for VS 2015

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22919
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18835] Add aligned memory variants to the suite of PyMem functions/macros

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18835
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16296] Patch to fix building on Win32/64 under VS 2010

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16296
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16296] Patch to fix building on Win32/64 under VS 2010

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
versions:  -Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16296
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13483] Use VirtualAlloc to allocate memory arenas

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13483
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3329] API for setting the memory allocator used by Python

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3329
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18203] Replace direct calls to malloc() with PyMem_Malloc() or PyMem_RawMalloc()

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18203
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12181] SIGBUS error on OpenBSD (sparc64)

[Trent Nelson]

Trent Nelson added the comment:

Yeah those slaves are definitely due for an update.  It's on the list.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12181
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12181] SIGBUS error on OpenBSD (sparc64)

[Trent Nelson]

Trent Nelson added the comment:

On Tue, Apr 09, 2013 at 03:04:42AM -0700, Charles-Fran?ois Natali wrote:
  Why are the OpenBSD buildbots down? Can we do anything about it?
  Having a buildbot slave up will definitely help here.
 
 All the OpenBSD buildbots we have are provided by SnakeByte, and
 they're all offline: http://buildbot.python.org/all/builders Maybe
 Trent has more info.

Oh dear, hadn't noticed that.  Should be fixed now.

Trent.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12181
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17611] Move unwinding of stack for pseudo exceptions from interpreter to compiler.

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17611
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17338] Add length_hint parameter to list, dict, set constructors to allow efficient presizing

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17338
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17444] multiprocessing.cpu_count() should use hw.availcpu on Mac OS X

[Trent Nelson]

Trent Nelson added the comment:

On Tue, Mar 19, 2013 at 01:58:59AM -0700, John Szakmeister wrote:
 
 John Szakmeister added the comment:
 
 Actually, Trent's version looks at hw.logicalcpu and then falls back
 to hw.ncpu, if there was an error.  Given the state of the
 documentation on these parameters, it's hard to say whether it's right
 or wrong, but at least hw.logicalcpu scales correctly if I disable
 some of the processors.

That's pretty much the rationale I used.  I tested the fallback on
OS X manually (i.e. the _bsd_cpu_count()), and that works, and the
hw.logicalcpu definitely works in the first place, so, I figured it
was good enough.

I'll raise a new issue for os.cpu_count().

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17444
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17444] multiprocessing.cpu_count() should use hw.availcpu on Mac OS X

[Trent Nelson]

Trent Nelson added the comment:

I remember looking at what multiprocessing did and not really liking it; I 
ended up writing a C version that works across a wider range of platforms, 
accessible via posixmodule.c:posix_cpu_count() (os.cpu_count()):

http://hg.python.org/sandbox/trent/file/dd1c2fd3aa31/Modules/posixmodule.c#l10213

--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17444
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17344] checking size of size_t... configure: error:

[Trent Nelson]

Trent Nelson added the comment:

Shilpi, can you paste the exact ./configure invocation you're using?

--
status: pending - open

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17344
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17056] Support Visual Studio 2012

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17056
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5289] ctypes.util.find_library does not work under Solaris

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5289
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1298835] Add a vendor-packages directory for system-supplied modules

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +brian-cameron-oracle, trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1298835
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13405] Add DTrace probes

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13405
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13057
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16902] Add OSS module support for Solaris

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16902
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16762] test_subprocess failure on OpenBSD/NetBSD buildbots

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16762
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16742] PyOS_Readline drops GIL and calls PyOS_StdioReadline, which isn't thread safe

[Trent Nelson]

New submission from Trent Nelson:

Relevant thread: 
http://mail.python.org/pipermail/python-dev/2012-December/123225.html

PyOS_StdioReadline features numerous calls that require the GIL to be held.  
Ideally, the GIL drop-take should be moved closer to the actual underlying read 
system call.

--
assignee: trent
components: Interpreter Core
messages: 177874
nosy: trent
priority: normal
severity: normal
stage: needs patch
status: open
title: PyOS_Readline drops GIL and calls PyOS_StdioReadline, which isn't thread 
safe
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16742
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16733] Solaris ctypes_test failures

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16733
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al).

[Trent Nelson]

Trent Nelson added the comment:

On Thu, Dec 13, 2012 at 10:28:00PM -0800, Ned Deily wrote:
 
 Ned Deily added the comment:
 
 Without having reviewed the proposed change in detail, a couple of
 comments.  On current OS X systems and others, the compiler could be
 clang which perhaps should be treated as gcc for most autoconf
 purposes.

I'm not intending to target OS X in the autoconf block I referred
to; it's a popular platform for developers and users, and doesn't
have any of the problems that the proprietary *NIXes/compilers
have.

This work is solely aimed at Solaris, Tru64, HP-UX, AIX and IRIX.

 Also, why are we putting any effort into supporting IRIX
 anymore?

We?  It's just me :-)  So a more appropriate question might be why
am I bothering to put effort into supporting it?  And the answer to
that is simply because I can; Snakebite has an SGI Origin running
the latest version of IRIX with the MIPSpro compiler suite, which
is all the hardware I need to keep things chugging along.  (IRIX
also has a huge active fan base of users that run a lot of OSS
software -- nekoware et al.)

 Both IRIX and the MIPS processor lines it runs on was retired by SGI
 in 2007.  That's why support for IRIX was pulled from Python 3.

Support was pulled for, to quote PEP 11, IRIX 4 and --with-sgi-dl;

PEP 11 also has a nice clause that basically says platform support
is primarily based on having an active maintainer willing to keep
everything in shape -- I'm happy to be marked as the maintainer for
all the aforementioned *NIX platforms.

Martin made a good point a few weeks ago when we discussed this on
infrastructure@; his concern was the effort involved in supporting
additional platforms could detract developers from more important
tasks.

I agree -- they're esoteric platforms at best, EOL at worst, and
just because I'm maintaining them shouldn't mean other developers
have to worry about breaking them.  They're not anywhere near as
important as the big 3 (Linux/Windows/OSX).  If they do break,
though, I'll keep fixing them as long as I'm actively maintaining
support for that platform.

The motivation behind this particular change is simple: it took
about three days to nail down the exact flags to use on Solaris
SPARC 32-bit to get a working ./python (with lots of referring
to various Sun/Oracle compiler docs).  No-one else should have
to go through this much effort -- ./configure should pick the
right flags out of the box for the following permutations:

32/64 bit debug builds:
./configure --without-gcc --with-pydebug
./configure --without-gcc --with-pydebug --enable-64bit

32/64 bit release builds:
./configure --without-gcc
./configure --without-gcc --enable-64bit

(And again, just to clarify, none of this work will remotely
 affect Linux, OS X or the *BSDs.  It doesn't take three days
 of reading compiler manuals to get working builds on those
 platforms.)

--
title: Improve ./configure's support for 32/64-bit debug|release|profiled 
builds w/ vendor (non-gcc) compilers on   proprietary UNIX systems 
(Solaris/HP-UX/AIX et al). - Improve ./configure's support for 32/64-bit 
debug|release|profiled builds w/ vendor (non-gcc) compilers  on proprietary 
UNIX systems (Solaris/HP-UX/AIX et al).

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15963
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al).

[Trent Nelson]

Trent Nelson added the comment:

I spent a little time on this yesterday.  Here's what I came up with.  The idea 
is to have a standalone block in configure.ac that kicks in when --without-gcc 
is specified (or if $CC != gcc) *IFF* CFLAGS/CPPFLAGS haven't been provided 
by the user.

If they have, we warn, and skip the block.  Rationale is wanting to cover two 
cases: a) experienced user consciously overriding our attempts at sensible 
defaults in that block, b) inexperienced user who has no clue what the sensible 
defaults are but has otherwise inadvertently set CFLAGS/CPPFLAGS (or perhaps 
just inherited such settings from their existing environment).

So, here's what the block looks like currently, albeit just for IRIX at the 
moment (and this was against 2.7).  I'll eventually expand it to cover 
Solaris/SPARC|AMD64, AIX, HP-UX (PA-RISC/IA64) and Tru64.

(Also note the new `--enable-64bit` arg, which is intended to be used on these 
platforms as a way to coerce easy 64-bit builds.  The functionality doesn't 
apply on x86/x64 free *nix platforms that use clang/gcc -- those will default 
to using whatever memory architecture is being used by the underlying system -- 
if you want something else, that's the job of cross-compilation, which is a 
different problem this particular issue is attempting to address.)

+AC_MSG_CHECKING(for --enable-64bit)
+AC_ARG_ENABLE(
+64bit,
+AS_HELP_STRING(
+[--enable-64bit],
+[attempt 64-bit build (use with --without-gcc)]
+)
+)
+if test -z $enable_64bit; then
+AC_MSG_RESULT(no)
+else
+AC_MSG_RESULT(yes)
+fi
+if test -n $enable_64bit  test $without_gcc != yes; then
+AC_MSG_WARN([
+--enable-64bit has no effect unless --without-gcc is also specified
+])
+fi
+
+# If we're not using GCC, we're probably on a proprietary UNIX, relying
+# on a proprietary compiler, running on non-x86/x64 hardware.  Autoconf
+# is pretty bad at picking sensible defaults for compiler flags in this
+# situation, so, let's try and do as much as we can ourselves.  The aim
+# is to pick the optimal settings for each of the following permutations:
+#
+# Debug builds, 32-bit and 64-bit:
+#   ./configure --without-gcc --with-pydebug
+#   ./configure --without-gcc --with-pydebug --enable-64bit
+#
+# Optimized release builds, 32-bit and 64-bit:
+#   ./configure --without-gcc
+#   ./configure --without-gcc --enable-64bit
+#
+if test $without_gcc = yes || test $CC != gcc; then
+# This whole block assumes we know more than a) the user, and b) autoconf.
+# If we detect CFLAGS/CPPFLAGS, then we can't safely assume a) anymore,
+# so print a message instead of doing any customisation.
+if test -n $CFLAGS || test -n $CPPFLAGS; then
+AC_MSG_WARN([
+You have defined CFLAGS and/or CPPFLAGS in conjunction with
+--with-gcc; skipping attempt at setting flags to sensible
+defaults -- make sure you know what you are doing.
+])
+else
+case $MACHDEP in
+irix6)
+# Trying to separate IRIX from C99 and still end up with a
+# working executable is an exercise in futility; it has a
+# much greater link between `cc -c99` and available system
+# facilities/headers than other OSes (which primarily rely
+# on the usual XPG4/XOPEN_SOURCE etc defines).  Using the
+# c99 compiler is the lesser of two evils.
+CC=c99
+CXX=CC
+# `-diag_error 1035` makes the compiler treat #error defines
+# as actual errors (and abort compilation), and not warnings.
+CFLAGS=-diag_error 1035
+# Try to target the underlying host hardware.
+_platform=`hinv -c processor |
+   head -n 1 |
+   cut -f 4 -d ' '`
+_processor=`hinv -c processor |
+head -n 2 |
+tail -n 1 |
+cut -f 3 -d ' '`
+CFLAGS=$CFLAGS -TARG:platform=$_platform
+CFLAGS=$CFLAGS -TARG:processor=$_processor
+
+if test $with_pydebug = yes; then
+OPT=-O -g2
+else
+OPT=-g3 -Ofast=$_platform -OPT:Olimit=5500
+fi
+
+if test -n $enable_64bit; then
+CFLAGS=-64 $CFLAGS
+LDFLAGS=-64
+else
+CFLAGS=-n32 $CFLAGS
+LDFLAGS=-n32
+fi
+;;
+*)  ;;
+esac
 fi
 fi

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15963
___
___
Python-bugs-list mailing list
Unsubscribe: 
http

[issue16668] Remove python3dll.vcxproj from pcbuild.sln

[Trent Nelson]

New submission from Trent Nelson:

As far as I can tell, the python3dll.vcxproj is bitrot and should be removed 
from pcbuild.sln.  It's a makefile target project that invokes 
..\PC\python3.mak, which builds a target named python3.dll; however, 
pythoncore.vxcproj builds python34[_d].dll as a proper VS project.

(Additionally, the python3dll.vxcproj has no Debug configuration, which is what 
brought it to my attention in the first place.)

Christian/Martin: is this python3dll.vcxproj and resulting python3.dll still 
used or can it be safely removed from pcbuild.sln?

--
assignee: trent
components: Build
messages: 177372
nosy: christian.heimes, loewis, trent
priority: normal
severity: normal
status: open
title: Remove python3dll.vcxproj from pcbuild.sln
versions: Python 3.2, Python 3.3, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16668
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16668] Remove python3dll.vcxproj from pcbuild.sln

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +brian.curtin

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16668
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16668] Remove python3dll.vcxproj from pcbuild.sln

[Trent Nelson]

Trent Nelson added the comment:

Thanks Martin, I wasn't aware of that PEP.  Explains why there isn't a debug 
configuration, too.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16668
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10052] Python/dtoa.c:158: #error Failed to find an exact-width 32-bit integer type (FreeBSD 4.11 + gcc 2.95.4)

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10052
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16533] HPUX: Unable to fork() in thread

[Trent Nelson]

Trent Nelson added the comment:

On Thu, Nov 22, 2012 at 02:18:32PM -0800, Stefan Krah wrote:
 
 New submission from Stefan Krah:
 
 There's an error on the HPUX-IA64 buildbot that might be due to
 some kernel limits. Trent, could you check if the following helps
 (requires root)?
 
 http://zensonic.dk/?p=326

Hmmm, there doesn't appear to be anything interesting in syslog.log.
I'll look into it.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16533
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16534] test_float failure on IA64 (HPUX)

[Trent Nelson]

Trent Nelson added the comment:

On Fri, Nov 23, 2012 at 05:43:15AM -0800, Mark Dickinson wrote:
 
 Mark Dickinson added the comment:
 
 I wonder whether adding -fpeval=float to the CFLAGS would fix this.  
 There's a lot of information at 
 
 http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=0008a22194f02110a22194f02110275d6e10RCRD
 
 but I don't know whether it's relevant to this machine.  Trent?

No idea.  I'll look into it.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16534
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

[Trent Nelson]

Trent Nelson added the comment:

On Sun, Nov 18, 2012 at 03:19:19PM -0800, Antoine Pitrou wrote:
 
 Antoine Pitrou added the comment:
 
 Related post:
 http://daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/

Yeah, came across that yesterday.  Few other relevant links, for the
records:


http://social.msdn.microsoft.com/Forums/en/wsk/thread/18769abd-fca0-4d3c-9884-1a38ce27ae90
 (has a code example of what doesn't work)


http://www.codeproject.com/Articles/140533/The-Differences-Between-Network-Calls-in-Windows-a

http://blogs.msdn.com/b/wndp/archive/2006/10/26/wsapoll.aspx

http://curl.haxx.se/mail/lib-2012-10/0038.html

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16507
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

[Trent Nelson]

New submission from Trent Nelson:

Attached patch adds select.poll() support on Windows via WSAPoll.

It's hacky; I was curious to see whether or not it could be done, and whether 
or not tulip's pollster would work with it.

It compiles and works, but doesn't play very nicely with tulip.  Also, just 
about every lick of code that tests poll() does so in a UNIX-specific way, so 
it's hard to test.

As with select, WSAPoll() will barf if you feed it anything other than SOCKETs 
(i.e. it doesn't work against non-socket file descriptors).

--
files: wsapoll.patch
keywords: patch
messages: 175927
nosy: trent
priority: normal
severity: normal
status: open
title: Patch selectmodule.c to support WSAPoll on Windows
Added file: http://bugs.python.org/file28038/wsapoll.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16507
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2005] posixmodule expects sizeof(pid_t/gid_t/uid_t) = sizeof(long)

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2005
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16442] PATH_MAX vs MAXPATHLEN vs pathconf(..., _PC_PATH_MAX).

[Trent Nelson]

New submission from Trent Nelson:

Two immediate issues identified whilst trying to build on HP-UX and IRIX:

1.  Our source is wildly inconsistent with regards to using PATH_MAX versus 
MAXPATHLEN.

2.  The current logic in osdefs.h is insufficient for ensuring one or the other 
always has a value (complicated by issue 1 above).

Christian alluded to introducing a PY_PATH_MAX define, which I like.  So, my 
proposal is to fix the logic in osdefs.h so that it works on a wider range of 
platforms, with the end goal of defining PY_PATH_MAX, then replacing all 
occurrences of PATH_MAX|MAXPATHLEN in our tree with the new PY_PATH_MAX.

(It's worth mentioning that, technically, we shouldn't be using PATH_MAX or 
MAXPATHLEN.  We should be using pathconf(..., _PC_PATH_CONF) to determine the 
maximum length of the underlying filesystem at runtime and dynamically 
allocating buffers based on that value.

However, that's a huge, non-trivial change.  For another day.)

--
assignee: trent
components: Build
messages: 175183
nosy: trent
priority: normal
severity: normal
stage: needs patch
status: open
title: PATH_MAX vs MAXPATHLEN vs pathconf(..., _PC_PATH_MAX).
type: compile error
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16442
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16136] Removal of VMS support

[Trent Nelson]

Trent Nelson added the comment:

Ah, I forgot about the VOE stuff.  That will work a lot better.  I'll still 
need to acquire VMS media though.

You're not a committer are you?  I can sort you out with access to Snakebite 
anyway -- email me your ssh key if you're interested (trent at snakebite.org).

I'd recommend dropping by #python-dev on irc.freenode.net too.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16136
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9742] Python 2.7: math module fails to build on Solaris 9

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9742
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9742] Python 2.7: math module fails to build on Solaris 9

[Trent Nelson]

Trent Nelson added the comment:

Snakebite's got a Solaris 9 SPARC instance up and running.  It's available via 
the s9 alias.

Regarding EOL, this indicates October 2014 for 9: 
http://en.wikipedia.org/wiki/Solaris_(operating_system)#Version_history

If it's as simple as suggested, I don't mind taking ownership of this.  I'm 
going to run into it anyway as soon as I set up a Solaris 9 slave.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9742
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15746] test_winsound bombing out on 2003 buildslave

[Trent Nelson]

Trent Nelson added the comment:

We avoided this by adding -u-audio to the affected slave.

--
resolution:  - fixed
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15746
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
resolution:  - fixed
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16274
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16136] Removal of VMS support

[Trent Nelson]

Trent Nelson added the comment:

On Mon, Oct 22, 2012 at 11:18:03AM -0700, Christian Heimes wrote:
 
 Christian Heimes added the comment:
 
 We don't have any box that is capable of running VMS. Even Trent's
 Snakebit setup doesn't have VMS although he has lots of exotic
 hardware and OS, even HP-UX on a PA-RISC machine.

I actually do have a box set aside for VMS.  It's a quad Itanium2
with ~24-32GB of RAM (same hardware as the 'titanium' HP-UX box).

I just haven't set it up yet due to lack of interest.  First thing
I'll need is OpenVMS media/licenses.  I'll ping HP and see if they
can assist.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16136
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

Trent Nelson added the comment:

On Mon, Oct 22, 2012 at 05:51:23AM -0700, Giampaolo Rodola' wrote:
 
 Giampaolo Rodola' added the comment:
 
 This should do it:
 
 diff --git a/Lib/test/test_asyncore.py b/Lib/test/test_asyncore.py
 --- a/Lib/test/test_asyncore.py
 +++ b/Lib/test/test_asyncore.py
 @@ -484,8 +484,9 @@
  return self.socket.getsockname()[:2]
  
  def handle_accept(self):
 -sock, addr = self.accept()
 -self.handler(sock)
 +pair = self.accept()
 +if pair is not None:
 +self.handler(pair[0])
  
  def handle_error(self):
  raise

Yeah this looks a lot more appropriate than the two changes
Jesús posted.  I'll test against my Solaris boxes and report
back.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16274
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16262] srcdir != builddir builds fail, if hg is not installed

[Trent Nelson]

Trent Nelson added the comment:

On Sun, Oct 21, 2012 at 02:59:37PM -0700, R. David Murray wrote:
 
 R. David Murray added the comment:
 
 This change appears to have broken the dmg builders:
 
   http://buildbot.python.org/all/builders/bolen-dmg-3.x/builds/19
   http://buildbot.python.org/all/builders/bolen-dmg-3.3/builds/17

Ah, relevant error:

creating Makefile
Traceback (most recent call last):
  File /Users/db3l/buildarea.dmg/bolen-dmg-3.x/build/Parser/asdl_c.py, line 
1254, in ?
main(args[0])
  File /Users/db3l/buildarea.dmg/bolen-dmg-3.x/build/Parser/asdl_c.py, line 
1203, in main
c = ChainOfVisitors(TypeDefVisitor(f),
  File /Users/db3l/buildarea.dmg/bolen-dmg-3.x/build/Parser/asdl_c.py, line 
87, in __init__
self.identifiers = set()
NameError: global name 'set' is not defined
make: *** [Include/Python-ast.h] Error 1
Running make

So, it's not that it broke the daily dmg builders per se, it's just
that the version of Python being used to generate the ADSL on those
boxes is old (and doesn't have set()).  I guess that means whatever
Python version was picked up is 2.4?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16262
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16263] sendmsg, recvmsg, recvmsg_into et al not being detected on Solaris

[Trent Nelson]

Trent Nelson added the comment:

After some investigation, I've established the following cause:

1. Our Solaris builds should add -D_XPG4_2 to CPPFLAGS.  I've been
   manually setting this on the Solaris build slaves.  This define
   ensures all the POSIX 95 things get picked up (like sendmsg etc).

2. Even when it is in CPPFLAGS, it doesn't get picked up when
   building extension modules, such as socketmodule.c, because they
   are built solely with CCSHARED.

The first issue can be fixed via configure.ac/Makefile.pre.in.

As for the second issue... it's somewhat odd that there's no documented
way to ensure extra flags get passed $CC when building extensions.  Then
again, it's always been like this, and nobody has complained to date.

Thus, rather than introduce a public/documented way for extending flags
passed to $CC when building extension modules, I think for now, altering
configure.ac/Makefile.pre.in to also tweak CCSHARED when on Solaris as
part of fixing the first part is sufficient.

Patch to follow.

Trent.

P.S.: when -D_XPG4_2 is added to CCSHARED, the socket sendmsg stuff gets
  built and... *drum-roll* fails some tests :-)

--
title: sendmsg, recvmsg, recvmsg_into et al not being detected on Solaris - 
sendmsg, recvmsg,  recvmsg_into et al not being detected on Solaris

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16263
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16263] sendmsg, recvmsg, recvmsg_into et al not being detected on Solaris

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
title: sendmsg, recvmsg,recvmsg_into et al not being detected on 
Solaris - sendmsg, recvmsg, recvmsg_into et al not being detected on Solaris

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16263
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al).

[Trent Nelson]

Trent Nelson added the comment:

On Tue, Sep 18, 2012 at 06:40:35AM -0700, Trent Nelson wrote:
 Side bar design question: on BSD/Linux/OSX w/ gcc/clang, if you're on
 an amd64 platform, you'll get a 64-bit build.  This isn't the case for
 Solaris, HP-UX and AIX -- the default is always 32-bit.  You need
 aforementioned gymnastics to coerce a 64-bit build.
 
 Is this by design?  If so, then I guess I'm proposing that ./configure
 should have a `--with-64`-type argument that'll generate a 64-bit
 build.
 
 If not, then we need to decide whether to change the default behavior
 such that ./configure always generates a 64-bit build if you're on a
 64-bit platform -- if you want a 32-bit build, you need to explicitly
 tell ./configure (i.e. --with-32).
 
 Changing the default is probably only viable for 3.4 onwards.  It'd be
 nice if 2.7-3.3 had generic configure support for 64-bit builds
 though (via --with-64).
 
 XXX TODO for trent: review autoconf's offerings... getting 64-bit
 builds from vendor cc's can't be that unusual.

Just wanted to make note of a precedent I noticed yesterday whilst
coercing local builds of Tcl, expect and a few other things on the
Solaris 10 SPARC box: they all use `--enable-64bit` as the arg to
configure to enable 64-bit builds.

Additionally, none of them default to 64-bit out-of-the-box; they
all inherit the underlying compilers default behavior.  Which
means gcc/clang gets you 64-bit on amd64, but a cc build on a
64-bit host may not.  (I need to check a few more permutations on
this, like what happens with gcc on SPARC/IA64 etc if the host OS
is 64-bit -- does it default to 64-bit?)

Side note: some of those projects had *much* nicer autoconf-fu
than we do.  Tcl implements the --enable-64bit stuff in aclocal.m4.

So, I'm changing my stance from what I quoted above.  We should try
mimic the precedent set by other projects:

- Use --enable-64bit as the flag.
- Default 64-bit builds depend on the underlying compiler.

--
title: Improve ./configure's support for 32/64-bit debug|release|profiled 
builds w/ vendor (non-gcc) compilers on proprietary UNIX systems 
(Solaris/HP-UX/AIX et al). - Improve ./configure's support for 32/64-bit 
debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary 
UNIX systems (Solaris/HP-UX/AIX et al).

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15963
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS

[Trent Nelson]

Trent Nelson added the comment:

Larry and I just chatted about this on IRC.  Summary:

 1.)  I was wrong about os.stat() affecting atime.  I fired up a
  console session on Solaris to prove my atime observation
  only to find os.stat() had no impact on atime:

% ./python
Python 2.7.3+ (2.7:90a46f8943d0, Oct 18 2012, 11:09:15) [C] on sunos5
Type help, copyright, credits or license for more information.
 import os
 fname = 'configure'
 st0 = os.stat(fname)
 os.utime(fname, (st0.st_atime, st0.st_mtime))
 st0.st_atime
1350571183.474864
 st1 = os.stat(fname)
 st1.st_atime
1350571183.474864

  So, we can ignore my but os.stat() affects atime! noise
  earlier in this report.

 2.)  Regardless of the underlying platform, the unit tests should
  test utime() with nano, micro and second resolution.  However,
  the tests should be cognizant of the underlying platform's
  os.stat() versus os.utime() resolution when testing the actual
  results.

  That is, if you pass a nanosecond time to os.utime() on a platform
  that doesn't have underlying nanosecond support for utime (i.e. no
  utimensat()), then expect a microsecond resolution time back from
  stat().

 3.)  Regarding fixed times versus re-setting the first results of our
  stat() call: no strong opinion either way -- the main objective
  is to ensure the tests have good coverage and are robust.  So
  whatever gets the job done.

--
title: Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ 
FFS, Solaris w/ UFS) - Numerous utime ns tests fail on FreeBSD w/ ZFS

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16287] Sporadic test_utime() failures on Solaris

[Trent Nelson]

New submission from Trent Nelson:

This was initially observed in #15745, however, there's a separate problem 
here.  The current test_utime() on Solaris sporadically (usually) fails along 
the following lines:

 self.assertEqual(attr(st0, st_mtime), attr(st1, st_mtime))
 AssertionError: 1347752941.275297 != 1347752941.275296

 That is, test_utime() always results in a st1.st_mtime that is
 off-by-1 from st0.st_mtime.  The precision is well within the
 nanasecond resolution offered by utimensat, so it doesn't appear to be
 the same issue experienced by other platforms.

Run that test in a loop though, and it sometimes passes.  So, there's an 
underlying bug, somewhere.

--
messages: 173339
nosy: trent
priority: normal
severity: normal
status: open
title: Sporadic test_utime() failures on Solaris

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16287
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16287] Sporadic test_utime() failures on Solaris

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +larry, pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16287
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

[Trent Nelson]

Trent Nelson added the comment:

On Tue, Oct 16, 2012 at 10:46:34PM -0700, Trent Nelson wrote:
 
 Trent Nelson added the comment:
 
 Thanks for the feedback Larry; yeah that patch definitely wasn't
 intended to be production quality -- more of a proof of concept.  I
 agree with your points, they'll be factored into the next patch.
 
 However, I'm absolutely baffled by the Solaris 10 failure.  The more I
 looked into it, the weirder it got.  The issue is always the same:
 
 self.assertEqual(attr(st0, st_mtime), attr(st1, st_mtime))
 AssertionError: 1347752941.275297 != 1347752941.275296
 
 That is, test_utime() always results in a st1.st_mtime that is
 off-by-1 from st0.st_mtime.  The precision is well within the
 nanasecond resolution offered by utimensat, so it doesn't appear to be
 the same issue experienced by other platforms.

I've concluded that the problem on Solaris is actually unrelated
to the original failures on FreeBSD and NetBSD that this issue
was raised for (where os.stat() returns nanosecond resolution but
os.utime() only accepts microsecond).

I've raised a separate bug for this issue: #16287.

--
title: Numerous utime ns tests fail on FreeBSD w/ ZFS - Numerous utime ns 
tests fail on FreeBSD w/ ZFS (update:and NetBSD w/ FFS, Solaris w/ UFS)

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
status: closed - open

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16274
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

New submission from Trent Nelson:

% ./python -m test.regrtest test_asyncore
test_asyncore
Exception in thread Thread-3:
Traceback (most recent call last):
  File /home/cpython/hg/2.7/Lib/threading.py, line 552, in __bootstrap_inner
self.run()
  File /home/cpython/hg/2.7/Lib/threading.py, line 505, in run
self.__target(*self.__args, **self.__kwargs)
  File /home/cpython/hg/2.7/Lib/test/test_asyncore.py, line 712, in lambda
t = threading.Thread(target=lambda: asyncore.loop(timeout=0.1, count=500))
  File /home/cpython/hg/2.7/Lib/asyncore.py, line 220, in loop
poll_fun(timeout, map)
  File /home/cpython/hg/2.7/Lib/asyncore.py, line 156, in poll
read(obj)
  File /home/cpython/hg/2.7/Lib/asyncore.py, line 87, in read
obj.handle_error()
  File /home/cpython/hg/2.7/Lib/asyncore.py, line 83, in read
obj.handle_read_event()
  File /home/cpython/hg/2.7/Lib/asyncore.py, line 443, in handle_read_event
self.handle_accept()
  File /home/cpython/hg/2.7/Lib/test/test_asyncore.py, line 487, in 
handle_accept
sock, addr = self.accept()
TypeError: 'NoneType' object is not iterable

Exception in thread Thread-4:
Traceback (most recent call last):
  File /home/cpython/hg/2.7/Lib/threading.py, line 552, in __bootstrap_inner
self.run()
  File /home/cpython/hg/2.7/Lib/threading.py, line 505, in run
self.__target(*self.__args, **self.__kwargs)
  File /home/cpython/hg/2.7/Lib/test/test_asyncore.py, line 712, in lambda
t = threading.Thread(target=lambda: asyncore.loop(timeout=0.1, count=500))
  File /home/cpython/hg/2.7/Lib/asyncore.py, line 220, in loop
poll_fun(timeout, map)
  File /home/cpython/hg/2.7/Lib/asyncore.py, line 156, in poll
read(obj)
  File /home/cpython/hg/2.7/Lib/asyncore.py, line 87, in read
obj.handle_error()
  File /home/cpython/hg/2.7/Lib/asyncore.py, line 83, in read
obj.handle_read_event()
  File /home/cpython/hg/2.7/Lib/asyncore.py, line 443, in handle_read_event
self.handle_accept()
  File /home/cpython/hg/2.7/Lib/test/test_asyncore.py, line 487, in 
handle_accept
sock, addr = self.accept()
TypeError: 'NoneType' object is not iterable

1 test OK.
[43391 refs]

Sample buildbot run that failed: 
http://buildbot.python.org/all/builders/SPARC64%20Solaris%2010%20%5BSB%5D%202.7/builds/69/steps/test/logs/stdio

Haven't investigated yet.

--
assignee: trent
messages: 173237
nosy: jcea, trent
priority: normal
severity: normal
status: open
title: test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16274
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13843] Python doesn't compile anymore on our Solaris buildbot: undefined libintl_* symbols

[Trent Nelson]

Trent Nelson added the comment:

I ran into this yesterday on my Solaris 10 box (nitrogen/s10), seemingly out of 
nowhere.

The problem is caused when a GNU libintl.h gets picked up via `#include 
libintl.h` instead of the system one in /usr/include.

In my case, this was happening because I had set CPPFLAGS to 
-I/opt/csw/include -I/opt/csw/include/ncurses -I/usr/include.

The fix is to order the includes as follows: -I/opt/csw/include/ncurses 
-I/usr/include -I/opt/csw/include.

The order is important: you want the /opt/csw/include/ncurses to come first, 
otherwise _curses won't build from the curses.h in /usr/include.  However, for 
libintl.h, you want the /usr/include version, not the /opt/csw/include version.

(Side note: I briefly looked at the GNU libintl.h in /opt/csw/include.  The 
`libintl_` function prefix is driven by some #ifdef logic, so, presumably, if 
you really wanted to build with the GNU libintl, you could do some #define 
tweaking to disable the `libintl_` prefix.  The libintl shipped with Solaris 10 
seems to work fine, so I didn't bother with this.)

Closing as fixed.

--
nosy: +trent
resolution:  - fixed
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13843
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16275] test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10) (Sun C compiler)

[Trent Nelson]

New submission from Trent Nelson:

This should be a fun one to track down.

Relevant buildbot run: 
http://buildbot.python.org/all/builders/SPARC64%20Solaris%2010%20%5BSB%5D%202.7/builds/69/steps/test/logs/stdio

When recompiled with gcc 4.6.3 (/opt/csw/bin/gcc), test_ctypes passes without 
issue (on 2.7 and 3.2).

Going to try a local build of libffi from git with Sun C and --with-system-ffi 
to see if that helps.

==
FAIL: test_struct_return_2H 
(ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)
--
Traceback (most recent call last):
  File 
/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py,
 line 172, in test_struct_return_2H
self.assertEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: Tuples differ: (-65, -28679) != (198, 264)

First differing element 0:
-65
198

- (-65, -28679)
+ (198, 264)

==
FAIL: test_struct_return_8H 
(ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)
--
Traceback (most recent call last):
  File 
/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py,
 line 189, in test_struct_return_8H
(9*2, 8*3, 7*4, 6*5, 5*6, 4*7, 3*8, 2*9))
AssertionError: Tuples differ: (8412232, 9364168, 1, -4223016... != (18, 24, 
28, 30, 30, 28, 24, 1...

First differing element 0:
8412232
18

- (8412232, 9364168, 1, -4223016, -8, -32, -4222983, 5425288)
+ (18, 24, 28, 30, 30, 28, 24, 18)

==
FAIL: test_wchar_parm 
(ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)
--
Traceback (most recent call last):
  File 
/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py,
 line 28, in test_wchar_parm
self.assertEqual(result, 139)
AssertionError: 138 != 139

==
FAIL: test_struct_return_2H 
(ctypes.test.test_as_parameter.AsParamWrapperTestCase)
--
Traceback (most recent call last):
  File 
/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py,
 line 172, in test_struct_return_2H
self.assertEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: Tuples differ: (-65, -28679) != (198, 264)

First differing element 0:
-65
198

- (-65, -28679)
+ (198, 264)

==
FAIL: test_struct_return_8H 
(ctypes.test.test_as_parameter.AsParamWrapperTestCase)
--
Traceback (most recent call last):
  File 
/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py,
 line 189, in test_struct_return_8H
(9*2, 8*3, 7*4, 6*5, 5*6, 4*7, 3*8, 2*9))
AssertionError: Tuples differ: (8431512, 9370440, 1, -4223016... != (18, 24, 
28, 30, 30, 28, 24, 1...

First differing element 0:
8431512
18

- (8431512, 9370440, 1, -4223016, -8, -32, -4222983, 5425848)
+ (18, 24, 28, 30, 30, 28, 24, 18)

==
FAIL: test_wchar_parm (ctypes.test.test_as_parameter.AsParamWrapperTestCase)
--
Traceback (most recent call last):
  File 
/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py,
 line 28, in test_wchar_parm
self.assertEqual(result, 139)
AssertionError: 138 != 139

==
FAIL: test_struct_return_2H (ctypes.test.test_as_parameter.BasicWrapTestCase)
--
Traceback (most recent call last):
  File 
/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py,
 line 172, in test_struct_return_2H
self.assertEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: Tuples differ: (-65, -28679) != (198, 264)

First differing element 0:
-65
198

- (-65, -28679)
+ (198, 264)

==
FAIL: test_struct_return_8H (ctypes.test.test_as_parameter.BasicWrapTestCase)
--
Traceback (most recent call last):
  File 
/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py,
 line 189

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

Trent Nelson added the comment:

3.2 appears fine.  This behavior only seems to happen on 2.7.

The affected tests are:

test_quick_connect (test.test_asyncore.TestAPI_UseSelect) 
test_quick_connect (test.test_asyncore.TestAPI_UsePoll) 

Doing some more digging.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16274
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

Trent Nelson added the comment:

Yeah I've just backported the semantic changes between asyncore and 
test_asyncore from 3.2 - 2.7.

I'll report back shortly with results.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16274
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

Trent Nelson added the comment:

Ok, attached patch is a semantic backport matching 2.7 to 3.2.  All tests pass 
with this patch.

(I can't comment on whether or not the changes in 3.2 actually fix an 
underlying issue, or just hide it better.)

--
keywords: +patch
Added file: http://bugs.python.org/file27609/issue16274_asyncore.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16274
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

Trent Nelson added the comment:

Patch applied and everything passes, so closing for now.

--
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16274
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16274] test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)

[Trent Nelson]

Trent Nelson added the comment:

That backport wasn't appropriate -- it included new public members to asyncore 
that were introduced in 3.2.

I'll work on a less intrusive patch.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16274
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1516] make _ctypes work with non-gcc compilers

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1516
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16275] test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10) (Sun C compiler)

[Trent Nelson]

Trent Nelson added the comment:

With the latest build (from git) of libffi, tests still fail, but differently.

(These errors seem slightly less perverse than the ones pasted previously.)

==
FAIL: test_wchar_parm 
(ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)
--
Traceback (most recent call last):
  File /home/cpython/hg/2.7/Lib/ctypes/test/test_as_parameter.py, line 28, in 
test_wchar_parm
self.assertEqual(result, 139)
AssertionError: 138 != 139

==
FAIL: test_wchar_parm (ctypes.test.test_as_parameter.AsParamWrapperTestCase)
--
Traceback (most recent call last):
  File /home/cpython/hg/2.7/Lib/ctypes/test/test_as_parameter.py, line 28, in 
test_wchar_parm
self.assertEqual(result, 139)
AssertionError: 138 != 139

==
FAIL: test_wchar_parm (ctypes.test.test_as_parameter.BasicWrapTestCase)
--
Traceback (most recent call last):
  File /home/cpython/hg/2.7/Lib/ctypes/test/test_as_parameter.py, line 28, in 
test_wchar_parm
self.assertEqual(result, 139)
AssertionError: 138 != 139

==
FAIL: test_ints (ctypes.test.test_bitfields.C_Test)
--
Traceback (most recent call last):
  File /home/cpython/hg/2.7/Lib/ctypes/test/test_bitfields.py, line 40, in 
test_ints
self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), 
name)))
AssertionError: Tuples differ: ('A', 1, -1) != ('A', 1, 0)

First differing element 2:
-1
0

- ('A', 1, -1)
?  ^^

+ ('A', 1, 0)
?  ^


==
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
--
Traceback (most recent call last):
  File /home/cpython/hg/2.7/Lib/ctypes/test/test_bitfields.py, line 47, in 
test_shorts
self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), 
name)))
AssertionError: Tuples differ: ('M', 1, -1) != ('M', 1, 0)

First differing element 2:
-1
0

- ('M', 1, -1)
?  ^^

+ ('M', 1, 0)
?  ^


==
FAIL: test_byte (ctypes.test.test_callbacks.Callbacks)
--
Traceback (most recent call last):
  File /home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py, line 36, in 
test_byte
self.check_type(c_byte, 42)
  File /home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py, line 22, in 
check_type
self.assertEqual(self.got_args, (arg,))
AssertionError: Tuples differ: (0,) != (42,)

First differing element 0:
0
42

- (0,)
+ (42,)

==
FAIL: test_char (ctypes.test.test_callbacks.Callbacks)
--
Traceback (most recent call last):
  File /home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py, line 91, in 
test_char
self.check_type(c_char, x)
  File /home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py, line 22, in 
check_type
self.assertEqual(self.got_args, (arg,))
AssertionError: Tuples differ: ('\x00',) != ('x',)

First differing element 0:

x

- ('\x00',)
?   - --

+ ('x',)

==
FAIL: test_double (ctypes.test.test_callbacks.Callbacks)
--
Traceback (most recent call last):
  File /home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py, line 83, in 
test_double
self.check_type(c_double, 3.14)
  File /home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py, line 30, in 
check_type
self.assertEqual(self.got_args, (-3, arg))
AssertionError: Tuples differ: (0, 3.14) != (-3, 3.14)

First differing element 0:
0
-3

- (0, 3.14)
?  ^

+ (-3, 3.14)
?  ^^


==
FAIL: test_int (ctypes.test.test_callbacks.Callbacks)
--
Traceback (most recent call last):
  File /home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py, line 50, in 
test_int
self.check_type(c_int, 42)
  File /home/cpython/hg/2.7/Lib/ctypes/test/test_callbacks.py, line 30, in 
check_type
self.assertEqual(self.got_args, (-3, arg))
AssertionError: Tuples differ: (0, 42) != (-3, 42)

First differing element 0:
0
-3

- (0, 42)
?  ^

+ (-3, 42

[issue16275] test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10) (Sun C compiler)

[Trent Nelson]

Trent Nelson added the comment:

After an hour of fiddling with pre-requisites, I was able to run the libffi 
testsuite (for the Sun C build).  The results weren't ideal:

=== libffi Summary ===

# of expected passes1528
# of unexpected failures118
# of unsupported tests  55

And for the gcc 4.6 build:

=== libffi Summary ===

# of expected passes1659
# of unsupported tests  55

I'm giving up.  (For now.)

Hopefully I'll be able to rope the libffi folk onto Snakebite in the future.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16275
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16275] test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10) (Sun C compiler)

[Trent Nelson]

Trent Nelson added the comment:

On Thu, Oct 18, 2012 at 07:47:40AM -0700, Stefan Krah wrote:
 
 Stefan Krah added the comment:
 
 --with-system-ffi should probably solve some problems, see #12927.

This isn't an option on Solaris 10, as it doesn't ship with a
system ffi, unfortunately.  (That being said, after building
the latest libffi with Sun C, I do use --with-system-ffi in
order to override the building of Modules/_ctypes/libffi.)

 The summary of that issue is that the unpatched libffi is not
 compatible with suncc and any issues should be reported upstream
 (at least that was Meador's and my own opinion).

Sun CC is supported by libffi for SPARC only.  You're right
regarding x86/x64 though; libffi explicitly doesn't support
using anything other than gcc on Solaris if it's x86.

(Unfortunately, my only SPARC boxes are running Solaris 9
 and 10.  I don't have new-enough SPARC CPUs that can run
 Solaris 11.  If I did, this would probably be moot, as I
 could just use the system libffi Sun provide.)

Side note: on my Solaris 11 x64 box, --with-system-ffi works
(once -I and -L are tweaked), but test_ctypes still fails if
you're building with Sun CC.

--
title: test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10) (Sun C 
compiler) - test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10)(Sun C 
compiler)

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16275
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1516] make _ctypes work with non-gcc compilers

[Trent Nelson]

Trent Nelson added the comment:

Hi Greg,

I realize it's been a good five years since you first raised this
issue, but I was wondering if you ever ended up making any progress
with it?

In trying to get Python working on Snakebite UNIX boxes with vendor
CCs, I'm running into all sorts of issues.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1516
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15298] _sysconfigdata is generated in srcdir, not builddir

[Trent Nelson]

Trent Nelson added the comment:

Ah, this is because of this OS X-specific snippet in sysconfig.get_platform():

elif osname[:6] == darwin:
import _osx_support
osname, release, machine = _osx_support.get_platform_osx(
get_config_vars(),
osname, release, machine)

get_config_vars() results in _init_posix() eventually being called, which 
attempts to import _sysconfigdata.

Ugh.  Looking into a patch now.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15298
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

[Trent Nelson]

Trent Nelson added the comment:

Re: how did it ever work... on Solaris, because of the st_mtime failure, it 
doesn't even get a chance to fail on the subsequent st_atime.  I suspect the 
only platform that's exercised the utimensat() to date is Linux, and either a) 
os.stat() doesn't affect atime on Linux, b) everyone has atime disabled, c) the 
two stat calls happen quick enough that no measurable difference is observed 
against st_atime.

As for POSIX:

http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm

The fstat() function shall update any time-related fields (as described in XBD 
File Times Update ), before writing into the stat structure.

The referenced section:

4.8 File Times Update

Each file has three distinct associated timestamps: the time of last data 
access, the time of last data modification, and the time the file status last 
changed. These values are returned in the file characteristics structure struct 
stat, as described in sys/stat.h .

Each function or utility in POSIX.1-2008 that reads or writes data (even if the 
data does not change) or performs an operation to change file status (even if 
the file status does not change) indicates which of the appropriate timestamps 
shall be marked for update. If an implementation of such a function or utility 
marks for update one of these timestamps in a place or time not specified by 
POSIX.1-2008, this shall be documented, except that any changes caused by 
pathname resolution need not be documented. For the other functions or 
utilities in POSIX.1-2008 (those that are not explicitly required to read or 
write file data or change file status, but that in some implementations happen 
to do so), the effect is unspecified.

An implementation may update timestamps that are marked for update immediately, 
or it may update such timestamps periodically. At the point in time when an 
update occurs, any marked timestamps shall be set to the current time and the 
update marks shall be cleared. All timestamps that are marked for update shall 
be updated when the file ceases to be open by any process or before a fstat(), 
fstatat(), fsync(), futimens(), lstat(), stat(), utime(), utimensat(), or 
utimes() is successfully performed on the file. Other times at which updates 
are done are unspecified. Marks for update, and updates themselves, shall not 
be done for files on read-only file systems; see Read-Only File System .

The resolution of timestamps of files in a file system is 
implementation-defined, but shall be no coarser than one-second resolution. The 
three timestamps shall always have values that are supported by the file 
system. Whenever any of a file's timestamps are to be set to a value V 
according to the rules of the preceding paragraphs of this section, the 
implementation shall immediately set the timestamp to the greatest value 
supported by the file system that is not greater than V.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

[Trent Nelson]

Trent Nelson added the comment:

Here's a thought...  why not alter the test to work with fixed times and 
separate the atime tests from the mtime tests.

For atime, we can set utime(filename, (0.0, ...)) and see if a subsequent 
os.stat() returns st_atime as 0.0 -- that'll tell us whether or not atime is 
affected.

For the mtime tests, rather than having a variable UTIME_EPSILON, just have 
fixed dates that match the expected precision of the underlying platform?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16257] test_socket.test_create_connection tests for wrong errno on Solaris

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
resolution:  - fixed
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16257
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16263] sendmsg, recvmsg, recvmsg_into et al not being detected on Solaris

[Trent Nelson]

New submission from Trent Nelson:

Sample test_socket -v output:

testSendmsgDataGenerator (test.test_socket.SendmsgUDPTest) ... skipped don't 
have sendmsg
testSendmsgExcessCmsgReject (test.test_socket.SendmsgUDPTest) ... skipped 
don't have sendmsg
testSendmsgGather (test.test_socket.SendmsgUDPTest) ... skipped don't have 
sendmsg
testSendmsgNoDestAddr (test.test_socket.SendmsgUDPTest) ... skipped don't have 
sendmsg
testRecvmsg (test.test_socket.RecvmsgUDPTest) ... skipped don't have recvmsg
testRecvmsgAfterClose (test.test_socket.RecvmsgUDPTest) ... skipped don't have 
recvmsg
testRecvmsgBadArgs (test.test_socket.RecvmsgUDPTest) ... skipped don't have 
recvmsg

This is on the Solaris 10 box.  sendmsg/recvmsg etc definitely exist.

Haven't investigated yet.

--
assignee: trent
messages: 173154
nosy: jcea, trent
priority: normal
severity: normal
status: open
title: sendmsg, recvmsg, recvmsg_into et al not being detected on Solaris
versions: Python 3.2, Python 3.3, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16263
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15298] _sysconfigdata is generated in srcdir, not builddir

[Trent Nelson]

Trent Nelson added the comment:

That last commit fixes in-tree builds, but broke out-of-tree builds.  I've 
refactored the patch (sysconfig.py.patch) to fix the issue, but it's getting 
progressively more hacky, so I wanted to see what other people think before 
proceeding.

(That being said, it works a *lot* better than the previous solution of writing 
_sysconfigdata.py to the root builddir, then moving it.  That didn't work at 
all for out-of-tree builds.  This solution slots _sysconfigdata directly into 
sys.modules, which _init_posix() is more than happy with.)

--
Added file: http://bugs.python.org/file27601/sysconfig.py.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15298
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16258] test_local.TestEnUSCollection failures on Solaris 10

[Trent Nelson]

Trent Nelson added the comment:

With the caveat that I know absolutely nothing about locales, here's what I've 
been able to reduce the problem down to:

zinc (alias s11, Solaris 11 x64):
 locale.setlocale(locale.LC_ALL, 'C')
'C'
 locale.strxfrm('a')
'a'
 locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
'en_US.UTF-8'
 locale.strxfrm('a')
Traceback (most recent call last):
  File stdin, line 1, in module
ValueError: character U+10105a3 is not in range [U+; U+10]
 

nitrogen (alias s10, Solaris 10 SPARC):

 locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
'en_US.UTF-8'
 locale.strxfrm('a')
Traceback (most recent call last):
  File stdin, line 1, in module
ValueError: character U+101010e is not in range [U+; U+10]

Not sure how relevant it is, but on both those Solaris boxes, locale.LC_ALL 
returns 6, whereas on BSD and OS X it always seems to return 0.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16258
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15833] most failures to write byte-compiled file no longer suppressed

[Trent Nelson]

Trent Nelson added the comment:

Charles' patch applied in 3.3 and merged to 3.x.  Thanks Charles.

--
resolution:  - fixed
stage:  - committed/rejected
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15833
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Trent Nelson]

Trent Nelson added the comment:

Things should be looking a lot better now across the board.  I just committed 
fixes where appropriate to 2.7, 3.2, 3.3 and 3.x for this issue and two related 
issues: 

http://bugs.python.org/issue15298
http://bugs.python.org/issue15833

The only thing that stands out now for 3.[23x] is $(srcdir)/Lib/$(PLATDIR).  Do 
we need a patch along the following lines?

% hg diff
diff -r 617591e7d708 Makefile.pre.in
--- a/Makefile.pre.in   Tue Oct 16 08:41:32 2012 -0400
+++ b/Makefile.pre.in   Tue Oct 16 09:46:53 2012 -0400
@@ -947,7 +947,7 @@
multiprocessing multiprocessing/dummy \
unittest unittest/test \
curses pydoc_data $(MACHDEPS)
-libinstall:build_all $(srcdir)/Lib/$(PLATDIR) $(srcdir)/Modules/xxmodule.c
+libinstall:build_all Lib/$(PLATDIR) $(srcdir)/Modules/xxmodule.c
@for i in $(SCRIPTDIR) $(LIBDEST); \
do \
if test ! -d $(DESTDIR)$$i; then \
@@ -1031,14 +1031,14 @@
./$(BUILDPYTHON) -m lib2to3.pgen2.driver 
$(DESTDIR)$(LIBDEST)/lib2to3/PatternGrammar.txt
 
 # Create the PLATDIR source directory, if one wasn't distributed..
-$(srcdir)/Lib/$(PLATDIR):
-   mkdir $(srcdir)/Lib/$(PLATDIR)
-   cp $(srcdir)/Lib/plat-generic/regen $(srcdir)/Lib/$(PLATDIR)/regen
+Lib/$(PLATDIR):
+   mkdir Lib/$(PLATDIR)
+   cp $(srcdir)/Lib/plat-generic/regen Lib/$(PLATDIR)/regen
export PATH; PATH=`pwd`:$$PATH; \
export PYTHONPATH; PYTHONPATH=`pwd`/Lib; \
export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH=`pwd`; \
export EXE; EXE=$(BUILDEXE); \
-   cd $(srcdir)/Lib/$(PLATDIR); $(RUNSHARED) ./regen
+   cd Lib/$(PLATDIR); $(RUNSHARED) ./regen
 
 python-config: $(srcdir)/Misc/python-config.in
# Substitution happens here, as the completely-expanded BINDIR

--
nosy: +pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15819
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

[Trent Nelson]

Trent Nelson added the comment:

I've figured out what the primary problem is on these platforms: os.stat() 
returns st_mtime and st_atime values with nanosecond resolution, but without a 
corresponding utimensat(), we can only affect time with microsecond precision 
via utimes().

Therefore, the following logic is faulty:

def _test_utime(self, filename, attr, utime, delta):
# Issue #13327 removed the requirement to pass None as the
# second argument. Check that the previous methods of passing
# a time tuple or None work in addition to no argument.
st0 = os.stat(filename)
# Doesn't set anything new, but sets the time tuple way
utime(filename, (attr(st0, st_atime), attr(st0, st_mtime)))
# Setting the time to the time you just read, then reading again,
# should always return exactly the same times.
st1 = os.stat(filename)
self.assertEqual(attr(st0, st_mtime), attr(st1, st_mtime))
self.assertEqual(attr(st0, st_atime), attr(st1, st_atime))

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

[Trent Nelson]

Trent Nelson added the comment:

There doesn't appear to be on FreeBSD.  Although, on Solaris, -D__EXTENSIONS__ 
opens up access to utimensat() (at least on 11), so I'll factor that into 
configure.ac.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

[Trent Nelson]

Trent Nelson added the comment:

This patch (surprisingly) seems to do the job quite nicely:

diff -r 1280b38fe583 Lib/test/test_os.py
--- a/Lib/test/test_os.py   Tue Oct 16 23:14:03 2012 +1000
+++ b/Lib/test/test_os.py   Tue Oct 16 21:25:36 2012 +
@@ -40,6 +40,20 @@
 or (st.st_mtime != st[8])
 or (st.st_ctime != st[9]))
 
+try:
+import posix
+except ImportError:
+# Windows has nanosecond utime resolution.
+UTIME_EPSILON = 2e-9
+else:
+import sysconfig
+if 'HAVE_UTIMENSAT' in posix._have_functions:
+UTIME_EPSILON = 2e-9
+elif 'HAVE_UTIMES' in sysconfig.get_config_vars():
+UTIME_EPSILON = 2e-6
+else:
+UTIME_EPSILON = 1.0
+
 # Detect whether we're on a Linux system that uses the (now outdated
 # and unmaintained) linuxthreads threading library.  There's an issue
 # when combining linuxthreads with a failed execv call: see
@@ -312,18 +326,32 @@
 st0 = os.stat(filename)
 # Doesn't set anything new, but sets the time tuple way
 utime(filename, (attr(st0, st_atime), attr(st0, st_mtime)))
-# Setting the time to the time you just read, then reading again,
-# should always return exactly the same times.
 st1 = os.stat(filename)
-self.assertEqual(attr(st0, st_mtime), attr(st1, st_mtime))
-self.assertEqual(attr(st0, st_atime), attr(st1, st_atime))
+
+def _t(left, right, attr, name):
+l = attr(left, name)
+r = attr(right, name)
+if isinstance(l, int):
+assert isinstance(r, int)
+l = l / 1e9
+r = r / 1e9
+return abs(l - r)
+
+epsilon = UTIME_EPSILON
+self.assertLess(_t(st0, st1, attr, st_mtime), epsilon)
+self.assertLess(_t(st0, st1, attr, st_atime), epsilon)
+
 # Set to the current time in the old explicit way.
 os.utime(filename, None)
 st2 = os.stat(support.TESTFN)
 # Set to the current time in the new way
 os.utime(filename)
 st3 = os.stat(filename)
-self.assertAlmostEqual(attr(st2, st_mtime), attr(st3, st_mtime), 
delta=delta)
+self.assertAlmostEqual(
+attr(st2, st_mtime),
+attr(st3, st_mtime),
+delta=delta
+)
 
 def test_utime(self):
 def utime(file, times):


test_os passes on FreeBSD, Linux and Mac OS X with that applied.  However, the 
Solaris 10/SPARC box still fails:

AssertionError: 9.5367431640625e-07 not less than 2e-09

But it appears that build is actually picking up utimensat(), which makes the 
Solaris failures unrelated to the FreeBSD/NetBSD ones.  I'll do some more 
investigating.  Might warrant a separate issue.

Larry: thoughts on the test_os.patch as is?

--
keywords: +patch
Added file: http://bugs.python.org/file27599/test_os.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16257] test_socket.test_create_connection tests for wrong errno on Solaris

[Trent Nelson]

New submission from Trent Nelson:

==
FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
--
Traceback (most recent call last):
  File 
/home/cpython/buildslave/3.x.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/test/test_socket.py,
 line 4112, in test_create_connection
self.assertEqual(cm.exception.errno, errno.ECONNREFUSED)
AssertionError: 128 != 146

 errno.errorcode[128]
'ENETUNREACH'

Needs a Solaris-specific exception.

--
messages: 173123
nosy: trent
priority: normal
severity: normal
status: open
title: test_socket.test_create_connection tests for wrong errno on Solaris
versions: Python 3.2, Python 3.3, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16257
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16258] test_local.TestEnUSCollection failures on Solaris 10

[Trent Nelson]

New submission from Trent Nelson:

==
ERROR: test_strxfrm (test.test_locale.TestEnUSCollation)
--
Traceback (most recent call last):
  File 
/home/cpython/buildslave/3.x.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/test/test_locale.py,
 line 346, in test_strxfrm
self.assertLess(locale.strxfrm('a'), locale.strxfrm('b'))
ValueError: character U+101010e is not in range [U+; U+10]

==
ERROR: test_strxfrm_with_diacritic (test.test_locale.TestEnUSCollation)
--
Traceback (most recent call last):
  File 
/home/cpython/buildslave/3.x.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/test/test_locale.py,
 line 367, in test_strxfrm_with_diacritic
self.assertLess(locale.strxfrm('à'), locale.strxfrm('b'))
ValueError: character U+101010e is not in range [U+; U+10]

--

Haven't investigated yet.

--
messages: 173124
nosy: trent
priority: normal
severity: normal
status: open
title: test_local.TestEnUSCollection failures on Solaris 10
versions: Python 3.3, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16258
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

[Trent Nelson]

Trent Nelson added the comment:

Thanks for the feedback Larry; yeah that patch definitely wasn't intended to be 
production quality -- more of a proof of concept.  I agree with your points, 
they'll be factored into the next patch.

However, I'm absolutely baffled by the Solaris 10 failure.  The more I looked 
into it, the weirder it got.  The issue is always the same:

self.assertEqual(attr(st0, st_mtime), attr(st1, st_mtime))
AssertionError: 1347752941.275297 != 1347752941.275296

That is, test_utime() always results in a st1.st_mtime that is off-by-1 from 
st0.st_mtime.  The precision is well within the nanasecond resolution offered 
by utimensat, so it doesn't appear to be the same issue experienced by other 
platforms.

I'll have to break into the debugger again and see what's going on.

Side note: I noticed this comment/code just above _test_utime():

def test_utime_dir(self):
delta = 100
st = os.stat(support.TESTFN)
# round to int, because some systems may support sub-second
# time stamps in stat, but not in utime.
os.utime(support.TESTFN, (st.st_atime, int(st.st_mtime-delta)))
st2 = os.stat(support.TESTFN)
self.assertEqual(st2.st_mtime, int(st.st_mtime-delta))

That... seems to (albeit vaguely) describe what's going on here with Solaris 
10.  I also noticed support.TESTFN is actually a directory in this test case.  
Again, I'm not sure how that fits in with test_utime_dir() versus a second 
invocation of _test_utime(support.TESTFN) from test_utime().

test_utime_dir() is ultra-lax, test_utime() is ultra-strict, I'm not sure which 
one should be updated to match the other.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

[Trent Nelson]

Trent Nelson added the comment:

Oh, and another quirk I noticed yesterday.  I usually religiously disable 
atime on all my filesystems.  For whatever reason, it's not disabled on this 
Solaris 10 box.

Turns out os.stat() was updating st_atime, which kind of throws a spanner in 
the works for all our st_atime tests in _test_utime() -- we call os.stat() 
after utime() to check that our atime update worked -- but the stat call 
results in another st_atime update.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16235] Add python-config.sh for use during cross compilation.

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16235
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15298] _sysconfigdata is generated in srcdir, not builddir

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15298
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15298] _sysconfigdata is generated in srcdir, not builddir

[Trent Nelson]

Trent Nelson added the comment:

The previous 'alt_sysconfigdata.patch' didn't apply cleanly to 3.3/3.x.  I've 
attached an updated patch that does.

Any objections to applying this to 3.3 - 3.x now that the freeze is over?

--
versions: +Python 3.4
Added file: http://bugs.python.org/file27552/issue15298-alt_sysconfigdata2.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15298
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14774] _sysconfigdata.py doesn't support multiple build configurations

[Trent Nelson]

Trent Nelson added the comment:

I'm pretty sure this is a duplicate of http://bugs.python.org/issue15298 (which 
should be fixed shortly).

Feel free to re-open if I'm wrong.

--
nosy: +trent
resolution:  - duplicate
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14774
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15833] most failures to write byte-compiled file no longer suppressed

[Trent Nelson]

Trent Nelson added the comment:

FWIW, I just ran into the following on Solaris 10:

% dbx python
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your .dbxrc
Reading python
Reading ld.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libintl.so.1
Reading librt.so.1
Reading libdl.so.1
Reading libsendfile.so.1
Reading libm.so.2
Reading libthread.so.1
Reading libc.so.1
Reading libaio.so.1
Reading libmd.so.1
(dbx) run
Running: python 
(process id 17819)
Reading libc_psr.so.1
Could not find platform dependent libraries exec_prefix
Consider setting $PYTHONHOME to prefix[:exec_prefix]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
Traceback (most recent call last):
  File frozen importlib._bootstrap, line 1558, in _find_and_load
  File frozen importlib._bootstrap, line 1525, in _find_and_load_unlocked
  File frozen importlib._bootstrap, line 586, in _check_name_wrapper
  File frozen importlib._bootstrap, line 1023, in load_module
  File frozen importlib._bootstrap, line 1004, in load_module
  File frozen importlib._bootstrap, line 562, in module_for_loader_wrapper
  File frozen importlib._bootstrap, line 854, in _load_module
  File frozen importlib._bootstrap, line 990, in get_code
  File frozen importlib._bootstrap, line 1051, in _cache_bytecode
  File frozen importlib._bootstrap, line 1065, in set_data
OSError: [Errno 30] Read-only file system: 
'/home/cpython/nfs/src/3.x/Lib/encodings/__pycache__'
t@1 (l@1) signal ABRT (Abort) in __lwp_kill at 0x7e2dc2c0
0x7e2dc2c0: __lwp_kill+0x0008:  bcc,a,pt  %icc,__lwp_kill+0x18  ! 
0x7e2dc2d0
Current function is Py_FatalError
 2360   abort();
(dbx) q 
q: not found
(dbx) quit


Testing the 'import_error.diff' patch now...

--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15833
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15833] most failures to write byte-compiled file no longer suppressed

[Trent Nelson]

Trent Nelson added the comment:

That... didn't work.  Also applied rpetrov's patch and that made no difference:

% ./python Could not find platform dependent libraries exec_prefix
Consider setting $PYTHONHOME to prefix[:exec_prefix]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
Traceback (most recent call last):
  File frozen importlib._bootstrap, line 1558, in _find_and_load
  File frozen importlib._bootstrap, line 1525, in _find_and_load_unlocked
  File frozen importlib._bootstrap, line 586, in _check_name_wrapper
  File frozen importlib._bootstrap, line 1023, in load_module
  File frozen importlib._bootstrap, line 1004, in load_module
  File frozen importlib._bootstrap, line 562, in module_for_loader_wrapper
  File frozen importlib._bootstrap, line 854, in _load_module
  File frozen importlib._bootstrap, line 990, in get_code
  File frozen importlib._bootstrap, line 1051, in _cache_bytecode
  File frozen importlib._bootstrap, line 1065, in set_data
OSError: [Errno 30] Read-only file system: 
'/home/cpython/nfs/src/3.x/Lib/encodings/__pycache__'
zsh: IOT instruction (core dumped)  ./python

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15833
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15833] most failures to write byte-compiled file no longer suppressed

[Trent Nelson]

Trent Nelson added the comment:

Charles: your patch is fine.  +1.

My Solaris failures can be traced back to http://bugs.python.org/issue15819.  
Sorry for the noise.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15833
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15298] _sysconfigdata is generated in srcdir, not builddir

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


Removed file: 
http://bugs.python.org/file27552/issue15298-alt_sysconfigdata2.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15298
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16136] Removal of VMS support

[Trent Nelson]

Trent Nelson added the comment:

FWIW, I have another Itanium box that I've earmarked for OpenVMS.  I don't 
believe the installation media is readily available for free, though, so I'd 
need to ping HP to try arrange a copy.

--
nosy: +trent

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16136
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16002] AIX buildbot compile errors

[Trent Nelson]

Trent Nelson added the comment:

Hi Stefan, quick question: how did you invoke ./configure on the AIX box?  The 
reason for asking is that a7/arsenic is a little quirky, you need to run a zsh 
subroutine via `_xlc 12` to set up the right CC env (see 
~/buildslave/start.zsh).

Once you've done that, you need ./configure --without-gcc --with-pydebug to get 
the same environment as the build slave.

(I haven't set up a buildslave for gcc on that box.)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16002
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

[Trent Nelson]

Changes by Trent Nelson tr...@snakebite.org:


--
title: Numerous utime ns tests fail on FreeBSD w/ ZFS - Numerous utime ns 
tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al).

[Trent Nelson]

New submission from Trent Nelson:

Gripe: if you want a 64-bit, non-gcc (i.e. vendor's cc) build on a proprietary 
UNIX system (i.e. Solaris, HP-UX, AIX etc), you're going to have a bad time.

Coercing a 64-bit build from a vendor's cc currently requires explicit 
CFLAGS/LDFLAGS/configure gymnastics for each platform.  It's a pain.

Initial goal: use this issue to document the gymnastics.

Assumption: once all the different techniques are documented, it'll be easier 
to assess what changes would be appropriate to configure.in.

Side bar design question: on BSD/Linux/OSX w/ gcc/clang, if you're on an amd64 
platform, you'll get a 64-bit build.  This isn't the case for Solaris, HP-UX 
and AIX -- the default is always 32-bit.  You need aforementioned gymnastics to 
coerce a 64-bit build.

Is this by design?  If so, then I guess I'm proposing that ./configure should 
have a `--with-64`-type argument that'll generate a 64-bit build.

If not, then we need to decide whether to change the default behavior such that 
./configure always generates a 64-bit build if you're on a 64-bit platform -- 
if you want a 32-bit build, you need to explicitly tell ./configure (i.e. 
--with-32).

Changing the default is probably only viable for 3.4 onwards.  It'd be nice if 
2.7-3.3 had generic configure support for 64-bit builds though (via --with-64).

XXX TODO for trent: review autoconf's offerings... getting 64-bit builds from 
vendor cc's can't be that unusual.

--
assignee: trent
components: Build
messages: 170643
nosy: trent
priority: low
severity: normal
status: open
title: Improve ./configure's support for 32/64-bit debug|release|profiled 
builds w/ vendor (non-gcc) compilers on proprietary UNIX systems 
(Solaris/HP-UX/AIX et al).
type: enhancement
versions: Python 2.7, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15963
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al).

[Trent Nelson]

Trent Nelson added the comment:

On the s10 slave (Solaris 10/nitrogen) for 3.x:

(cpython@nitrogen:ttypts/4) (Tue/12:32) ..  

   
% ../../src/configure --with-pydebug --without-gcc CFLAGS=-m64 -mt 
-xcheck=%all -g3 -xarch=native -xchip=native CPPFLAGS=-IInclude OPT= 
LDFLAGS=-m64 -mt -xcheck=%all -g3 -xarch=native -xchip=native 
CC=/opt/solarisstudio12.3/bin/cc

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15963
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15965] AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings.

[Trent Nelson]

New submission from Trent Nelson:

On Solaris (s10/nitrogen):


% find /usr/include -type f | xargs fgrep -ni AT_FDCWD
/usr/include/sys/fcntl.h:320:#defineAT_FDCWD
0xffd19553

(AIX uses -2, FreeBSD uses -100.)

Anyway, that results in:


(cpython@nitrogen:ttypts/10) (Tue/15:34) .. 

(~/hg/3.x.trent/build/release)
% touch ../../src/Modules/posixmodule.c 
(cpython@nitrogen:ttypts/10) (Tue/15:34) .. 

(~/hg/3.x.trent/build/release)
% time /usr/ccs/bin/make 
/opt/solarisstudio12.3/bin/cc  -DNDEBUG -v -m64 -mt=yes -xbuiltin -xhwcprof -xF 
-xarch=native -xchip=native -fast -fma=fused -g -xO4 -library=sunperf   -I. 
-I../../src/Include -IInclude   -DPy_BUILD_CORE  -c 
../../src/Modules/posixmodule.c -o Modules/posixmodule.o
../../src/Modules/posixmodule.c, line 2307: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 2337: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 2386: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 2626: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 2966: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 3198: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 3199: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 3845: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 3989: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 3990: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 4111: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 4267: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 4587: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 7007: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 7092: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 7510: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 8260: warning: initializer does not fit 
or is out of range: 0xffd19553
../../src/Modules/posixmodule.c, line 8322: warning: initializer does not fit 
or is out of range: 0xffd19553
^C
*** Modules/posixmodule.o removed.
/usr/ccs/bin/make  2.79s user 0.28s system 46% cpu 6.598 total

In every case, the affected line is:

int dir_fd = DEFAULT_DIR_FD;

(DEFAULT_DIR_FD defaults to AT_FDCWD if it's defined.)

Note that Solaris 10 64-bit is LP64, ints are still 32-bit.

--
assignee: trent
components: Build
messages: 170648
nosy: trent
priority: normal
severity: normal
stage: needs patch
status: open
title: AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings.
type: compile error

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15965
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15965] AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings.

[Trent Nelson]

Trent Nelson added the comment:

Easy fix, cast AT_FDCWD to (int):


% hg diff
diff -r 3a880d640981 Modules/posixmodule.c
--- a/Modules/posixmodule.c Tue Sep 18 07:21:18 2012 +0300
+++ b/Modules/posixmodule.c Tue Sep 18 16:04:58 2012 +
@@ -414,7 +414,14 @@
 
 
 #ifdef AT_FDCWD
-#define DEFAULT_DIR_FD AT_FDCWD
+/*
+ * Why the (int) cast?  Solaris 10 defines AT_FDCWD as 0xffd19553 (-3041965);
+ * without the int cast, the value gets interpreted as uint (4291925331),
+ * which doesn't play nicely with all the initializer lines in this file that
+ * look like this:
+ *  int dir_fd = DEFAULT_DIR_FD;
+ */
+#define DEFAULT_DIR_FD (int)AT_FDCWD
 #else
 #define DEFAULT_DIR_FD (-100)
 #endif


The cast is harmless on other platforms that use an actual integer (rather than 
a hex representation).

Any objections?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15965
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2286] Stack overflow exception caused by test_marshal on Windows x64

[Trent Nelson]

Trent Nelson added the comment:

Closing issue; this has been fixed.

--
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2286
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al).

[Trent Nelson]

Trent Nelson added the comment:

Solaris 10 release (i.e. optimized) build requires the following:

../../src/configure --without-gcc CFLAGS=-v -fsimple=0 -m64 -mt=yes -xbuiltin 
-xhwcprof -xF -xarch=native -xchip=native -fma=fused -g -xO5 -xlibmil -xlibmopt 
-xmemalign=8s -xregs=frameptr -xtarget=native -xbuiltin=%all -library=sunperf 
CPPFLAGS=-IInclude OPT= LDFLAGS=-v  -fsimple=0 -m64 -mt=yes -xbuiltin 
-xhwcprof -xF -xarch=native -xchip=native -fma=fused -g -xO5 -xlibmil -xlibmopt 
-xmemalign=8s -xbuiltin=%all -xregs=frameptr -xtarget=native -library=sunperf 
CC=/opt/solarisstudio12.3/bin/cc 

(Due to indirect linker invocation via cc, I'm purposely duplicating CFLAGS - 
LDFLAGS for now.  I'll refine later.)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15963
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15967] Slaves don't seem to clean up their /tmp mess if a step fails.

[Trent Nelson]

New submission from Trent Nelson:

All my slaves' /tmp's are polluted with regrtest fluff.  I haven't checked yet, 
but I presume no cleanup is done if a test/run fails.

nitrogen% find /tmp -user cpython 2 /dev/null | wc -l
197
netbsd51-x64-1$ find /tmp -user cpython 2 /dev/null | wc -l
 142
oxygen% find /tmp -user cpython 2 /dev/null | wc -l
456

Placeholder issue until it annoys me enough to patch.

--
assignee: trent
components: Build
messages: 170663
nosy: trent
priority: normal
severity: normal
status: open
title: Slaves don't seem to clean up their /tmp mess if a step fails.
type: behavior

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15967
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com