On Fri, 2010-06-18 at 14:54 +0530, Jitesh Shah wrote:
..snip..
mergerepos is exiting with an error: Traceback (most recent call last): File "/usr/libexec/kojid/mergerepos", line 229, in ? main(sys.argv[1:]) File "/usr/libexec/kojid/mergerepos", line 224, in main merge.write_metadata() File "/usr/libexec/kojid/mergerepos", line 205, in write_metadata mdgen.doRepoMetadata() File "/usr/lib/python2.4/site-packages/createrepo/__init__.py", line 789, in doRepoMetadata rp.getPrimary(complete_path, csum) File "/usr/lib64/python2.4/site-packages/sqlitecachec.py", line 42, in getPrimary self.repoid)) TypeError: Parsing primary.xml error: attributes construct error I'm assuming this is because of the new sha256 checksums introduced a release or two back.This might be related or not, but a while ago I was grappling with the same error in mergerepos. The conclusion was that mergerepos couldn't handle certain unicode (or some random encoding. don't remember) which createrepo can handle. I manually ran the mergerepo command run by koji and looked at the the primary.xml file generated. Removing the packages that did unicode/random-encoding Provides/Requires solved the problem.
I suspect you're right, though it seems the bug is in createrepo. I've just upgraded to createrepo-0.9.8-5 (which meant rebuilding deltarpm for the updated for rpm-4.6.0, and then rebuilding yum-3.2.23-10 for el5), and the bug is gone, though now mergerepo ends with:
19133/16961 - junit-demo-3.8.2-6.4.fc12.x86_64 19134/16961 - rubygem-gettext_rails-doc-2.1.0-2.fc13.noarch 19135/16961 - perl-DateTime-Event-Recurrence-0.16-9.fc13.noarch 19136/16961 - bluez-compat-4.63-3.fc13.x86_64 19137/16961 - perl-XML-XPath-1.13-10.fc13.noarch
I guess it's the new way of doing math. :)
What version of createrepo and yum are on the builders?
Jonathan