[00:00] <workthrick> jelmer: thanks for your help, I'll come with more substantial questions tomorrow or thereabouts
[00:00] <jelmer> workthrick: sure
[00:04]  * workthrick reboots
[00:17] <poolie> hi all
[00:19] <jelmer> 'morning poolie
[00:20] <poolie> hi jelmer
[01:06] <spiv> Good morning
[02:19] <wgrant> spiv, poolie: We had some odd branch corruption on the db-devel builder on Friday.
[02:20] <wgrant> http://people.canonical.com/~wgrant/launchpad/pygettextpo.tar.gz is the branch. An upgrade to 2a works, then pulling lp:~launchpad-pqm/pygettextpo/trunk crashes with BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:d34f39faee56e120a83e7cec4fe01c4fd5fd32f6',)]
[02:20] <wgrant> A fresh checkout works fine.
[02:21] <wgrant> Still broken on a daily 2.4 build.
[02:26] <spiv> wgrant: hmm
[02:27] <wgrant> Yes.
[02:27] <spiv> I don't think we've had a report of that error from a fresh upgrade before.
[02:27] <wgrant> check/reconcile are happy.
[02:27] <wgrant> So perhaps the remote branch is bad or something...
[02:28] <spiv> Oh, it's probably not upgrade then, problem an issue in the remote
[02:28] <wgrant> Only just saw that they're happy now.
[02:28] <wgrant> But the remote branch hasn't changed in a year...
[02:29] <spiv> *or* if the remote is fine in isolation too (passes check), then you've possibly got a example that pinpoints a bug in fetch.
[02:30] <spiv> Oh, if the remote is that old, possibly it has the non-canonical-chks issue
[02:30] <spiv> wgrant: try 'bzr check-chk' from the lp:bzr-repodebug plugin on the remote
[02:32] <wgrant> Hmmmmmm.
[02:32] <wgrant> bzr was upgraded in devel recently.
[02:32] <wgrant> But one revision after what's in db-devel at the moment.
[02:33] <wgrant> Rather suspicious timing.
[02:33] <spiv> wgrant: ah, yes, check-chk finds *many* issues in lp:~launchpad-pqm/pygettextpo/trunk
[02:33] <wgrant> I don't see how the db-devel slave would be using the devel bzr, though...
[02:34] <wgrant> spiv: How do we fix that?
[02:34] <spiv> bzr reconcile --canonicalize-chks
[02:35] <spiv> (it's a hidden option, it's specifically for repairing damage from bug 522637)
[02:35] <ubot5> Launchpad bug 522637 in Bazaar 2.0 "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys" [High,Fix released] https://launchpad.net/bugs/522637
[02:35] <wgrant> Time for some PQM fun, I guess...
[02:35] <wgrant> Thanks.
[02:35] <spiv> And must be run on the actual damaged repo, not just done elsewhere and pulled, due to the nature of the problem.
[02:35] <wgrant> Yep.
[02:36] <spiv> It's pretty impressive, actually.
[02:36] <spiv> I'm not sure I've seen a branch with so many non-canonical-form CHK maps before!
[02:39] <spiv> wgrant: thanks for reminding me of that issue!
[02:39] <spiv> wgrant: I just realised it accounts for some package import failures :)
[02:39] <wgrant> spiv: Ah!
[02:50] <poolie> hi spiv, wgrant
[03:16] <spiv> Hmm.
[03:16] <spiv> Non-canonical CHKs were *part* of what was breaking libffi
[03:16] <spiv> But there's still something funky going on.
=== poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | UDD failure ratchet: 481
[03:51] <poolie> lifeless: in https://code.launchpad.net/~mbp/bzr/220464-stale-locks/+merge/62582 what do you mean by something stronger?
[04:53] <lifeless> poolie: well, you mentioned putting a machine identifying hash in or something
[04:54] <poolie> mm
[04:54] <poolie> it could go in /home
[04:54] <poolie> a lot of the problem cases have shared disks so that may not help
[06:31] <shadeslayer> https://code.launchpad.net/~neon/+recipe/project-neon-calligra << bzr runs out of memory on that recipe, could someone look at it? IIRC this bug was fixed a couple of months ago right?
[06:33] <spiv> shadeslayer: well, bzr memory usage has typically been improving with every major release
[06:33] <shadeslayer> spiv: i agree, but that branch is like 97 MB's in xz format :)
[06:33] <spiv> Whether that means your particular out of memory case has been fixed I couldn't immediately say.
[06:34] <shadeslayer> any ideas when it'll be able to build that particular size?
[06:34] <spiv> Depends on what the problem is, and what version of bzr (and maybe bzr-builder) the buildslave is running.
[06:35] <shadeslayer> i guess, whatever launchpad uses
[06:35] <spiv> It *might* be as simple as getting bzr upgraded there.
[06:35] <spiv> Well, I say âââ"simple" but I'm sure wgrant will correct me...
[06:36] <shadeslayer> well .. the source code import uses git->bzr conversion, but i have no idea what the bzr branch format is ... will look into it later this evening then
[06:37] <spiv> I don't mean upgrading the repo/branch format being used
[06:37] <spiv> Those are already current
[06:37] <spiv> I mean the version of the 'bzr' program being used.
[06:37] <shadeslayer> ah
[06:38] <poolie> i think jelmer and others  have a project underway to upgrade bzr
[06:38] <poolie> i don't think it's all done yet
[06:42] <poolie> according to https://code.launchpad.net/ lp is still using bzr 2.2.3
[06:43] <fullermd> Headers: {'Software version': '2.2.3dev'}
[06:45] <spiv> I don't think the PPA builders are necessarily using the same version of bzr as the rest of Launchpad.  I might be wrong.
[06:50] <wgrant> poolie, spiv, shadeslayer: The bzr upgrade has landed, and I'm QAing it now. Will be deployed in a couple of days.
[06:50] <wgrant> But spiv is right.
[06:50] <wgrant> The buildds don't use the same version.
[06:50] <wgrant> They use packages.
[06:50] <wgrant> I may converse with lamont.
[06:52] <lifeless> poolie: re: locks - I want to avoid us trashing repositories in the lp deployed configuration which will be N hosts, one cluster FS for storage
[06:53] <poolie> i want that too :)
[06:54] <poolie> having multiple hosts, one filesystem should be safe
[06:54] <poolie> s//should actually be safe in the patch as proposed
[06:54] <poolie> i'm going to check the server side behaviour though
[07:10] <spiv> shadeslayer: and fwiw that branch is much larger than your xz'd 97MB.  'du -hs .bzr' says 509M.
[08:09] <maxb> spiv: Hi. Do you think I should file a bug for "Please upgrade bzr-builddeb on jubany", or is it not worth the process?
[08:10] <maxb> We should be in the clear to redo the sysvinit import as soon as current trunk of builddeb & udd are deployed, which would be nice, as it's a user request
[08:11] <spiv> Hmm, a lot of changes since r494
[08:12] <maxb> oh yes :-)
[08:14] <spiv> It sounds like a good idea, and I think I'd be happy to just do it, but not at 5pm :)
[08:14] <spiv> So probably worth filing a bug
[08:14] <maxb> rihgt
[08:21]  * maxb is intrigued by the cpuarrayd failur
[08:22] <maxb> Somehow the importer has decided to import a package name which does not exist
[08:23] <spiv> maxb: yeah, I was wondering about that one too
=== tomaw_ is now known as tomaw__
=== tomaw__ is now known as tomaw
[09:27] <poolie> hello vila
[09:28] <vila> poolie: hey !
[09:28] <poolie> hi
[09:28] <poolie> :)
[09:28] <poolie> i like your mails-
[09:28] <poolie> i might need subtitles though :)
[09:29] <vila> http://www.youtube.com/watch?v=CN666q3ptAU
[09:30] <vila> :)
[09:34] <vila> poolie: corrections welcome nevertheless ;)
=== gerard_1 is now known as gerard_
[10:05] <poolie> vila so actually more seriously i don't know what spam you're talking about
[10:06] <poolie> did people object to the previous message/
[10:07] <vila> hmm, right, so what's the saying about explaining jokes ? ;)
[10:08] <vila> this was just a way to roll the drums about the policy change, people should know that there is something going on with reviews and subscriptions by now
[10:09] <vila> I probably viewed too much monty python lately: http://www.imdb.com/title/tt0071853/crazycredits
[10:09] <poolie> i like the humour
[10:09] <poolie> i think perhaps a subtitle saying what's actually happening would help
[10:10] <vila> right, the link to maxb message was supposed to give the serious info
[10:11] <poolie> well, just something to think about
[10:33] <poolie> vila, whoa, you sent through my stale lock branch?
[10:33] <poolie> i was just drafting a reply to robert
[10:33] <vila> mgz approved it...
[10:33] <vila> :-/
[10:33] <poolie> i think it's probably ok but i was going to look at it again
[10:33] <vila> did I miss a reply from Robert ?
[10:33] <poolie> i do appreciate you trying to flush the queue
[10:34] <poolie> he asked if it's safe wrt server side operations
[10:34] <vila> May be I over interpreted but I read mgz's last comment as: that's fine as it is, we can do a further proposal
[10:35] <vila> poolie: oh right, but this won't be deployed on lp then ?
[10:36] <poolie> why not?
[10:37] <vila> meh, if you think you need a further proposal, this don't *have* to be deployed on lp
[10:37] <vila> if you're ok, I don't have objections myself
[10:38] <poolie> well
[10:38] <poolie> on the whole we should probably land it and perhaps do follow up
[10:38] <poolie> i wouldn't mind brainstorming other things we could check, with you
[10:40] <poolie> what do you think we should do about matching up the host names?
[10:42] <poolie> i'm tempted to also ask a losa to kill the pqm job until we're agreed on how to do it
[10:47] <vila> how about a grace period before stealing the lock ?
[10:48] <vila> The issues you and Robert raised still exist with break-lock no ?
[10:50] <poolie> ok, i replied
[10:50] <poolie> a grace period could be another option
[10:50] <vila> I can't think of a good way to make the host name check stronger that can't be defeated either so I'm not sure about that
[10:54] <poolie> ok, good night!
[10:54] <vila> g'night !
[10:59] <vila> poolie: pqm failure anyway, so no worries
[11:00] <jelmer> g'night poolie
[11:07] <lifeless> vila: poolie: re: landing and iterating; If landing something that makes server deployment risky, how would we identify that this blocks a release/deploy to lp ?
[11:08] <lifeless> not saying you should or shouldn't, just wondering what the process to avoid mistakes further down the line is
[11:12] <vila> lifeless: add more tests ? ;) Anyway, there was a pqm failure for this proposal so it didn't land
[11:38] <bigjools> hi all, I'm doing a "bzr shelve --all" and getting this error, what can I do to fix it?
[11:38] <bigjools> bzr: ERROR: Could not acquire lock "/home/ed/canonical/lp-branches/copies-must-use-queue-bug-789502/.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailable
[11:39] <jelmer> bigjools: there's no other bzr instance trying to access that branch at the same time?
[11:39] <bigjools> jelmer: I hope not, I've not touched bzr since I booted the box, that's the first thing I typed
[11:40] <bigjools> ah, there's a bzr grep running ...
[11:40] <bigjools> jelmer: that was it :/
[11:40] <bigjools> I didn't think it'd do an exclusive lock
[11:40] <bigjools> thanks
[11:41] <jelmer> not one of our best error messages..
[11:41] <bigjools> no :)
[12:09] <quicksilver> does anyone use reviewboard with bzr? or alternatively, have suggestions on tools in this area? That is, support for code review workflows
[12:10] <ScottK> quicksilver: I've used it.
[12:11] <quicksilver> ScottK: works well?
[12:11] <ScottK> You need a patch and then it works.
[12:11] <ScottK> Let me see if I can find it.
[12:11] <quicksilver> the bzr-diff-revid stuff?
[12:12] <ScottK> Yes.
[12:12] <quicksilver> found that already in my initial researches.
[12:12] <quicksilver> trying to find a bit of automation for a good merge-request/code-review workflow.
[12:12] <ScottK> There's also a patch to rbtools we needed.
[12:13] <ScottK> I think that may just be because we were on an older version.
[12:14] <quicksilver> I really want something which can work on the output of "bzr merge --preview"
[12:14] <quicksilver> that is, the diff between unmerged branches.
[12:14] <quicksilver> most code review tools seem to want to work on diffs between versions of a particular branch
[12:15] <ScottK> I don't think I've used it that way.
[12:16]  * quicksilver nods
[12:16] <quicksilver> maybe my workflow is odd
[12:16] <quicksilver> but I like to review changes before we pull them into mainline.
[12:17] <spiv> quicksilver: that's not odd at all; it's how Launchpad's code review workflow works for example.
[12:17] <quicksilver> spiv: hmm maybe running an internal launchpad instance is a better idea then?
[12:17]  * quicksilver tries to google info about lp code review
[12:18] <spiv> quicksilver: but I guess the thing is if you have a branch that's simply a bunch of revisions on top of the target branch (i.e. no merges from the target onto the branch-for-review part way through its new commits) then diff-between-versions-of-branch is the same.
[12:19] <quicksilver> right. but we always have those (merges from target onto branch-for-review)
[12:19] <quicksilver> apart from anything else it's the branch-developers obligation to keep testing against latest mainline and ensure there are no conflicts
[12:19] <quicksilver> so there should be regular merges in that direction.
[12:19]  * spiv nods
[12:20] <quicksilver> spiv: seems lp code review gives you a workflow and an interface to browse merge candidates, btu doesn't actually support the process of annotating the diffs?
[12:21] <spiv> It gives you a place to add comments about the whole diff, but no way to directly annotate a part of the diff with a particular comment, no.
[12:21]  * quicksilver nods
[12:21] <quicksilver> currently I review the entire output of bzr merge --preview in emacs, make notes and then discuss those notes with the developer.
[12:21] <spiv> (I think there was some discussion recently about maybe adding something like that)
[12:21] <quicksilver> it works OK but I was wondering if I could automate some of those parts
[12:22] <quicksilver> and having it on the intranet lets the rest of the team get some idea what's going on
[12:22] <quicksilver> which is nice.
[12:22] <spiv> My usual way to do reviews with Launchpad is I get the email sayingg
[12:22] <spiv> "review this, here's the diff" and I reply to that email, quoting the bits of the diff I'm commenting on and following them with my remarks.
[12:23] <spiv> s/to do/I do/
[12:23]  * quicksilver nods
[12:23] <spiv> I don't mean to suggest my preferences are universal :)
[12:23] <spiv> Part of the difficulty of directly annotating LP's diffs is that they are updated automatically as the branch changes
[12:24] <spiv> So the comments on a review may be interleaved with "New revision: Add more comments, fix typo." etc
[12:25] <quicksilver> spiv: reviewboard (which ScottK and I were just discussing) claims to understand about different versions of diff.
[12:25] <quicksilver> I'm not sure what it looks like in practice.
[12:26] <spiv> I'm not either, I haven't taken a close look at reviewboard recently at all.
[12:27] <ScottK> I think you'll have to try it to know if it fits your workflow.
[12:29]  * quicksilver nods
[14:32] <niemeyer> Greetings!
[14:33] <niemeyer> I faced an issue with bzr over the weekend that prevented importing some code on it.  Wondering if someone already had a look at something similar:
[14:33] <niemeyer> bzr: ERROR: An inconsistent delta was supplied involving '<unknown>', 'hg:usr_sgri'
[14:33] <niemeyer> reason: Parent is not present in resulting inventory.
[14:34] <niemeyer> This was a simple non-fancy import of about 8600 revisions, just one commit after the other
[14:40] <niemeyer> This seems to be the same bug as this one:
[14:40] <niemeyer> https://bugs.launchpad.net/bzr-hg/+bug/513368
[14:40] <ubot5> Ubuntu bug 513368 in Bazaar Hg Plugin "inconsistent delta during fetch" [Medium,Triaged]
[14:41] <niemeyer> What surprised me is that I'm hitting the bug just with plain command line interaction
[14:54] <maxb> niemeyer: It's not that surprising, bzr-hg is somewhat less developed that other bzr foreign plugins
[14:55] <niemeyer> maxb: I'm not using bzr-hg
[14:55] <niemeyer> maxb: bzr is crashing all by itself
[14:56] <niemeyer> maxb: I go 8600 revisions doing "bzr add; bzr remove; bzr commit"
[14:56] <niemeyer> and the resulting repository has this bug
[14:57] <maxb> The string 'hg:usr_sgri' from your error message is *highly* suggestive of bzr-hg being involved
[14:57] <niemeyer> maxb: Ouch.. maybe the plugin is kicking in just because there's an .hg directory?
[14:57] <maxb> Entirely possible
[14:57] <niemeyer> Ugh
[14:57] <niemeyer> Ok, that'd explain a lot
[14:58] <niemeyer> maxb: ...and I had it installed. I'll try to reproduce the bug without it, but it looks like you're right. That was very helpful, thanks!
[15:17] <niemeyer> maxb: OMG.. not only it works, but it's also several orders of magnitude faster
[15:17]  * niemeyer hugs maxb
[15:17] <maxb> :-)
[15:17] <maxb> Did you try using bzr-hg to import the branch first?
[15:18] <maxb> It would be somewhat simpler than an add/commit loop
[15:29] <gour> reddit story about bzr - http://www.reddit.com/r/programming/comments/hseul/do_you_like_bzr_were_working_on_the_github_for/
[15:37] <asabil> mergebox sounds like something that would probably help increasing bzr adoption
[15:45] <niemeyer> maxb: Heh
[15:46] <niemeyer> maxb: I'm sure it's simpler when it works
[15:46] <niemeyer> maxb: This bug is around for more than a year
[15:56] <shadeslayer> wgrant: thanks!
[15:56] <shadeslayer> spiv: alright, i
[15:56] <shadeslayer> +i'll test it out when its rolled out
[16:08] <shadeslayer> wgrant: is the new bzr out on production servers?
=== deryck is now known as deryck[lunch]
=== deryck[lunch] is now known as deryck
=== bigjools-afk is now known as bigjools
=== zyga is now known as zyga-afk
=== yofel_ is now known as yofel
=== zyga-afk is now known as zyga
[23:18] <poolie> hi maxb, all
[23:18] <maxb> hello
[23:27] <jelmer> hi poolie, maxb
[23:29] <poolie> hey there
[23:35] <wizonesolutions> Anyone know if Bazaar has something similar to git-submodule?
[23:44] <lifeless> there is a plugin