[08:22] <jam> vila, jelmer: bzr's PQM seems to be working again, so if you want to submit your approved patches, go for it. I tried to send some things through, though at least one had a genuine failure in the test suite.
[08:22] <vila> jam: thanks, did send mine yesterday, worked fine
[08:23] <vila> jam: what was needed in the end ?
[08:27] <jam> vila: we needed python-testools reinstalled, then finally 'subunit' itself to have 'subunit-stats' available.
[08:27] <jam> oh, and *not* have bzrtools installed
[08:27] <jam> because it complains to stderr about not being compatible
[08:27] <vila> weird, wonder how this got messed up (-stats and bzrtools)
[08:30] <jam> vila: not sure, uninstalling python-pkg_resources chained to some stuff we needed (like python-testtools), it is possible the re-install process brought more than we wanted.
[08:30] <jam> also bzrtools is only complaining because it is the system 2.5.1 version, and bzr.dev is now 2.6.?
[08:32] <vila> possibly
[15:53] <joey> any blue/bzr team awake here?
[15:54] <joey> Need some help with https://bugs.launchpad.net/bzr/+bug/1021537
[15:58] <vila> jelmer: did you ever reproduce this one ?
[15:59] <jelmer> hi joey, vila
[15:59] <jelmer> yeah, it's fairly easy to reproduce
[15:59] <vila> jelmer: isn't the revid hinting that it was created with bzr-git ?
[15:59] <jelmer> vila: no, bzr-svn
[16:00] <vila> close ;)
[16:00] <joey> howdy, thanks jelmer and vila for being awake and being work-aholics
[16:00] <jelmer> there is invalid data in one of the two branches caused by an old bzr-svn bug
[16:00] <vila> >-/
[16:01] <joey> is there a way to suck the branch down and run a cleanup script on it?
[16:01] <joey> and then push it back up
[16:02] <jelmer> joey: ideally 'bzr reconcile' would take care of this cleanup, but alas it doesn't yet
[16:03]  * joey nods in agreement. 
[16:04] <joey> if it was anything other than gcc or equiv I don't think we'd care as much but since we push out gcc regularly it's a pita and got kiko's attention now
[16:04] <jelmer> joey: if you don't care about the actual history of gcc-linaro, then the simplest thing to do would be to take the last revision from lp:gcc that was merged into lp:gcc-linaro, "rsync --delete -avz" over the existing contents from lp:gcc-linaro and commit it in a single commit
[16:05] <joey> hmm I'd have to have michael hope about that.  It may be possible for us to start a new series as part of normal ops and then fix it that way
[16:06] <joey> I'll update the bug
[16:06] <jelmer> I started looking at this bug a while ago after talking to ams_cs, but then we were pulled away on other stuff
[16:06] <joey> he's in NZ so I think he's off until sunday
[16:07] <jelmer> There should be another bug elsewhere with more details, but I can't find it at the moment.
[16:09] <joey> jelmer: gotcha. If we can't resync because we need history, is there another method we can use?
[16:14] <jelmer> joey: I think you would have to replay the history and make sure text revisions are recorded consistently with the way they are in lp:gcc
[16:14] <joey> ok thanks
[16:15] <jelmer> (it would probably involve some scripting on top of bzrlib)
[16:16] <joey> sounds like a pita ...
[16:16] <jelmer> yeah, that would be fairly tricky :(
[16:17] <joey> Ok I've updated the comments in the bug for Michael and we'll see what he wants to do with it.  Hopefully the resync will be viable.
[16:17] <joey> Thanks for your time
[16:19] <jelmer> np
[22:17] <tgm4883> How do I revert a revison that I have already pushed to a shared branch in the shared tree? I've done a bzr uncommit locally which removed the bad commit, but I don't see a nice way to push this change since I'm now technically a commit behind the shared tree
[22:17] <glyph> tgm4883: you have to do a reverse-merge
[22:17] <beuno> or push --overwrite
[22:17] <beuno> but make sure there's no subsequent revisions  :)
[22:19] <tgm4883> ok, the reverse-merge sounds more like the way to go if there are multiple people capable of doing commits
[22:19] <tgm4883> the push --overwrite sounds better if it's just me
[22:19] <glyph> tgm4883: yes, exactly
[22:19] <glyph> tgm4883: I believe the appropriate voodoo is 'bzr merge . -r -1..-2'
[22:29] <tgm4883> glyph beuno that works. Thanks for the info
[22:30] <glyph> tgm4883: Glad to help :)