At 06:09 PM 3/26/2008 -0700, zooko wrote:
Bug report #1: ... PYTHONPATH="/home/buildslave/slave-tahoe/dapper/build/support/lib/ python2.4/site-packages" python ./setup.py develop --prefix="/home/ buildslave/slave-tahoe/dapper/build/support" ... Running Nevow-0.9.18/setup.py -q bdist_egg --dist-dir /tmp/ easy_install-rk83KQ/Nevow-0.9.18/egg-dist-tmp-nJ8GSy Traceback (most recent call last): ... File "/home/buildslave/slave-tahoe/dapper/build/ setuptools-0.6c8.egg/setuptools/command/develop.py", line 102, in install_for_development File "/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/ easy_install.py", line 518, in process_distribution
Full details:
https://dev.allmydata.com/buildbot-tahoe/builders/dapper/builds/1427/ steps/compile/logs/stdio
That URL requires login credentials that I don't have. And I need the rest of the traceback to make any sense of this.
Bug report #2:
_get_unpatched() is way too clever for me to spend time trying to understand and debug right now: ... What the heck? I don't want to think about that, so instead we're delisting Ubuntu Dapper as a supported platform, since it is the only one of our supported platforms on which we have this problem.
Looking at what limited information you've given me, I doubt the problem has anything to do with this function, whose operation is ridiculously simple - it finds the first base class that wasn't defined by setuptools, and *was* defined by the distutils. Since the distutils don't define an easy_install *or* develop command, neither one uses _get_unpatched and there should thus be no way that this is causing the weird import situation you have. This is 99.9% unlikely to be related in *any* way to _get_unpatched(), and I'm only hedging the .1% because I'm cautious by nature. :) (Well, that, and there's not a lot of info to go on here.)