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.) _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig