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