[00:09] sinzui: you will laugh and cry at bug 618356 [00:09] <_mup_> Bug #618356: Person-picker takes a very long time consistently

< https://launchpad.net/bugs/618356 > [00:09] sinzui: full text queries without a full text index are slow. [00:11] lifeless: we are discussing this right now actually. Why do we do a fti searching for a person? I think we care about displayname, not homepage_content [00:11] sinzui: the simplest thing would be to drop the fti lookup [00:11] sinzui: but if we do /any/ fti lookups on person we will need that index [00:16] sinzui: anyhow, its in your squads court; I just dug into the query from curiosity; I hope that helped. [00:16] lifeless: It was a very timely query. Thank you very much [00:18] huwshimi: http://people.canonical.com/~ianb/person-picker-extra-detail.png [00:21] Ugh, my wifi is flaky [00:38] Project windmill-db-devel build #312: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-db-devel/312/ [00:52] lifeless: How does it not explain the cause? [00:52] It says there are already binaries published in the archive. [00:52] It is less than completely transparent. [00:53] But it *does* explain the cause for anybody who knows anything about Debian archives in the last 10 years. [00:53] wgrant: its sufficiently opaque to confuse doko. [01:03] True. [01:14] Why does an Icelandic volcano always erupt like a month before we go to Europe? :/ [01:28] Die, git, die. [01:28] WedonotneedaForkbuttondammit [02:48] man, users get *so* confused [02:48] bug/158702 [02:50] Yes. [02:50] But this user has a bit of karma. [02:50] It's not the normal confused brand new user case. [02:50] Ah, heh. [02:51] no [02:51] its a confused established user [02:51] I think they meant question 158072? [02:51] Er, 158702. [03:08] wow [03:08] bug queries with structuralsubscriptions in the are -really- slow [03:11] still running [03:13] still running [03:13] ! [03:18] lifeless: When doing the initial work for populate-spr-changelogs, the initial query took 65 *minutes* on DF [03:21] Project windmill-devel build #124: STILL FAILING in 1 hr 19 min: https://lpci.wedontsleep.org/job/windmill-devel/124/ [03:53] heh [03:53] this is up at 45 now [03:54] you can see why its timing out in prod [03:59] Aggregate (cost=816866.73..816866.74 rows=1 width=0) [04:04] that's quite a lot of milliseconds [04:04] thats cost, not ms [04:05] running it the time was past 45 minutes when I nuked it [04:05] cost may be ms, but its actually not comparable between pg instances unless - all- the config knobs are identical (including CPU) [04:05] ah [04:06] plans are evaluated by cost [04:06] the cheapest is chosen [04:06] the knobs say things like 'a block of random IO costs X' [04:07] and an in-memory sort of width 500 length 200 costs Y [04:11] Project windmill-devel build #125: STILL FAILING in 50 min: https://lpci.wedontsleep.org/job/windmill-devel/125/ [04:21] wgrant: ping [04:22] sinzui: Hi. [04:22] wgrant: I want to talk about bug 561380 [04:22] <_mup_> Bug #561380: /builders page is oopsing

