[08:12] <noodles775> thumper or anyone who can rs a testfix: http://pastebin.ubuntu.com/447621/
[08:12] <noodles775> It was the result of a bad but non-conflicting merge.
[08:12] <noodles775> to test: `bin/test -vvm test_sourcepackagerecipebuild`
[08:14]  * noodles775 RS's himself.
[08:39] <thumper> noodles775: it is fine to rs those yourself I think
[08:42] <noodles775> thumper: yeah, I thought so too :)
[10:51] <noodles775> Thanks jelmer_ :)
[12:52] <jtv> noodles775, jelmer_: got a slightly weird but very simple review for you.
[13:14] <noodles775> jtv: r=me, but why not just merge it and resolve the conflict once (then you won't have to worry about it?) Are you keeping a pipeline with your feature, or just a single branch?
[13:22] <bigjools> trivial CP branch
[13:22] <bigjools> well - trivial if you know SQL like stub does :)
[13:22]  * bigjools -> kunch
[13:22] <bigjools> lunch even
[13:22] <noodles775> :)
[13:36] <abentley> wgrant, mainly because _handleStatus_OK scares me, but also because I don't trust that if I break it the tests will catch it, and because another team is the main owner of the code.
[13:36] <wgrant> abentley: Mmm, true, it is pretty scary.
[13:37] <wgrant> But large piles of hacks also scare me. :/
[13:38] <abentley> wgrant, whether or not it's a hack depends on whether you think _handleStatus methods should always notify.  Otherwise, it's just programming-by-difference.
[13:53] <stub> https://code.edge.launchpad.net/~stub/launchpad/pending-db-changes/+merge/27263 has some random minor DB related updates for production stuff
[14:30] <noodles775> Ah, jelmer_, had you already started stubs review?
[14:30] <jelmer_> no, I haven't started yet
[14:30] <jelmer_> noodles775: did you already start?
[14:31] <mars> noodles775, jelmer_, have time to review a branch that will restore everyone's confidence in ec2?  :)   https://code.edge.launchpad.net/~mars/launchpad/use-zope.testing-3.9.4-p1/+merge/27265
[14:31] <jelmer_> I can take mars' mp
[14:31] <noodles775> mars: I've already done it.
[14:31] <mars> noodles775, wow, that was fast.  Thanks!
[14:31] <mars> noodles775, thinking about your comment
[14:32] <noodles775> jelmer_: ^^, and no, I hadn't started stubs, I just clicked on claim a few seconds before you changed the topi.
[14:32] <noodles775> topic.
[14:32] <noodles775> jelmer_: I'll just finish stubs now that I've claimed it then :)
[14:32] <jelmer_> noodles775: Ok :-)
[14:33] <jelmer_> mars: what does your branch fix wrt ec2 ?
[14:34] <mars> jelmer_, updates to a new version of the zope.testing testrunner with a backported patch fixing a crash.
[14:34] <mars> jelmer_, the testrunner would crash, forgetting all previous work, then continue to run the suite as if nothing happened: false suite success.
[14:37] <jelmer_> mars: ah, ok
[14:37] <jelmer_> mars: I'm still seeing branches disappear, is that a known issue?
[14:38] <mars> jelmer_, when was the last disappearance?  I landed the fix yesterday
[14:39] <jelmer_> mars: yesterday evening, after your fix landed afaik
[14:39] <jelmer_> mars: I'm running the testsuite locally but I'll try again with ec2 as well
[14:40] <mars> jelmer_, may have been a different bug: same crash, different source
[14:40] <mars> jelmer_, the subprocess handling in zope.testrunner is screwed.  This will keep happening until I land another branch or two.
[14:41] <jelmer_> mars: ah, ok
[14:41] <mars> jelmer_, with what frequency are you seeing ec2 disappearances?
[14:41] <mars> I was seeing it with 40% frequency
[14:43] <jelmer_> mars: it varied; it used to be one in 4 but I've seen more recently (40% sounds about right)
[14:43] <jelmer_> also, some branches seem more prone to disappearance than others
[14:44] <mars> makes sense depending on what the branch changed.  So far the failures are caused by race conditions and such.
[14:45] <mars> jelmer_, it is also possible that this branch that fixes the doctest failures will fix the crashes you are seeing
[14:45] <mars> jelmer_, I'll let you know when it lands.  Hopefully that will make more of them go away.
[14:46] <jelmer_> mars: thanks!
[14:56] <noodles775> jelmer_: are you landing that branch of mvo's? (or can you?)
[17:27] <rockstar> jelmer_, you're not still around, are you?
[17:36] <jelmer_> rockstar: I am
[17:36] <jelmer_> rockstar: what's up?
[17:39] <rockstar> jelmer_, I was gonna change the topic...  :)
[17:42] <jelmer_> ah :-)
[18:49] <gary_poster> rockstart, anyone, up for reviewing a change to our deps for the python2.6 switch? https://code.edge.launchpad.net/~gary/meta-lp-deps/generic-python/+merge/27292
[18:49] <gary_poster> rockstar
[18:49] <rockstar> gary_poster, sure.
[18:49] <gary_poster> thank you
[18:50] <rockstar> gary_poster, r=me
[18:51] <gary_poster> thanks rockstar
[22:00] <abentley> rockstar, could you please review https://code.launchpad.net/~abentley/launchpad/version-revno/+merge/27308 ?
[22:00] <rockstar> abentley, sure.
[22:01] <abentley> rockstar, ta
[22:02] <rockstar> abentley, is {revno} special to bzr-builder?
[22:02] <abentley> rockstar, yes.
[22:02] <rockstar> abentley, ah great, so we don't need the MANIFEST at all.
[22:03] <abentley> rockstar, huh?
[22:03] <rockstar> abentley, we were talking about doing this ourselves, but we needed access to the MANIFEST to get to the bzr revno.
[22:04] <abentley> rockstar, we'll still need manifests to abort duplicate builds, because {revno} is only evaluated once the build has started.
[22:05] <rockstar> abentley, ah, okay.
[22:05] <rockstar> abentley, r=me
[22:07] <abentley> rockstar, thanks.