This is the first[total unknown] failure:
['\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n',
'\n']
which has:
sha - c9c5790d04d50eb9c94a8300529112a79eff180a
expected sha - 45cb77d073b02f8e0376f2840c29375931e9b554
key - ('Arch-1:%guile-gnome-pkg--release--0--patch-9',)
stripping the last \n in case its a \n trailing problem:
(Pdb) print sha_strings(text[:-1] + [""])
4bc10a37bd929b0e091c93147c771bef12d37e55
So its not the previously fixed bug.
As the gzip hunk decompressed ok, its not a random bit error (though it could be a multi-bit error).
I think the most likely explanation is a transplanted inventory delta with a bad basis.
E.g.:
repo 1 has rev basis, sha X
repo 2 has rev basis, sha Y
repo 2 creates a new patch ('Arch-1:%guile-gnome-pkg--release--0--patch-9',) on top of basis
The line delta of ('Arch-1:%
guile-gnome-pkg--release--0--patch-9',) is fetched as a delta to repo 1.
This line delta applies to make a sensible inventory but because the
inventory in repo 1 is different (specifically I think it has a
different last-changed in one or more files) the sha1 of the resulting
text does not match.
As a commentary, the restructured full-text based inventory we are
working on is much more resilient against these sorts of confusion
regardless of what api's an importer might use.
To fix this, I'm going to write a repair script for your repository
which will rewrite the inventory file assuming all the content is usable
but the sha's are wrong; and then see if the results look sensible.
-Rob