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 f
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', i
Stephen Hansen 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
___
Pyt
Stephen Hansen 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
Changes by Stephen Hansen :
--
superseder: -> pep-0370 on osx duplicates existing functionality
___
Python tracker
<http://bugs.python.org/issue10881>
___
_
Stephen Hansen added the comment:
... oops! Apparently dupe. Forgot to search first. Ignore.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
New submission from Stephen Hansen :
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/buil
Stephen Hansen 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 su
Stephen Hansen 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
<http://bug
Stephen Hansen 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
Stephen Hansen 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
Stephen Hansen 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
Stephen Hansen added the comment:
On 11/16/10 5:44 AM, Ronald Oussoren wrote:
> Ronald Oussoren 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: py
Stephen Hansen 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
Stephen Hansen 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
Changes by Stephen Hansen :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue7900>
___
___
Python-bugs-list mailing list
Unsubscri
Stephen Hansen 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
Stephen Hansen 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
<h
Stephen Hansen 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
Changes by Stephen Hansen :
--
components: +Library (Lib), Tests
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue10236>
___
___
Python-
New submission from Stephen Hansen :
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/b
Changes by Stephen Hansen :
Removed file: http://bugs.python.org/file19390/issue10116.patch
___
Python tracker
<http://bugs.python.org/issue10116>
___
___
Python-bug
Stephen Hansen added the comment:
New patch, sans trailing whitespace. Ahem.
--
Added file: http://bugs.python.org/file19398/issue10116-nowhitespace.patch
___
Python tracker
<http://bugs.python.org/issue10
Stephen Hansen 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
Stephen Hansen 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
<http://bugs.python.org/issue7
Stephen Hansen 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 oft
Stephen Hansen 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 b
Stephen Hansen 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',
&#
New submission from Stephen Hansen :
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 d
Stephen Hansen 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 c
Stephen Hansen 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
<http://bugs.python.
Stephen Hansen 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/
Stephen Hansen 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&#x
New submission from Stephen Hansen :
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:
Stephen Hansen added the comment:
For the record, everything (2.7, 3.1, and 3.x) runs this test successfully now.
:)
--
___
Python tracker
<http://bugs.python.org/issue8
Stephen Hansen 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
Stephen Hansen 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: +i
Stephen Hansen added the comment:
This issue seems to be the cause of issue4388 -- and cmdline_encoding-2.patch
fixes it, fwiw.
--
nosy: +ixokai
___
Python tracker
<http://bugs.python.org/issue9
Stephen Hansen 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
39 matches
Mail list logo
