[00:26] it would be nice, yes [00:39] * wgrant sobs [00:40] (@ the bug-columns-related new sort orders) [00:50] * StevenK tries to work out what to get run on qas to generate mail to qa bug 114753 [00:50] <_mup_> Bug #114753: Team membership status change emails should be gender neutral

< https://launchpad.net/bugs/114753 > [00:50] Or where the staging mailbox password even is. I thought I had it locally. :-( [00:50] Probably cronscripts/send-person-notifications.py [00:54] wgrant: StevenK: would like your opinions on bug 897442 [00:54] <_mup_> Bug #897442: maintained packages page not up to date after several weeks < https://launchpad.net/bugs/897442 > [00:55] lifeless: Aw, you're ruining all the fun. [01:00] wgrant: howso? [01:01] Asking me directly about derived distros omissions that I pointed out a year ago, so I can't just sadly and derisively laugh at it from the sidelines. [01:01] I *think* that was due to the gina fallout [01:02] Morning! [01:02] I can't wait to ask bigjools about cricket. [01:02] StevenK: so, fixed already? [01:02] StevenK: or 'operational glitch not a bug' ? [01:03] Not fixed. [01:03] The solution is undefined, and probably unclear. [01:03] ok [01:03] And to some extent probably impossible. [01:03] can one of you define the problem clearly in the description then ? [01:03] It's very similar to the notification issue, which was only vaguely solved recently. [01:04] the symptoms are fairly clear, but too high level :) [01:13] nigelb: Oh, why? [01:14] 370 tech debt bugs [01:14] wgrant: StevenK: ^ [please to be updating the bug] [01:15] StevenK: England bowled out in the second innings for 72. [01:16] nigelb: Bwahaha [01:16] #1 in the world my left foot [01:16] Exactly. [01:22] wheee httpbis goes insnae [01:34] lifeless: Oh? I've not been following it much. [01:34] What have they done now? [01:35] its about to be recharted [01:36] rechartered [01:36] httpbis is done, now onto a new version of http [01:36] you can imagine the long carried concepts that this is dragging out of the woodwork [01:36] some good [01:36] some, uhm, less [01:36] Oh yes. [01:42] ok, htf does bug 235168 remain open ?? [01:42] <_mup_> Bug #235168: Database user fiera needs access to table GPGKeys

