Hi.
I have a bzr repo on which bzr check fails. It is here:
http://arch.gna.org/guile-gnome/bzr/pkg
Here's the traceback: http://paste.ubuntu.com/19674/
I am running bzr r3494 on a fedora 9 system.
Relevant IRC log:
<jam> wingo-tp: there are different variations on what causes KnitCorrupt to be raised
<jam> sometimes it is genuine disk corruption
<jam> the specific case listed in that bug has been fixed
<jam> Do you know if that is what you are experiencing?
<vila> jam: for a start, I want to have a look at the tests adaptation/application since lifeless said he want to get rid of all classes
<wingo-tp> jam: i pulled from bzr today, so if that bug is fixed, it is not the bug that i am experiencing
<wingo-tp> disk corruption would be the badness
<jam> wingo-tp: are you seeing "Knit *inventory* corrupt"
<jam> or just "Knit Corrupt" ?
<jam> (do you have the traceback to paste)?
<jam> !past
<ubottu> Factoid past not found
<jam> !paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<wingo-tp> i do have it, /me goes to pastebin
* andrea-bs has quit ("rm -r andrea-bs")
<wingo-tp> http://paste.ubuntu.com/19674/
<jam> wingo-tp: any chance you would have had 2 conversions of the arch tree
<jam> possibly with one of them having more history than the other?
<wingo-tp> perhaps it had something to do with the fact that it was imported from arch a long time ago, but i have upgraded it since -- i first saw this error when trying to upgrade to ricj-root-packs
<wingo-tp> jam: this is possible, i suppose
<jam> wingo-tp: so what it *could* be, is that at one point you did a conversion with a different amount of history
<jam> which caused the "last-modified" fields in the inventories to differ
<jam> at some point after that, the branches were merged together
<jam> and they didn't notice that the inventories they were referencing had a different text
<jam> and so they pulled across a delta which technically only applies to the *other* base
<jam> and thus when applied to this base, the sha-1 doesn't match
<jam> I would have thought you would encounter the error sooner rather than later
<jam> I probably can hack something together as a workaround, but a real fix is probably a bit involved.
<wingo-tp> odd.. i mean, i can bzr log all of the branches in this repo
* bigdo2 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) has joined #bzr
* jaypipes has quit (Read error: 110 (Connection timed out))
<jam> wingo-tp: we don't need inventories to do 'bzr log'
<jam> just revisions
<jam> different place
<wingo-tp> ok
<jam> if you did "bzr log --verbose"
<jam> Then you would probably get the failure
* jaypipes (n=jpipes@nat/sun/x-bc98c86c402debb9) has joined #bzr
<wingo-tp> indeed i do get the failure
<wingo-tp> after a merge with another arch branch
<jam> wingo-tp: is this a recent conversion?
<wingo-tp> no it is not
<wingo-tp> about august 2006
<jam> wingo-tp: is this a recent merge of that other branch, though?
<wingo-tp> jam: nope
<jam> the guile-gnome-pkg--release--0--base-0 branch?
<wingo-tp> no, i completely left arch around august of 2006
* quatauta has quit ("Verlassend")
<jam> I'm talking mostly about a branch derived from that revision
<jam> not merging that revision specifically
<wingo-tp> and have not done merges from other branches that hadn't been forked off of this one
<wingo-tp> i guess what you are saying is possible, but i don't think so.
<jam> wingo-tp: I'm just trying to figure out why you are hitting it *now* rather than earlier
<wingo-tp> jam: well, i've never run bzr check before
<jam> do you have any idea of things that have been happening recenty?
<jam> oh, well I suppose that might do it
<wingo-tp> so if a previous bzr upgrade happened and did not run bzr check...
<jam> if you never access that revision, it wouldn't ever find it broken
<wingo-tp> that very well could be
<jam> specifically, we check sha1 sum whenever we extract the full text
<jam> but you may have never needed to do that
<wingo-tp> right
<jam> I'm guessing you have a very small few nodes that are effected
* cody-somerville has quit (Remote closed the connection)
<jam> and it is restricted to a specific local part of ancestry
<jam> wingo-tp: how high of a priority is this for you, as in, does it block something you are trying to do?
<jam> I don't have a lot of time to write a workaround right now, unless you really need it
<jam> wingo-tp: but I *would* ask you to submit a new bug
<jam> if you can, link to the branch that shows the problem
* bigdog has quit (Connection timed out)
<wingo-tp> jam: i can wait a while, i think;
* trepca has quit ()
<wingo-tp> how do you think this will affect people who have checkouts of this branch? they will have to re-pull, no? will all the sha1's be different, like in git?
<wingo-tp> it's http://arch.gna.org/guile-gnome/bzr/pkg/
<jam> wingo-tp: only a few local sha1s will be changed
* BasicOSX (<email address hidden>) has joined #bzr
<jam> I'm not sure how we would be able to propagate that to everyone
<jam> it shouldn't change the whole ancestry
<wingo-tp> i should just tell everyone to branch again, no?
<jam> wingo-tp: they would have to clear out any repository that they have
<wingo-tp> ok
<jam> It is probably easier to just have them all run whatever fix I come up with
<wingo-tp> (thanks for looking at this, btw)
traceback is
(g-wrap guile) wingo@unquote:
bzr: ERROR: bzrlib.
sha-1 c17d607f36f8f3d
of reconstructed text does not match
expected 1549a9422b50217
for version Arch-1:<email address hidden>
Traceback (most recent call last):
File "/usr/lib/
return run_bzr(argv)
File "/usr/lib/
ret = run(*run_argv)
File "/usr/lib/
return self.run(
File "/usr/lib/
check(
File "/usr/lib/
repo_result = branch.
File "/usr/lib/
return unbound(self, *args, **kwargs)
File "/usr/lib/
return self._check(
File "/usr/lib/
result.check()
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
tree = self.repository
File "/usr/lib/
return unbound(self, *args, **kwargs)
File "/usr/lib/
inv = self.get_
File "/usr/lib/
return unbound(self, *args, **kwargs)
File "/usr/lib/
return self.get_
File "/usr/lib/
return unbound(self, *args, **kwargs)
File "/usr/lib/
return self.iter_
File "/usr/lib/
texts = self.get_
File "/usr/lib/
return [''.join(l) for l in self.get_
File "/usr/lib/
text_map, content_map = self._get_
File "/usr/lib/
(actual_sha, ...