[00:05] Project devel build (473): STILL FAILING in 5 hr 24 min: https://hudson.wedontsleep.org/job/devel/473/ [00:05] * Launchpad Patch Queue Manager: [testfix][r=jml, leonardr][bug=251685, [00:05] 586695] An implementation of the Poppy FTP server using Twisted. [00:05] * Launchpad Patch Queue Manager: [r=henninge][no-qa] Replace DistroSeries/SourcePackageName with [00:05] SourcePackage in translationsharinginfo. [00:05] * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=721784][no-qa] [no-qa] [00:05] [r=leonardr][bug=721784] Add ec2 list command to list running ec2 instances [00:05] and test status [00:10] Any other reviewers around? [00:10] sinzui: ^^? [00:11] sinzui: thanks, was otp [00:12] wgrant: is that the right way around? [00:12] shouldn't it be 'is not None' ? [00:13] sinzui: trying it now [00:13] lifeless: Yes. [00:13] So, then, why does it work. [00:14] wgrant: because its not none so it leaves it installed [00:15] wgrant: you're testing the external contract 'do not warn on this case' - but thats not comprehensive ;) [00:15] sinzui: >< [00:15] File "/home/robertc/launchpad/lp-branches/working/lib/canonical/launchpad/browser/launchpad.py", line 283, in makeBreadcrumbForRequestedPage [00:15] if view.__name__ != default_view_name: [00:15] AttributeError: 'Branch' object has no attribute '__name__' [00:16] request = make_fake_request( [00:16] 'http://code.launchpad.dev/~%s/%s/%s/+index' % (branch.owner.name, product.name, branch.name), [00:16] [branch.owner, product, branch]) [00:16] view = create_initialized_view(branch, '+index', request=request, principal=branch.owner) [00:16] view.render() [00:17] lifeless: Heh, what this shows is that the synchronizer can just be registered at startup. [00:18] It doesn't matter if it's removed any more, because with Storm there is only ever one. [00:18] Will investigate later. [00:19] you're inverting the if for now ? [00:19] Yes. [00:19] Just testing that it behaves properly in the app. [00:20] It does. [00:21] lifeless: DOne. [00:23] approved [00:24] Thanks. [00:44] sinzui: something really odd is going on here [00:44] in pdb I get this: [00:45] (Pdb) self [00:45] [00:45] (Pdb) view [00:45] [00:45] but in the test, the second is the branch /object/ [00:45] not the view [00:47] ah [00:47] sinzui: [00:47] (Pdb) self.request.traversed_objects[4] [00:47] [00:48] sinzui: I think create_initialized_view should poke that in [01:00] fingers crossed! [01:06] sinzui: so I made it work, but its showing a query count of 19, which is implausibly small [01:07] sinzui: http://pastebin.com/nB3ZSn2t for your reference, I'm going to use getUserBrowser now [01:11] sinzui: getUserBrowser finds - Difference: queries do not match: 50 is >= 53 [01:36] wgrant: have you landed that webapp session cache preloading yet ? [01:36] lifeless: It's in ec2. [01:36] Windmill killed it last night. [01:37] its new matcher time, baby [01:37] Oh? [01:38] rewriting assert_milestone_page_query_count as a matcher for reuse [01:42] Excellent. [01:45] 0 tests run in 3:51:18.052785, 0 failures, 0 errors [01:46] Ah, windmill. [01:46] ., [01:46] Die Windmill die. [01:46] OK, I am going to lunch and then beat Windmill to death with a few ec2 instances. [02:04] wgrant: are you cleaning up test_milestone in that change? [02:06] lp:~lifeless/launchpad/bug-710685 if anyone is interested === lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews [02:25] lifeless: What needs cleaning up? [02:25] wgrant: accomdations for the session issue [02:25] I have a test in there that does a request to seed it [02:25] Ah. [02:25] may be others scattered around the code base [02:26] I have two unexplained failures that *appear* to be fallout, but look fairly irrelevant, and only show up on ec2. I am sorting them out first. [02:26] +opstats OOPSes unexpectedly :/ [02:26] But this is in PageTestLayer... [02:26] http://pastebin.com/f6xQ1J8L [02:26] ^- thats what writing scaling tests is down to now ;) [02:26] +opstats - whats the oops ? [02:26] Not sure yet. [02:27] Cannot reproduce locally. [02:27] >< [02:27] it runs w/o a db [02:27] But it's slightly crazy, since PageTestLayer runs an appserver in a subprocess... [02:27] Ah, hm. [02:27] do you not get the oops in the subunit stream now? [02:27] True. [02:27] james_w`: Not this one :/ [02:27] damn [02:27] It's a doctest, which may be relevant. [02:27] james_w`: only if the generator is in the same process [02:28] wgrant: this is xx-oops.txt ? [02:28] lifeless: xx-opstats.txt [02:28] wgrant: cause I saw an ec2 failure with it, but I made sure it passed locally before submitting [02:28] bah, thats the one I meant [02:28] Also librarian.txt failed. [02:28] wgrant: thats in-process FWIW, but its a doctest [02:28] But not on a second run. [02:29] I guess I will run just those tests in devel on ec2. [02:30] Interestingly they passed yesterday. [02:30] All I've changed since it loading bzr plugins. [02:30] So perhaps they are yet more wonderful spurious failures for me to crush this afternoon. [02:32] * lifeless facepalms [02:32] @cachedproperty [02:32] def linked_bugs(self): [02:32] """Return a list of DecoratedBugs linked to the branch.""" [02:32] bugs = self.context.linked_bugs [02:32] if self.context.is_series_branch: [02:32] bugs = [ [02:32] bug for bug in bugs [02:32] if bug.bugtask.status in UNRESOLVED_BUGTASK_STATUSES] [02:32] return bugs [02:32] Hahahah [02:32] That's been done before. [02:32] there are two bugs here. [02:33] Not cached if it's not a series branch, and lots of queries if it is. [02:33] yes! [02:33] well, not -quite- [02:33] because its a DecoratedBranch [02:33] which needs to be unwound and pushed down [02:34] utilities/ec2 list is great. [02:37] yep, both cases scale poorly [02:37] Heh [02:38] lifeless: Nice Matcher. [02:39] wgrant: thanks [02:42] UI check [02:42] currently the menu shows [02:42] 'Link to another bug report' [02:43] or 'Link to a bug report' [02:43] depending on - you guessed it - a query [02:43] Nice. [02:43] Drop it. [02:43] which doesn't matches the is_series_branch change [02:43] *check* [02:43] so, its a) broken. [02:43] b) pointless [02:43] yeah. [02:43] 'Link a bug report' is how I'd like to phrase it [02:43] Yeah. [02:43] The tags applied to this bug. Web service: The list of tags is whitespace delimited. Launchpadlib: The list of tags is represented as a sequence of strings. [02:44] james_w`: huwshimi has a branch for that. [02:44] great [02:44] Also, you seem to have a parasite. [02:45] * lifeless sobs [02:45] isBugBadgeVisible [02:46] Hah. [02:46] Nice. [02:46] not when you conside rthat context is a decorated branch [02:46] which means that this requires /all/ the bugs to evaluate [02:46] regardless of what it claims === james_w` is now known as james_w [02:49] hmm [02:49] the linked_bugs api call probably takes forever on these branches too [02:50] because its not eager loading anything, it will do just-in-time permission checks for every bug [02:51] *meep* [02:51] related_bugs [02:51] repeatedly queries the target branch bug list for every bug in the source branch [02:51] that kinda sucks [02:52] I'm sure that wasn't the intention :) [02:52] I'm sure it wasn't either [02:52] wgrant: Just sending that off to land now :) [02:52] given that I wrote it :) [02:52] huwshimi: Good luck with that... [02:52] wgrant: Is stuff still not working? [02:52] its a symptom of us not having a persistence layer and data access being mixed with business logic as python code [02:52] lifeless: Confirmed xx-opstats.txt occasionally shows up on devel... but only on ec2. [02:52] huwshimi: ec2 land is still a bit broken. [02:52] pqm-submitting the branch now. [02:52] wgrant: I'd lke to see the error [02:53] wgrant: Should I just wait for Monday [02:53] ? [02:53] thumper: I know you spent a lot of time on this, its really tricky with the tools we /had/ and still pretty darn tricky [02:53] thumper: https://bugs.launchpad.net/launchpad/+bug/710685 is the bug I'm chasing [02:53] <_mup_> Bug #710685: Branch:+index timeouts - 3 queries triggered per linked bug < https://launchpad.net/bugs/710685 > [02:53] huwshimi: 40 minutes should do it. [02:54] wgrant: Oh awesome [02:54] * thumper sighs [02:54] lifeless: Forwarded. [02:54] thumper: http://pastebin.com/uf0FCV1G is my work in progress - currently that test shows 58 new queries in the second assert - for both the series and nonseries case. [02:54] lifeless: That's plain devel except for my fixed ec2test-remote.py [02:55] Can't reproduce the librarian failure anyway, but it only showed up in one of the three runs. [02:55] wgrant: I assume these errors are related to those issues? http://paste.ubuntu.com/572017/ [02:55] So it's probably old and spurious too. [02:55] the good news is we squashed nearly 200 timeouts since last week [02:55] wgrant: From another branch [02:55] 600 overnight vs 800 [02:55] huwshimi: That's fixed now. [02:55] wgrant: your mua sucks [02:55] lifeless: Oh? [02:56] wgrant: I got a .eml attachment with base64 encoded internal structure + headers [02:56] lifeless: I use Thunderbird on my desktop and Evolution on my laptop, and they both suck. [02:56] wgrant: Is that just related to landing the branch? As in, can I just manually land that branch or do I need to resubmit for testing? [02:56] huwshimi: I'd lp-land that. [02:57] No point retesting. [02:57] wgrant: Great, thanks. [02:57] The fact that the original change got through in the first place shows that there are no tests. [02:58] buildbot approaches the moment of truth... [02:58] It is past it! [02:59] Windmill did not blow up! [03:00] lifeless: Were you able to read the attachment? [03:00] Or shall I forward with Evo instead? [03:01] And add Thunderbird to my list of things to eliminate after Windmill and xx-opstats.txt [03:02] Hmmm. Can someone try to click the diff link on https://code.launchpad.net/~wgrant/launchpad/secret-query-count-determinism and then try and close the diff popup? [03:03] anyone seeing ec2 errors on xx-opstats.txt ? [03:03] I thought wgrant just mentioned that [03:03] wgrant: not without more futzing than I have mental space for right now [03:04] [13:52] < wgrant> lifeless: Confirmed xx-opstats.txt occasionally shows up on devel... but only on ec2. [03:04] StevenK: Yes, broken here too. [03:04] thumper: When did you first see that. [03:04] StevenK: (the diff popup, that is) [03:04] wgrant: Excellent. Let me file a bug [03:04] now [03:04] well, on the ec2 run that just finished [03:04] thumper: Which rev of devel? [03:04] works locally now though [03:04] * thumper checks the email [03:04] thumper: It always works locally. [03:04] r12457 [03:05] But fails around half the time on ec2. [03:05] Thanks. [03:05] half? [03:05] anyone want to claim a review? https://code.launchpad.net/~wallyworld/launchpad/recipe-request-build-partial-success/+merge/50873 [03:05] thumper: hi [03:05] thumper: question for you about linked bugs [03:05] thumper: which bugtask do we /intend/ to show ? [03:05] lifeless: shoot [03:05] lifeless: it should be the bugtask relating to the target of the branch [03:06] tal:define="bugtask bug/bugtask [03:06] sometimes it is linked to a bug that doesn't have a task for that [03:06] is the lookup [03:06] in which case, we get the first [03:06] I can't find a bugtask attribute on bug [03:06] is it on the annotated bug? [03:06] ah [03:07] DecoratedBug [03:07] right [03:07] is branch.target the context of the branch [03:07] e.g. the product/sourcepackage ? [03:08] it is a BranchTarget object [03:08] lifeless: Can I blame you? [03:08] I think I might. [03:08] thumper: I'm sure you considered this, but what about linking to bugtask ? It would push this complexity to where we add links, but we wouldn't pay it after [03:08] wgrant: it might be me [03:09] wgrant: pastebin it [03:09] lifeless: I'm thinking that your profiling stuff is suspicious. [03:09] But I still can't repro locally. [03:09] lifeless: it was considered but just not done, we could also link revisions as fixes [03:10] lifeless: http://paste.ubuntu.com/572027/ [03:11] Ew, doctest diffs [03:12] I guess I will add some getLastOops stuff to it and rerun. [03:12] Because it does not want to happen locally. [03:12] Has anyone seen it before r12457? [03:13] Confirmed. [03:13] +opstats OOPSes on launchpad.dev [03:13] its throwing a 503 [03:14] Hm, not 500? [03:14] wgrant: thanks for finding and digging [03:14] + 503s:1@1298603161 [03:14] + 5XXs:1@1298603161 [03:14] Oh. [03:14] and there is one error higher up [03:14] +opstats explodes when you are authenticated regardless. [03:14] yes [03:14] 503... it times out? [03:30] lifeless: Can you check how many BugSubscriptionFilters staging and qastaging have? [03:30] We added them manually on production, so I think they may be missing on the stagings. [03:30] Which would explain the quick query. [03:31] The plan suggests that there are very fwe. [03:33] 4 [03:33] Hah. [03:33] So the plan is completely invalid. [03:33] That would do it. [03:40] how many filters does prod have? [03:41] wgrant: ^ ballpark [03:41] lifeless: SELECT COUNT(*) StructuralSubscription [03:41] It has one for every strucsub. [03:41] wgrant: that was the conversion thing ? [03:42] so, unknown number. did you happen to see the actual row count inserted ? [03:42] lifeless: Yes, we added a no-op filter for every subscription. [03:42] Yes. [03:42] [yes unknown?] [03:42] INSERT 0 24056 [03:46] lifeless: I have a traceback for you. [03:46] http://paste.ubuntu.com/572033/ [03:46] It is *timing out* in the flag check. [03:48] Ah. [03:48] I see. [03:48] The tests override the timeouts. [03:48] This wasn't a problem before because there was no DB access. [03:49] But now it checks the timeout before it can raise a DisallowedStore. [03:49] Impressive. [03:51] the flag layer checks the timeout [03:51] because if you just query and get timed out by the db - in other tests - you end up with a doomed transaction [03:52] which is a world of pain when that happens *in the error handler* [03:52] Ah, right. [03:52] however [03:52] Have you filed a bug, or shall I? [03:52] its passing that (not timed out), then doing the query, and is slow enough it has then timed out [03:53] wgrant: if you would [03:53] that would be great [03:53] lifeless: But there should be a DisallowedStore in there somewhere, right? [03:53] Before it gets to the query. [03:55] I would have expected that, yes. [03:55] except [03:55] uhm [03:55] it probably hasn't traversed to +opstts yet [03:55] *+opstats* yet. [03:56] Ha ha ha. [03:56] Nice. [03:56] Bug #724718 [03:56] <_mup_> Bug #724718: xx-opstats.txt failing occasionally < https://launchpad.net/bugs/724718 > [03:59] those tests are basically bong [03:59] Almost all of our tests are basically bong. [03:59] every time I change instrumentation gathering, or things like features, I meet them again. [04:06] wgrant: uhm, it may be we need to patch into zope publication more and switch to a 'straight after traversal before callObject' point [04:06] wgrant: and/or call out from right after the dbpolicy is installed [04:06] which would be a shame, because traversal is nonfree [04:06] Yes :( [04:07] Anyway, sounds like we may want to roll it back, or possibly just mangle the test a bit. [04:08] lifeless: +1 on your structuralsubscription suggestion. [04:08] wgrant: do what you think best; I think pushing the timeout up -just a little- will probably make it reliable [04:09] thumper: so whats the branch target for a junk branch? I'm very confused about the difference between a branch target and a bugtask target [04:09] lifeless: it is a PersonTarget [04:09] lifeless: It looks like the timeout-causing views will adapt themselves to the configured timeout values. [04:10] lifeless: BranchTaget objects are found in lp.code.model.branchtarget [04:10] Which is handy, albeit in a "I think I'm going to be sick" way. [04:11] thumper: interesting thing [04:12] thumper: linked bugs show *no* bugtask if the task is on a different context [04:12] thumper: so I can just push that down to the bug search [04:12] lifeless: that seems wrong... [04:12] lib/lp/code/browser/decorations.py [04:12] the bugtask property returns [04:13] the result of getBugTask [04:13] which looks for an exact match and on failure returns None [04:14] which is excellent, I can push this all down to the db [04:14] refactor to return tasks not bugs [04:14] \o/ [04:15] lifeless: OTOH I can fix this permanently by popping the config before requesting +opstats [04:15] I might do that. [04:15] wgrant: \o/ [04:20] lets see how badly I've broken this [04:24] thumper: ah, I see what its doing; I will preserve it. Some epic confusion is possible here ;) [04:26] * wgrant narrows eyes at Windmill. [04:27] --layer=WindmillLayer has passed 5 times on ec2 so far. [04:27] Bad Windmill. [04:28] lifeless: https://code.launchpad.net/~wgrant/launchpad/bump-opstats-test-timeouts/+merge/51249 [04:29] wgrant: passed or failed? [04:30] thumper: passed. [04:30] thumper: I want it to fail so I can minimise the problem from "the whole test suite" [04:30] Because it's much quicker to run WindmillLayer than everything. [04:31] In fact it takes only 46 minutes. [04:31] lifeless: Thanks. [04:32] wgrant: comments welcome https://code.launchpad.net/~thumper/launchpad/inline-recipe-name-edit/+merge/51248 [04:34] * thumper lands self reviewed branch [04:35] https://code.launchpad.net/~thumper/launchpad/recipe-heading-overlap/+merge/51250 in case anyone cares... [04:35] fixes bug 721134 [04:35] <_mup_> Bug #721134: Description and Recipe Text heading overlap when logged out < https://launchpad.net/bugs/721134 > [04:37] * thumper EODs [04:37] I'll check in later on ec2 test runs [04:38] lifeless: It has the usual line editor glitches, but apart from that looks great. [04:38] Er. [04:38] thumper: ^^ [04:38] wgrant: what does ? [04:39] wgrant: what line editor glitches? [04:39] thumper: Clicking the edit link next to the name shifts the whole page down slightly. [04:39] wgrant: file a bug and I'll fix it [04:39] wgrant: I did fix the multi-line editor 1px down-shift [04:40] wgrant: that it got on hover [04:40] wgrant: those are the sort of bugs that most people never notice, but once you have, it annoys the shit out of you [04:40] thumper: The single-line editor one is really obvious. [04:41] Have you seen it? [04:41] wgrant: not focused on it [04:42] thumper: lazr-js or launchpad? [04:42] wgrant: both? [04:43] I fixed the multiline in lazr-js [04:45] thumper: Bug #724727 [04:45] <_mup_> Bug #724727: Single-line inline editor causes page to shift when editing < https://launchpad.net/bugs/724727 > [04:45] wgrant: ta [04:51] * StevenK peers at dogfood [04:51] StevenK: Oh, are you doing stuff to it? [04:52] I am testing the trio of poppys. [04:52] KeyError: 'request_daily_build'
[04:52] StevenK: New templates, old code? [04:52] Well, what is the full traceback? [04:52] Could be. Unsure [04:53] wgrant: Let me dig up the OOPS [04:53] StevenK: Shall I restart the appserver? [04:53] wgrant: 17471.DF5 in the usual place [04:54] Ja, needs appserver restart. [04:54] * wgrant restarts the appserver. [04:55] wgrant: I'm worried that Julian is no longer testing Zope's poppy [04:56] StevenK: I just did. [04:56] Still works. [04:56] wgrant: Er, sorry. That due to his changes the testsuite no longer is. [04:56] Ah/ [04:56] Maybe. [04:56] Has the appserver restarted? [04:57] No. [04:57] Still building the WADL so it can stop. [04:57] Fail [04:58] Is down. [04:58] Coming back up. [04:58] Yes, he no longer is. [04:58] :( [04:59] \o/ down to one bugtask query [05:00] 2 related lookups to squash [05:00] wgrant: I'm not sure when Julian plans to kill the Zope FTP server, though, so it could be a non-issue [05:01] wgrant: I take it by the lack of make processes, the appserver is back? [05:02] StevenK: It should be. [05:02] I cannot auth to poppy-sftp, though :( [05:02] Hm. [05:02] Appserver did not come back up. [05:02] Did Julian pull db-devel? [05:02] Probably. [05:02] wut [05:03] wgrant: That reminds me. When I was in Adelaide there was one wireless network in range of where I was staying. The ESSID was 'lolwut' [05:04] wgrant: Usually when the appserver fails like this, dogfood-nohup.out fills with tracebacks [05:05] StevenK: It did. [05:05] The 'wut' was at a very strange error. [05:05] But I was looking in development-nohup.out instead. [05:05] dogfood-nohup.out has the usual patch failure. [05:05] Faking it now... [05:09] StevenK: We're back. [05:10] lp:~lifeless/launchpad/bug-710685 handles products properly now, still have productseries and distroseries to capture [05:10] wgrant: Confirmed, thanks. [05:13] wgrant: Any luck with ec2 land or still working on it? [05:13] huwshimi: The fix landed, merge devel [05:14] StevenK: Awesome thanks. [05:15] * StevenK grumbles at the lack of logtailing on dogfood buildds [05:16] Ah, poppy-sftp works better when it's not using the former production xmlrpc server. [05:16] StevenK: Do it manually. [05:16] Heh, former production? [05:16] wgrant: I don't know how :-( [05:16] StevenK: It was still using xmlrpc.lp.internal:8097, which died a couple of months ago. [05:17] StevenK: import xmlrpclib; xmlrpclib.ServerProxy('http://something.buildd:8221/rpc').status() [05:19] Which says IDLE [05:19] That would suggest idleness. [05:20] Clearly, but the build page itself and /builders disagrees. [05:20] Now it says building. WTF [05:21] Could have been resuming. [05:22] Or just being shit. [05:22] I did say karmic, it could have been digging out a chroot tarball [05:22] Indeed. [05:25] StevenK: I am done with mawson. [05:25] all three poppys work! [05:25] Project devel build (474): STILL FAILING in 5 hr 20 min: https://hudson.wedontsleep.org/job/devel/474/ [05:25] * Launchpad Patch Queue Manager: [testfix][r=jml][no-qa] Fix test failures in [05:25] devscripts.ec2test.tests.test_remote [05:25] * Launchpad Patch Queue Manager: [r=lifeless][no-qa] Allow overriding the profiling_allowed config [05:25] entry via a feature flag. [05:25] * Launchpad Patch Queue Manager: [r=jtv][no-qa] Work around Storm ClassAlias bug more cleanly. [05:25] wgrant: As am I. Incidently, you'll get some mail. [05:26] Which mail? [05:26] I got two more disappointing ec2 successes. [05:27] But is there anything else? [05:27] I changed some bug statues [05:27] *statuses [05:28] :( short months make me sad. [05:29] wgrant: Oh? [05:30] wgrant: Based on your experience do you think bug 579870 can be nailed shut? [05:30] <_mup_> Bug #579870: Packages built from daily builds say 'No signer' < https://launchpad.net/bugs/579870 > [05:30] StevenK: Yes, it's fixed. [05:30] StevenK: Less time to fix bugs. [05:30] The milestone is looking rather sad, yet we are a week from release. [05:31] wallyworld: O hai? [05:32] StevenK: de ho [05:33] wallyworld: We were going to add a button "Build right now" to daily built recipes, were you working on that? [05:34] It's done. [05:34] Will be deployed in 4 hours. [05:34] Ah, what's the bug number, I haz dupe [05:34] * wallyworld looks [05:34] bug 687623 [05:34] <_mup_> Bug #687623: No ability to manually trigger a build 'like the daily build system' < https://launchpad.net/bugs/687623 > [05:35] * wallyworld unlooks [05:35] So marked, thanks [05:35] 3 bugs knocked off [05:35] there's also some enhancements to that stuff waiting for review https://code.launchpad.net/~wallyworld/launchpad/recipe-request-build-partial-success/+merge/50873 [05:37] wallyworld: I also filed bug 724679 earlier. [05:37] <_mup_> Bug #724679: Not obvious why "Build now" button is missing < https://launchpad.net/bugs/724679 > [05:38] wgrant: you reall think that's a bug? [05:38] pbkbac [05:38] :-P [05:38] wallyworld: It had me confused for a while. [05:38] wgrant: i'm not sure what we can do about it though [05:38] wallyworld: Problem Between Keyboard And Blood Alcohol Content? [05:39] wgrant: you should know by now i can't type :-) [05:40] lifeless: What you want to do with bug 721460? [05:40] <_mup_> Bug #721460: Cannot use 'lp:bzr' as a branch in a recipe < https://launchpad.net/bugs/721460 > [05:41] wgrant: Thoughts on bug 515918? [05:41] <_mup_> Bug #515918: package_name and suite not passed to dailydeb < https://launchpad.net/bugs/515918 > [05:42] wallyworld: I put some concrete suggestions in the bug... do you have any thoughts? [05:42] * wallyworld looks at the bug [05:43] StevenK: I'm not sure. [05:43] StevenK: That needs testing. [05:44] wgrant: it's not quite that simple. there are other reasons why the build now link won't show, besides the recipe being stale [05:44] wgrant: eg if the user doesn't have upload permissions to the archive [05:44] wallyworld: Right, but one of those already has a warning at the top of the page. [05:44] And the other is a bug. [05:45] hmmmm. if you can convince thumper to assign it to me, i'll do it :-) he had some definite ideas about how he wanted that to work [05:45] I only know of two other cases it won't show: [05:46] 1) No permissions, for which there is already a big warning at the top of the page. [05:46] 2) Not a daily build, for which we should show the link. [05:46] Because that's still useful even for non-daily builds. [05:47] eg. when updating stuff in the ~launchpad PPA... we don't want daily builds, but a single-click build request would be wonderful. [05:47] In fact, you are more likely to want the "Build now" button if you are not a daily build. [05:47] there's already a "request builds" link for adhoc builds [05:47] But that is a more complex issue than merely presenting it better for daily builds. [05:47] wallyworld: Right, but these aren't ad-hoc builds. [05:47] the daily "Build now" link has a specific purpose [05:47] wgrant: http://pastebin.ubuntu.com/572056/ from Hudson [05:48] wallyworld: Right, and I want that purpose. [05:48] and you get it, no? but not if the recipe isn't stale [05:48] which is what the requirement stated [05:48] StevenK: Which revs is that? [05:49] so for the case "when updating stuff in the ~launchpad PPA,....", you wouls just use the "Request Builds" link? [05:49] wgrant: r12458 [05:49] wallyworld: But it's already preconfigured. [05:49] StevenK: Are you sure? [05:49] That could have plausibly been introduced by r12460 [05:50] wgrant: Er, a little [05:50] But it passes here. [05:50] wgrant: by "it's", you mean the "Build now" link is already configured to do the same thing as a daily build would if it were to run? [05:51] wallyworld: The ~launchpad recipes want the same functionality as a daily build, except on request. [05:51] Project devel build (475): ABORTED in 25 min: https://hudson.wedontsleep.org/job/devel/475/ [05:51] * Launchpad Patch Queue Manager: [r=allenap][no-qa] Implement splitting Package/Product translations [05:51] * Launchpad Patch Queue Manager: [r=thumper][bug=724004][no-qa][incr] Rename LP.client.cache and [05:51] LP.client.links to LP.cache and LP.links in preparation of [05:51] LP.client becoming a YUI module. [05:51] * Launchpad Patch Queue Manager: [r=mbp, [05:51] wgrant][ui=sinzui][bug=591274] Modified the bug tag field width so [05:51] that it is a more appropriate length for the content. [05:51] * Launchpad Patch Queue Manager: [r=jml][bug=724039, 724232][no-qa] Prepopulate the cookie secret cache, [05:51] preventing tests from seeing an extra query when they are the first [05:51] in a layer. Also unbreak ec2 land and silence the import fascist. [05:51] * Launchpad Patch Queue Manager: [r=lifeless][bug=724522] Make clear_request_started() work when [05:51] called twice in a row, unbreaking request retrying. [05:51] * Launchpad Patch Queue Manager: [r=leonardr][bug=712329, [05:51] 712331] Add extra recipe methods to the web service. [05:51] wallyworld: Daily builds get to build daily, but they also now get this nice single-click button to do everything. [05:51] Sorry for the spam, I'm upgrading to Jenkins [05:51] wgrant: and you get that but not if the recipe isn't stale :-) [05:51] wgrant: so your issue is you want to request a daily build even if the recipe isn;t stale? [05:52] wallyworld: Even if it's not configured to build daily? [05:53] ah, so when it's configured as " build on request", you want to trigger the build_daily() method [05:53] ? [05:53] wallyworld: Yes. [05:53] that's confusing perhaps? [05:53] The name is confusing, but the action is not. [05:53] I guess I don't understand why only daily builds get the one-click functionality. [05:54] so the problem scope is larger then since the naming of the boolean choices for "build daily/build on request" would need rework etc [05:54] Right. [05:54] That's why I separated it from the daily build status issue. [05:54] Mostly. [05:54] wgrant: i only came to recipes late so haven't got all the history of the requirements discussions etc [05:55] so i can't really tell you for sure why certain decisions were made [05:55] i can follow up with thumper [05:55] I was only really involved in the backend stuff, not the later frontend development :( [05:56] sure, but here we're talking about the semantics of a recipe attribute [05:57] wgrant: it is my suggestion, but I'm about to take the girls out to watch the rugby [05:57] thumper: What is your suggestion? [05:58] StevenK: I think its invalid [05:58] Won't Fix, if anything. [05:58] It is very valid. [05:58] StevenK: its definitely confusing on qastaging [06:00] * StevenK waits for aptitude [06:00] Sigh, the jenkins package conflicts with hudson [06:01] This is not convincing me of a pain-free upgrade process [06:18] wgrant: You know, I think that rabbitmq install error is due to DEBCONF_FRONTEND=noninteractive [06:18] StevenK: That rabbitmq install error? [06:19] wgrant: When Jenkins installs rabbitmq on a slave it errors [06:19] :( [06:19] Ah. [06:19] StevenK: I have a branch using rabbit [06:19] so thats probably important to fix ;) [06:19] lifeless: It's not quite that easy to get rid of the buildd secret, sadly. [06:19] lifeless: apt still needs it. [06:19] Even if lp-buildd does not. [06:20] wgrant: theres an alternative anyhow. [06:20] Have a nice friday everyone [06:20] wgrant: add and subscriber 'buildd' to all private ppas [06:20] Night huwshimi. [06:20] lifeless: Yeah. [06:21] lifeless: Do we have to use config-manager in PQM? [06:21] Can't we just use the precommit hook to pull download-cache?" [06:21] Without c-m it doesn't have to redownload the whole tree. [06:21] lifeless: It actually drops files on disk, the postinst fails [06:21] And it takes about 10 seconds instead of 20 minutes. [06:22] wgrant: yes [06:22] And I think it's because of noninteractive [06:22] wgrant: why wouldn't it need the whole tree? [06:22] lifeless: It already has the whole tree. [06:22] lifeless: eg. look at shipit merges. [06:22] wgrant: after the rm -rf ? [06:22] lifeless: Why would it rm -rf? [06:22] because it doesn't trust the build before [06:23] it might have been hostile [06:23] shipit merges have most of the history, and take like 2 minutes. [06:23] Ah, not 2 minutes, 25 seconds! [06:23] 25 second PQM! [06:24] config-manager can do a lightweight checkout [06:25] the thing thats slow is grabbing the whole history because *make check* uses bzr operations [06:25] fix *that* and we can switch to lightweight checkouts [06:26] [ `PYTHONPATH= bzr status -S database/schema/ | \ [06:26] grep -v "\(^P\|pending\|security.cfg\|Makefile\|unautovacuumable\|_pythonpath.py\)" | wc -l` -eq 0 ] [06:26] That's the only bzr operation I can see. [06:26] right [06:26] it opens the tree [06:26] the tree opens the branch [06:26] the branch opens the repo [06:26] And the lightweight checkout works. [06:26] it wants the pending head revision to show the last commit [06:26] wgrant: not once you chroot [06:27] wgrant: the ssh key for lp being outside the chroot [06:27] (and likewise the local disk copy in ~/archives/rocketfuel being outside the chroot) [06:27] lifeless: :( [06:27] lifeless: I'm late to this discussion, and have to hit the road in a sec, but stacked commit would help there. [06:27] lifeless: We could still make it approximately lots of times faster by just cping the tree across... [06:28] wgrant: except we don't start from a known good treee and we don't have any operation to give us one reliably. [06:28] But the local disk might be hostile! [06:28] lifeless: Hm? The on-disk copy is good. [06:28] spiv: stacked branches still open the parent [06:28] wgrant: I thought you meant the build tree [06:28] lifeless: If PQM's checkout outside the chroot is fucked, we are all fucked. [06:28] Hmm, even for 'bzr status'? That might be fixable. [06:28] wgrant: because we're not lightweighting it, *all* of sourcecode is copied. [06:28] lifeless: Right. And if we can't lightweight it, then we should just cp -a the tree into the chroot. [06:29] spiv: mixed blessing to change that [06:29] Then we can stop running buildout. [06:29] And have 30s PQM. [06:29] wgrant: its more complex than that; its in a shared repo [06:29] lifeless: That can be fixed. [06:29] Or the shared repo can be copied. [06:29] wgrant: and we don't want information leakage of embargoed revisions if someone gets smart [06:29] wgrant: its really a lot simpler to stop calling into bzr [06:30] lifeless: You know... [06:30] We don't need to chroot, really. [06:30] We don't need buildout. [06:30] We don't need to run any code from the tree. [06:30] We just need to run bzr st, check that no DB stuff is modified, and grep for conflict markers. [06:30] That's all check_merge does now. [06:31] so [06:31] change pqm [06:31] it does all of that except the db check [06:31] Just need to change the config, even. [06:31] add a feature to exclude changes to a subtree, add that to the config for devel, done. [06:31] We could just add the grep to the precommit hook. [06:32] It's sitting in Makefile at the moment. [06:32] wgrant: thats possible too [06:32] wgrant: and the pqm precommit hook runs outside the chroot [06:32] lifeless: Exactly. [06:32] No PQM code change required. [06:32] But no chroot required. [06:32] Project db-devel build (394): STILL FAILING in 2 min 9 sec: https://hudson.wedontsleep.org/job/db-devel/394/ [06:32] And no config-manager required. [06:32] So no half-hour required! [06:33] I'm not sure if we want the conflict marker test still. [06:34] * StevenK peers at Jenkins [06:34] We would lose the guarantee that buildout works. [06:34] But I think that is a reasonable sacrifice for 60x faster landing. [06:35] buildbot will tell us that [06:35] Uhhh [06:35] $ bzr branch http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel /mnt/test/launchpad/workspace/db-devel [06:35] bzr: ERROR: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/.bzr/repository/packs/09fb66d3dfb9df78e2bb1ca7b6c7aac9.pack is redirected to https://launchpad.net [06:35] ERROR: Failed to clone http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel [06:35] \o/ [06:35] also wtf [06:35] i guess its a 404 [06:36] It works now ... [06:36] so you hit a repack [06:36] (during a) [06:36] file a bug [06:36] StevenK: what lifeless said [06:36] StevenK: especially \o/ [06:36] It was repacking while downloading? [06:36] pqm did it, yes [06:36] StevenK: concurrent push while you pulled [06:37] It's a bzr bug or codehosting? [06:37] I'd say both :) [06:37] codehosting [06:37] Mainly codehostin [06:38] bzr can't really sensible handle a redirect there [06:38] because it points at not-a-pack [06:39] But I think it would be ok for bzr to understand that a redirect while reading a pack indicates "probably not there"; if bzr has gotten as far as trying to read packs it's already successfully fetched a bunch of other stuff under .bzr/ [06:39] spiv: 'ewww' [06:39] It might be too nasty to code though. [06:39] * lifeless puts on the http nazi hat [06:40] lifeless: https://bugs.launchpad.net/launchpad/+bug/724750 [06:40] <_mup_> Bug #724750: repacking during checkout results in wierd error < https://launchpad.net/bugs/724750 > [06:40] StevenK: go on, triage it. [06:40] Bah, sorry, forget to set status and importance [06:40] :) [06:40] StevenK: jinx [06:41] Triaged/Low. Not sure if you agree [06:41] https://code.launchpad.net/~lifeless/launchpad/bug-710685/+merge/51258 [06:41] StevenK: I agree [06:42] ^ thats I can has review, plox [06:43] Waiting for diff [06:44] What. [06:44] wgrant: Hm? [06:44] lib/lp/tests/test_no_conflict_marker.py [06:44] 49 lines of Python wrapped in two of make wrapped in one of shell. [06:44] To run one line of shell. [06:45] EEEEEK [06:46] lifeless: You stop importing TestCase in lib/lp/testing/tests/test_matchers.py and one class still bases off it? [06:47] lifeless: Your multi imports require ( and ) [06:49] lifeless: You didn't drop the unittest import from lib/lp/code/browser/tests/test_branch.py [06:51] As well as lib/lp/code/browser/decorations.py [06:52] I'm not sure about the move into setupBrowserForUser(), but I'm willing to humour you [07:05] https://pastebin.canonical.com/43935/ [07:05] I think that does the same as we do now, except without the test that buildout works, because I hate buildout. [07:08] StevenK: I don't stop importing TestCase [07:08] Ah. Fix your imports anyway [07:08] :-) [07:10] where are you saying () is needed ? [07:10] I've removed the two useless imports of unittest [07:11] StevenK: ^ [07:11] lifeless: from lp.testing import TestCase, TestCaseWithFactory , for instance. [07:12] blah [07:12] I *actually* intended that to be ok when I argued about this [07:12] but the nuance got lost somewhere [07:12] changed [07:13] Just run the import formatter and stress less [07:22] StevenK: anything else ? [07:23] lifeless: Not that I can think of right now [07:26] man, oracle are really not dealing with hudson stuff well [07:26] Oh? [07:26] Oh? [07:26] What have they broken now? [07:28] the long thread with charles rhys [07:30] lifeless: So, any flaws in my PQM plan? [07:30] I admit to not knowing PQM very well at all. [07:31] wgrant: pqm already rejects conflicts [07:31] lifeless: Sure, but people sometimes commit them. [07:32] I've seen them in MPs :/ [07:32] But we could probably drop that check, true. [07:32] other than that, it seems fine [07:33] while you're at it [07:33] care to look at why prod config landings take an hour [07:33] Same reason. [07:33] They grab and build LP, then verify all of the configs against the schema. [07:33] We could probably install lazr.config on prasé and do it without using the tree, though. [07:34] Let's see how easy that would be. [07:34] lifeless: You missed the imports in lib/lp/registry/browser/tests/test_milestone.py [07:35] Mmm, not really feasible. [07:35] We may have to live with long prod configs for a while :( [07:35] StevenK: which imports [07:35] from testtools.matchers import LessThan, Matcher ; from lp.testing.matchers import HasQueryCount, BrowsesWithQueryLimit [07:36] * wgrant foods. [07:36] I will return and request a deploy to finish off that incident. [07:36] Unless buildbot chokes on Windmill again, in which case I will be tempted to rs=me disablement of WindmillLayer. [07:37] Haha [07:37] StevenK: thanks [07:37] lifeless: If you've made that change, r=me [07:37] I have [07:38] needs a non-* review [07:38] Indeed [07:38] Can't help you, sadly [07:45] oh, there is a stub [07:46] https://code.launchpad.net/~lifeless/launchpad/bug-710685/+merge/51258 [07:55] Yay. [07:59] stub: could I get a review of https://code.launchpad.net/~lifeless/launchpad/bug-710685/+merge/51258 [07:59] lifeless: yer - looking already. [07:59] stub: cool, thanks [08:00] lifeless: I don't particularly like how you are having to sniff params.linked_branches for type in model code (browser code I could forgive when things are coming from HTML forms). [08:01] stub: it doesn't make sense to have a different parameter [08:01] stub: I don't like the sniff either, but the original linked_branches code was bong [08:01] it should have used not(None) and None with a normal searchbuilder right from the get go. [08:03] stub: we can fix that up separately [08:03] lifeless: So what is zope_isinstance(params.linked_branches, (any, all, int)) doing? any and all are builtin functions [08:04] stub: not here they aren't [08:04] canonical.launchpad.searchbuilder [08:04] this is the standard way for passing in constraints to bug searches [08:05] I see now. [08:06] Might be better to use a namespace since we are overriding builtins (searchbuilder.any) [08:07] stub: perhaps; its used bare /throughout/ bugtask.py though [08:08] stub: what I mean is, it wouldn't reduce the burden of that override at all to do different here [08:08] yup. Just thinking about 'best practice', and if it really matters (they may be builtins, but does anyone use 'em?) [08:08] and it would be inconsistent [08:08] I think we should improve it - perhaps move to Any rather than any, as a separate, large mechanical change. === almaisan-away is now known as al-maisan [08:09] lifeless: Ok. Better sooner than later though, as people will start cargo culting this code. [08:09] ah, the use of it in browser code I can change easily. [08:09] and will do so now [08:10] done [08:12] lifeless: line 139 of the diff, you should use shortlist rather than list [08:12] stub: doesn't that blow up at 1000 [08:13] (Not that I'm sure why you need to materialize the result set apart from doing what the docstring says) [08:13] lifeless: It should emit warnings for smaller lists than that. [08:13] stub: we're doing this because we have bugs with 400+ bugs [08:13] lifeless: But if we are materializing large lists, we have a different problem. [08:13] branches with 400_ bugs [08:14] stub: yah, I'm wondering about paginating these [08:14] I can put shortlist in there [08:14] lifeless: You can specify the expected sane limit [08:14] where does it live? [08:15] canonical.launchpad.helpers (for now...) [08:16] I'll run with the default [08:16] an oops will be no worse than the current timeouts [08:17] lifeless: So 'linked_bugtasks' has a docstring stating it returns DecoratedBugs [08:17] oh, shall fix. [08:18] I got kindof mired in the restructuring mess here - was tired at the end [08:18] lifeless: And further down, you do 'for bugtask in self.branch.linked_bugs' [08:18] hah - UserWarning: shortlist() should not be used here. It's meant to listify sequences with no more than 15 items. There were 36 items. [08:19] shortlist should be emitting soft oopses now soft oopses exist. [08:19] But the goal is good :) [08:19] i've given it a 1000 expected length. [08:20] thats a great point. [08:21] fixing that bugrask in linked_bugs code - http://pastebin.com/bw7Cv4UM [08:21] it is late evaluation [08:22] but AFAICT that code path isn't actually used anymore [08:22] I just haven't tracked down every case to be sure of it. [08:23] that looks fine [08:25] What does self.assertThat(branch, browses_under_limit) actually check? I'm not sure how a branch can be used to check a query limit. [08:25] it renders the default view for the branch [08:25] and checks the queries made doing that [08:25] it uses userBrowser [08:25] so we get the full stack, all the portlets etc [08:26] see the matcher, its new in the branch - it wraps a QueryCollector + HasQueryCounts [08:28] hi folks [08:30] jtv: Yo. I need you to better describe how you want those tests to look so I can land that branch. [08:31] stub: you could have a pruner that takes a list of ids for its constructor… makes it easy to create pruners that will or won't clean up specific objects. Or you could do it on some other specific attribute value. [08:32] Then you can do things like "create 3 objects that will get cleaned up; run one pruner iteration with a batch size of 2; now 2 are gone but one's still there." [08:33] Presto: no reliance on sample data. [08:33] I'm not relying on sample data [08:33] I thought you were? [08:33] The IrcID thingies? [08:34] Last iteration changed. Instead of using a random table with some arbitrary data (IrcId), I create a new table with some arbitrary data (FooSomething) [08:34] Oh cool [08:34] (Meanwhile, I'm browsing to the MP) [08:34] The data never mattered - I just needed a table with some data in it (> chunksize items actually) [08:36] lifeless: we probably can do the 'filter unnecessary bugtasks' in SQL, but I doubt it will be much of a win over the current approach. Not dealing with large numbers of items to prune here. [08:36] Wow that's a large indentation. Wasn't it easier to put the method body in a separate method, and wrap the call to that method in a try/finally? [08:36] stub: i think we should leave that for a later iteration [08:36] stub: *but* - some bugs have 100's of tasks [08:36] pathological ones to be sure [08:36] lifeless: Yes. I'm suggesting that later iteration might never happen. [08:37] Outliers, that are probably indicative of another bug (something is wrong if a bug has 100's of tasks) [08:37] stub: indeed. Lets be guided by data :) [08:37] stub: yes, something is wrong... we have users [08:38] Status: 666 (Electrocute Luser) [08:38] in fact looking at this I see another possible bug, Should we really show 'wontfix', 'invalid' and 'opinion' bugs [08:38] (we do currently, but it seems like an easy way to deal with these pathological bugs, just don't bring back those tasks. [08:38] lifeless: This is model code, so you really shouldn't be making decisions for the browser code here. [08:39] stub: the browser code passes the filter in [08:39] stub: I'm saying the filter may be bong [08:39] I've preserved the behaviour, but its not necessarily defined correctly to start with [08:39] Ok. So different, existing bug :) [08:40] stub: big improvement in that you no longer rely on pre-existing items… is it safe to make BulkFoo a non-temp table? [08:41] jtv: Yes, as the test suite will clean everything up. But I can't see why I can't use a temporary table in any case. [08:41] stub: that's the thing—you're not using a temp table [08:42] temp table would be faster to test with [08:42] Typo? [08:42] I know. By double negative was attempting to say I can change that without ill effects. [08:42] Ah sorry [08:43] Seems cleaner to make it a temp table and have cleanUp drop it. [08:45] If the base class didn't do the query, this would be easy to unit-test without a table; you could just pass a list. [08:46] jtv: I need a table so I can define a Storm class so I can add it as an attribute to the BulkPruner [08:47] Ah, the bulkpruner also does the delete in SQL of course. Stupid of me. [08:47] I'll have a coffee after this. [08:47] Get me one too please. My eyes blur over when I look at lifeless's filter code. [08:48] For that, I recommend beer. [08:48] (Any other religions we can offend with simple beverages?) [08:49] ok. I see why it is done that way and how it works now. [08:49] I don't need props to offend religions [08:49] * stub is naturally offensive [08:49] Plus, you have a T-shirt! [08:54] good morning [08:56] stub: I still think it'd help to break that test down into chunks that prove separate things. "isDone initially returns zero." "A run with a batch size of 2 removes exactly 2 objects." "Iterating until isDone() clears up everything." (I don't see why there are two of those bits in the test.) [08:58] jtv: I don't think the test is particularly large or unwieldy, and I know every test is going to take about 1.5 seconds as the database will need to be reset. But I can change that if you insist. [08:58] lifeless: approved [08:58] stub: thanks [09:00] stub: that long? [09:00] Where does the time go? [09:01] Last I checked. dropdb, createdb --template (in a loop, waiting for dropdb to complete and pg to complete) [09:02] Although if I use a temporary table, I can tell the test suite the db isn't dirty and avoid that [09:02] stub: you can use a temp table with storm [09:02] So yes, we can split the tests without time increases with a little magic. [09:02] Maybe try the timing with the temp table first. :) [09:02] lifeless: Yes, but I'm defining a Storm subclass to access it. [09:03] stub: sure, I don't understand why that implies any trauma [09:03] lifeless: Ideally I could create a Storm class on the fly but I don't know if I can. [09:03] stub: you can - curry it in your test [09:03] AFAIR you can [09:03] [not that you need to, but you definitely can] [09:04] I mean easily. temporary_table = StormTempTable("SELECT * FROM FooBar WHERE wibble IS FALSE") [09:04] I was thinking - definte the temp class once [09:04] do store.execute() once in the test to create the temp table [09:05] lifeless: That is what I'm doing. I just need to add 'TEMPORARY' to my 'CREATE TABLE' statement in the test. [09:05] cool [09:05] doesn't sound magic then :) [09:30] hi [09:34] hi mrevell! [09:44] \o/ profiling on qastaging. -win- [09:44] lifeless: Do they go somewhere useful now? [09:44] lifeless: don't play with our feelings… seriously? [09:44] wgrant: I suspect the rsync isn't in cron or whatever yet [09:45] wgrant: will worry about that when losas are not sprinting [09:45] Do we still need to get the config swizzled in order to use them? [09:45] jtv: no [09:45] jtv: just need to be in team launchpad [09:45] \o/ [09:45] jtv: it will still lock every other concurrent request out [09:45] so not something we're going to do in production then [09:45] (or it should anyhow...) - but thats a profiling limitation [09:45] we could actually, once we're single threaded in production [09:46] eh :) [09:46] thats coming with the new servers [09:46] and haproxy reconfiguration [09:47] jtv: anyhow - https://bugs.qastaging.launchpad.net/++profile++show/ubuntu/+bug/1 [09:47] <_mup_> Bug #1: Microsoft has a majority market share jtv: This really isn't better. I've replaced a simple, linear test with several less simple tests for a net increase in complexity and decrease in readability [09:48] stub: oh well, at least you gave it a try. Thanks for that—I won't hold you up any longer. [09:49] wow, 1/3 of a second in 0.3811 0.0110 +storm.references:133(__get__) [09:50] lifeless: yes, they're expensive even when they come out of the cache. [09:50] jtv: I knew that in principle, but I didn't have data to support it [09:51] this isn't conclusive yet either because it may still be lazy loading on that page [09:51] You could have asked. :) I fixed a timeout recently that was largely based on that. [09:51] jtv: I remember the review, I forget the page id [09:52] So do I, unfortunately—but IIRC it was more or less two consecutive lines in the code, with ridiculous time spent python-side without queries. [09:53] Sometimes I wonder if it'd be worthwhile to have per-request caches in front of the object-info dict in storm. [09:53] lifeless: OK, ++show is extremely awesome. [09:53] What's that do? [09:53] jtv: click on the url I linked before [09:53] wgrant: that was gary's magic [09:54] I'll let everyone know about this and the improving scaling count helper on monday [09:54] Oh wait I've seen this before [09:55] Didn't realize you got the page underneath as well though. Awesome! [09:56] I wonder if I could hack up my browser to add a "profile this request" link to all my LP pages… [09:59] jtv: You were getting 502s from that error, right? [09:59] jtv: Can you push the relevant buttons on https://code.launchpad.net/~stub/launchpad/garbo/+merge/50595 to keep ec2 land happy? [10:00] wgrant: from what error, sorry? [10:00] jtv: The one you're discussing in #launchpad [10:00] stub: I was in the process of doing that, actually. [10:00] wgrant: ah, they were getting those non-oops "can't connect to Launchpad server" errors. [10:00] stub: see? It's people like wgrant keeping me from approving your work. [10:00] jtv: Yeah, the 502s. They're fixed now. [10:01] Great! [10:01] But they do indicate an IntegrityError. [10:01] Which is exactly what I currently have a fix in EC2 for. And thanks for fixing "ec2 land" btw. :) [10:01] It finally landed. [10:01] After Windmill kicked it out twice. [10:01] Grr [10:02] and a new spurious failure (now fixed) kicked it out a third time. [10:22] r12426 started creating the no-op filters. [10:24] r12435 is the only rev since that affects bug notifications. [10:26] night all === danilo-afk is now known as danilo === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring | https://code.launchpad.net/launchpad-project/+activereviews === al-maisan is now known as almaisan-away [11:01] adeuring: Hi. [11:01] hi wgrant [11:01] adeuring: https://code.launchpad.net/~wgrant/launchpad/remove-canonical.widgets/+merge/51277 should be a nice quick one. [11:01] If you could. [11:01] wgrant: I'll look [11:13] wgrant: r=me. [11:14] adeuring, jml: Thanks. [11:58] jelmer: thanks for the email. [11:59] jml: np. Let's get this show on the road :) [12:03] Project devel build (476): STILL FAILING in 5 hr 44 min: https://hudson.wedontsleep.org/job/devel/476/ [12:07] Morning, all. [12:08] * jml is off for a bit, last driving lesson in a while, I hope. [12:21] good luck jml, good morning deryck [12:21] Ahhhh an empty translations import queue for once. Lovely. [12:32] stub, hi, just one q re your review of https://code.launchpad.net/~danilo/launchpad/bug-720826-db/+merge/51146 [12:33] stub, we are mostly going to do joins through bugnotification, is _pkey as you suggest going to be enough for that? [12:33] danilo: yes [12:34] stub, (fwiw, we might not even need the index on bug_subscription_filter, so how bad for the DB is it to add it "just in case"?) [12:35] stub, ah, interesting, so the BTREE index on a tuple will be a BTREE on the first element of the tuple "first"? [12:35] there is a good chance we won't need it, as the primary key index should be usable going in that direction too. [12:35] but it will be faster, and just in case. [12:36] danilo: I don't know the details of the structure. [12:36] stub, well, what I am saying that we are not going to be joining through this table from the direction of a bugsubscriptionfilter (iow, we won't be taking a set of bugsubscriptionfilters and look for all bugnotifications that it caused; at least not for now) [12:37] So that is two reasons we might not need it :) I just put it there because your patch had it too. [12:38] stub, right, I just put it in for "just in case" (i.e. we might want to do that when we start trying to estimate how much mails is each filter generating) [12:39] stub, but I wonder if it is a drag on the DB and we shouldn't create such indexes "just in case" (iow, I am asking how bad is it to have an index that's not used?) [12:40] It slows down inserts and chews some disk space, apart from that not much. [12:40] stub, right, thanks [12:40] stub, I think I'll leave this one in [12:40] If the filters can be removed, we want the index. [12:40] Project db-devel build (395): STILL FAILING in 5 hr 50 min: https://hudson.wedontsleep.org/job/db-devel/395/ [12:46] stub, right, good point [12:47] * jtv wants hypothetical indexes [12:58] jtv, I want a hypothetical database ("if you need it, it'll be there" :) [12:58] Go buy hardware [12:59] jtv, hypothetical hardware? [12:59] hypotheticall, yes [13:01] jtv, there's not enough "all" for what we might need :) [13:16] Project devel build (477): ABORTED in 1 hr 12 min: https://hudson.wedontsleep.org/job/devel/477/ [13:16] * Launchpad Patch Queue Manager: [r=thumper][bug=721134] Fix the heading alignment for the multi-line [13:16] editors on the recipe index page. === bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring, bac | https://code.launchpad.net/launchpad-project/+activereviews [13:17] hi adeuring [13:18] morning bac === almaisan-away is now known as al-maisan [14:15] adeuring or bac, no rush, but I have a branch up for review if one of you can take it please [14:15] bigjools: I'll look [14:16] thank you [14:37] So begins another day where the first 1.5 hours is spent working natty bugs [14:40] natty is not yet released, right? :) [14:45] I do not think people will be happy if it were released today [14:47] sinzui: you free to mumble about the messages stuff in about half an hour? [14:48] sure [14:48] if mumble/pulse works [14:48] I had to fix the mic again this morning [14:48] bigjools: PoppyAnonymousShell.openForWriting() has a "catch-all" except. I think we do not want to catch KeyboardInterrupt and SystemExit. And I think we should log an error for other exceptions. [14:49] otherwise, the branch looks good, I think [14:50] adeuring: that was cargo-culted from the parent class... I wasn't sure what to do about it TBH [14:51] sinzui: dig. i think all meeting plans these days involve a "natty-errors" fudge factor. :-P [14:51] bigjools: admittedly, I am not familiar with twisted, so I am not sure about KBInterrupt and SystemExit. But nevertheless I think we should log other exceptions. [14:53] "eating" exceptions simply scares me ;) [14:53] adeuring: yeah [14:54] adeuring: so I'll re-raise KeyboardInterrupt and SystemExit [14:54] adeuring: oh wait [14:55] adeuring: yes twisted has confused us both momentarily - the defer.fail() is effectively the same as re-raising the exception, it gets dealt with later [14:56] bigjools: intersting. So, IOError and OSError are re-raised too? [14:56] ah, no, there no fail() call [14:56] adeuring: no, they are converted to ftp errors [14:57] ftp.errnoToFailure will return a defer.fail [14:57] bigjools: right, thanks for the explanation, so r=me. But perhaps a small comment that twisted properly deals with the exceptions? (just to avoid the same question I asked again)? [14:57] adeuring: yup, will do, thanks for the review [14:58] I am blocked on landing this right now anyway [14:59] talking of which, does it matter if we lay our own eggs in lieu of a proper Twisted release? === henninge_ is now known as henninge [15:08] gary_poster: hi [15:18] jml, hi on call but maybe will postpone call if your conversation will change the tenor of the call :-) what is your topic? [15:19] gary_poster: general mgmt stuff. It can wait. [15:19] ok cool will ping jml thanks [15:19] gary_poster: np [15:19] * jml fetches tea & chocolate. [15:34] jml, ping? [15:34] gary_poster: hi. [15:34] gary_poster: skype? (mumble's broken for me atm) [15:34] hey. Skype or mumble? [15:34] ok [15:36] jkakar: I'd like to be notified via a Zope event whenever objects of a particular type are removed from the store. It looks like Storm does emit an event then, but I can't find any documentation of how that works. [15:36] jkakar: Do you have any pointers? [15:37] Hmm, let me look at some code, one sec. [15:43] abentley: Okay, so the only thing I can recommend is not really part of the public Storm library. [15:43] abentley: I wouldn't rely on it not changing under you. [15:44] abentley: Anyway, Storm has an internal event system which it uses to keep track of things. You can hook into it, but as I said, it's not recommended. [15:45] jkakar: understood. I already have a 95% solution, by overriding Foo.destroySelf. Maybe that's enough. [15:45] abentley: That's what I was going to recommend... providing a wrapper/hook on the public API. [15:47] jkakar: Yeah, it just wouldn't surprise me if someone did Store.remove instead of destroySelf at some point. [15:47] jkakar: It's more Storm-y. [15:47] sinzui: mumble? [15:49] abentley: Right. [15:49] jkakar: Perhaps you could put a docstring in storm.event that says it's for internal use only? [15:50] abentley: That's a good idea. We desperately need to improve our documentation system... no one has taken up the charge to do it, though... I've made some small starts, but haven't managed to push through. === deryck is now known as deryck[lunch] === beuno is now known as beuno-lunch [16:34] anyone done a rockefuel-get lately and then not been able to make? SyntaxError: invalid syntax (shipit.py, line 51) [16:39] hmm, conflict markers in the file, trying to see if it's just a local problem or not [16:40] adeuring, bac: It would be great if either of you could look at my branch! It's UI work. [16:40] https://code.launchpad.net/~henninge/launchpad/devel-705176-sharing-info-on-page/+merge/51283 [16:41] sinzui: Can you do a UI review on that, please? ^ [16:41] okay [16:41] henninge: I'll look [16:42] adeuring, sinzui: thanks. I gotta run out now for 30 min but will be back to answer any questions ... ;-) === al-maisan is now known as almaisan-away === beuno-lunch is now known as beuno === deryck[lunch] is now known as deryck === Ursinha is now known as Ursinha-lunch [17:21] * henninge is back [17:37] adeuring: are you still reviewing? [17:37] henninge: nearly done, give me five more minutes [17:37] * henninge sets count down on watch ;) [17:37] adeuring: cool, thanks ;) [17:40] henninge: r=me with a few nitpicks [17:40] allenap, hey, sorry for missing out on that bit of extra review you asked for, had a nice, wild day — +1 for ignoring my lazy ass :) [17:41] danilo: :) [17:43] adeuring: Danke! Schönes Wochenende! [17:43] allenap, fwiw, if you run into problems, you can always change the user to be defined as group=launchpad when it inherits all the permissions of the "launchpad" user (though, you might know that already, but I am just saying :) [17:44] henninge: Dir auch auch ein schönes Wochenede! === Ursinha-lunch is now known as Ursinha [18:19] moin [18:21] looks like I win. I get to try a bug import [18:24] Project db-devel build #396: STILL FAILING in 5 hr 7 min: https://hudson.wedontsleep.org/job/db-devel/396/ [18:55] * jml has to go === bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: bac | https://code.launchpad.net/launchpad-project/+activereviews === Ursinha is now known as Ursinha-afk [19:37] are we still having ec2 problems? i just got back three ec2 runs which seem to have taken the full time, but show 0 tests run, 0 errors, 0 failures. log looks like everything actually ran. [19:37] * jcsackett is confused. [19:41] jcsackett: hi [19:41] jcsackett: windmill [19:42] lifeless: oh goodie. [19:42] (ah, the problems with splitpanes) [19:43] I prefer F16's myself [19:43] * jcsackett laughs. [19:43] so, we're having windmill issues in the tree, still, or i have somehow blown up windmill in my branch? [19:43] bit from column A [19:43] bit from column B [19:44] righto. [19:44] shiny: http://caniuse.com/ [19:52] sinzui: ping [19:52] hi lifeless [19:52] hi [19:52] I'd like to mark bug 719182 wontfix [19:52] <_mup_> Bug #719182: boolean interpretation for feature flags < https://launchpad.net/bugs/719182 > [19:52] but I just noticed you're working on it [19:52] and I don't want to be a nuisance [19:53] the problem statement at the top is false: we don't have varying interpretations for booleans; that all got cleaned up by wgrants work [19:53] Project devel build #478: STILL FAILING in 5 hr 52 min: https://hudson.wedontsleep.org/job/devel/478/ [19:54] fab [19:54] thats ok with you ? [19:54] Indeed it is. [19:54] cool. I'll twiddle the knobs. [19:55] lifeless do you happen to know if there is a way to use the WITH statement in Storm? Mucking about with SQL, I can get the 1200-1500ms query from bug 723999 down to 180ms simply, and if I can use the WITH statement somehow I can get it down to 50ms. [19:55] <_mup_> Bug #723999: BugNomination:+edit-form structural subscriptions taking 4.8 seconds during nomination editing POST < https://launchpad.net/bugs/723999 > [19:56] gary_poster: thats a decent improvement :) [19:56] :-) [19:57] gary_poster: The short answer is 'probably not' [19:57] :-( [19:57] oh well [19:57] 180 is the big improvement, so I'll run with that [19:57] thanks [19:57] storms compiler will put the SELECT at the start [19:58] :-/ [19:58] so we'd need to hack into that to actually support with (or similar) directly. [19:58] you could use a temp table explicitly [19:58] how would I do that? [19:58] (pointing to an example or telling me what to grep for would be great) [19:59] have you seen gavins hack to do distinct on ? [19:59] I don't think so [19:59] SQL("distinct on foo 0 as ignore") [19:59] it didn't stivk with me if so [19:59] and use that as the first thing in the select clause [19:59] store.find((SQL("distinct on foo 0 as ignore"), Foo, Bar), ...) [19:59] for _, foo, bar in result: [20:00] not entirely sure I follow but will grep to see if that helps [20:00] you can probably inject a INTO TEMPORARY TABLE (I forget the syntax offhand ...) in the same way [20:00] however [20:00] ah ok [20:00] * gary_poster waits for however ;-) [20:00] then you've make the temp table, and use it in followups [20:01] oh the however: 180*4=720ms, which is tolerable for a month or two [20:01] sure [20:01] since I'm focusing on it I want to see if I can get it down [20:01] 'cause 200ms is even better ;-) [20:02] I am a little scared by the size of query, and if you have any concerns about the modelling that you inherited with this project, I stand ready to consult [20:02] yeah, 200ms is even better [20:02] if the same basic temp table is used by all 4 queries [20:02] the query is down to, say, 25 lines lifeless. no worries there [20:02] then a temp table can be an even bigger win than with - make it once, use it 4 times [20:02] (25 nicely formatted lines) [20:03] gary_poster: \o/ that will be a significant benefit all of its own. [20:03] yeah [20:03] ok, I'll read up on temporary tables; I didn't realize you could use them within a transaction [20:04] oh yeah, they are awesome [20:04] variables FTW [20:04] :-) [20:04] deryck: could you have a look at https://code.launchpad.net/~abentley/launchpad/refactor-merge-job/+merge/51359 ? I may have used too much magic. [20:04] ok thank you very much lifeless. I'll dig, and come back up for air with you if I encounter confusion. [20:05] cool [20:05] abentley, sure. I'll take a look. [20:05] deryck: thanks. [20:17] bac: Could you please review https://code.launchpad.net/~abentley/launchpad/refactor-merge-job/+merge/51359 ? [20:22] jcsackett: you wanted to talk about spam [20:23] yes, but i think it's no longer necessary. [20:23] ? [20:23] you were concerned about performance implications for pushing the visible attr down into imessage and having multiple message systems use it, yeah? [20:23] yes [20:24] message is fat, link tables are pretty darn narrow [20:24] we probably need an overhaul on message [20:24] e.g. drop the fti index [20:24] right. i'm thinking as far as not having to rewrite code too much, going for an IHideable or similar, and having shared rules there. it means some reimplemenation, but at least reliably linked. [20:25] abentley: yes [20:25] rather than questions being entirely different from bugs, and so forth. [20:25] jcsackett: bugmessage is 188MB, message is 2.4GB [20:26] bac: thanks! [20:26] jcsackett: postgresql has to read every row that indexes say *might* be a match, because the liveness of the row is only in the row [20:30] lifeless: right. [20:31] jcsackett: this doesn't mean we /can't/ put it on message, but it does mean we need to try the migration, measure the impact [20:31] jcsackett: it -might- be faster than it is now. It might be slower. [20:31] lifeless: yeah, i'm going to give it a try. [20:31] jcsackett: what I know *for sure* is that we have issues in this area, and we doing things that are hard to undo (e.g. schema schanges) should be done with care. [20:32] jcsackett: as a test case, i give you http://bugs.launchpad.net/bugs/1 [20:32] oops [20:32] <_mup_> Bug #1: Microsoft has a majority market share jcsackett: https://bugs.launchpad.net/ubuntu/+bug/1?comments=all [20:32] <_mup_> Bug #1: Microsoft has a majority market share jcsackett: that url is (now) (largely) driven by messaging system performance [20:33] i'm still impressed the non-all comments version renders, btw. :-P [20:33] jcsackett: actually, thats a little unfair of me : we're looking at pagination - but still - the count(*) in a batchnavigator isn't free [20:33] no indeed. [20:34] i'll probably getting into that stuff more on monday. today has been hunting down permissions stuff, since the visible attribute being used for culling spam on bug comments is admin only, and we would like registry to be able to deal with it. [20:34] jcsackett: its not reliable yet, I need to keep pushing it [20:38] abentley: why do you use a staticmethod for _register_subclass instead of a classmethod? [20:39] bac: it had to be invoked in TranslationPackagingJob, and that didn't work with a classmethod. [20:40] bac: There's no syntax for "invoke this class's classmethod, but with this other class as the first parameter." [20:40] * bac looks [20:41] that would be a definitional problem - unless the otherclass is a subclass [20:57] lifeless: otherclass is indeed a subclass. [20:58] abentley: does it define its own version of that method ? [20:58] lifeless: yes. [20:58] ah [20:58] that will indeed be tricky [21:02] bac: The follow-on is here: https://code.launchpad.net/~abentley/launchpad/translation-splitting-job/+merge/51371 [21:02] bac: You can see that these refactorings make the actual definition of TranslationSplitJob very small. [21:08] bac: just noticed schedule_merge needed to be deleted. Pushed now. [21:27] bac: thanks for your review. Updates pushed. [22:27] also, I hate sample data [22:27] lib/lp/soyuz/doc/closing-bugs-from-changelogs.txt is going boom because of the dsp.currentrelease change to not pick a crazy random package. [22:28] lifeless: sample data is the devil. kill the doctest--you have solid unittests. [22:29] jcsackett: we do? kill the whole thing? [22:29] * jcsackett considers. [22:29] i *thought* we did. [22:29] perhaps do a check, and then kill it. [22:29] where would I find the unit tests? [22:31] crap, i don't actually see a test that exactly handles that. [22:31] sorry for the false hope. [22:32] fair bit of that does look to me like it would be better covered by unit tests, but i imagine you don't really want to write a ton more tests if you can just update the doc. [22:33] sinzui: are we doing standup this evening? [22:35] jcsackett: yes. [22:49] wgrant: while you're around, whats the easiest way in a doctest of doing an upload to the currentseries of ubuntu - see the error i've just forwarded you [22:50] lifeless: Use the factory. [22:50] Or maybe SoyuzTestPublisher. [22:50] Depending on what exactly you want. [22:50] wgrant: well, thats why I'm asking :) [22:50] I had tw oissues in my branch to nuke Distro.getCurrentSourceReleases() [22:50] Aha. [22:50] I see now. [22:50] one was a type items() rather than values() [22:50] thats fixed [22:51] the closing bugs upload one however is epic fail sample data [22:51] this isn't a critical bug, I want to sweep it under the carpet for later polish [22:52] so I was figuring that if I do a new upload of cdrkit to hoary [22:52] it will work [22:53] lifeless: Try just using factory.makeSourcePackageRelease [22:53] It may need more than that. [22:53] But we'll see. [22:53] is there a global factory in doctests? [22:53] * lifeless doesn't do doc tests :) === bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews [23:00] lifeless: I think 'factory' may be a factory. [23:00] But not entirely sure. [23:00] I don't write new ones. === Ursinha-afk is now known as Ursinha