collective.recipe.zope2install needs better diagnostics when dealing with bad Zope tarball
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
collective.buildout |
New
|
Undecided
|
Unassigned |
Bug Description
If there's a transient error or an interruption of the execution of the collective.
Restarting the buildout results in the recipe discovering the partial tarball, which then attempts to extract it, resulting in a stack trace:
----
An internal error occurred due to a bug in either zc.buildout or in a recipe being used
Traceback (most recent call last):
...
File: "/usr/lib64/
raise IOError, "CRC check failed"
IOError: CRC check failed
----
Users, unaware of any issue, may repeatedly re-try the buildout to no avail. Deleting the partial tarball is the only way to make progress, but Buildout newbies may not realize there is even a "downloads" directory or a download cache specified elsewhere by a particular buildout or user default.cfg file.
Better diagnostics would certainly help. And we could provide excellent diagnostics by including an md5sum as an option to the recipe: it could flag a bad or partial tarball instantly.
I've seen this too, even in the case where I rm -rf'ed the original buildout checkout dir, and then reran python bootstrap.py -d and then ../bin/buildout. It looks like b/c of the transient nature of the d/l, it can keep getting back *.tar.gz files for Zope.
I was running this on Cent OS 5, with python 2.4.