| lifeless | sinzui: jcsackett: security.cfg | 00:03 |
|---|---|---|
| lifeless | I have a suggestion | 00:03 |
| sinzui | do tell | 00:03 |
| lifeless | why don't we sort the permissions in each section | 00:04 |
| sinzui | That was my suggestion too | 00:04 |
| lifeless | analagously to what we do with imports | 00:04 |
| lifeless | sinzui: win! | 00:04 |
| sinzui | exactly | 00:04 |
| sinzui | We cannot trust merge if we do not wort | 00:04 |
| sinzui | sort | 00:04 |
| lifeless | we could do a merge plugin | 00:04 |
| lifeless | but sort is easier. | 00:04 |
| lifeless | we need to check renames are solid now | 00:11 |
| lifeless | and then trigger the mass update script | 00:11 |
| lifeless | poolie: branch id is the default for stacking now | 02:01 |
| poolie | great | 02:03 |
| lifeless | no reports of zomg yet | 02:04 |
| lifeless | I imagine tim will organise the migration script to run early next week | 02:04 |
| lifeless | thumper: ^ not before teh weekend plox :) | 02:04 |
| thumper | plox? | 02:09 |
| thumper | I'm currently writing a blog post about it | 02:11 |
| thumper | I'm happy to have the migration script run next week | 02:11 |
| lifeless | thumper: slang for please | 02:15 |
| lifeless | thumper: cool; I just don't want emergencies on friday:) - which is unlikely, but touching hundred-thousand plus objects... | 02:15 |
| wgrant | This is also the worst Friday ever. | 02:17 |
| wgrant | Since it is a 4 or 5 day weekend for most of the world. | 02:17 |
| thumper | :) | 02:17 |
| spiv | wgrant: ITYM best, not worst :) | 02:18 |
| wgrant | True, true. | 02:19 |
| spiv | If not best, then it's at least good ;) | 02:19 |
| poolie | lifeless, there's a 9m lag between bug comments being posted and mail being sent | 02:22 |
| poolie | do you want a bug about it? | 02:22 |
| poolie | or not want a bug | 02:23 |
| wgrant | No bug yet. | 02:23 |
| wgrant | Do you have a feeling about how long this has been happening? | 02:23 |
| poolie | i think for a week or so? | 02:23 |
| poolie | i remember noticing lag next week and checking for a problem at my end, and whether lp was sending to the wrong address | 02:24 |
| poolie | you can see the problem in the gap between the Date header (which i guess comes from the bug message date) and the first Received header | 02:24 |
| wgrant | poolie: It's meant to be 5 minutes, but can reasonably be up to 8. | 02:25 |
| poolie | well wth, i'll file and you can always close it | 02:25 |
| poolie | oh ok | 02:25 |
| poolie | a 5-min interval cronscript | 02:25 |
| wgrant | Not quite. | 02:25 |
| wgrant | We batch up to 5 minutes of events. | 02:25 |
| wgrant | So each comment is not sent until 5 minutes have expired. | 02:25 |
| wgrant | And the cronjob is */3 IIRC. | 02:25 |
| wgrant | (it has been this way since at least 2006) | 02:26 |
| wgrant | Hmm. | 02:26 |
| wgrant | send-bug-notifications is */5 now. | 02:26 |
| wgrant | That's less than ideal. | 02:26 |
| wgrant | Should really be */1, I think. | 02:27 |
| poolie | ok, so if it waits for 5m and then just-misses the next cronjob, that'd be 9m | 02:27 |
| poolie | i'll leave it then | 02:27 |
| poolie | rebooting for natty | 02:27 |
| wgrant | See you next week. | 02:28 |
| poolie | :) | 02:32 |
| LPCIBot | Project windmill build #202: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/202/ | 03:46 |
| nigelb | wgrant: Happy Birthday :-) | 03:58 |
| wgrant | nigelb: Thanks. | 04:01 |
| lifeless | wgrant: ditto | 04:15 |
| poolie | happy birthday! | 04:19 |
| poolie | is the 'opinion' status going to go away some time? | 04:21 |
| poolie | i thought i'd heard that it would | 04:21 |
| lifeless | jml will know; last I heard he was getting an ack from mark | 04:21 |
| poolie | i hit a couple of bugs where people were confused what it meant | 04:22 |
| poolie | probably not worth filing about | 04:22 |
| lifeless | I need a sanity check | 04:41 |
| lifeless | the current sample data creates the bugtask on jokosher for bug 11 with status 10 | 04:41 |
| _mup_ | Bug #11: Rosetta says there are untranslated strings, but it isn't <lp-translations> <Launchpad itself:Fix Released by carlos> < https://launchpad.net/bugs/11 > | 04:41 |
| lifeless | which is NEW | 04:41 |
| lifeless | nvm | 04:41 |
| lifeless | doc fraking tests | 04:41 |
| lifeless | facepalm | 04:50 |
| lifeless | we expire bugs that re INCOMPLETE_WITH_RESPONSE | 04:51 |
| lifeless | does this seem wrong ? | 04:51 |
| * lifeless doesn't have his optimistic mojo on today | 04:51 | |
| lifeless | huwshimi: have you mailed warthogs? the rule is live | 04:57 |
| huwshimi | lifeless: Will do now | 04:57 |
| wgrant | Thanks lifeless, poolie. | 05:25 |
| wgrant | lifeless: I believe bugs do expire if they have a response but then nobody touches them for two months, yes. | 05:26 |
| wgrant | Which happens all the time in Ubuntu. | 05:26 |
| wgrant | Looks like the expire-bugtasks unbreakage worked. | 05:33 |
| lifeless | wgrant: I think this sucks | 05:33 |
| wgrant | lifeless: Yes. | 05:35 |
| StevenK | Bad machine! No cookie for you. | 05:43 |
| lifeless | helpful : https://bugs.launchpad.net/launchpad/+bug/484712/+activity | 05:46 |
| _mup_ | Bug #484712: Potential synchronisation of comments between Launchpad bugs via remote bug trackers <bugwatch> <lp-bugs> <Launchpad itself:Expired> < https://launchpad.net/bugs/484712 > | 05:46 |
| lifeless | spot when it became incomplete | 05:46 |
| wgrant | Must have been filed Incomplete. | 05:47 |
| wgrant | ** Affects: malone | 05:47 |
| wgrant | Importance: High | 05:47 |
| wgrant | Assignee: Graham Binns (gmb) | 05:47 |
| wgrant | Status: Incomplete | 05:47 |
| wgrant | So, yes. | 05:47 |
| lifeless | -win- | 05:48 |
| lifeless | I've assigned it to him now :> | 05:48 |
| lifeless | what to do, what to do. | 05:54 |
| lifeless | expiry still going :) | 06:00 |
| poolie | wgrant: isn't bug 767084 a regression? | 06:15 |
| _mup_ | Bug #767084: "Mark as duplicate" popup gives an unhelpful error when attempted to dupe against a dupe <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/767084 > | 06:15 |
| poolie | i distinctly recall that transitive bug marking worked a few weeks ago | 06:16 |
| wgrant | poolie: In one direction, yes. | 06:16 |
| wgrant | It will work if you mark a bug that has dupes as a dup.e | 06:16 |
| wgrant | But not if you try to dupe against a bug that is a dupe. | 06:16 |
| poolie | ah, right | 06:16 |
| poolie | but it used to give better errors, surely? | 06:16 |
| wgrant | Not that I've ever seen. | 06:16 |
| wgrant | And that hasn't changed in a Long Time. | 06:16 |
| poolie | hm | 06:16 |
| poolie | if you say so | 06:17 |
| jtv | StevenK: I may be missing something... I don't actually see publish-distro do any locking at all currently. | 06:27 |
| wgrant | jtv: The script infrastructure does it. | 06:28 |
| wgrant | Hm. | 06:28 |
| wgrant | That's interesting. | 06:29 |
| wgrant | It doesn't actually use the script infrastructure. | 06:29 |
| jtv | 'zacly | 06:31 |
| wgrant | Created new stacked branch referring to /+branch-id/24637. | 06:35 |
| wgrant | That's a bit ugly :( | 06:35 |
| spiv | wgrant: :( | 06:45 |
| wgrant | StevenK: https://code.launchpad.net/~wgrant/launchpad/purge-shipit-cruft/+merge/58616 | 06:45 |
| StevenK | ! | 06:45 |
| wgrant | https://code.launchpad.net/~wgrant/launchpad/exterminate-shipit-admins/+merge/58618 | 06:45 |
| spiv | I suppose the best fix there is finally figure out how to translate the paths we report back to clients… | 06:46 |
| lifeless | we could include the project | 06:46 |
| lifeless | /proj/+branch-id/24637 | 06:46 |
| lifeless | and ignore /proj/ on input | 06:46 |
| StevenK | wgrant: Only niggle with the second branch is why do you assume no-priv is female? :-) | 06:49 |
| wgrant | Bah. | 06:49 |
| StevenK | wgrant: First branch is good, r=me | 06:50 |
| StevenK | wgrant: Is that all of it? | 06:50 |
| wgrant | StevenK: Yes, apart from DB cruft. | 06:51 |
| wgrant | Which is waiting for stub. | 06:51 |
| StevenK | Purging shipit has not felt as good as I thought it would. Can we add it back so we can remove it again? | 06:51 |
| wgrant | We haven't reached the good stuff yet. | 06:51 |
| wgrant | Like deleting Account. | 06:51 |
| wgrant | But that's ages away :( | 06:51 |
| wgrant | Damn Criticals. | 06:51 |
| StevenK | Hold on, can't we delete parts of canonical now that shipit isn't holding them in? | 06:52 |
| wgrant | I moved all of that to lp.shipit a couple of months ago. | 06:52 |
| spiv | lifeless: that sounds like a nice cheap workaround | 06:52 |
| lifeless | spiv: care to file a bug for it ? | 06:52 |
| lifeless | thumper might even get to it next week before he completely goes | 06:53 |
| StevenK | wgrant: canonical.mumble.widgets is sticking in my head for some reason, can haz check? | 06:53 |
| wgrant | StevenK: That's what triggered me to move everything to lp.shipit. | 06:53 |
| thumper | lifeless: for what? | 06:53 |
| wgrant | canonical.widgets is now gone. | 06:53 |
| spiv | lifeless: ok | 06:54 |
| lifeless | thumper: 17:35 < wgrant> Created new stacked branch referring to /+branch-id/24637. | 06:54 |
| lifeless | 17:35 < wgrant> That's a bit ugly :( | 06:54 |
| lifeless | 17:46 < spiv> I suppose the best fix there is finally figure out how to translate the paths we report back to clients… | 06:54 |
| lifeless | 17:45 < spiv> wgrant: :( | 06:54 |
| lifeless | 17:46 < lifeless> we could include the project | 06:54 |
| lifeless | 17:52 < spiv> lifeless: that sounds like a nice cheap workaround | 06:55 |
| lifeless | 17:46 < lifeless> /proj/+branch-id/24637 | 06:55 |
| lifeless | 17:46 < lifeless> and ignore /proj/ on input | 06:55 |
| lifeless | 17:52 < lifeless> spiv: care to file a bug for it ? | 06:55 |
| thumper | lifeless: yes it is a bit ugly, but I always said that | 06:55 |
| lifeless | 17:53 < lifeless> thumper might even get to it next week before he completely goes | 06:55 |
| thumper | no, I won't get around to it | 06:55 |
| lifeless | thumper: what do you think of the workaround I suggest | 06:55 |
| lifeless | ok | 06:55 |
| thumper | I've pretty much finished | 06:55 |
| lifeless | no worries | 06:55 |
| wgrant | Why do I have no MP mail... | 06:56 |
| StevenK | wgrant: My DSD.parent_series branch is massive. :-( | 06:57 |
| wgrant | StevenK: Oh? | 06:59 |
| spiv | lifeless: https://bugs.launchpad.net/launchpad/+bug/768068 filed | 06:59 |
| StevenK | wgrant: Since it also moves DSD and DSDJ to using DSP | 06:59 |
| lifeless | wgrant: btw, if you're going to do the BFJ refactoring this cycle, it probably has to be started on wed | 07:00 |
| lifeless | wgrant: (per sinzui saying it would be amongst the next work started) | 07:00 |
| lifeless | s/cycle/before may 4th deploy | 07:00 |
| wgrant | Hm, indeed. | 07:00 |
| StevenK | wgrant: 924 lines, +179/-162 | 07:02 |
| * wgrant stabs adelie. | 07:03 | |
| wgrant | Stop delaying my email by 20 minutes, thanks. | 07:03 |
| wgrant | Oh, actually, may have been loganberry. | 07:03 |
| wgrant | Bad loganberry and adelie, BAD. | 07:03 |
| StevenK | Can haz review? | 07:17 |
| StevenK | https://code.launchpad.net/~stevenk/launchpad/db-use-dsp/+merge/58624 | 07:17 |
| StevenK | It's a little over-sized, will compensate with cookies (but not cake) | 07:17 |
| * StevenK looks at spm | 07:17 | |
| spm | depends on the cookies. and you need more. | 07:18 |
| StevenK | spm: The point was the reviewer couldn't have cake, since that's reserved. :-) | 07:23 |
| spm | good lad; you may still get a losa xmas card (ie IOU losa's $X Cake) | 07:23 |
| lifeless | poolie: you still up for virtual beer-chat in a bit ? | 07:41 |
| lifeless | poolie: If so, I'm going to : pop out and grab a beer (stocks are low :P), dinner for lynne, a quick eow call with stub and then I'm up for it | 07:42 |
| poolie | haha | 07:42 |
| poolie | sure, why not | 07:42 |
| poolie | let's use some kind of less echoey telephony device though | 07:43 |
| lifeless | sure, will do | 07:44 |
| jtv | StevenK, wgrant: got time to discuss the archives locking issue? | 07:50 |
| wgrant | jtv: Sure. | 07:50 |
| jtv | Thanks. | 07:50 |
| jtv | I was thinking: we have script that work on multiple archives, | 07:50 |
| jtv | and we may have distros sharing arhives. | 07:50 |
| wgrant | Don't you ever say that again. | 07:51 |
| jtv | No? | 07:51 |
| jtv | Just mindlessly repeating what StevenK told me. | 07:51 |
| wgrant | Well, certainly not in the current model. | 07:51 |
| wgrant | Archive.distribution exists. | 07:51 |
| wgrant | I guess it's possible. But it's a reasonably big change. | 07:51 |
| wgrant | But we need to lock per-archive. | 07:51 |
| wgrant | So distributions don't matter here at all.; | 07:51 |
| jtv | So that brings us to the same conclusion anyway. | 07:51 |
| jtv | Next: block or fail? | 07:53 |
| * jtv coughs lungs out, along with pieces of chili | 07:53 | |
| wgrant | Probably fail. | 07:54 |
| jtv | If we block, there's a risk of deadlocks. If we fail, there's a risk of failure halfway through a script and I'm not so sure it's all idempotent. | 07:54 |
| jtv | So: | 07:54 |
| jtv | grab all relevant locks right at the outset, in some pre-determined global order. | 07:55 |
| wgrant | I'd hope there'd only be one lock. | 07:55 |
| wgrant | Except for the PPA publisher. | 07:55 |
| wgrant | Hmm. | 07:55 |
| jtv | Hmm. | 07:55 |
| jtv | Or publish-ftpmaster. | 07:55 |
| wgrant | True, now it is one. | 07:56 |
| jtv | But we want to be able to operate on multiple distros concurrently. | 07:56 |
| wgrant | In a single process? | 07:56 |
| jtv | No, in concurrent processes. | 07:56 |
| jtv | Plus some script runs operate on multiple archives concurrently, of course. | 07:57 |
| jtv | Sorry! I meant "sequentially" there. | 07:58 |
| jtv | The advantage of grabbing all relevant locks is that there'll be no locking surprises later on in the script. They can act pretty much as a single lock, except you get overlap of lock sets rather than competition for a single lock. | 07:59 |
| jtv1 | 13:56:48) wgrant: In a single process? | 08:01 |
| jtv1 | (13:56:55) jtv: No, in concurrent processes. | 08:01 |
| jtv1 | (13:57:24) jtv: Plus some script runs operate on multiple archives concurrently, of course. | 08:01 |
| jtv1 | (13:58:03) jtv: Sorry! I meant "sequentially" there. | 08:01 |
| jtv1 | (13:59:28) jtv: The advantage of grabbing all relevant locks is that there'll be no locking surprises later on in the script. They can act pretty much as a single lock, except you get overlap of lock sets rather than competition for a single lock. | 08:01 |
| jtv1 | (14:00:53) jtv: Grabbing them in a globally total order eliminates deadlock and livelock hazards: nobody's going to be holding the lock you want while trying to grab one of yours (or waiting for somebody who is). | 08:01 |
| wgrant | jtv1?: Won't each job be for a single archive? | 08:01 |
| wgrant | Once publish-ftpmaster.py dies. | 08:01 |
| jtv1 | publish-ftpmaster calls publish-distro for multiple archives, both in its old incarnation and the new. | 08:01 |
| wgrant | For now. | 08:02 |
| jtv1 | ? | 08:02 |
| jtv1 | What's going to change? | 08:02 |
| jtv1 | For all I know it's just going to get worse once we start publishing Debug. | 08:02 |
| jtv1 | salut rvba | 08:02 |
| jtv1 | "le stigue" | 08:02 |
| LPCIBot | Project windmill build #203: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill/203/ | 08:02 |
| wgrant | jtv1: Won't it eventually replaced with publishing jobs? | 08:02 |
| wgrant | +be | 08:03 |
| rvba | Hi jtv1! | 08:03 |
| jtv1 | wgrant: who am I to say? But life in the hard school of Launchpad has taught me to be wary of "eventually." | 08:03 |
| wgrant | jtv1: True. | 08:03 |
| jtv1 | We have real problems now. Piling requirements onto the Final Solution is just going to make it take longer. | 08:04 |
| === jtv1 is now known as jtv | ||
| jtv | So I think we can't get around concurrency plus multiple sequential locks that mustn't fail. | 08:05 |
| wgrant | wom 3 | 08:05 |
| wgrant | Grah. | 08:05 |
| jtv | What is this mysterious language you speak? | 08:06 |
| wgrant | An unintended keyboard offset. | 08:06 |
| jtv | Were you trying to type "some"? | 08:06 |
| wgrant | /win 3 | 08:07 |
| jtv | ah | 08:07 |
| * jtv washes chili off hands before it causes keyboard damage | 08:08 | |
| jtv | wgrant: if a script operates on just one archive in isolation, then it should be fine for it to block. | 08:13 |
| wgrant | jtv: Do we want it to block? | 08:14 |
| jtv | Of course we don't want multiple instances of the same cron job to pile up, *but* if we have a non-blocking lock for the script itself then we'll only have one instance waiting at most. | 08:14 |
| jtv | So then, blocking will help get the job done. | 08:14 |
| jtv | We wouldn't want, for instance, cron script A failing every single time because cron script B comes in first and grabs a lock that A also wants. | 08:15 |
| jtv | A blocking lock would help sort that out (or at least signal failure to sort it out). | 08:15 |
| jtv | For manual scripts I'd prefer failing over blocking. | 08:16 |
| jtv | wgrant: the 3 Singletons of Doom were publish-distro, process-accepted, and death-row, right? | 08:18 |
| wgrant | jtv: That's correct. | 08:18 |
| jtv | Does each of those modify the archive's database state? | 08:19 |
| wgrant | Yes. | 08:19 |
| wgrant | But they're meant to be safely concurrent. | 08:19 |
| wgrant | There is probably a slight race between process-death-row and publish-distro, but it's very unlikely and never happened TTBOMK | 08:20 |
| jtv | Well we could conceivably address that with whatever solution we come up with here. | 08:20 |
| jtv | If all three SOD change the archive's db state, then db locking would be a possibility. | 08:22 |
| jtv | (If they didn't, we might want to deploy them without master db access) | 08:22 |
| wgrant | They all write to the DB. | 08:22 |
| jtv | Right | 08:23 |
| jtv | wgrant: what concurrency requirements do we have on PPAs when it comes to these scripts? | 08:27 |
| lifeless | stub: around ? | 08:30 |
| stub | Yup. | 08:30 |
| lifeless | skype in 5? | 08:30 |
| stub | Sure. | 08:30 |
| stub | I'll need to let the maid in in a few mins. | 08:31 |
| wgrant | jtv: We do them serially at the moment. | 08:31 |
| wgrant | jtv: No significant reason for that. | 08:31 |
| === jtv1 is now known as jtv | ||
| jtv | wgrant: which of these scripts operate on PPAs? | 08:35 |
| wgrant | jtv: All of the above, when given the --ppa option. | 08:36 |
| jtv | And you're saying two instances of the same one can operate on the same PPA at the same time? | 08:36 |
| wgrant | No. At most one instance of each of those scripts can operate on a particular archive at a time. | 08:37 |
| lifeless | stub: ready? | 08:40 |
| jtv1 | wgrant: So we need the same locking for PPAs that we do for distro archives... then what is the "we do them serially at the moment" that we have no significant reason for? | 08:41 |
| stub | lifeless: yo | 08:41 |
| lifeless | jtv1: incremental development not incremented | 08:41 |
| spm | o/ stub | 08:41 |
| jtv1 | lifeless: huh wha? | 08:41 |
| wgrant | jtv1: We have exactly the same locking requirements, yes. At the moment each run of the Three processes all pending PPAs serially, but there's no reason they couldn't run multiple instances of, say, publish-distro, couldn't run simultaneously in separate runners over different PPAs. | 08:43 |
| jtv1 | wgrant: ah you're saying one script could process multiple PPAs concurrently? | 08:43 |
| wgrant | jtv1: Right. | 08:44 |
| jtv1 | Sounds nice. | 08:44 |
| lifeless | mup poke lifeless | 08:44 |
| jtv1 | wgrant: I wonder if this should be a LEP. | 08:45 |
| jtv1 | I've got some slightly more systematic notes now, and an idea of what we want; I'll draft a rough design. | 08:46 |
| lifeless | jtv1: I think it should be a lep if you don't know why you're doing it | 08:46 |
| lifeless | jtv1: if you're merely trying to sort out how to do it, I don't know that LEP adds much | 08:47 |
| lifeless | jtv1: the question for me is why do you want to change this? | 08:47 |
| jtv1 | lifeless: two separate things, arguably: an existing concurrency risk where we assumed there was a lock but there doesn't seem to be one, and second as part of derivation, we want to support multiple distros. | 08:48 |
| jtv1 | Which means that slightly freeer concurrency is needed. | 08:48 |
| lifeless | jtv1: I don't understand the linkage | 08:49 |
| jtv1 | The linkage is incidental. We want looser locking, but also we discovered that one lock was missing altogether. | 08:49 |
| lifeless | unless there is an assumption we want to publish N *distros* into one archive which would be a little questionable | 08:49 |
| jtv1 | AIUI there is no such requirement just now, so we could get by with "distro _or_ archive" locking. | 08:51 |
| jtv1 | (Currently all we have is per-script locking, which turns out to be broken) | 08:51 |
| jtv1 | I'm not sure "lock this distro or archive" is better than "lock these archives" though. | 08:52 |
| jtv1 | And it's not unthinkable that we'll move to a pure per-archive model anyway, if I understood correctly. | 08:53 |
| jtv1 | So I think a LEP would be helpful for laying down what requirements we have now, and which ones we see coming. | 08:53 |
| jtv1 | Makes it easier to challenge those assumptions. | 08:54 |
| lifeless | mrevell: your blog theme de jour: bug expiry is now *really* working | 08:57 |
| mrevell | Hello | 08:57 |
| jtv1 | "du" | 08:57 |
| jtv1 | unless he blogs as Mr Hyde by night | 08:58 |
| mrevell | lifeless, Oh, cool. Is there any more detail on that? I don't see anything on the list. | 08:58 |
| lifeless | mrevell: was a simple bug | 08:59 |
| lifeless | script was barfing | 08:59 |
| wgrant | It expired 2000 bugs this afternoon. | 08:59 |
| mrevell | blimey | 08:59 |
| lifeless | mrevell: I'm on a call, but I'm sure wgrant or someone can help you come up with good blurb | 08:59 |
| mrevell | Hey wgrant, happy birthday. | 08:59 |
| wgrant | Thanks mrevell. | 08:59 |
| jtv1 | oh! | 09:00 |
| jtv1 | many happy returns, wgrant | 09:00 |
| mrevell | wgrant, Do you know how long bug expiry was busted? | 09:00 |
| wgrant | mrevell: Well, it's been busted for just about ever. | 09:01 |
| wgrant | Since it was turned back on. | 09:01 |
| wgrant | AFAICT. | 09:01 |
| wgrant | scriptactivity might be able to tell us, though. | 09:01 |
| mrevell | wgrant, Any detail on what was wrong? | 09:04 |
| wgrant | mrevell: A missing database permission combined with a broken OOPS handler, so it wasn't logging the errors anywhere that we could see. | 09:04 |
| wgrant | And I guess we don't have scriptactivity monitoring for it. | 09:05 |
| lifeless | wgrant: it did a weeks run or something ok | 09:05 |
| lifeless | and then we refactored | 09:05 |
| adeuring | good morning | 09:06 |
| wgrant | lifeless: Ah, I see. | 09:06 |
| mrevell | Okay, so 2,000 bugs expired in the space of a few hours ... lots of bug mail gone out. I think it's worth a status update and a post to -users but I'm not sure it needs a blog post. I'm willing to be persuaded otherwise. | 09:10 |
| wgrant | I agree. | 09:10 |
| lifeless | mrevell: 'feature we said was working now works' | 09:10 |
| lifeless | mrevell: Thats the focus I was suggesting, the # of emails is incidental | 09:11 |
| lifeless | shiny-new really working, is more relevant | 09:11 |
| bigjools | positive spin, lifeless should work for the gubmint | 09:12 |
| lifeless | bigjools: shhh | 09:12 |
| lifeless | mrevell: not that I mind, but you *did* want blog material | 09:13 |
| mrevell | lifeless, Yes, absolutely, and thanks for thinking of the blog :) I agree that this needs announcing ... it's just that I reckon a blog post requires some explanation and hand-wringing etc in this sort of situation and I'm not sure I have a lot to say other than, "Oops, we made a mistake, didn't notice and now we've fixed it." That feels like a status message to me, not a blog post. Bah, it's too early for me to th | 09:15 |
| mrevell | ink about this. I'll write something short and simple for the blog just in case people come there expecting an explanation. | 09:15 |
| lifeless | up to you :) | 09:15 |
| lifeless | I wouldn't hand wring much myself. | 09:15 |
| lifeless | I'd say 'you may have wondered why X which we blogged about 3 months as working, was not working... it was failing and due to a second bug our alerts were not alerting. We have fixed both bugs and the service is now running well, .... | 09:16 |
| wgrant | lifeless: And a third bug. | 09:17 |
| wgrant | lifeless: No scriptactivity monitoring :( | 09:17 |
| mrevell | Thanks lifeless | 09:17 |
| lifeless | mrevell: but thats me; not saying it must be a blog or not. | 09:21 |
| lifeless | mrevell: I know we want the home page blog posts to be a bit of advertising | 09:21 |
| lifeless | mrevell: but being transparent and open about issues is part of who we are, and is valuable to our users, so we shouldn't be afraid of talking about things we [messed up]|[have fixed] | 09:22 |
| === almaisan-away is now known as al-maisan | ||
| mrevell | lifeless, Yeah, I agree we must be open etc. but I think the line between operational status updates on identi.ca and something requiring a blog post is pretty blurry. Having tried to write an identi.ca update I reckon it's pretty clear we need a blog post too :) | 09:33 |
| mrevell | hey henninge, do you have time today for a call? I want to talk about the translations sharing announcement. | 09:35 |
| henninge | mrevell: I guess I could spare the time but I'd rather do it next week, if that is OK? | 09:36 |
| henninge | mrevell: I still need to finish the feature before we can announce it ;-) | 09:37 |
| mrevell | henninge, I have a call scheduled with deryck to day so I can speak to him and then email you if I need any further detail. | 09:37 |
| mrevell | Oh, right, heh, fair enough :) | 09:37 |
| henninge | mrevell: thanks ;) | 09:37 |
| wgrant | stub: So, ShipIt is now gone from prod. The DB can be deplagued at your leisure. | 09:37 |
| stub | \o/ | 09:39 |
| stub | I get to delete stuff. | 09:39 |
| stub | That is going to fsck my bloat reports :) | 09:39 |
| stub | Person table, 90% bloat. | 09:39 |
| wgrant | Heh. | 09:40 |
| lifeless | validpersoncache may stop sucking | 09:41 |
| stub | The tables will be small enough to pack them next upgrade anyway... maybe live too. | 09:42 |
| wgrant | stub: Have the Personless Accounts all been purged yet? | 09:42 |
| wgrant | I suspect not :( | 09:42 |
| StevenK | allenap: https://code.launchpad.net/~stevenk/launchpad/db-use-dsp/+merge/58624 | 09:43 |
| stub | No, because they were tied up with shipit. | 09:43 |
| stub | Almost all the personless accounts were shipit users. | 09:43 |
| StevenK | stub: ^, too, since I need a DB review | 09:43 |
| wgrant | stub: Ah, I guess so. So the SSO-only Accounts are still around? | 09:45 |
| allenap | StevenK: Cheers :) | 09:49 |
| stub | yup | 09:54 |
| jtv1 | wgrant: yhm about locks | 10:03 |
| rvba | allenap: could you review this https://code.launchpad.net/~rvb/launchpad/add-help-initseries/+merge/58641 | 10:14 |
| allenap | rvba: Sure. | 10:15 |
| rvba | allenap: thanks. | 10:15 |
| allenap | rvba: I'm doing StevenK's right now, but straight after that. | 10:15 |
| StevenK | stub: Erk, sorry, I hadn't added you as a reviewer. | 10:15 |
| rvba | allenap: splendid. It's a very small fix. | 10:16 |
| === almaisan-away is now known as al-maisan | ||
| wgrant | Could someone please review https://code.launchpad.net/~wgrant/launchpad/bug-766742/+merge/58643? | 10:28 |
| lifeless | try:finally: missing | 10:30 |
| wgrant | lifeless: Bah. True. | 10:42 |
| lifeless | a context manager/fixture would make this more obvious for simple cases | 10:43 |
| wgrant | I was initially going to turn it into a context manager, but decided it wasn't worth it. | 10:43 |
| wgrant | Right. | 10:43 |
| wgrant | lifeless: As for the None thing, it gets written out as '00235-00235@openid-association-complete-stop None', which looks OK to me. | 10:45 |
| lifeless | ok, sure | 10:47 |
| bigjools | lifeless: around? | 11:09 |
| bigjools | lifeless: http://pastebin.ubuntu.com/596858/ | 11:09 |
| bigjools | lazr.restful bug? | 11:10 |
| lifeless | yes | 11:10 |
| lifeless | lazr.restful.error appears to assume that str() works always | 11:11 |
| lifeless | which it doesn't | 11:11 |
| lifeless | in particular, if the context only defines __unicode__ or whatever you'll get ascii encoding happening, which is fail | 11:11 |
| lifeless | basically anything using str() on arbitrary objects is broken | 11:11 |
| bigjools | so this only just started being a problem on DF | 11:12 |
| lifeless | Rapha\xebl | 11:12 |
| bigjools | there was a lazr.resful update | 11:12 |
| bigjools | coincidence? :) | 11:12 |
| lifeless | we also hired a dude with a unicode name | 11:12 |
| bigjools | heh | 11:12 |
| wgrant | lazr.restful hasn't been upgraded significantly in a few week.s | 11:12 |
| wgrant | But the error handling changed a couple of months ago. | 11:12 |
| bigjools | something just changed in the sourcecode deps, damn I forgot which | 11:12 |
| wgrant | lazr.enum. | 11:12 |
| lifeless | anyhow | 11:12 |
| wgrant | Triviall change. | 11:13 |
| bigjools | ah | 11:13 |
| lifeless | I wouldn't worry about how we got here | 11:13 |
| bigjools | I wonder why this is breaking now | 11:13 |
| lifeless | we are here, and its got clearly bong code. | 11:13 |
| bigjools | indeed | 11:13 |
| lifeless | its trying to thow one exception | 11:13 |
| lifeless | and its failing and barfing its internals | 11:13 |
| lifeless | (thats a WAG) | 11:13 |
| lifeless | anyhow, I'm not here ;) | 11:13 |
| === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap | https://code.launchpad.net/launchpad-project/+activereviews | ||
| stub | StevenK, bigjools, wgrant, rvba: So the model for derived distros is now clear? I've got this review here from StevenK for DistroSeriesDifference.parent_series | 11:17 |
| bigjools | stub: yes, this new column allows for multiple parents for the same derivation | 11:17 |
| wgrant | stub: I have no objections to the addition of that column. | 11:18 |
| wgrant | The other stuff is less clear. | 11:18 |
| stub | "The distribution series which identifies the parent series with the difference." | 11:27 |
| stub | Is that English? | 11:27 |
| bigjools | barely | 11:29 |
| bigjools | s/which/that/ maybe | 11:30 |
| stub | I would have thought the parent_series column would reference the parent distro series, not a distro series that references the parent distro series through unspecified means. | 11:30 |
| bigjools | or that | 11:32 |
| jtv1 | jml: https://wiki.ubuntu.com/NewReleaseCycleProcess step 11 says to have you or james_w create "the branches" for a new Ubuntu series. What branches are those? Are they an Ubuntu thing or would this happen for derived distros as well? | 11:45 |
| bigjools | jtv1: package branches | 11:51 |
| jtv1 | bigjools: thanks. Making an inventory of things that look like we could chuck into an automated initialization process. | 11:52 |
| bigjools | jtv1: that is one of them for sure, but out of scope for us ;) | 11:54 |
| jtv1 | Wasn't planning to do them all today. :) | 11:54 |
| jtv1 | bigjools: I do have something of an ulterior agenda in looking ahead a bit though... the process involves manual work by the Rosetta team. :-) | 11:56 |
| jtv1 | wgrant, you'd know this: when we create a new Ubuntu series, we create override files for restricted as links pointing to the ones for main. Do initialise-from-parent and publish-distro require that? | 12:00 |
| wgrant | jtv1: I admit that I don't entirely understand that bit. | 12:03 |
| jtv1 | then all is lost | 12:03 |
| === jtv1 is now known as jtv | ||
| wgrant | The a-f stuff is one of the few bits of Soyuz I'm quite happy to lalalallalaimnotlistening about. | 12:03 |
| deryck | Morning, all. | 12:04 |
| jtv | hi deryck | 12:04 |
| wgrant | jtv: I believe it's from germinate, thought. | 12:04 |
| bigjools | jtv: i-f-p does not, p-d does | 12:04 |
| wgrant | jtv: I guess germinate creates one file, but a-f wants one for each component. | 12:04 |
| wgrant | Right. | 12:04 |
| bigjools | the override files start out as the same as the previous series | 12:04 |
| wgrant | i-f-p doesn't care about a-f crap. | 12:04 |
| bigjools | the override files are a freaking nightmare | 12:05 |
| wgrant | bigjools: I'm not sure that's the case here. | 12:05 |
| jtv | So this is ubuntu-specific on the one hand, but on the other it's required for the initial index generation? | 12:05 |
| wgrant | This is more-extra. | 12:05 |
| wgrant | more-extra is generated by germinate. | 12:05 |
| wgrant | So they probably only exist on the second run. | 12:05 |
| wgrant | Since NRCP doesn't say to copy, just to create the links. | 12:05 |
| * jtv just keeps getting dizzy when trying to follow these conversations | 12:05 | |
| bigjools | wgrant: they have to exist or ln -s will fail | 12:06 |
| lifeless | deryck: why does expiry expiry INCOMPLETE_WITH_RESPONSE bugs? | 12:06 |
| wgrant | bigjools: No... | 12:06 |
| wgrant | bigjools: It will be a dangling link. | 12:06 |
| bigjools | ye gads | 12:06 |
| bigjools | that's horrid | 12:07 |
| wgrant | It's fine. | 12:07 |
| wgrant | a-f will just see the file doesn't exist and there will be no Task headers. | 12:07 |
| bigjools | the fact that ln lets you link to an nonexistent file I mean | 12:07 |
| wgrant | Until the second run. | 12:07 |
| wgrant | It's very useful! | 12:07 |
| wgrant | It's essential here, for example. | 12:07 |
| bigjools | I'd at least like a warning! | 12:07 |
| jtv | Sissy. | 12:07 |
| wgrant | ls -l -> OMG RED | 12:07 |
| bigjools | typos are part of my life | 12:07 |
| wgrant | UNIX doesn't do typos. | 12:08 |
| deryck | lifeless, it's based on date of recent activity... so if the response falls outside the 60 days without activity, then it expires. which can happen if it's been awhile since expiry has run. | 12:08 |
| jtv | apt-get remove --purge adobe-anything ; ln -s foo<tab><tab> etc | 12:08 |
| bigjools | ln -s importantfile overrides.mainwgrantsucks.natty | 12:08 |
| bigjools | oops! | 12:08 |
| lifeless | deryck: I think I'm not clear | 12:08 |
| lifeless | deryck: we have in the UI two versions of INCOMPLETE | 12:09 |
| lifeless | one is INCOMPLETE_WITHOUT_RESPONSE | 12:09 |
| lifeless | and one is INCOMPLETE_WITH_RESPONSE | 12:09 |
| deryck | right | 12:09 |
| deryck | these are to help people find bugs they need to act on. they have nothing to do with the rules for expiry actually. | 12:09 |
| lifeless | the workflow we sortof suggest is that 'put the bug into incomplete, when someone responds a search for INCOMPLETE_WITH_RESPONSE will show it, and you can take it from there. | 12:09 |
| deryck | and that is all correct. | 12:10 |
| lifeless | myself and several others today were surprised to figure out that expiry expires both WITH and WITHOUT cases | 12:10 |
| lifeless | so I'm not asking about the implementation, I'm asking about the intent :) | 12:10 |
| jtv | wgrant: what exactly is "more extra" anyway? | 12:10 |
| deryck | people assume that means expiry won't get it if there is a comment. but that's not true, if the comment itself is also over 60 days old. | 12:10 |
| deryck | lifeless, I don't actually no the intent from way back. the implementation is intent at this point. :-) | 12:11 |
| lifeless | deryck: so /why/ do we do this. | 12:11 |
| deryck | lifeless, but I went through all this with bdmurray and ubuntu qa when we re-enabled this. and everyone felt comfortable this was ok, and works as expected. | 12:12 |
| lifeless | deryck: I see; I propose to file a bug then, because I think its surprising to discriminate on has/has not responded in one part of the UI but not the other. | 12:12 |
| deryck | lifeless, actually.... | 12:12 |
| lifeless | deryck: I'll happily run it past ubuntu qa | 12:12 |
| wgrant | jtv: We write append/prepend/something it to the extra overrides. | 12:12 |
| deryck | lifeless, if we fix this, I'd propose we just toggle out of incomplete and drop the whole incomplete with response stuff | 12:12 |
| deryck | there's a bug about that already | 12:13 |
| lifeless | deryck: that would be good | 12:13 |
| wgrant | jtv: So we generate overide.*.extra.* ourselves, then append more-extra (which is generated by cron.germinate) | 12:13 |
| lifeless | I've nearly got a patch landed to store WITH/WITHOUT directly in the db | 12:13 |
| jtv | wgrant: oh, so it's specifically for publish-distro to use, not e.g. food for a debian script? | 12:13 |
| deryck | lifeless, nice | 12:13 |
| wgrant | jtv: It is food for a Debian script, but it goes via ftparchive.py. | 12:13 |
| lifeless | one more round of ec2 should see the last failures gone and it landed - purely an optimisation for the DB | 12:13 |
| wgrant | jtv: So we can do with it what we wish, I guess. | 12:14 |
| lifeless | makes task.status a property, and folds it in/out as needed | 12:14 |
| jtv | wgrant: when you're not intimately familiar with the debian scripts it's very helpful if you can see what a file does from looking at just the LP python code. | 12:14 |
| wgrant | jtv: Heh. You can't understand the content, but you can understand what's done with it. | 12:15 |
| jtv | wgrant: exactly. I don't need to understand the content for what I'm doing. | 12:15 |
| wgrant | jtv: Although the more-extra handling is untested, IIRC. | 12:15 |
| jtv | I very earnestly hope. :) | 12:15 |
| jtv | (Oh man I love moving windows in unity without dragging! Just a 3-fingered drag) | 12:16 |
| wgrant | My T400 touchpad doesn't do multi-finger :( | 12:16 |
| wgrant | My 5 year old Dell does, though :( | 12:16 |
| jtv | On recent macbooks it's already required because that's how you simulate multiple mouse buttons. | 12:17 |
| jtv | Next, easy scrolling would be nice. | 12:17 |
| === al-maisan is now known as almaisan-away | ||
| jtv | bigjools: : I don't suppose a derived distro would be wanting the more.extra links? | 12:19 |
| wgrant | They probably will. | 12:20 |
| bigjools | the definitely will | 12:20 |
| bigjools | they* | 12:20 |
| wgrant | They should be allowed to have them. | 12:20 |
| bigjools | Ubuntu for starters :) | 12:21 |
| wgrant | Their hooks will create them, though. | 12:21 |
| bigjools | yeah, I think this sort of thing should all go in hooks | 12:21 |
| lifeless | bigjools: any reason we shouldn't set a currentseries for every distro, and require one ? (Like we require a currentseries for all products) | 12:21 |
| lifeless | (bug 277118 would be rendered obsolete by doing this) | 12:21 |
| wgrant | jtv, bigjools: Perhaps cron.germinate should maintain the links itself. | 12:21 |
| _mup_ | Bug #277118: +upstreamreport oopses for some distributions <lp-bugs> <oops> <ubuntu-upstream-relations> <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/277118 > | 12:21 |
| wgrant | Since it's conceivable that distros may want different files for each. | 12:22 |
| bigjools | lifeless: a db column or property? | 12:22 |
| lifeless | bigjools: the existence of a distroseries that can match the 'development_focus' rules | 12:22 |
| lifeless | bigjools: so nither a db column or a property - there already is a property | 12:22 |
| jtv | wgrant: does cron.germinate facilitate such customization? | 12:23 |
| wgrant | jtv: Hm? | 12:23 |
| bigjools | wgrant: interesting idea | 12:23 |
| wgrant | And it removes some stupidity from i-f-p. | 12:23 |
| wgrant | And that can only be a good thing. | 12:23 |
| bigjools | lifeless: is nither neither or either? | 12:24 |
| jtv | "er... either?" | 12:24 |
| lifeless | neither | 12:24 |
| lifeless | the property already exists ;) | 12:24 |
| bigjools | lifeless: so you can use that? or am I missing something? | 12:24 |
| jtv | wgrant: one small thing though: I think the current release procedure creates the links _before_ cron.germinate gets to run. | 12:24 |
| lifeless | bigjools: there are distros that don't have a currentseries | 12:24 |
| bigjools | oh you want to enforce it? | 12:25 |
| lifeless | yes | 12:25 |
| wgrant | jtv: Yes. | 12:25 |
| bigjools | hmm | 12:25 |
| wgrant | jtv: But it will just ignore them if they don't exist. | 12:25 |
| lifeless | we do for product | 12:25 |
| wgrant | jtv: 'it' being ftparchive.py | 12:25 |
| lifeless | and it makes a lot of code simpler. | 12:25 |
| bigjools | lifeless: it only really means something for soyuz-maintained distros | 12:25 |
| lifeless | you can assume that there is a trunk (whatever its name) and that its usable and sane. | 12:25 |
| bigjools | which is only one distro | 12:25 |
| jtv | wgrant: won't that cause any trouble for the initial publish-distro runs that create the indexes? | 12:25 |
| bigjools | lifeless: there's no concept of current series for the others because we don't maintain them in LP | 12:26 |
| lifeless | bigjools: the same argument can be made about products registered in LP but not maintained in LP | 12:26 |
| bigjools | true | 12:26 |
| lifeless | bigjools: but we do it there, and its not really an issue - we just create trunk when the product is registered | 12:26 |
| lifeless | no user questions or anything | 12:26 |
| wgrant | jtv: The first run will lack the germinate output (Task headers), yes. | 12:27 |
| lifeless | just don't let them delete it if its the last one present | 12:27 |
| wgrant | jtv: But that's already the case, AFAICT. | 12:27 |
| lifeless | bigjools: the context for this is: | 12:27 |
| wgrant | jtv: NRCP creates the links, but they are dangling. | 12:27 |
| lifeless | - my simplifying the bugtask model post | 12:27 |
| wgrant | jtv: Because more-extra.override.DSN.main doesn't exist yet. | 12:27 |
| lifeless | - and bugs like the one adeuring is looking at | 12:27 |
| bigjools | lifeless: I don't think anything will break if we add series to other distros | 12:28 |
| jtv | wgrant: so I needn't be worried about whether these links exist when I automate the publish-distro -A runs? | 12:28 |
| wgrant | jtv: No. That's just to get the empty indices out there. | 12:28 |
| wgrant | Empty indices -> no packages to look for extra overrides for. | 12:28 |
| bigjools | lifeless: the code seems to just pick the first series it can find if it's not in one of the known "current" states | 12:29 |
| wgrant | Except for the release pocket, which will be updated anyway in an hour. | 12:29 |
| wgrant | With cron.germinate this time. | 12:29 |
| lifeless | bigjools: yeah | 12:29 |
| * jtv is slightly worried that what wgrant just burbled through the smoke of mystical herbs starts to make sense to him | 12:29 | |
| bigjools | lifeless: the states are not set by soyuz | 12:29 |
| lifeless | bigjools: I'll suggest this to adeuring & deryck as a way to fix it | 12:30 |
| bigjools | but they change its behaviour significantly | 12:30 |
| bigjools | lifeless: yeah it should be ok | 12:30 |
| lifeless | bigjools: but we don't use soyuz there, so shrug :) \o/ | 12:30 |
| bigjools | indeed | 12:30 |
| jtv | bigjools: thanks for the review. I shoot for tests that are short and well-named enough not to require docs. Useful goal I hope, even if that doesn't imply realistic. :) | 12:31 |
| bigjools | :) | 12:31 |
| lifeless | bigjools: https://bugs.launchpad.net/launchpad/+bug/277118/comments/3 | 12:33 |
| _mup_ | Bug #277118: +upstreamreport oopses for some distributions <lp-bugs> <oops> <ubuntu-upstream-relations> <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/277118 > | 12:33 |
| lifeless | deryck: ^ | 12:34 |
| adeuring | lifeless: sorry, was out for a few minutes. What about this bug? | 12:34 |
| lifeless | adeuring: just that one way to fix it - one that is inline with other parts of the code base - is to ensure that currentseries always returns a series | 12:35 |
| adeuring | lifeless: ah, right | 12:35 |
| bigjools | lifeless: it begs the question, why does that page need to know what the currentseries is? | 12:36 |
| lifeless | bigjools: because packages don't live in distros | 12:38 |
| lifeless | bigjools: they live in distroseries. | 12:38 |
| bigjools | lifeless: not entirely | 12:39 |
| bigjools | the report is distro specific, there's no series in the URL | 12:39 |
| lifeless | bigjools: I konw | 12:39 |
| lifeless | but its deriving data from the current series | 12:39 |
| lifeless | which is reasonable because: | 12:39 |
| lifeless | - we don't care about things not in the current series | 12:39 |
| lifeless | - nope, just one key reason | 12:40 |
| bigjools | you don't need to know the series, you can just take the latest published version | 12:40 |
| deryck | lifeless, we can look at the bug during standup and get one of us on it. | 12:40 |
| lifeless | deryck: adeuring is already on it; I'm merely suggesting a possible impl strategy | 12:42 |
| lifeless | bigjools: Module canonical.launchpad.browser.distribution_upstream_bug_report, line 161, in __init__ | 12:42 |
| lifeless | self.packaging_url = canonical_url(self.dssp) + "/+edit-packaging" | 12:42 |
| lifeless | Module canonical.launchpad.webapp.publisher, line 370, in canonical_url | 12:42 |
| lifeless | urlparts = [urldata.path | 12:42 |
| lifeless | Module canonical.launchpad.webapp.publisher, line 325, in canonical_urldata_iterator | 12:42 |
| deryck | lifeless, ah, ok. | 12:42 |
| lifeless | raise NoCanonicalUrl(obj, current_object) | 12:42 |
| lifeless | NoCanonicalUrl: No url for None because None broke the chain. | 12:42 |
| bigjools | because it's using a DSSP | 12:43 |
| bigjools | hmph | 12:43 |
| bigjools | well you can get the series from the latest publication | 12:43 |
| lifeless | a possibly better question is htf these distros have publications without a currentseries | 12:43 |
| bigjools | lifeless: it seems like the page is implemented weirdly | 12:43 |
| bigjools | they should not, indeed | 12:44 |
| lifeless | forcing currentseries to return something is similar to the null pattern object, but without the code duplication or the friction one has in zope (e.g. see the rather horrid (and now dead) NullBugTask) | 12:45 |
| lifeless | whup, nearly midnight. ciao. | 12:45 |
| bigjools | we need to look deeper at this rather than papering over the problem | 12:45 |
| bigjools | nn lifeless | 12:45 |
| adeuring | lifeless: Distribution.currentseries returns None no series exists at all. So, should we enforce the creation of a series? | 12:45 |
| lifeless | bigjools: I'm not suggesting papering; I'm suggesting that there are a bunch o freasons to want currentseries to always work. | 12:45 |
| lifeless | adeuring: yes, precisely. | 12:45 |
| lifeless | bigjools: there may well be other problems in that page. | 12:46 |
| adeuring | ok | 12:46 |
| lifeless | adeuring: on staging, make a new product | 12:46 |
| lifeless | note that it comes with a series | 12:46 |
| lifeless | and you can't get rid of it | 12:46 |
| adeuring | right | 12:46 |
| bigjools | adeuring: lifeless: if therer is no current series, there can be no packages. So there can be no upstream report. | 12:46 |
| lifeless | you can't obsolete etc etc | 12:46 |
| lifeless | adeuring: so I'm suggesting the same rule apply to distributions | 12:47 |
| lifeless | bigjools: I agree that for this report there may well be other headaches in the page. | 12:47 |
| adeuring | bigjools: well, don't ask me for details, but somehow the upstream report page breaks... | 12:47 |
| lifeless | anyhow, must go. Have a great easter. | 12:47 |
| bigjools | nn again :) | 12:47 |
| adeuring | at the crash really caused by a missing series | 12:47 |
| bigjools | adeuring: we need to look at how it thinks there are packages in a distro that is not soyuz-maintained | 12:48 |
| bigjools | because there should be none | 12:48 |
| adeuring | ah, ok | 12:48 |
| bigjools | the upstream report should be empty | 12:48 |
| bigjools | AIUI anyway :) | 12:48 |
| adeuring | bigjools: yeah, I see it now. https://launchpad.net/archlinux is a completely empty distro, but the upstream report page crashes | 12:50 |
| === almaisan-away is now known as al-maisan | ||
| === mrevell is now known as mrevell-la-comid | ||
| === jtv is now known as jtv-afk | ||
| deryck | https://dev.launchpad.net/MaintenanceRotationSchedule | 14:03 |
| === mrevell-la-comid is now known as mrevell | ||
| === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap, jcsackett | https://code.launchpad.net/launchpad-project/+activereviews | ||
| === jtv-afk is now known as jtv | ||
| === henninge is now known as henninge-afk | ||
| LPCIBot | Project windmill build #204: STILL FAILING in 1 hr 3 min: https://lpci.wedontsleep.org/job/windmill/204/ | 14:31 |
| jcsackett | allenap: can you take a look at https://code.launchpad.net/~jcsackett/launchpad/remove-duplicate-settings/+merge/58529 for me? | 14:31 |
| allenap | jcsackett: Sure. | 14:31 |
| jcsackett | thanks! | 14:31 |
| deryck | jam, hi. Did you mean to target bug 437003 to lp series 2.1 and 2.2? | 14:38 |
| _mup_ | Bug #437003: Failure to autopack because of 'missing inventories' <missing-inventory> <mysql> <packs> <Bazaar:Fix Released by jameinel> <Bazaar 2.0:Fix Released by jameinel> <Launchpad itself:New> <Launchpad itself 2.1:New> <Launchpad itself 2.2:New> < https://launchpad.net/bugs/437003 > | 14:38 |
| allenap | jcsackett: r=me | 14:41 |
| jcsackett | allenap: thanks. | 14:42 |
| deryck | bigjools, hi. I'm not sure if bug 767258 is really a bug or if we just changed something? it's about ppa stats being different since feb. 10. | 14:45 |
| _mup_ | Bug #767258: weird PPA stats before Feb 10 <Launchpad itself:New> < https://launchpad.net/bugs/767258 > | 14:45 |
| * bigjools looks | 14:46 | |
| wgrant | deryck: I need to get hold of logs to investigate. | 14:47 |
| wgrant | There was significant changes deployed on that date. | 14:47 |
| bigjools | deryck: it would be a good idea to check other packages in other PPAs - it could be a genuine jump in his stats | 14:47 |
| wgrant | I *think* the new ones are correct. | 14:47 |
| wgrant | But I need to grab logs from both ends to verify manually. | 14:47 |
| deryck | wgrant, bigjools -- ok, cool. I'll triage it then. Thanks! | 14:48 |
| bigjools | ctrl-q FTL | 14:48 |
| deryck | jam, I see your other bug now. nevermind. :-) | 14:52 |
| === flacoste changed the topic of #launchpad-dev to: We have a 9s timeout!!! (2 months early | https://dev.launchpad.net/ | On call reviewer: allenap, jcsackett | https://code.launchpad.net/launchpad-project/+activereviews | ||
| === flacoste changed the topic of #launchpad-dev to: We have a 9s timeout!!! (2 months early!) | https://dev.launchpad.net/ | On call reviewer: allenap, jcsackett | https://code.launchpad.net/launchpad-project/+activereviews | ||
| bigjools | flacoste: \o/ | 14:53 |
| abentley | henninge-afk: we were supposed to chat, right? When would you like to do that? | 14:53 |
| flacoste | bigjools: yep, we did it! it was 20s last year | 14:55 |
| bigjools | flacoste: so are we going to aim for something lower before Dublin? ;) | 14:55 |
| wgrant | We have 260 criticals :( | 14:56 |
| jcsackett | wgrant: no raining on the parade. :-P | 14:56 |
| benji | 20s to 9s is indeed an achievement | 14:56 |
| flacoste | bigjools: nope, we now need to fix all the remaining critical bugs | 14:58 |
| flacoste | wgrant: thanks for the shipit cleanup! much appreciated | 14:58 |
| flacoste | no more proprietery links in our code base | 14:59 |
| flacoste | well, apart our branding of course :-/ | 14:59 |
| wgrant | flacoste: Heh, yes. I think it's all gone now, apart from the DB stuff. | 15:00 |
| bigjools | it'll be interesting to see how we hold up around ubuntu release time | 15:03 |
| wgrant | There's no ShipIt to destroy us this time (that's happened at least twice). | 15:04 |
| wgrant | Hmmmm. | 15:05 |
| magcius | I want to make UI enhancements to bugs... who should I talk to? | 15:12 |
| magcius | jam, oh, and I haven't given up on https://bugs.launchpad.net/569355 -- I'm trying to think some things through. | 15:14 |
| jam | magcius: That bug shows as 404, is there a different number? | 15:14 |
| magcius | https://bugs.launchpad.net/loggerhead/+bug/569355 | 15:14 |
| _mup_ | Bug #569355: Left margin in code view. <loggerhead:Triaged by jstpierre> < https://launchpad.net/bugs/569355 > | 15:14 |
| magcius | gah, you apparently need the +bug | 15:14 |
| magcius | That's dumb. | 15:14 |
| magcius | Bug numbers are global! | 15:15 |
| jam | magcius: http://pad.lv/569355 | 15:15 |
| jam | :) | 15:15 |
| wgrant | https://launchpad.net/bugs/569355 | 15:15 |
| _mup_ | Bug #569355: Left margin in code view. <loggerhead:Triaged by jstpierre> < https://launchpad.net/bugs/569355 > | 15:15 |
| magcius | One or the other, not both! | 15:15 |
| jam | mines shorter, wgrant | 15:15 |
| magcius | The URL is your UI too! | 15:15 |
| wgrant | jam: Mine's real :P | 15:15 |
| magcius | https://bugs.launchpad.net/569355 should work, no matter what. | 15:15 |
| magcius | But that's a separate bug. | 15:15 |
| jam | wgrant: both are redirects, I don't see how your's is more real than mine | 15:15 |
| wgrant | jam: Well, mine is official. | 15:16 |
| magcius | The most information I can see on that page. | 15:16 |
| magcius | Is in the smallest font size possible. | 15:16 |
| magcius | "John A Meinel: Needs Fixing on 2011-04-14" | 15:16 |
| magcius | Not to mention it's "Ready for review"... even though it's already reviewed. | 15:16 |
| magcius | If a reviewed branch is linked to a bug, then you should be able to see the comments in there. | 15:17 |
| jam | magcius: there is a link to the review page. Usually they are different discussions | 15:17 |
| magcius | A link that's in the smallest font on the page. | 15:17 |
| magcius | It took me four or five minutes to find the comments I've been receiving through email.. | 15:18 |
| jam | magcius: I set it back to WiP for you | 15:18 |
| magcius | Additionally, screenshot: http://i.imgur.com/ATjMV.png | 15:18 |
| magcius | I see three knobs: This bug affects me, Unsubscribe, and the (-) button next to my name in subscriptions. | 15:19 |
| magcius | How are they different? | 15:19 |
| magcius | Additionally, why is the status in the "Affects" grid -- doesn't a bug have one status? | 15:19 |
| jam | magcius: a bug may have different statuses in different projects, distributions, release series, etc. | 15:19 |
| magcius | How? | 15:20 |
| jam | loggerhead may have be suffering for something in bzr | 15:20 |
| jam | and we fixed it in bzr | 15:20 |
| jam | but loggerhead hasn't updated to use the new funciton | 15:20 |
| jam | function | 15:20 |
| magcius | That's not the same bug... is it? | 15:20 |
| jam | or we released a fix in bzr-2.3 but it isn't in bzr-2.2 | 15:20 |
| magcius | I'm confused. | 15:20 |
| magcius | How can a bug be "Fix Commited" in one project, but not in another? | 15:20 |
| magcius | There's more than one bug if there's more than one fix. | 15:21 |
| jam | magcius: because to finish off the bug it requires updating 2 code fixes | 15:21 |
| jam | magcius: only for someone who ties Issues 1:1 with code drops | 15:21 |
| jam | and even if you say different code bases need a different bug (I don't) | 15:21 |
| jam | you still have multiple versions of a code base within one project | 15:21 |
| magcius | "This isn't working" | 15:21 |
| magcius | "That's because bzr has a bug in this... bug 12345" | 15:21 |
| _mup_ | Bug #12345: isdn does not work, fritz avm (pnp?) <isdnutils (Ubuntu):Fix Released by doko> < https://launchpad.net/bugs/12345 > | 15:21 |
| jam | (the one in Maverick, the one in Natty, the one in Debian-sid, the one in...) | 15:21 |
| jam | magcius: I it may be fixed by *Debian* patches, and not upstream | 15:22 |
| magcius | jam, sure, then use the distro bug feature, not the project bug feature. | 15:22 |
| magcius | But meh. | 15:22 |
| magcius | Not worth fighting. | 15:22 |
| magcius | So... there's "Affects" | 15:22 |
| magcius | and right above it, it says the bug affects me. | 15:22 |
| magcius | Why? | 15:22 |
| jam | magcius: As a way to avoid "Me too" comments | 15:23 |
| magcius | OK, sure. | 15:23 |
| magcius | So a bug can affect users and projects. | 15:23 |
| magcius | And there's two different UIs for each. | 15:23 |
| magcius | er, a UI for each | 15:23 |
| magcius | What's the difference between "Unsubscribe" and clicking the (-) next to my name in Subscriptions? | 15:24 |
| magcius | I assume the user "affects" is just an accumulator, wheras Subscriptions is like the CC list in Bugzilla/ | 15:25 |
| magcius | Sorry for complaining, but I'm really confused after staring at this UI now. | 15:25 |
| jam | magcius: If you say "Affects me" I believe it adds you to the list, but doesn't email you when other people comment on the bug. Subscribing sends an email for any modification. I assume the (-) is the same as Unsubscribe, not sure, though. | 15:26 |
| magcius | OK, so we should remove the Unsubscribe and Subscribe other people | 15:26 |
| magcius | and keep the (-) and add a new "Add user..." button | 15:26 |
| wgrant | (-) was added to all subscriptions you can remove. This includes you and your teams. yes, it is duplicated with the (-) Unsubscribe link. | 15:26 |
| magcius | OK. | 15:27 |
| magcius | The fact that it displays incorrectly is a separate bug. | 15:27 |
| === al-maisan is now known as almaisan-away | ||
| magcius | Additionally, I'd like to dump the breadcrumbs under the bug title: "loggerhead >> Bugs >> Bug #569355 | 15:28 |
| magcius | " | 15:28 |
| _mup_ | Bug #569355: Left margin in code view. <loggerhead:Triaged by jstpierre> < https://launchpad.net/bugs/569355 > | 15:28 |
| magcius | That data isn't really useful at all, and it's already in the URL if we fix the URL :D | 15:28 |
| jam | magcius: I personally find the breadcrumbs very useful. | 15:28 |
| magcius | Really? | 15:28 |
| jam | yep | 15:28 |
| magcius | How? | 15:28 |
| jam | it is consistent between views as a way to "go up, but not all the way to the top" | 15:28 |
| magcius | Do you find it more useful than clicking on "Overview" or "Bugs"? | 15:29 |
| jam | magcius: It isn't huge when you are one deep. But stuff like: http://bazaar.launchpad.net/~daker/dexter-rolodex/fix.688511/view/24.1.5/data/media/background.png has breadcrumbs for the directory entries | 15:29 |
| magcius | (also, I'd like to either get rid of Overview and/or make the title clickable) | 15:29 |
| magcius | Oh, that's fine. | 15:30 |
| jtv | allenap: want to do a very simple review? https://code.launchpad.net/~jtv/launchpad/db-bug-768342/+merge/58685 | 15:30 |
| magcius | The breadcrumbs look completely different. | 15:30 |
| magcius | Well, they're not consistent between the "View" and "Files" views, but that's a separate bug. | 15:30 |
| allenap | jtv: Sure! | 15:31 |
| jtv | Thanks :) | 15:31 |
| magcius | But I have to click on the words "On hold" to get to the review comments/. | 15:31 |
| magcius | From the bug. | 15:31 |
| deryck | abentley, I'm reading bug 766242 as a bzr-builder issue, not launchpad. Am I reading that wrong? | 15:57 |
| _mup_ | Bug #766242: Launchpad bzr builder can't build from some ubuntu source branches <bzr-builder:New> <Launchpad itself:New> < https://launchpad.net/bugs/766242 > | 15:57 |
| abentley | deryck: no, it looks like a problem with the content of the branch. | 15:58 |
| abentley | deryck: per james' comment. | 15:58 |
| deryck | abentley, something we're doing to mess up the branch content? Or just in the branch itself? I'm not clear if it's a bug or not. | 15:58 |
| abentley | deryck: So that might be a package-importer bug. Not sure the provenance of the branch. | 15:58 |
| abentley | deryck: Neither am I, because I don't know whether the package-importer is at fault. | 15:59 |
| deryck | abentley, can you ask for more info then and set to incomplete? | 15:59 |
| abentley | deryck: james knows much more about this, and he's already involved, so I'd rather leave it to him. | 16:02 |
| deryck | abentley, fair enough. | 16:02 |
| abentley | james_w: do we know whether the broken contents of lp:ubuntu/cloud-init are a bug in our code? | 16:03 |
| james_w | abentley, bzr-builder, it isn't, other code, possibly, depends how it got that way | 16:03 |
| abentley | james_w: e.g. the package importer could have created the branch? | 16:04 |
| james_w | yes | 16:04 |
| abentley | james_w: how could we tell? | 16:05 |
| james_w | abentley, look at the committer of the last few revisions | 16:05 |
| abentley | james_w: it is Scott Moser. | 16:05 |
| james_w | or really, the first revision where the patches are applied but there is no .pc directory | 16:05 |
| jam | deryck: speaking of which, I have no way to *actually* target bzr-2.1 and bzr-2.2 on that bug, now that I've added Launchpad | 16:06 |
| jam | anything I can do? | 16:06 |
| jam | (There is only one Target to Series link, and it is doing the wrong thing) | 16:06 |
| abentley | james_w: for cloud-config-mcollective.txt, that is revno 90. | 16:10 |
| abentley | james: that's where it's created at least. | 16:10 |
| abentley | james_w: revno 90 also has no .pc directory. | 16:11 |
| james_w | abentley, this looks very much like a person error | 16:12 |
| abentley | james_w: Thanks for your help. | 16:17 |
| deryck | jam, can you not switch to the bzr context and it work? | 16:17 |
| * deryck is late for lunch with daughter and has to go now.... | 16:19 | |
| deryck | sorry | 16:19 |
| === deryck is now known as deryck[lunch] | ||
| === henninge-afk is now known as henninge | ||
| henninge | abentley: let's chat in like 20 minutes, ok? | 16:27 |
| abentley | henninge: sure. | 16:27 |
| magcius | ok, i'm just playing around with the design | 16:28 |
| magcius | http://i.imgur.com/FYY40.png | 16:28 |
| magcius | vs. http://i.imgur.com/ATjMV.png | 16:28 |
| magcius | oh whoops, I forgot the "me too" button | 16:30 |
| jtv | allenap: I'll have to be off very soon | 16:31 |
| henninge | abentley: actually, let's chat right now ... ;) | 16:32 |
| henninge | abentley: if that's ok? | 16:32 |
| abentley | henninge: sure. | 16:32 |
| allenap | Sorry jtv, for some reason that branch slipped from my memory :( I'll do it before I finish today. Sorry again. | 16:35 |
| jtv | allenap: no worries, I can get back to it tomorrow. Thanks. | 16:35 |
| === jtv is now known as jtv-afk | ||
| sinzui | jcsackett: can you review https://code.launchpad.net/~sinzui/launchpad/dsp-question-permissions-0/+merge/58705 ... Oh can we mumble first though. I want to talk about how hard queue question emails is. | 16:50 |
| jcsackett | sinzui: i can mumble, and then i will be happy to review the branch. | 16:50 |
| bigjools | ec2 is borked then ... :( | 16:52 |
| benji | bigjools: some of it is: http://status.aws.amazon.com/?a | 16:56 |
| benji | I wonder how hard it is to retarget to the North California region. | 16:56 |
| bigjools | I can't start my instance :( | 16:56 |
| bigjools | heh, it's kinda funny that the US-EAST status updates are timestamped in PDT | 16:57 |
| benji | heh, yeah I thought the same thing | 16:59 |
| bigjools | what defines which region we use for ec2 land? | 16:59 |
| allenap | bigjools: I /think/ it uses the default region as defined in boto. | 17:00 |
| * bigjools ponders a hack | 17:00 | |
| gary_poster | mrevell, hi, are we chatting? | 17:01 |
| mrevell | hi gary_poster, yes. Mumble? | 17:01 |
| gary_poster | mrevell sure | 17:01 |
| allenap | bigjools: ISTR that env variables can be used to override. I'm looking now. | 17:02 |
| bigjools | ah cool | 17:02 |
| bigjools | BOTO_CONFIG | 17:03 |
| bigjools | ? | 17:04 |
| magcius | OK, I know nobody is responding, but meh: http://i.imgur.com/5cdow.png | 17:05 |
| allenap | bigjools: In ~/.boto, add a [Boto] section, and ec2_region_name. It defaults to us-east-1. | 17:06 |
| allenap | s/and/and set/ | 17:06 |
| bigjools | coolio | 17:06 |
| bigjools | allenap: now, to figure out what the valid values are | 17:07 |
| bigjools | ah, the default one just started ... | 17:07 |
| bigjools | looks like eu-west-1 would work | 17:08 |
| allenap | bigjools: ap-northeast-1, ap-southeast-1, eu-west-1, us-east-1, us-west-1 | 17:08 |
| bigjools | you're a veritable mine of data | 17:09 |
| allenap | bigjools: python -c 'import boto; print ", ".join(sorted(rg.name for rg in boto.connect_ec2().get_all_regions()))' | 17:09 |
| === deryck[lunch] is now known as deryck | ||
| jcsackett | sinzui: i'm confused about one thing in your tests on the branch. the second test added says it's about an indirect contact being able to reject a question, but it looks to me like it's testing that the answerer can't reject. i assume i am misunderstanding something? | 17:46 |
| * sinzui checks diff and hopes he did not commit the verification that the assert will not fail | 17:47 | |
| dobey | hey guys | 17:47 |
| sinzui | jcsackett: self.assertTrue( | 17:48 |
| sinzui | 83+ getattr(self.question, 'reject'), | 17:48 |
| dobey | does anyone have any idea what the best way to give a "bot user" on LP permissions to view the members list of a private team would be? | 17:48 |
| sinzui | 84+ "Answer contact cannot reject question.") | 17:48 |
| jcsackett | Ah, yes. | 17:48 |
| sinzui | jcsackett: ^ If the assert fails you will see who cannot access the reject method | 17:48 |
| jcsackett | i was reading "assertEqual." so less misunderstanding, more visually imparied. | 17:48 |
| jcsackett | sinzui: r=me, and i think i need glasses. :-P | 17:49 |
| sinzui | dobey: I do not know the answer, but I know other teams have done that. I think some have also give them bot access to scripts via oauth. I do not think anyone has documented how to do this | 17:50 |
| sinzui | dobey: I think users are creating a profile (with an unique email address) for the bot. The bot uses LP API for manage resources. The bot owner does all the initial email confirmations and oauth approvals | 17:52 |
| dobey | sinzui: hrmm. so tarmac has this awesome feature that some awesome hacker wrote, where it can check that contributors are members of certain teams, for use with contributor agreement requirements. but as we're using it in u1, it only works half-heartedly right now, because one team we really need it to read, is private; and the bot isn't (nor should it be) a member of said team | 17:53 |
| dobey | sinzui: right. i alreaady have such a user, and have been using it for a while now. but there is a private team it needs to view member list of, without being a member itself | 17:54 |
| henninge | abentley: I have all checks reverting correctly now except for the first one (the productseries). What could be missing? | 17:54 |
| henninge | abentley: the branch is lp:~henninge/launchpad/devel-759606-ajaxify-delete-link if you want to have a look. | 17:54 |
| sinzui | dobey: That is a common problem. You cannot do it at this time. We often describe it as the owner is not a member problem, but your phrasing is closer to the disclosure feature that will start in a few weeks. There the goal is to allow owners to grant access to users without granting membership/control | 17:57 |
| sinzui | dobey: at this time, only a team member or owner can see all the members. The bot must be a member, or a member pulls information to a secure locate that the bot can access. | 17:58 |
| dobey | sinzui: is there any magical workaround we could use in the meantime? | 17:59 |
| dobey | hmm | 17:59 |
| abentley | henninge: I'll look at it in a minute. | 18:24 |
| mrevell | deryck, hey, bdmurray has an interesting comment on the blog. I think we have a help page clash ... I've been treating https://help.launchpad.net/Bugs/Expiry as the canonical bug expiry help page. I have to run now, but I'll fix this Monday ... if you have any comments though deryck, please do email me. Cheers. | 18:27 |
| mrevell | Bye all. I'll be back Monday. | 18:27 |
| * deryck looks at the blog, though mrevell will never know | 18:27 | |
| deryck | bdmurray is correct | 18:28 |
| bdmurray | \o/ | 18:29 |
| === beuno is now known as beuno-lunch | ||
| abentley | henninge: set_productseries needs an else clause that calls clear_link() like set_branch. | 18:40 |
| henninge | abentley: ah, thanks | 18:41 |
| henninge | abentley: I just pushed a new rev that shows the project link in the overlay. | 18:42 |
| abentley | henninge: Until now, it didn't need to handle the case where the link had a value but was being unset. | 18:42 |
| abentley | henninge: also, you don't need to explicitly call that.update_check(productseries_check); in set_checks. | 18:42 |
| henninge | abentley: Yeah, all working now! ;-) | 18:52 |
| abentley | henninge: great! | 18:52 |
| henninge | Well, I guess I should add some tests, too. | 18:52 |
| === beuno-lunch is now known as beuno | ||
| LPCIBot | Project windmill build #205: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/205/ | 19:02 |
| * magcius sighs | 20:00 | |
| abentley | allenap or jcsackett: could you please review https://code.launchpad.net/~abentley/launchpad/translation-sharing-details-permissions/+merge/58746 ? | 21:17 |
| jcsackett | abentley: sure. | 21:17 |
| abentley | jcsackett: thanks. | 21:18 |
| jcsackett | abentley: r=me. | 21:59 |
| abentley | jcsackett: thanks. | 21:59 |
| gary_poster | magcius did you ever get a reply? | 22:18 |
| gary_poster | lifeless, ping? | 22:18 |
| gary_poster | lifeless, in lp.registry.browser.tests.test_milestone.TestProjectMilestoneIndexQueryCount.test_more_private_bugs_query_count_is_constant there's a comment that we should not increase the query count. | 22:22 |
| gary_poster | I'd already adjusted my change (in code that this page, and others, call) to only increase the query count by 1, but I don't see a way to reduce the number further. | 22:22 |
| gary_poster | I was hoping you had some ideas on decreasing that query count quickly, so I can land my very small and very loosely related branch (https://code.launchpad.net/~gary/launchpad/owner_administrator/+merge/58683). | 22:22 |
| gary_poster | I don't see any, with a quick zoom through the code; all of the low hanging and some of the middle-hanging fruit that I can see have been picked. | 22:22 |
| lifeless | gary_poster: hi, its easter here :) | 22:24 |
| lifeless | gary_poster: I'll have a quick look though | 22:24 |
| gary_poster | magcius, if you see this, I suggest that you contact Jonathan Lange <jml@canonical.com> (who is out this week) and possibly also Huw Wilkins <huw.wilkins@canonical.com> (I don't know is availability) | 22:25 |
| gary_poster | thank you lifeless, and sorry to bother you | 22:25 |
| lifeless | gary_poster: can you pastebin the queries you see (should be an attachment to the failure) | 22:25 |
| gary_poster | lifeless sure 1 sec | 22:26 |
| gary_poster | lifeless http://pastebin.ubuntu.com/597156/ | 22:27 |
| gary_poster | lifeless line 15 is the new query fwiw | 22:28 |
| lifeless | so, one thing I see there is 5 separate person lookups after the initial user lookup | 22:28 |
| lifeless | gary_poster: an alternate reason suggests that the meat starts at line 20 | 22:31 |
| gary_poster | the meat of what? | 22:31 |
| magcius | gary_poster, thanks. | 22:31 |
| magcius | I'm working on making it into tangible HTML right now. | 22:32 |
| lifeless | gary_poster: the page | 22:33 |
| gary_poster | magcius awesome. Cool, I think Jonathan and Huw will be the ones who will have the perspective/authority to figure out how to run with your ideas. | 22:33 |
| lifeless | gary_poster: after the session update traversal is complete | 22:33 |
| gary_poster | lifeless, ah ok. So, I think I actually see what I can do. I think I can make the function I was working on issue less SQL. I'm not sure it will be a big win, but it would keep us under the numbers. Would you be alright with me landing the current branch, which I don't think will kill kittens, and then make a new bug and branch to start tomorrow to try and reduce the numbers for that one function? | 22:35 |
| lifeless | gary_poster: so you need to raise it by 1 ? | 22:35 |
| gary_poster | lifeless, yeah | 22:35 |
| gary_poster | static 1 | 22:35 |
| lifeless | gary_poster: sure, that ssounds fine | 22:35 |
| gary_poster | ok thanks lifeless. have a great holiday and thanks for help | 22:35 |
| lifeless | query count is just a proxy for efficiency | 22:35 |
| lifeless | so a reasoned change is always fine | 22:36 |
| gary_poster | cool | 22:36 |
| LPCIBot | Project windmill build #206: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/206/ | 23:02 |
| === jcsackett changed the topic of #launchpad-dev to: We have a 9s timeout!!! (2 months early!) | https://dev.launchpad.net/ | On call reviewer: allenap | https://code.launchpad.net/launchpad-project/+activereviews | ||
| === jcsackett changed the topic of #launchpad-dev to: We have a 9s timeout!!! (2 months early!) | https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | ||
| cody-somerville | ubuntuone-client 1.6.1-0ubuntu3 finished building on amd64 7 hours ago but hasn't published. Is this because natty is in pre-release freeze? | 23:24 |
| maxb | It looks published at https://launchpad.net/ubuntu/+source/ubuntuone-client/1.6.1-0ubuntu3/+buildjob/2490924 | 23:39 |
| maxb | Ah, I reckon this close to release the publisher cronjobs are probably in manual mode | 23:41 |
| maxb | That's certainly borne out by the timestamps at http://gb.archive.ubuntu.com/ubuntu/project/trace/ | 23:41 |
| maxb | cody-somerville: ^ | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