< https://launchpad.net/bugs/235168 > [01:43] StevenK: wgrant: you may know. We should be seeing massive failure unless its been worked around somehow. [01:43] lifeless: It *does* have access to gpgkey. [01:43] Perhaps the bug is that it shouldn't need it. [01:44] But it clearly should. [01:44] ok [01:44] s s/needs/has/ then close invalid [01:44] Let me just check when it was added. [01:44] It was added the day after that bug was filed. [01:45] By al-maisan [01:45] So I think it can be closed, as it's not a bug. [01:46] yay timeouts [01:47] wgrant: so it has access to the gpgkeys table to find folk from keys? [01:47] lifeless: Right. === micahg_ is now known as micahg [01:47] thanks [01:49] lifeless: Any idea why we can now sort bugs by tag or spec name? [01:50] They both seem only marginally useful, if that. [01:50] the bugcolumn project decided that every shown field should be sortable [01:50] O_o [01:50] o_O [01:50] so they can show the fields being shown as 'columns' [01:50] -_- [01:50] and they can be clicked on to sort. [01:51] This didn't raise performance concerns? [01:51] It's both somewhat useless, and likely to be very slow. [01:51] I flagged that with the team, yes. [01:51] I don't know if they have measured. [01:52] The original idea was to allow arbitrary combinations of sorts. [01:52] importance + age, etc. [01:52] Sure. [01:52] That sort of thing is useful. [01:52] Yes, but complex and hard to get right performance wise. [01:52] But it's made a little more challening by having 9 billion combinations. [01:52] 8.7 billion of which aren't useful [01:52] sure [01:53] anyhow, so a) the squad were, AFAIK, aware that performance is a factor [01:53] I have a feeling that even ordering by assignee will no longer work for Ubuntu. [01:53] and b) I don't know if they profiled the resulting queries. [01:53] Indeed it does not. [01:54] timeout? [01:54] of course :) [01:54] file a bug [01:54] this probably needs revisiting [01:54] I am trying to work out how to safely do the fact table. [01:54] But there's about 10 useless sort orders that I really don't want to have to test against it. [01:57] lifeless: Hah [01:58] lifeless: Did you know that there are still several per-bug query regressions left in the new bug listings? [01:58] I didn't [01:58] please file a bug and flag for deryck [01:58] I did a month ago :/ [01:58] That got fixed, I thought. [01:58] So did I. [01:59] Ah, no. [01:59] Bug #901122 [01:59] <_mup_> Bug #901122: New bug listings need to preload more attributes < https://launchpad.net/bugs/901122 > [01:59] It's the other one, with duplicated 4s queries, that got fixed. [02:00] Nearly 2 months ago. [02:00] ok [02:01] I have a clal planned with deryck this week anyhow [02:01] I will mention that bug [02:01] Does the 5s policy not apply in weaker form to that sort of thing? [02:01] Something like "can't release with known trivial performance regressions"? [02:01] Hah [02:02] yes, [02:02] lifeless: wgrant I know he reported on it a couple of times during stand ups [02:02] we're not meant to release with known regressions [02:02] it's on our kanban and in coding [02:02] and all new pages are meant to be 5s capped. [02:02] we haven't yet agreed to 'changed pages need to be 5s capped' - I don't think we are quite ready for that. [02:03] lifeless: Sure, but "changed pages shouldn't have obvious easily-fixed speed regressions" seems reasonable enough. [02:03] wgrant: I think francis would support 'changed pages should not have regressions' [02:04] we don't have a formal checkpoint for this today [02:04] (and in fact if you check the current release process stuff, squads are not meant to rotate while there are regressions [02:05] but we're not following through all that well yet; still figuring out the mechanics [02:05] I've given up on pointing that bit out :) [02:06] please don't give up [02:06] sometimes just a reminder is very useful [02:06] We conciously regressed with speed, usability, information density regressions. [02:06] Presumably because the feature was dragging on. [02:06] s/regressed/released/ [02:07] I was only aware that the latter one was considered [02:08] Fortunately for products it's somewhat usable. [02:08] As you can turn off location display. [02:08] And get near-normal density. [02:08] For Ubuntu you can't :/ [02:33] hates isp. [02:34] StevenK: \o/ 114753 [02:34] lifeless: I think you should your ISP exactly what you think of them. [02:34] At length. [02:34] Sigh. Should *tell* your ISP [02:34] StevenK: I've started whinging on twitter to them when it goes :P [02:35] Oh sure, *that* will help. [02:35] makes me feel better [02:36] and back to the bug triage. wgrant - could you please comment on / update the description for bug 897442 ? [02:36] <_mup_> Bug #897442: maintained packages page not up to date after several weeks < https://launchpad.net/bugs/897442 > [02:39] hah, crazy, my if-I-had-to-choose tweet is *still* being retweeted [02:40] to another 3K folk today. *boing* [02:50] lifeless: Which tweet? [02:54] https://twitter.com/#!/rbtcollins/status/160126945995141122 [02:55] ohyeah, I RT'd that the other day. [02:55] . [02:55] . [02:55] . [02:55] hi lifeless [02:55] Ah [02:56] james_w: hi [02:56] hi wgrant [02:56] I've been looking at getting Django to include the oops id in the response body [02:56] I have an approach that does it, but it has to use thread local storage [02:56] Hi james_w. [02:57] james_w: can't you use the wsgi context? [02:57] hmm, possibly [02:57] and then get it back out from the report in the error_render function [02:58] james_w: I was suggesting, at the point you decide you are oopsing (which is probably the django error handler, which is inside the wsgi shell) [02:59] at that point we can either publish the oops directly, dropping some of oops_wsgi from the stack [02:59] that you use a timeuuid, (uuid1?) back that to a unicode string, stash it in the wsgi context in a oops.id or oops.context['id'] or some such [02:59] and change the oops-wsgi default handlers to honour if from there, if found. [03:00] that would work, but would break publish_only_new [03:00] I wonder if that should use some mechanism other than the id to decide if the report has already been published? [03:00] uhm [03:01] I wouldn't publish directly, theres no value in doing so [03:01] and you'd have to duplicate logic [03:01] yeah [03:01] (consider that we also want to make oopses for soft timeouts, local 404's etc) [03:01] the fact that django isn't structured like a wsgi app is a nuisance :) [03:02] yes [03:05] would a published key in the report work sufficiently well for publish_only_new to do the amqp->datedir fallback? [03:10] we'd need to teach it [03:10] e.g. have a requested_id field or some such [03:11] allocation in publish() is very clean, but then we get this nasty django interaction [03:13] lifeless: I've commented on that bug, but it has probably only confused matters :) [03:13] one way would be to track 'published' separately [03:13] (e.g. in a key, or as a separate publishing-state-variable) [03:13] (most interpretations of the bug would have previously been very confused, but in too simple a fashion) [03:14] another is to have a helper in the oops code that publishers can use to decide what id to use (see also the related 'preserve id' flag to DateDirRepo [03:14] wgrant: thanks [03:47] wgrant: whats the jargon for the 'functionality to which lifeless refers' [03:49] 'impossibilities and other fantastic legends' [03:49] zing! [03:50] Haha [03:50] lifeless: Not sure it has a name. [03:51] +1 for calling it what spm did [03:51] :-) [03:51] All hail spm, the well-timed. [03:51] years of practice [03:51] :modest: [03:52] lifeless: O hai. Can I please kill the maverick packages in the LP PPA? [03:52] By rights we should kill natty too, but one DAS at a time [03:52] There are still natty users [03:53] I don't think anyone's still on maverick, though. [03:53] In fact I think maverick's broken. [03:53] StevenK: L, O and P should be all we need [03:53] wgrant: what natty users? [03:53] At least one LP dev uses natty. [03:53] wgrant: !cite [03:56] lifeless: There is an already existing Obsolete PPA which contains a bunch of hardy stuff, I'll copy the maverick packages there and then delete them [03:56] coolio [03:56] given the canonical policy for O/S use [03:57] I wouldn't bother asking me about this, JFDI :) - after checking on buildbot and any non-prod machines, of course [as prod machines use the losa repo...) [03:57] s/losa/is/ [03:58] 6/1 1/2 other [03:58] lifeless: buildbot does not use the PPA [03:58] ec2 and dev machines only [04:00] * StevenK gets distracted by changing the displayname of the obsolete PPA to something better [04:00] StevenK: blargh, I knew whereof I meant. [04:01] wgrant: what dev uses natty? [04:01] lifeless: I don't recall, but I'm pretty sure it came up at the Thunderdome. [04:02] I can recall hearing it too [04:02] I think it was one of the mac fanbois [04:02] That makes sense, yes. [04:03] * StevenK waits for the copied packages to be published before deleting them [04:05] so, tough luck for them, really. [04:05] we should all be dogfooding precise in the next month or so anyhow. [04:05] and everyone should have gotten onto O in similar fashion. [04:06] lifeless: I'll be mailing about Maverick after the fact, the mail warns about Natty. [04:07] thanks [04:08] lets aim to clean natty and O up a week or so after P ships. [04:08] clean sweep [04:08] That late? I was going to clean up natty this week [04:08] oh, sure [04:08] I was figuring you wouldn't want to fiddle with it again so soon [04:08] but if you're inclined, I won't get in the way :) [04:09] Meh, most of it is waiting for the PPA publisher [04:09] StevenK: Why? [04:09] You don't need to wait. [04:09] wgrant: I'd prefer them to be published in the other PPA before I delete them from the first. [04:10] Unnecessary, unless you're going to take more than 7 days to copy them. [04:10] They just published, anyway. [04:11] "Source and binaries deleted by Steve Kowalik request:" [04:12] * StevenK eyerolls [04:27] wgrant: https://code.launchpad.net/~stevenk/launchpad/ppa-packages-deletion-grammar/+merge/90646https://code.launchpad.net/~stevenk/launchpad/ppa-packages-deletion-grammar/+merge/90646 [04:27] * StevenK glares at his mouse [04:27] wgrant: https://code.launchpad.net/~stevenk/launchpad/ppa-packages-deletion-grammar/+merge/90646 that is [04:28] StevenK: Needs fixing, but you have to work out why :) [04:28] It's not a bug you've introduced. [04:29] * StevenK peers at wgrant [04:30] Can I have a clue? :-) [04:30] messages = []; messages.append() is a horrid way of expressing it, so I've fixed that too [04:30] It's not in the test, or the comment. [04:31] I thought that was a reasonable way to do it, but I'm not too fussed. [04:31] gnar [04:31] I can't find the bug about bug 1 [04:31] <_mup_> Bug #1: Microsoft has a majority market share wgrant: Your issue is with the prose, then? [04:32] No, it's a code bug. [04:34] escaping? [04:34] Bingo. [04:34] cause we like xss ? [04:34] Ah [04:35] + messages = [ [04:35] + '