< https://launchpad.net/bugs/561380 > [04:23] I'm not sure it requires any discussion, but OK :) [04:23] The fix is very clear and simple. [04:24] delete the page yeah ? [04:25] wgrant: Since the template is just reporting current state; I propose PackageBuildFormatterAPI return either nothing, , state thee is nothing to see, or the link the build obfuscating the private team+ppa, [04:25] sinzui: We already have facilities to show private BPBs. [04:25] We just need to extend that to SPRBs. [04:25] lifeless: Why? [04:26] wgrant: I have a massive headache; my sense of humour gets distorted at such times [04:28] I do not see the formatters for that. [04:29] lifeless: I suspected it may have been an attempt at humour, but you are not unknown for making radical proposals. [04:33] sinzui: Let me see. [04:34] Oh, I see. [04:34] This is different from the SPRB bug. [04:35] So, yes, Julian's analysis is correct. [04:35] But hmm. [04:36] I think this may be fixed. [04:36] wgrant: PackageBuildFormatterAPI think it is checking that the user can see it: [04:36] if not check_permission('launchpad.View', build): [04:36] return 'private source' [04:36] IPerson's launchpad.View adapter allows commercial admins to see the person. [04:36] But that guard predates the bug reports [04:36] s/the person/private teams/ [04:36] Sure, in this case he can view the build because he can view the archive because he's a commercial admin. [04:36] But the archive is owned by a private team. [04:37] Which he can see (at least now). [04:37] I guess the adapters have changed since PMTs were removed. [04:37] But let's see. [04:38] Heh. [04:38] Yes. [04:38] You fixed this in August. [04:38] 11327.2.1 "Allow commercial admins to view private teams." [04:39] Yes, but was bigjools the victim here? === almaisan-away is now known as al-maisan [04:40] "You are logged in as Julian Edwards." [04:40] Unless we have another Julian Edwards. [04:40] He has also been a commercial admin for more that a year, so how did he see it [04:40] hmm? [04:40] This was filed in last April. [04:40] When he could see all private PPAs due to his commercial adminity. [04:40] But couldn't see private teams. [04:40] Sorry [04:40] I have no ind [04:40] mind [04:41] No ind! [04:41] * sinzui shuts up [04:41] This sounds disastrous. [04:41] * wgrant closes ze bug. [04:41] ViewBinaryPackageBuild looks sensible too [04:42] Yeah. [04:42] SPRBs into private archives may still be problematic. [04:42] But BPBs are fine. [04:42] (assuming the security adapters aren't insane, and in this case they were -- access to a subordinate object was granted without having access all the way up to the root) [04:43] jtv: The conventional way to avoid this discussion is just to use ~janitor. [04:43] jtv: I think that may be prudent here. [04:43] wgrant: been over that. No. [04:43] :( [04:44] * jtv relocates [04:46] lifeless: Any ideas on that maybe-bad rev? [04:46] I've tested it in a few browsers and it seems to work OK. [04:46] And bac did not respond to my cries last night. [04:47] And the feature is as-yet unreleased. [04:47] So I think I shall qa-ok it and the two other things and organise a deployment. [04:47] Hm. [04:47] Although we are LOSAless. [04:47] So I guess it doesn't matter all that much. [04:59] lifeless: You were saying earlier that person.fti was unindexed, but I see a gist index on it. [05:19] sinzui: Still around? [05:19] yes [05:19] wgrant: where are you looking [05:20] sinzui: I am attempting to install Balsamiq Mockups. They have am amd64 .deb, but I cannot locate an amd64 build of Adobe AIR. Am I missing something here, or must I hack the i386 one? [05:20] wgrant: revert the bad rev [05:20] lifeless: Huh, you're right, it's not on the production DB. [05:20] But is on dev. [05:21] wgrant: http://kb2.adobe.com/cps/521/cpsid_52132.html [05:21] lifeless: :( [05:21] yuck. [05:21] wgrant: the different between theory and practice [05:21] StevenK: BURN [05:21] I am using i386 [05:21] sinzui: The 90s called, they want their archtag back [05:21] i386 VM time. [05:21] its ironic to be using proprietary software to build open source software [05:22] by ironic I mean saddening [05:22] lifeless: *cough splutter* Launchpad *cough cough* [05:22] StevenK: I gave up on 64 when I realised that the apps were only using more memory and not providing more performance [05:22] wgrant: By various hacks that I don't want to recall, I got AIR to install on amd64 [05:23] StevenK: Yes, but I probably don't want Adobe crap outside a VM anyway. [05:23] wgrant: at least we fixed Launchpad. [05:23] sinzui: But it's a complete waste if you have more than 4GiB RAM [05:23] jtv: This is true. [05:23] not soon enough for me. I was tired if having deadlines with a broken environemnt [05:24] StevenK, wgrant: mind if I kick df for an upgrade? [05:24] YES [05:24] I believe StevenK is currently touching it in bad ways. [05:24] wgrant: mind if I kick StevenK for an upgrade? [05:24] I'm using it, hands off [05:24] Well keep the door open just in case. [05:25] Or do you mean "I'm using it. Hands off."? [05:25] I updated the code before lunch, so about 2 hours ago [05:26] Looks like that was still well before my overnight landing percolated through. :( [05:27] wgrant: so bac's rev [05:27] wgrant: I think it should be reverted [05:27] wgrant: i said as much in the bug [05:27] I shall revert it. [05:27] You did. [05:29] Ahhh what luck it was merely the version number that was out of date—my branch is in there. [05:29] StevenK: mind if I sync a few oneiric packages on df? [05:29] jtv: Yes [05:29] hmmmgrr [05:30] I'm playing with the package copier [05:30] Ah! [05:30] Then maybe you can just tell me what I need to know. [05:30] In fact, looks like (once I got past the timeouts just now) I've found an example of just the display I was trying to reproduce. Thanks [05:33] Gnargh testfix. [05:33] lifeless: Can we disable the rabbit test pls? [05:33] s/test // [05:34] wgrant: gavin has an improvement he is/has landed [05:34] Stil fails. [05:34] +l [05:34] wgrant: its possible that the failure is due to that improvement, or that the improvement hasn't reached bb [05:34] No, this is clearly a failure with the new code. [05:34] Hard to tell if it's the same failure that we've hit 20 times in the last week. [05:34] But concealed by the improvement. [05:35] so sure - critical bug for disabled test, etc [05:39] You know it's failing probably near half the buildbot runs, right? [05:40] wgrant: I just agreed to disabling it! [05:40] Yes, but your suggestion that the improvement caused the failure suggests that it hadn't already been failing every second run for weeks. [05:41] wgrant: I didn't realise it was that flaky [05:41] It's actually only 1/3. But yeah. [05:41] still not great. [05:41] -> Bitmap Index Scan on bugtask__distribution_sourcepackage__heat__idx (cost=0.00..567.17 rows=17172 width=0) (actual time=141.166..141.166 rows=503359 loops=164) [05:42] repeated 146 times [05:42] Fun. [05:42] -> structural subscription scaling fail [05:42] 70M rows processed to get 2.5K results [05:42] Hmm. [05:42] Not sure how best to disable this. [05:42] Since it's the only test in the class. [05:42] And the only class in the file. [05:42] I guess I should rename the file. [05:42] Yeah, rename the file [05:43] hih [05:43] just rename the test [05:43] No, then the testrunner bitches that there are no tests in the class. [05:43] :( [05:43] well [05:43] thats a stupid freaking test runner then isn't it [05:43] does it support skips ? [05:43] I don't think so. [05:43] actually [05:44] testtools does [05:44] just do a skip [05:44] self.skip('disabled') [05:44] @skip? [05:44] see what happens [05:44] Heh. [05:44] OK. [05:44] or that; 6 billion ways to spell it [05:45] It appears to succeed, but at least does not fail. [05:45] Thanks. [05:47] not the plan your doctor ordered: [05:47] Nested Loop (cost=2.76..17359385328490.43 rows=247357031677542 width=4) [05:48] ..... [05:51] exactly [05:52] Is that 247 trillion? [05:52] who knows [05:53] Looks like it. I don't think we have that many rows in our entire db [05:53] structsubs [05:53] win [05:53] got it down to 25 seconds so far [05:54] 247 trillion, yeah. Awesome. [05:54] 25 seconds [05:54] bah [05:54] 15 [05:54] server team has 146 subscriptions [05:55] the live plan is evaluating *each one* with 5 bugtask table index bitmap scans [05:56] sorry, 164 subs [05:57] Adobe crap safely contained in a VM :) [05:57] I like how the AIR download page tells you you'll probably need to turn off antivirus software. [05:59] win! [06:15] hah, this subscription query is broken anyhow [06:18] Oh? [06:19] actually a sub limit [06:19] can't do series + package [06:46] Hm. [06:46] ValidPersonOrTeamVocabulary is stupid. [06:51] jtv: Did you copy alien-arena-data into oneiric-updates? [06:52] StevenK: yesterday (though I didn't get to specify a pocket) [06:52] jtv: It's component is non-free [06:52] Because copies don't do overrides. [06:52] Yet [06:53] ValidPersonOrTeamVocabulary is pretty nice. [06:53] StevenK: did I cause a problem? [06:53] Yes [06:53] I'm sorry about that... any way in which it could have been prevented? [06:53] It seems to take the 100 most relevant results, then order them by displayname instead of relevance. [06:53] How useful. [06:54] jtv: By not doing that [06:54] *And* get my Q/A done? [06:54] By undoing it [06:54] :-) [06:55] * StevenK re-publishes -updates [06:55] Or by copying stuff that's in Debian main. [06:55] And not contrib/non-free. [06:55] That's the critical bit. [06:55] Why is it specifically contrib and non-free that are a problem? [06:56] Because they're not in Ubuntu. [06:56] Because Ubuntu doesn't have those components [06:56] The other Debian component is main, which Ubuntu has too. [06:56] wgrant: win! [06:56] Then presumably the copy simply went into main? [06:56] jtv: No, because that needs overrides. [06:56] Copies don't do overrides. [06:57] So then what happened instead? [06:57] It went into non-free. [06:57] So it created a component? [06:57] And alien-arena is in contrib [06:57] it created an invalid publication. [06:57] Because that component is not publishable in that archive. [06:58] I suppose that will be fixed at some point though? [06:58] * StevenK re-publishes -updates AGAIN [06:58] lifeless: It also seems to retrieve the top N private teams separately, then merges the two and drops all the FTI info. [06:58] That whole function makes my head hurt. [06:58] jtv: Copies need overrides, yes. I'm QAing it now [06:58] Which this mess didn't help at all [06:59] QAing the first step of it. [06:59] Very sorry about that; I'll coordinate with the others next time I copy a package. [07:00] Or pick a package that is in Debian main, not contrib or non-free, like wgrant said [07:00] Proprietary software destroys the world, again! [07:00] Bwaha [07:02] StevenK: I don't think that'll help as much: this time it's a matter of figuring out what Debian component it's in (which I guess I'd find out on packages.debian.org?) but once this particular bug is fixed, it'll be something else. [07:03] jtv: rmadison is your friend [07:04] It may say so on youface or whatever your kids use these days, but I'm not aware of the lady in question. [07:04] % rmadison -u debian -s sid alien-arena [07:04] alien-arena | 7.51-2 | sid/contrib | source, amd64, armel, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc [07:05] Ah, alpha/hppa are actually dead now? [07:05] * jtv sheds tear for alpha [07:05] Or at least on ports. [07:06] They've moved === al-maisan is now known as almaisan-away [07:22] Project windmill-devel build #126: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/126/ [07:24] Hi stub! Want to try the Ubuntu Café for going over that patch? [07:24] Urgh. [07:24] Still booting. [07:25] Where is it btw? [07:25] The BranchRevision.id doompatch? [07:26] The footgun, yeah. [07:26] It looked simple enough, but zomgscary. [07:26] With luck, it will give our toenails a lovely trim. [07:26] And not our toes? [07:27] Ha ha, StevenK, always the optimist [07:36] * jtv relocates === stub1 is now known as stub === stub1 is now known as stub [07:45] oh man, that was a tough one. [07:45] wgrant: if you're interested - https://bugs.launchpad.net/launchpad/+bug/787294/comments/11 [07:45] <_mup_> Bug #787294: Person:+patches timeouts < https://launchpad.net/bugs/787294 > === stub1 is now known as stub [07:45] my headache really didn't help - hard to think well about problems with a pounding going on === stub1 is now known as stub === stub1 is now known as stub === stub1 is now known as stub === stub1 is now known as stub === stub1 is now known as stub === stub1 is now known as stub === stub1 is now known as stub [08:48] good morning [09:04] wgrant, lifeless: We could try increasing the time-out. I didn't change that. [09:04] Re. the RabbitMQ fixture test. [09:04] Hmm. [09:09] wgrant: The time-out is only 5 seconds right now, which is fairly tight. I think we should put it up to 15 seconds and see what happens. [09:18] Guten morgen [09:20] Project windmill-devel build #127: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-devel/127/ === almaisan-away is now known as al-maisan === gmb changed the topic of #launchpad-dev to: Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: gmb | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:214 - 0:[######=_]:256 [11:02] Project windmill-devel build #128: STILL FAILING in 1 hr 17 min: https://lpci.wedontsleep.org/job/windmill-devel/128/ === al-maisan is now known as almaisan-away [11:09] oh yay [11:09] linkin invites sent to lp bugs [11:16] heh [11:17] how long does a fix take to land from qa-staging to production? [11:17] (after being verified) [11:18] nigelb: depends how quickly someone presses the button [11:18] bigjools: Ah, so just wait some more I guess :) [11:18] and what other things need QA [11:19] nigelb: Which revision? [11:19] StevenK: "Fixed in stable r13094" [11:20] Ah, you're stuck behind r13092 which is qa-bad [11:20] There was a revert happening at some point [11:20] gmb needs to QA r13096 [11:21] And allenap needs to QA r13101 [11:21] ah, that's 13108, revert 13092 [11:21] Right, it likely hasn't hit qastaging yet [11:21] Ah [11:21] It has [11:21] My deployment report was old [11:21] StevenK: I /think/ I've done that one. [11:22] I was looking at http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/changes [11:22] nigelb: And you need to QA r13106 :-) [11:22] StevenK: that landed a few hours back, didn't get time :D [11:22] "[testfix][rs=wgrant][rollback=13092] Disable TestRabbitFixture.test_start_check_shutdown. Its days of destroying the test suite are over." [11:22] * StevenK cackles [11:23] haha [11:23] nigelb: So, to answer your question: "It depends" [11:23] Right, so I think I'm one of the people blocking it at this point :) [11:24] There is a bunch of QA to do [11:24] :) [11:24] I guess I have to wait until 13108 to get QA'd because of 13092. [11:25] r13108 won't get QA'd, it's a rollback [11:25] If you mean up to r13108, that's different. [11:26] lifeless: hi [11:26] I meant upto. [11:26] Bah, my rev isn't seeming to work. [11:26] nigelb: Right, then yes, you do. [11:26] How do I know something is in qastaging for sure? [11:27] wait, PQM got done with it a minute back :/ [11:27] jml: hi [11:27] nigelb: when its on qastaging the tagger will notice and tag the bug [11:27] nigelb: check the revision number that it landed on [11:28] compare with the one at the bottom of every page [11:28] lifeless: ah, yes. Its tagged. [11:28] bigjools: hrm, that seems to indicate its landed. But it isn't working. *whee* QA fail. [11:28] nigelb: we only flag qa-bad if it should block rollout [11:29] bigjools: Its not doing anything harmful, just needs more fixing. [11:29] hrm, okay. This is really random. [11:29] https://blueprints.qastaging.launchpad.net/ubuntu/+spec/test-blueprint-mark/ [11:29] I don't even know what order its getting sorted :( [11:30] Its working "mostly" except for the adicarlo name. I suspect it has something to do with python's sort function. [11:32] You probably should have used .order_by() on a ResultSet? [11:32] I used sort because that's what's used in the sprints too. [11:34] nigelb: Python's sort is entirely sensible, except that the default ordering for objects that don't define how they should be compared is arbitrary (i.e. based on memory address) [11:34] Bah, its a problem with using sort(), it clubs all the capitals first and the small letters later. [11:35] lifeless: hello. I'm at a cafe, but am willing to try some sort of voice comms if you're up for it [11:35] that sounds great. pick your poison [11:35] sky.net? [11:35] nigelb: Well, that's how str/unicode's sort order is defined :) [11:35] nigelb: sort(seq, key=unicode.lower) [11:36] nigelb: or as StevenK says use order_by on the result set [11:36] Project windmill-db-devel build #313: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-db-devel/313/ [11:36] order_by ? [11:36] isn't that a query thing? [11:36] lifeless: ok. [11:37] nigelb: yes. The data originates in a db query after all. [11:37] spiv: yeah, but its a cached property, so we end up having to mutate that list every now and then when someone subscribes newly. [11:37] that's probably the most efficient place to do it [11:38] https://code.launchpad.net/~nigelbabu/launchpad/90628-spec-sub/+merge/62003 [11:38] ^^ that's the branch with the merge changes for this one [11:38] lifeless: hello can you hear me speaking? [11:39] lifeless: I can hear you [11:39] lifeless: my mic isn't coming up in sound config, even though it's correctly configured. [11:40] nigelb: well I guess just add .lower() to the sort key func, e.g. key=lambda sub: sub.person.displayname.lower() [11:40] spiv: aha, I shall test that when I get to my computer running LP and propose merge again :) [11:40] this means I should add a test case for this. [11:41] nigelb: I'm so glad you said that :) [11:42] gmb: I have a branch waiting for your perusal if you're reviewing please? [11:42] bigjools: Sure. I'll be free to look in about ten minutes [11:42] cheers, no rush [11:45] spiv: yay, it works locally. So I need to fix and push them both. [11:46]