Description of problem:
When making rawhide:
Traceback (most recent call last):
File "/usr/bin/mash", line 96, in <module>
File "/usr/bin/mash", line 77, in main
rc = themash.doCompose()
File "/usr/lib/python2.6/site-packages/mash/__init__.py", line 378, in doCompose
repocache = repocache, comps = True, arch = arch)
File "/usr/lib/python2.6/site-packages/mash/__init__.py", line 215, in _write_files
status = self._makeMetadata(repo_path, repocache, arch, comps, previous = previous_path)
File "/usr/lib/python2.6/site-packages/mash/__init__.py", line 115, in _makeMetadata
File "/usr/lib/python2.6/site-packages/mash/metadata.py", line 191, in run
File "/usr/lib/python2.6/site-packages/mash/metadata.py", line 155, in run
File "/usr/lib/python2.6/site-packages/createrepo/__init__.py", line 367, in doPkgMetadata
File "/usr/lib/python2.6/site-packages/createrepo/__init__.py", line 601, in closeMetadataDocs
File "/usr/lib/python2.6/site-packages/createrepo/__init__.py", line 698, in generate_delta_xml
File "/usr/lib/python2.6/site-packages/createrepo/deltarpms.py", line 48, in __init__
File "/usr/lib/python2.6/site-packages/createrepo/deltarpms.py", line 71, in _getOldInfo
if compobj.read(4)[:3] != "DLT":
File "/usr/lib/python2.6/gzip.py", line 219, in read
File "/usr/lib/python2.6/gzip.py", line 255, in _read
File "/usr/lib/python2.6/gzip.py", line 156, in _read_gzip_header
raise IOError, 'Not a gzipped file'
IOError: Not a gzipped file
mash failed in /mnt/koji/mash/rawhide-20090821/development
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. do xz -> xz deltaing
*** Bug 518656 has been marked as a duplicate of this bug. ***
Do we have any python bindings for xz compression? 'Cause if not, this is going to suck.
Not that I can find.
Ok, there's http://pypi.python.org/pypi/pyliblzma. As far as I can see, it uses xz rather than lzma, but haven't tested it yet (and last release was in February). I'll be away over the next few days, but if no one has done anything with this by the time I get back, I'll see what I can do.
Created attachment 358272 [details]
minor deltarpm compilation fix
Here come some patches; first fixes some needed includes in deltarpm header files.
Created attachment 358273 [details]
really basic bindings
Patch #2: Adds some basic deltarpm python bindings for reading delta rpms.
Created attachment 358274 [details]
createrepo: Use said bindings
And this patches createrepo to use these bindings.
Comments? (I have no idea if upstream deltarpm wants to take this.)
I'm a little afraid of the basic deltarpm python bindings and the related patch to createrepo unless this change gets upstream. Otherwise it binds createrepo to a very special ver of deltarpm which I'd like to avoid.
I can see that; I just think it's simplest in the long run if createrepo doesn't have to parse the deltarpms itself.
no dispute - but I don't want to put this patch into createrepo unless we've gotten it signed off by upstream deltarpm maintainers.
I've sent an e-mail (cc'd to Bill) to Michael Schroeder (upstream deltarpm) asking if he has a problem with adding these bindings to deltarpm, and have still not received a response. I have no problem adding them in, but, for something this large, I really want his ACK.
If he's fine with it, I'll add the patch upstream.
Ok, the first two patches have been committed to upstream deltarpm and are available at http://koji.fedoraproject.org/koji/taskinfo?taskID=1645765
The bindings are now in a subpackage cunningly called python-deltarpm.
applied the patch and it is koji as createrepo-0.9.8-2.fc12
If it works okay - I'll apply it upstream.