[01:20] <tlonim> jelmer: ah, the older ones which I saw similar to them were fixed already but I could still repeat this
[01:21] <jelmer> tlonim: https://bugs.launchpad.net/bzr/+bug/1021537
[01:23] <tlonim> so 'bzr reconcile --canonicalize-chks' ?
[01:25] <jelmer> tlonim: unfortunately that's not sufficient - it takes about 6 months to run that on the gcc repo, and it doesn't fix all instances
[01:26] <tlonim> and that seems to be due to broken repo..if we know the possible commits which caused this, is it possible to fix only those?
[01:28] <jelmer> tlonim: the broken commits are the commits in the existing gcc repositories, on which lp:gcc/1.8 gets stacked
[01:28] <tlonim> hmm
[01:28] <jelmer> tlonim: so in order to fix this, you'd have to do a fresh import of all existing gcc branches in Launchpad, or disable stacking somehow
[01:28] <tlonim> in my case there is no svn bridgeetc.
[01:30] <jelmer> tlonim: the essential problem is that both repositories disagree about the contents of an inventory (most likely a spurious file revision)
[01:33] <jelmer> tlonim: I can't think of any easy workarounds
[01:33] <tlonim> jelmer: so the "missing text keys:" are what caused the issue there?
[01:34] <tlonim> I mean the contents of that list
[01:34] <jelmer> tlonim: not really the texts themselves, rather that the text keys are slightly different in one or more revisions somewhere in the history of the two branches
[01:35] <tlonim> hmm. which two branches, I am not doing a merge here
[01:36] <jelmer> tlonim: you're copying them both into the same repository
[01:36] <tlonim> yeah.. shared-repo
[01:36] <jelmer> tlonim: right, so that repository has only one copy of each revision
[01:38] <jelmer> tlonim: if other data you try to import into that repository references a bit of the ambiguous revision(s), things break
[01:44] <tlonim> jelmer: so there may be something wrong with that branch itself - can I ask the people who merged into that branch to check
[01:45] <jelmer> tlonim: right, so the problem is that one of the two branches has some revisions in it that were imported with an old version of bzr-svn that was buggy
[01:45] <jelmer> tlonim: IIRC it was the linaro branch that actually had the issue in it
[01:46] <tlonim> I don't think we use bzr-svn in my case.. did you see anything related to that in mine
[01:47] <tlonim> jelmer: if I branch it as a non-shared clone, that should fix it for now right
[01:47] <tlonim> btw, I am running
[01:47] <tlonim> bzr reconcile -v  --canonicalize-chks lp:~percona-core/percona-server/release-5.5.32-31.0
[01:47] <tlonim> let me see how long it takes
[01:47] <jelmer> tlonim: that will allow the "bzr branch" commands to complete, but you won't be able to merge the two branches
[01:48] <tlonim> jelmer: btw, this reconcile can be killed anytime without leaving repo inconsistent right
[01:48] <jelmer> tlonim: the lp:gcc-linaro branch was actually created by bzr-svn originally (either bzr-svn directly or a launchpad import)
[01:48] <jelmer> tlonim: the reconcile doesn't help IIRC
[01:48] <jelmer> see my comment on that bug
[01:48] <tlonim> ack
[01:56] <tlonim> anyways, I got this with reconcile http://paste.wnohang.net/f45a3c :) (I guess that is because it is not on sftp or local right)
[02:02] <spiv> tlonim: right
[02:02] <spiv> tlonim: doing it locally will be much faster
[03:05] <jelmer> it'll still be quite slow locally judging  by the comments on that bug report..
[03:12] <spiv> jelmer: "faster" is a relative term :)
[03:12] <jelmer> spiv: fair 'nough :-)