[00:24] <mwhudson> thumper: want to review a testfix branch?
[00:24] <thumper> sure
[00:27] <mwhudson> thumper: https://code.edge.launchpad.net/~mwhudson/launchpad/db-devel/+merge/24270
[00:46] <thumper> mwhudson: done
[00:47] <mwhudson> thumper: thanks
[00:48] <thumper> mwhudson: I have my breadcrumbs working
[00:48] <mwhudson> thumper: woo
[00:48] <thumper> mwhudson: and I'm going to refactor one of the existing tests
[00:48] <mwhudson> thumper: i'm sure there's a joke to be made about a fairy tale in here somewhere...
[00:48] <thumper> :)
[00:59] <mwhudson> time for lunch
[01:00] <mwhudson> ... and breakfast, which somehow got lost today
[01:12] <thumper> :(
[01:12] <thumper> my breadcrumbs works as long as you don't look for a person or product :)
[03:14] <mwhudson> ah poo, it seems like there's a database patch in db-devel before my no-hosted-area landing, so i'll have to wait for a db restore before i can qa it :(
[03:15] <wgrant> mwhudson: Why does that require a DB restore? Wouldn't that just need the patch to be applied when it next updates?
[03:15] <mwhudson> oh, do we do that?
[03:15]  * mwhudson hopes so
[03:16] <wgrant> It would make a lot of sense.
[03:19] <wgrant> The last DB reimport was on 9274->9275, which had no schema changes, so it probably isn't triggered by schema changes.
[03:23] <thumper> mwhudson: I was under the impression that we were at least going to try that
[03:23] <thumper> mwhudson: best to ask a losa though
[03:24] <wgrant> Have we lost lots of tests again, or has the test suite really dropped to around 3:15 on EC2?
[03:24] <mwhudson> wgrant: it
[03:25] <mwhudson> wgrant: it is a lot faster since stub removed the commits from the test factory
[03:25] <wgrant> I knew that made it faster... but I didn't think it would be nearly 25% faster.
[03:25] <wgrant> Impressive.
[03:27] <thumper> :(
[03:28] <thumper> mwhudson: my breadcrumb change has found problems in other people's breadcrumb tests
[03:28] <thumper> now to find out if they are real or not
[03:28] <thumper> wgrant: yes, it is all those unneeded transaction.commits
[03:29] <thumper> wgrant: they slowed down test.tearDown a lot
[03:29] <wgrant> Yeah, I guess they would.
[03:34] <mwhudson> thumper: somehow i am not very surprised
[03:34] <thumper> down to 1 failure and 4 errors
[03:34] <thumper> 3 translations 2 bugs
[03:34]  * thumper grrs
[03:35] <thumper> TranslationUnavailable: Translations for this release series are not available yet. is one error
[03:35] <thumper> NotFound: Object: <lp.translations.model.potemplate.POTemplateSubset object at 0xed26750>, name: u'template'
[03:35] <thumper> is the other two template errors
[03:35]  * thumper digs
[03:36] <thumper> I'm now ignoring the traversed objects they pass in
[03:36] <thumper> and determining it from the url
[03:36] <thumper> so not entirely surprising
[03:37] <thumper> can I land a deprecation error?
[03:37] <thumper> as in will it kill the test suite?
[03:38] <wgrant> It will kill things if it shows up in script output. salgado supressed lots of those this morning for the 2.6 migration.
[03:38] <wgrant> But if it lands somewhere that doesn't have its stderr checked, the test suite will be happy.
[03:39] <wgrant> (only the people will be unhappy)
[03:41] <thumper> I want people to be unhappy
[03:44] <mwhudson> thumper: for the allow-import-password thing, what do you think of this text? http://people.canonical.com/~mwh/subversion-text.png
[03:44] <mwhudson> i'm not very happy with it
[03:46] <thumper> You can inclue a username and password as part of the url, but this will be
[03:46] <thumper> displayed on the branch page.
[03:46] <thumper> what about that?
[03:46] <mwhudson> yeah, that seems better
[03:46] <thumper> One of the breadcrumb bugs is just plain wrong test
[03:48]  * thumper shakes his head
[03:48]  * thumper is sad
[03:48]  * thumper wants to delete the bugs breadcrumb privacy test
[03:51] <mwhudson> hmm
[03:51] <mwhudson> bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/dulwich/devel/ has 129 inconsistent parents
[04:14] <poolie> spiv, I wish Launchpad gave out xbox-style achievements
[04:14] <poolie> like when you file 50 bugs and get someone else to fix them
[04:15] <poolie> or do 50 reviews
[04:15] <thumper> poolie: and you want it submitted for facebook for you?
[04:16] <poolie> wbn
[04:16] <poolie> but just showing them inline would be enough
[04:16] <poolie> you could almost build it using apis and feeds
[04:16] <poolie> but it might be a bit anonying
[04:17] <thumper> :(
[04:17] <thumper> I found a bug in the canonical_url of bug comment
[04:18] <thumper> I wish I could say skip and inform the bug team
[04:18] <thumper> poolie: I was hoping to get this finished before our call but it doesn't look like it is going to happen
[04:19] <thumper> poolie: want to do a call now?
[04:19] <poolie> sounds good
[05:00] <mwhudson> spm: ping
[05:00] <spm> mwhudson: yo
[05:02] <mwhudson> spm: is it possible for you to guess for me how long it will take r9306 of db-stable to get onto staging?
[05:02] <spm> mwhudson: no idea. < 48 hours, all going well :-)
[05:03] <mwhudson> spm: staging is currently on r9302 but r9303 includes a database patch
[05:03] <spm> then yeah, at least a full day.
[05:03] <mwhudson> spm: i leave the launchpad team in 48 hours and no-hosted-area _really_ needs serious QA
[05:03] <mwhudson> spm: is there anything we can do to speed it up? :/
[05:04] <spm> mwhudson: this week? not so far as I'm aware of. :-/
[05:04] <mwhudson> oh well
[06:48] <adeuring> good morning
[08:18] <jtv> noodles775: good morning!  Delegating deletion of BuildFarmJobs is complicated a bit by the introduction of BuildFarmJobDerived.
[08:19] <noodles775> jtv: in what way?
[08:20] <noodles775> jtv: btw, let me know if a call is easier.
[08:20] <jtv> noodles775: well I wouldn't even have noticed if it weren't for the fact that buildfarmjobbehavior.txt does builder.currentjob.destroySelf()
[08:21] <jtv> noodles775: IRC is easier because chances are that at some point wgrant will notice and solve it all in one offhand remark.  :-)
[08:21] <noodles775> lol, yep.
[08:22] <jtv> What builder.currentjob.destroySelf() does in the current codebase is delete the BuildQueue entry (the currentjob); then Store.of(currentjob.specific_job).remove(currentjob.specific_job); and finally delete the Job.
[08:23] <jtv> I replaced the Store.of(...).remove(...) with a call to a BranchJob method that does Store.of(self).remove(self), and in this test, _that_ now fails with exactly the error I had in practice—i.e. self has no store.
[08:23] <jtv> Does that mean I'm supposed to delegate to IBranchJobDerived instead of IBranchJob?
[08:26] <noodles775> jtv: I don't understand 'I replaced... with a call to a BranchJob method'? Can you point me to a branch or WIP MP?
[08:26] <jtv> Yup, that does resolve the test failure.
[08:27] <noodles775> Great.
[08:27] <jtv> noodles775: haven't done up the MP yet... I was just unaware of the BranchJobDerived change.
[08:27] <wgrant> So you're going to have double delegation?
[08:27] <jtv> wgrant: no, I'm just moving the cleanup method from BranchJob to BranchJobDerived.
[08:28] <noodles775> But you shouldn't normally be delegating to IBranchJobDerived (I wouldn't think). That's a code thing (the pattern of which I'm using for the BuildFarmJob stuff).
[08:28] <wgrant> Ah.
[08:28] <noodles775> Ah... that makes more sense.
[08:30] <jtv> noodles775: do I need to make provisions for IBranchJob implementations that aren't BranchJobDerived?
[08:32] <noodles775> jtv: I didn't create the BranchJobDerived classes (I'm just using the pattern), but afaiui, you should inherit from BranchJobDerived if you want to automatically *delegate* IBranchJob (overriding anything as necessary).
[08:33] <noodles775> So I think your question implies that you're creating an implementation of IBranchJob that doesn't delegate?
[08:33] <jtv> noodles775: any idea who did create the BranchJobDerived classes?
[08:33] <jtv> No, I'm asking if there are any implementations of IBranchJob that don't delegate.
[08:34] <noodles775> jtv: I assume one of the code guys, but annotate should show you.
[08:34] <jtv> yes
[08:35] <noodles775> jtv: I'd assume that there aren't any though... why do you ask?
[08:35]  * noodles775 has a quick look.
[08:35] <jtv> Because I need to know whether there is any point in my design allowing for it.
[08:35] <jtv> Or whether there _would_ be, rather.
[08:39] <noodles775> jtv: so the only mention of IBranchJob I can see is your IBuildFarmBranchJob (implemented by TranslationTemplatesBuildJob).
[08:40] <jtv> noodles775: ironically, "bzr annotate" shows just "michael" for the Derived changes...  I guess that's mwhudson then.  :)
[08:41] <noodles775> yep (well, for the BranchJobDerived changes) :)
[08:48] <jtv> Did I say BranchJobDerived?  I meant BuildFarmJobDerived.  Sigh.
[08:49] <noodles775> jtv: ok, that is the one that I created (using the same pattern as BranchJobDerived).
[08:49] <jtv> Confusion reigns.
[08:50] <jtv> That's what I meant to ask, sorry.  But BranchJobDerived is so much easier and more familiar that it seems to have taken over my brain and fingers.  :)
[08:51] <noodles775> Aha. So is it working now that you've moved your method into BuildFarmJobDerived?
[08:51] <jtv> noodles775: so, to fix all that up...  Would there be any point in the delegation of BuildFarmJob cleanup accommodating specific_jobs that were not BuildFarmJobDerived?
[08:51] <jtv> Right.
[08:52] <noodles775> jtv: Nope.
[08:52] <jtv> Great.  Saves me some other potential complications as well.
[08:53] <noodles775> Excellent.
[08:55] <bigjools> morning
[09:36] <jtv> noodles775: something puzzling here... why did getByJob move from a utility class into IBuildFarmJobDerived?
[09:38] <noodles775> jtv: it was only used by classes inheriting from IBuildFarmJobDerived... from memory.
[09:40] <jtv> noodles775: but doesn't that imply that you need an IBuildFarmJobDerived in order to find one?
[09:40] <noodles775> jtv: it's a class method.
[09:41] <jtv> noodles775: not in IBuildFarmJobDerived it's not.
[09:42] <jtv> Interface-wise, it went from "class provides" to "implements."
[09:42] <jtv> Which means that it's suddenly not accessible from the utility.
[09:42] <noodles775> jtv: Sorry, it is on the implementation (BuildFarmJobDerived)... I'd forgotten to indicate that on the iface.
[09:43] <noodles775> Just otp... back in a few mins.
[09:55] <noodles775> jtv: ok, back. So the mistake was that the IFace does not define it as a classmethod, or was there more?
[09:56] <jtv> noodles775: frankly I don't even know whether an interface _can_ specify a class method in implementing classes... you may need a separate interface, and classProvides it instead of implements it, like it was before.
[10:06] <noodles775> jtv: sorry, I'm not seeing what the problem is? It is still provided by the class as it was before, it just moved from being on a separate interface (and using classProvides()). The branch that that change landed with still used getUtility(IBuildQueueSet).getByJob().
[10:07]  * noodles775 tries that in a harness.
[10:07] <jtv> noodles775: this isn't the IBuildQueueSet.getByJob though, I think.
[10:07] <jtv> (I must admit I get easily confused with this stuff)
[10:07] <noodles775> yeah, my brain is swimming atm.
[10:08] <jtv> I worked around it by invoking getByJob directly on the class, without going through the utility.
[10:09] <jtv> Right now I'm hitting a very different problem: when the changes from BuildQueue.destroySelf get flushed, BuildQueue still holds a fk to Job.
[10:09] <jtv> Which is odd because the BuildQueue did delete itself first.
[10:14] <noodles775> jtv: looking at the diff where I updated getByJob, i didn't modify any call-sites, so it seems the class has always been used to access the method, rather than a utility?
[10:15] <jtv> noodles775: maybe it's the conflation with BranchJob confusing things again...
[10:15] <noodles775> aha. Did you sort out your foreign key issue?
[10:15] <jtv> Not yet  :(
[10:30] <wgrant> Hmm. db-devel loggerhead crashes when I try to log in.
[10:30] <jtv> noodles775: it's as if Store.of(branchjob).remove(branchjob) is calling branchjob.destroySelf(), which in turn deletes the Job before its time.  :(
[10:31] <noodles775> jtv: can you create a WIP MP?
[10:31] <jtv> noodles775: OK
[10:33] <wgrant> Hmmm. I was going to add a print statement to debug this issue. But one is present in db-devel (lib/launchpad_loggerhead/app.py)! This does not bode well.
[10:35] <jtv> noodles775: https://code.edge.launchpad.net/~jtv/launchpad/bug-569108/+merge/24297
[10:37] <jtv> noodles775: note how I can't call BranchJob.destroySelf, because that tries to destroy self.job, which we can't destroy yet because BuildQueue still refers to it at that point.
[10:38] <jtv> but wait... the order to delete the BuildQueue comes in even before that.
[10:41] <noodles775> jtv: just otp again, but will look straight afterwards.
[10:41] <jtv> thanks
[10:44] <wgrant> allenap: Hmm, so that's twice it's vanished?
[10:46] <allenap> wgrant: Yes. I'm a bit grumpy about that. There seems to be a lot of this about at the moment.
[10:46] <wgrant> allenap: Indeed :(
[10:47] <wgrant> lp:~wgrant/launchpad/fix-mailman-testrot also probably disappeared, although it's so long ago that I don't remember.
[10:50] <thumper> jtv: I'm being nice to translations
[10:51] <jtv> thumper: ?
[10:51] <thumper> jtv: your breadcrumb test sucks less than that others
[10:51] <jtv> thumper: strong praise
[10:51] <jtv> do we have one?
[10:51] <allenap> wgrant: I'll submit that too, see if one of them sticks :)
[10:51] <jtv> or are you saying we don't?
[10:52] <wgrant> allenap: Thanks.
[10:53] <thumper> jtv: you do, and they are reasonably good
[10:53] <thumper> jtv: I've refactored the base breadcrumb test case
[10:54]  * jtv tries to swap the subject back in
[11:08] <jtv> noodles775: found it
[11:09] <noodles775> jtv: great... what was it?
[11:10] <jtv> noodles775: this is why strong typing is sometimes a good idea, and naming things after their type is often a bad idea
[11:11] <jtv> buildqueue wasn't a BuildQueue.
[11:11] <noodles775> Ah.
[11:12]  * thumper mops brow
[11:12] <thumper> that's all the breadcrumb tests fixed
[11:12] <thumper> in the vetinary sense
[11:13] <jtv> thumper: neutered..?
[11:13] <thumper> put down :)
[11:13] <jtv> thumper: hope your kids aren't there to hear that...
[11:26] <thumper> ✁☹
[11:26] <thumper> I should have stopped by now :(
[11:31]  * thumper is done now
[11:31] <thumper> branch is in ec2
[11:33] <thumper> 1145 lines? no wonder if felt long
[11:33] <thumper> no wikkid hacking for me tonight
[11:33] <thumper> need to sleep before the TL call
[12:15] <wgrant> jtv: I think you might be confused about the slave's buildid handling.
[12:16] <wgrant> 'build ID' may be an overloaded term, but 'chroot checksum' is not among its meanings.
[12:17] <jtv> wgrant: but the one I'm pointing at is definitely the chroot checksum.
[12:18] <jtv> So I'm saying it's _too_ overloaded in this case, probably by accident.
[12:19] <wgrant> jtv: The only thing I can see xmlrpc_build calling with the chrootsum as an argument is BuildManager.initiate.
[12:19] <wgrant> Which takes a chroot checksum in the expected position.
[12:19] <jtv> wgrant: exactly
[12:19] <jtv> ...and stores it in self._buildid
[12:19] <jtv> ...after which it gets used all over the place, sometimes as an arbitrary id, sometimes in dealing with the chroot tarball.
[12:20] <wgrant> jtv: _buildid is set only in __init__(), not initiate()
[12:20] <jtv> wgrant: then I may be wrong about how it gets there, but look at the logs: the chroot hash is all over the place
[12:21] <wgrant> And xmlrpc_build calls __init__ like "self.slave.startBuild(self._builders[builder](self.slave, buildid))"
[12:21] <wgrant> jtv: Hm, they've always looked fine for me. I haven't used it in the new Era of Cookies, but it all used to look sane.
[12:23] <jtv> wgrant: where do the BuildManager classes get instantiated anyway?
[12:26] <wgrant> jtv: The expression that I quoted three lines ago.
[12:26] <jtv> wgrant: actually it's quite possible that I'm wrong about this...  but then that means we're seeing the cookie all over, which would probably be a bad thing
[12:26] <wgrant> jtv: You should expect to see the cookie in quite a few places.
[13:22] <deryck> bigjools, ping
[13:23] <bigjools> deryck: helleau
[14:47] <deryck> BjornT, ping.
[14:49] <BjornT> hi deryck
[14:50] <Ursinha> danilos, sure :)
[14:58] <danilos> Ursinha, here are the people who can probably help you more than I can :)
[15:00] <bac> reviewers meeting beginning
[17:24] <jelmer> danilo: I wasn't the one updating lp:~launchpad-pqm/bzr-git/devel, so I guess that must've been mwhudson
[17:25] <jelmer> danilos: In that case, all that's left to do is update sourcedeps.conf
[17:25] <danilos> jelmer, right, it must simply be very approximate timing then :)
[17:25] <danilos> jelmer, cool, can you do that or should I take care of it?
[17:26] <jelmer> danilos: If you can do it that'd be great, I've got enough pending branches as is.
[17:26] <danilos> jelmer, heh, who doesn't :) sure, I'll take care of it then
[17:27] <jelmer> danilos: it should be a matter of updating utilities/sourcedeps.conf to point at the latest tip and firing that off to ec2
[17:27] <danilos> jelmer, yeah
[18:12] <mrevell> Night
[20:12] <jml> thumper: I thought you might like to look at http://www.wikimatrix.org/
[20:24] <jml> james_w, I've got your wadllib patch down as something I'd like to look at
[20:24] <jml> james_w, but realistically, that's unlikely to happen for another three weeks.
[20:25]  * jml stops for the day
[22:40] <wgrant> Is PQM really open?
[22:42] <mwhudson> wgrant: yes
[22:43] <wgrant> I've two branches that were rejected during last night's testfix... and one that disappeared in EC2 (\o/)
[23:00] <thumper> wgrant: I had one ec2 run disappear too
[23:00] <thumper> wgrant: although I caught it before it killed itself
[23:00] <thumper> wgrant: stuck in windmill tests
[23:01] <thumper> wgrant: pqm closes in approx 24 hours
[23:03] <wgrant> Hm, I thought it was closing earlier.
[23:04] <thumper> wgrant: that is earlier
[23:04] <thumper> wgrant: normally it closes in approc 48 hours
[23:04] <wgrant> Ah. oops.
[23:26] <wgrant> mwhudson: Hi.
[23:26] <mwhudson> wgrant: hi
[23:27] <wgrant> mwhudson: So, I tried to get codebrowse running on db-devel last night... and it was crashing when I tried to authenticate. So I looked in launchpad_loggerhead and tried to add a debug print... but it was already there (app.py:113).
[23:28] <wgrant> This has me suspicious that it's actually broken, and you were trying to debug it, and then it landed broken with the debug print.
[23:28] <mwhudson> wgrant: ah yes
[23:28] <mwhudson> wgrant: i think the problem is that testopenid.dev is a bit lame
[23:29] <mwhudson> you're right that the debug print shouldn't be there though
[23:31] <mwhudson> wgrant: afaict testopenid doesn't support the sreg extensions codebrowse needs
[23:31] <mwhudson> wgrant: so, uh, i hope it'll work on staging
[23:31] <wgrant> Sounds easy enough to fix.
[23:31]  * wgrant tries.
[23:31] <wgrant> But yes, hopefully it will work on staging...
[23:31] <mwhudson> wgrant: browsing private branches is totally broken on prod right now
[23:32] <wgrant> I wondered if that was related.
[23:32] <mwhudson> (i'm surprised that noone's tried to burn my house down)
[23:32] <mwhudson> wgrant: it's not, it's a launchpad branch that removed an api launchpad-loggerhead used
[23:32] <wgrant> Ah.
[23:34] <wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/fix-mailman-testrot/+merge/23475 and https://code.edge.launchpad.net/~wgrant/launchpad/bug-565739-dont-retry-superseded-builds/+merge/23622 passed EC2 overnight (the latter took three tries to not disappear in EC2...), but were rejected in the testfix. allenap said he'd pqm-submit them, but it looks like he didn't get around to it. Can someone please deal with them, if they have a moment?
[23:35] <wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/delete-more-stuff/+merge/24280 also disappeared in EC2 overnight, so it would be nice if someone could try it again...
[23:37] <mwhudson> wgrant: ok
[23:41] <StevenK> wgrant: I had the same problem yesterday with EC2 instances buggering off.
[23:45] <mwhudson> wgrant: two pqm-submits done
[23:46] <wgrant> mwhudson: Thanks!
[23:46] <wgrant> StevenK: Yeah, it's been happening for a while :/
[23:46] <mwhudson> wgrant: and the ec2 land is firing up
[23:46] <StevenK> wgrant: But now the branch has failures in windmill tests ... :-(
[23:47] <wgrant> mwhudson: Even better.
[23:48] <wgrant> mwhudson: Where are you escaping to, BTW?
[23:48] <mwhudson> wgrant: can't say in public yet
[23:48] <wgrant> Ah.
[23:48] <mwhudson> wgrant: i'm sure you've been paying enough attention for you to know what that means though
[23:50] <wgrant> You're not as leaky as you used to be, although I have some ideas :P