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