Trent Nelson added the comment:
Hm... tested against other types of file systems and didn't see any issues.
Tested manually against ZFS again:
% ~/src/cpython/python /tmp/test_readlink.py
temp dir: /mnt/t-zfs/trent/d_6i51
path 1: /mnt/t-zfs/trent/d_6i51/qux, length 1: 27,
Trent Nelson added the comment:
Looks like it's not specific to just FreeBSD, no ZFS. From a new NetBSD slave
I set up:
==
FAIL: test_futimes_ns (test.test_os.StatAttribute
New submission from Trent Nelson:
The 2.7 builds of both my NetBSD slaves keep hanging on test_posix (and
eventually time out after an hour). Running the test manually:
netbsd51-x86-1$ pwd
/home/cpython/2.7
netbsd51-x86-1$ b/test/regrtest.py -uall -rwW -v test_posix
Trent Nelson added the comment:
Reproduced behaviour with test_readlink.sh. Sending an e-mail to freebsd-fs to
see what they think.
--
Added file: http://bugs.python.org/file26979/test_readlink.sh
___
Python tracker
<http://bugs.python.
Trent Nelson added the comment:
Link to my freebsd-fs e-mail:
http://lists.freebsd.org/pipermail/freebsd-fs/2012-August/014964.html
--
___
Python tracker
<http://bugs.python.org/issue15
Trent Nelson added the comment:
Hacked the test to print out info each loop:
test_getcwd_long_pathnames (test.test_posix.PosixTester) ... [0/0]
getcwd-test-directory-0123456789abcdef-01234567890abcdef
[1/57] getcwd-test-directory-0123456789abcdef-01234567890abcdef
[2/114] getcwd-test
Trent Nelson added the comment:
Looks like this is a duplicate of issue 9185. The fix used for that just needs
to be extended to cover NetBSD as well. See proposed patch. I'll commit this
to 2.7 in a day or two if there are no objections.
Antoine: added you as nosy as you were inv
Changes by Trent Nelson :
--
nosy: +trent
___
Python tracker
<http://bugs.python.org/issue9860>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Trent Nelson :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15765>
___
___
Python-bugs-list mailing list
Unsubscri
New submission from Trent Nelson:
This is somewhat related to Issue #9860. You can't currently build Python
out-of-tree when the source directory is readonly. This is because there are a
few Parser/pgen/AST/python_asdl.py steps that try and write to $(srcdir).
The attached patch fixes
Changes by Trent Nelson :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue15819>
___
___
Python-bugs-list mailing list
Un
Trent Nelson added the comment:
Hm. Now I'm confused. Is this what you meant?
---
% hg diff
diff -r 019a2390b014 Makefile.pre.in
--- a/Makefile.pre.in Tue Aug 21 23:41:43 2012 +
+++ b/Makefile.pre.in Thu Aug 30 07:16:55 2012 +
@@ -43,6 +43,8 @@
Trent Nelson added the comment:
That's what I figured you meant initially... Until I couldn't find any MKDIR_P
definitions, and couldn't get it working without the hack above.
I thought it might be an implicit make variable as well, but, not so much.
(Tested with BSD ma
Trent Nelson added the comment:
Ah, I see the MKDIR_P changes in 3.x/configure as well.
Objections to backporting to 3.2?
Is 2.7 off the table?
(Building from a readonly source is handy for Snakebite; saves having a dozen
machines needing to use their own hg clone
Changes by Trent Nelson :
--
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15819>
___
___
Trent Nelson added the comment:
FWIW, `make patchcheck` fails for me as follows:
% make patchcheck
./python /home/trent/hg/cpython-3.2/Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... abort: no repository
found in '/tmp/cpython-3.2-build' (.hg
Trent Nelson added the comment:
Well, that escalated quickly :-)
I think I should clarify my use case that resulted in raising this bug.
1. Create a fresh hg clone, say, ~/hg/cpython-3.2.
2. Make it readonly: `zfs set readonly=on tank/home/cpython/hg/cpython-3.2`
3. cd /tmp/cpython-3.2-build
4
Trent Nelson added the comment:
Turns out our unit test uncovered a very subtle corner-case bug in ZFS,
requiring the following patch to FreeBSD:
a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c
b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c
index 69374fb..7f61517 100644
--- a/sys
New submission from Trent Nelson:
Building on HP-UX with the HP ANSI C compiler:
% make
cc -Ae -c -O -O -I. -I./Include-DPy_BUILD_CORE -o
Python/pythonrun.o Python/pythonrun.c
"Python/pythonrun.c", line 805: error #2020: identifier
Trent Nelson added the comment:
> Since the committed patch is already a step in that direction,
> I think it now needs to be completed. It's mandatory (IMO)
> that the generated files are actually used; that the generators
> are not run if not needed is optional and can be fix
Trent Nelson added the comment:
Not really... the problem is that the chmod 0007 actually corrupts the ZFS
metadata regarding the symlink by always setting the length to 24.
Andriy did some debugging here:
http://lists.freebsd.org/pipermail/freebsd-fs/2012-August/015005.html
So, the link
Trent Nelson added the comment:
Link to discussion (initiated by Andriy) on z...@lists.illumos.org:
http://thread.gmane.org/gmane.os.illumos.zfs/69
--
___
Python tracker
<http://bugs.python.org/issue15
Changes by Trent Nelson :
--
nosy: +trent
___
Python tracker
<http://bugs.python.org/issue15923>
___
___
Python-bugs-list mailing list
Unsubscribe:
Trent Nelson added the comment:
Just noticed that the Solaris 10 slave is failing in the same way:
==
FAIL: test_utime (test.test_os.StatAttributeTests
Changes by Trent Nelson :
--
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
<http://bugs.python.org/issu
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
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
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
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
Trent Nelson added the comment:
Closing issue; this has been fixed.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue2286>
___
___
Py
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=fra
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&
Changes by Trent Nelson :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15965>
___
___
Python-bugs-list
Trent Nelson added the comment:
> > All my slaves' /tmp's are polluted with regrtest fluff.
> Which "regrtest fluff" exactly?
I was being lazy when I wrote that. By "regrtest fluff" I was referring to
lingering files/directories in /tmp, owned by cpyt
Trent Nelson added the comment:
> Cleanup on test failure is supposed to be done. Cleanup on crash or
> buildbot timeout isn't done as far as I know (and that was a concern I
> had with the changes made to support.TESTFN and the cwd, but I didn't
> articulate it very we
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
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.
Changes by Trent Nelson :
--
nosy: +trent
___
Python tracker
<http://bugs.python.org/issue15298>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
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
__
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
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
Consider setting $PYTHONHOME to [:]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
Traceback (m
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
<http://bugs.python.org/issue15
Changes by Trent Nelson :
Removed file:
http://bugs.python.org/file27552/issue15298-alt_sysconfigdata2.patch
___
Python tracker
<http://bugs.python.org/issue15
Changes by Trent Nelson :
--
nosy: +trent
___
Python tracker
<http://bugs.python.org/issue16235>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.pyth
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
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
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
<http://bu
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
New submission from Trent Nelson:
==
FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
--
Traceback (most recent call last):
File
New submission from Trent Nelson:
==
ERROR: test_strxfrm (test.test_locale.TestEnUSCollation)
--
Traceback (most recent call last):
File
"/home/cp
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
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
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_pl
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.s
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 whet
Changes by Trent Nelson :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue16257>
___
___
Python-bugs-list
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 s
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 bein
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&#
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/L
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
` instead of the system one in /usr/include.
In my case, this was happening because I had set
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
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
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
<http://bugs.pytho
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:
Trent Nelson added the comment:
Patch applied and everything passes, so closing for now.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
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
<http://bugs.python.o
Changes by Trent Nelson :
--
nosy: +trent
___
Python tracker
<http://bugs.python.org/issue1516>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
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 ru
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
Changes by Trent Nelson :
--
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
<http://bugs.python.org/issu
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
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:
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"), a
Changes by Trent Nelson :
--
nosy: +larry, pitrou
___
Python tracker
<http://bugs.python.org/issue16287>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Changes by Trent Nelson :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue16274>
___
___
Python-bugs-list mailing list
Unsubscri
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 lo
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/te
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:
Trent Nelson added the comment:
We avoided this by adding -u-audio to the affected slave.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Changes by Trent Nelson :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue16274>
___
___
Python-bugs-list
Changes by Trent Nelson :
--
nosy: +trent
___
Python tracker
<http://bugs.python.org/issue9742>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 suggeste
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 inter
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
Changes by Trent Nelson :
--
nosy: +trent
___
Python tracker
<http://bugs.python.org/issue2005>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 wi
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
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
> (re
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:/
Changes by Trent Nelson :
--
nosy: +trent
___
Python tracker
<http://bugs.python.org/issue10052>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Changes by Trent Nelson :
--
nosy: +brian.curtin
___
Python tracker
<http://bugs.python.org/issue16668>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.python.o
101 - 200 of 220 matches
Mail list logo
