Hi Pere, i think i fixed (most of) the issues behind the failures on OSX. could you do a "pip install -i http://pypi.testrun.org -U pytest" and rerun the tests and send along the full output if there remain issues?
thanks, holger On Fri, Oct 28, 2011 at 21:08 +0000, holger krekel wrote: > On Fri, Oct 28, 2011 at 01:32 +0200, Pere Martir wrote: > > On Thu, Oct 27, 2011 at 2:15 PM, Ronny Pfannschmidt > > <ronny.pfannschm...@gmx.de> wrote: > > > On 10/27/2011 01:54 PM, Pere Martir wrote: > > >> By the way, where is the CI server please ? > > > http://hudson.testrun.org/job/pytest/ > > > > It seems to be a problem specific to Mac OS X. Since there is no Mac > > OS X slave, I suppose that the unit tests on this platform has not > > been paid much attention ? > > right, is the reason i asked for a build host in my last mail. > > > It's strange that if I only executed a subset of unit tests with -k, > > they don't fail. For example: > > > > python pytest.py -k TestGenerator > > > > But as you can see in the attachment of my previous post, they failed. > > It's also true for many other test suites, any clue ? > > > > on my OSX 10.8 all tests pass FWIW. > > > By the way, I fixed a problem. The failure of > > TestSession.test_parsearg is because on Mac OS X /var is actually a > > symbolic link of /private/var, and many other path under /. Patching > > TmpDir to return realpath fixes the problem. This doesn't fix many > > failures. "tox -e py26" still blocks at test_pdb forever, for example. > > > > I feel like that the other failures are due to the other bugs. Is it > > worthwhile spending time looking at the code ? Or it's probably the > > problem of my configuration/environment (not the source code) ? > > I don't know. could you send a new "py.test testing" log with the > x.realpath() patch applied? > > Is there a way to log into your OSX machine by chance? > > thanks, > holger > _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
