[issue2850] Augmenting the Windows build to support code signing.
New submission from Trent Nelson <[EMAIL PROTECTED]>: Now that we've finally got a VeriSign code-signing certificate (hurrah!), we can look at how we want to integrate the aspect of code signing into our build process. I'd like to propose augmenting the build process such that as a post- link step for .exe|.pyd targets, a little helper Python code signing script will be run (i.e. trunk/pcbuild/signfile.py). The first thing that this script will check is whether or not the environment variable PYTHON_CODESIGNING_CERT_NAME is defined. If it is not defined or is empty, the script will simply exit. This will be the case for the vast majority of users. However, if the environment variable exists, it indicates to the signfile.py script that the target .exe|.pyd should be signed, using the identifier specified by the environment variable, with Microsoft's code-signing facilities (signtool.exe etc). The net effect is that if a user has a valid code-signing certificate installed, they can get the standard Python build system to automatically sign all binaries by setting this environment variable. I think this approach is more useful than, say, having Martin manually sign each binary when it comes to release time, as it is automated (and as such, less error prone), and can be leveraged by anyone wishing to create signed Python distributions, not just the PSF (i.e. ActiveState, Enthought, etc). Assuming there are no objections to this proposal, a couple of other things I'll provide: a) documentation on both what's required in order to produce a signed distribution, as well as guidelines for other companies wishing to obtain code-signing certificates for the purposes of signing their custom Python distributions (perhaps better suited to a wiki entry) b) a helper script in pcbuild/ that can a) augment existing .vcprojs and add the post-link signing step, and b) be run in such a way that it checks all existing .vcprojs for .exe|.pyd targets have the post-link event correctly configured Comments/objections? Trent. -- assignee: Trent.Nelson components: Build messages: 66814 nosy: Trent.Nelson, loewis, tmick priority: normal severity: normal status: open title: Augmenting the Windows build to support code signing. type: feature request versions: Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2850> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2887] bsddb3 needs to be ported to Python 3.0
Trent Nelson <[EMAIL PROTECTED]> added the comment: FWIW, I bumped the version of Berkeley DB being used on Windows from 4.4.20 to 4.7.25 in r64555 (trunk). I blocked this from being merged to py3k. This block should be removed once bsddb has been updated. -- nosy: +Trent.Nelson ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2887> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3373] sys recursion limit a lot shorter on trunk?
Trent Nelson <[EMAIL PROTECTED]> added the comment: Darryl, was your trunk version built as debug? If so, can you try without? -- nosy: +Trent.Nelson ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3373> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3270] test_multiprocessing: test_listener_client flakiness
Trent Nelson <[EMAIL PROTECTED]> added the comment: Jesse, thanks for capturing my e-mail thread in this issue. Can you comment on my last three paragraphs? Essentially, I think we should lock down the API and assert that Listener.address will always be a 'connectable' end-point. (i.e. not a wildcard host, 0.0.0.0, that can't be bound to by a socket, for example) This would mean raising an exception in Listener.__init__ if this invariant is violated. -- nosy: +Trent.Nelson ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3270> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3270] test_multiprocessing: test_listener_client flakiness
Trent Nelson <[EMAIL PROTECTED]> added the comment: I can confirm the patch works in Windows. Regarding the 0.0.0.0 issue, perhaps we can compromise on something like this: % svn diff connection.py Index: connection.py === --- connection.py (revision 65645) +++ connection.py (working copy) @@ -217,6 +217,8 @@ self._socket.bind(address) self._socket.listen(backlog) self._address = self._socket.getsockname() +if self._address[0] == '0.0.0.0': +self._address[0] = '127.0.0.1' self._family = family self._last_accepted = None That way, we still support binding on all addresses, and self._address will always represent a connectable end-point. Thoughts? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3270> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3270] test_multiprocessing: test_listener_client flakiness
Trent Nelson <[EMAIL PROTECTED]> added the comment: I was thinking about this on the way home last night and concluded that my last suggestion (s/0.0.0.0/127.0.0.1/) is a terrible one as well. I'd be happy with a mention in the documentation (for now) stating that if you listen on '0.0.0.0', Listener._address won't be a connectable end-point (and you'll have to explicitly connect to 127.0.0.1, for example). As for the original issue, Jesse I'm +1 on your connection_v2.patch. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3270> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8576] test_support.find_unused_port can cause socket conflicts on Windows
Trent Nelson added the comment: I introduced test_support.find_unused_port in r62234, as part of a general refactoring of client/server network-oriented tests. The only reason I introduced this method at the time was because the SSL tests used to launch openssl in server mode, which required a port to be specified as part of the command line. Pure Python tests shouldn't use this method, as noted in the docstring, they should use bind_port(), which takes platform socket-oddities into account. I'm not sure if I agree that find_unused_port() should be removed though; it does serve a purpose in very rare corner cases. Perhaps it should be renamed to _find_unused_port() to discourage accidental usage. (I'd recommend reviewing r62234's commit log and change set for more info.) -- nosy: +trent ___ Python tracker <http://bugs.python.org/issue8576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8.
New submission from Trent Nelson: posix_tmpfile() needs to be reworked such that tmpfile() isn't used if MS_WINDOWS is defined, as it requires administrative privileges to run (it creates the file in the root directory) on Vista/2k8 (although there are reports of this not working on XP w/ 2.5: http://www.thescripts.com/forum/thread600423.html). The recommended approach in MSDN is to use, quote, "tmpname or tempnam in conjunction with fopen": http://msdn2.microsoft.com/en- us/library/x8x7sakw(VS.80).aspx Assuming no one beats me to it, I'll look at creating a patch in the next day or two when I get some spare time. -- components: Windows messages: 63254 nosy: Trent.Nelson severity: normal status: open title: Current os.tmpfile() implementation requires admin privs on Vista/2k8. type: behavior versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2232> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8.
Trent Nelson added the comment:
With Chris and Ben's comments taken into account, what's the best way to
handle this?
1. Change the test: if the user is not admin, assert os.tmpfile()
returns a permission denied OSError, otherwise, assert return value is
a current file.
2. Alter posix_tmpfile() to warn the user of the situation if the call
fails and we're on Windows:
Index: posixmodule.c
===
--- posixmodule.c (revision 61233)
+++ posixmodule.c (working copy)
@@ -7029,8 +7029,15 @@
FILE *fp;
fp = tmpfile();
-if (fp == NULL)
+if (fp == NULL) {
+#ifdef MS_WINDOWS
+PyErr_Warn(PyExc_RuntimeWarning,
+ "tmpfile creates a file in the root directory and " \
+ "requires administrative privileges, consider using " \
+ "tempfile.mkstemp() instead");
+#endif
return posix_error();
+}
return PyFile_FromFile(fp, "", "w+b", fclose);
}
#endif
3. Alter posix_tmpfile() to use _tempnam() on Windows instead, such
admin privileges are no longer required. (Possibly adding a similar
warning that tempfile.mkstemp should be used instead though, as above?)
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2232>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8.
Trent Nelson added the comment:
I agree. Following patch fixes the issue for me:
Index: test_os.py
===
--- test_os.py (revision 61260)
+++ test_os.py (working copy)
@@ -65,6 +65,44 @@
def test_tmpfile(self):
if not hasattr(os, "tmpfile"):
return
+# As with test_tmpnam() below, the Windows implementation of
tmpfile()
+# attempts to create a file in the root directory of the
current drive.
+# On Vista and Server 2008, this test will always fail for
normal users
+# as writing to the root directory requires elevated
privileges. With
+# XP and below, the semantics of tmpfile() are the same, but
the user
+# running the test is more likely to have administrative
privileges on
+# their account already. If that's the case, then os.tmpfile
() should
+# work. In order to make this test as useful as possible,
rather than
+# trying to detect Windows versions or whether or not the user
has the
+# right permissions, just try and create a file in the root
directory
+# and see if it raises a 'Permission denied' OSError. If it
does, then
+# test that a subsequent call to os.tmpfile() raises the same
error. If
+# it doesn't, assume we're on XP or below and the user running
the test
+# has administrative privileges, and proceed with the test as
normal.
+if sys.platform == 'win32':
+name = '\\python_test_os_test_tmpfile.txt'
+if os.path.exists(name):
+os.remove(name)
+try:
+fp = open(name, 'w')
+except IOError, first:
+# open() failed, assert tmpfile() fails in the same
way.
+# Although open() raises an IOError and os.tmpfile()
raises an
+# OSError(), 'args' will be (12, 'Permission denied')
in both
+# cases.
+try:
+fp = os.tmpfile()
+except OSError, second:
+self.assertEqual(first.args, second.args)
+else:
+self.fail("expected os.tmpfile() to raise OSError")
+return
+else:
+# open() worked, therefore, tmpfile() should work.
Close our
+# dummy file and proceed with the test as normal.
+fp.close()
+os.remove(name)
+
fp = os.tmpfile()
fp.write("foobar")
fp.seek(0,0)
--
keywords: +patch
Added file: http://bugs.python.org/file9616/test_os.py.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2232>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8.
Trent Nelson added the comment: Er, errno being referred to in a comment in that last patch should be 13, not 12. Added file: http://bugs.python.org/file9617/test_os.py.2.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2232> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2284] [PATCH] -x64 option added to pcbuild/rt.bat to facilitate testing of amd64\python[_d].exe.
New submission from Trent Nelson <[EMAIL PROTECTED]>: Looks like there's been a recent change to trunk such that x64 Windows builds now get placed in pcbuild\amd64 instead of just pcbuild (thanks to whoever added it). The attached patch against rt.bat allows it to be called with an -x64 arg, which invokes the 64-bit Python build, instead of the 32-bit one. (tools/buildbot/test-amd64.bat should eventually be created to call this as well, once we've ironed out all the Windows x64 issues.) -- components: Build files: rt.bat.patch keywords: patch messages: 63520 nosy: Trent.Nelson severity: normal status: open title: [PATCH] -x64 option added to pcbuild/rt.bat to facilitate testing of amd64\python[_d].exe. type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file9670/rt.bat.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2284> __ ___ 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
New submission from Trent Nelson <[EMAIL PROTECTED]>: S:\src\svn\svn.python.org\projects\python\trunk.x64\PCbuild>amd64\python_d ..\lib\test\test_marshal.py test_bool (__main__.IntTestCase) ... ok test_int64 (__main__.IntTestCase) ... ok test_ints (__main__.IntTestCase) ... ok test_floats (__main__.FloatTestCase) ... ok test_buffer (__main__.StringTestCase) ... ok test_string (__main__.StringTestCase) ... ok test_unicode (__main__.StringTestCase) ... ok test_code (__main__.CodeTestCase) ... ok test_dict (__main__.ContainerTestCase) ... ok test_list (__main__.ContainerTestCase) ... ok test_sets (__main__.ContainerTestCase) ... ok test_tuple (__main__.ContainerTestCase) ... ok test_exceptions (__main__.ExceptionTestCase) ... ok test_bug_5888452 (__main__.BugsTestCase) ... ok test_exact_type_match (__main__.BugsTestCase) ... ok test_fuzz (__main__.BugsTestCase) ... ok test_loads_recursion (__main__.BugsTestCase) ... ^^^ python_d.exe crashes at this point with a stack overflow. Just capturing the issue for now. Will investigate shortly and hopefully provide a patch. -- components: Tests messages: 63523 nosy: Trent.Nelson severity: normal status: open title: Stack overflow exception caused by test_marshal on Windows x64 type: crash versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2286> __ ___ 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 <[EMAIL PROTECTED]> added the comment:
Traced the problem down to the following minimal code snippet:
import marshal
s = 'c' + ('X' * 4*4) + '{' * 2**20
marshal.loads(s)
When Python/marshal.c:18 MAX_MARSHAL_STACK_DEPTH is 2000 (which is what
it is currently), marshal.loads() eventually overflows the stack in
r_object(). There is a check in r_object() to avoid this though:
if (p->depth > MAX_MARSHAL_STACK_DEPTH) {
p->depth--;
PyErr_SetString(PyExc_ValueError, "recursion limit exceeded");
return NULL;
}
On Windows x64, a value of 1964 raises the recursion limit exception
above (which is what test_marshal is expecting). With a value of 1965,
a C stack overflow exception is raised.
So, MAX_MARSHAL_STACK_DEPTH needs to be <= 1964 in order to prevent this
particular code from overflowing the stack on Win64 before we can raise
a Python recursion limit exception.
Was there any science behind choosing 2000 as the current value? Should
a new value (e.g. 1500) be provided for only Win64, leaving everyone
else at 2000? Interesting that Linux/BSD etc on AMD64 don't run into this.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2286>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2290] [PATCH] Update Lib/distutils/sysconfig.py to handle x64 Windows builds living in pcbuild/amd64.
New submission from Trent Nelson <[EMAIL PROTECTED]>: This patch is required in order to support x64 Windows builds that live in pcbuild/amd64. Without it, sysutils._python_build() returns the wrong directory, which causes the test_get_config_h_filename method in Lib/distutils/tests/test_sysconfig.py to fail. -- components: Library (Lib) files: sysconfig.py.patch keywords: patch messages: 63537 nosy: Trent.Nelson severity: normal status: open title: [PATCH] Update Lib/distutils/sysconfig.py to handle x64 Windows builds living in pcbuild/amd64. type: behavior versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9671/sysconfig.py.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2290> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2290] [PATCH] Update Lib/distutils/sysconfig.py to handle x64 Windows builds living in pcbuild/amd64.
Trent Nelson <[EMAIL PROTECTED]> added the comment: Ah, I suspect not. (Unless the 64-bit python*.exe builds end up in pcbuild/amd64.) -- versions: -Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2290> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2296] [PATCH] Tcl/Tk 8.4.16 patches needed to get an x64 Windows build
New submission from Trent Nelson <[EMAIL PROTECTED]>: Martin, I've attached two patches required in order to get Tcl/Tk 8.4.16 to successfully compile on Windows x64. I haven't included the patch to external-amd64.bat (and pcbuild/readme.txt with updated build instructions) yet as I wanted to confirm how you apply updates to the external/ branch such that the buildbots can pick it up as well. Note that I also dropped a generic standalone sed.exe into tk-8.4.16/win, which is required for reasons that I couldn't be bothered digging into in makefile.vc. You can grab it from http://svn.onresolve.com/external/tags/tcl-8.4.18.1/win/sed.exe. Also, wanted to query the role of 'COMPILERFLAGS=-DWINVER=0x0500' in your recommended nmake flags; do we still need it? I used the following for x64 debug builds: ..\tcl8.4.16\win>nmake -f makefile.vc DEBUG=1 MACHINE=AMD64 INSTALLDIR=../../tcltk64 clean all install And for tk: ..\tk8.4.16\win>nmake -f makefile.vc DEBUG=1 MACHINE=AMD64 TCLDIR=../../tcl8.4.16 INSTALLDIR=../../tcltk64 clean all install Let me know how you want to deal with the tcl/tk patches and then we can look at fixing external-amd64.bat and updating pcbuild/readme.txt. -- components: Tkinter files: tk-8.4.16.patch keywords: patch messages: 63566 nosy: Trent.Nelson, loewis severity: normal status: open title: [PATCH] Tcl/Tk 8.4.16 patches needed to get an x64 Windows build versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9676/tk-8.4.16.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2296> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2296] [PATCH] Tcl/Tk 8.4.16 patches needed to get an x64 Windows build
Trent Nelson <[EMAIL PROTECTED]> added the comment: And the tcl patch... Added file: http://bugs.python.org/file9677/tcl-8.4.16.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2296> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2296] [PATCH] Tcl/Tk 8.4.16 patches needed to get an x64 Windows build
Trent Nelson <[EMAIL PROTECTED]> added the comment: Oh, another question, do we use tix for anything anymore? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2296> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2297] Patch for fatal stack overflow in Windows caused by -v
Trent Nelson <[EMAIL PROTECTED]> added the comment: Any chance of getting a test case that demonstrates this? I'll happily test the patch if there's an associated test case I can run to assert before/after behaviour. -- nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2297> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2297] Patch for fatal stack overflow in Windows caused by -v
Trent Nelson <[EMAIL PROTECTED]> added the comment: +1, tested on x86 XP and x64 2k8. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2297> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue719888] tokenize module w/ coding cookie
Trent Nelson <[EMAIL PROTECTED]> added the comment: I've attached a patch to test_tokenizer.py and a bunch of text files (that should be dropped into Lib/test) that highlight this issue a *lot* better than the current state of affairs. The existing implementation defines roundup() in the doctest, then proceeds to define it again in the code body. The last for loop in the doctest is failing every so often -- what it's failing on isn't at all clear as a) ten random files are selected out of 332 in Lib/test, and b) there's no way of figuring out which files are causing it to fail unless you hack another method into the test case to try and replicate what the doctest is doing, with some additional print statements (which is the approach I took, only to get bitten by the fact that roundup() was being resolved to the bogus definition that's in the code body, not the functional one in the doctest, which resulted in even more misleading behaviour). FWIW, the file that causes the exception is test_doctest2.py as it contains encoded characters. So, the approach this patch takes is to drop the 'pick ten random test files and untokenize/tokenize' approach and add a class that specifically tests for the tokenizer's compliance with PEP 0263. I'll move on to a patch to tokenizer.py now, but this patch is ok to commit now -- it'll clean up the misleading errors being reported by the plethora of red 3.0 buildbots at the moment at the very least. -- nosy: +Trent.Nelson Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue719888> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue719888] tokenize module w/ coding cookie
Trent Nelson <[EMAIL PROTECTED]> added the comment: Hmm, I take it multiple file uploads aren't supported. I don't want to use svn diff for the text files as it looks like it's butchering the bom encodings, so, tar it is! (Untar in root py3k/ directory.) Added file: http://bugs.python.org/file9686/test_tokenize_patch.tar Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue719888> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2297] Patch for fatal stack overflow in Windows caused by -v
Changes by Trent Nelson <[EMAIL PROTECTED]>: -- assignee: -> Trent.Nelson priority: -> normal __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2297> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue719888] tokenize module w/ coding cookie
Trent Nelson <[EMAIL PROTECTED]> added the comment: Tested patch on Win x86/x64 2k8, XP & FreeBSD 6.2, +1. -- assignee: -> Trent.Nelson keywords: +patch Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue719888> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2405] Drop w9xpopen and all dependencies
New submission from Trent Nelson <[EMAIL PROTECTED]>: Python 2.6+ drops support for Windows 95/98, which removes the need for w9xpopen. Get rid of the module and all dependencies (such as in the .msi). -- assignee: Trent.Nelson components: Build messages: 63978 nosy: Trent.Nelson severity: normal status: open title: Drop w9xpopen and all dependencies type: feature request versions: Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2405> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2290] [PATCH] Update Lib/distutils/sysconfig.py to handle x64 Windows builds living in pcbuild/amd64.
Trent Nelson <[EMAIL PROTECTED]> added the comment: Fixed in r61606. -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2290> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2297] Patch for fatal stack overflow in Windows caused by -v
Trent Nelson <[EMAIL PROTECTED]> added the comment: Fixed in r61607, thanks for the report + patch. -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2297> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2329] ImportError: No module named _bsddb
Trent Nelson <[EMAIL PROTECTED]> added the comment: Please provide more information about your platform. Also note that ./configure needs to be able to find pre-existing bsddb libs in order for Python to build the _bsddb module. -- nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2329> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1657] [patch] epoll and kqueue wrappers for the select module
Trent Nelson <[EMAIL PROTECTED]> added the comment: Patch applies cleanly on FreeBSD 6.2-STABLE and all tests pass. Can't comment on technical accuracy. -- nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1657> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2440] Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t.
New submission from Trent Nelson <[EMAIL PROTECTED]>: test_getargs2 fails on Win x64: test_getargs2 is failing on Windows x64: test test_getargs2 failed -- Traceback (most recent call last): File "S:\buildbots\python.x64\3.0.nelson-win64\build\lib\test\test_getargs2.py", line 190, in test_n self.failUnlessEqual(99, getargs_n(Long())) TypeError: 'Long' object cannot be interpreted as an integer The problem is twofold: case 'n' on Win x64 (where SIZEOF_SIZE_T != SIZEOF_LONG) had a broken code path and needed updating. Also, the fallback to 'l' for systems where SIZEOF_SIZE_T == SIZEOF_LONG wasn't correct -- it should still do a PyNumber_Index() check, and then use PyLong_AsSize_t() to extract the value. The attached patch corrects the behaviour on 32-bit and 64-bit systems, including Windows. However, it has now uncovered another bug in Windows x64: >>> from _testcapi import getargs_n >>> getargs_n(sys.maxsize) 9223372036854775807 >>> getargs_n(-sys.maxsize) 1 >>> getargs_n(-sys.maxsize-1) 0 After a bit of investigation with Martin, the logic in PyLong_AsSize_t() is incorrect and needs to be reworked to handle negative maximums properly. -- components: Interpreter Core files: getargs_and_abstract.patch keywords: patch, patch messages: 64212 nosy: Trent.Nelson, loewis severity: normal status: open title: Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t. versions: Python 3.0 Added file: http://bugs.python.org/file9793/getargs_and_abstract.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2440> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2440] Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t.
Changes by Trent Nelson <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9793/getargs_and_abstract.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2440> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2440] Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t.
Trent Nelson <[EMAIL PROTECTED]> added the comment: Attached a slightly cleaner patch. Added file: http://bugs.python.org/file9794/getargs_and_abstract.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2440> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2440] Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t.
Changes by Trent Nelson <[EMAIL PROTECTED]>: __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2440> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2440] Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t.
Changes by Trent Nelson <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9794/getargs_and_abstract.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2440> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2440] Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t.
Trent Nelson <[EMAIL PROTECTED]> added the comment: Attach a slightly cleaner patch, take 2. Added file: http://bugs.python.org/file9795/getargs_and_abstract.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2440> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2513] 64bit cross compilation on windows
Trent Nelson <[EMAIL PROTECTED]> added the comment: Hi guys, have been on holiday since PyCon ended, only getting back into the swing of things now. With regards to the x64 Windows build, indeed, PCbuild/readme.txt is definitely in need of an update, especially with the details of the slightly new build system I checked in a few weeks ago. As it currently stands, the Professional version of Visual Studio 2008 is required for a complete x64 build, however, this is because a cross- compilation 'vsvars32.bat'-type file needs to be called in order to do command line (i.e. nmake) x64 builds. (The particular file I'm referring to is "C:\Program Files (x86) \Microsoft Visual Studio 9.0\VC\vcvarsall.bat", which needs to be invoked with 'x86_amd64' as the first parameter. This is only shipped with the Professional version of Visual Studio 2008 -- the buildbots currently rely on it to produce x64 builds, see http://svn.python.org/projects/python/trunk/Tools/buildbot/build- amd64.bat.) We need to invoke this particular batch file in order to build x64 versions tcl/tk and openssl because we're currently reliant on the nmake-oriented builds each of these projects ship with. That said, the next step in my build-related improvements is to remove this reliance and mimick the nmake-oriented builds with custom .vcproj builds that inherit all of our property sheets -- this is the approach I took with bsddb and sqlite3 and it worked *very*, *very* well. (See _bsddb44.vcproj and sqlite3.vcproj in the PCbuild directory.) There are many advantages with this approach. To name a few: the release versions of the modules will benefit from profile guided optimisation, just like the rest of the python build, the modules are significantly easier to debug, and there is no chance for conflicting compiler/linker flags (which was a continual source of pain with bsddb/sqlite3 when they were built with the vendor-supplied build system). So, eventually, you should be able to build and entire release version of Python x64 with just the Express edition of Visual Studio 2008 (note that the Express edition won't support a PGO build though). The 'official' release though will be built with a Professional version though, as Mark states, thus allowing us to take advantage of profile guided optimisation. Hopefully this isn't too much off topic. (I can't comment on the patches Mark has provided just yet as I haven't had a chance to review them -- just wanted to clear up the x64 cross-compilation questions.) Perhaps I should create a separate issue to track the work needed to cross compile an x64 build with the Express edition only. Any objections? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2513> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2513] 64bit cross compilation on windows
Trent Nelson <[EMAIL PROTECTED]> added the comment: Humm, just saw the MSDN page Marc-Andre referred to, which indeed seems to indicate the Express edition doesn't support x64 cross-compilation *at all*. AFAICT the latest Platform SDK (6.1) ships with an x64 cross compilation environment, but it's command line only, so unless there's a way to hook it up such that 'vcbuild' uses it with the Express edition as well -- it seems like you do need Standard edition or higher for x64 builds. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2513> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2513] 64bit cross compilation on windows
Trent Nelson <[EMAIL PROTECTED]> added the comment: Christian, regarding shipping x64 .lib files as well as 32-bit ones -- sensible idea, but where would we place the x64 version libs? In Python [xx]\libs\amd64? (This would mirror the approach used with PCbuild and PCbuild\amd64 -- although there's currently an ongoing discussion on this topic in python-dev.) With regards to updating PCbuild/readme.txt, I'm planning on doing that by EOD today. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2513> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2513] 64bit cross compilation on windows
Trent Nelson <[EMAIL PROTECTED]> added the comment: Updated PCbuild/readme.txt in r62105 and r62106 for trunk and py3k respectively. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2513> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2549] shutil: NameError (WindowsError) when moving from ext3 to fat32 under linux
Changes by Trent Nelson <[EMAIL PROTECTED]>: -- assignee: -> Trent.Nelson keywords: +easy nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2549> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix
New submission from Trent Nelson <[EMAIL PROTECTED]>: Background: I came across this issue when trying to track down why test_asynchat would periodically wedge python processes on the Windows buildbots, to the point that they wouldn't even respond to SIGKILL (or ctrl-c on the console). What I found after a bit of digging is that Windows doesn't raise EADDRINUSE socket.errors when you bind() two sockets to identical host/ports *IFF* SO_REUSEADDR has been set as a socket option. Decided to brighten up my tube journey into work this morning by reading the Gospel's take on the situation. As per the 'SO_REUSEADDR and SO_REUSEPORT Socket Options' section in chapter 7.5 of Stevens' UNIX Network Programming Volume 1 (2nd Ed): "With TCP, we are never able to start multiple servers that bind the same IP address and same port: a completely duplicate binding. That is, we cannot start one server that binds 198.69.10.2 port 80 and start another that also binds 198.69.10.2 port 80, even if we set the SO_REUSEADDR socket option for the second server." So, it seems at least Windows isn't adhering to this, at least on XP and Server 2008 with 2.5-2.6. I've patched test_socket.py to explicitly test for this situation -- as expected, it passes on Unix (tested on FreeBSD in particular), and fails on Windows. I'd like to commit this to trunk to see if any of the buildbots for different platforms match the behaviour of Windows. -- assignee: Trent.Nelson components: Library (Lib), Windows files: test_socket.py.patch keywords: 26backport, patch messages: 64933 nosy: Trent.Nelson priority: high severity: normal status: open title: SO_REUSEADDR doesn't have the same semantics on Windows as on Unix type: behavior versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9939/test_socket.py.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2550> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2296] [PATCH] Tcl/Tk 8.4.16 patches needed to get an x64 Windows build
Changes by Trent Nelson <[EMAIL PROTECTED]>: -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2296> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue815646] thread unsafe file objects cause crash
Trent Nelson <[EMAIL PROTECTED]> added the comment: Patched and tested on one of my buildbots, test_file passes without error with your latest Patch Greg. -- nosy: +Trent.Nelson Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue815646> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix
Trent Nelson <[EMAIL PROTECTED]> added the comment: [Updating the issue with relevant mailing list conversation] Interesting results! I committed the patch to test_socket.py in r62152. I was expecting all other platforms except for Windows to behave consistently (i.e. pass). That is, given the following: import socket host = '127.0.0.1' sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.bind((host, 0)) port = sock.getsockname()[1] sock.close() del sock sock1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock1.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock1.bind((host, port)) sock2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock2.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock2.bind((host, port)) the second bind should fail with EADDRINUSE, at least according to the 'SO_REUSEADDR and SO_REUSEPORT Socket Options' section in chapter 7.5 of Stevens' UNIX Network Programming Volume 1 (2nd Ed): "With TCP, we are never able to start multiple servers that bind the same IP address and same port: a completely duplicate binding. That is, we cannot start one server that binds 198.69.10.2 port 80 and start another that also binds 198.69.10.2 port 80, even if we set the SO_REUSEADDR socket option for the second server." The results: both Windows *and* Linux fail the patched test; none of the buildbots for either platform encountered an EADDRINUSE socket.error after the second bind(). FreeBSD, OS X, Solaris and Tru64 pass the test -- EADDRINUSE is raised on the second bind. (Interesting that all the ones that passed have a BSD lineage.) I've just reverted the test in r62156 as planned. The real issue now is that there are tests that are calling test_support.bind_socket() with the assumption that the port returned by this method is 'unbound', when in fact, the current implementation can't guarantee this: def bind_port(sock, host='', preferred_port=54321): for port in [preferred_port, 9907, 10243, 32999, 0]: try: sock.bind((host, port)) if port == 0: port = sock.getsockname()[1] return port except socket.error, (err, msg): if err != errno.EADDRINUSE: raise print >>sys.__stderr__, \ ' WARNING: failed to listen on port %d, trying another' % port This logic is only correct for platforms other than Windows and Linux. I haven't looked into all the networking test cases that rely on bind_port(), but I would think an implementation such as this would be much more reliable than what we've got for returning an unused port: def bind_port(sock, host='127.0.0.1', *args): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind((host, 0)) port = s.getsockname()[1] s.close() del s sock.bind((host, port)) return port Actually, FWIW, I just ran a full regrtest.py against trunk on Win32 with this change in place and all the tests still pass. Thoughts? Trent. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2550> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix
Trent Nelson <[EMAIL PROTECTED]> added the comment: [Updating issue with mailing list discussion; my reply to Jean-Paul] > >"With TCP, we are never able to start multiple servers that bind > > the same IP address and same port: a completely duplicate binding. > > That is, we cannot start one server that binds 198.69.10.2 port 80 > > and start another that also binds 198.69.10.2 port 80, even if we > > set the SO_REUSEADDR socket option for the second server." > Notice that the quoted text explains that you cannot start multiple > servers that etc. Since you didn't call listen on either socket, it's > arguable that you didn't start any servers, so there should be no > surprise regarding the behavior. Try adding listen calls at various > places in the example and you'll see something different happen. I agree in principle, Stevens says nothing about what happens if you *do* try and bind two sockets on two identical host/port addresses. Even so, test_support.bind_port() makes an assumption that bind() will raise EADDRINUSE if the port is not available, which, as has been demonstrated, won't be the case on Windows or Linux. > FWIW, AIUI, SO_REUSEADDR behaves just as described in the above quote > on Linux/BSD/UNIX/etc. On Windows, however, that option actually means > something quite different. It means that the address should be stolen > from any process which happens to be using it at the moment. Probably explains why the python process wedges when this happens on Windows... > There is another option, SO_EXCLUSIVEADDRUSE, only on Windows I think, > which, AIUI, makes it impossible for another process to steal the port > using SO_REUSEADDR. Nod, if SO_EXCLUSIVEADDRUSE is used instead in the code I posted, Windows raises EADDRINUSE on the second bind(). I don't have access to any Linux boxes at the moment, so I can't test what sort of error is raised with the example I posted if listen() and accept() are called on the two sockets bound to identical addresses. Can anyone else shed some light on this? I'd be interested in knowing if the process wedges on Linux as badly as it does on Windows (to the point where it's not respecting ctrl-c or sigkill). Trent. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2550> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix
Trent Nelson <[EMAIL PROTECTED]> added the comment: [Updating issue with mailing list discussion; Jean-Paul's reply] On Fri, 4 Apr 2008 13:24:49 -0700, Trent Nelson <[EMAIL PROTECTED]> wrote: >Interesting results! I committed the patch to test_socket.py in r62152. I was expecting all other platforms except for Windows to behave consistently (i.e. pass). That is, given the following: > >import socket >host = '127.0.0.1' >sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >sock.bind((host, 0)) >port = sock.getsockname()[1] >sock.close() >del sock > >sock1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >sock1.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) >sock1.bind((host, port)) >sock2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >sock2.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) >sock2.bind((host, port)) > > >the second bind should fail with EADDRINUSE, at least according to the 'SO_REUSEADDR and SO_REUSEPORT Socket Options' section in chapter 7.5 of Stevens' UNIX Network Programming Volume 1 (2nd Ed): > >"With TCP, we are never able to start multiple servers that bind > the same IP address and same port: a completely duplicate binding. > That is, we cannot start one server that binds 198.69.10.2 port 80 > and start another that also binds 198.69.10.2 port 80, even if we > set the SO_REUSEADDR socket option for the second server." > >The results: both Windows *and* Linux fail the patched test; none of the buildbots for either platform encountered an EADDRINUSE socket.error after the second bind(). FreeBSD, OS X, Solaris and Tru64 pass the test -- EADDRINUSE is raised on the second bind. (Interesting that all the ones that passed have a BSD lineage.) Notice that the quoted text explains that you cannot start multiple servers that etc. Since you didn't call listen on either socket, it's arguable that you didn't start any servers, so there should be no surprise regarding the behavior. Try adding listen calls at various places in the example and you'll see something different happen. FWIW, AIUI, SO_REUSEADDR behaves just as described in the above quote on Linux/BSD/UNIX/etc. On Windows, however, that option actually means something quite different. It means that the address should be stolen from any process which happens to be using it at the moment. There is another option, SO_EXCLUSIVEADDRUSE, only on Windows I think, which, AIUI, makes it impossible for another process to steal the port using SO_REUSEADDR. Hope this helps, Jean-Paul __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2550> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix
Trent Nelson <[EMAIL PROTECTED]> added the comment: I've attached another patch that fixes test_support.bind_port() as well as a bunch of files that used that method. The new implementation always uses an ephemeral port in order to elicit an unused port for subsequent binding. Tested on Windows 32-bit & x64 and FreeBSD 6.2. Would like to apply sooner rather than later unless anyone has any objections as it'll fix my two Windows buildbots that are on the same machine from both hanging if they test asynchat at the same time (which happens more often than you'd think). Added file: http://bugs.python.org/file9966/trunk.2550.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2550> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix
Trent Nelson <[EMAIL PROTECTED]> added the comment: To be honest, I wasn't really happy either with having to return HOST, it's somewhat redundant given that all these tests should be binding against localhost. What about something like this for bind_port(): def bind_port(sock, host=''): """Bind the socket to a free port and return the port number. Relies on ephemeral ports in order to ensure we are using an unbound port. This is important as many tests may be running simultaneously, especially in a buildbot environment.""" # Use a temporary socket object to ensure we're not # affected by any socket options that have already # been set on the 'sock' object we're passed. tempsock = socket.socket(sock.family, sock.type) tempsock.bind((host, 0)) port = tempsock.getsockname()[1] tempsock.close() del tempsock sock.bind((host, port)) return port The tests would then look something like: HOST = 'localhost' PORT = None class Foo(TestCase): def setUp(self): sock = socket.socket() global PORT PORT = test_support.bind_port(sock, HOST) So, the return value is the port bound to, no change there, but we're abolishing preferred_port as an optional argument, which is important, IMO, as none of these tests should be stipulating which port they want to listen on. That's actually the root of this entire problem. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2550> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix
Trent Nelson <[EMAIL PROTECTED]> added the comment: Invested quite a few cycles on this issue last night. The more time I spent on it, the more I became convinced that every single test working with sockets should be changed in one fell swoop in order to facilitate (virtually unlimited) parallel test execution without fear of port conflicts. I've attached a second patch, trunk.2550-2.patch, which is my progress so far on doing just this. The main changes can be expressed by the following two points: a) do whatever it takes in network-oriented tests to ensure unique ports are obtained (relying on the bind_port() and find_unused_port() methods exposed by test_support) b) never, ever, ever call SO_REUSEADDR on a socket from a test; because we're putting so much effort into obtaining a unique port, this should never be necessary -- in the rare cases that our attempts to obtain a unique port fail, then we absolutely should fail with EADDRINUSE, as the ability to obtain a unique port for the duration of a client/server test is an invariant that we *must* be able to depend upon. If the invariant is broken, fail immediately (don't mask the problem with SO_REUSEADDR). With this patch applied, I can spawn a handful of Python processes and run the entire test suite (without -r, ensuring all tests are run in the same order, which should encourage port conflicts (if there were any)) without any errors*. Doing that now is completely and utterly impossible. [*] Well, almost without error. All the I/O related tests that try and open @test fail. I believe there's still outstanding work to do with this patch with regards to how the intracacies of SO_REUSEADDR and SO_EXCLUSIVEADDRUSE should be handled in the rest of the stdlib. I'm still thinking about the best approach for this. However, the patch as it currently stands is still quite substantial so I wanted to get it out sooner rather than later for review. (I'll forward this to python-dev@ to try and encourage more eyes from people with far more network-fu than I.) Added file: http://bugs.python.org/file9980/trunk.2550-2.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2550> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2564] Python hangs on FreeBSD7 in test_capi
Trent Nelson <[EMAIL PROTECTED]> added the comment: Ahh, more FreeBSD threading woes. If no-one beats me to it, I'll be able to start taking a look at this when our FreeBSD 7 server is up in a week or so. -- assignee: -> Trent.Nelson nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2564> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2563] embed manifest in windows extensions
Trent Nelson <[EMAIL PROTECTED]> added the comment: +1 from me on principle (haven't tested). -- nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2563> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1489] test_socket_ssl hanhs on Windows (deadlock)
Trent Nelson <[EMAIL PROTECTED]> added the comment: Re-assigned this to myself (hope you don't mind janssen ;-) as I'm actively looking into it. We build openssl.exe as part of our Windows build so we should make an effort to use this where possible. Note that there is definitely a problem with 'openssl s_server' on Windows, I'm not sure if it's to do with buffering though as I can step through the same actions the test is performing in the console and I get 'ERROR\n' immediately back from the server. This sort of falls into my existing work with issue 2550 (and patches) to improve network- oriented tests such that they can be ran in parallel. Note that patch trunk.2550-2.patch attached to issue2550 goes as far as converting openssl to use the -accept [port] option such that we don't bind on 4443 by default (thus impeding other test_ssl_socket tests that may be running). Also, openssl.exe in the s_server mode is using SO_REUSEADDR when it should be using SO_EXCLUSIVEADDRUSE. That's not our problem per se, but given that we maintain our own openssl-0.9.8g sources, I'm considering fixing it if it improves the reliability of the test. (I'll feed back any changes to the OpenSSL project, of course.) -- assignee: janssen -> Trent.Nelson nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1489> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220212] os.kill on windows
Changes by Trent Nelson <[EMAIL PROTECTED]>: -- nosy: +Trent.Nelson _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1220212> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix
Trent Nelson <[EMAIL PROTECTED]> added the comment: Committed updates to relevant network-oriented tests, as well as test_support changes discussed, in r62234. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2550> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1049] socket.socket.getsockname() has inconsistent UNIX/Windows behavior
Changes by Trent Nelson <[EMAIL PROTECTED]>: -- nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1049> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2440] Issues with getargs_n() and PyNumber_Index.
Trent Nelson <[EMAIL PROTECTED]> added the comment: Committed patch in r62269. I'll raise a separate tracker issue for PyLong_AsSsize_t as it isn't related to this issue. -- assignee: -> Trent.Nelson keywords: +64bit resolution: -> fixed status: open -> closed title: Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t. -> Issues with getargs_n() and PyNumber_Index. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2440> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2440] Issues with getargs_n() and PyNumber_Index.
Trent Nelson <[EMAIL PROTECTED]> added the comment:
Eek, so it does, thanks. Applied the following patch on a bunch of 32-
bit/x64 systems, testing now, so far everything looks good...
Index: abstract.c
===
--- abstract.c (revision 62279)
+++ abstract.c (working copy)
@@ -1240,7 +1240,7 @@
return NULL;
}
}
- else if (m && m->nb_int != NULL) {
+ else if (m && m->nb_int != NULL && m->nb_float == NULL) {
result = m->nb_int(item);
if (result && !PyLong_Check(result)) {
PyErr_Format(PyExc_TypeError,
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2440>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2240] setitimer, getitimer wrapper
Changes by Trent Nelson <[EMAIL PROTECTED]>: -- nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2240> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2611] Extend buildbot web interface to allow for forced tests to be run on a slave in verbose mode.
New submission from Trent Nelson <[EMAIL PROTECTED]>: It'd be nice if there was a facility to force a particular test to be re-run in verbose mode with the most recent build via the buildbot web interface. It would allow us to get a bit more information about what's going on when the buildbots report stuff like this: test_property test_cprofile test_signal command timed out: 1800 seconds without output, killing pid 214235 SIGKILL failed to kill process using fake rc=-1 program finished with exit code -1 Neal or Martin, if neither of you have the desire/bandwidth to look into this, I'm more than happy to take it on. Suspect it'd involve a buildbot change on dinsdale right? -- components: Build messages: 65328 nosy: Trent.Nelson, loewis, nnorwitz severity: normal status: open title: Extend buildbot web interface to allow for forced tests to be run on a slave in verbose mode. type: feature request __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2611> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2609] Tests fail if ./@test is not writeable
Changes by Trent Nelson <[EMAIL PROTECTED]>: -- assignee: -> Trent.Nelson nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2609> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows
Changes by Trent Nelson <[EMAIL PROTECTED]>: -- nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2643> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2440] Issues with getargs_n() and PyNumber_Index.
Trent Nelson <[EMAIL PROTECTED]> added the comment: Update: the changes committed on r62269 and r62279 were incorrect and reverted in r62292. Log: Issue 2440: revert r62269 and r62279. These changes were made in an effort to fix test_args2.Signed_TestCase.test_n(), which was failing on Windows x64 on the following line: 'self.failUnlessEqual(99, getargs_n (Long()))'. Although the two commits *did* fix the test on Windows x64, it's become clear that it's the test that's incorrect, and the changes to PyNumber_Index() in particular were not warranted (and actually violate PEP 357). This commit will get us back to where we were at r62268, before I started butchering things. The reworked patch fixes test_getargs2.py, such that it verifies Long() and Int() can't be used as indexes. It also fixes the handling of 'n' in getargs.c's convertsimple(). Committed in r62462. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2440> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue719888] tokenize module w/ coding cookie
Trent Nelson <[EMAIL PROTECTED]> added the comment: This was fixed in trunk in r61573, and merged to py3k in r61982. -- status: open -> closed Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue719888> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1489] test_socket_ssl hanhs on Windows (deadlock)
Trent Nelson <[EMAIL PROTECTED]> added the comment: Hey, if we can get rid of it, that's great. You sound 95% certain in your last post that completely removing test_socket_ssl on trunk and py3k is the Right Thing -- any chance of getting you to 100% so I can go ahead and delete it and close this ticket? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1489> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2686] Any chance we could double the height of the 'Comment:' text area on tracker?
New submission from Trent Nelson <[EMAIL PROTECTED]>: I'd give my left arm for the comment box to be at least double its current height. Once you've written more than a paragraph, it becomes a nuisance having to scroll up and down to re-read what you've written before typing more. Quick win? -- assignee: loewis components: None messages: 65754 nosy: Trent.Nelson, loewis severity: normal status: open title: Any chance we could double the height of the 'Comment:' text area on tracker? type: feature request __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2686> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2686] Any chance we could double the height of the 'Comment:' text area on tracker?
Trent Nelson <[EMAIL PROTECTED]> added the comment: Perhaps you could sell my arm on eBay then forward me the proceeds such that I can buy a Mac and use Safari? ;-) Will use meta tracker herein -- didn't even know that existed. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2686> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2733] mmap resize fails on anonymous memory (Windows)
Changes by Trent Nelson <[EMAIL PROTECTED]>: -- nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2733> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31562] snakebite.net is not available
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 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 > <https://bugs.python.org/issue31562> > ___ -- ___ Python tracker <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 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 <https://bugs.python.org/issue31562> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3329] API for setting the memory allocator used by Python
Changes by Trent Nelson : -- nosy: +trent ___ Python tracker <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()
Changes by Trent Nelson : -- nosy: +trent ___ Python tracker <http://bugs.python.org/issue18203> ___ ___ 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
Changes by Trent Nelson : -- nosy: +trent ___ Python tracker <http://bugs.python.org/issue13483> ___ ___ 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
Changes by Trent Nelson : -- nosy: +trent ___ Python tracker <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
Changes by Trent Nelson : -- versions: -Python 3.2 ___ Python tracker <http://bugs.python.org/issue16296> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Trent Nelson added the comment: Hi Ned, On a brand new OS X Lion install with the latest XCode (4.3.2) and command line tools*, the following worked: ./configure --with-pydebug CC=clang MACOSX_DEPLOYMENT_TARGET=10.7 That is, everything built cleanly, and all tests ran without failures: 336 tests OK. 2 tests altered the execution environment: test_packaging test_site 26 tests skipped: test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu test_devpoll test_epoll test_gdb test_largefile test_lzma test_msilib test_ossaudiodev test_smtpnet test_socketserver test_startfile test_timeout test_tk test_ttk_guionly test_urllib2net test_urllibnet test_winreg test_winsound test_xmlrpc_net test_zipfile64 3 skips unexpected on darwin: test_lzma test_tk test_ttk_guionly I presume the aim is to be able to build correctly (on all UNIX platforms) with just ./configure --with-pydebug, right? How's your configure*-toolchain-fu? Once we fix this I can add the build slave. Side bar: note that this was a vanilla 10.6->10.7 install. The XCode 4.3.2 install on 10.7 was the first XCode ever installed on the box; there's no /Developer or any of the old gcc* cruft. [*]: Went to https://developer.apple.com/downloads/index.action, logged in with my Apple ID, then downloaded 'Commandline Tools for XCode - Late March 2012' -- dmg was 'cltools_lion_latemarch12.dmg'. -- nosy: +trent ___ Python tracker <http://bugs.python.org/issue13241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Trent Nelson added the comment: > > "Once we fix this I can add the build slave" > I'm missing the context for this. Yeah I uh, seemed to have deleted the introductory sentence I wrote that said I was doing some prep work before adding an OS X 10.7 build slave. > Can't you override with environment variables or on the configure command > itself? Are you referring to when I set up the build slave? i.e. tweak the local environment the build slave account runs under so that `./configure --with-pydebug` works out of the box? I don't think that's really a precedent we want to set (having build slave owners hack the local environment to work around build issues). -- ___ Python tracker <http://bugs.python.org/issue13241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15477] test_cmath failures on OS X 10.8
Trent Nelson added the comment:
I ran into this last night and posted to python-dev before realizing this bug
had been raised:
http://mail.python.org/pipermail/python-dev/2012-August/121359.html
I'll reproduce it here as I made a few observations that haven't yet been
mentioned in this issue:
The Mountain Lion build slave I set up earlier this evening fails on
test_cmath:
==
FAIL: test_specific_values (test.test_cmath.CMathTests)
--
Traceback (most recent call last):
File
"/Volumes/bay2/buildslave/cpython/2.7.snakebite-mountainlion-amd64/build/Lib/test/test_cmath.py",
line 352, in test_specific_values
msg=error_message)
File
"/Volumes/bay2/buildslave/cpython/2.7.snakebite-mountainlion-amd64/build/Lib/test/test_cmath.py",
line 94, in rAssertAlmostEqual
'got {!r}'.format(a, b))
AssertionError: atan: atan(complex(0.0, 0.0))
Expected: complex(0.0, 0.0)
Received: complex(0.0, -0.0)
Received value insufficiently close to expected value.
Mountain Lion's atan/log1p appear to drop the negative sign when
passed in -0.0, whereas previous versions of OS X didn't:
Mountain Lion:
% ~/log1p-viper
log1p_drops_zero_sign_test:
atan2(log1p(-0.), -1.) != atan2(-0., -1.)
3.14159 vs -3.14159
atan_drops_zero_sign_test:
atan2(-0., 0.): -0.0
atan2( 0., -0.): 3.14159
atan2(-0., -0.): -3.14159
atan2( 0., 0.): 0.0
log1p(-0.): 0.0
log1p( 0.): 0.0
Lion:
% ./log1p
log1p_drops_zero_sign_test:
atan2(log1p(-0.), -1.) == atan2(-0., -1.)
-3.14159 vs -3.14159
atan_drops_zero_sign_test:
atan2(-0., 0.): -0.0
atan2( 0., -0.): 3.14159
atan2(-0., -0.): -3.14159
atan2( 0., 0.): 0.0
log1p(-0.): -0.0
log1p( 0.): 0.0
(The C code for that is below.)
configure.ac already has a test for this (it makes mention of AIX
having similar behaviour), and the corresponding sysconfig entry
named 'LOG1P_DROPS_ZERO_SIGN' is already being used on a few tests,
i.e.:
# The algorithm used for atan and atanh makes use of the system
# log1p function; If that system function doesn't respect the sign
# of zero, then atan and atanh will also have difficulties with
# the sign of complex zeros.
@requires_IEEE_754
@unittest.skipIf(sysconfig.get_config_var('LOG1P_DROPS_ZERO_SIGN'),
"system log1p() function doesn't preserve the sign")
def testAtanSign(self):
for z in complex_zeros:
self.assertComplexIdentical(cmath.atan(z), z)
@requires_IEEE_754
@unittest.skipIf(sysconfig.get_config_var('LOG1P_DROPS_ZERO_SIGN'),
"system log1p() function doesn't preserve the sign")
def testAtanhSign(self):
for z in complex_zeros:
self.assertComplexIdentical(cmath.atanh(z), z)
Taking a look at cmath_testcases.txt, and we can see this:
-- These are tested in testAtanSign in test_cmath.py
-- atan atan 0.0 0.0 -> 0.0 0.0
-- atan0001 atan 0.0 -0.0 -> 0.0 -0.0
-- atan0002 atan -0.0 0.0 -> -0.0 0.0
-- atan0003 atan -0.0 -0.0 -> -0.0 -0.0
However, a few lines down, those tests crop up again:
-- special values
atan1000 atan -0.0 0.0 -> -0.0 0.0
atan1014 atan 0.0 0.0 -> 0.0 0.0
which is what causes the current test failures. I hacked
test_cmath.py a bit to spit out all the errors it finds after
it's finished parsing the test file (instead of bombing out on
the first one), and it yielded this:
FAIL: test_specific_values (test.test_cmath.CMathTests)
--
Traceback (most recent call last):
File
"/Volumes/bay2/buildslave/cpython/3.2.snakebite-mountainlion-amd64/build/Lib/test/test_cmath.py",
line 446, in test_specific_values
self.fail("\n".join(failures))
AssertionError: atan1000: atan(complex(-0.0, 0.0))
Expected: complex(-0.0, 0.0)
Received: complex(-0.0, -0.0)
Received value insufficiently close to expected value.
atan1014: atan(complex(0.0, 0.0))
Expected: complex(0.0, 0.0)
Received: complex
[issue15477] test_cmath failures on OS X 10.8
Trent Nelson added the comment: Happy to report your patch does the trick Mark. test_cmath passes on 10.7 and 10.8 with it applied. -- ___ Python tracker <http://bugs.python.org/issue15477> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet
Trent Nelson added the comment: Proposed patch attached. -- keywords: +patch nosy: +trent Added file: http://bugs.python.org/file26890/test_timeout.patch ___ Python tracker <http://bugs.python.org/issue15285> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet
Changes by Trent Nelson : -- assignee: -> trent ___ Python tracker <http://bugs.python.org/issue15285> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15285] test_timeout failure when system on IPv4 10.x.x.x subnet
Trent Nelson added the comment: Fixed in 3.2: changeset: 78690:9c2af1f9 branch: 3.2 parent: 78686:8600ae913b63 user:Trent Nelson date:Mon Aug 20 21:22:59 2012 -0400 summary: Issue #15285: Refactor connect timeout test in test_timeout. Fixed in 3.x: changeset: 78691:b86f3af4746c tag: tip parent: 78689:f8eabfed9a1d parent: 78690:9c2af1f9 user:Trent Nelson date:Mon Aug 20 21:40:21 2012 -0400 summary: Issue #15285: Refactor connect timeout test in test_timeout. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue15285> ___ ___ 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
New submission from Trent Nelson: I've got two FreeBSD buildslaves running on ZFS (8.2 and 9.1) experiencing this: == FAIL: test_futimes_ns (test.test_os.StatAttributeTests) -- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 369, in test_futimes_ns self._test_utime_ns(futimes_ns, test_dir=False) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 339, in _test_utime_ns self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 318, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 1345497270884503433 != 1345497270884503000 == FAIL: test_lutimes_ns (test.test_os.StatAttributeTests) -- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 362, in test_lutimes_ns self._test_utime_ns(lutimes_ns) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 339, in _test_utime_ns self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 318, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 134549727047634 != 134549727047000 == FAIL: test_utime (test.test_os.StatAttributeTests) -- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 331, in test_utime self._test_utime(self.fname, getattr, utime, 10) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 318, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 1345497270.8923829 != 1345497270.892382 == FAIL: test_utime_ns (test.test_os.StatAttributeTests) -- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 346, in test_utime_ns self._test_utime_ns(utime_ns) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 339, in _test_utime_ns self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 318, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 1345497270894558518 != 1345497270894558000 I briefly stepped through the test on one of the affected slaves. There's a rounding issue somewhere... I personally think this method is involved: def _test_utime_ns(self, set_times_ns, test_dir=True): def getattr_ns(o, attr): return getattr(o, attr + "_ns") ten_s = 10 * 1000 * 1000 * 1000 self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s) if test_dir: self._test_utime(support.TESTFN, getattr_ns, set_times_ns, ten_s) I didn't have enough time to keep debugging, so I'm raising this as a placeholder until I can pick it back up again. -- assignee: trent messages: 168728 nosy: trent priority: normal severity: normal stage: needs patch status: open title: Numerous utime ns tests fail on FreeBSD w/ ZFS type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue15745> ___ ___ 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
New submission from Trent Nelson: The 'Windows Server 2003 R2 SP1' build slave I set up keeps bombing out on test_winsound: == FAIL: test_alias_nofallback (test.test_winsound.PlaySoundTest) -- Traceback (most recent call last): File "E:\Data\buildslave\cpython\2.7.snakebite-win2k3r2sp2-x86\build\lib\test\test_winsound.py", line 199, in test_alias_nofallback '!"$%&/(#+*', winsound.SND_ALIAS | winsound.SND_NODEFAULT AssertionError: RuntimeError not raised Raising this as a placeholder until I can look into it in more detail. -- assignee: trent messages: 168729 nosy: trent priority: normal severity: normal status: open title: test_winsound bombing out on 2003 buildslave type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue15746> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15747] Various chflags tests failing on FreeBSD/ZFS
New submission from Trent Nelson: Both of my FreeBSD ZFS slaves (8.2 and 9.1) have chflags tests failing as follows: == ERROR: test_chflags (test.test_posix.PosixTester) -- Traceback (most recent call last): File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 350, in test_chflags self._test_chflags_regular_file(posix.chflags, support.TESTFN) File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 337, in _test_chflags_regular_file chflags_func(target_file, st.st_flags | stat.UF_IMMUTABLE) OSError: [Errno 45] Operation not supported: '@test_48794_tmp' == ERROR: test_lchflags_regular_file (test.test_posix.PosixTester) -- Traceback (most recent call last): File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 354, in test_lchflags_regular_file self._test_chflags_regular_file(posix.lchflags, support.TESTFN) File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 337, in _test_chflags_regular_file chflags_func(target_file, st.st_flags | stat.UF_IMMUTABLE) OSError: [Errno 45] Operation not supported: '@test_48794_tmp' == ERROR: test_lchflags_symlink (test.test_posix.PosixTester) -- Traceback (most recent call last): File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 367, in test_lchflags_symlink dummy_symlink_st.st_flags | stat.UF_IMMUTABLE) OSError: [Errno 45] Operation not supported: '/tmp/@test_48794_tmp-dummy-symlink' -- >From the FreeBSD chflags(1) manual page: The flags are specified as an octal number or a comma separated list of keywords. The following keywords are currently defined: arch, archived set the archived flag (super-user only) opaque set the opaque flag (owner or super-user only) nodump set the nodump flag (owner or super-user only) sappnd, sappend set the system append-only flag (super-user only) schg, schange, simmutable set the system immutable flag (super-user only) sunlnk, sunlink set the system undeletable flag (super-user only) uappnd, uappend set the user append-only flag (owner or super-user only) uchg, uchange, uimmutable set the user immutable flag (owner or super-user only) uunlnk, uunlink set the user undeletable flag (owner or super-user only) That indicates only root can set the immutable flag -- but if this were the case, I wonder why none of the other FreeBSD build slaves have run into it? Either way, placeholder issue until I can spend some more time on it. -- assignee: trent components: Tests messages: 168730 nosy: trent priority: normal severity: normal status: open title: Various chflags tests failing on FreeBSD/ZFS type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue15747> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15748] Various symlink test failures in test_shutil on FreeBSD
New submission from Trent Nelson: FreeBSD slaves are running into this: == ERROR: test_copy2_symlinks (test.test_shutil.TestShutil) -- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_shutil.py", line 490, in test_copy2_symlinks shutil.copy2(src_link, dst, follow_symlinks=False) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/shutil.py", line 237, in copy2 copyfile(src, dst, follow_symlinks=follow_symlinks) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/shutil.py", line 107, in copyfile os.symlink(os.readlink(src), dst) TypeError: embedded NUL character == ERROR: test_copy_symlinks (test.test_shutil.TestShutil) -- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_shutil.py", line 463, in test_copy_symlinks shutil.copy(src_link, dst, follow_symlinks=False) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/shutil.py", line 221, in copy copyfile(src, dst, follow_symlinks=follow_symlinks) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/shutil.py", line 107, in copyfile os.symlink(os.readlink(src), dst) TypeError: embedded NUL character == FAIL: test_copytree_symlinks (test.test_shutil.TestShutil) -- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_shutil.py", line 606, in test_copytree_symlinks os.path.join(src_dir, 'file.txt')) AssertionError: '/tmp/tmpqlihz5/src/file.' != '/tmp/tmpqlihz5/src/file.txt' - /tmp/tmpqlihz5/src/file. + /tmp/tmpqlihz5/src/file.txt ? +++ Haven't had time to debug it any further yet. Have no clue what's going on either just from a cursory look at the error messages. Not sure if it's ZFS related like the other FreeBSD issues. -- assignee: trent components: Tests messages: 168731 nosy: trent priority: normal severity: normal status: open title: Various symlink test failures in test_shutil on FreeBSD type: behavior versions: Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue15748> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15747] Various chflags tests failing on FreeBSD/ZFS
Trent Nelson added the comment: Turns out ZFS doesn't support any of the traditional chflags flags -- it returns EOPNOTSUPP for all of them. Attached patch factors this into the various chflags tests. -- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file26942/test_posix.patch ___ Python tracker <http://bugs.python.org/issue15747> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15750] test_localtime_daylight_false_dst_true raises OverflowError: mktime argument out of range
New submission from Trent Nelson: On the FreeBSD 8.2 build slave: == ERROR: test_localtime_daylight_false_dst_true (test_utils.LocaltimeTests) -- Traceback (most recent call last): File "/home/buildslave/python/3.x.snakebite-freebsd82-amd64/build/Lib/test/test_email/test_utils.py", line 86, in test_localtime_daylight_false_dst_true t1 = utils.localtime(t0, isdst=1) File "/home/buildslave/python/3.x.snakebite-freebsd82-amd64/build/Lib/email/utils.py", line 397, in localtime seconds = time.mktime(tm) OverflowError: mktime argument out of range == ERROR: test_localtime_daylight_true_dst_true (test_utils.LocaltimeTests) -- Traceback (most recent call last): File "/home/buildslave/python/3.x.snakebite-freebsd82-amd64/build/Lib/test/test_email/test_utils.py", line 79, in test_localtime_daylight_true_dst_true t1 = utils.localtime(t0, isdst=1) File "/home/buildslave/python/3.x.snakebite-freebsd82-amd64/build/Lib/email/utils.py", line 397, in localtime seconds = time.mktime(tm) OverflowError: mktime argument out of range -- Placeholder issue, haven't looked into it in detail yet. -- components: Tests messages: 168741 nosy: trent priority: normal severity: normal stage: needs patch status: open title: test_localtime_daylight_false_dst_true raises OverflowError: mktime argument out of range type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue15750> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15750] test_localtime_daylight_false_dst_true raises OverflowError: mktime argument out of range
Trent Nelson added the comment: Narrowed it down to the following snippet: >>> time.mktime((2012, 3, 12, 1, 1, 0, 0, 72, -1)) 1331514060.0 [70780 refs] >>> time.mktime((2012, 3, 12, 1, 1, 0, 0, 72, 1)) Traceback (most recent call last): File "", line 1, in OverflowError: mktime argument out of range [70832 refs] On all my FreeBSD boxes, that latter invocation always raises an OverflowError. -- ___ Python tracker <http://bugs.python.org/issue15750> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15750] test_localtime_daylight_false_dst_true raises OverflowError: mktime argument out of range
Trent Nelson added the comment:
All my servers are set to use UTC, which affects how FreeBSD (and other BSDs)
treat the isdst param in struct tm in mktime:
#include
#include
#include
int main(int argc, char **argv)
{
struct tm tm1, tm2;
time_t t1, t2;
memset((void *)&tm1, 0, sizeof(struct tm));
memset((void *)&tm2, 0, sizeof(struct tm));
// UTC
setenv("TZ", "UTC", 1);
tzset();
tm1.tm_sec = 0;
tm1.tm_min = 1;
tm1.tm_hour = 1;
tm1.tm_mday = 12;
tm1.tm_mon = 3;
tm1.tm_year = 2012;
tm1.tm_wday = -1;
tm1.tm_yday = -1;
tm1.tm_isdst = 1;
t1 = mktime(&tm1);
printf("t1 (UTC): %d\n", t1);
// EST
setenv("TZ", "CET", 1);
tzset();
tm2.tm_sec = 0;
tm2.tm_min = 1;
tm2.tm_hour = 1;
tm2.tm_mday = 12;
tm2.tm_mon = 3;
tm2.tm_year = 2012;
tm2.tm_wday = -1;
tm2.tm_yday = -1;
tm2.tm_isdst = 1;
t2 = mktime(&tm2);
printf("t2 (CET): %d\n", t2);
return 0;
}
% gcc -g test_mktime.c -o test_time && ./test_time
t1 (UTC): -1
t2 (CET): 1162787116
The two tests causing problems are Lib/test/test_email/test_utils.py:
def test_localtime_daylight_false_dst_false(self):
test.support.patch(self, time, 'daylight', False)
t0 = datetime.datetime(2012, 3, 12, 1, 1)
t1 = utils.localtime(t0, isdst=-1)
t2 = utils.localtime(t1)
self.assertEqual(t1, t2)
def test_localtime_daylight_true_dst_true(self):
test.support.patch(self, time, 'daylight', True)
t0 = datetime.datetime(2012, 3, 12, 1, 1)
t1 = utils.localtime(t0, isdst=1)
t2 = utils.localtime(t1)
self.assertEqual(t1, t2)
In order for those tests to work on a *BSD server with a TZ set to UTC, TZ is
going to need to be set to something else first, and then tzset() called.
Otherwise, mktime() will return -1, which triggers the overflow error.
--
___
Python tracker
<http://bugs.python.org/issue15750>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15748] Various symlink test failures in test_shutil on FreeBSD
Trent Nelson added the comment:
Looks like os.readlink() is busted:
> /home/trent/src/cpython/Lib/shutil.py(107)copyfile()
-> os.symlink(os.readlink(src), dst)
(Pdb) s
TypeError: embedded NUL character
> /home/trent/src/cpython/Lib/shutil.py(107)copyfile()
-> os.symlink(os.readlink(src), dst)
(Pdb) os.readlink(src)
'/tmp/tmpr3obfj/foo\x00\x00\x00\x00\x00\x00'
(Pdb) p src
'/tmp/tmpr3obfj/baz'
(Pdb) l
102 # XXX What about other special files? (sockets, devices...)
103 if stat.S_ISFIFO(st.st_mode):
104 raise SpecialFileError("`%s` is a named pipe" % fn)
105
106 if not follow_symlinks and os.path.islink(src):
107 -> os.symlink(os.readlink(src), dst)
108 else:
109 with open(src, 'rb') as fsrc:
110 with open(dst, 'wb') as fdst:
111 copyfileobj(fsrc, fdst)
112 return dst
> /home/trent/src/cpython/Lib/shutil.py(107)copyfile()
-> os.symlink(os.readlink(src), dst)
(Pdb) s
TypeError: embedded NUL character
> /home/trent/src/cpython/Lib/shutil.py(107)copyfile()
-> os.symlink(os.readlink(src), dst)
(Pdb) os.readlink(src)
'/tmp/tmpr3obfj/foo\x00\x00\x00\x00\x00\x00'
(Pdb) p src
'/tmp/tmpr3obfj/baz'
(Pdb) l
102 # XXX What about other special files? (sockets, devices...)
103 if stat.S_ISFIFO(st.st_mode):
104 raise SpecialFileError("`%s` is a named pipe" % fn)
105
106 if not follow_symlinks and os.path.islink(src):
107 -> os.symlink(os.readlink(src), dst)
108 else:
109 with open(src, 'rb') as fsrc:
110 with open(dst, 'wb') as fdst:
111 copyfileobj(fsrc, fdst)
112 return dst
i.e.:
(Pdb) os.readlink(src)
'/tmp/tmpr3obfj/foo\x00\x00\x00\x00\x00\x00'
Started another session with gdb, set a breakpoint at posix_readlink:
Breakpoint 1, posix_readlink (self=0x800909858, args=0x805ec2840, kwargs=0x0)
at ./Modules/posixmodule.c:7007
7007int dir_fd = DEFAULT_DIR_FD;
(gdb) l
7002
7003static PyObject *
7004posix_readlink(PyObject *self, PyObject *args, PyObject *kwargs)
7005{
7006path_t path;
7007int dir_fd = DEFAULT_DIR_FD;
7008char buffer[MAXPATHLEN];
7009ssize_t length;
7010PyObject *return_value = NULL;
7011static char *keywords[] = {"path", "dir_fd", NULL};
(gdb) n
7013memset(&path, 0, sizeof(path));
(gdb)
7014if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O&|$O&:readlink",
keywords,
(gdb)
7024Py_BEGIN_ALLOW_THREADS
(gdb)
7026if (dir_fd != DEFAULT_DIR_FD)
(gdb) p path
$1 = {function_name = 0x0, argument_name = 0x0, nullable = 0, allow_fd = 0,
wide = 0x0, narrow = 0x805ec0f10 "/tmp/tmpko8vo_/baz", fd = -1, length = 18,
object = 0x805e30d60, cleanup = 0x805ec0ee0}
path.narrow and length are correct at that point.
(gdb) p dir_fd
$2 = -100
(gdb) n
7024Py_BEGIN_ALLOW_THREADS
(gdb) n
7026if (dir_fd != DEFAULT_DIR_FD)
(gdb) n
7030length = readlink(path.narrow, buffer, sizeof(buffer));
(gdb) n
7031Py_END_ALLOW_THREADS
(gdb) p length
$3 = 24
(gdb) p sizeof(buffer)
$7 = 1024
(gdb) p buffer
$9 =
"/tmp/tmpko8vo_/foo\000\000\000\000\000\000อค\r\001\b\000\000\000\000\000\000\000??A",
'\0' , "??\203\000\b\000\000\000?v???\177\000\000??A", '\0'
, "f\023J", '\0' ,
"??A\000\000\000\000\000\001\000\000\000\000\000\000\000\030u???\177\000\000
u???\177\000\000RCJ\000\000\000\000\000\000\001\000\000\000\000\000\000??A\000\000\000\000\000?v???\177\000\000?(?\005\b\000\000\?L\002\b\000\000\000\210N?\005\b\000\000\000\001\000\000\000\000\000\000\000??A\000\000\000\000\000?"...
No idea why readlink is returning 24. Need to look into it more.
--
___
Python tracker
<http://bugs.python.org/issue15748>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15757] ./configure --with-pydebug on FreeBSD results in -O2 -pipe eventually ending up in CFLAGS.
New submission from Trent Nelson: All the FreeBSD build slaves seem to be experiencing the same symptom: ./configure --with-pydebug eventually results in this: gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -O2 -pipe -fno-strict-aliasing -Wall -march=native -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c What I find odd: % grep -e '-O2' Makefile | wc -l 0 There are references to -O2 elsewhere, like in configure.ac|configure, but, the Makefile doesn't source any of those. (Right?) This is occurring on all of my slaves as well as others, so I'm pretty sure it's not just specific to my environment. -- assignee: trent messages: 168805 nosy: koobs, skrah, trent priority: normal severity: normal status: open title: ./configure --with-pydebug on FreeBSD results in -O2 -pipe eventually ending up in CFLAGS. type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue15757> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15748] Various symlink test failures in test_shutil on FreeBSD
Trent Nelson added the comment: Hi Larry, Funnily enough, I just tried to step through a heavily hacked version of posix_readlink again, only to get gdb telling me I couldn't 'print' the variables I had added in. Turns out, `./configure --with-pydebug` on FreeBSD ends up with '-O2' being appended to CFLAGS some how. I've raised a separate issue for this: http://bugs.python.org/issue15748. -- ___ Python tracker <http://bugs.python.org/issue15748> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15757] ./configure --with-pydebug on FreeBSD results in -O2 -pipe eventually ending up in CFLAGS.
Trent Nelson added the comment: Ah! % gmake gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes-I. -I./Include-DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes-I. -I./Include-DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c ^C % make % make gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -O2 -pipe -I. -I./Include-DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -O2 -pipe -I. -I./Include-DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -O2 -pipe -I. -I./Include-DPy_BUILD_CORE -o Parser/grammar1.o Parser/grammar1.c ^C So, the default BSD make likes to add in -O2 -pipe. I'll do a bit more digging. -- ___ Python tracker <http://bugs.python.org/issue15757> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15757] ./configure --with-pydebug on FreeBSD results in -O2 -pipe eventually ending up in CFLAGS.
Trent Nelson added the comment: So, looks like FreeBSD's /usr/share/mk/sys.mk is to blame here. It unconditionally sets CFLAGS to `-O2 -pipe`. [trent@hydrogen/ttypts/1(~s/cpython)%] uname -a FreeBSD hydrogen.snakebite.net 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r0: Mon Jul 16 06:28:19 UTC 2012 r...@hydrogen.snakebite.net:/usr/obj/src/freebsd/9/r238513m/sys/AMD64 amd64 [trent@hydrogen/ttypts/1(~s/cpython)%] grep -A3 'bsd_make_test' Makefile bsd_make_test: @echo "CFLAGS: $(CFLAGS)" @echo "EXTRA_CFLAGS: $(EXTRA_CFLAGS)" [trent@hydrogen/ttypts/1(~s/cpython)%] make bsd_make_test CFLAGS: -O2 -pipe EXTRA_CFLAGS: [trent@hydrogen/ttypts/1(~s/cpython)%] make CFLAGS= bsd_make_test CFLAGS: EXTRA_CFLAGS: I can think of a few ways to work around this... some better than others. 1. Change the FreeBSD buildbots to always invoke make via `make CFLAGS=`. 2. Hack configure.* to automatically invoke make via `make CFLAGS=` when `-O2 -pipe` crops up in a `--with-pydebug` build. Some of the less desirable ones: 3. Switch FreeBSD to gmake. 4. Patch FreeBSD make so that it is 'debug aware' and stops appending `-O2` everywhere. -- ___ Python tracker <http://bugs.python.org/issue15757> ___ ___ 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 added the comment: >>> print(_have_functions) ['HAVE_FACCESSAT', 'HAVE_FCHDIR', 'HAVE_FCHMOD', 'HAVE_FCHMODAT', 'HAVE_FCHOWN', 'HAVE_FEXECVE', 'HAVE_FDOPENDIR', 'HAVE_FPATHCONF', 'HAVE_FSTATAT', 'HAVE_FSTATVFS', 'HAVE_FTRUNCATE', 'HAVE_FUTIMES', 'HAVE_FUTIMESAT', 'HAVE_LINKAT', 'HAVE_LCHFLAGS', 'HAVE_LCHMOD', 'HAVE_LCHOWN', 'HAVE_LSTAT', 'HAVE_LUTIMES', 'HAVE_MKDIRAT', 'HAVE_MKFIFOAT', 'HAVE_MKNODAT', 'HAVE_OPENAT', 'HAVE_READLINKAT', 'HAVE_RENAMEAT', 'HAVE_SYMLINKAT', 'HAVE_UNLINKAT'] /usr/include/utime.h exists. FWIW, when I stepped through it a few nights ago, I remember that all the code paths eventually visited the point where the mtime gets converted into a decimal: == FAIL: test_utime (test.test_os.StatAttributeTests) -- Traceback (most recent call last): File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 331, in test_utime self._test_utime(self.fname, getattr, utime, 10) File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 318, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 1345497270.8923829 != 1345497270.892382 However, for the other errors: AssertionError: 1345497270884503433 != 1345497270884503000 AssertionError: 134549727047634 != 134549727047000 they'd get cast back before the assertEqual test would be done. As for this: 1345497270.8923829 != 1345497270.892382 The trailing 9 is getting lopped off, which results in the rounding errors. -- ___ Python tracker <http://bugs.python.org/issue15745> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15748] Various symlink test failures in test_shutil on FreeBSD
Trent Nelson added the comment:
Well, bugger me, check this out:
import os
import stat
import tempfile
d = tempfile.mkdtemp()
src = os.path.join(d, 'foo')
dst = os.path.join(d, 'bar')
src_link = os.path.join(d, 'baz')
dst_link = os.path.join(d, 'qux')
sf = open(dst, 'w')
sf.write('foo')
sf.flush()
sf.close()
df = open(dst, 'w')
df.write('bar')
df.flush()
df.close()
os.symlink(src, src_link)
os.symlink(dst, dst_link)
os.lchmod(src_link, stat.S_IRWXU | stat.S_IRWXO)
os.readlink(dst_link)
os.readlink(src_link)
Results of the last two calls:
>>> os.readlink(dst_link)
path 1: /tmp/tmpfz5v6h/qux, length 1: 18, buf 1: /tmp/tmpfz5v6h/bar
path 2: /tmp/tmpfz5v6h/qux, length 2: 18, buf 2: /tmp/tmpfz5v6h/bar
'/tmp/tmpfz5v6h/bar'
[73299 refs]
>>> os.readlink(src_link)
path 1: /tmp/tmpfz5v6h/baz, length 1: 24, buf 1: /tmp/tmpfz5v6h/foo
path 2: /tmp/tmpfz5v6h/baz, length 2: 24, buf 2: /tmp/tmpfz5v6h/foo
'/tmp/tmpfz5v6h/foo\x00\x00\x00\x00\x00\x00'
[73299 refs]
So, without the os.lchmod() call, the length is returned correctly. With it,
it gets returned as 24. Looks like an OS bug.
--
___
Python tracker
<http://bugs.python.org/issue15748>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15747] Various chflags tests failing on FreeBSD/ZFS
Changes by Trent Nelson : -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue15747> ___ ___ 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 added the comment: Oh, heh, yes, I meant double :-) -- ___ Python tracker <http://bugs.python.org/issue15745> ___ ___ 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 added the comment:
Affirmative:
E:\Apps\activestate-python-2.7.2.5-x86>python
ActivePython 2.7.2.5 (ActiveState Software Inc.) based on
Python 2.7.2 (default, Jun 24 2011, 12:21:10) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import test.test_winsound
>>> test.test_winsound._have_soundcard()
False
>>> import winsound
>>> winsound.PlaySound('!"$%&/(#+*', winsound.SND_ALIAS |
>>> winsound.SND_NODEFAULT)
>>>
No exception raised. (No sound is played, either, FWIW.)
I like the approach taken by the method before test_alias_nofallback():
def test_alias_fallback(self):
# This test can't be expected to work on all systems. The MS
# PlaySound() docs say:
#
# If it cannot find the specified sound, PlaySound uses the
# default system event sound entry instead. If the function
# can find neither the system default entry nor the default
# sound, it makes no sound and returns FALSE.
#
# It's known to return FALSE on some real systems.
# winsound.PlaySound('!"$%&/(#+*', winsound.SND_ALIAS)
return
I suspect that'll solve all our problems ;-)
--
___
Python tracker
<http://bugs.python.org/issue15746>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
