mwhudson | thumper: want to review a testfix branch? | 00:24 |
---|---|---|
thumper | sure | 00:24 |
mwhudson | thumper: https://code.edge.launchpad.net/~mwhudson/launchpad/db-devel/+merge/24270 | 00:27 |
thumper | mwhudson: done | 00:46 |
mwhudson | thumper: thanks | 00:47 |
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:48 |
mwhudson | time for lunch | 00:59 |
mwhudson | ... and breakfast, which somehow got lost today | 01:00 |
thumper | :( | 01:12 |
thumper | my breadcrumbs works as long as you don't look for a person or product :) | 01:12 |
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:14 |
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:15 | |
wgrant | It would make a lot of sense. | 03:16 |
wgrant | The last DB reimport was on 9274->9275, which had no schema changes, so it probably isn't triggered by schema changes. | 03:19 |
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:23 |
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:24 |
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:25 |
thumper | :( | 03:27 |
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:28 |
thumper | wgrant: they slowed down test.tearDown a lot | 03:29 |
wgrant | Yeah, I guess they would. | 03:29 |
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:34 | |
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:35 | |
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:36 |
thumper | can I land a deprecation error? | 03:37 |
thumper | as in will it kill the test suite? | 03:37 |
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:38 |
wgrant | (only the people will be unhappy) | 03:39 |
thumper | I want people to be unhappy | 03:41 |
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:44 |
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:46 |
* thumper shakes his head | 03:48 | |
* thumper is sad | 03:48 | |
* thumper wants to delete the bugs breadcrumb privacy test | 03:48 | |
mwhudson | hmm | 03:51 |
mwhudson | bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/dulwich/devel/ has 129 inconsistent parents | 03:51 |
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:14 |
poolie | or do 50 reviews | 04:15 |
thumper | poolie: and you want it submitted for facebook for you? | 04:15 |
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:16 |
thumper | :( | 04:17 |
thumper | I found a bug in the canonical_url of bug comment | 04:17 |
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:18 |
thumper | poolie: want to do a call now? | 04:19 |
poolie | sounds good | 04:19 |
mwhudson | spm: ping | 05:00 |
spm | mwhudson: yo | 05:00 |
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:02 |
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:03 |
spm | mwhudson: this week? not so far as I'm aware of. :-/ | 05:04 |
mwhudson | oh well | 05:04 |
=== almaisan-away is now known as al-maisan | ||
adeuring | good morning | 06:48 |
jtv | noodles775: good morning! Delegating deletion of BuildFarmJobs is complicated a bit by the introduction of BuildFarmJobDerived. | 08:18 |
noodles775 | jtv: in what way? | 08:19 |
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:20 |
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:21 |
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:22 |
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:23 |
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:26 |
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:27 |
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:28 |
jtv | noodles775: do I need to make provisions for IBranchJob implementations that aren't BranchJobDerived? | 08:30 |
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:32 |
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:33 |
noodles775 | jtv: I assume one of the code guys, but annotate should show you. | 08:34 |
jtv | yes | 08:34 |
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:35 |
noodles775 | jtv: so the only mention of IBranchJob I can see is your IBuildFarmBranchJob (implemented by TranslationTemplatesBuildJob). | 08:39 |
jtv | noodles775: ironically, "bzr annotate" shows just "michael" for the Derived changes... I guess that's mwhudson then. :) | 08:40 |
noodles775 | yep (well, for the BranchJobDerived changes) :) | 08:41 |
jtv | Did I say BranchJobDerived? I meant BuildFarmJobDerived. Sigh. | 08:48 |
noodles775 | jtv: ok, that is the one that I created (using the same pattern as BranchJobDerived). | 08:49 |
jtv | Confusion reigns. | 08:49 |
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:50 |
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:51 |
noodles775 | jtv: Nope. | 08:52 |
jtv | Great. Saves me some other potential complications as well. | 08:52 |
noodles775 | Excellent. | 08:53 |
bigjools | morning | 08:55 |
jtv | noodles775: something puzzling here... why did getByJob move from a utility class into IBuildFarmJobDerived? | 09:36 |
noodles775 | jtv: it was only used by classes inheriting from IBuildFarmJobDerived... from memory. | 09:38 |
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:40 |
jtv | noodles775: not in IBuildFarmJobDerived it's not. | 09:41 |
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:42 |
noodles775 | Just otp... back in a few mins. | 09:43 |
noodles775 | jtv: ok, back. So the mistake was that the IFace does not define it as a classmethod, or was there more? | 09:55 |
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. | 09:56 |
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:06 |
* 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:07 |
jtv | I worked around it by invoking getByJob directly on the class, without going through the utility. | 10:08 |
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:09 |
=== al-maisan is now known as almaisan-away | ||
=== almaisan-away is now known as al-maisan | ||
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:14 |
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:15 |
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:30 |
noodles775 | jtv: can you create a WIP MP? | 10:31 |
jtv | noodles775: OK | 10:31 |
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:33 |
jtv | noodles775: https://code.edge.launchpad.net/~jtv/launchpad/bug-569108/+merge/24297 | 10:35 |
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:37 |
jtv | but wait... the order to delete the BuildQueue comes in even before that. | 10:38 |
noodles775 | jtv: just otp again, but will look straight afterwards. | 10:41 |
jtv | thanks | 10:41 |
wgrant | allenap: Hmm, so that's twice it's vanished? | 10:44 |
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:46 |
wgrant | lp:~wgrant/launchpad/fix-mailman-testrot also probably disappeared, although it's so long ago that I don't remember. | 10:47 |
thumper | jtv: I'm being nice to translations | 10:50 |
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:51 |
wgrant | allenap: Thanks. | 10:52 |
thumper | jtv: you do, and they are reasonably good | 10:53 |
thumper | jtv: I've refactored the base breadcrumb test case | 10:53 |
* jtv tries to swap the subject back in | 10:54 | |
jtv | noodles775: found it | 11:08 |
noodles775 | jtv: great... what was it? | 11:09 |
jtv | noodles775: this is why strong typing is sometimes a good idea, and naming things after their type is often a bad idea | 11:10 |
jtv | buildqueue wasn't a BuildQueue. | 11:11 |
noodles775 | Ah. | 11:11 |
* thumper mops brow | 11:12 | |
thumper | that's all the breadcrumb tests fixed | 11:12 |
thumper | in the vetinary sense | 11:12 |
jtv | thumper: neutered..? | 11:13 |
thumper | put down :) | 11:13 |
jtv | thumper: hope your kids aren't there to hear that... | 11:13 |
=== al-maisa` is now known as almaisan-away | ||
=== almaisan-away is now known as almaisan | ||
=== almaisan is now known as al-maisan | ||
thumper | ✁☹ | 11:26 |
thumper | I should have stopped by now :( | 11:26 |
* thumper is done now | 11:31 | |
thumper | branch is in ec2 | 11:31 |
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 | 11:33 |
wgrant | jtv: I think you might be confused about the slave's buildid handling. | 12:15 |
wgrant | 'build ID' may be an overloaded term, but 'chroot checksum' is not among its meanings. | 12:16 |
jtv | wgrant: but the one I'm pointing at is definitely the chroot checksum. | 12:17 |
jtv | So I'm saying it's _too_ overloaded in this case, probably by accident. | 12:18 |
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:19 |
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:20 |
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:21 |
jtv | wgrant: where do the BuildManager classes get instantiated anyway? | 12:23 |
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. | 12:26 |
=== mrevell is now known as mrevell-lunch | ||
=== matsubara-afk is now known as matsubara | ||
deryck | bigjools, ping | 13:22 |
=== mrevell-lunch is now known as mrevell | ||
bigjools | deryck: helleau | 13:23 |
=== salgado is now known as salgado-afk | ||
=== al-maisan is now known as almaisan-away | ||
=== salgado-afk is now known as salgado | ||
deryck | BjornT, ping. | 14:47 |
BjornT | hi deryck | 14:49 |
Ursinha | danilos, sure :) | 14:50 |
danilos | Ursinha, here are the people who can probably help you more than I can :) | 14:58 |
bac | reviewers meeting beginning | 15:00 |
=== 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 | ||
jelmer | danilo: I wasn't the one updating lp:~launchpad-pqm/bzr-git/devel, so I guess that must've been mwhudson | 17:24 |
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:25 |
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:26 |
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 | 17:27 |
=== EdwinGrubbs is now known as Edwin-lunch | ||
=== beuno-lunch is now known as beuno | ||
=== matsubara is now known as matsubara-lunch | ||
mrevell | Night | 18:12 |
=== 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 | ||
jml | thumper: I thought you might like to look at http://www.wikimatrix.org/ | 20:12 |
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:24 |
* jml stops for the day | 20:25 | |
=== bjf is now known as bjf[afk] | ||
=== deryck[afk] is now known as deryck | ||
=== salgado is now known as salgado-afk | ||
wgrant | Is PQM really open? | 22:40 |
mwhudson | wgrant: yes | 22:42 |
wgrant | I've two branches that were rejected during last night's testfix... and one that disappeared in EC2 (\o/) | 22:43 |
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:00 |
thumper | wgrant: pqm closes in approx 24 hours | 23:01 |
wgrant | Hm, I thought it was closing earlier. | 23:03 |
thumper | wgrant: that is earlier | 23:04 |
thumper | wgrant: normally it closes in approc 48 hours | 23:04 |
wgrant | Ah. oops. | 23:04 |
wgrant | mwhudson: Hi. | 23:26 |
mwhudson | wgrant: hi | 23:26 |
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:27 |
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:28 |
mwhudson | you're right that the debug print shouldn't be there though | 23:29 |
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:31 |
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 |
=== bjf[afk] is now known as bjf | ||
wgrant | Ah. | 23:32 |
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:34 |
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:35 |
mwhudson | wgrant: ok | 23:37 |
StevenK | wgrant: I had the same problem yesterday with EC2 instances buggering off. | 23:41 |
mwhudson | wgrant: two pqm-submits done | 23:45 |
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:46 |
wgrant | mwhudson: Even better. | 23:47 |
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:48 |
wgrant | You're not as leaky as you used to be, although I have some ideas :P | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!