[issue4431] Distutils MSVC doesn't create manifest file
Stephen Hansen added the comment: Just to be clear, I ran into this exact issue recently in VS2010 professional as I indicated earlier. I don't know about what should or should not be needed, but the solution in the original comment fixed it exactly for me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4431 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4431] Distutils MSVC doesn't create manifest file
Stephen Hansen added the comment:
FYI. Windows 8.1, Visual Studio 2010 SP1 Pro just installed, Python 3.3.3; a
random extension did this as a 'test' in its setup.py:
compiler = distutils.ccompiler.new_compiler()
if not compiler.has_function('rand', includes = ['stdlib.h']):
...
And this failed. Further investigation turned brought me here, and adding
/MANIFEST to my ld_args as this patch does fixed it.
--
nosy: +ixokai
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4431
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11124] test_posix failure on the Leopard buildbot
Stephen Hansen me+pyt...@ixokai.io added the comment: This is just http://bugs.python.org/issue7900 all over again. In the meantime, I restarted the buildslave and re-submitted the jobs so the failures should go away. (I still advocate that the test is fundamentally wrong/flawed on Mac and should be disabled at least -- but that discussion is over on issue7900). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7108] test_commands.py failing on OS X 10.5.7 due to '@' in ls output
Stephen Hansen me+pyt...@ixokai.io added the comment: I can confirm that this test has been failing on my slave, and that the patch fixes it. Recommend commit. Red is bad. -- assignee: - ronaldoussoren components: +Macintosh nosy: +ixokai, ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7108 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10820] 3.2 Makefile changes for versioned scripts break OS X framework installs
Stephen Hansen me+pyt...@ixokai.io added the comment: FYI, The patch applied cleanly to branches/py3k; I then built a framework build (universal), installed it and ran the test-suite. I had two failures, but I don't know if either is related. The first was the tk tests didn't pass, but I'm not sure if there was something special I need to do to get tk compiled universal in a framework build-- I'll look into it. But this one perplexes me: Wimp:build pythonbuildbot$ ./python.exe -m test.regrtest test_site [1/1] test_site test test_site failed -- Traceback (most recent call last): File /Users/pythonbuildbot/32test/build/Lib/test/test_site.py, line 225, in test_getsitepackages self.assertEqual(len(dirs), 2) AssertionError: 3 != 2 1 test failed: test_site Wimp:build pythonbuildbot$ ./python.exe Python 3.2b2+ (py3k:87899M, Jan 10 2011, 11:08:48) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type help, copyright, credits or license for more information. import site site.getsitepackages() ['/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages', '/Library/Frameworks/Python.framework/Versions/3.2/lib/site-python', '/Library/Python/3.2/site-packages'] This machine fwiw never had any Python 3.x installed anywhere: in fact it was an almost pure stock 10.5 with buildbots put on it. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10820 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10881] test_site and macframework builds fails
New submission from Stephen Hansen me+pyt...@ixokai.io: With the latest from branches/py3k, in a framework build, I get: Wimp:build pythonbuildbot$ ./python.exe -m test.regrtest test_site [1/1] test_site test test_site failed -- Traceback (most recent call last): File /Users/pythonbuildbot/32test/build/Lib/test/test_site.py, line 225, in test_getsitepackages self.assertEqual(len(dirs), 2) AssertionError: 3 != 2 1 test failed: test_site Wimp:build pythonbuildbot$ ./python.exe Python 3.2b2+ (py3k:87899M, Jan 10 2011, 11:08:48) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type help, copyright, credits or license for more information. import site site.getsitepackages() ['/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages', '/Library/Frameworks/Python.framework/Versions/3.2/lib/site-python', '/Library/Python/3.2/site-packages'] Those three dirs look correct for me, but the test is written to find exactly two from site.getsitepackages() -- the code, however, adds an extra in the event of framework builds. -- assignee: ronaldoussoren components: Macintosh, Tests messages: 125919 nosy: ixokai, ronaldoussoren priority: normal severity: normal status: open title: test_site and macframework builds fails versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10881 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10881] test_site and macframework builds fails
Stephen Hansen me+pyt...@ixokai.io added the comment: ... oops! Apparently dupe. Forgot to search first. Ignore. -- resolution: - duplicate status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10881 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10881] test_site and macframework builds fails
Changes by Stephen Hansen me+pyt...@ixokai.io: -- superseder: - pep-0370 on osx duplicates existing functionality ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10881 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10092] calendar does not restore locale properly
Stephen Hansen me+pyt...@ixokai.io added the comment: On windows, France may work and fr_FR may not; yet on OSX its exactly the opposite. Its not consistant across platforms. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10092 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10500] Palevo.DZ worm msix86 installer 3.x installer
Stephen Hansen me+pyt...@ixokai.io added the comment: Latest Norton 360 fully updated has it clean; further, File Insight has it marked as Trusted (thousands of Norton users have had the same file installed for over a month with no reported trouble). Seems clean to me. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10500 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10500] Palevo.DZ worm msix86 installer 3.x installer
Stephen Hansen me+pyt...@ixokai.io added the comment: I downloaded that linked MSI again (as its different from the one originally reported)-- and it too is still coming up as clean. I would suggest that its clearly either a false positive as Jesús is suggesting... or something on your side or between you and python.org is infecting it as or right after you download it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10500 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7900] posix.getgroups() failure on Mac OS X
Stephen Hansen me+pyt...@ixokai.io added the comment: On 11/16/10 5:44 AM, Ronald Oussoren wrote: Ronald Oussoren ronaldousso...@mac.com added the comment: Please explain how the failure can be reproduced. I have. But to do so more directly: 1. Launch Terminal.app; leave the window console open. 2. Run: id -G 3. Run: python 4. Type: import posix; posix.getgroups() 5. Go into System Preferences, add a user. 6. Type again, posix.getgroups(): notice, the values have not changed. 7. Either os.system(id -G) or ^D and type id -G: in either case, these values *have* changed. Tested both. I've done some testing on my machine using Apple's copy of python 2.6.1 (on OSX 10.6), which has the same getgroups implementation as the current heads of the active branches. As I said, the slave is running the latest on 10.5. Perhaps its a platform bug which is fixed in 10.6: either way, the test is declaring behavior is true that it shouldn't, I think. Perhaps the test should only be skipped on 10.5? I am happy to provide a patch which tests sys.platform == darwin and then runs sw_vars to make only skip 10.6. I verified posix.getgroups() on 10.6 does not appear to exhibit this behavior on my SL slave. However, that box does a LOT, so I can't vouch for its 'purity' like the 10.5 box. Was the buildbot started using launchd (the recipe at http://buildbot.net/trac/wiki/UsingLaunchd seems correct)? If not, how is it started? It was started with launchd, yes: with a variation of that recipe. However as I stated, the behavior can be readily reproduced directly in Terminal. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2901] error: can't allocate region from mmap() when receiving big chunk of data
Stephen Hansen me+pyt...@ixokai.io added the comment: I can try to do some testing to reproduce w/ 2.7: 2.5 was IIRC 32-bit on leopard by default though, so should I force a non-64-bit build to test this? I'm not entirely sure if that'll change things, but want to make sure. I can test with both 2.5 and 2.7 on leopard. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2901 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7900] posix.getgroups() failure on Mac OS X
Stephen Hansen me+pyt...@ixokai.io added the comment: The test is clearly verifying a *wrong* assumption: that id -G will match posix.getgroups() which simply does not hold on OSX. I can reproduce this reliably on a completely clean, brand new installation of 10.5: from there the only things that have been done to the box is updating to 10.5.8, and then downloading the latest XCode tools that run on Leopard. From here, launch Terminal: leave the console open. Run id -G; then run python and look at posix.getgroups(). Now, go into System Preferences and add a new user. Don't do anything else. Don't change anything with existing user. In the console that was already open, do id -G again. Now run python again, and do posix.getgroups() -- those no longer match. Clearly IMHO the assumption that the test is declaring to be an expected result simply is not true in a OSX-Unix environment. Yes, if I go and *edit the actual slave user* then surely I can expect failures until I restarted the buildslave. But, if by merely adding a user causes a change to the buildslaves user by no action of my own, and that causes this test to be invalid... the test itself seems to be founded on assumptions which simply are not reliably true. I understand disabling the test means os.getgroups() will no longer be tested on OSX: and yet, the current situation is a specific behavior of os.getgroups() is tested which is *not* actually the guaranteed behavior of that operation. There is at least one very easy to reproduce situation in which id -G and posix.getgroups() do not match: I don't know if there are more. But for the test to assert the truth that its only correct when they match seems to be a mistake. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7900] posix.getgroups() failure on Mac OS X
Stephen Hansen me+pyt...@ixokai.io added the comment: This test is failing again, and IIUC, largely due to the same sort of issues: http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.1/builds/65 I was able to track down what exactly caused it to fail in this case on my box, though. Whatever posix.getgroups() ends up calling, appears to be tied to the current users login -- or at least, doesn't get updated when new groups are added to the user. This failure happened because at some point after the buildbot was up and running, I added a new user to the machine (totally unconnected to the existing buildbot runner): this caused a new group to be added to the buildbot runner's user. id -G starts returning that group immediately, but posix.getgroups() returns the same list as it had before. I was able to further reproduce it in Terminal, by having a console open, and compiling 3.1 there then adding a user, and running the test. It fails. Opening up a new terminal window, running the test-- and it succeeds. The original console continues to fail. -- nosy: +ixokai versions: +Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7900] posix.getgroups() failure on Mac OS X
Changes by Stephen Hansen me+pyt...@ixokai.io: -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7900] posix.getgroups() failure on Mac OS X
Stephen Hansen me+pyt...@ixokai.io added the comment: Well, yes: the result of posix.getgroups is not a bug in Python, but is it a bug in the test? Should it be skipped on OSX, or some other solution? Having buildbots fail because of something that's expected behavior is bad, isn't it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10340] asyncore doesn't properly handle EINVAL on OSX
Stephen Hansen me+pyt...@ixokai.io added the comment: I can verify the problem exists in asyncore at release27-maint on the mac, and that the below patch fixes it. After applying, I ran a full regrtest and nothing new broke. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10237] failure in Barrier tests
Stephen Hansen me+pyt...@ixokai.io added the comment: FWIW, my snow leopard slave isn't slow at all so I doubt there's a timeout related to machine speed going on here, as its failing thus: test test_threading failed -- Traceback (most recent call last): File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/lock_tests.py, line 784, in test_default_timeout self.run_threads(f) File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/lock_tests.py, line 615, in run_threads f() File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/lock_tests.py, line 783, in f self.assertRaises(threading.BrokenBarrierError, self.barrier.wait) AssertionError: BrokenBarrierError not raised by wait Its actually a really spammy sort of failure with a lot of errors before it, which may or may not shed more light on the situation: http://www.python.org/dev//buildbot/3.x.stable/builders/x86%20Snow%20Leopard%203.x/builds/267/steps/test/logs/stdio This was r85883, so after the increase in the timeout. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10236] Sporadic failures of test_ssl
New submission from Stephen Hansen me+pyt...@ixokai.io: Another sporadic failure I've noticed since setting up my buildbot; test_ssl keeps going down. This one I have a hard time analyzing with the tests output, but the latest is: http://www.python.org/dev/buildbot/all/builders/x86%20Snow%20Leopard%203.x/builds/250 There's this part in the log: test_get_server_certificate (test.test_ssl.NetworkedTests) ... [Errno 1] _ssl.c:390: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Verified certificate for svn.python.org:443 is [...pem...] ok There's an errno printed there, but then more debugging for that same test-- and an 'ok'-- so I don't see the FAIL message I'm expecting. So to my naive reading, it seems that it is running once and failing, then re-running in verbose and /not/ failing (and that the error-like message there may not be an error). So, the original problem is a mystery. Or I'm totally reading it wrong. Either way, I've seen this several times and am not sure how to further debug it. Any suggestions or pointers are welcome. Or fixes :) -- messages: 119932 nosy: ixokai priority: normal severity: normal status: open title: Sporadic failures of test_ssl versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10236 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10236] Sporadic failures of test_ssl
Changes by Stephen Hansen me+pyt...@ixokai.io: -- components: +Library (Lib), Tests type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10236 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10116] Sporadic failures in test_urllibnet
Stephen Hansen me+pyt...@ixokai.io added the comment: New patch, sans trailing whitespace. Ahem. -- Added file: http://bugs.python.org/file19398/issue10116-nowhitespace.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10116] Sporadic failures in test_urllibnet
Changes by Stephen Hansen me+pyt...@ixokai.io: Removed file: http://bugs.python.org/file19390/issue10116.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7351] Rename BadZipfile to BadZipFile for consistency
Stephen Hansen me+pyt...@ixokai.io added the comment: You may not care about backwards compatibility, but introducing a breaking change in 3.2 for mere style-conformity is not OK, IMO. If the patcher insists on it being a breaking change, it should be rejected. FWIW, this casing is sufficiently bizarre and inconsistent in the module itself, that it seems clearly wrong and likely to produce difficulties for people using it-- so although I'm not upgrading to Python3 anytime soon, I'd really like to change my code to be BadZipFile when I do, so I'd be +1 with an alias. :) -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7351 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7351] Rename BadZipfile to BadZipFile for consistency
Stephen Hansen me+pyt...@ixokai.io added the comment: Considering I do use zipfiles a lot, I slightly care about this (at least, eventually)-- I'm attaching a new patch, with doc and test changes as well (and the compatibility alias). What convinced me was looking at test_zipfile, and noticing how often it actually confused the issue in comments at least, between typing BadZipfile and BadZipFile. Dunno if I worded the doc-change well, so you may want to adjust that. -- Added file: http://bugs.python.org/file19389/issue7351-complete.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7351 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7351] Rename BadZipfile to BadZipFile for consistency
Stephen Hansen me+pyt...@ixokai.io added the comment: Oh: and I tested it against branches/py3k in the head, it applies cleanly and builds, and test_zipfile runs without error. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7351 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10116] Sporadic failures in test_urllibnet
Stephen Hansen me+pyt...@ixokai.io added the comment: The attached patch wraps all the calls to the internet in support.transient_internet; I ran it against 3.x and it passed, and then I ran it for quite awhile with the -F option, and encountered one event that I believe would previously had resulted in one of these sporadic failures, and it resulted in a skipped 'resource not available' message. I left in the previous 'retry' code, just by virtue of changing as little as possible. I can adjust if its desired. I believe that transient_internet won't capture EBADF: so if that particular sporadic failure happens again, I'll post up a new issue about it. -- keywords: +patch Added file: http://bugs.python.org/file19390/issue10116.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10154] locale.normalize strips - from UTF-8, which fails on Mac
Stephen Hansen me+pyt...@ixokai.io added the comment:
Mark, the locals() right before if encoding: (line 399) are:
locale.normalize(en_US.UTF-8)
{'code': 'en_US.ISO8859-1', 'langname': 'en_US', 'encoding': 'UTF8',
'norm_encoding': 'utf_8', 'defenc': 'ISO8859-1', 'localename': 'en_US.UTF-8',
'lookup_name': 'en_us.utf-8', 'fullname': 'en_us.utf-8'}
'en_US.UTF8'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10154
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10092] calendar does not restore locale properly
Stephen Hansen me+pyt...@ixokai.io added the comment: I can't be entirely sure, because a) I have never even glanced at the calendar module, and b) my locale-fu is very weak, but my buildbot has consistently failed on this test since this commit: == ERROR: test_localecalendars (test.test_calendar.CalendarTestCase) -- Traceback (most recent call last): File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_calendar.py, line 264, in test_localecalendars locale=def_locale).formatmonthname(2010, 10, 10) File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/calendar.py, line 520, in formatmonthname with different_locale(self.locale): File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/calendar.py, line 490, in __enter__ _locale.setlocale(_locale.LC_TIME, self.locale) File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/locale.py, line 538, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting I will look into it in more detail tomorrow to try to provide more meaningful feedback, but I think this fix has introduced a problem. If someone sees what before I have time to dig into this unfamiliar territory, yay. :) -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10092 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10154] locale.normalize strips - from UTF-8, which fails on Mac
New submission from Stephen Hansen me+pyt...@ixokai.io: In the course of investigating issue10092, Georg discovered that the behavior of locale.normalize() on Mac is bad. Basically, en_US.UTF-8 is how the correct locale string should be spelled on the Mac. If you drop the dash, it fails: which locale.normalize does, so you can't pass the return value of the function to setlocale, even though that's what its documented to be for. If that isn't clear, this should demonstrate (from /branches/py3k): Top-2:build pythonbuildbot$ ./python.exe Python 3.2a3+ (py3k:85631, Oct 17 2010, 06:45:22) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type help, copyright, credits or license for more information. import locale [51767 refs] locale.normalize(en_US.UTF-8) 'en_US.UTF8' [51770 refs] locale.setlocale(locale.LC_TIME, 'en_US.UTF8') Traceback (most recent call last): File stdin, line 1, in module File /Users/pythonbuildbot/test/build/Lib/locale.py, line 538, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting [51816 refs] locale.setlocale(locale.LC_TIME, 'en_US.UTF-8') 'en_US.UTF-8' [51816 refs] The precise same behavior exists on my stock/system Python 2.6, too, fwiw. (Not that it can be fixed on 2.6, but maybe 2.7?) -- assignee: ronaldoussoren components: Library (Lib), Macintosh messages: 119213 nosy: ixokai, ronaldoussoren priority: normal severity: normal status: open title: locale.normalize strips - from UTF-8, which fails on Mac type: behavior versions: Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5117] os.path.relpath problem with root directory
Stephen Hansen me+pyt...@ixokai.io added the comment: FYI, this fix broke some buildbots: http://www.python.org/dev/buildbot/all/builders/x86%20Snow%20Leopard%202.7/builds/50 for instance. Gentoo too. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5117 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10116] Sporadic failures in test_urllibnet
Stephen Hansen me+pyt...@ixokai.io added the comment: I'll run the test in -F mode for a few hours to see if it comes up or not: but its hard for me to say one way or the other if anything has fixed or not fixed it, as the failure only came up every once in awhile. But I'll look. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10116] Sporadic failures in test_urllibnet
Stephen Hansen me+pyt...@ixokai.io added the comment: Okay, at -r85630 on branches/py3k, I ran: ./python.exe -m test.regrtest -uall -F test_urllibnet And after 158 retries, got the same error I had before: test test_urllibnet failed -- Traceback (most recent call last): File /Users/pythonbuildbot/test/build/Lib/urllib/request.py, line 1504, in open return getattr(self, name)(url) File /Users/pythonbuildbot/test/build/Lib/urllib/request.py, line 1676, in open_http return self._open_generic_http(http.client.HTTPConnection, url, data) File /Users/pythonbuildbot/test/build/Lib/urllib/request.py, line 1659, in _open_generic_http response = http_conn.getresponse() File /Users/pythonbuildbot/test/build/Lib/http/client.py, line 1027, in getresponse response.begin() File /Users/pythonbuildbot/test/build/Lib/http/client.py, line 347, in begin version, status, reason = self._read_status() File /Users/pythonbuildbot/test/build/Lib/http/client.py, line 303, in _read_status line = str(self.fp.readline(), iso-8859-1) File /Users/pythonbuildbot/test/build/Lib/socket.py, line 267, in readinto return self._sock.recv_into(b) socket.error: [Errno 9] Bad file descriptor -- resolution: fixed - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10116] Sporadic failures in test_urllibnet
New submission from Stephen Hansen me+pyt...@ixokai.io: Ever since running the snow leopard buildslave, I've had sporadic failures in test_urllibnet. At first I thought it was just a net glitch on my machine or something, as immediately re-running the tests made it go away: but this most recent one: http://www.python.org/dev//buildbot/builders/x86%20Snow%20Leopard%203.1/builds/20/steps/test/logs/stdio happened while I was very much monitoring and using the network on the machine for other purposes, and everything was fine in general. So, I went and looked into test_urllibnet to try to figure out why, and I notice that some of the tests use code to retry on IOErrors, and some don't-- and this test that failed in particular is one that doesn't. So: anyone have a better idea of what's going wrong, or is it just that hey, the active network tests are a bit flaky and all should use _open_with_retry instead of just some as is the case now? [If the latter, I can do a patch] FWIW, I've only seen this on the 3.1 and 3.x buildslaves, but have seen it on both of those more then once. But I don't know that its a 3.x specific issue: those builds get run more often then the 2.7 one, so have more chances to run into a sporadic issue. -- components: Tests messages: 118772 nosy: ixokai priority: normal severity: normal status: open title: Sporadic failures in test_urllibnet versions: Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8445] buildbot: test_ttk_guionly failures (test_traversal, test_tab_identifiers, test_identify, test_heading_callback)
Stephen Hansen me+pyt...@ixokai.io added the comment: For the record, everything (2.7, 3.1, and 3.x) runs this test successfully now. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4388] test_cmd_line fails on MacOS X
Stephen Hansen me+pyt...@ixokai.io added the comment: FWIW, this still happens on the latest of /branches/py3k, when LANG does not match up to the enforced fs encoding-- which for me happened when I ran the buildslave under launchd. I was finally able to reproduce it, and after doing so, verified that cmdline_encoding-2.patch on issue9992 fixed it. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4388 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodedif locale and fileystem encodings aredifferent
Stephen Hansen me+pyt...@ixokai.io added the comment: This issue seems to be the cause of issue4388 -- and cmdline_encoding-2.patch fixes it, fwiw. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8445] buildbot: test_ttk_guionly failures (test_traversal, test_tab_identifiers, test_identify, test_heading_callback)
Stephen Hansen me+pyt...@ixokai.io added the comment: I'm still getting this error on the release27-maint branch on my Snow Leopard slave, and the issue8445.diff fixes it: will this fix be backported? I tested issue8445.diff and it applies cleanly, and fixes the issue. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8445] buildbot: test_ttk_guionly failures (test_traversal, test_tab_identifiers, test_identify, test_heading_callback)
Stephen Hansen me+pyt...@ixokai.io added the comment: BTW, release31-maint appears to have the same issue, its fouling up that build on my slave too. I tried applying the ttk3k.patch but it didn't apply cleanly, and I'm completely ignorant of TK so can't really figure out what's different between the 3.1-3.2 version to try to adjust the fix and test it out. Then again I'm not sure if there's still going to be test-fixes applied to 3.1. So its possible you can just ignore this comment :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
