[00:02] wallyworld: do you want to try mumble? [00:04] sinzui: now i have no mic. i got my sound working eventually (seems a recent kernel update killed it for others too). i ended up having to upgrade to natty. but now it won't recognise my mic anymore :-( [00:04] so i'm doing the phonon/pulse dance :-( [00:05] wallyworld: is your mumble working [00:05] thumper: ^^^^^^ [00:05] i silent wallyworld is a good wallyworld [00:05] :) [00:12] sinzui: sorry, no work :-( [00:14] * wgrant deletes shipit. [00:14] Yay, this even lets us delete a celebrity. [00:27] wgrant: As soon as I saw the announcement I knew you'd be happy :) [00:29] how is it coffee time again already [00:34] thumper: at least you have a working coffee machine :-( [00:34] hahah [00:39] Project windmill build #144: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill/144/ [00:59] gmb: did you find an OOPS for that bug 1 timeout ? [00:59] <_mup_> Bug #1: Microsoft has a majority market share

gmb: I'd be happy to eyeball it and see if I can suggest a cause [01:05] thumper: stacked branches [01:05] thumper: I see the code is going well [01:05] lifeless: yup [01:06] thumper: did I correctly read that private http branch access isn't supported? [01:06] lifeless: landing the branch id support now [01:06] yes [01:06] that is right [01:06] we don't support any private branches over http [01:06] oh [01:06] thats easy then [01:06] I thought they worked in loggerhead [01:06] that's different [01:06] well [01:06] loggerhead backs onto http [01:06] it raises permission denied [01:06] inside the dc [01:06] and loggerhead goes to https [01:07] It uses internal by-ID HTTP, right? [01:07] lifeless: different rule [01:07] Like, raw by-ID, not +branch-id [01:07] right [01:07] wgrant: its mapped to that [01:07] wgrant: I'm not sure how it handles stacked-on urls [01:07] which is why I'm asking these questions [01:08] um... [01:08] it should be the same way [01:08] ... [01:08] * thumper thinks [01:08] I'll take a look [01:08] It must translatePath, right? [01:08] thumper: until we change the virtual policy file [01:08] thumper: this isn't going to magically affect people [01:08] lifeless: yes, I'm not landing that pipe yet [01:08] thumper: so I'd check it on qastaging or whatever [01:08] yep [01:09] just worth noting 'private stacked branches should work in loggerhead still' :) [01:09] yes they should [01:09] \o/ [01:09] landing incremental support is good though [01:09] totally [01:09] we can slam it on things like this [01:14] thumper: i got my sound working again. if you are free at some stage, i'd like to mumble to discuss some code [01:14] wallyworld_: sure [01:14] now is fine [01:14] ok === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | https://code.launchpad.net/launchpad-project/+activereviews [01:26] aaaaaaaaaaaaaaaaaaaaaaaargh [01:27] I just read ' def getBatches(self):' in lazr.batchnavigator [01:35] thumper/lifeless: loggerhead still uses that nasty transform_fallback_location hook i added to bzrlib i think [01:43] heh [01:43] mwhudson: ping [01:43] thumper: hello [01:44] mwhudson: I was going to ask you about how loggerhead talked [01:48] thumper: ah, i think i may have been lying above [01:49] * mwhudson tries to remember if he wrote this code [01:51] aaah right [01:52] thumper: basically, it uses translatePath under the hood, it actually accesses branches in a pretty similar way to how codehosting does now [01:52] right [01:52] it seems likely then that my change to the vfs to support +branch-id alias will work fine there too === Ursinha-bbl is now known as Ursinha-afk [01:53] I wonder if we should look at openid support for bzr [01:53] / oauth [01:53] thumper: yes [01:53] \o/ [01:53] rather than ssh keys? [01:54] http://productblog.37signals.com/products/2011/01/well-be-retiring-our-support-of-openid-on-may-1.html [01:54] thumper: it seems like loggerhead should survive almost any rearrangement of how virtual paths map to real ones, basically [01:54] (this is not true of the external http service) [01:54] I've tweaked the rewrite map code to work with the new alias [01:54] ah ok [01:55] seriously, lplib started silently sending me to staging in natty? :( [01:55] poolie: i realized the other week that what i wanted for openid to be useful was my browser to know to send me to my chosen OP whenever openid was offered as an option [01:55] poolie: for https access to private branches [01:56] mwhudson, if it had been decently integrated into browsers it would have had a better chance [01:56] probably chicken/egg [01:56] poolie: yeah, I saw that blog post [01:56] poolie: did anyone actually try that? it sort of seems that the standard was at the wrong level for it to be feasible [01:56] mwhudson: entirely wrong level [01:57] mwhudson: I don't recall /any/ chatter on http-wg about it [01:57] well, exactly [01:58] poolie: lplib has always defaulted to staging, AFAIK... [01:58] it works nicely enough, although with a bunch of unnecessary hair i guess, for canonical/ubuntu SSO [01:58] even if you specify a different root [01:59] i understand what it is; i'm filing a bug [01:59] adding new parameters to python methods other than at the end is not a good idea for api compatibility [01:59] What's changed now? [01:59] get_token_and_login? [02:00] Distribution:+bugtarget-portlet-tags-content needs attention [02:00] Yeah. It almost looks cold-cachey, but it's hard to say. [02:01] wgrant: it probably just needs the countBugs aggregate function applied to it [02:01] wgrant: I bet most of the queries are table scans [02:01] lifeless: IIRC it's a single 10s query in a lot of cases. [02:01] I looked at it a while ago. [02:02] lets have a looksee [02:02] wgrant, https://bugs.launchpad.net/launchpadlib/+bug/752095 [02:02] <_mup_> Bug #752095: Launchpad constructor parameters changed incompatibly in natty < https://launchpad.net/bugs/752095 > [02:02] Grar. [02:03] "Organize your workflow with Launchpad. [02:03] " [02:03] From 37signals.com/accounts [02:03] 1 5211.0 2 [02:03] Do people not Google these things :( [02:03] wgrant: 2 x 5000ms queries [02:03] poolie: Hm, is the constructor really a public API? [02:03] poolie: I've never seen it recommended, I don't think. [02:04] wgrant: also nonddy queries [02:04] wgrant: totally identical [02:04] https://help.launchpad.net/API/launchpadlib recommends it [02:04] and, its name suggests it's public [02:04] wgrant: and looking at every tag when in fact I think the portlet only shows official tags [02:04] for fks sake [02:05] how gratuituous, after all the pissing and moaning about compatibilyt [02:05] wgrant: so, kill the duplicate call, constrain by the official tags, win. [02:08] poolie: Bah :/ [02:11] i know api stability is hard in python [02:11] this one is just a bit annoying because it doesn't just give a typeerror, it happily does nearly the right thing [02:15] wgrant: ok, I've analyzed it up [02:15] wgrant: we can make it a 300ms portlet [02:15] https://bugs.launchpad.net/launchpad/+bug/736002 [02:15] <_mup_> Bug #736002: Distribution:+bugtarget-portlet-tags-content timeouts < https://launchpad.net/bugs/736002 > [02:29] Yippie, build fixed! [02:29] Project windmill build #145: FIXED in 1 hr 2 min: https://lpci.wedontsleep.org/job/windmill/145/ === _thumper_ is now known as thumper [02:33] Hmmm. [02:34] lifeless: I'm trying to QA the bugattachment LFC preloading thing. [02:34] wgrant: e-pic fail ? [02:34] The bug in question times out on qas, even without ?comments=all [02:34] Looking at an OOPS, the query take 20ms. [02:34] hit up ++profile++show [02:34] But there is a 4s gap afterwards. [02:34] wgrant: does it timeout on prod without ?comments=all [02:35] lifeless: No, it only takes 5s. [02:35] Erm. [02:35] Got a 502 from qas when asking for a profile. [02:36] Odd. [02:37] wgrant: you've marked it ok, was that optimistic ? [02:38] Erm, that must have been the wrong bug. [02:39] lifeless: http://paste.ubuntu.com/590009/ only returns a few hundred rows on qas? [02:43] wgrant: 750949 [02:43] Er.... [02:43] [Bug 750949] [NEW] BugTask:+index times out with lots of attachments .. ** Tags added: qa-ok [02:43] <_mup_> Bug #750949: BugTask:+index times out with lots of attachments < https://launchpad.net/bugs/750949 > [02:43] Oh, right, bug number, not row count. [02:43] ** Tags removed: qa-needstesting [02:44] Fixed. [02:44] 342 rows [02:44] Right. [02:44] So 4s after that is completely insane. [02:44] Also, qas seems to be dead now. [02:44] Maybe it's updating slowly. [02:45] 40ms [02:45] Right. [02:45] That's slightly longer than the OOPses show, but still not too terrible. [02:51] Ah, now it's sometimes timing out before it even gets to attachments. [02:51] So I think it might just be generally unwell. [02:52] Random multi-second sleeps in there too. [02:52] So I'm going to re-OK this and blame it on asuka being shit. [02:54] check the asuka load graph [02:54] huwshimi: btw [02:54] huwshimi: ajax log on qastaging is bokred [02:54] lifeless: Oh [02:55] lifeless: Ugh, any idea what's got it so high? [02:55] Spiked massively an hour ago. [02:55] askalosa [02:56] Huh. [02:56] Interesting. [02:56] spm: Hi. [02:57] damn. why does my /ignore not work anymore. :-( [02:57] spm: :( [02:57] spm: Something made asuka reasonably angry load- and RAM-wise right around midnight UTC. [02:57] any idea what that is? [02:57] (it is somewhat recovering now, but still not ideal) [02:58] lifeless: Where abouts is it not working? [02:58] In fact it appears to now have flattened out at a heightened level. [02:59] Whereas it normally drops back down to normally quickly after this sort of spike. [02:59] wgrant: hrm. not offhand. tho the load in general for asuka is pretty spiky. I'd suggest a combo of a rollout of something and/or cronjobs firing off [02:59] spm: Spiky and *11*. [02:59] I tried to use capital digits there. [03:00] Sadly they don't exist. [03:00] wgrant: heh, I see about 15 of those over the past week. :-/ [03:00] Indeed, but they're fairly irregular. [03:01] ish [03:01] I guess I'll see if it's less unhappy in a few hours. [03:01] we should probably fork qas onto a separate box [03:01] Or just toss the scripts elsewhere and see what happens. [03:01] I hear we have at least two free appserver boxes now ;) [03:02] Haha [03:03] Maybe we can convince gandwana and potassium to serve their sentences on qas, too. [03:03] Since I doubt anybody else wants them :) [03:04] heh, I am not typically privy to the next hop destinations of servers. :-) [03:05] spm: there is a ticket to move the scripts off [03:05] /forcenickchange lifeless ticketmaster [03:05] huwshimi: huh, iz working now [03:05] it wasn't working before [03:05] lifeless: It just updated. [03:05] lifeless: May have been icing skew? [03:06] perhaps [03:06] spm: I prefer KeyMaster, thanksverymuch [03:06] sigh. delusions of grandeur. [03:11] wgrant: and w/out ? [03:11] 4s [03:12] Slightly faster than prod. [03:12] +1 [03:12] But not much. [03:13] nie work [03:22] hee hee, http://bazaar.launchpad.net/+branch/linaro-android-build-tools/files/head:/ works [03:27] mwhudson: of course [03:28] mwhudson: or is that unexpected somehow ? [03:28] It's pretty new. [03:28] And probably an unintended side-effect. [03:29] lifeless: it's new-ish at least [03:39] bah! [03:41] I'm trying to make a unit test that does the equivalent of: http://pastebin.ubuntu.com/590022/ [03:41] anyone got any ideas? [03:42] You should be able to add a header to a testbrowser... [03:42] hmm... [03:42] Using the remarkable browser.addHeader method. [03:42] right now it oopses [03:42] which is what i'm wanting to fix [03:42] * lifeless hates on doctests [03:43] lifeless: Then remove them? [03:43] StevenK: its the README [03:43] Bwaha [03:44] anyone see a reason for start=0 to be present on the first batch url ? [03:45] No. [03:48] may be some test fallout... shurg [03:48] I've already caused that [03:48] Test fallout is dealable with. [03:50] * lifeless loves matchers [03:50] * wgrant unbreaks publish-distro.d [03:55] StevenK: You has QA. [04:00] Hmm. [04:00] We need a publisher on qastaging. [04:03] wgrant: The QA tagger should move to someone else [04:04] StevenK: Oh? [04:04] Indeed, it's moved to r12746. [04:04] Yeah. [04:04] Waiting for my fixed publish-ftpmaster.py to run before I try PPA publishing. [04:05] On DF? [04:05] Yeah. [04:05] I've turned on the run-parts things and made them work. [04:05] That could take eons [04:05] So we might get a full run. [04:05] No! [04:05] jtv deleted PublishingTunableLoop, so it should only take about 10 minutes to generate file lists now. [04:05] Indeed, now into a-f itself. [04:05] I wonder how much that will speed up the publisher on cocobanana [04:06] wgrant: Do you need to land a branch of fixes for the run-parts fixes? [04:06] Yes :( [04:06] StevenK: Not by more than a minute or so, I don't think. [04:06] But let me check. [04:08] Seconds at most. [04:08] Since wildcherry can keep the necessary indices in RAM. [04:08] So the massive speed up is for DF's benefit only [04:08] Right. [04:09] I guess it'll be around a 15-20s improvement for natty on prod. [04:09] ie. nothing at all. [04:11] done [04:11] gpg: signing failed: secret key not available [04:11] :( [04:11] lifeless: What's done? Batchnav? [04:11] yeppers [04:12] phase 1 [04:12] Nice work! [04:12] Does it work>? [04:12] who knows [04:16] Argh. [04:16] ? [04:16] bzr+ssh://bazaar.launchpad.net/~lifeless/lazr.batchnavigator/keyoffset/ if you want to peek, mp coming up now [04:17] publish-ftpmaster.py's signing hook doesn't work. [04:17] Since the GPGHandler utility overrides GNUPGHOME to a temp dir. [04:18] does this break the deply? [04:18] No. [04:18] this is the rev we didn't merge. [04:18] And we weren't even planning to move to this new script immediately either. [04:20] I can has review? [04:20] https://code.launchpad.net/~lifeless/lazr.batchnavigator/keyoffset/+merge/56499 [04:21] StevenK: ^ [04:21] 1400 lines. [04:21] That's almost into Soyuz territory. [04:21] StevenK: if you whine that its too large, I'll whine that its using copied code from zope [04:22] wgrant: I can halve it by deleting comments and tests. [04:22] wgrant: Lines of code is a terrible complexity metric [04:23] wgrant: particular because of context [04:23] 12 files changed, 659 insertions(+), 209 deletions(-) [04:23] is a better-but-still-not-great indicator [04:24] lifeless: I think you linked the wrong bug [04:24] StevenK: thats merge proposals being noddy [04:25] StevenK: bug 726195 [04:25] <_mup_> Bug #726195: merge proposals show closed bugs < https://launchpad.net/bugs/726195 > [04:25] which is nontrivial [04:25] because we should capture the bugs against the MP [04:26] so the branch can get more links and not alter the MP [04:26] this would also make some queries faster [04:26] lifeless: I'm not sure about your choice of 'memo' as a variable name -- especially since it's shown in URLs [04:27] StevenK: cosmetic and easy to change if you have a better label [04:27] StevenK: its going to be base64 junk [04:27] StevenK: not hand guessable or enterable [04:27] Well, I'm not sure what you're trying to show with it [04:28] StevenK: its the db constraints needed to get back to a particular batch, serialised. [04:28] e.g. for a bug search it might be ABBD23427834EfJ [04:28] meaning 'bug heat < 43 and bugtask.id > 34' [04:29] http://en.wikipedia.org/wiki/Memoization [04:30] Right [04:31] lifeless: I'm ... I don't know, half-way? Breaking for lunch, so my stomach doesn't break out and insist. [04:31] StevenK: thats cool [04:31] StevenK: I'm going to start on a 'lets see if this breaks lp' branch of lp [04:32] Aha! It no longer crashes! [04:32] We may have victory. [04:32] * wgrant carefully publishes a few suites. [04:39] lifeless: https://code.launchpad.net/~wgrant/launchpad/bug-752149/+merge/56500 [04:40] Oh, actually, even simpler. [04:41] wgrant: tell me when [04:45] I kindof wish we'd done an april fools thing [04:45] like skinning lp like sourceforge and announcing a merge [04:45] Heh. [04:46] Even Debian did one this time. [04:46] I know [04:46] lifeless: Diff updated. [04:51] sadness, make schema day [04:52] we should make that incremental [04:52] lifeless: You mean like, say, running upgrade.py? [04:52] mmm, or make it obvious how to do it incrementally if one knows how [04:52] wgrant: well its not always safe [04:52] wgrant: but yes, upgrade.py on launchpad_ftest_template etc [04:52] Also, make schema isn't *that* slow any more. [04:52] tell that to my wadl compiler [04:53] I'm just wearing my curmudgeon hat today [04:58] lifeless: Thanks. [04:59] * wgrant glares at mawson. [05:03] spiv: Hi. [05:10] ok, launchpad bugs needs to die [05:10] can we just delete that catchall ? [05:10] let folk use the shocking mute functionality ? [05:10] We should probably blackhole it for now. [05:11] I was hoping the bug subscription feature work would think about how to fix not just bug notifications, but apparently not :/ [05:13] lifeless, i'm aware there's a "bugs i reported" function [05:13] nm, i'll comment on the bug [05:13] wgrant: well, by removing the thing, I think we can subscribe things more directly and appropriately [05:15] lifeless: I guess we'll also find out what's going there pretty quickly. [05:15] And work out how to fix it. [05:17] lifeless, hi, did you see any other occurrences of bug 727552? [05:17] <_mup_> Bug #727552: when first rev is bad, with a later rollback, qatagger incorrectly reports it deployable atthe top < https://launchpad.net/bugs/727552 > [05:17] I can't reproduce that [05:22] wgrant: hi? [05:23] spiv: Your Codehosting Twisted evil needs QA. [05:25] Eyes bleeding ... [05:25] wgrant: ok. What would that look like? Would verifying that 'bzr push' of a new branch still works, (to staging/qastaging) suffice? [05:26] so [05:26] sob [05:26] GoogleBatchNavigator - facepalm [05:26] lifeless: Burn it with Holy Fire? [05:26] spiv: Well, how did you notice the slowness in the first place? [05:26] Ursinha-afk: well I saw it right before I reported the bug, unless its been specifically fixed i suspect its still the case [05:27] StevenK: jam noticed it locally in a vm [05:27] spiv: pushing to qastaging is good - be sure to trigger some failures [05:29] StevenK: jam noticed it. [05:31] StevenK: can't burn it trivially, it wants a refactor of the base class, for now I'll just copy and paste and cry [05:31] StevenK: I saw the profiling data he generated, applied my knowledge of which bits of Twisted are particularly crummy, jam did a crude hack confirming our hypothesis, I wrote a proper workaround (and proper fix for upstream, plus micro-benchmark for upstream). [05:32] lifeless: practically everything we do triggers failures [05:32] lifeless: that's the issue! ;) [05:32] lifeless: jam noticed this issue from a simple initialize BzrDir RPC. [05:32] spiv: I know, familiar with it [05:32] spiv: I mean trigger something we expect to return an error to you, the user. [05:32] Ok. [05:33] spiv: because if its going to break, I'd expect that to be where it does. [05:33] e.g. unknown project [05:33] So, 1) push up a new branch to somewhere that works, ~user/proj/branch, and 2) try a push that should fail, e.g. to ~user/no-such-project/foo ? [05:33] or a project you don't have permissions to push into [05:33] yes, exactly [05:34] Ok. When will the code be on qastaging? [05:34] It is now. [05:34] Great! I'll do that QA now. [05:35] spiv: when the qatagger comments on abug saying 'x landed', its reached a staging server. [05:35] spiv: the specific one depending on the branch it landed on [05:35] Sounds handy, although I'm sure to have forgotten that by the next time I have another LP change to land and QA. [05:35]