| lifeless | ah, so the problem is that milestones are not unique | 00:00 |
|---|---|---|
| sinzui | StevenK, wgrant, mumble? | 00:01 |
| lifeless | sinzui: hi | 00:03 |
| lifeless | sinzui: milestones | 00:03 |
| lifeless | sinzui: are they meant to be per-series ? | 00:03 |
| sinzui | life no, their name space is per project, their parent is a series | 00:04 |
| sinzui | lifeless, ^ | 00:04 |
| lifeless | so its expected folk may have one bug, with two tasks on different series, and the same milestone on both tasks? | 00:04 |
| lifeless | or would that be an unusual use ? | 00:05 |
| sinzui | It is possible. the milestone is the release version. Project release versions are uniqu | 00:05 |
| lifeless | sinzui: so, when you're done with that call | 00:10 |
| lifeless | I'd like to talk through this with you | 00:10 |
| lifeless | to help me solve a quandry | 00:10 |
| sinzui | lifeless, I will be available to talk in ~30 minutes | 00:12 |
| lifeless | excellent | 00:12 |
| lifeless | I will fiddle with lxc containers until you ping me | 00:12 |
| LPCIBot | Project windmill-devel build #261: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill-devel/261/ | 00:14 |
| wgrant | sinzui: http://paste.ubuntu.com/630585/ | 00:23 |
| LPCIBot | Project db-devel build #653: STILL FAILING in 6 hr 9 min: https://lpci.wedontsleep.org/job/db-devel/653/ | 00:26 |
| wgrant | sinzui: http://paste.ubuntu.com/630589/ | 00:32 |
| sinzui | wgrant, thanks | 00:33 |
| LPCIBot | Project windmill-db-devel build #413: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/413/ | 00:35 |
| wallyworld_ | sinzui: i get this when i try the yui tests - https://pastebin.canonical.com/48843/ | 00:38 |
| wgrant | wallyworld_: Upgrade. | 00:39 |
| lifeless | sinzui: ping me whenever you are ready | 00:56 |
| timrc | jcsackett, woo | 00:57 |
| sinzui | lifeless, okay | 00:57 |
| lifeless | sinzui: is skype working for you atm ? | 00:58 |
| sinzui | lifeless, I suspect so | 00:59 |
| sinzui | I have sip too | 00:59 |
| lifeless | can we use skype? | 00:59 |
| === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugs: 205 - 0:[######=_]:256 | ||
| lifeless | sinzui: I'd prefer skype unless you have a different preference - its echo cancellation is very good | 01:00 |
| timrc | lifeless, this is not OEM-blessed work, but would it be valuable to remove buildd_secret from the web view? I'd be willing to look into it | 01:14 |
| lifeless | timrc: I think its only visible to admins atm, and useful for debugging | 01:15 |
| lifeless | timrc: IMBW | 01:15 |
| timrc | lifeless, that's a good point | 01:15 |
| lifeless | sinzui: if another time would be better, thats fine with me; I'm a little blocked till I resolve this however | 01:22 |
| sinzui | lifeless, We love to talk | 01:23 |
| lifeless | sinzui: I cxan't see you on skype | 01:23 |
| sinzui | lifeless, coming online now. | 01:25 |
| wallyworld_ | wgrant: sorry, i exited prematurely. you were still talking | 01:25 |
| wgrant | wallyworld_: Just complaining that libwebkitgtk-3.0-0-dbgsym is 250MB. | 01:26 |
| wallyworld_ | that's quite large for sure | 01:27 |
| cody-somerville | timrc, furthermore, its the only mechanism to change the buildd_secret if it were to get leaked without having to use SQL. | 01:27 |
| cody-somerville | timrc, but more importantly, congratz on getting your first change landed! :) | 01:27 |
| LPCIBot | Project devel build #824: STILL FAILING in 6 hr 32 min: https://lpci.wedontsleep.org/job/devel/824/ | 01:30 |
| === mwhudson_ is now known as mwhudson | ||
| lifeless | wgrant: I'm available to talk whenever you want about ubuntu disclosure / security bugs [sinzui says you know what this is about but he'll be email you regardless] | 02:04 |
| wgrant | lifeless: I shall await the email. | 02:05 |
| wgrant | sinzui: I have a somewhat symbolised backtrace now. | 02:08 |
| wgrant | sinzui: http://paste.ubuntu.com/630607/ | 02:17 |
| lifeless | hah | 02:27 |
| lifeless | sinzui: http://pastebin.com/85p07rfv makes my test pass; there is no sample data with series milestones outside of debian. ok with this? | 02:30 |
| sinzui | lifeless, I am | 02:31 |
| sinzui | wgrant, thank you very much | 02:32 |
| lifeless | woohoo, its lp-land time | 02:33 |
| wgrant | lifeless: It seems we have a regression. | 02:33 |
| wgrant | lifeless: Probably in flacoste's branch. | 02:33 |
| wgrant | 00134-09052@SQL-launchpad-main-master SELECT SourcePackagePublishingHistory.ancestor, SourcePackagePublishingHistory.archive, SourcePackagePublishingHistory.component, SourcePackagePublishingHistory.datecreated, SourcePackagePublishingHistory.datemadepending, SourcePackagePublishingHistory.datepublished, SourcePackagePublishingHistory.dateremoved, SourcePackagePublishingHistory.datesuperseded, SourcePackagePublishingHistory.distroseries, ... | 02:33 |
| wgrant | ... SourcePackagePublishingHistory.id, SourcePackagePublishingHistory.pocket, SourcePackagePublishingHistory.removal_comment, SourcePackagePublishingHistory.removed_by, SourcePackagePublishingHistory.scheduleddeletiondate, SourcePackagePublishingHistory.section, SourcePackagePublishingHistory.sourcepackagerelease, SourcePackagePublishingHistory.status, SourcePackagePublishingHistory.supersededby FROM Archive, ... | 02:34 |
| wgrant | ... SourcePackagePublishingHistory, SourcePackageRelease WHERE SourcePackagePublishingHistory.archive = Archive.id AND Archive.distribution = 1 AND Archive.purpose IN (1, 4, 7) AND SourcePackagePublishingHistory.sourcepackagerelease = SourcePackageRelease.id AND SourcePackageRelease.sourcepackagename = 31856 AND SourcePackagePublishingHistory.status IN (2, 1) ORDER BY SourcePackagePublishingHistory.id DESC LIMIT 1 | 02:34 |
| lifeless | wgrant: doing what? | 02:34 |
| lifeless | wgrant: it looks like it could be bug 721643 | 02:35 |
| _mup_ | Bug #721643: BugTask:+editstatus-page timeout changing source package <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/721643 > | 02:35 |
| wgrant | lifeless: It was editstatus, yeah. | 02:35 |
| lifeless | wgrant: changing the source package? | 02:35 |
| wgrant | lifeless: Indeed. | 02:36 |
| wgrant | But the query is different. | 02:36 |
| wgrant | I wonder if the archive join is killing it. | 02:37 |
| wgrant | Previously it named the IDs explicitly. | 02:37 |
| lifeless | 15K archives | 02:38 |
| lifeless | plenty of room for wtfs | 02:38 |
| wgrant | Could you perhaps explainalyze it on staging? | 02:39 |
| lifeless | pastebin the q somewhere for me ? | 02:39 |
| lifeless | or gimve me the oops id ? | 02:39 |
| wgrant | http://paste.ubuntu.com/630614/ | 02:40 |
| lifeless | wgrant: its going to be -terrible- cold | 02:44 |
| lifeless | wgrant: its been running for 4 minutes now | 02:44 |
| wgrant | lifeless: What if you drop the archive join and replace it with archive IN (1, 534)? | 02:44 |
| lifeless | http://paste.ubuntu.com/630616/ | 02:45 |
| lifeless | wgrant: 1.8 seconds hot | 02:45 |
| lifeless | without changing the q | 02:45 |
| wgrant | lifeless: That's still pretty slow. | 02:46 |
| wgrant | lifeless: What if you do change it? | 02:46 |
| lifeless | its not brillirant | 02:46 |
| lifeless | 74ms | 02:47 |
| lifeless | http://paste.ubuntu.com/630617/ | 02:47 |
| StevenK | 74ms isn't brilliant? | 02:48 |
| lifeless | 1800ms isn't brilliant | 02:48 |
| sinzui | wgrant, lifeless would the editstatus timeouts be less of an issue if we completed this bug: https://bugs.launchpad.net/launchpad/+bug/399756 | 02:49 |
| _mup_ | Bug #399756: Remove the inline bugtask edit form <javascript> <lp-bugs> <tech-debt> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/399756 > | 02:49 |
| wgrant | sinzui: Only marginally. | 02:49 |
| wgrant | sinzui: This query is enough to make a single AJAX request timeout anyway. | 02:49 |
| lifeless | sinzui: I don't think they are related | 02:49 |
| lifeless | sinzui: the inline form doesn't do that much more work | 02:50 |
| lifeless | wgrant: rollback time ? | 02:50 |
| lifeless | wgrant: or hotfix? | 02:50 |
| lifeless | wgrant: (you've looked at flacostes patch already I presume; I haven't) | 02:50 |
| wgrant | lifeless: It's >1000 lines, IIRC. | 02:51 |
| wgrant | So... Hm | 02:51 |
| wgrant | Possibly it's even the 2300 line branch. | 02:52 |
| wgrant | Yay | 02:52 |
| * wgrant goes digging. | 02:52 | |
| wgrant | Ah, mostly lint fixes. | 02:55 |
| wgrant | But so many :( | 02:55 |
| wgrant | lifeless: So, hotfix is tiny, if we want to. | 02:57 |
| wgrant | I'm not sure if we really want to roll back. | 02:57 |
| wgrant | Given the fun. | 02:57 |
| lifeless | no, its been traumatic | 02:57 |
| lifeless | lets hotfix | 02:58 |
| wgrant | k | 02:58 |
| wgrant | Preparing branch. | 02:58 |
| lifeless | preparing incident report | 02:58 |
| wgrant | Thanks. | 02:59 |
| lifeless | bug # ? | 03:03 |
| wgrant | None as yet. | 03:03 |
| wgrant | Will file if you want. | 03:03 |
| wgrant | But you seem to be handling the paperwork fine :P | 03:03 |
| lifeless | thanks :( | 03:03 |
| lifeless | and today I was finally hoping to do microservices. | 03:03 |
| wgrant | Well, what did you expect after 6 days :( | 03:04 |
| lifeless | epic fail? | 03:04 |
| wgrant | Yes. | 03:04 |
| lifeless | what rev broke stuff? | 03:04 |
| lifeless | and whats the OOPS id you have? | 03:04 |
| wgrant | 13263, OOPS-1999DR15 | 03:05 |
| wgrant | Probably not synced yet. | 03:05 |
| wgrant | But carob:~wgrant/logs/soybean/2011-06-22/05353.DR15, if you want it. | 03:05 |
| lifeless | nah | 03:06 |
| lifeless | just for the paperwork | 03:06 |
| lifeless | bug 800485 | 03:06 |
| _mup_ | Bug #800485: timeout changing sourcepackage names in bugs <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/800485 > | 03:06 |
| wgrant | Thanks. | 03:06 |
| wgrant | Tests pass with the fix, unsurprisingly. | 03:07 |
| wgrant | http://paste.ubuntu.com/630623/ | 03:07 |
| lifeless | diff ? | 03:07 |
| lifeless | thanks | 03:07 |
| lifeless | doit | 03:07 |
| lifeless | this may help that other timeout? or is it undoing a spurious change flacoste made? | 03:08 |
| wgrant | The latter. | 03:08 |
| wgrant | He Stormified the query, and changed it to use a nice join instead of nasty all_distro_archive_ids. | 03:09 |
| wgrant | But again, it has caused a performance issue :( | 03:09 |
| wgrant | Probably because SPPH is so skewed. | 03:09 |
| lifeless | ah | 03:10 |
| wgrant | sinzui: And what about apport bugs? :) | 03:53 |
| sinzui | wgrant, I do not know. Some or public some are private. I do not know its rules,, but I do not need to know why some of my bugs are private if we make apport behave like the current web UI | 03:55 |
| StevenK | The bugs are created private since the backtrace may contain private information. | 03:55 |
| sinzui | I wish apport was smart enough to know I do not have personal information in the bug an I really do want someone to see it | 03:56 |
| wgrant | The bugs start with only the robot subscribed. It processes the coredump into a retracted backtrace. | 03:56 |
| wgrant | It then makes a decision as to whether the backtrace should be kept private. | 03:57 |
| wgrant | If so, it subscribes the crash bug triagers. | 03:57 |
| sinzui | So apports visibility rules are not directly affected since they are not flagged as secuirty | 03:57 |
| wgrant | if not, it makes the bug public. | 03:57 |
| wgrant | sinzui: Right, but this would give Ubuntu owners direct access to sensitive passwords. | 03:57 |
| wgrant | So it is a change of behaviour. | 03:57 |
| sinzui | all six people? | 03:58 |
| LPCIBot | Project parallel-test build #58: STILL FAILING in 1 hr 1 min: https://lpci.wedontsleep.org/job/parallel-test/58/ | 03:58 |
| sinzui | wgrant, how can they not see them now? because they are not bug supervisors? They can change that at any moment | 03:59 |
| wgrant | sinzui: Hm? | 03:59 |
| wgrant | sinzui: Apport reports bugs with only the robot and the reporter subscribed. | 03:59 |
| wgrant | No bug supervisor is involved. | 03:59 |
| sinzui | ah, sorry. I misunderstood that. | 03:59 |
| sinzui | This somewhat relates to the IRobot discussion. I think the case here is that bug report is not finalised so is not in a full state. | 04:01 |
| wgrant | It's more similar to the security case. | 04:01 |
| wgrant | Which suggests that the security case is not really that special. | 04:01 |
| wgrant | Which suggests that it should not be much of a special case. | 04:02 |
| cody-somerville | "Launchpad requires that the project maintain(er) be a member of bug supervisor team." <-- I don't believe this is currently true. Are you proposing it become true? | 04:03 |
| sinzui | I think privacy mean personal data, which is the cited reason for hiding the bugs. | 04:03 |
| sinzui | cody-somerville, it is true, but I know how to break the rule. We have lots of orphaned bugs because the maintain changed *after* the bug supervisor was set | 04:04 |
| wgrant | It is not true. | 04:04 |
| wgrant | The fields are unrelated. | 04:04 |
| wgrant | Except that the maintainer can change the bug supervisor. | 04:04 |
| sinzui | I can set the supervisor to myself or a team I am in. I cannot set it to another team | 04:05 |
| lifeless | back | 04:05 |
| sinzui | Nope still cannot make ~zeitgeist mange the bugs in py projects | 04:07 |
| lifeless | sinzui: or a team you own ? | 04:07 |
| sinzui | lifeless, I must be a team admin | 04:08 |
| lifeless | sinzui: ownership grants Launchpad.Admin | 04:08 |
| sinzui | Yes, that also mean I can make myself a member when ever I chose. I did that two weeks ago and bac could not stop me | 04:09 |
| lifeless | sinzui: yup, thats what we agreed on wasn't it ? | 04:09 |
| sinzui | yes it was. | 04:10 |
| lifeless | I do wonder, perhaps project owners should be able to set any team as supervisor | 04:10 |
| sinzui | I have all the access I want | 04:10 |
| lifeless | but thats a different discussion | 04:10 |
| lifeless | testblahblah might be a junk project :( | 04:11 |
| sinzui | I think users need to say they need to do that. Ubuntu and canonical projects use bugs and security differently than everyone else | 04:12 |
| LPCIBot | Project windmill-db-devel build #414: STILL FAILING in 1 hr 13 min: https://lpci.wedontsleep.org/job/windmill-db-devel/414/ | 04:24 |
| lifeless | sinzui: I have replied | 04:27 |
| lifeless | sinzui: I have some bits I don't understand yet | 04:27 |
| lifeless | sinzui: and perhaps some confusion | 04:27 |
| lifeless | sinzui: I think apport is quite easily fixable in the very short term, with a crash db being the long term fix. | 04:28 |
| wgrant | People don't read :( | 04:33 |
| wgrant | /projects/+new says "You do not need to register a project to: [...] Activate a PPA" | 04:33 |
| jtv | StevenK, wgrant: mind if I restart the appserver on dogfood? | 04:49 |
| wgrant | jtv: Please do. | 04:51 |
| jtv | thanks | 04:51 |
| wgrant | lifeless: The primary archive does use a-f. | 04:55 |
| lifeless | wgrant: the bug is about ppas | 04:56 |
| wgrant | lifeless: But the slowness that Julian speaks of is a-f. | 05:03 |
| lifeless | yes | 05:04 |
| lifeless | I read the cache comment as 'can you not jus tuse a-ft with a cache db to get ppa contents.gz working | 05:04 |
| lifeless | ' | 05:04 |
| lifeless | to which the answer is no, we don't use a-f for ppa contents.gz | 05:04 |
| lifeless | wgrant: do I have something wrong in that logic? | 05:07 |
| LPCIBot | Project windmill-devel build #262: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill-devel/262/ | 05:07 |
| StevenK | lifeless: Right, we do not use a-f for PPAs | 05:08 |
| StevenK | lifeless: Who is asking about Contents for PPAs? | 05:08 |
| lifeless | there was a comment in the bug about it | 05:08 |
| StevenK | https://bugs.launchpad.net/launchpad/+bug/796997 is tracking my work on it, but it *will* be slow going. | 05:09 |
| _mup_ | Bug #796997: Contents generation should be done from the database <qa-untestable> <soyuz-publish> <Launchpad itself:In Progress by stevenk> < https://launchpad.net/bugs/796997 > | 05:09 |
| lifeless | StevenK: yeah, its fine | 05:09 |
| lifeless | he was suggesting using a-f with the cache switch, which is just irrelevant for contents.gz w/ ppas | 05:09 |
| StevenK | I doubt I can populate BRPC for a bit. 6.6 million BPRs with unexpired .debs | 05:10 |
| lifeless | yeah | 05:10 |
| lifeless | its pending the disk space increase as much as anything | 05:11 |
| StevenK | Right | 05:11 |
| StevenK | I figure I can take it slow, wait for db-stable to get merged into devel, and work from that. | 05:11 |
| lifeless | sure | 05:11 |
| lifeless | though if you are not modifying existing tables, you can add the new ones live | 05:11 |
| lifeless | no downtime | 05:11 |
| * StevenK shrugs | 05:12 | |
| StevenK | My brain is hardwired for "any changes to the db == db-devel" | 05:12 |
| lifeless | hopefully that will be history in a few weeks. | 05:13 |
| StevenK | Excellent. Then I can progres to "any change to the db == " *SEGV* | 05:13 |
| StevenK | I have a play branch, I'll be hitting up mawson probably at the sprint | 05:14 |
| wgrant | Hahaha | 06:08 |
| StevenK | Hmm? | 06:10 |
| wgrant | http://people.canonical.com/~wgrant/launchpad/big-plans.png | 06:10 |
| wgrant | Should I be scared? | 06:10 |
| StevenK | Bwahaa | 06:10 |
| wgrant | Grar. | 06:10 |
| wgrant | RT | 06:11 |
| wgrant | DIE | 06:11 |
| wgrant | I can't Cc myself to stuff :( | 06:11 |
| wgrant | So, let's see this query plan. | 06:11 |
| wgrant | It is obscene. | 06:11 |
| wgrant | Perhaps we just want to bite the bullet and create a summary table. | 06:12 |
| lifeless | 404 | 06:15 |
| lifeless | wgrant: what situation ? | 06:16 |
| wgrant | lifeless: Efficient querying of binary and source publication presence and overrides. | 06:17 |
| wgrant | lifeless: By name. | 06:17 |
| wgrant | At the moment we have to join through BPR to BPPH. | 06:17 |
| lifeless | yes | 06:17 |
| wgrant | Since there's no name on BPPH. | 06:17 |
| lifeless | Can denorm that onto it | 06:17 |
| wgrant | Probably. | 06:17 |
| lifeless | if that will fix the queries, its a perfectly cromulent solution | 06:17 |
| wgrant | Guess it wouldn't be that big. | 06:17 |
| wgrant | Let's see what happens... | 06:18 |
| lifeless | wgrant: what was the png ? | 06:19 |
| wgrant | lifeless: A half-fullscreen terminal. | 06:20 |
| StevenK | Amusing, is what it was. | 06:20 |
| wgrant | The top half has the word QUERY in it. | 06:20 |
| wgrant | The bottom half was the seperator at the top of the table. | 06:20 |
| lifeless | heh | 06:20 |
| wgrant | None of the actual plan fit on the screen. | 06:20 |
| wgrant | Because it is so hideous. | 06:20 |
| wgrant | HIDEOUS | 06:20 |
| wgrant | Let's see if mawson melts... | 06:20 |
| LPCIBot | Project db-devel build #654: STILL FAILING in 5 hr 58 min: https://lpci.wedontsleep.org/job/db-devel/654/ | 06:24 |
| LPCIBot | Yippie, build fixed! | 07:07 |
| LPCIBot | Project devel build #825: FIXED in 5 hr 37 min: https://lpci.wedontsleep.org/job/devel/825/ | 07:07 |
| wgrant | Hm. | 07:10 |
| wgrant | So those two persistent codeimport failures are gone? | 07:10 |
| StevenK | I think they've moved from persistent to spurious | 07:12 |
| StevenK | Wait, wrong word :-/ | 07:12 |
| wgrant | s/spurious/intermittent/? | 07:12 |
| StevenK | Right | 07:12 |
| jtv | StevenK, wgrant: either of you willing to offer a shoulder to cry on? Got a bit of a soyuz question. | 07:43 |
| wgrant | jtv: Fire away | 07:43 |
| jtv | Thanks. It's about how the +queue view batch-loads the various items associated with a batch of PackageUploads. | 07:44 |
| wgrant | Oh dear. | 07:44 |
| wgrant | "Slowly" | 07:44 |
| wgrant | "Awkwardly" | 07:44 |
| jtv | AFAICT it retrieves the PackageUploadBuilds in self.builds_dict. | 07:44 |
| jtv | That starts with BinaryPackageReleases. | 07:45 |
| nigelb | I guess working on LP eventually does eventually need a shoulder to cry on. | 07:45 |
| jtv | From there, it collects the builds. | 07:45 |
| * jtv looks up what those are | 07:45 | |
| wgrant | nigelb: Particularly Soyuz, yeah. | 07:45 |
| wgrant | jtv: Odd, it shouldn't be able to start with BinaryPackageReleases. | 07:45 |
| jtv | BinaryPackageBuilds. | 07:45 |
| nigelb | wgrant: And here I thought Blueprints were bad. | 07:45 |
| wgrant | jtv: Since it goes PU -> PUB -> BPB -> BPB | 07:45 |
| wgrant | BPB -> BPR, sorry. | 07:45 |
| jtv | Don't worry, I hadn't gotten that far yet. :) What's the correct line then? | 07:46 |
| wgrant | ? | 07:46 |
| jtv | PU → PUB → BPB → BPR? | 07:46 |
| wgrant | Yes. | 07:46 |
| * jtv decodes | 07:46 | |
| jtv | Ah yes | 07:46 |
| jtv | In my case, I'm more interested in the SPR than the BPR but it's much the same story otherwise. | 07:47 |
| wgrant | PUS → PUS → SPR | 07:47 |
| wgrant | Grar | 07:47 |
| wgrant | PU → PUS → SPR | 07:47 |
| jtv | I thought the FKs go PU ← BUB → BPB → SPR | 07:47 |
| StevenK | One of your arrows is backward | 07:47 |
| wgrant | No, it's right. | 07:47 |
| jtv | Don't worry about the PUS; I think those aren't related to my current problem. | 07:48 |
| wgrant | PU ← PUB → BPB ← BPR | 07:48 |
| jtv | I'm interested in the chain from PUB to SPR. | 07:48 |
| wgrant | Why? | 07:48 |
| wgrant | That's not normally something you want to do. | 07:48 |
| * jtv images the rest of the LP team looking on in bafflement | 07:48 | |
| jtv | In this particular case, I need to find the PS. | 07:49 |
| jtv | Packageset, sorry. | 07:49 |
| wgrant | Normally it'd be PU ← PUS → SPR → SPR | 07:49 |
| wgrant | Ah. | 07:49 |
| StevenK | SPR -> SPR? WTF? | 07:49 |
| jtv | StevenK: ISWYM | 07:49 |
| wgrant | StevenK: SourcePackageRelease → SourcePackageRecipe | 07:49 |
| wgrant | Except I am wrong. | 07:49 |
| jtv | OIC — WTF indeed | 07:49 |
| wgrant | PU ← PUS → SPR → SPRB → SPR | 07:50 |
| StevenK | Right | 07:50 |
| wgrant | jtv: So, for a source upload you wouldn't go near PUB. | 07:50 |
| wgrant | Why are you trying to? | 07:50 |
| jtv | I'm not saying it has to be a source upload. | 07:51 |
| StevenK | AssertionError: [] is not [] | 07:51 |
| jtv | Why would there even be a PUB for a source upload? | 07:51 |
| StevenK | Sorry?! | 07:51 |
| wgrant | jtv: There wouldn't be. But I'm not sure we care about Packagesets for binary uploads now. | 07:51 |
| jtv | StevenK: you're creating empty list objects with different identities. | 07:51 |
| wgrant | jtv: If you want to, it's PU ← PUB → BPB → SPR | 07:51 |
| StevenK | Oh, right | 07:51 |
| StevenK | Sigh | 07:51 |
| StevenK | Stupid Python | 07:51 |
| jtv | wgrant: true—maybe I should go back to what my real problem is. | 07:52 |
| jtv | Which is that I'm missing the packageset "core" for a PU for netapplet 0.99.6-1 in the sample data. | 07:52 |
| jtv | (Fun with doctests) | 07:52 |
| wgrant | jtv: What have you changed? | 07:53 |
| wgrant | Is it a mixed upload? | 07:53 |
| jtv | I'm not sure. It's listed as (source) but that may be sort of a straw to clutch at. | 07:53 |
| jtv | The packagesets do work for alsa-utils, which also says it's (source). | 07:54 |
| jtv | And the packgesets look pretty simple to me, when it comes to source uploads. | 07:54 |
| jtv | Ahhh, maybe they're not actually. | 07:54 |
| jtv | Because again, the view doesn't go straight through the PUS to get the SPR. It goes through SPRF. | 07:55 |
| wgrant | Hm? SPRF is at the end. | 07:55 |
| wgrant | After SPR | 07:56 |
| jtv | Should be, yes. | 07:58 |
| jtv | That's what you get when documentation simply says things like "a list of SPRs" without being precise about which ones they are. | 07:59 |
| wgrant | Hm? | 08:00 |
| adeuring | good morning | 08:01 |
| jtv | hi adeuring | 08:02 |
| adeuring | hi jtv! | 08:02 |
| jtv | wgrant: I can see now that the view probably needs a bit of tightening up of these access routes. It should bulk-load classes in a more sensible step-by-step manner, following the primary access paths. | 08:03 |
| wgrant | jtv: Indeed. It was one of the earlier places to do preloading. | 08:03 |
| jtv | I think I walked into a trap because I wasn't familiar with the "natural" access paths. That's going to be a growing risk, or source of friction, with squads. | 08:04 |
| wgrant | Mm. | 08:05 |
| wgrant | Everyone will be familiar with the model eventually. | 08:05 |
| jtv | But how long will it take and how hard will it be? | 08:08 |
| wgrant | A while and not terribly. | 08:08 |
| wgrant | I even know translations somewhat now. | 08:09 |
| jtv | I suspect the rest of LP is relatively easy when you started with soyuz! | 08:09 |
| wgrant | Fair point. | 08:09 |
| jtv | Also, I'm pretty sure that a lot of the Soyuz knowledge will suffer from degrading memory _and_ code changes after a few rotations on other stuff. | 08:10 |
| wgrant | I don't know about others, but it's pretty irrevocably scarred into my mind. | 08:11 |
| jtv | Good, that's one innocence ruined; who's next? | 08:11 |
| jtv | I think an investment in clarity here would pay off handsomely, both in terms of performance and in terms of developer effectiveness. | 08:11 |
| jtv | \o/ got that test passing! | 08:12 |
| jtv | Wonder how many others I broke. | 08:12 |
| wgrant | What criminal act have you performed on the view? | 08:12 |
| jtv | Bulk-loaded PUS, SPR, Packageset. | 08:13 |
| jtv | Also, we have put… a bag over its head. | 08:13 |
| wgrant | Ah, excellent. | 08:13 |
| jtv | (Because the Blackadder angle was just too good to resist) | 08:13 |
| wgrant | I had a branch that trialled that long, long ago. Before it was accepted that we could bulk-load collections. | 08:14 |
| wgrant | Because it issues so many queries :( | 08:14 |
| jtv | Quite. | 08:14 |
| jtv | I suspect some of the complexity would evaporate from that view if we would just take the bulk-loading one step at a time. | 08:14 |
| wgrant | It needs to be ripped out and replaced. | 08:15 |
| jtv | Right now there's a fair amount of "I've got objects at step 1 in the reference chain; get me the ones at step 3." | 08:15 |
| wgrant | The bulk-loading is rather messy. | 08:15 |
| wgrant | Needs to be redone with helpers. | 08:15 |
| jtv | Well yes, ripping out would feel good too. | 08:15 |
| wgrant | And sense. | 08:15 |
| jtv | One thing that bothers me about the whole thing is that we _could_ fetch the PUS/PUB/PUC and so on in Ajax as you fold open one queue item in the UI, _but_ we still need to know that they're there so we can decorate each with the right icons. | 08:16 |
| jtv | Which reminds me… | 08:16 |
| wgrant | Yes. | 08:16 |
| wgrant | They're very cheap to get, though. | 08:16 |
| wgrant | Just have to remove the scaling. | 08:16 |
| jtv | …do we have any icon that we might use to represent a package sync? | 08:16 |
| wgrant | We do not. | 08:16 |
| wgrant | I think Julian was going to talk to Huw about that. | 08:16 |
| wgrant | Or something. | 08:16 |
| wgrant | but it's been a while. | 08:16 |
| wgrant | You see we're sort of scratching for icons already. | 08:17 |
| wgrant | Which is why we use the Ubuntu logo for translations... | 08:17 |
| wgrant | Maybe not translations. | 08:17 |
| wgrant | Maybe it was dist-upgraders and debian-installerse. | 08:17 |
| jtv | (The page could also do with some sprites) | 08:17 |
| wgrant | But something that shouldn't have the Ubuntu logo, anyway. | 08:17 |
| jtv | Yes, saw some of that. | 08:17 |
| jtv | Actually it's quite easy to see in my new code: | 08:17 |
| jtv | I've got a method that says "here's a list of icons you may need; for each you get condition, alt, title, image name. Now spit out HTML for the ones that apply." | 08:18 |
| wgrant | Excellent. | 08:18 |
| jtv | I'm hoping that a future step could also notice that "hang on, I have a sprite for this somewhere." | 08:19 |
| jtv | Even further into the future though, maybe we could just render PUs though and have the icons filled in asynchronously. | 08:19 |
| jtv | wgrant: you wouldn't be interested in reviewing my view change by any chance? It's about a thousand lines, but it might give you some satisfaction. | 08:20 |
| wgrant | jtv: It would be quite satisfying to review cleanup of that view. | 08:20 |
| jtv | It's not a full cleanup by any stretch of the imagination, but I hope a step in the right direction. I'm hoping that CompletePackageUpload will evolve into a PackageUploadView. | 08:21 |
| jtv | wgrant: might it make sense to use copy.png for a PCJ upload? | 08:27 |
| wgrant | jtv: Not sure. | 08:28 |
| wgrant | It probably makes more sense in the translations UI. | 08:28 |
| jtv | wgrant: I guess copy.png is for the action, rather than as a description. "Sync" icons are a dime a dozen though; I suppose the world has a fairly well-defined idea what they look like. | 08:31 |
| lifeless | yeah | 08:35 |
| lifeless | so we should do something different P | 08:35 |
| jtv | In this case, I doubt that would help. | 08:36 |
| danilos | hum, anyone knows if we have trouble accessing SF SVN branches? (re question https://answers.launchpad.net/launchpad/+question/162211, "svn ls" works for me) | 08:44 |
| jtv | danilos: they used to block us, though I thought that was resolved. | 08:44 |
| jtv | And hi. :) | 08:44 |
| jtv | wgrant: would you be willing to review my branch? | 08:44 |
| danilos | jtv, hi :) | 08:44 |
| jtv | which reminds me | 08:44 |
| jtv | current topic is: https://dev.launchpad.net/ | On call reviewer: StevenK,jtv | Critical bugs: 205 - 0:[######=_]:256 | 08:44 |
| === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK,jtv | Critical bugs: 205 - 0:[######=_]:256 | ||
| === lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK,jtv | Critical bugs: 211 - 0:[######=_]:256 | ||
| wgrant | :( | 08:46 |
| danilos | jtv, which reminds me... | 08:47 |
| jtv | lots of embarrassed coughing all around ☺ | 08:47 |
| === danilos changed the topic of #launchpad-dev to: lifeless промени тему у https://dev.launchpad.net/ | On call reviewer: StevenK, jtv, danilo | Critical bugs: 211 - 0:[######=_]:256 | ||
| jtv | promeny temy? | 08:47 |
| danilos | haha | 08:48 |
| === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK, jtv, danilo | Critical bugs: 211 - 0:[######=_]:256 | ||
| jtv | ah, same word as "theme," right? | 08:48 |
| jtv | Greek "thema" | 08:48 |
| danilos | jtv, yeah, "promeni temu" :) | 08:48 |
| jtv | subject | 08:48 |
| lifeless | I changed the topic? yes I did | 08:49 |
| danilos | lifeless, I didn't have to put that fact in the topic, though :) | 08:49 |
| jtv | regardless of language :) | 08:49 |
| lifeless | indeed :) | 08:49 |
| jtv | "Extra! Extra! lifeless has changed the topic! Read all about it." | 08:49 |
| danilos | jtv, btw, other than the +languages/xx page, do you think dropping tm__language__submitter__idx could harm anything else? (if you can remember anything off the top of your big, bald head) | 08:50 |
| jtv | danilos: err.. POFile filter? | 08:50 |
| jtv | Which I know you've been looking at… | 08:50 |
| danilos | jtv, it actually seems to help that :) | 08:50 |
| jtv | wow | 08:50 |
| jtv | That may mean that the index actually needed more columns. | 08:51 |
| danilos | jtv, not surprising, considering the index is for a (language, submitter), and for those active translators, it's going to be more | 08:51 |
| danilos | jtv, yeah, I am trying to add potmsgset in | 08:51 |
| lifeless | allenap: if you used a temp table, did you analyze it first ? | 08:51 |
| danilos | jtv, unfortunately, if I just add another index, postgres still uses tm__language__submitter__idx even after analyze | 08:52 |
| jtv | danilos: I believe you've been looking at putting TM in a different type of DB… some less radical things that I think might help include: using arrays for msgstr1…msgstr5 and moving the is_current_u* flags out of the table. | 08:52 |
| lifeless | danilos: whats the new index you added ? | 08:52 |
| jtv | danilos: maybe the fields are in an inconvenient order? | 08:52 |
| jtv | lifeless: any chance of us getting hypothetical indexes? | 08:53 |
| lifeless | danilos: (perhaps the index is being selected due to sort order; making sure the columns match the sort order both left->right and asc/desc) | 08:53 |
| lifeless | jtv: is it in 9.0 ? :) | 08:53 |
| jtv | It's a 3rd-party patch. | 08:53 |
| jtv | I think on 8.something & up. | 08:53 |
| jtv | http://pqxx.org/development/libpqxx/wiki/HypotheticalIndexes | 08:53 |
| lifeless | jtv: http://sourceforge.net/projects/hypotheticalind/ ? | 08:53 |
| jtv | I think that's the one, yes | 08:53 |
| jtv | I got them to put up some documentation a while ago. :-) | 08:54 |
| danilos | lifeless, hum, interesting, never tried that out | 08:54 |
| lifeless | ah, I see | 08:54 |
| jtv | postgres does know reverse index scans though. | 08:55 |
| danilos | jtv, let me read through that as well :) I love all things hypothetical | 08:55 |
| lifeless | danilos: when pg can satisfy the requested sort from index, it will take that index even if it makes things worse (AFAICT) - perhaps our query cost estimators are whack. | 08:55 |
| jtv | lifeless: that would indicate a problem with cost estimation, yes. | 08:55 |
| lifeless | danilos: so if you have a better index and its competing on a sort-matching index, you need to make the better one also sort-match. | 08:55 |
| jtv | We may even have tried too hard to _make_ it use indexes. | 08:55 |
| danilos | lifeless, in this particular case, it's sorting by things outside this index, so doesn't seem related | 08:55 |
| lifeless | ok | 08:56 |
| danilos | jtv, lifeless: I get roughly an order of magnitude improvement just by dropping the index for the query from bug 534203 | 08:56 |
| _mup_ | Bug #534203: Timeouts on POFile:+filter (filter by person) <lp-translations> <timeout> <Launchpad itself:Triaged by danilo> < https://launchpad.net/bugs/534203 > | 08:56 |
| jtv | danilos: it may be interesting to learn what index the optimizer uses instead on the faster query, and comparing that to the one you dropped. | 08:56 |
| lifeless | danilos: yeah, I saw the comments. | 08:56 |
| lifeless | danilos: I'm fine with dropping the index FWIW, if we fairly sure nothing else is thrown out. | 08:57 |
| danilos | jtv, well, I did look into it, which is why I thought adding potmsgset in would help :) | 08:57 |
| jtv | danilos: but you didn't enlighten us. :) | 08:57 |
| lifeless | [unless the index is needed for FK cascade deletes] | 08:57 |
| jtv | I think we have separate indexes for each FK. | 08:58 |
| danilos | jtv, heh, right, I did that in the bug report | 08:58 |
| LPCIBot | Project parallel-test build #59: STILL FAILING in 1 hr 16 min: https://lpci.wedontsleep.org/job/parallel-test/59/ | 08:59 |
| danilos | jtv, so, I am just creating tm__potmsgset__language__submitter__idx and dropping the tm__language_submitter__idx and I'll see how that works | 08:59 |
| lifeless | jtv: hypotheticals : +1 for dev, staging, qastaging. | 08:59 |
| lifeless | jtv: -0 for prod | 08:59 |
| jtv | Of course. | 08:59 |
| danilos | jtv, this hypothetical indexes stuff sounds very cool! | 08:59 |
| jtv | Yes, it means you can just shower your tables with indexes just to see what the ideal ones would be. | 09:00 |
| lifeless | o/~ its raining indices | 09:00 |
| jtv | ? | 09:00 |
| lifeless | jtv: its raining men, shower, - I have a weird associational memory | 09:01 |
| jtv | But what is "o/~"? | 09:01 |
| jtv | a horizontal shower? | 09:02 |
| lifeless | oh, a note symbol from sheet music | 09:02 |
| lifeless | e.q. quaver | 09:02 |
| jtv | argh | 09:02 |
| LPCIBot | Project windmill-db-devel build #415: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/415/ | 09:02 |
| jtv | I would've thought something like d^ | 09:03 |
| lifeless | indeed, I didn't invent it :) | 09:03 |
| allenap | lifeless: I did. I tried a temp table and, iirc, a couple of variations on WITH. The temp table improved thing marginally, but there was still that 300000+ rows loop in the plan. The WITH clause reduced execution time from ~6s to <2s, but the UNION approach got it down to ~0.7s. | 09:04 |
| lifeless | allenap: did you compare the plans ? | 09:04 |
| lifeless | allenap: I want to know whats going wrong | 09:04 |
| * jtv thought allenap claimed to invent the ascii quaver | 09:04 | |
| allenap | lifeless: I still have them. I'll organize them and attach them to the bug report. | 09:05 |
| lifeless | allenap: its thinking that the selectivity is all whack | 09:05 |
| lifeless | allenap: the union thing uhm, freaks me. | 09:05 |
| allenap | lifeless: Yeah! It's a like a weird hack. | 09:06 |
| lifeless | I can't look into it tonight, but I will happily have a fiddle around tomorrow | 09:06 |
| lifeless | sinzui: bug 800544 | 09:13 |
| _mup_ | Bug #800544: series milestone tasks not shown on project|distro scope bug portlets <bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/800544 > | 09:13 |
| henninge | Hey danilos! ;) | 09:23 |
| danilos | henninge, hey-hey, how's it going? | 09:23 |
| henninge | danilos: good, I have the next two days off ... ;-) | 09:23 |
| lifeless | henninge: nice | 09:24 |
| danilos | henninge, yeah, sounds nice, so I better get hold of you for a chat today :) | 09:24 |
| henninge | danilos: this morning, I'll already be travelling in the afternoon. | 09:25 |
| jml | yo | 09:25 |
| danilos | henninge, how about in 35 mins then? I just want to finish some performance testing first | 09:25 |
| jml | 'sup dawgs? | 09:25 |
| jml | (also, would someone kindly glance at <https://code.launchpad.net/~jml/launchpad/buildd-cleanups/+merge/65378>)? | 09:25 |
| lifeless | stuff | 09:25 |
| henninge | danilos: sounds good | 09:25 |
| danilos | henninge, cool, talk to you then | 09:26 |
| henninge | ok | 09:26 |
| === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv, danilo | Critical bugs: 211 - 0:[######=_]:256 | ||
| allenap | lifeless: https://bugs.launchpad.net/launchpad/+bug/798301/+attachment/2177909/+files/plans.txt | 09:28 |
| _mup_ | Bug #798301: Time-out on +localpackagediffs <derivation> <timeout> <Launchpad itself:In Progress by allenap> < https://launchpad.net/bugs/798301 > | 09:28 |
| danilos | jml, looks good, r=me | 09:29 |
| jml | danilos: thank you. | 09:29 |
| StevenK | bigjools: Are you feeling better? | 09:31 |
| bigjools | StevenK: quite a lot better thanks | 09:31 |
| jtv | huwshimi: I think we need a new icon, to mark package uploads in the UI that are "package synchronizations." | 09:49 |
| huwshimi | jtv: OK. I'm not familiar with that part of LP. What's the difference? | 09:50 |
| lifeless | huwshimi: have you heard of soyuz ? | 09:50 |
| huwshimi | lifeless: Of course :) | 09:50 |
| jtv | Hi. This is soyuz, and only a small group of people really need to deal with it. A package upload can be a source upload, or contain builds, or contain translation tarballs, and so on. | 09:50 |
| * lifeless gets out before the dogpile is too large :P | 09:51 | |
| jtv | A new item they can have attached is a job to sync a package. | 09:51 |
| huwshimi | jtv: And is that a transitory status? | 09:52 |
| bigjools | wgrant: hello | 09:53 |
| jtv | Only to the extent that the package upload object itself is. This copy job will be its raison d'être. | 09:53 |
| jtv | So it's more a characterization of the object you're looking at. | 09:53 |
| bigjools | jtv: I don' think you need to block on this BTW | 09:53 |
| jtv | bigjools: I'm not, but might as well get it going. :) | 09:53 |
| bigjools | ok :) | 09:54 |
| jtv | allenap: the performance problem isn't simply a matter of running out of work_mem? | 09:54 |
| allenap | jtv: Absolutely no idea! | 09:55 |
| allenap | jtv: Can I tweak that before running the query? | 09:55 |
| jtv | allenap: you could, but it's just a tiny bit nasty to do that as a matter of course. | 09:55 |
| lifeless | jtv: its selecting a 300K row scan | 09:55 |
| jtv | But it's something you can try in-session while experimenting on any of the test dbs. | 09:55 |
| jtv | lifeless: so it's a quantum leap to a different plan then, not a gradual increase in run time? | 09:56 |
| huwshimi | jtv: Maybe you can provide a bug for this with a screenshot of what we currently have. | 09:56 |
| jtv | (for some value of "gradual" of course) | 09:56 |
| huwshimi | jtv: Is this part of a feature you're working on? | 09:56 |
| jtv | huwshimi: we have nothing for it yet. It's a new item that a package upload can have. | 09:56 |
| huwshimi | jtv: Oh right | 09:56 |
| jtv | Yes, this is the feature we're working on. | 09:56 |
| lifeless | jtv: I can't drill into it tonight, but the plan when its slow looks poor | 09:57 |
| jtv | lifeless: I gather that's it pretty much good enough for now, so maybe we should just go with what we have and worry more if it becomes a problem again? | 09:57 |
| lifeless | jtv: (I have a 0530 am wake up tomorrow which is why fiddling tonight would be bad :) | 09:57 |
| jtv | bird in the hand etc. | 09:58 |
| jtv | I know how you feel — I'm on 05:00 at the moment. Followed by a few more hours of sleep, thankfully. | 09:58 |
| lifeless | jtv: the use of a union to work around a poor plan is a bit unnerving | 09:58 |
| lifeless | jtv: allenap: I think identifying the cause is worthwhile; that or just the expedient thing of clamping the batch size (which is a 1-line fix) | 09:59 |
| henninge | danilos: did you want to do voice? | 09:59 |
| jtv | lifeless: I'll still need to get to that part, so no idea how unnerving it is yet. Guess I'll look at that first. | 09:59 |
| henninge | s/did/do/ | 09:59 |
| huwshimi | jtv: OK, so what icon do we currently use for package uploads that are not package syncs? | 09:59 |
| jtv | huwshimi: each has a collection of icons depending on what types of items are attached. | 09:59 |
| jtv | We need to add one more icon to that. | 09:59 |
| danilos | henninge, yes please, though mumble is kind of dead for me, so it'd have to be skype | 10:00 |
| jtv | We do suffer a paucity of icons there. | 10:00 |
| allenap | lifeless: Clamping the batch size is going to displease the users, from what I've heard. If we can work around it one way or the other I think it's worth it. | 10:00 |
| lifeless | allenap: what they want and what they need are totally different things | 10:00 |
| danilos | henninge, if that doesn't work for you, irc is fine as well | 10:00 |
| lifeless | allenap: seriously - they are talking about paginating through thousands of entries; thats a terrible UI | 10:00 |
| jtv | allenap, lifeless: Sometimes the answer may just be to have separate pages for separate purposes, and optimize them to extremes for their specific purposes. | 10:00 |
| huwshimi | jtv: Ok, I'm just want to look at something so I can see what to base this new icon off (or at least make it fit with what we have for the other types). | 10:00 |
| jtv | huwshimi: try /ubuntu/oneiric/+queue | 10:01 |
| jtv | (Try selecting a different status than New to see more) | 10:01 |
| huwshimi | jtv: Ah thanks | 10:02 |
| lifeless | allenap: bigjools initial reaction to the bug was to say '300 is url hacking, low pri' - which says to me that supporting large batches isn't important to the feature at this point. | 10:02 |
| danilos | henninge, heh, call when ready | 10:02 |
| bigjools | lifeless: more complicated than that | 10:02 |
| allenap | lifeless: Yes, but then you put it back up to Critical! | 10:02 |
| allenap | lifeless: But fair. I think we can leave this alone for now. | 10:03 |
| huwshimi | jtv: OK, can you file a bug for it anyway, just so I have something in the system and explain what you want and I'll get onto it. | 10:03 |
| jtv | huwshimi: certainly — hang on | 10:04 |
| huwshimi | jtv: Thanks | 10:04 |
| allenap | jtv: I've mostly heard rumblings that better search for those pages is what's needed. I think that's the way to ensure that batches stay small. | 10:04 |
| jtv | huwshimi: bug 800573 | 10:08 |
| _mup_ | Bug #800573: Need icon for sync package uploads <derivation> <Launchpad itself:Triaged by huwshimi> < https://launchpad.net/bugs/800573 > | 10:08 |
| huwshimi | jtv: Thanks | 10:08 |
| jtv | thanks for looking into it — I assigned it to you | 10:09 |
| huwshimi | jtv: No problems | 10:11 |
| wgrant | bigjools: Hi. | 10:13 |
| bigjools | wgrant: hey, I just want to help rvba finish his branch | 10:14 |
| bigjools | he's done the stuff you asked but I have one more question | 10:14 |
| wgrant | bigjools: Oh? | 10:15 |
| wgrant | (I have further concerns, but not sure how to resolve them) | 10:15 |
| bigjools | if he blocks binaries with conflicting files, we'll end up with builds with incomplete binaries and wondered about the effects of that | 10:15 |
| wgrant | Yes | 10:15 |
| bigjools | and wondered if we should block the source for the binary too | 10:15 |
| wgrant | We really need to copy the sources, I think, not the publications. | 10:15 |
| wgrant | Or we're going to end up with a patchwork mess of series. | 10:16 |
| wgrant | Which are not consistent. | 10:16 |
| wgrant | Not legal. | 10:16 |
| wgrant | Not recoverable. | 10:16 |
| bigjools | yes it is confusing | 10:16 |
| bigjools | so you think making a new spr and its files is better? | 10:16 |
| wgrant | No, no. | 10:16 |
| bigjools | what do you mean by sources then? | 10:16 |
| wgrant | I think rephrasing initialisation as a copy of all of the sources is better. | 10:16 |
| wgrant | Rather than a copy of all the source and binary publications. | 10:17 |
| wgrant | But I don't know how that will work. | 10:17 |
| bigjools | well yes I think copying binaries is crack anyway | 10:17 |
| bigjools | but it's in the spec, so ... | 10:17 |
| wgrant | I mean using the usual copy logic, and just syncing all sources with binaries. | 10:17 |
| bigjools | using the packagecopier? | 10:18 |
| wgrant | That's the behaviour we want, ideally. | 10:18 |
| bigjools | I think we tried that originally | 10:18 |
| bigjools | it was so slow as to be unusable | 10:18 |
| jtv | allenap: 35? | 10:18 |
| wgrant | Of course. | 10:18 |
| bigjools | hence the lovely packagecloner | 10:18 |
| wgrant | But it's the behaviour we want. | 10:18 |
| bigjools | true | 10:18 |
| wgrant | And the package copier used to suck. | 10:18 |
| wgrant | It still sucks. | 10:18 |
| wgrant | But it's not quite as bad. | 10:19 |
| wgrant | I don't know if we can use it. | 10:19 |
| rvba | The package copier will end up really slow if I continue to add new checks to it. | 10:19 |
| wgrant | But the current approach of just excluding the specific bits that conflict is.... messy and problem-prone. | 10:19 |
| bigjools | so I've said to rvba that if we block conflicting sources then he needs to block their binaries too | 10:19 |
| rvba | and slow. | 10:19 |
| wgrant | bigjools: Certainly. | 10:19 |
| bigjools | apart from that I want to land this puppy | 10:19 |
| wgrant | bigjools: And I think probably the other way too. | 10:19 |
| bigjools | wgrant: yes, I mentioned that too | 10:19 |
| wgrant | Which means we basically want the full consistency checks that the copier provides. | 10:20 |
| wgrant | We need to optimise that for mass-syncs anyway. | 10:20 |
| wgrant | Eventually. | 10:20 |
| wgrant | And a large mass-sync could be easily 10% of the archive. | 10:20 |
| wgrant | So... | 10:20 |
| wgrant | We're approaching the same order-of-magnitude. | 10:20 |
| bigjools | right | 10:21 |
| wgrant | Given what it is, duplicating this logic does not sit well with me at all. | 10:21 |
| bigjools | rvba: ok so add the "don't copy corresponding binary/source if you block a source/binary" change and then let's land it | 10:22 |
| wgrant | But, similarly, using the package copier for initialisation is also a little bit scary. | 10:22 |
| bigjools | wgrant: very | 10:22 |
| bigjools | and no I hate this duplication | 10:22 |
| rvba | bigjools: ok | 10:22 |
| bigjools | it's only there as a special case to make intialisation quick | 10:22 |
| wgrant | Yeah. | 10:22 |
| wgrant | Eventually the copier will be just as fast :) | 10:22 |
| bigjools | but the multi-parent stuff fecked that all up | 10:22 |
| wgrant | Yup | 10:22 |
| * bigjools is getting the irish lingo already | 10:23 | |
| lifeless | allenap: I put it to critical because we want to be able to jump on every oops that happens | 10:23 |
| lifeless | allenap: when means no spurious oopses | 10:23 |
| bigjools | lifeless: in this case it's indicative of a lack of good search options | 10:23 |
| lifeless | allenap: if something is a users fault, it needs special reason to be an OOPS | 10:23 |
| lifeless | bigjools: yeah | 10:23 |
| wgrant | bigjools: Hmm. | 10:23 |
| bigjools | wgrant: ? | 10:23 |
| lifeless | bigjools: but still, we need to either (make it not timeout) | (make it not oops) | 10:24 |
| wgrant | bigjools: I'm wondering if we can do a known-good initialisation (from a series in the same distro, or into a fresh distribution) the quick way, and then do the others afterwards using the copier to ensure consistency. | 10:24 |
| bigjools | lifeless: well I think it's already fine with the default batch size, it only oopses because someone hacked that | 10:24 |
| lifeless | bigjools: agreed | 10:25 |
| bigjools | so it's a rather special case | 10:25 |
| lifeless | bigjools: my recommended fix is to clamp the batch size | 10:25 |
| wgrant | bigjools: This would keep the Ubuntu case fast. | 10:25 |
| bigjools | lifeless: +1 | 10:25 |
| lifeless | bigjools: batchnav has a parameter for this | 10:25 |
| lifeless | bigjools: which will make url hacking throw a non-oops error (UFD I think) | 10:25 |
| bigjools | lifeless: +1 | 10:26 |
| lifeless | or if it does oops today, its one we can blanket ignore | 10:26 |
| bigjools | -1 to ignoring oopses - need to stop them happening in the first place | 10:26 |
| lifeless | bigjools: oh I agree | 10:26 |
| bigjools | by whatever means | 10:26 |
| bigjools | wgrant: so | 10:26 |
| bigjools | wgrant: interesting | 10:26 |
| lifeless | bigjools: by blanket ignore I was meaning ignore the exception in the oops raising() method | 10:27 |
| wgrant | bigjools: Since in most cases the big copy will be known-good. | 10:27 |
| wgrant | bigjools: natty->oneiric is within an archive, so it's fine. | 10:27 |
| wgrant | natty->newderivativedistro is fine, because it's a new archive. | 10:27 |
| bigjools | wgrant: yes, indeed. and I think in retrospect this is what should have been done | 10:27 |
| bigjools | I have a first class degree in hindsight from the university of life | 10:27 |
| jml | huwshimi: btw, I'm just starting to work through my hand-off tasks. if you'd like to talk, now would be a good time. | 10:28 |
| wgrant | Retrospect is handy; keeping domain experts together can be too :) | 10:28 |
| bigjools | wgrant: yes :/ | 10:28 |
| huwshimi | jml: Do you mean about the designs? | 10:29 |
| jml | huwshimi: about whatever :) | 10:29 |
| huwshimi | jml: Sure, we can talk about whatever, but at least with the designs I'll need to wait until I've had a bit more of a chance to look at them to day... maybe this afternoon for that | 10:30 |
| jtv | allenap: 35..? | 10:30 |
| jml | huwshimi: ok. let's chat then. | 10:30 |
| huwshimi | jml: Sure | 10:30 |
| jml | ambiguity resolved! | 10:32 |
| huwshimi | jml: ambiguity is never resolved | 10:32 |
| jml | it expires? | 10:32 |
| huwshimi | jml: Could be | 10:33 |
| allenap | jtv: I plucked that one out of the air. It means that there will be two subselects in the UNION for the default batch size of 75. | 10:37 |
| lifeless | allenap: fwiw see bigjools +1ing clamping the batch size rather than doing the union *terrifying* patch | 10:39 |
| lifeless | and with that, I'm running for sleep | 10:39 |
| bigjools | a combo of both? | 10:40 |
| allenap | lifeless: Okay, cheerio, and thanks. | 10:40 |
| wgrant | bigjools: We are considering denormalising BPR.binarypackagename onto BPPH. | 10:46 |
| bigjools | BPPH not BPR? | 10:47 |
| wgrant | Yes. We need to be able to index BPPH on either BPR.binarypackagename or BPN.name. | 10:47 |
| wgrant | I guess we could just go all the way and stick BPN.name into BPPH | 10:47 |
| lifeless | wgrant: that is what I was suggesting | 10:48 |
| wgrant | (overrides during copies are too slow without that :/) | 10:48 |
| wgrant | lifeless: Well, BPN.name is quite a bit wider than BPN.id. | 10:48 |
| lifeless | wgrant: lets do some numbers, but not now. | 10:48 |
| lifeless | zzz | 10:48 |
| wgrant | Night. | 10:49 |
| === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: danilo | Critical bugs: 211 - 0:[######=_]:256 | ||
| LPCIBot | Project db-devel build #655: STILL FAILING in 5 hr 36 min: https://lpci.wedontsleep.org/job/db-devel/655/ | 12:00 |
| jtv | say danilos, perhaps you can review my thousand-line branch? https://code.launchpad.net/~jtv/launchpad/bug-798521/+merge/65297 | 12:03 |
| danilos | jtv, I was considering it, but just couldn't get around to doing it :) any reason why it's not two smaller branches? | 12:04 |
| * jtv stops himself from mentioning a disgusting joke | 12:04 | |
| jtv | It was all sort of stuck together. | 12:04 |
| jtv | There are a few parts I could isolate, in retrospect, but this is soyuz: if I'd done it up front I would have had to fix the first branch while doing the second. :/ | 12:05 |
| jtv | Things working as specified but not as desired, that sort of thing. | 12:06 |
| danilos | jtv, yeah, you should try pipelines sometime if you haven't already :) | 12:06 |
| jtv | I have. Gave me enough trouble that I no longer bother. | 12:06 |
| danilos | jtv, anyway, looking through your branch now | 12:06 |
| jtv | Thanks! | 12:06 |
| * henninge is outta here | 12:19 | |
| jml | huwshimi: let me know when you want to head out for lunch. (note that the standup is in ~1hr 15m) | 12:27 |
| huwshimi | jml: We can go now. I probably just need to stop work on this now anyway | 12:28 |
| jml | huwshimi: OK. Let's do that. | 12:28 |
| LPCIBot | Project parallel-test build #60: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/parallel-test/60/ | 13:07 |
| LPCIBot | Project windmill-db-devel build #416: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/416/ | 13:20 |
| === matsubara-afk is now known as matsubara | ||
| jtv | thanks danilos! | 13:36 |
| jtv | Or hvala | 13:36 |
| danilos | jtv, it wasn't me! | 13:36 |
| jtv | suuuurre | 13:36 |
| deryck | Morning, all. | 14:08 |
| deryck | abentley, hey, I'm around now. | 14:09 |
| deryck | abentley, adeuring -- https://wiki.canonical.com/Launchpad/Sprints/Thunderdome2011/Agenda | 14:17 |
| huwshimi | jml: I'm available if you want to talk. | 14:17 |
| jml | huwshimi: oh, right. good idea. I'll just finish off this email. | 14:17 |
| huwshimi | jml: No problems | 14:18 |
| huwshimi | deryck: Morning | 14:18 |
| huwshimi | deryck: I noticed this bug which is only a year old: #561586. Does this change anything about what we talked about yesterday? | 14:19 |
| _mup_ | Bug #561586: Move javascript code to lp.app directories <javascript> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/561586 > | 14:19 |
| wgrant | jml: What's broken about the contributions page? | 14:36 |
| wgrant | Hmm, I possibly didn't land my fixes... | 14:37 |
| wgrant | Still seems to work OK, although I should probably remove my non-Canonical persona from there somehow. | 14:40 |
| jml | wgrant: it hasn't been updated since May. Maybe that's not a problem. Also, you're listed as non-Canonical. | 14:45 |
| jml | wgrant: anyway, in a meeting. please reply via email. | 14:45 |
| deryck | sinzui, hi. Don't suppose you had any luck on 64 bit errors with YUI layer yesterday? | 14:59 |
| sinzui | deryck, I am reading wgrants gdb. The fault in the JS JIT | 14:59 |
| deryck | ah, cool. | 15:00 |
| sinzui | I am contemplating downgrading to libwebkitgtk-3*.so | 15:00 |
| deryck | adeuring, shall we chat now? | 15:01 |
| adeuring | deryck: sure | 15:01 |
| === Ursinha is now known as Ursinha-lunch | ||
| sinzui | deryck, abentley, wgrant: The YUI segfault is a webkit's JIT. There is a history of jit failures for amd64 in webkit : https://launchpad.net/ubuntu/+source/webkit/1.3.13-0ubuntu1 I am exploring using the older version of the lib | 15:11 |
| wgrant | sinzui: That patch is for the ARM JIT. | 15:11 |
| wgrant | But OK. | 15:11 |
| sinzui | wgrant, sorry, I pasted the wrong one. | 15:12 |
| abentley | sinzui: Ah. | 15:12 |
| deryck | interesting. | 15:16 |
| === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 211 - 0:[######=_]:256 | ||
| huwshimi | deryck: I'm back now | 15:27 |
| jml | bigjools: do you understand my XXX comment in test_resumeHost_success? | 15:28 |
| bigjools | jml: OTP, gimme a few mins | 15:29 |
| jml | bigjools: ok. | 15:29 |
| jml | bigjools: http://paste.ubuntu.com/630835/ (for when you're ready) | 15:30 |
| deryck | Hi, huwshimi. So I don't think that bug has any impact on us.... | 15:37 |
| deryck | huwshimi, that relates to the plan to get everything, js or otherwise, out of lib/canonical/launchpad and into lib/lp | 15:37 |
| deryck | huwshimi, and we can always spin up a thread on launchpad-dev list and see what others think. | 15:38 |
| huwshimi | deryck: Aren't we talking about reversing that decision? | 15:39 |
| jml | I haven't heard anything about that. | 15:39 |
| deryck | huwshimi, I don't think so. We're saying "have a single place of all js files" | 15:39 |
| deryck | huwshimi, I assumed that would be something like lib/lp/javascript | 15:39 |
| deryck | jml, it's an idea huwshimi and I are tossing around. | 15:40 |
| jml | I saw sinzui post something about moving stuff to lp/app | 15:40 |
| jml | deryck: I meant, I haven't heard anything about reversing the decision to move stuff out of l/c/launchpad | 15:40 |
| sinzui | jml, deryckI stumbled on a bug yesterday about removing canonical/launchpad/js. There is about 1h of work left to remove it | 15:41 |
| deryck | jml, yeah, there hasn't been. huwshimi was worried our desire to move to a single js dir would reverse that bug. | 15:41 |
| deryck | sinzui, huwshimi and I have been discussing moving all the app-specific js files to a single js directory. you have any concerns about that? | 15:42 |
| jml | oh ok | 15:42 |
| jml | sorry for the noise :) | 15:42 |
| deryck | jml, no worries :) | 15:42 |
| abentley | deryck: so the js for translation-sharing would be moved away from its html file? | 15:43 |
| deryck | abentley, yes | 15:43 |
| deryck | that's by design actually.... to get people to stop doing in-page scripts. decouple the page and the js a bit. | 15:44 |
| sinzui | Only that putting the files in a deprecated directory is wrong. some where in lp/ is fine. I would like to think that lp/services/javascript would be the right place. I do not know if our js code can be considered a standalone, reusable library yet | 15:44 |
| abentley | deryck: it seems to me we'd need to set up a parallel hierarchy in that js directory. | 15:44 |
| deryck | sinzui, yeah, I was thinking somewhere in lib/lp. I'm not picky about location. and yeah... | 15:44 |
| jml | fwiw, lifeless disagrees with the current 'lp' structure | 15:45 |
| deryck | sinzui, it's not a stand alone library. nor intended to be, I don't think. | 15:45 |
| LPCIBot | Project windmill-devel build #263: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill-devel/263/ | 15:45 |
| deryck | sinzui, the idea is just to make it easier to discover all the js we have, and prevent people writing the same code over and over again. | 15:45 |
| jml | he has some valid points, but I can't help but feel slightly discouraged at the thought of another whole tree refactoring | 15:45 |
| deryck | yeah, I don't want to get into that either. I hope this is a much simpler endeavor. | 15:46 |
| === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugs: 211 - 0:[######=_]:256 | ||
| deryck | abentley, so yeah, we would need some parallel structure or grouping of files, but huwshimi and I hope it will be functional, not app-specific.... | 15:46 |
| deryck | abentley, so grouping all the pickers, all the dom-editing stuff, or something like that. | 15:46 |
| abentley | deryck: I'm totally in favour of extracting everything we can from the page-specific files. I'm not enthusiastic about moving the page-specific files. | 15:47 |
| deryck | abentley, so +1 to no in page scripts, but -1 on moving the js files themselves. Is that a good reading of that? | 15:48 |
| abentley | deryck: yes, and also +1 on grouping all the pickers, alll the dom-editing stuff, or something like that. | 15:48 |
| deryck | abentley, which would cover most of our js, I think. so you're only -1 in the case where the js is tied heavily to a page, e.g. the translation sharing js. | 15:49 |
| deryck | right? | 15:49 |
| abentley | deryck: Not really. I assume that most of the per-page JS files have a little bit of JS that's tied heavily to that page. | 15:52 |
| deryck | abentley, yeah, and I see that as a bad pattern. unavoidable completely, I agree, but we abuse the tie between page and js files. | 15:53 |
| sinzui | deryck, abentley: could either of you untar this in a working tree and run all the YUI tests: http://people.canonical.com/~curtis/html5browser-fix.tar | 15:53 |
| deryck | sinzui, I can in just a sec. | 15:53 |
| sinzui | untar in the root | 15:53 |
| deryck | sinzui, root of the lp tree? | 15:54 |
| abentley | deryck: So you're thinking the content of the page should completely control how the JS attaches to it? | 15:54 |
| deryck | abentley, I don't know if that's what I mean. I don't think so, but not sure I understand what you mean.... | 15:56 |
| deryck | abentley, I mean just that we should decouple the page from the script as much as possible, make re-usable widgets primarly, and have page-specific scripts be as small and decoupled as possible. | 15:57 |
| deryck | I also see us moving to an event-driven system, where page-specific stuff, if event reacting, rather than the long procedural-like files we have now. | 15:58 |
| deryck | as I mentioned on the stand-up this morning. ;) Though I know you don't care for that. | 15:58 |
| abentley | deryck: I said "most pages have a little bit of js that's tied heavily to that page", and you said "that's a bad pattern". I think you mean "It's bad to have even a little bit of JS that's tied heavily to a page". Is that what you mean? | 15:58 |
| deryck | abentley, I think it's bad to have tight coupling. Where there is a close link between js and page, it's bad. I think there will always be some link, of course. so if it is truly "a little bit" then no, I don't think that's bad.... | 16:00 |
| deryck | abentley, I meant more that the "little bit of js linked to page" is a common pattern and abuses. I question that it's really just a little. so that's why I said it was a bad pattern. | 16:01 |
| abentley | deryck: I think that all the javascript that doesn't need to be linked to the page should be extracted, leaving behind the little bit that does need to be linked. | 16:05 |
| abentley | deryck: For example, I think most of the translation-sharing-details code could be extracted. | 16:05 |
| deryck | abentley, I think we agree more than we disagree then. | 16:06 |
| abentley | deryck: Cool. | 16:07 |
| cjohnston | jml: is there a version of the community contrib page that I can see? | 16:10 |
| jml | cjohnston: you can't *see* the contrib page?! | 16:10 |
| cjohnston | nm.. I clicked the cronjob link. :-/ | 16:10 |
| jml | bigjools: re-ping re http://paste.ubuntu.com/630835/ | 16:13 |
| bigjools | jml: ok ok :) just got off TP | 16:13 |
| deryck | sinzui, I untarred into the lp tree. ran make. ran tests. still seq faulting. | 16:13 |
| cjohnston | I would make a suggestion/request to whoever takes it over.. maybe show the number of bugs fixed as well as top level landings.. I have had 4 landings, but fixed 6 bugs. so there is the potential for a discrepancy making it look like less work has been done than what has actually been done | 16:13 |
| sinzui | deryck, to confirm you have lib/html5browser/__init__.py ? | 16:14 |
| jml | cjohnston: that's a good idea | 16:14 |
| deryck | sinzui, yup. and I see a .pyc file in there, so it's being used. | 16:14 |
| sinzui | deryck, :( this means that natty amd64 has broken webkit 1.0, 3.0 | 16:15 |
| deryck | sinzui, that sucks :( | 16:16 |
| bigjools | jml: it's to do with the fake slave, I think it just echo-ed its own vm_host so we can test the stdout | 16:16 |
| deryck | sinzui, I can spin up a 32bit vm for myself. but that's not ideal for everyone. | 16:16 |
| sinzui | The change I made was to run everyone on the same python, pykgtk, and webkit as lucid amd64 | 16:16 |
| bigjools | jml: although I can't remember how "SlaveHelper is being moved around" affected that | 16:16 |
| jml | bigjools: what do you think I meant by "pass the expected vm_host into the client slave"? | 16:16 |
| jml | bigjools: the moved around thing was probably, "Oh, we should change this but it'll be mega conflict central if I do it now" | 16:17 |
| bigjools | jml: I suspect it means to pass it to getClientSlave() and hence the __init__ for BuilderSlave | 16:18 |
| bigjools | it's hard-coded to "vmhost" right now | 16:18 |
| bigjools | not sure why we didn't file a bug and add it to th eXXX | 16:19 |
| jml | bigjools: probably because we were in a rush. I'm realizing increasingly that being able to just put them down quickly is part of the glory of XXX comments. | 16:21 |
| bigjools | jml: I tend to do TODO instead of XXX if I intend to fix it in the same branch | 16:22 |
| bigjools | and your todo plugin helps :) | 16:22 |
| sinzui | deryck, do you have the python-webkit package installed? | 16:22 |
| jml | where a bug is most useful is for XXX comments that are like, "when $FOO is done, we can fix this awful mess" | 16:22 |
| jml | so there's a bug for $FOO | 16:22 |
| bigjools | welllll | 16:22 |
| bigjools | also, "I want to do $FOO but not right now" | 16:23 |
| deryck | sinzui, yes. 1.1.8-1ubuntu2 | 16:23 |
| sinzui | :( | 16:23 |
| sinzui | I believe you have the same packaging rules are lucid amd64 | 16:23 |
| bigjools | jml: anyway did I get anywhere near close to answering your question? | 16:25 |
| jml | bigjools: yeah, I think so, thanks. | 16:25 |
| bigjools | cool | 16:25 |
| abentley | jml: I know, let's write a tool that files a bug for every XXX! | 16:35 |
| jml | :( | 16:35 |
| LPCIBot | Project windmill-devel build #264: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill-devel/264/ | 16:42 |
| nigelb | jml: Nice docs. | 16:53 |
| nigelb | " Angels fear to tread." | 16:53 |
| === salgado is now known as salgado-lunch | ||
| gary_poster | flacoste, I'm trying to come up with a proposal on how to have wadl served by apache (for bug 607961). To your knowledge, am I right that api.launchpad.net/beta serves both wadl and json depending on the request's Accept, and that the json service root is not served anywhere else other than api.launchpad.net? | 17:16 |
| _mup_ | Bug #607961: wadl generation timeout? <lp-foundations> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/607961 > | 17:16 |
| * gary_poster was looking at Apache for that info. I'll look in zcml when I return | 17:22 | |
| flacoste | gary_poster: your assumptions sound correct to me | 17:27 |
| === deryck is now known as deryck[lunch] | ||
| flacoste | gary_poster: there is also a "feature" that i think you can ask the wadl of any resource, but i don't think anything uses that | 17:28 |
| flacoste | gary_poster: so in practice, it's only the main wadl resource we care about | 17:28 |
| gary_poster | cool thanks flacoste | 17:36 |
| === deryck[lunch] is now known as deryck | ||
| * deryck is not doing lunch, yet. | 17:37 | |
| * gary_poster thought he was doing lunch, but was wrong | 17:40 | |
| sinzui | deryck, can you run this http://people.canonical.com/~curtis/test_yui.py | 17:42 |
| sinzui | deryck, python test_yui.py <my-built-tree>/lib/lp/app/javascript/tests | 17:42 |
| deryck | sinzui, sure. | 17:42 |
| sinzui | ^ that will use python2.7 without the zope testrunner | 17:42 |
| sinzui | I doubt this will work | 17:43 |
| deryck | sinzui, yeah, seq fault again. sorry :( | 17:44 |
| sinzui | deryck, okay. thank you | 17:48 |
| deryck | np | 17:48 |
| * deryck really lunches now | 17:49 | |
| === deryck is now known as deryck[lunch] | ||
| jml | I'm off for the day | 17:55 |
| jml | only two more working days until Dublin | 17:55 |
| jml | I'm excited | 17:55 |
| LPCIBot | Project db-devel build #656: STILL FAILING in 5 hr 54 min: https://lpci.wedontsleep.org/job/db-devel/656/ | 18:19 |
| === salgado-lunch is now known as salgado | ||
| === deryck[lunch] is now known as deryck | ||
| === Ursinha-lunch is now known as Ursinha | ||
| === matsubara is now known as matsubara-lunch | ||
| LPCIBot | Project windmill-devel build #265: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-devel/265/ | 19:24 |
| LPCIBot | Project parallel-test build #61: STILL FAILING in 1 hr 11 min: https://lpci.wedontsleep.org/job/parallel-test/61/ | 19:57 |
| lifeless | bigjools: hi | 20:06 |
| bigjools | /o\ | 20:06 |
| lifeless | bigjools: I'm worried I might cause you grief if I suddenly enforce the (agreed) 1s/5s thing for the dsd new pages (e.g. +initseries) | 20:06 |
| lifeless | bigjools: do you have any thoughts / concerns around this ? | 20:06 |
| bigjools | lifeless: 1s? | 20:07 |
| lifeless | 1s soft timeout | 20:07 |
| bigjools | ah | 20:07 |
| bigjools | 1s is pushing it | 20:07 |
| bigjools | initseries is totally ajax btw | 20:07 |
| lifeless | so its phrased as 1s 99th percentile | 20:07 |
| lifeless | the soft timeout just grants access to info on the things over the 1st that don't timeout | 20:08 |
| bigjools | the diff pages are 2-3s at the moment but when gavin lands his performance fix it might get better | 20:08 |
| lifeless | so its an aid | 20:08 |
| bigjools | yeah | 20:08 |
| bigjools | did you see what he did BTW? | 20:09 |
| lifeless | +0 | 20:09 |
| bigjools | yeah... wtf :) | 20:09 |
| lifeless | so its avoiding an index | 20:09 |
| lifeless | that same index is what broke sourcepackagename checking on bugs yesterday, I think. | 20:09 |
| lifeless | so we have a root cause we need to diagnose | 20:09 |
| bigjools | wouldn't it be great to say "WITH index SELECT ..." | 20:10 |
| bigjools | can we analyse what indexes all the queries use? would be interesting to see what needs that slow one | 20:10 |
| lifeless | stub is working on that with the goal of dropping unused indices | 20:11 |
| lifeless | same data should help us answer what-uses it AIUI | 20:11 |
| lifeless | anyhow, on the timeout thing | 20:11 |
| bigjools | awesome | 20:11 |
| lifeless | I could look at the PPR for each page and rather than jump to 5s | 20:11 |
| lifeless | perhaps jump to max(5s, current 99th percentile) | 20:12 |
| bigjools | can do | 20:12 |
| lifeless | what do you think? | 20:12 |
| bigjools | we're well under 5s except for when someone hacks the batch size | 20:12 |
| lifeless | ok | 20:12 |
| bigjools | like I said, 2-3s | 20:13 |
| lifeless | so I'll just set them to 5s | 20:13 |
| lifeless | I don't have a proper list yet | 20:13 |
| bigjools | how are you doing that, rules for specific pages? | 20:13 |
| lifeless | the tooling for that is in our to-do list | 20:13 |
| lifeless | yeah | 20:13 |
| bigjools | that's going to get to be a big list | 20:13 |
| lifeless | moderate size yes | 20:14 |
| lifeless | but we could have a few hundred new things before its too big | 20:14 |
| lifeless | and by then I hope we'll have dragged the default down more | 20:14 |
| bigjools | I hope by then the sitewide is 5s .. | 20:14 |
| lifeless | ELOCAL | 20:15 |
| bigjools | anyway, way past EoD for me, ttyl | 20:17 |
| lifeless | back | 20:17 |
| === matsubara-lunch is now known as matsubara | ||
| lifeless | ciao | 20:17 |
| bigjools | o/ | 20:17 |
| deryck | heh, several of us decided to catch up on sinzui's email at the same time. | 20:18 |
| deryck | I could say something about great minds and all... :) | 20:19 |
| flacoste | lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1998QASTAGING103 | 20:20 |
| flacoste | that's the OOPS i got yesterday on qastaging | 20:21 |
| flacoste | the problematic query is fast (63ms) in there | 20:21 |
| lifeless | flacoste: \o/ | 20:21 |
| lifeless | flacoste: ok, so the moral is 'have nothing wrong as a baseline' | 20:21 |
| flacoste | yeah | 20:21 |
| flacoste | but that still weird | 20:21 |
| flacoste | because even then | 20:21 |
| flacoste | wouldn't have prevented the regression from going to production | 20:22 |
| flacoste | since the query seems fine | 20:22 |
| flacoste | could it be bloat on production? | 20:22 |
| gary_poster | world-at-large, do we still prefer that imported branches be for trunks? If so, how strongly? | 20:22 |
| flacoste | gary_poster: no | 20:22 |
| gary_poster | cool, I'll update pertinent CHR page, thanks flacoste | 20:23 |
| flacoste | gary_poster: but we don't support importing from non git | 20:23 |
| flacoste | gary_poster: there reason for that was related to subversion | 20:23 |
| flacoste | if i recall | 20:23 |
| gary_poster | flacoste--oh--only one of hg as well? | 20:23 |
| flacoste | as supported by cscvs | 20:23 |
| flacoste | but not sure if the restriction applied | 20:23 |
| lifeless | flacoste: bloat, extra data, different pg parameters related to memory sizing | 20:23 |
| flacoste | support i mean: do not support importing non-HEAD git branches | 20:23 |
| gary_poster | o I see | 20:24 |
| lifeless | flacoste: thanks for digging in | 20:24 |
| gary_poster | Ah got it: I had just missed the necessary detail already on the page | 20:26 |
| gary_poster | "Now that we use bzr-svn, non-mainline svn branches can be imported in such that they will be compatible with mainline svn imports. However, they will not be compatible with old svn imports based on CSCVS. | 20:26 |
| gary_poster | For Git and Hg, there's no way to specify anything other than the mainline at the moment (Bug #380871)." | 20:26 |
| _mup_ | Bug #380871: support for colocated branches <code-import> <lp-code> <Bazaar:In Progress by jelmer> <Bazaar Git Plugin:Fix Released by jelmer> <Bazaar Hg Plugin:Fix Committed by jelmer> <Launchpad itself:Triaged> < https://launchpad.net/bugs/380871 > | 20:26 |
| gary_poster | oh | 20:27 |
| gary_poster | oh ok, fixed everywhere except LP | 20:27 |
| jelmer | gary_poster, and bzr | 20:27 |
| gary_poster | heh ok | 20:27 |
| gary_poster | thanks | 20:28 |
| gary_poster | flacoste, we have a question about whether we block LP from Cuba (https://support.one.ubuntu.com/Ticket/Display.html?id=2772, "The access to Launchpad it's negated for the Cuban developers or do you have technical problems that causes that we can access you services from Cuba?"). I'm reasonably confident we don't, but am I missing anything? | 20:29 |
| * gary_poster wishes he remembered Google analytics access ids | 20:29 | |
| LPCIBot | Project windmill-db-devel build #417: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/417/ | 20:30 |
| flacoste | gary_poster: we don't | 20:31 |
| gary_poster | k thanks flacoste | 20:31 |
| flacoste | gary_poster: we are UK hosted | 20:31 |
| flacoste | so no US export restrictions | 20:31 |
| gary_poster | heh | 20:31 |
| gary_poster | flacoste, who has Google analytics access for LP, and how could I get it? | 20:32 |
| lifeless | its more nuanced that that AIUI | 20:32 |
| lifeless | we have a US arm | 20:32 |
| lifeless | we could have restrictions imposed on us | 20:33 |
| lifeless | so far we don't | 20:33 |
| gary_poster | oh | 20:33 |
| gary_poster | ok | 20:33 |
| lifeless | but we can not promise that we won't. | 20:33 |
| gary_poster | sure | 20:33 |
| gary_poster | promises about the future are generally risky :-) | 20:34 |
| lifeless | yeah | 20:34 |
| flacoste | lifeless: but OOPS-1998QASTAGING102 showed the issue | 20:36 |
| flacoste | so cold cache problem | 20:36 |
| lifeless | combination | 20:36 |
| flacoste | 12 or 63ms hot | 20:36 |
| lifeless | poor cold cache, + crap plan on prod | 20:36 |
| flacoste | but 9000 when not cached | 20:36 |
| flacoste | probably | 20:36 |
| flacoste | lifeless: anything we could do cheaply to have "instant" OOPS access? | 20:37 |
| flacoste | i didn't look at that first OOPS | 20:37 |
| flacoste | because it wasn't available immediately | 20:37 |
| flacoste | so i reloaded | 20:37 |
| flacoste | and retried | 20:37 |
| lifeless | flacoste: you can rsync them directly in the dc immediately. | 20:37 |
| flacoste | and eventually, only looked at the 'last' oops | 20:37 |
| flacoste | ah ok | 20:38 |
| lifeless | its fugly but works | 20:38 |
| flacoste | lifeless: do you think we could make that automatic on 404 when visiting lp-oops? | 20:38 |
| flacoste | oops not found -> let's try a rsync and try again | 20:38 |
| flacoste | without the dev having to do anything | 20:38 |
| lifeless | that would be fun | 20:39 |
| lifeless | I see no reason why not | 20:39 |
| flacoste | cool, i'll file a bug and eventually scratch the itch | 20:39 |
| lifeless | hmm | 20:53 |
| lifeless | in ff5 the filebug form is stuffed | 20:53 |
| LPCIBot | Project windmill-devel build #266: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill-devel/266/ | 21:03 |
| deryck | lifeless, what do you mean by "stuffed"? | 21:35 |
| lifeless | you know the expander | 21:36 |
| lifeless | for extra options? | 21:37 |
| lifeless | its missing | 21:37 |
| lifeless | the include-an-attachment border is showing greyed out | 21:37 |
| lifeless | and no widgets at all from 'extra options' down to 'submit bug report' | 21:37 |
| lifeless | for launchpad/+filebug, where I do have perms to do that | 21:37 |
| deryck | lifeless, weird, works for me. | 21:37 |
| deryck | lifeless, everything looks normal to me in FF5. | 21:37 |
| lifeless | deryck: funnky | 21:38 |
| deryck | indeed | 21:38 |
| deryck | lifeless, you running ff5 anyway special, or just the normal ubuntu upgrade? | 21:38 |
| lifeless | the -proposed one | 21:38 |
| lifeless | that micahg asked for testers on | 21:38 |
| deryck | ah | 21:40 |
| deryck | I just regular ol' updated today and am running that one. | 21:40 |
| sinzui | jcsackett, do you have time to mumble? | 21:41 |
| jcsackett | sinzui: sure. | 21:41 |
| flacoste | deryck: https://dev.launchpad.net/Code/BazaarUpgrades | 21:48 |
| flacoste | that's the code QA page i was talking about | 21:48 |
| flacoste | we should have a central QA page | 21:48 |
| deryck | flacoste, ah, ok. Thanks. I presume lifeless was referring to the qa tagging instructions as a central qa page? | 21:49 |
| lifeless | yes I was | 21:50 |
| lifeless | or at least as an entry point to same | 21:50 |
| lifeless | ok, -> monthly allergy injection time | 21:50 |
| gary_poster | lifeless, zero rush (I'm EoD soon), but if sometime today you could review my most recent comment on https://bugs.launchpad.net/launchpad/+bug/607961 for broad concerns, advice, or agreement, I'd appreciate it. | 21:51 |
| _mup_ | Bug #607961: wadl generation timeout? <lp-foundations> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/607961 > | 21:51 |
| flacoste | lifeless, deryck: /QA is also a central QA page | 21:54 |
| lifeless | gary_poster: tab is open, will look when I return | 21:54 |
| gary_poster | :-) thanks lifeless | 21:54 |
| flacoste | i looked at the qa tagging one and wouldn't find a place where to put the information in | 21:54 |
| flacoste | which wouldn't be out of place | 21:54 |
| flacoste | i emailed diogo to see if he could work on a clean-up of the wiki | 21:55 |
| flacoste | let's see what he says | 21:55 |
| deryck | ok, cool. | 21:56 |
| deryck | Thanks for chasing that up flacoste! | 21:56 |
| LPCIBot | Project windmill-devel build #267: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill-devel/267/ | 21:57 |
| === matsubara is now known as matsubara-afk | ||
| deryck | Can we please kill those windmill notices? Windmill is dead to us. | 21:59 |
| deryck | wgrant, maybe you're the contact for that? ^^ | 21:59 |
| sinzui | windmill is dead to me | 22:03 |
| sinzui | Windmill was never alove for me | 22:03 |
| abentley | deryck: We can stop tilting at windmills? | 22:04 |
| flacoste | deryck: StevenK is I think | 22:07 |
| sinzui | deryck, StevenK own the jenkins setup. It is lying now, it was not lying yesterday about the broken YUI test | 22:07 |
| sinzui | I fixed the YUI test | 22:07 |
| deryck | abentley, indeed. we'll move to selenium2/webdriver at the Thunderdome. | 22:08 |
| abentley | Yay! | 22:08 |
| deryck | flacoste, sinzui -- ok, thanks. StevenK can we kill the Windmill runner? Not needed now. | 22:08 |
| poolie | gary, hi? | 22:14 |
| deryck | until tomorrow then, everyone.... | 22:17 |
| poolie | cheerio der | 22:32 |
| poolie | deryck | 22:32 |
| micahg | lifeless: firefox 5 is out for everyone | 23:06 |
| micahg | at least in naty | 23:06 |
| micahg | natty | 23:06 |
| wgrant | Yay, no more Windmill. | 23:43 |
| sinzui | wgrant, StevenK, wallyworld_, I will be late to our meeting. Can we postping it about an hour? | 23:47 |
| wallyworld_ | sinzui: ok | 23:47 |
| wgrant | sinzui: Sure. | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
