| wgrant | Ooh. | 02:17 |
|---|---|---|
| wgrant | The new bug listings are mostly nice. | 02:17 |
| === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugtasks: 275 | ||
| wallyworld_ | StevenK: you working on 884217? | 02:28 |
| StevenK | wallyworld_: I have a branch for it | 02:30 |
| wallyworld_ | 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 |
| wallyworld_ | so if the team name needs to be displayed because the team is a bug subscriber, then the context would be the bug | 02:31 |
| wallyworld_ | these rules would replace any current security adaptor for private team visibility | 02:32 |
| StevenK | I think we only have the TAL formatter | 02:32 |
| wallyworld_ | StevenK: so i wanted to be sure that we weren't going to do the same thing etc | 02:32 |
| StevenK | Which returns <hidden> and soft OOPSes a MixedVisibilityError | 02:33 |
| wallyworld_ | i'll need to dig around and see what needs to be done | 02:33 |
| wallyworld_ | to fix it | 02:33 |
| wallyworld_ | but i think the above sounds ok? | 02:34 |
| jtv1 | StevenK: [BS]PPH.{binary,source}packagename have been fully populated now? | 02:58 |
| === jtv1 is now known as jtv | ||
| bac | hi, lifeless, sorry i had to run | 02:59 |
| StevenK | jtv: Not even close. | 02:59 |
| jtv | Oh. | 02:59 |
| jtv | Damn Raphaël and his clever ideas. | 02:59 |
| bac | lifeless: the tests that actually failed are those that use the helper, such as testBadUrlBzrSshCaught | 02:59 |
| jtv | StevenK: I guess you'll add not-null constraints when done. | 03:00 |
| bac | 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 |
| jtv | hi bac :) | 03:00 |
| bac | hi jtv | 03:00 |
| StevenK | 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 |
| lifeless | bac: thats very unusual then isn't it! | 03:00 |
| bac | lifeless: yeppers | 03:01 |
| lifeless | bac: uhm, I'm not entirely here today; can you drop me a mail and I will look first thing tomorrow ? | 03:01 |
| jtv | StevenK: ironic, since I was also hoping to use the column to speed up the publisher. | 03:01 |
| bac | lifeless: sure. thanks. | 03:01 |
| bac | jtv: staying dry? | 03:01 |
| jtv | 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 |
| jtv | The hip new word is revacuee. | 03:02 |
| jtv | StevenK: perhaps there's more we can do to break up those long-running publisher transactions? | 03:41 |
| StevenK | Fixing the dominator would be one, I think. | 03:47 |
| jtv | Catch 22. | 03:50 |
| jtv | StevenK: the updater code looks like it's probably slower than necessary. | 03:51 |
| StevenK | jtv: You need my denorm work to make the dominator faster? | 03:52 |
| jtv | 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:53 |
| jtv | Some things that I think would speed up the updater: | 03:54 |
| jtv | * Don't order by id. | 03:54 |
| jtv | * Bulk-load the [BS]PRs. | 03:54 |
| jtv | * Don't load the [BS]PNs at all—all you need is their ids. | 03:55 |
| jtv | * More radical: don't load anything, just let the DB do the work. | 03:55 |
| poolie | is this change to block reopening fixreleased bugs new? | 03:57 |
| jtv | poolie: EWIN? | 03:58 |
| poolie | no | 03:58 |
| wgrant | poolie: It's at least several months old. | 03:58 |
| wgrant | Maybe even a year now. | 03:58 |
| poolie | perhaps i just never hit it | 03:58 |
| wgrant | poolie: The reporter and bug supervisor can reopen. | 03:59 |
| wgrant | But not eg. the assignee. | 03:59 |
| poolie | hm | 03:59 |
| poolie | i guess i'm not a supervisor for bzr-svn | 04:00 |
| poolie | :/ | 04:00 |
| wgrant | Indeed. | 04:01 |
| wgrant | That's ~bzr-svn, which has only three real members. | 04:01 |
| poolie | ffs | 04:02 |
| poolie | i see, i thought it changed recently because robert just answered a year-old question about it | 04:04 |
| poolie | wgrant, StevenK, lifeless, what are we going to do with https://code.launchpad.net/~vorlon/launchpad/sbuild-multiarch-syntax/+merge/81385 ? | 04:17 |
| wgrant | poolie: Land it. | 04:18 |
| poolie | *hug* | 04:18 |
| wgrant | poolie: Don't add [no-qa] to the commit message. | 04:22 |
| wgrant | Rather use bzr lp-land --no-qa | 04:22 |
| wgrant | Or ec2 land --no-qa | 04:22 |
| wgrant | That adds it automatically. | 04:22 |
| wgrant | And hopefully avoids confusing things. | 04:22 |
| poolie | ok | 04:24 |
| poolie | i wonder if there is a bug for it | 04:24 |
| wgrant | I don't think so. I've discussed it with various people in person, but I don't recall a bug. | 04:25 |
| poolie | not obviously | 04:25 |
| poolie | and it's out-of-band qa anyhow | 04:25 |
| micahg | poolie: I think we have security builds going for the next 9 hours | 04:26 |
| micahg | eh, semi-wrong channel, meh | 04:27 |
| wgrant | Hah. | 04:39 |
| wgrant | There's no UNIQUE bugsubscription(bug, person) | 04:39 |
| StevenK | The UI forbids it, though? | 04:40 |
| wgrant | Probably mostly. | 04:41 |
| wgrant | poolie: Not going to make that bug Critical+regression? :) | 04:41 |
| poolie | i guess i could | 04:41 |
| poolie | rebooting | 04:42 |
| nigelb | jamesh: Hi, around? | 04:47 |
| nigelb | Ah, its lunch time in Perth. | 04:54 |
| jamesh | nigelb: hi | 05:02 |
| nigelb | jamesh: Hey, are you the James listed as Uploader on PyPI for django-openid-auth? :) | 05:06 |
| jamesh | nigelb: yeah | 05:06 |
| nigelb | 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:06 |
| nigelb | It was fun tracking that down, pip search django-openid-auth says 0.4 is latest, but installing doesn't work. | 05:08 |
| jamesh | nigelb: ah. I didn't actually roll the 0.4 release (achuni handled it, iirc) | 05:08 |
| nigelb | jamesh: ah. I couldn't find achuni on IRC, so I thought best to let you know :) | 05:09 |
| jamesh | nigelb: could you file a bug about it so we don't mess it up for 0.5? | 05:09 |
| nigelb | cool, will do. Is there a way to fix 0.4? | 05:10 |
| jamesh | nigelb: I don't really use pip. Where is the error occurring? | 05:12 |
| nigelb | jamesh: let me get you a pastebin | 05:12 |
| nigelb | jamesh: http://paste.ubuntu.com/732749/ | 05:14 |
| nigelb | Hrm. I guess I could try installing _0.4 | 05:14 |
| nigelb | Nope, didn't work. | 05:15 |
| jamesh | nigelb: anything relevant in the log file that paste mentions? | 05:16 |
| nigelb | yup | 05:16 |
| nigelb | sec | 05:16 |
| nigelb | jamesh: http://paste.ubuntu.com/732755/ | 05:18 |
| jamesh | 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:19 |
| jamesh | checking that here, I get "303 See Other" response pointing at the file in the librarian | 05:20 |
| nigelb | Oh. | 05:20 |
| nigelb | That is weird. | 05:20 |
| wgrant | stub1: around? | 05:22 |
| poolie | i think i will build a package of the buildd stuff now just to test | 05:25 |
| poolie | and then do an update after vorlon's stuff lands | 05:25 |
| wgrant | poolie: Sounds good. | 05:26 |
| nigelb | 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 <django-openid-auth:New> < https://launchpad.net/bugs/887882 > | 05:27 |
| huwshimi | 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 |
| jamesh | nigelb: thanks | 05:30 |
| nigelb | :) | 05:31 |
| wgrant | huwshimi: Join https://qastaging.launchpad.net/~custom-buglisting-demo (it's Open) and you'll see them on qas. | 05:31 |
| nigelb | oooh. | 05:33 |
| poolie | hi nigelb | 05:33 |
| poolie | wgrant, only qas for now? | 05:34 |
| nigelb | Afternoon poolie :) | 05:34 |
| huwshimi | wgrant: Ah, perfect, thanks | 05:34 |
| stub1 | wgrant: yo | 05:35 |
| === stub1 is now known as stub | ||
| wgrant | poolie: Yes. | 05:35 |
| nigelb | zomg. Can't wait. custom bug listings is *amazing* | 05:35 |
| wgrant | 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 |
| wgrant | This seems to be because it always does a seq scan on accesspolicygrant. | 05:38 |
| wgrant | Rather than indexing into it. | 05:38 |
| wgrant | Can't work out why. | 05:38 |
| wgrant | http://paste.ubuntu.com/732768/ is the setup and some sample queries. | 05:38 |
| wgrant | The third query (one CTE and some subselects) is the fastest for Ubuntu. The others sit at 1-1.5s. | 05:40 |
| wgrant | But I can't get it to not seq scan apg. | 05:40 |
| poolie | that is nice | 05:40 |
| poolie | i wish the colors were better chosen though | 05:40 |
| wgrant | poolie: What in particular? | 05:40 |
| wgrant | I think Low should not be bold and black. | 05:41 |
| poolie | i agree | 05:41 |
| poolie | i would like the importance things to be on one spectrum, so their ordering is reflected in the colors | 05:41 |
| wgrant | Yeah. | 05:41 |
| poolie | and i think i would like them not to overlap with the status colors | 05:42 |
| wgrant | They're the same as they are now. | 05:42 |
| poolie | huwshimi, what do you think? | 05:42 |
| poolie | i like incremental changes | 05:42 |
| wgrant | Red/Orange/Yellow... Black/Blue | 05:42 |
| poolie | but for things like this it seems like it would be a shame not to make a better splash | 05:42 |
| wgrant | Hmm. | 05:42 |
| wgrant | Actually. | 05:42 |
| wgrant | They're the same as the current *text* colours. | 05:42 |
| wgrant | Which is Red/Orange/Green/Black/Blue. | 05:43 |
| huwshimi | wgrant, poolie: We actually have a set of colours that the design team use for statuses | 05:43 |
| poolie | i wonder if that icon next to the product name is really earning its keep | 05:43 |
| huwshimi | wgrant, poolie: I haven't seen this black before | 05:43 |
| wgrant | Rather than the icons, which are Red/Reddish/Orange/Yellow/Blue | 05:44 |
| wgrant | Which probably makes more sense. | 05:44 |
| wgrant | Except for Yellow being yellow. | 05:44 |
| wgrant | Which is a bit ew. | 05:44 |
| poolie | huwshimi, and are these colors on qas the official colors? | 05:45 |
| huwshimi | poolie: Nope | 05:45 |
| poolie | i guess specifically 'medium' has a very bold green which is more saturated (to my eye) than High | 05:45 |
| poolie | and Low even more so | 05:45 |
| poolie | and Wishlist too | 05:45 |
| poolie | :) | 05:45 |
| wgrant | Yeah, Medium and Low are really obvious. | 05:45 |
| huwshimi | poolie: I believe these are the same colours we used to have, with the exception of the black | 05:46 |
| poolie | i think that's true | 05:46 |
| wgrant | Particularly since High/Critical are the same colour as Triaged, which is the usual status for bugs with an importance. | 05:46 |
| wgrant | So there's no contrast. | 05:46 |
| huwshimi | wgrant: I had thought the status colours were going to be removed | 05:46 |
| wgrant | Hmm, interesting. | 05:46 |
| poolie | also the small caps importance next to the regular status is a little jarring | 05:47 |
| huwshimi | It's been a long time since I've seen this work and clearly I need to do a proper review | 05:47 |
| poolie | and they are oddly aligned | 05:47 |
| wgrant | There was a bug filed overnight about Fix Committed looking like an ajax link. | 05:47 |
| poolie | 'ajax link' :) | 05:47 |
| wgrant | Bug #887576 | 05:47 |
| _mup_ | Bug #887576: new bug listing importance is difficult to read <bug-columns> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/887576 > | 05:47 |
| wgrant | Bug #887575 | 05:47 |
| _mup_ | Bug #887575: fix released and fix committed status color in new bug listing look like ajax action links <bug-columns> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/887575 > | 05:47 |
| wgrant | Interestingly, the first bug's title mentions importance, but description says status. | 05:48 |
| wgrant | Hmm. | 05:52 |
| wgrant | GitHub's status styleing on the issue page itself is suspiciously similar to our new listings' importance styling. | 05:52 |
| poolie | wgrant, yeah, and unfortunately there is a bit more logic to them styling them that way | 05:53 |
| wgrant | Yes. | 05:53 |
| poolie | which is that they are tag-type things that can be dragged around | 05:53 |
| wgrant | Well, labels are separate, but all the category-related things seem to be styled like that. | 05:57 |
| wgrant | Labels, statuses, filters. | 05:57 |
| wgrant | And Google Code's issue tracker is just hilarious. | 05:58 |
| wgrant | huwshimi: Are the desired colours shown somewhere? | 05:59 |
| huwshimi | wgrant: Not that I know of | 05:59 |
| huwshimi | wgrant: I have some hex codes | 06:00 |
| wgrant | Do their values map reasonably well onto ours? | 06:00 |
| huwshimi | wgrant: Yeah, let me grab a screenshot | 06:01 |
| wgrant | poolie: What do you think of the general prominence of the importance? | 06:02 |
| wgrant | poolie: It seems like it's massively emphasised over the status. | 06:02 |
| wgrant | When the status is possibly more important. | 06:02 |
| poolie | i find the stacked layout kind of hard to scan | 06:03 |
| poolie | especially because the colors overlap | 06:03 |
| wgrant | Yeah, that's a worry. | 06:03 |
| huwshimi | wgrant: http://people.canonical.com/~huwshimi/status_colours.png | 06:03 |
| wgrant | But maybe that's less important once we have good sorting and filtering. | 06:03 |
| wgrant | huwshimi: Hmmmmmmmmm. | 06:03 |
| poolie | i think we ought to ask: why are we showing this at all | 06:03 |
| poolie | what kind of thing do people do with this information | 06:03 |
| poolie | ... | 06:04 |
| poolie | "oh, that's new/untriaged, i'll go and do it now" | 06:04 |
| wgrant | Entirely desaturating the status was not the solution I had in mind. | 06:04 |
| wgrant | Sort of the opposite :) | 06:04 |
| wgrant | The importance is really more like a tag, IME. | 06:04 |
| poolie | "of the bugs with this tag, 2 are in progress, 3 fixed, 3 triaged" | 06:04 |
| wgrant | An unimportant tag. | 06:04 |
| poolie | i think also whether projects accept it or not, there's "critical, high, other" | 06:05 |
| poolie | oh, and null | 06:05 |
| wgrant | Yep. | 06:05 |
| poolie | 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:05 |
| wgrant | Yeah. | 06:06 |
| wgrant | "Other" is split. | 06:06 |
| wgrant | But it's clearly separate from Critical and High. | 06:06 |
| wgrant | By being cooler. | 06:06 |
| poolie | so i would have eg "red, orange, yellow, faded yellow, dull yellow" | 06:06 |
| wgrant | The colours in that are much more subtle, too. | 06:06 |
| wgrant | Much better. | 06:06 |
| wgrant | The blocks of colour also look pretty odd next to our detailed icons, I think. | 06:07 |
| poolie | i do generally like the colors | 06:08 |
| poolie | i think | 06:08 |
| wgrant | It's all pretty simple and not busy, but then you get to these variously-coloured outlined detailed icons :( | 06:08 |
| poolie | the statuses are less jarring because they are not colored at all | 06:08 |
| * wgrant campaigns for monochrome icons. | 06:08 | |
| wgrant | Yeah. | 06:08 |
| poolie | but it seems based on an assumption that the importance is much more salient than the status | 06:09 |
| poolie | which i don't think is true | 06:09 |
| wgrant | Indeed. | 06:09 |
| poolie | ... and again that should probably come out of a theory about what people use this information for | 06:09 |
| wgrant | Well. | 06:09 |
| wgrant | It really depends. | 06:09 |
| wgrant | Depending on the filter. | 06:09 |
| poolie | i don't think it's universally true | 06:09 |
| poolie | right | 06:09 |
| wgrant | eg. we by default filter to open bugs. | 06:09 |
| poolie | yeah | 06:09 |
| poolie | you know i'd really like the filters to start having an overridable opinion about what you're using that filter for | 06:10 |
| poolie | eg inprogress should show you to whom they're assigned | 06:10 |
| wgrant | 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 |
| wgrant | Yeah. | 06:10 |
| wgrant | So. | 06:10 |
| poolie | yes | 06:10 |
| wgrant | Really the status is just noise normally. | 06:10 |
| poolie | i think it at least some uses it'd be good to highlight "in play" statuses | 06:10 |
| wgrant | Everything can be distinguished from importance and assignee. | 06:10 |
| poolie | well, really just inprogress, and maybe fixcomitted | 06:11 |
| wgrant | New: unset importance | 06:11 |
| wgrant | Triaged: set importance | 06:11 |
| poolie | well, that too | 06:11 |
| wgrant | In progress: set assignee | 06:11 |
| poolie | get rid of a few statuses | 06:11 |
| wgrant | Incomplete... not sure | 06:11 |
| wgrant | Fix Committed: pointless | 06:11 |
| poolie | i think incomplete is an orthogonal bit | 06:11 |
| wgrant | Yeah. | 06:11 |
| poolie | "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 |
| wgrant | I've thought about abolishing status for issuetracker. | 06:12 |
| poolie | i think this works pretty well in answers | 06:12 |
| wgrant | invalid/wontfix/opinion are all one status | 06:12 |
| wgrant | fixcommitted is largely pointless | 06:13 |
| wgrant | incomplete can apply to most states, so should be separate | 06:13 |
| wgrant | new is implied by there being no importance | 06:13 |
| wgrant | inprogress is implied by there being an assignee | 06:13 |
| poolie | ... anyhow, one step at a time | 06:13 |
| wgrant | Heh | 06:13 |
| poolie | 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 |
| wgrant | Yeah. | 06:13 |
| wgrant | huwshimi: Do you have plans for our iconset? | 06:14 |
| poolie | i would hope it says it's used for important things | 06:14 |
| poolie | kill the goddamn pencil | 06:14 |
| huwshimi | wgrant: Yeah, I have plans to redesign it. | 06:14 |
| wgrant | The pencil was scheduled for demolition 2.5 years ago :) | 06:14 |
| wgrant | huwshimi: Excellent. | 06:14 |
| huwshimi | wgrant: I haven't done much work on it yet, but it's probably going to be monochrome | 06:15 |
| wgrant | Eeeexcellent. | 06:15 |
| huwshimi | wgrant: At least in the current mockups it has been | 06:15 |
| poolie | grey plus purple anyhow | 06:15 |
| micahg | 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:16 |
| wgrant | micahg: You can delete any task individually, as long as at least one task is left on the bug. | 06:17 |
| wgrant | micahg: This does mean that you can have eg. a linux (Ubuntu Lucid) task without a linux (Ubuntu) task. | 06:17 |
| micahg | 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 <firefox (Ubuntu):Invalid> <mozvoikko (Ubuntu):Invalid> <ubufox (Ubuntu):Invalid> <firefox (Ubuntu Natty):Fix Committed by micahg> <mozvoikko (Ubuntu Natty):Fix Committed by micahg> <ubufox (Ubuntu Natty):Fix Committed by micahg> <firefox (Ubuntu Oneiric):Fix Committed by micahg> <mozvoikko (Ubuntu Oneiric):Fix Committed by micahg> <ubufox (Ubuntu Oneiric):Fix Committed by micahg> < https://la | 06:17 |
| wgrant | I would discourage deleting them. | 06:17 |
| wgrant | 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 <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 > | 06:18 |
| wgrant | Er. | 06:18 |
| wgrant | Not that. | 06:18 |
| wgrant | Bug #43150 | 06:18 |
| _mup_ | Bug #43150: [SRU] maxima frontends fail to connect <wxmaxima (Ubuntu):Fix Released> <gcl (Ubuntu Dapper):Fix Released by wgrant> <maxima (Ubuntu Dapper):Fix Released> < https://launchpad.net/bugs/43150 > | 06:18 |
| wgrant | The parent targets without tasks are still shown in the table. | 06:18 |
| wgrant | Task deletion exists mostly to remove projects that shouldn't be on bugs. | 06:19 |
| wgrant | It's not intended for what you suggest, though it will mostly work. | 06:19 |
| micahg | right, that's what I'm thinking, to look something like that bug | 06:20 |
| micahg | but if it's not advised, I'll leave it | 06:20 |
| wgrant | (that bug was never intended to be like that, but it ended up being somewhat broken when series tasks were reworked in 2007) | 06:20 |
| === 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 | ||
| jtv | StevenK: oh crap, completely forgot to OCR today. I'll just join you. | 06:58 |
| === jtv changed the topic of #launchpad-dev to: qas/staging down | https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugtasks: 275 | ||
| StevenK | Or not join me | 06:58 |
| jtv | Well, replace you. | 06:59 |
| jtv | Or something. | 06:59 |
| StevenK | I sit replaced. | 06:59 |
| === spm changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugtasks: 275 | ||
| jtv | morning rvba | 07:25 |
| rvba | \o jtv! | 07:25 |
| poolie | hi rvba, jtv | 07:28 |
| rvba | Hello poolie. | 07:28 |
| poolie | so when launchpad runs its tests against the external buildd code | 08:10 |
| poolie | it will need a copy of that | 08:10 |
| wgrant | poolie: Probably best to put it in sourcecode/ for now. | 08:12 |
| poolie | ok | 08:12 |
| poolie | yeah it would be a bit weird to make it an egg | 08:13 |
| jtv | hi poolie — back from getting some stuff | 08:17 |
| jtv | wgrant: any objections to a dogfood update? | 08:18 |
| wgrant | jtv: Go ahead. | 08:18 |
| jtv | thx | 08:18 |
| poolie | package name 'launchpad_buildd' or 'launchpadbuildd' or 'lpbuildd'? | 08:23 |
| poolie | maybe the last | 08:23 |
| huwshimi | Just heading out, but a branch for someone who is generous enough: https://code.launchpad.net/~huwshimi/launchpad/tag-cloud-removal-709009/+merge/81689 | 08:37 |
| danhg | Morning all | 09:03 |
| mrevell | Hello | 09:04 |
| adeuring | good morning | 09:07 |
| jtv | 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:10 |
| jml | jtv: it's a bit tricky. | 09:16 |
| jml | jtv: try decorating the test with @run_test_with(FullStackRunTest) | 09:17 |
| jtv | That doesn't sound too tricky! | 09:17 |
| jml | jtv: from testtools import run_test_with; from testtools.tests.helpers import FullStackRunTest | 09:17 |
| jtv | Thanks. | 09:17 |
| jml | jtv: it won't give you the full stack though, it'll just reveal the testtools-specific stuff | 09:17 |
| jtv | We'll see how far it gets me. | 09:18 |
| jml | 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 <regression> <traceback> <testtools:Triaged> < https://launchpad.net/bugs/881778 > | 09:18 |
| _mup_ | Bug #881780: no way to transiently disable frame hiding <traceback> <testtools:Triaged> < https://launchpad.net/bugs/881780 > | 09:18 |
| jtv | Alas, it didn't do the trick. | 09:19 |
| jml | jtv: did it not work at all? | 09:19 |
| jtv | 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:19 |
| jtv | Traceback (most recent call last): | 09:20 |
| jtv | DNSLookupError: DNS lookup failed: <etc.> | 09:20 |
| jtv | Just those two lines. | 09:20 |
| poolie | can someone have a squiz at https://code.launchpad.net/~mbp/launchpad-buildd/rename-package/+merge/81692 | 09:35 |
| jtv | poolie: after my standup, sure | 09:36 |
| allenap | jtv: Little review? https://code.launchpad.net/~allenap/launchpad/bug-export-schema/+merge/81699 | 10:29 |
| jtv | allenap: otp; would half an hour be OK? | 10:31 |
| allenap | jtv: Absolutely, it's not urgent. | 10:31 |
| allenap | Thanks. | 10:31 |
| jtv | cool | 10:31 |
| jml | hey, diffs seem to be taking a long time to generate. | 10:56 |
| jml | 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:57 |
| lifeless | jml: single threaded, possibly behind something big. | 10:58 |
| bigjools | that would be a great euphemism though | 10:59 |
| lifeless | jml: your bug about reviews | 10:59 |
| lifeless | jml: isn't https://code.launchpad.net/~lifeless/+activereviews roughly the view you ask for ? | 10:59 |
| nigelb | ooh, it was jml that asked for this at the launchpad session? | 11:02 |
| nigelb | lifeless: NICE! | 11:02 |
| nigelb | 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:04 |
| lifeless | https://code.launchpad.net/launchpad-project/+activereviews | 11:05 |
| lifeless | does for me | 11:05 |
| nigelb | what the.... | 11:05 |
| nigelb | it didn't work 2 minutes ago. | 11:05 |
| nigelb | It picks every review I'm associated with. Like. | 11:07 |
| lifeless | check the url | 11:07 |
| lifeless | bet you there is a difference | 11:07 |
| nigelb | Probably my mistake | 11:07 |
| nigelb | Anyway, this is nice :) | 11:07 |
| lifeless | e.g. +reviews vs +activereviews | 11:07 |
| lifeless | or something | 11:07 |
| jml | lifeless: no. | 11:08 |
| 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:09 |
| nigelb | "Reviews I *can* do" | 11:10 |
| jml | well | 11:10 |
| jml | yes. although there's a lot of those :) | 11:10 |
| nigelb | heh | 11:10 |
| jml | restricting it to projects I'm interested in would be nice. | 11:10 |
| jtv | allenap: you're done. | 11:12 |
| allenap | jtv: Thanks. | 11:12 |
| lifeless | 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 |
| lifeless | jml: one way is to not be in the reviewer team for X. | 11:16 |
| jml | uhh... no? | 11:16 |
| jml | well, depends on what "it" is there | 11:16 |
| lifeless | 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 |
| lifeless | 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 |
| jml | lifeless: no, it doesn't. | 11:17 |
| lifeless | ' | 11:17 |
| lifeless | and then '00:10 < jml> restricting it to projects I'm interested in would be nice. | 11:17 |
| lifeless | jml: are you saying you want proposals that you're not an authoritative reviewer for to show up as well? | 11:18 |
| jml | lifeless: "as well" is wrong. Person/+activereviews does not show reviews that aren't assigned to me. e.g. kampka's review on https://code.launchpad.net/testtools/+activereviews isn't shown on https://code.launchpad.net/~jml/+activereviews | 11:19 |
| lifeless | jml: ah, or are you saying that 'reviews I can do' doesn't show up on your ~ +activereviews? | 11:19 |
| lifeless | jml: This may be shallow. Thanks for helping me understand. | 11:20 |
| jml | lifeless: yes, that's what I'm saying. That was the intended behaviour of the page when thumper made it. | 11:20 |
| jml | tbh, if suddenly there was a "Reviews I can do" section, I'd want it grouped by project. | 11:20 |
| jml | lifeless: np | 11:20 |
| jml | another slow diff generation :\ | 11:23 |
| lifeless | jml: naturally | 11:23 |
| lifeless | jml: would you care to note this in the bug ? | 11:23 |
| jml | lifeless: done | 11:30 |
| lifeless | thhanks | 11:34 |
| === matsubara-afk is now known as matsubara | ||
| StevenK | jtv: Are you still OCR, or are you EOD? | 12:09 |
| jtv | StevenK: sort of eod tbh | 12:15 |
| jtv | But! | 12:15 |
| jtv | If your branch isn't too big I can trade you a speedup for the [BS]PPH.{source,binary}packagename populators. | 12:16 |
| === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 275 | ||
| StevenK | In the garbo job? | 12:16 |
| jtv | Yes | 12:16 |
| StevenK | jtv: Problem is, my branch isn't done yet. | 12:16 |
| jtv | Well that'd put a bit of a crimp on it. | 12:16 |
| StevenK | A bit, yes | 12:21 |
| jtv | bigjools: about a minute and a half — still seems to do the usual stuff though | 12:36 |
| StevenK | jtv: Are you still up for that MP swap? | 13:04 |
| deryck | Hi, all. | 14:02 |
| flacoste | hi deryck! | 14:12 |
| deryck | adeuring, ping for standup | 14:30 |
| adeuring | deryck: oops, starting mumble now. sorry | 14:31 |
| deryck | np | 14:31 |
| sinzui | I believe there are 3 private new bugs in Launchpad that no-one can see. This has been the case for a few months | 14:45 |
| * sinzui wonders if staging can show them | 14:46 | |
| deryck | adeuring, are you working from this mockup for the beta banner? http://people.canonical.com/~deryck/beta_banner.png | 14:49 |
| adeuring | deryck: yes | 14:50 |
| deryck | adeuring, ok. And it's that blue on black that's hard to read? | 14:50 |
| adeuring | deryck: right | 14:50 |
| deryck | adeuring, do you have the transparency, too? | 14:50 |
| adeuring | deryck: yes | 14:50 |
| deryck | adeuring, ok, cool. I'd say just keep that match and point huw at the issues you see then. | 14:51 |
| adeuring | deryck: ok. BTW, I suspect that the blue colour in the mockup is simply not identical with the colour we use elsewhere for links | 14:52 |
| nigelb | Custom bug lists feature looks amazing btw | 14:52 |
| deryck | nigelb, thanks! | 14:52 |
| nigelb | :) | 14:52 |
| deryck | adeuring, that's what I was wondering. let me open in gimp and get the exact color. | 14:53 |
| * deryck thinks the Oranga Mafia are becoming design gurus | 14:53 | |
| === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugtasks: 275 | ||
| deryck | adeuring, like the gray, it's hard to pin down from mockup, but I think it's #4884EF. | 15:01 |
| adeuring | deryck: ok, I'll try it | 15:01 |
| === jtv1 is now known as jtv | ||
| abentley | deryck: could you please review https://code.launchpad.net/~abentley/launchpad/enable-anonymous-jsoncache/+merge/81741 ? (I'm the OCR) | 15:25 |
| deryck | abentley, I can. Give me 15-20 minutes to wrap up some emails for the day, and then I'll start. | 15:26 |
| abentley | deryck: thanks. | 15:26 |
| === matsubara is now known as matsubara-lunch | ||
| deryck | abentley, your MP looks great. No comments really. r=me. | 16:17 |
| abentley | deryck: thanks. | 16:18 |
| deryck | abentley, adeuring, hey look there's rick_h :) | 16:31 |
| adeuring | rick_h: welcome! | 16:31 |
| rick_h | sorry, should have thought to look for -dev a while ago | 16:32 |
| abentley | rick_h: Hi! | 16:32 |
| rick_h | howdy all | 16:32 |
| deryck | rick_h will be new Orange Mafia next week, for those who don't know. | 16:34 |
| jelmer | rick_h: welcome :) | 16:35 |
| rick_h | thanks, looking forward to it | 16:36 |
| === matsubara-lunch is now known as matsubara | ||
| rvba | welcome rick_h! | 16:36 |
| nigelb | oooh! Hello rick_h! | 16:37 |
| === beuno is now known as beuno-lunch | ||
| === deryck is now known as deryck[lunch] | ||
| timrc | danhg, welcome aboard and thanks for doing the usability sessions at UDS/P | 17:24 |
| danhg | hey, thanks tim | 17:24 |
| danhg | was great to hang out | 17:25 |
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| abentley | deryck: back, forward and reload buttons now work. | 18:04 |
| deryck | abentley, nice! | 18:05 |
| deryck | abentley, well done. | 18:05 |
| === beuno is now known as beuno-lunch | ||
| lifeless | cr3: hi | 18:53 |
| cr3 | lifeless: hola senor, what's up? | 19:03 |
| lifeless | sorry otp now ;) | 19:06 |
| cr3 | lifeless: no worries, reping me when done | 19:07 |
| === beuno-lunch is now known as beuno | ||
| lifeless | cr3: hi | 19:26 |
| lifeless | cr3: wanted to touch base on the person access api we discussed | 19:26 |
| mrevell | night all | 19:28 |
| lifeless | cr3: however I have to run in a minute now - monthly allergy vaccine injection | 19:35 |
| lifeless | cr3: will try around this time tomorrow | 19:36 |
| cr3 | lifeless: sure, looking forward to your ping tomorrow | 19:37 |
| lifeless | wallyworld_: add member should't need changing | 19:46 |
| lifeless | wallyworld_: non-open/delegated teams already prevent addition of open-delegated teams to the team. | 19:46 |
| thumper | lifeless: the reason behind avoiding having reviews I can do on the person review page was the potential amount of them | 19:57 |
| abentley | deryck: chat? | 20:27 |
| deryck | abentley, sure. | 20:27 |
| abentley | deryck: on mumble, I mean. | 20:28 |
| mwhudson | + report.get('value', 'No execption value')) | 20:31 |
| * mwhudson twitches | 20:31 | |
| bac | hi mwhudson | 20:36 |
| bac | mwhudson: you afflicted by more than the typo? | 20:42 |
| mwhudson | bac: no, just the typo | 20:42 |
| mwhudson | bac: i guess i could just fix it myself, sorry | 20:43 |
| bac | mwhudson: ok -- i'll fix it. | 20:43 |
| bac | mwhudson: turns out 'execption' occurs in our code base three times! | 20:45 |
| mwhudson | bac: hahaha | 20:45 |
| === matsubara is now known as matsubara-afk | ||
| Lifelrss | Statik: hi | 21:01 |
| mwhudson | jelmer: so if the recipe memory problems are fixed, has anyone tried a kernel build yet? :-) | 21:34 |
| jelmer | mwhudson: hmm, that'd be an interesting thing to try | 21:35 |
| mwhudson | jelmer: john rigby from linaro actually wanted to do it, too | 21:36 |
| mwhudson | ah, kernel imports don't scan correctly | 21:36 |
| mwhudson | is that going to be a problem? | 21:36 |
| jelmer | mwhudson: yeah, that might be a problem | 21:37 |
| jelmer | it seems like 2.6 imports fine though | 21:37 |
| mwhudson | ah, that's probably been around for long enough | 21:37 |
| jelmer | and I have some in-progress work to improve the scanner performance | 21:37 |
| jelmer | Branch.revision_history() is deprecated in bzr 2.5, which breaks lots of things in Launchpad, so that code will have to change anyway | 21:38 |
| mwhudson | i think it's some new-ish time restriction on how long scanner jobs run for that prevents new imports from scanning | 21:38 |
| jelmer | might as well use the new, fancy, APIs | 21:38 |
| mwhudson | jelmer: does it involve deleting BranchRevision? | 21:38 |
| jelmer | mwhudson: no | 21:38 |
| mwhudson | sad fave | 21:38 |
| mwhudson | *face | 21:38 |
| jelmer | branchrevision scares me | 21:39 |
| mwhudson | the things it does that aren't trivial to replace with bzr ops are ... i forget now | 21:39 |
| mwhudson | per project revision feeds? | 21:39 |
| mwhudson | revisioncache updates in general i guess | 21:39 |
| mwhudson | really we should have a microservice for things like "which revisions are unmerged in this mp" blah blah blah | 21:40 |
| mwhudson | jelmer: i remember that revision_history started to be bad news around when i started with canonical | 21:43 |
| mwhudson | jelmer: some things move slowly :-) | 21:43 |
| jelmer | mwhudson: the format moved away from it a long time ago | 21:46 |
| mwhudson | yeah | 21:46 |
| jelmer | mwhudson: but the API was still there | 21:46 |
| mwhudson | there was a version of knits with it and another without it? | 21:46 |
| wgrant | jelmer, mwhudson: I've had some luck with manually doing progressive scans of large new imports. | 21:55 |
| poolie | huwshimi, hi, there were a couple of things at the google event that i wanted to briefly mention with you | 22:20 |
| poolie | also thanks for fixing the tag cloud | 22:20 |
| huwshimi | poolie: :)] | 22:20 |
| StevenK | abentley: Hai, are you still up for reviewing a branch? | 22:22 |
| sinzui | wallyworld_, from canonical.launchpad.webapp.authorization import ( | 22:24 |
| sinzui | precache_permission_for_objects, | 22:24 |
| sinzui | ) | 22:24 |
| poolie | lifeless, re putting launchpad-buildd in an egg, that seemed a bit strange for something that's mostly not python, and has no python packaging at the moment | 22:30 |
| poolie | it feels more like it should be a dpkg dependency | 22:31 |
| jelmer | wgrant: that's by pushing the branch 10k or so revisions at a time? | 22:33 |
| wgrant | jelmer: Yep. | 22:34 |
| wgrant | jelmer: Sometimes much less :/ | 22:34 |
| abentley | StevenK: sorry. | 22:35 |
| === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 275 | ||
| lifeless | poolie: I want to reduce the number of dependency systems we are using | 22:39 |
| lifeless | poolie: for the forseeable future, eggs are needed, and so are dpkg packages. | 22:39 |
| lifeless | poolie: so either is fine IMO | 22:39 |
| poolie | i just need to make sure installing the package does not convert your machine into a buildd | 22:42 |
| poolie | though that might be kind of useful :) | 22:42 |
| poolie | especially leading up to the release | 22:42 |
| lifeless | well | 22:42 |
| lifeless | there are some options | 22:42 |
| lifeless | we could mandate having it run in a container | 22:42 |
| lifeless | for instance | 22:43 |
| lifeless | or you could create a test fake like that sketched on the SOA pages | 22:43 |
| poolie | i think eventually separating the tests along the interface will be good | 22:44 |
| poolie | for now i'm testing the whole thing because it's not very expensive and there is risk of integration breakage | 22:44 |
| poolie | do you know how hard it would be to run up a realistic buildd vm locally and do manual integration testing? | 22:45 |
| poolie | my impression is it's quite hard and unautomated | 22:45 |
| lifeless | https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally | 22:45 |
| wgrant | poolie: It's reasonably unautomated, but not exactly hard. | 22:45 |
| wgrant | It's also well-documented. | 22:46 |
| wgrant | Reasonably. | 22:46 |
| wgrant | I think people other than me have done it. | 22:46 |
| lifeless | ripe for improvement | 22:46 |
| mwhudson | i've set up an arm buildd | 22:46 |
| mwhudson | and used it with launchpad | 22:46 |
| mwhudson | .dev | 22:46 |
| mwhudson | it's fiddly, but not hard | 22:46 |
| poolie | thanks | 22:46 |
| wgrant | That page suggests installing it on your LP system, but that only really makes sense if your LP is running in a VM. | 22:47 |
| wgrant | Because it really shouldn't be running on a real machine. | 22:47 |
| poolie | i'm surprised that will work because it seems to have a hardcoded "if not under xen, abort" check | 22:48 |
| wgrant | poolie: Ah, for recipe builds, probably not. | 22:49 |
| wgrant | We have some thoroughly stupid checks. | 22:49 |
| wgrant | That I couldn't be bothered complaining about. | 22:49 |
| wgrant | (that one is new) | 22:49 |
| flacoste | iirc, it was a request from IS | 22:52 |
| flacoste | (the if not under xen, abort) | 22:53 |
| wgrant | Yes, and it was not a very sensible request :/ | 22:53 |
| wgrant | Because recipe builds are the safe ones. | 22:53 |
| wgrant | Well, not safe. | 22:53 |
| wgrant | But safer than binary builds. | 22:53 |
| wgrant | If it's not running under Xen, we have far larger problem.s | 22:53 |
| flacoste | i have to admin, i forgot the rationale behind them asking this | 22:53 |
| flacoste | admit | 22:53 |
| poolie | i can easily change it to be on by default but disableable | 22:54 |
| poolie | if that's a word | 22:54 |
| wgrant | Hopefully lamont won't notice if we remove it. | 22:54 |
| wgrant | It's only very very slightly beneficial to security. | 22:54 |
| poolie | that actually seems like a nice place to use one of those TCB features | 22:55 |
| poolie | perhaps they're not in the stock kernel | 22:55 |
| poolie | but, limiting the machine to exec'ing only particular binaries | 22:55 |
| poolie | or for that matter just having some noexec filesystems | 22:55 |
| wgrant | poolie: Doesn't quite work for a buildd :) | 22:55 |
| StevenK | sinzui: I can't use celebrity_logged_in -- I need to pass the principal into the view. | 22:55 |
| poolie | wgrant, why? | 22:55 |
| StevenK | sinzui: I already thought of using it when I wrote the branch. | 22:55 |
| poolie | hm | 22:56 |
| wgrant | poolie: Because they construct unsigned binaries... | 22:56 |
| poolie | i guess you would need something that allowed execution inside the chroot but not outside | 22:56 |
| poolie | perhaps possible though | 22:56 |
| wgrant | And that's not useful. | 22:56 |
| wgrant | Because chroots are not secure. | 22:56 |
| poolie | so the point is to make sure arbitrary code does not run outside of the vm | 22:59 |
| poolie | perhaps the host outside of the vm should be more locked | 22:59 |
| wgrant | No. | 23:00 |
| wgrant | It's to make sure untrusted code doesn't run on the non-virt builders. | 23:00 |
| wgrant | But it's a failed attempt to do that. | 23:01 |
| wgrant | Because binary builds still work, and they're far easier to exploit. | 23:01 |
| lifeless | uhm | 23:01 |
| lifeless | so I'm not endorsing the check | 23:01 |
| lifeless | but failure to prevent attacks A *and* B doesn't make a solution to attack A valueless. | 23:01 |
| wgrant | No. | 23:01 |
| wgrant | But in this case it's really not very useful. | 23:02 |
| wgrant | And it's actively harmful to development. | 23:02 |
| wgrant | Not useful + harmful == kill | 23:02 |
| poolie | i'll do something about it so i can test | 23:03 |
| poolie | i can understand how they would want some protection against things running in the wrong place through operator error, even if it is not 100% | 23:03 |
| wgrant | It's not even 10%. | 23:03 |
| wgrant | lifeless: http://paste.ubuntu.com/732768/ is an attempt without the denormalisation (AccessPolicyArtifact.policy exists, and AccessPolicyGrant's policy and artifact columns are mutually exclusive). | 23:42 |
| wgrant | lifeless: It's about 10% slower for Ubuntu on DF. | 23:42 |
| wgrant | lifeless: But much slower for other projects. | 23:42 |
| wgrant | (the third form of the query seems to be the fastest) | 23:42 |
| wgrant | Because it does a seq scan on APG. | 23:43 |
| wgrant | Refuses to use the indices. | 23:43 |
| wgrant | Was wondering if you could poke a bit. | 23:43 |
| lifeless | sure, I need to have an urgent poke at a few other things first, but after that I will | 23:54 |
| lifeless | (running out of disk space on carob would be bad) | 23:54 |
| StevenK | Sure, not seeing 2,000 OOPSes would be so tragic. | 23:54 |
| StevenK | Won't someone think of the OOPSes | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
