[00:10] wallyworld: https://code.launchpad.net/~wgrant/launchpad/better-createManyTasks/+merge/105422 should be pretty quick [00:11] When you have a sec [00:11] * wallyworld looks [00:11] Thanks. [00:15] gmb: ping [00:16] czajkowski, Hi [00:16] gmb: coming int san fran @ 6:30 [00:16] shopping n dinner [00:16] How'd the clinic go? [00:16] czajkowski, Can't; too much to get done. Thanks for the invite, though. [00:16] 2 people asked for help to fix bugs today [00:16] gmb: np [00:17] gmb: too much retouching to do to my pic :) [00:17] wgrant: how tied are ppas into builds? [00:17] czajkowski: How do you mean? [00:18] wgrant: someone was sayign debian would like to have ppas [00:18] but mentioned that they are tied into builds [00:19] I believe that's Launchpad's bug with the most me-toos... [00:19] Bug #188564 [00:19] <_mup_> Bug #188564: Build also packages for Debian in PPA's

< https://launchpad.net/bugs/188564 > [00:20] Technically it's easy. [00:20] The resources and social aspects are less so. [00:20] well its been brought up todayin session [00:24] one of my goals is to allow people to use their own machines to build packages in their own ppas [00:25] which would open up the possibility of debian ppas [00:29] wgrant: so the flush() business on the createTask just isn't necessary to maintain? [00:29] bigjools: ah good to know [00:30] czajkowski: but that's totally unofficial :) [00:30] czajkowski: but it's a place where maas could shine [00:31] rick_h_: createManyTasks uses create(), which does that implicitly -- it runs a manual explicit Insert and then loads the tasks from the DB. [00:31] rick_h_: Creating with BugTask() just adds it to the list of pending add operations. [00:32] wgrant: ah, ok gotcha [00:33] We also probably should rewrite validate_new_target and validate_target to be set-based, as they can be somewhat expensive, executing a few queries per target. [00:33] Eventually. [00:34] wgrant: while you're in there with this can you hit lifeless's suggestoin on removing the BugTask middleman? [00:34] rick_h_: I didn't see that... is it a comment on the MP? [00:34] https://code.launchpad.net/~rharding/launchpad/bugnom_874250/+merge/105317 [00:34] yea, after it was merged, so was going to do a follow up branch in the moring, but while you've got changes going [00:35] it'll be more LoC reduction [00:35] Ah, it being post-merge would explain why I didn't see it. [00:35] Will fix, thanks for the pointer. [00:35] ty much for the work, looking it over for education purposes [00:36] It can seem nice to have helpers on Bug like that, but then you end up with multi-thousand line classes like Person :/ [00:36] np [00:36] Thanks for working on these damn timeouts. [00:36] yea, well consistant vs "right" so oh well, guessed wriong [00:36] I might land a followup to drop Bug.addTask too [00:37] There's only a few dozen callsites. [00:37] Mostly tests. [00:37] heh, this is awesome, so when I looked at removing the _init_ didn't want to dupe some of the code, but by doing that you get to remove it all [00:37] wgrant: yea, that seems like it'd be the best plan, but trying to wrap this up by EOD torrow [00:37] Exactly :) [00:37] so wasn't goint to go all the way through the clenaup atm since we've got a full plate starting next week [00:38] rick_h_: Eventually we probably want to move the nomination stuff into createManyTasks as well, but that opens a bit of a can of worms which I didn't really want just yet. [00:38] wgrant: so the next timeout issue there is on the notification subscriber stuff [00:39] it queries person 100's of times for 100's of subscribers, that's the next point after this one lands [00:39] BugNotificationRecipient? [00:39] Oh [00:39] That, right. [00:39] sec, wonder if I still have the paste [00:39] That's going to be a fun one -- I'll be surprised if you get it done this week. But worth a try. [00:40] yea, this is all for now [00:40] I've got to finish the bugtask.txt killing tomorrow [00:40] Yep [00:40] Good riddance :) [00:40] Death to doctests, and all that [00:40] damn straight [00:41] http://paste.mitechie.com/show/650/ is a sucky paste of the oops post this change [00:42] the select Person seems to be the next target [00:42] Inserting 242 bugtasks may still be too slow, given the exponential behaviour of bugsummary. But this has to be better than before. [00:42] And I'm rewriting bugsummary today to not be exponentially complex. [00:43] cool [00:43] Ah, I misread the OOPS, there's not 242 in that case. [00:43] But we do have insane numbers like that sometimes. [00:43] The Ubuntu kernel team always manages to find new ways to break LP :( [00:43] right it was taking 240ms per insert, now it's one inesrt to hopefully this helps a ton [00:44] Most of that's likely to be bugsummary, but we'll see. [00:44] wallyworld: Thanks. [00:45] np [00:53] rick_h_: Ah, can't actually remove addTask, since it's exposed on the webservice. [00:55] return None! [00:55] WCPGW [02:10] wgrant: booo, oh well [05:38] wgrant: did you have a pre-impl with anyone re: the sample data change? it sounds reasonable [05:39] wallyworld__: I polled lifeless and StevenK in -ops and nobody complained. [05:40] 15:05:17 < StevenK> wgrant: When I last used it, which was yesterday, I expected it to write to current{,-dev}.sql. [05:40] etc [05:40] wgrant: ok, thanks. r=me [05:40] wallyworld__: Thanks [06:16] wgrant: I suggested a larger sample size... [06:17] My sample size covered a third of the active team. [06:17] That's sufficient. [06:17] Haha [06:31] wgrant: so, I've just mailed the list in reply to curtis; I may be confused on some stuff... feel free to unconfuse me :) [06:33] lifeless: I can't disagree with anything you said. === wallyworld__ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2 [07:15] kk === almaisan` is now known as al-maisan [09:25] gmb: would something explode if I increase the version number for testresources in versions.txt to 0.2.5? [09:36] adeuring: I think everything using testresources is using the package or buildout, so bumping the version is pretty much a requirement before anything can see your changes. [09:38] stub: right === adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugs: 3.47*10^2 [10:16] wgrant: We should be able to write a script to generate the bugtaskflat indexes by now :) [10:17] stub: Indeed. [10:17] I'll hopefully drop 2/3 of bug and bugtask's indices next week. [10:18] And hopefully DROP COLUMN bug.private soon after [10:18] wgrant: r=stub. Does this go live now? [10:18] Or staging first? [10:18] stub: I've tested them on DF, so live would be nice. Nothing will use them until Monday. [10:19] I'll apply it live now, assuming everything is quiet. [10:19] Should be. [10:19] Given that we killed everything 20 minutes ago [10:24] I'm surprised BugTaskFlat inserts are still performing OK, with 63 indices. [10:24] Although I guess most of them are very partial. [10:25] Launchpad is very low write. [10:25] And PG has been optimized over decades :) [10:25] Indeed. [10:25] Speaking of which, when can we upgrade to 9.2? :) [10:25] Index-only scans ftw. [10:26] It will take a while with librariangc and apache-log-parser running [10:26] wgrant: Sometime after it is released I think. [10:26] Bah [10:26] Live a little. [10:51] wgrant, hey. it looks like the sampledata change breaks a lot of tests. The parallel runner shows 197 errors (http://ec2-23-20-37-133.compute-1.amazonaws.com:8010/waterfall) and the standard one shows 6 so far (https://lpbuildbot.canonical.com/waterfall) [10:56] actually the errors seem very different [10:56] http://ec2-23-20-37-133.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/4/steps/shell_8/logs/summary [10:56] vs. [10:56] https://lpbuildbot.canonical.com/builders/lucid_lp/builds/2054/steps/shell_6/logs/summary (which is, wow, hard to read) [10:58] lp.codehosting.puller.tests.test_scheduler.TestPullerMasterIntegration causes everything to fall over in the official buildbot [10:58] gary_poster: Odd, I've had two ec2 runs with those revs without a problem. [10:58] The production thing looks unrelated. [10:58] It's just normal flakiness [10:58] Looking at parallel [10:59] That looks unrelated as well [10:59] wgrant, agreed. sorry for bothering you; I saw the seeming correlation and assumed. [11:00] Quite a reasonable assumption... it's a more spectacular failure than we normally see spuriously :/ [11:00] heh, yeah [11:00] Worrying. [11:01] we'll look into the ones we encounter on parallel. As you probably saw, I forced a build on parallel, so hopefully that will show a green build [11:01] Well [11:01] TBH I hope it fails the same way :) [11:02] Having 200 spurious failures like that is ungood. [11:02] Well, we generally file a bug and try to fix them anyway, if we can. Sometimes it's harder to dupe than others. [11:02] Yeah. [11:14] stub: Thanks. === al-maisan is now known as almaisan-away === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring,bac | Firefighting: - | Critical bugs: 3.47*10^2 [12:14] morning adeuring [12:23] adeuring: i'm going to start on wgrant's review === almaisan-away is now known as al-maisan [12:25] bac: ok (and good morning :) [12:25] Thanks bac. === al-maisan is now known as almaisan-away [13:32] deryck: ping for stand up party time [13:32] rick_h_, yup, on the way, thanks [13:57] Hi! Do the production LP updates happen at specific times during the day? === noodles785 is now known as noodles775 [14:02] noodles775: no, they occur as they're ready to go usually [14:03] k, thanks rick_h_ [14:04] noodles775: has some info https://dev.launchpad.net/LEP/FastDowntime [14:07] rick_h_: I'm getting "ImportError: No module named convoy.meta" http://pastebin.ubuntu.com/981754/ [14:09] abentley: your download cache is up to date? [14:09] rick_h_: yes. [14:09] sorry, mean your deps, it's in the lp ppa [14:11] rick_h_: I'll check. [14:12] abentley: yea, looking for the -deps [14:12] abentley: looks like it's in apt-cache show launchpad-developer-dependencies [14:12] rick_h_: Not seeing convoy listed by apt-get upgrade. I do see other LP deps. [14:13] abentley: it's listed as python-convoy if that helps at all [14:16] morning [14:23] rick_h_: looks like I had uninstalled launchpad-developer-dependencies. [14:23] abentley: ah ok. Yea, debugging here, I've got some many copies floating around with dev version, pypi versions, etc [14:51] allenap: How does with-xvfb compare to xvfb-run? === mrevell_ is now known as mrevell === matsubara is now known as matsubara-lunch === adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: bac | Firefighting: - | Critical bugs: 3.47*10^2 === salgado is now known as salgado-lunch [16:45] jcsackett: ping, so is the issue with the dupe banners a matter of cleaning up the creators of banners is a pita? [16:45] jcsackett: one other way to do the single method is to stick a variable in the module file and to store the $node so you don't have to query again. [17:00] rick_h_: oh, i like the idea of just storing the node. [17:01] although, come to think of it, that won't actually work. [17:02] jcsackett: yea, I started thinkering in a branch but it's a bit messier [17:02] you'd have to store a dict key'd by the class.NAME [17:02] but then it looks funky when you pull it out and .set(text) [17:02] and I don't have a full view of the scope so I'll just shush [17:02] rick_h_: well, and there's still the problem of what happens if a banner object is created in another module. [17:03] like, there's a banner created in the js in base-layout-macros on any private page. [17:03] right, but this is tracked in the YUI.add() so there's only one [17:03] you can stick 'private' vars inside that .add() code [17:03] just how var ns = Y.namespace... each module has that ns. and it's a single value for all of that module definition [17:04] no matter where it's used/messed with [17:04] rick_h_: ah, got it. [17:04] i think when i read "in module" i thought "in class". [17:04] but yea nvm...forget me. Ugh on the need to deal with it, but understand [17:04] right, no I mean in module [17:04] rick_h_: yeah, it's still not perfect, but it's better. [17:04] sometimes i'll take better. :-) [17:04] a module can contain private stuff, mutliple classes, etc [17:04] * jcsackett nods [17:05] anyway, sorry I stuck my nose in it, my curiosity got peaked [17:05] all good. you didn't happen to read enough of the MP to vote "approve" on it, did ya? :-P [17:05] yea, I guess I'm there might as well eh [17:05] *i* certainly wouldn't mind. :-) [17:06] and i'm sure bac would be happy to let someone else help clear out active reviews. :-P [17:06] k, sec, will do === deryck is now known as deryck[lunch] [17:13] jcsackett: ok, approved with comments [17:13] thanks, rick_h_. === matsubara-lunch is now known as matsubara === salgado-lunch is now known as salgado [17:34] bac ping [17:35] hi sinzui [17:36] bac , have you looked at https://code.launchpad.net/~dooferlad/launchpad/upcoming_view_show_all_work_items/+merge/105495 yet [17:36] sinzui: no [17:37] bac: I just investigated it. I will take it [17:37] sinzui: ok. do you know what happened to wgrant's branch? [17:38] The one replaced methods to create fast queries of new bugs? [17:38] sinzui: ah, i see you got to it. [17:38] i got tied up before lunch. thanks for handling it [17:38] I did. He made some changes for me and merged it 30 minutes later [17:38] cool [18:00] morning === deryck[lunch] is now known as deryck [18:18] jcsackett: thanks for giving that a shot, sucky it didn't help [20:18] flacoste: ping; any chance of a quick call ? === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2