[02:17] Ooh. [02:17] The new bug listings are mostly nice. === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugtasks: 275 [02:28] StevenK: you working on 884217? [02:30] wallyworld_: I have a branch for it [02:31] StevenK: the reason for asking is that i am thinking about implementing a security adaptor such that if the logged in user can view the context undet which team name visibility is required, they can see the team name [02:31] so if the team name needs to be displayed because the team is a bug subscriber, then the context would be the bug [02:32] these rules would replace any current security adaptor for private team visibility [02:32] I think we only have the TAL formatter [02:32] StevenK: so i wanted to be sure that we weren't going to do the same thing etc [02:33] Which returns and soft OOPSes a MixedVisibilityError [02:33] i'll need to dig around and see what needs to be done [02:33] to fix it [02:34] but i think the above sounds ok? [02:58] StevenK: [BS]PPH.{binary,source}packagename have been fully populated now? === jtv1 is now known as jtv [02:59] hi, lifeless, sorry i had to run [02:59] jtv: Not even close. [02:59] Oh. [02:59] Damn Raphaël and his clever ideas. [02:59] lifeless: the tests that actually failed are those that use the helper, such as testBadUrlBzrSshCaught [03:00] StevenK: I guess you'll add not-null constraints when done. [03:00] and they do pass on their own. they only fail if run after the new test i introduced, which makes me think i've done something Bad(tm) in that test [03:00] hi bac :) [03:00] hi jtv [03:00] jtv: It is being blocked by long running transactions from the publisher, and if that isn't running, then it's the backups. [03:00] bac: thats very unusual then isn't it! [03:01] lifeless: yeppers [03:01] bac: uhm, I'm not entirely here today; can you drop me a mail and I will look first thing tomorrow ? [03:01] StevenK: ironic, since I was also hoping to use the column to speed up the publisher. [03:01] lifeless: sure. thanks. [03:01] jtv: staying dry? [03:02] bac: moving around to do so, but yes. In the house, last we know is it got up to just below the kitchen counter-top. [03:02] The hip new word is revacuee. [03:41] StevenK: perhaps there's more we can do to break up those long-running publisher transactions? [03:47] Fixing the dominator would be one, I think. [03:50] Catch 22. [03:51] StevenK: the updater code looks like it's probably slower than necessary. [03:52] jtv: You need my denorm work to make the dominator faster? [03:53] It'd help, yes. I've got about 5 branches waiting for rollout, and those will probably help, but it's getting close to the end of the low-hanging fruit. [03:54] Some things that I think would speed up the updater: [03:54] * Don't order by id. [03:54] * Bulk-load the [BS]PRs. [03:55] * Don't load the [BS]PNs at all—all you need is their ids. [03:55] * More radical: don't load anything, just let the DB do the work. [03:57] is this change to block reopening fixreleased bugs new? [03:58] poolie: EWIN? [03:58] no [03:58] poolie: It's at least several months old. [03:58] Maybe even a year now. [03:58] perhaps i just never hit it [03:59] poolie: The reporter and bug supervisor can reopen. [03:59] But not eg. the assignee. [03:59] hm [04:00] i guess i'm not a supervisor for bzr-svn [04:00] :/ [04:01] Indeed. [04:01] That's ~bzr-svn, which has only three real members. [04:02] ffs [04:04] i see, i thought it changed recently because robert just answered a year-old question about it [04:17] wgrant, StevenK, lifeless, what are we going to do with https://code.launchpad.net/~vorlon/launchpad/sbuild-multiarch-syntax/+merge/81385 ? [04:18] poolie: Land it. [04:18] *hug* [04:22] poolie: Don't add [no-qa] to the commit message. [04:22] Rather use bzr lp-land --no-qa [04:22] Or ec2 land --no-qa [04:22] That adds it automatically. [04:22] And hopefully avoids confusing things. [04:24] ok [04:24] i wonder if there is a bug for it [04:25] I don't think so. I've discussed it with various people in person, but I don't recall a bug. [04:25] not obviously [04:25] and it's out-of-band qa anyhow [04:26] poolie: I think we have security builds going for the next 9 hours [04:27] eh, semi-wrong channel, meh [04:39] Hah. [04:39] There's no UNIQUE bugsubscription(bug, person) [04:40] The UI forbids it, though? [04:41] Probably mostly. [04:41] poolie: Not going to make that bug Critical+regression? :) [04:41] i guess i could [04:42] rebooting [04:47] jamesh: Hi, around? [04:54] Ah, its lunch time in Perth. [05:02] nigelb: hi [05:06] jamesh: Hey, are you the James listed as Uploader on PyPI for django-openid-auth? :) [05:06] nigelb: yeah [05:06] jamesh: Excellent, 0.4 was uploaded as django-openid-auth_0.4.tar.gz as opposed to -0.4 which leads to pip not finding it :( [05:08] It was fun tracking that down, pip search django-openid-auth says 0.4 is latest, but installing doesn't work. [05:08] nigelb: ah. I didn't actually roll the 0.4 release (achuni handled it, iirc) [05:09] jamesh: ah. I couldn't find achuni on IRC, so I thought best to let you know :) [05:09] nigelb: could you file a bug about it so we don't mess it up for 0.5? [05:10] cool, will do. Is there a way to fix 0.4? [05:12] nigelb: I don't really use pip. Where is the error occurring? [05:12] jamesh: let me get you a pastebin [05:14] jamesh: http://paste.ubuntu.com/732749/ [05:14] Hrm. I guess I could try installing _0.4 [05:15] Nope, didn't work. [05:16] nigelb: anything relevant in the log file that paste mentions? [05:16] yup [05:16] sec [05:18] jamesh: http://paste.ubuntu.com/732755/ [05:19] nigelb: that's weird: Could not fetch URL http://launchpad.net/django-openid-auth/trunk/0.4/+download/django-openid-auth_0.4.tar.gz (from http://pypi.python.org/simple/django-openid-auth/): HTTP Error 404: Not Found [05:20] checking that here, I get "303 See Other" response pointing at the file in the librarian [05:20] Oh. [05:20] That is weird. [05:22] stub1: around? [05:25] i think i will build a package of the buildd stuff now just to test [05:25] and then do an update after vorlon's stuff lands [05:26] poolie: Sounds good. [05:27] jamesh: I'm guessing the usual download is directly from PyPI which it can't find now. Anyway, filed bug 887882 [05:27] <_mup_> Bug #887882: Can't install django-openid-auth 0.4 via pip < https://launchpad.net/bugs/887882 > [05:30] wgrant: I saw you said something about the new bug columns earlier. Are they live somewhere or did you just see a mockup? [05:30] nigelb: thanks [05:31] :) [05:31] huwshimi: Join https://qastaging.launchpad.net/~custom-buglisting-demo (it's Open) and you'll see them on qas. [05:33] oooh. [05:33] hi nigelb [05:34] wgrant, only qas for now? [05:34] Afternoon poolie :) [05:34] wgrant: Ah, perfect, thanks [05:35] wgrant: yo === stub1 is now known as stub [05:35] poolie: Yes. [05:35] zomg. Can't wait. custom bug listings is *amazing* [05:38] stub: It was suggested that I try the new schema without the denormalisation (so, adding policy to AccessPolicyArtifact, meaning that AccessPolicyGrant has either policy or artifact set, not both). I managed to get the equivalent Ubuntu query down to only 10% slower than the denormed version on DF (~650ms), but for products it's around ~100ms, which is slower than the original. [05:38] This seems to be because it always does a seq scan on accesspolicygrant. [05:38] Rather than indexing into it. [05:38] Can't work out why. [05:38] http://paste.ubuntu.com/732768/ is the setup and some sample queries. [05:40] The third query (one CTE and some subselects) is the fastest for Ubuntu. The others sit at 1-1.5s. [05:40] But I can't get it to not seq scan apg. [05:40] that is nice [05:40] i wish the colors were better chosen though [05:40] poolie: What in particular? [05:41] I think Low should not be bold and black. [05:41] i agree [05:41] i would like the importance things to be on one spectrum, so their ordering is reflected in the colors [05:41] Yeah. [05:42] and i think i would like them not to overlap with the status colors [05:42] They're the same as they are now. [05:42] huwshimi, what do you think? [05:42] i like incremental changes [05:42] Red/Orange/Yellow... Black/Blue [05:42] but for things like this it seems like it would be a shame not to make a better splash [05:42] Hmm. [05:42] Actually. [05:42] They're the same as the current *text* colours. [05:43] Which is Red/Orange/Green/Black/Blue. [05:43] wgrant, poolie: We actually have a set of colours that the design team use for statuses [05:43] i wonder if that icon next to the product name is really earning its keep [05:43] wgrant, poolie: I haven't seen this black before [05:44] Rather than the icons, which are Red/Reddish/Orange/Yellow/Blue [05:44] Which probably makes more sense. [05:44] Except for Yellow being yellow. [05:44] Which is a bit ew. [05:45] huwshimi, and are these colors on qas the official colors? [05:45] poolie: Nope [05:45] i guess specifically 'medium' has a very bold green which is more saturated (to my eye) than High [05:45] and Low even more so [05:45] and Wishlist too [05:45] :) [05:45] Yeah, Medium and Low are really obvious. [05:46] poolie: I believe these are the same colours we used to have, with the exception of the black [05:46] i think that's true [05:46] Particularly since High/Critical are the same colour as Triaged, which is the usual status for bugs with an importance. [05:46] So there's no contrast. [05:46] wgrant: I had thought the status colours were going to be removed [05:46] Hmm, interesting. [05:47] also the small caps importance next to the regular status is a little jarring [05:47] It's been a long time since I've seen this work and clearly I need to do a proper review [05:47] and they are oddly aligned [05:47] There was a bug filed overnight about Fix Committed looking like an ajax link. [05:47] 'ajax link' :) [05:47] Bug #887576 [05:47] <_mup_> Bug #887576: new bug listing importance is difficult to read < https://launchpad.net/bugs/887576 > [05:47] Bug #887575 [05:47] <_mup_> Bug #887575: fix released and fix committed status color in new bug listing look like ajax action links < https://launchpad.net/bugs/887575 > [05:48] Interestingly, the first bug's title mentions importance, but description says status. [05:52] Hmm. [05:52] GitHub's status styleing on the issue page itself is suspiciously similar to our new listings' importance styling. [05:53] wgrant, yeah, and unfortunately there is a bit more logic to them styling them that way [05:53] Yes. [05:53] which is that they are tag-type things that can be dragged around [05:57] Well, labels are separate, but all the category-related things seem to be styled like that. [05:57] Labels, statuses, filters. [05:58] And Google Code's issue tracker is just hilarious. [05:59] huwshimi: Are the desired colours shown somewhere? [05:59] wgrant: Not that I know of [06:00] wgrant: I have some hex codes [06:00] Do their values map reasonably well onto ours? [06:01] wgrant: Yeah, let me grab a screenshot [06:02] poolie: What do you think of the general prominence of the importance? [06:02] poolie: It seems like it's massively emphasised over the status. [06:02] When the status is possibly more important. [06:03] i find the stacked layout kind of hard to scan [06:03] especially because the colors overlap [06:03] Yeah, that's a worry. [06:03] wgrant: http://people.canonical.com/~huwshimi/status_colours.png [06:03] But maybe that's less important once we have good sorting and filtering. [06:03] huwshimi: Hmmmmmmmmm. [06:03] i think we ought to ask: why are we showing this at all [06:03] what kind of thing do people do with this information [06:04] ... [06:04] "oh, that's new/untriaged, i'll go and do it now" [06:04] Entirely desaturating the status was not the solution I had in mind. [06:04] Sort of the opposite :) [06:04] The importance is really more like a tag, IME. [06:04] "of the bugs with this tag, 2 are in progress, 3 fixed, 3 triaged" [06:04] An unimportant tag. [06:05] i think also whether projects accept it or not, there's "critical, high, other" [06:05] oh, and null [06:05] Yep. [06:05] i do wonder if the scale should reflect that by having nonlinear differences in color - http://people.canonical.com/~huwshimi/status_colours.png is a bit better in that respect but not quite there [06:06] Yeah. [06:06] "Other" is split. [06:06] But it's clearly separate from Critical and High. [06:06] By being cooler. [06:06] so i would have eg "red, orange, yellow, faded yellow, dull yellow" [06:06] The colours in that are much more subtle, too. [06:06] Much better. [06:07] The blocks of colour also look pretty odd next to our detailed icons, I think. [06:08] i do generally like the colors [06:08] i think [06:08] It's all pretty simple and not busy, but then you get to these variously-coloured outlined detailed icons :( [06:08] the statuses are less jarring because they are not colored at all [06:08] * wgrant campaigns for monochrome icons. [06:08] Yeah. [06:09] but it seems based on an assumption that the importance is much more salient than the status [06:09] which i don't think is true [06:09] Indeed. [06:09] ... and again that should probably come out of a theory about what people use this information for [06:09] Well. [06:09] It really depends. [06:09] Depending on the filter. [06:09] i don't think it's universally true [06:09] right [06:09] eg. we by default filter to open bugs. [06:09] yeah [06:10] you know i'd really like the filters to start having an overridable opinion about what you're using that filter for [06:10] eg inprogress should show you to whom they're assigned [06:10] But it's still useful to distinguish between those that are untriaged (although they would have NULL importance), those that can be worked on, and those that are being worked, and those that are fixed but not released. [06:10] Yeah. [06:10] So. [06:10] yes [06:10] Really the status is just noise normally. [06:10] i think it at least some uses it'd be good to highlight "in play" statuses [06:10] Everything can be distinguished from importance and assignee. [06:11] well, really just inprogress, and maybe fixcomitted [06:11] New: unset importance [06:11] Triaged: set importance [06:11] well, that too [06:11] In progress: set assignee [06:11] get rid of a few statuses [06:11] Incomplete... not sure [06:11] Fix Committed: pointless [06:11] i think incomplete is an orthogonal bit [06:11] Yeah. [06:12] "needs more input", ie developers can't work on it (and it will eventually expire) if an affected user doesn't provide more info [06:12] I've thought about abolishing status for issuetracker. [06:12] i think this works pretty well in answers [06:12] invalid/wontfix/opinion are all one status [06:13] fixcommitted is largely pointless [06:13] incomplete can apply to most states, so should be separate [06:13] new is implied by there being no importance [06:13] inprogress is implied by there being an assignee [06:13] ... anyhow, one step at a time [06:13] Heh [06:13] i think one good thing huw's retheme can hopefully do is provide a consistency about where color is used and how much [06:13] Yeah. [06:14] huwshimi: Do you have plans for our iconset? [06:14] i would hope it says it's used for important things [06:14] kill the goddamn pencil [06:14] wgrant: Yeah, I have plans to redesign it. [06:14] The pencil was scheduled for demolition 2.5 years ago :) [06:14] huwshimi: Excellent. [06:15] wgrant: I haven't done much work on it yet, but it's probably going to be monochrome [06:15] Eeeexcellent. [06:15] wgrant: At least in the current mockups it has been [06:15] grey plus purple anyhow [06:16] ok, so I see the new delete task feature, but I'm not sure, if I delete a default task, does that remove the targetted tasks as well or do I have to target the devel release to delete the default task or is there still no way to delete the default task? [06:17] micahg: You can delete any task individually, as long as at least one task is left on the bug. [06:17] micahg: This does mean that you can have eg. a linux (Ubuntu Lucid) task without a linux (Ubuntu) task. [06:17] right, but like in bug 887339, I don't need the default tasks, but I need the targetted ones [06:17] <_mup_> Bug #887339: Tracking bug for Firefox 8 transition < https://la [06:17] I would discourage deleting them. [06:18] The parent target will still appear, see eg. bug #1234 [06:18] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts < https://launchpad.net/bugs/1234 > [06:18] Er. [06:18] Not that. [06:18] Bug #43150 [06:18] <_mup_> Bug #43150: [SRU] maxima frontends fail to connect < https://launchpad.net/bugs/43150 > [06:18] The parent targets without tasks are still shown in the table. [06:19] Task deletion exists mostly to remove projects that shouldn't be on bugs. [06:19] It's not intended for what you suggest, though it will mostly work. [06:20] right, that's what I'm thinking, to look something like that bug [06:20] but if it's not advised, I'll leave it [06:20] (that bug was never intended to be like that, but it ended up being somewhat broken when series tasks were reworked in 2007) === spm changed the topic of #launchpad-dev to: qas/staging down | https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugtasks: 275 === StevenK changed the topic of #launchpad-dev to: qas/staging down | https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 275 [06:58] StevenK: oh crap, completely forgot to OCR today. I'll just join you. === jtv changed the topic of #launchpad-dev to: qas/staging down | https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugtasks: 275 [06:58] Or not join me [06:59] Well, replace you. [06:59] Or something. [06:59] I sit replaced. === spm changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugtasks: 275 [07:25] morning rvba [07:25] \o jtv! [07:28] hi rvba, jtv [07:28] Hello poolie. [08:10] so when launchpad runs its tests against the external buildd code [08:10] it will need a copy of that [08:12] poolie: Probably best to put it in sourcecode/ for now. [08:12] ok [08:13] yeah it would be a bit weird to make it an egg [08:17] hi poolie — back from getting some stuff [08:18] wgrant: any objections to a dogfood update? [08:18] jtv: Go ahead. [08:18] thx [08:23] package name 'launchpad_buildd' or 'launchpadbuildd' or 'lpbuildd'? [08:23] maybe the last [08:37] Just heading out, but a branch for someone who is generous enough: https://code.launchpad.net/~huwshimi/launchpad/tag-cloud-removal-709009/+merge/81689 [09:03] Morning all [09:04] Hello [09:07] good morning [09:10] I think this is one of those rare cases where I need full tracebacks from test errors. Anyone know how I get the full traceback instead of the normal abridged one? [09:16] jtv: it's a bit tricky. [09:17] jtv: try decorating the test with @run_test_with(FullStackRunTest) [09:17] That doesn't sound too tricky! [09:17] jtv: from testtools import run_test_with; from testtools.tests.helpers import FullStackRunTest [09:17] Thanks. [09:17] jtv: it won't give you the full stack though, it'll just reveal the testtools-specific stuff [09:18] We'll see how far it gets me. [09:18] jtv: bug 881778 and bug 881780 have been filed already on testtools and are my next thing to do for it. [09:18] <_mup_> Bug #881778: frame hiding cannot be disabled, interferes with debugging < https://launchpad.net/bugs/881778 > [09:18] <_mup_> Bug #881780: no way to transiently disable frame hiding < https://launchpad.net/bugs/881780 > [09:19] Alas, it didn't do the trick. [09:19] jtv: did it not work at all? [09:19] Actually, the "traceback" consists of _only_ the exception description. I've been assuming that that was just because the abridgment eliminated the whole thing, but perhaps there's some other way that could happen? [09:20] Traceback (most recent call last): [09:20] DNSLookupError: DNS lookup failed: [09:20] Just those two lines. [09:35] can someone have a squiz at https://code.launchpad.net/~mbp/launchpad-buildd/rename-package/+merge/81692 [09:36] poolie: after my standup, sure [10:29] jtv: Little review? https://code.launchpad.net/~allenap/launchpad/bug-export-schema/+merge/81699 [10:31] allenap: otp; would half an hour be OK? [10:31] jtv: Absolutely, it's not urgent. [10:31] Thanks. [10:31] cool [10:56] hey, diffs seem to be taking a long time to generate. [10:57] since posting my MP, I've gone downstairs & filled up a bottle of water, greeted the postman (not a euphemism), and then put a bunch of cardboard boxes in the loft. Still no diff. [10:58] jml: single threaded, possibly behind something big. [10:59] that would be a great euphemism though [10:59] jml: your bug about reviews [10:59] jml: isn't https://code.launchpad.net/~lifeless/+activereviews roughly the view you ask for ? [11:02] ooh, it was jml that asked for this at the launchpad session? [11:02] lifeless: NICE! [11:04] lifeless: I maybe seeing a regression. On the project page now it doesn't show the different categories "Reviews I'm waiting", "Reviews I can do", etc [11:05] https://code.launchpad.net/launchpad-project/+activereviews [11:05] does for me [11:05] what the.... [11:05] it didn't work 2 minutes ago. [11:07] It picks every review I'm associated with. Like. [11:07] check the url [11:07] bet you there is a difference [11:07] Probably my mistake [11:07] Anyway, this is nice :) [11:07] e.g. +reviews vs +activereviews [11:07] or something [11:08] lifeless: no. [11:09] lifeless: or rather, it's close, but I want reviews that aren't assigned to me to appear on it. If you submit an MP to, say, it won't show up on my page. [11:10] "Reviews I *can* do" [11:10] well [11:10] yes. although there's a lot of those :) [11:10] heh [11:10] restricting it to projects I'm interested in would be nice. [11:12] allenap: you're done. [11:12] jtv: Thanks. [11:16] jml: so, I think it just needs a way to say 'I may be a reviewer for X, but I don't care about it'. [11:16] jml: one way is to not be in the reviewer team for X. [11:16] uhh... no? [11:16] well, depends on what "it" is there [11:17] so, +activereviews shows reviews that aren't assigned to you. The heuristics is that they are on a branch you are in the review team for. [11:17] what you said above was '00:09 < jml> lifeless: or rather, it's close, but I want reviews that aren't assigned to me to appear on it. If you submit an MP to, say, it won't show up on my page. [11:17] lifeless: no, it doesn't. [11:17] ' [11:17] and then '00:10 < jml> restricting it to projects I'm interested in would be nice. [11:18]