Source and binaries deleted by %(self.user.display_name)s:'] [04:35] wgrant: ^ [04:36] StevenK: ? [04:36] wut [04:36] StevenK: nice troll :P [04:36] StevenK: display_name is untrusted data [04:36] StevenK: you are assembling html. [04:36] Obviously [04:37] StevenK: so you need to html entity escape the display name to stop monkey business [04:37] No. [04:37] But that pattern is used like five lines down [04:37] messages.append("

Deletion comment: %(comment)s

") [04:37] StevenK: oh yay, even more holes [04:37] So I guess I get to fix both ... [04:38] StevenK: actually, let me rephrase - that second one depends on the value of comment when the string is substituted [04:38] dafuq. [04:38] # Replace the 'comment' content added by the user via structured(), [04:38] comment = data.get('deletion_comment') [04:38] # so it will be quoted appropriately. [04:38] I DO NOT GET IT [04:38] messages.append("

Deletion comment: %(comment)s

") [04:38] * wgrant blame [04:38] wgrant: Shall I just go on a rampage and delete this code for being utter rubbish? [04:39] No, you should fix it, while I write bzr blamestab. [04:39] cprov [04:40] wgrant: Hm, it is wrapped in structured() a few lines down? [04:40] Oh [04:40] So it is [04:40] So yes, that bit is correct. [04:40] (but that was only fixed relatively recently) [04:41] In r5945 [04:41] Hah, recently [04:41] wgrant: http://pastebin.ubuntu.com/822187/ [04:41] Amusingly there were two identical vulnerabilities in the preceding 10 lines, which were not fixed. [04:42] StevenK: That's fixed one of them. [04:42] And the source displayname? [04:42] That one is probably not presently exploitable, due to some constraints in our current data model, but yes. [04:42] Right [04:42] I'm not sure how to fix that in the same way, given the loop [04:43] * StevenK wraps source.displyname in structured() [04:43] Right, it may be best to use the nested structured() support that you added a while back. [04:44] Like I just did? :-) [04:48] Hmmm, wrapping source.displayname in structured didn't work [04:49] How did you try it? [04:49] % structured(source.displayname) effectively [04:50] That's precisely the opposite of what you want. [04:50] Which is utterly wrong, since I've just managed to swap in how to actually use it. :-) [04:50] structured()'s first operand is markup. [04:51] notification = "\n".join(messages) [04:51] TypeError: sequence item 1: expected string, structured found [04:51] Oh, BAH [04:52] This is utterly pointlessness to do it with an array. May as well build a string [04:55] You know what would be good here? :) [04:55] A... TEMPLATE! [jarring chord] [04:55] Haha [04:56] Oh, damn it, can't use += for strings and structured [04:56] No, you'd have to use .escapedtext, which would be nice to avoid. [04:57] Hopefully += works if everything is structured [04:58] ... which it does not. [04:58] No. [04:58] This is where MarkupSafe is nice. [04:58] But IE. [04:58] IE destroys everything :) [05:00] Sigh, this would be easy if it wasn't for the loop of sources in the middle. [05:00] Sure. This is the sort of thing templates were invented for. [05:02] Grrr [05:03] I can't see a nice way to do this. I wonder how to pull in pystache [05:04] Use escapedtext [05:05] Or I guess you could use pystache, but eeeeh. [05:05] mustache is slow and awful. [05:08] Oh, bah, structured is replacing the < and > too [05:10] Hmmm? [05:10] That's the point of it. [05:10] But I'm building HTML :-( [05:11] How are you trying to use structured()? Because it's wrong :) [05:11] wgrant: http://pastebin.ubuntu.com/822199/ [05:12] StevenK: So, you need to wrap the final thing in structured(), or addNotification will escape it. [05:14] wgrant: That works. Other than that, I guess I'm using structed() correctly? :-) [05:14] Sigh, structured() [05:20] StevenK: Not correctly, but not wrongly. [05:20] There's no correct way here. [05:20] I think I can cope with "It's not perfect, but much better than what was there." [05:21] wgrant: Diff updated. [05:24] StevenK: Approved, with one change. [05:26] wgrant: Like http://pastebin.ubuntu.com/822212/ ? [05:28] StevenK: Right. [05:29] Possibly with a comment "If you change the next statement, wgrant will send rabid dogs after you." [05:32] Haha [05:49] Hm, have we been wallyworld-less today? [05:49] no? [05:49] You've just said nothing all day [05:49] been busy [05:50] * StevenK is getting quite tempted to upgrade the ec2 image [05:50] do, you know you want to [05:54] jtv: You can delete your ec2 ami-2b5e9e42 [06:59] bac: You can delete your ec2 ami-9165a5f8 of id 521. [06:59] lifeless: Do you know if anybody in maintenance is sorting out the remaining longpoll issue, or should I JFDI given that Red is no longer with us? [07:01] * StevenK purges Java off his system now that he doesn't need ec2-api-tools [07:05] poor Java :-( === almaisan-away is now known as al-maisan [07:37] * stub adds Zookeeper to -dependencies for a laugh [07:39] I hope we'll need it eventually :) [08:00] Ooh... counter troll. [08:03] * StevenK stabs Thunderbird, pulls the knife out, and stabs it again, twisting the knife. [08:04] Why does every single mail client have to completly suck? [08:05] Perhaps it's mandated in RFC 3501. [08:20] StevenK: A combination of 3501 and 5322, yes. [08:50] good mornig === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 [09:01] wgrant: they are not [09:02] wgrant: if you want to DI, that would rock [09:03] lifeless: Will need some CORS stuff in Apache, I suspect, but will look at some point. [09:15] Morning everyone [09:16] Morning danhg, mrevell [09:17] bigjools: Watched the cricket? I heard England had fun :D === jam1 is now known as jam [09:27] StevenK: Are we going to conflict with ec2 images or are you finished now? I'm just about to attempt to build a PG 9.1 image. [09:27] (but that won't be public until testing is done, couple of days) [09:28] stub: hey [09:28] stub: That sounds dangerous, given that 9.1 on prod is probably some time away... [09:28] lifeless: yo [09:28] stub: so, I missed our catchup last week [09:28] wgrant: Says who? [09:28] lifeless: That is fine. I wasn't there either :) [09:28] stub: I'd like to catch up tomorrow; reckon you could be around a bit earlier? [09:30] lifeless: sure [09:30] stub: Says me not trusting pg_upgrade, and an insufficient CPU count to do it any other way :) [09:30] But if pg_upgrade works now, that's great. [09:30] stub: also, there are about 4 bugs that all boil down to 'make a new user', wondering if you want to knock them over sometime soonish; seems like one straightforward patch should do it [09:30] stub: I've tagged them 'dbuser' [09:30] wgrant: I need to push it forward or it will never happen. There are problems, and we will go ahead when I have solutions :) [09:30] stub: (tomorrow - thanks) [09:30] and now, for me, gnight [09:30] lifeless: k [10:09] stub: I'm done, 524 was just an update since I got sick of waiting for ec2 to upgrade 80MiB worth of packages. === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugtasks: 4*10^2 === Ursinha` is now known as Ursinha === fjlacoste is now known as flacoste [14:04] Morning, all. === matsubara is now known as matsubara-lunch === salgado is now known as salgado-lunch [15:32] jcsackett, do you have time to mumble? === matsubara-lunch is now known as matsubara [15:52] Interesting quit message there :) [15:53] sinzui: i can mumble now, sorry i missed your ping. [15:53] * sinzui starts mumble [15:53] * jcsackett does too === al-maisan is now known as almaisan-away === salgado-lunch is now known as salgado === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck [19:28] mornink [19:28] deryck: hey [19:56] lifeless, hey man. been meaning to reply to you all day. sorry [19:56] lifeless, how about sometime after the TL call this week? [19:57] mm, pretty sure that that morning is wall to wall calls [19:57] * lifeless consults calendar [19:57] I think statik cancelled, so I could do tlstart + 2h as the start time [19:58] lifeless, 2100 UTC? [20:02] I think so [20:03] lifeless: hang out time? [20:04] flacoste: sure, can you send a regular invite? that one is on the wrong machine :P [20:05] lifeless: i did [20:06] oh, google notifications fail [20:06] 'this service is unavailable please try again later' [20:06] i resent the invite [20:08] lifeless, I'll calendar you and move it if it's wrong. === matsubara is now known as matsubara-afk [20:34]