Attempting to easy_install all 'zope'-related releases using the script at http://svn.repoze.org/playground/trunk/chris/zopesvnchecker/releasechecker.p... , the results were: 122 failures, 67 successes. See http://www.plope.com/static/misc/rcresults-2007-11-14.txt for details. - C
On Nov 14, 2007, at 8:23 AM, Chris McDonough wrote:
Attempting to easy_install all 'zope'-related releases using the script at http://svn.repoze.org/playground/trunk/chris/ zopesvnchecker/releasechecker.py , the results were:
122 failures, 67 successes.
I guess most of these can be fixed by unscrewing the zope.traversing problem. Has anyone done that? Is anyone going to? :) If not, I will just cause I'm tired of reading about it. :( Some of these errors are spurious. For example, ZODB4 shows up as a failure even though there are no distributions. I think the test script needs to check for this case. I also think you should not list as failures anything that failes due to a gcc error. Often this will be due to the absense of libraries (e.g. spread).
See http://www.plope.com/static/misc/rcresults-2007-11-14.txt for details.
I'd really like to see the broken packages get fixed or removed from the cheesehop. Until we can get this cleaned up, as an interim measure, I suggest we hide the broken packages. They'll still be available as download. It will be interesting to see where we stand after the above problems are fixed. Jim -- Jim Fulton Zope Corporation
On Nov 16, 2007, at 9:25 AM, Jim Fulton wrote:
On Nov 14, 2007, at 8:23 AM, Chris McDonough wrote:
Attempting to easy_install all 'zope'-related releases using the script at http://svn.repoze.org/playground/trunk/chris/zopesvnchecker/releasechecker.p... , the results were:
122 failures, 67 successes.
I guess most of these can be fixed by unscrewing the zope.traversing problem. Has anyone done that? Is anyone going to? :) If not, I will just cause I'm tired of reading about it. :(
I would, but I don't have access. I think we just need to take down the bogus zope.app.publisher 3.5.0a2 release. I hate the idea of removing releases (because it "changes history"). But I suspect it's a better solution than releasing zope.app.publisher 3.5.0 and zope.traversing 3.5.0, where zope.app.publisher 3.5.0 depends on 'zope.traversing' instead of 'zope.traversing>=3.5.0a1.dev- r78730'. That would mean we're positing that that release actually works with everything else and I don't know if it does or doesn't.
Some of these errors are spurious. For example, ZODB4 shows up as a failure even though there are no distributions. I think the test script needs to check for this case.
I think the metadata on the cheeseshop needs to get cleaned up:
import xmlrpclib s = xmlrpclib.ServerProxy('http://www.python.org/pypi') s.package_releases('ZODB4') ['4.0a2']
http://pypi.python.org/pypi/ZODB4/4.0a2
I also think you should not list as failures anything that failes due to a gcc error. Often this will be due to the absense of libraries (e.g. spread).
Yep. I'll have to maintain the exclude list manually I think, because the failure output isn't necessarily regular. - C
On Friday 16 November 2007, Chris McDonough wrote:
I guess most of these can be fixed by unscrewing the zope.traversing problem. Has anyone done that? Is anyone going to? :) If not, I will just cause I'm tired of reading about it. :(
I would, but I don't have access. I think we just need to take down the bogus zope.app.publisher 3.5.0a2 release.
What's you PyPI username. I can give you access. BTW, I developed a small tool that makes it easy to grant and revoke access to packages in PyPI called zope.pypisupport (http://svn.zope.org/zope.pypisupport/).
I hate the idea of removing releases (because it "changes history"). But I suspect it's a better solution than releasing zope.app.publisher 3.5.0 and zope.traversing 3.5.0, where zope.app.publisher 3.5.0 depends on 'zope.traversing' instead of 'zope.traversing>=3.5.0a1.dev- r78730'. That would mean we're positing that that release actually works with everything else and I don't know if it does or doesn't.
+1
I also think you should not list as failures anything that failes due to a gcc error. Often this will be due to the absense of libraries (e.g. spread).
Yep. I'll have to maintain the exclude list manually I think, because the failure output isn't necessarily regular.
Yeah, in the KGS I had to do the same. Some packages depend on stuff that is not yet fulfilled by the packages. For example, at least in buildout, the generated pyc files do not point to the correct py source files. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
On Nov 16, 2007, at 11:29 AM, Stephan Richter wrote:
On Friday 16 November 2007, Chris McDonough wrote:
I guess most of these can be fixed by unscrewing the zope.traversing problem. Has anyone done that? Is anyone going to? :) If not, I will just cause I'm tired of reading about it. :(
I would, but I don't have access. I think we just need to take down the bogus zope.app.publisher 3.5.0a2 release.
What's you PyPI username. I can give you access. BTW, I developed a small tool that makes it easy to grant and revoke access to packages in PyPI called zope.pypisupport (http://svn.zope.org/zope.pypisupport/).
chrism - C
I have taken down the zope.app.publisher 3.5.0a2 release from the cheese shop after being punished with the appropriate access. ;-) I suspect that will bite someone, but I think it will bite "the right" people. We'll see how this works out during the bot run tonight (an interactive test of installing zope.tal was promising). - C On Nov 16, 2007, at 10:49 AM, Chris McDonough wrote:
On Nov 16, 2007, at 9:25 AM, Jim Fulton wrote:
On Nov 14, 2007, at 8:23 AM, Chris McDonough wrote:
Attempting to easy_install all 'zope'-related releases using the script at http://svn.repoze.org/playground/trunk/chris/zopesvnchecker/releasechecker.p... , the results were:
122 failures, 67 successes.
I guess most of these can be fixed by unscrewing the zope.traversing problem. Has anyone done that? Is anyone going to? :) If not, I will just cause I'm tired of reading about it. :(
I would, but I don't have access. I think we just need to take down the bogus zope.app.publisher 3.5.0a2 release.
I hate the idea of removing releases (because it "changes history"). But I suspect it's a better solution than releasing zope.app.publisher 3.5.0 and zope.traversing 3.5.0, where zope.app.publisher 3.5.0 depends on 'zope.traversing' instead of 'zope.traversing>=3.5.0a1.dev-r78730'. That would mean we're positing that that release actually works with everything else and I don't know if it does or doesn't.
Some of these errors are spurious. For example, ZODB4 shows up as a failure even though there are no distributions. I think the test script needs to check for this case.
I think the metadata on the cheeseshop needs to get cleaned up:
import xmlrpclib s = xmlrpclib.ServerProxy('http://www.python.org/pypi') s.package_releases('ZODB4') ['4.0a2']
http://pypi.python.org/pypi/ZODB4/4.0a2
I also think you should not list as failures anything that failes due to a gcc error. Often this will be due to the absense of libraries (e.g. spread).
Yep. I'll have to maintain the exclude list manually I think, because the failure output isn't necessarily regular.
- C
participants (3)
-
Chris McDonough -
Jim Fulton -
Stephan Richter