[00:01] cool [00:02] Rargh, the lack of tab completion for bzr mv is really really annoying [00:03] StevenK: It's pushed, anyway. [00:03] wgrant: I've already commited and pushed my revision, so like you said to me last night: Way ahead of you. [00:03] Heh [00:05] I wish lp-open worked with piped branches [00:05] fuuuu [00:05] test failuer. [00:08] and I don't even know whats going wrong. [00:09] well, what happened ? :) [00:09] http://paste.ubuntu.com/687980/ [00:10] nigelb: You missed a bit [00:10] Effectively [00:10] column "statusexplanation" does not exist\nLINE 11: SELECT statusexplanation FROM BugTask\n ... [00:10] FFFFFFFFFFFFFFFFUUUUUUUUUUUUUUU. [00:10] My devel landing missed something? [00:11] Looks like [00:11] *headdesk* [00:11] nigelb: How did you search for it? [00:12] grep inside lib/lp I think. [00:12] I see it in oops.py and oops_prune.py [00:12] grep lib, not lib/lp [00:12] Oooooh. [00:12] Sigh. [00:12] And look into bzr grep [00:12] Now I have to land something to devel [00:12] or . in fact, for complete coverage. [00:12] It is AWESOME [00:12] and then re-land [00:12] bzr grep ++ [00:13] nigelb: lib/canonical/launchpad/scripts/ftests/test_oops_prune.py, lib/canonical/launchpad/scripts/oops.py and lib/lp/bugs/stories/bugs/xx-bug-activity.txt [00:13] the last one I think is fine. [00:13] nigelb: Since your earlier work has landed, this must be a seperate branch [00:13] another incremental landing for the same bug? [00:13] Yup [00:14] k [00:14] nigelb: You're learning, it happens [00:14] That doesn't mean I'm happy about it :) [00:15] StevenK: https://code.launchpad.net/~stevenk/launchpad/denorm-bspph-model/+merge/75093 has db and model code mixed - is that intentional ? [00:15] I missed the pre-req branch, I've resubmitted it [00:15] ah cool [00:15] Damn pipes :-P [00:16] Hrm, what do I do for this query? http://paste.ubuntu.com/687983/ [00:16] remove the select and where? [00:16] Drop lines 10-12 [00:16] UNION ALL [00:16] SELECT statusexplanation FROM BugTask [00:16] WHERE statusexplanation %(posix_oops_match)s [00:17] aha,okay. === wgrant changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: wgrant | Critical bugs: 263 - 0:[########*** stack smashing detected ***: ./lp terminated [00:31] Oh, excellent. Reviewer on duty earlier. [00:31] *earlier than I expected. [00:33] Project devel build #1,062: STILL FAILING in 1 hr 3 min: https://lpci.wedontsleep.org/job/devel/1062/ [00:34] That is suboptimal. [00:34] StevenK, lifeless: Do we want to revert stub's rev, or expedite the pgbouncer fix and see if it helps? [00:34] wgrant: Was there thoughts of removing opinion? [00:35] (I should have asked "Whats your opinion on removing opinion") [00:35] It should never have existed. [00:35] +1 [00:35] It was meant to be removed once the experiment failed, but that never happened. [00:36] Excellent. Shall I proceed to destory that as well? [00:36] Needs discussion. [00:36] And migration. [00:36] Which is why it shouldn't have been added. [00:36] A bug with status "Opinion" perhaps? :) [00:36] It was pointless, and fixing it is expensive. [00:36] Expensive in terms of downtime? [00:36] No. [00:36] Or in terms of plan effort. [00:36] That's easy. [00:37] Plan effort, mainly. [00:37] plain [00:37] *plain [00:37] Hrm. How hard? [00:37] The Bugs squad no longer exists. [00:37] So they aren't around to abort the experiment. [00:37] lifeless: Can we abort the experiment? :) [00:37] Lets declare Teal as bugs squad and declare it aborted? :P [00:38] last I heard there was a final signoff needed [00:38] which jml may or may not have done before he stepped down [00:38] \o/ [00:38] That kind of effort. [00:38] I think its currently in limbo, but there isn't a lot of point rushing it when IssueTracker is just around the corner [00:39] IssueTracker? [00:39] ... he says as a feature is extended to 10 months [00:39] wgrant: whats this about pgbouncer? [00:39] http://ec2-204-236-255-184.compute-1.amazonaws.com/ is running my 0.0.5 upgrade atm [00:39] lifeless: With stub's librarian<->pgbouncer interaction tests, jenkins no longer works. [00:39] lifeless: It's unclear if buildbot works. [00:39] We'll find out soon, [00:39] wgrant: do they fail locally ? [00:39] But I now consider Jenkins failures to be fatal. [00:40] lifeless: https://lpci.wedontsleep.org/job/devel/1062/console [00:41] It passes locally. [00:42] lifeless: if you are able to +1 my db-devel mp in the next 1/2 hour, i can make the next bb run :-) [00:42] It needs to be sooner than that. [00:43] 15 minutes will be pushing it, even. [00:43] buildbot's estimates sort of suck. [00:43] ah [00:43] It would not surprise me if it finished in less than 5. [00:44] Haha [00:45] that's not nice :-( [00:48] Operation timed out. [00:49] wallyworld_: And it's done. [00:49] rofl [00:49] Finished 00:48:43 [00:49] 10:43:43 < wgrant> It would not surprise me if it finished in less than 5. [00:49] How the.. [00:50] wgrant = nostrodamous [00:50] buildbot's estimates suck. [00:50] Jenkins tend to work out the time much better. [00:50] i know that now :-( [00:50] And buildbot will "forget" the time if a build fails [00:50] i wish we could move to jenkins [00:51] bah. iwlagn --fail-- [00:51] wgrant: do they fail locally ? [00:51] lifeless: No. [00:51] It'll be in buildbot in a couple of hours. [00:51] I can lp-land the 0.0.5 upgrade if you want [00:51] lifeless: Can haz db review for two branches so they can hopefully be deployed tonight as part of FDT? [00:52] lifeless: That might be handy. [00:52] lifeless: It looks safe to me... [00:52] StevenK: urls ? [note that we only do one change per fdt. So you can't get in anyhow] [00:52] lifeless: We have a week of patches queued already. [00:52] https://code.launchpad.net/~stevenk/launchpad/denorm-bspph-indices/+merge/75094 is mine [00:52] And we deployed 7 on Friday without trouble. [00:53] I know we did. [00:53] wallyworld_: RT #43352 [00:53] <_mup_> Bug #43352: ipp jobs not purged; purging causes 100% cpu usage < https://launchpad.net/bugs/43352 > [00:53] StevenK: Anyway, you're too late for today. [00:53] ok, lp-land on its way [00:53] StevenK: buildbot has started already. [00:53] Oh! [00:53] No it hasn't. [00:53] wgrant: the point of one patch at a time is recoverability and diagnosis. Risk mitigation. [00:53] Indeed [00:53] wgrant: its nice that folk are keen. [00:53] Because lucid_lp was broken, there was no merge. [00:54] wallyworld_: You can still get your patch in if you want. [00:54] wgrant: but, doing batching won't make this -better- [00:54] lifeless: This is half joking -- but we want to go faster and you're trying to slow us down. [00:54] StevenK: those are not FDT safe. [00:54] They aren't? [00:55] StevenK: they are hot changes. [00:55] StevenK: I want to make change *safe* and *frequent* [00:55] So I can just ask stub to add the indexes for me? [00:55] yes [00:55] Right [00:55] flacoste: ah thanks [00:55] can't be done during a backup or other long transaction [00:56] I'll talk to stub when he surfaces [00:56] Now to see if I can reorder this pipeline [00:56] StevenK: He surfaced a few hours back. [00:56] He was probably just still up. [00:56] StevenK: anyhow, as the guy that got buyin and resourcing for fast downtime, I think I can can say I've made a huge improvement to 'going faster' :) [00:56] Given he appeared right after FDT last night. [00:57] He said "Cause I woke up at 3pm of course. What a silly question!" [00:57] Haha [00:57] Hm, can't reorder pipes [00:58] lifeless: Thanks, jenkins is building with your pgbouncer fix. [00:58] StevenK: You have to do it manually. [00:58] Edit the branch.conf of each. [00:58] I'll just delete the pipe [00:58] wgrant: Can haz review? https://code.launchpad.net/~nigelbabu/launchpad/the-return-of-destory-statusexplanation-88545/+merge/75099 [00:58] Hahahaha [00:58] destory [00:59] :D [00:59] nigelb: Hm, how did it land with those references still there? [00:59] Oh, right. [00:59] I understand now. [00:59] Entirely different places. [01:00] wgrant: err needs the incremental flag [01:00] nigelb: I see you fixed some lint... do you feel like fixing the last three? [01:01] (two long lines, one unused variable) [01:01] one unused variable is false positive [01:01] its used in SQL query [01:02] Ah, and it uses local() to get it in? [01:02] *locals() [01:02] vars() [01:03] Ew [01:03] want me to change that? [01:03] Let me see. [01:03] Since that's the only var, yeah. [01:03] Might as well fix it. [01:03] Also fix the two long lines while you're there. [01:04] One of which is the regex. [01:04] This stuff doesn't get touched frequently, so it's nice to get rid of the lint when it is. [01:04] close the quotes, use \, and start quotes in new line? [01:04] I'd use parens instead of \ [01:04] foo = ( [01:04] "barfewfwefwQ" [01:05] "efwfwefwfw") [01:05] okay. [01:05] Perl! s///x [01:05] /x allows comments and whitespace *inside* regexs [01:06] http://xkcd.com/208/ [01:06] Yes, yes. [01:06] Go way, I know regular expressions. [01:06] s/way/away/g [01:06] But,yeah. [01:06] g not needed, you're only replacing once [01:07] :-P [01:07] Dammit. [01:12] wgrant: If you're free, https://code.launchpad.net/~stevenk/launchpad/denorm-bspph-model/+merge/75100 [01:12] StevenK: Doesn't that depend on the hot index? [01:13] You say it can land anyway, but doesn't it include the patch? [01:13] It doesn't any more [01:13] Ah, no prereq any more. [01:13] icy. [01:13] And it doesn't need the index, no, it just adds the columns to the model [01:13] Yeah, but I thought that was the branch I saw earlier with the DB patch. [01:13] That you said needed a prereq. [01:13] Yes, I was fighting with pipes [01:14] And then lifeless said the patch is unsuitable and so I resubmitted the MP again [01:14] "This time, for reals" [01:14] StevenK: erm, its not a FDT patch; it was fine in all other regards. [01:14] What other kind of patch do we have!? [01:14] wgrant: suggestions on "description='https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1Foo666'" [01:15] StevenK: hot db patches and code patches. [01:15] its inside the sql query [01:15] nigelb: [01:15] description= [01:15] 'https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1Foo666' [01:15] Is that sufficient? [01:15] Otherwise use || to concat. [01:15] StevenK: https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess#Hot_Patches [01:16] wgrant: Is this fine? http://paste.ubuntu.com/688008/ [01:16] StevenK: I'm not needed? ;) (really wish awaylog gave context) [01:16] nigelb: If that's short enough, yep. [01:16] StevenK: and https://wiki.canonical.com/Launchpad/PolicyandProcess/ProductionChange#Hot_database_patches [01:18] wgrant: Updated MP. [01:18] lifeless: That's what I said -- I was going to talk to stub about the indexes when he surfaces [01:18] right [01:18] StevenK: you still need to land the patch though [01:18] StevenK: I guess all I'm saying is that your patch wasn't *bad*, it just *wasn't FDT relevant* [01:18] nigelb: You are now lint-clean? [01:19] Yes [01:19] Pasted on MP description as well. [01:19] StevenK: and I suspect I gave the wrong impression before [01:19] StevenK: so I want to fix that up [01:19] What the... every other lint I read has barry as author/co-author. [01:20] s/lint/PEP [01:20] lint, PEP, same thing :P [01:20] lol [01:20] he is the flufl [01:20] But yeah, barry is fairly Python. [01:20] heh [01:21] lifeless: I didn't say bad, I said unsuitable [01:21] nigelb: Looks good, thanks. [01:21] StevenK: ok, if we're copacetic, cool. Sorry for the sidebar :) [01:21] nigelb: Shall I land it? [01:21] wgrant: yes, please :) [01:21] wgrant: With --incremental [01:22] Indeed. [01:22] I only noticed last week that Barry co-authored PEP8. I've read that a zillion times and never noticed! [01:23] Ok, now I can go sleep without something left to do. [01:23] Night nigelb. [01:24] Its 7 am, but yeah. Laters. [01:24] nigelb: uhm. Sustainable patches please ;) [01:24] lifeless: Huh? [01:25] nigelb: You Need To Sleep. [01:25] What did I write unsustainable? [01:25] nigelb: If you're not gone yet, care to set a commit message? [01:25] Setting. [01:25] lifeless: sorry to nag - if you are able to +1 my db-devel mp i can land it before something else triggers bb :-) [01:25] lifeless: I was up till 4 for work, then I got test failure email, and then sat and fixed :) [01:26] wallyworld_: I prefer to let stub review them all as much as possible [01:26] ok. np [01:26] wgrant: What's the official word on that? Some reviewers like me setting the commit message, otheres do it themselves. [01:26] wallyworld_: your patch will be several days away anyway, due to folk dogpiling in so excitedly ;) [01:26] wallyworld_: which is nice. [01:26] nigelb: They're just being nice. [01:27] nigelb: Generally the author sets it. [01:27] Oh. /me notes for future. [01:27] wallyworld_: and may make the one-patch-per policy get revisited. [01:27] I'm in queue for a db patch as well :D [01:27] lifeless: you you are enforcing that atm [01:27] sounds a bit rigid [01:27] wallyworld_: FTR - https://dev.launchpad.net/Database/LivePatching [01:27] (they landed 7 patches the other day. wgrant was plotting 3 tomorrow :P) [01:28] Or was it 2) [01:28] They can't land in the same run [01:28] wallyworld_: bah, wrong link [01:28] nigelb: from reading the ML wasn't the 7 an exception to try and catch up? [01:28] nigelb: Instance is starting. [01:28] nigelb: Now go away. [01:28] :) [01:28] wallyworld_: on https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess#Making_a_database_patch it has discussion about adding columns and performance [01:29] * nigelb goes away. [01:29] wallyworld_: the reason for one at a time is to avoid multiple zomg's. [01:29] wallyworld_: db schema changes are -the- most risky routine thing we can do. [01:29] sure, but if there are a few totally orthogonal changes.... [01:30] these could be done together [01:30] they could [01:30] if we want to risk multiple disparate fallouts all at once. [01:30] Otherwise people will just conspire to do more things in one patch. [01:30] eg. I'm dropping 36 tables in one patch instead of 36. [01:30] which is fine [01:30] its one conceptual thing. [01:30] wgrant: Otherwise we'd need to jump to 2209 :-P [01:30] folk aren't going to be silly. [01:30] there is precisely one DBA. [01:31] lifeless: Right, they're going to be sensible and work around a silly restriction :P [01:31] speaking bluntly, if we have a shitstorm, there is only one person that will be fixing it. I don't want us to -ever- have 2 shitstorms and one person working on them. [01:31] lifeless: btw, i did read that wiki page on adding columns but then saw previous patches adding not null columns and figured it must have been a "soft" policy [01:32] wallyworld_: it is soft 'Similarly, new columns must default NULL unless the data size is extraordinarily small. ' [01:32] wallyworld_: Branch is not extraordinarily small :) [01:32] wgrant: if folk batch inappropriately, I will veto their changes. [01:32] wgrant: and stomp very hard. [01:32] Bah. [01:32] wgrant: there is a fundamental cultural change we *will* make. [01:32] fair point. i can't recall the example i saw, but i could have sworn it was for a lrgish table [01:33] wallyworld_: if it was more than 6 weeks ago it was before FDT. [01:33] ah that makes sense [01:33] wgrant: the payoff for this change is a more reliable process and that means we can execute more often. [01:34] wgrant: we have a -long- way to go to prove that we can be trusted to execute changes rapidly. Until we have things that make it more risky, are well, silly risks to take. [01:35] wgrant: before FDT we were doing *6* schema changes a month. [01:35] wgrant: even with 2-step changes, 12 a month is well below the capacity we could do if we had to and still be doing one-per. [01:36] wgrant: so arguing that batching is important right now seems specious and to be ignoring the very real risk tradeoffs that the new process is designed around. [01:36] Perhaps. [01:37] can you make an affirmative argument for why we should accept the increased risk that batching brings *right now* [01:38] I don't believe there is significant credible risk in batching some kinds of patches. [01:38] how good would you say our risk assessment for schema patches is? [01:39] In terms of performance? Terrible. In terms of blowing up? Pretty good. [01:39] like, if we bet 1000 dollars on the patch being sideeffect free, per patch, how often would we payout [have a patch with undesirable side effects] ? [01:39] When have we had problems recently, apart from bugsummary fun? [01:40] If we deploy something that causes grief, we need to roll it back at the next slot - or even sooner if its really bad. That means a pipeline stall on *all* db patches [so we're not compounding the error] [01:41] wgrant: we've blown up a number of collections with indices that caused sideeffects in other queries [01:43] True. [01:44] add to this that we have a number of 24 hour cycles [01:44] oops reports [01:44] api scripts in cron [01:44] its hard to tell if we've borked something without giving it some time to settle in. [01:44] we need to fix all of this stuff [01:44] drive the intervals down [01:44] get more responsive. [01:45] everything we batch gets in the way of driving the lead-time lower [01:45] so, we're not batching here. Unless a -really really really- compelling argument that we *want* to batch, in everything, is made. [01:45] How about that we're not going to be driving down intervals for at least 18 months? [01:46] So we're going to have few opportunities for optimisation until then. [01:47] (unless you do it all single-handedly) [01:48] We are at 263 criticals, and no crisis has been declared. [01:48] We are not going to be improving anything apart from criticals for a *very* *long* *time*. [01:50] francis is analysing that [01:50] fdt is one example of driving down intervals [01:50] Right, but I think it needs more of a declaration of crisis than an analysis. [01:50] So I wouldn't say single handed driving things down. [01:51] FDT wasn't single-handed? It was entirely Technical Architecture. [01:51] But all the SOA stuff - oops with rabbit etc - are all dovetailing into more responsiveness in our systems [01:51] Single-handed. [01:51] red are working on rabbit [01:51] lol [01:51] thats support for this [01:52] we have the test suite stuff enqueue for this year [01:52] hahaahhahha [01:52] 30m test runs or thereabouts [01:52] rofl [01:52] okok, 60m. [01:52] lol [02:00] I am impressed with your vision for these improvements. [02:00] But I present exhibit A. [02:00] http://webnumbr.com/launchpad-critical-bugs [02:01] Everyone seems to be ignoring the fact that we are probably never going to exhaust the queue. [02:01] All progress is predicated on that happening. [02:02] It's been clear for at least a month, and probably 3.5 months, that a crisis needed to be declared. [02:02] wgrant, so do you think there should be less feature work and more critical bug work, or ...? [02:02] I don't know. [02:02] Probably. [02:02] But the current situation is dire. [02:02] And it is steadily getting even worse. [02:03] What we're doing now is not working. [02:03] At. All. [02:03] so [02:03] the trend is a problem [02:04] Even more amusingly, the squad that was unassigned at exactly the time the downward trend stopped will remain on feature work until probably April. [02:04] thats why francis is analysing to determine the source of the criticals. [02:04] Are we breaking things too often? [02:04] are we still finding debt that meets the policy rules? [02:04] etc. [02:04] until we have that breakdown, there isn't any change that is sensible to take - we need data. [02:04] this is a crucial thing for us. [02:05] Well, when are we likely to have results? [02:05] I don't know. [02:06] I forgot to ask him today. [02:06] as an example though - if the problem is that we're creating more criticals. [02:06] We have more than 25% more criticals than when the problem first becams eclear. [02:06] more folk working on criticals might just increase the rate at which we break things. [02:08] most of the criticals seem to be timeout/db related right? (just my observation, don't know if I'm right or not) [02:08] All is lost, so I am going to have lunch. [02:13] lifeless: your pgbouncer fix worked, btw. [02:15] heh [02:15] thats good [02:16] wgrant: care to note that in one of the bugs? (so we learn from our mistakes ;P) [02:18] lifeless: Commented on bug #848400 [02:18] <_mup_> Bug #848400: fixture shares fd's with testrunner process, will cause test hangs and worse. < https://launchpad.net/bugs/848400 > [02:34] jamesh: around ? [02:34] hi [02:35] hi [02:35] got time to talk storm ? [02:35] jamu and I weren't sure if we needed to rollback my landing [02:35] sure. [02:35] or to tweak, etc [02:36] I don't think it is worth rolling back: it is new code that isn't being used anywhere, so we may as well build on top of it [02:37] I replied to your review [02:37] (and thanks for that) [02:37] so, paramstyle was a reference to the DB-API spec: "pyformat" is the style used by psycopg2 with "%s" as a marker [02:37] ah [02:37] and qmark is the style used by sqlite with "?" as a marker [02:37] I haven't read that spec [02:38] how is something like "column LIKE '%s' AND column2=%s" handled where the LIKE clause is actually a suffix search, not a substitution [02:38] the degenerate case that would cause problems would be something like connection.execute(u"SELECT ? = '%s'", (u"foo",)) [02:39] on a backend using the qmark paramstyle, the interpolation would fail in the tracer. Of course, it would fail earlier on a pyformat paramstyle backend though. [02:39] one way to handle it would be a try:except: around the interpolation with a fallback of outputting something more like debug does. [02:40] or just the plain statement. [02:40] fyi: you might find the startswith(), endswith() and contains_string() sql expression methods in Storm handle most of the LIKE clauses you have pretty well [02:41] jamesh: I think we use them in various places [02:42] do they compile to "column LIKE %s" , (u"%suffix",) ? [02:42] more-or-less [02:42] for the quoted '%' case for a LIKE expression, the if you're using a pyformat paramstyle backend, you'd usually have to escape the percent sign (one of the reasons some people dislike pyformat) [02:43] \%s ? [02:43] %s [02:43] gar. "%s" [02:43] xchat seems to be eating the double percent sign :( [02:43] hahaha [02:43] %%s ? [02:43] yes. [02:44] so, what should we test ? [02:45] Storm's startswith(), etc methods change the glob characters to ones that don't look like a pyformat interpolation sequence [02:46] If you have an unescaped "%" character, I don't think psycopg will be particularly happy anyway. [02:47] I'm not aware enough of storms needs to predict the missing tests / changes. [02:47] what I copied over is working live in LP with the pg backend. [02:47] >>> cursor.execute("SELECT %s = '%'", ('%',)) [02:47] Traceback (most recent call last): [02:47] File "", line 1, in [02:47] IndexError: tuple index out of range [02:49] if I understand correctly you're saying there isn't an issue [02:49] because something that would break the tracer will break pscyopg too [02:49] there probably isn't an issue for psycopg2 and other pyformat backends [02:50] people could pass queries through that will cause problems on qmark backends [02:50] because we don't escape existing %s's on qmark lookups ? [02:51] right. At the point where the tracer is running, the query will be in the adapter's preferred format, so we wouldn't expect '%' interpolation at that point [02:52] jamesh: but the quoted_statement re sub should fix that [02:52] I guess the code should look something like: (a) if connection.param_mark == '?', double all percent signs and convert param marks to '%s' [02:52] (b) if param_mark is '%s', don't alter the query string at all [02:53] if param_mark is something else again, panic :) [02:53] ah, we preserve %s's [02:53] mmm [02:53] how about [02:53] if param_mark is not %s: double all percent signs, otherwise double all non-%s % signs. [02:54] then convert marks to %s [02:54] done [02:54] wgrant: Please take back your "Lies." comment: http://pastebin.ubuntu.com/688053/ [02:54] I don't think you should need to do anything to the '%' signs if param_mark is '%s' [02:54] ian broke LP with that assumption. [02:54] it was a fun day of broken buildbot. [02:55] if the non-interpolated '%' signs haven't been escaped, then they will fail when passed to the database adapter anyway [02:55] apparently we have something somewhere that manages this [02:55] ENOIDEAWHERE. [02:59] StevenK: Oh? [03:00] * StevenK waits for wgrant to read the pastebin [03:00] I read the pastebin. [03:00] I see a SourcePackageName declared as an integer. [03:01] jamesh: what about the other thing [03:01] jamesh: the control api [03:02] lifeless: the part I cringed at was exposing the threading.local() object as part of the public API to the tracer [03:02] wgrant: ALTER TABLE SourcePackagePublishingHistory ADD COLUMN sourcepackagename INTEGER REFERENCES SourcePackageName [03:03] jamesh: yes, I explained the things that led me to doing that. [03:03] StevenK: I'm not sure what the DB has to do with this. [03:03] jamesh: and a possible alternative, but it seems rather like yagni to me. I'm willing to do it if needed [03:03] StevenK: SourcePackagePublishingHistory.sourcepackagename is not an integer, so why is ISourcePackagePublishingHistory['sourcepackagename'] an Int? [03:04] wgrant: Oh, I've declared it wrong in the model? [03:04] In the interface. [03:04] The code I quoted! [03:04] OH [03:05] Attribute() and Int() are the wrong way around. [03:05] You know, the only two types in the code I quoted :) [03:05] Sorry, I read it as "You have sourcepackagename in BPPH and vice versa" [03:08] jamesh: http://paste.ubuntu.com/688059/ for the quoting thing. [03:09] lifeless: the timeline_factory argument or an abstract get_timeline() method method would be my preferred APIs. Do you have example code of how you'd use the class in Launchpad as it is currently written though? [03:09] jamesh: adapter.set_request_started [03:10] jamesh: the version of this tracer in LP knows about the 'current request', so it calls 'get_request_timeline' [03:10] jamesh: which could drop straight into a timeline_factory parameter. [03:10] lifeless: re. the paste, I still think you should be able to get by without munging the statement in the connection.param_mark == '%s' case [03:11] jamesh: you can't because "%%" % () -> "%" [03:11] jamesh: but we want "%%" to be shown as "%%" [03:11] lifeless: why? [03:11] jamesh: the munging is to *preserve* the %'s. [03:11] lifeless: they aren't preserved in the statement executed by the DB [03:12] they match what folk see when they look at the code though, which was a strong consideration. [03:12] hmm [03:12] I could go either way. [03:12] I'm convinced its a presentation thing. [03:13] it also happens to ensure its safe to format, but thats incidental. [03:13] my point earlier was that if it isn't safe to format, then it is going to fail when passed to the adapter anyway ... [03:13] jamesh: so I changed to the thread locals() because it seemed to me that that is the common need [03:14] jamesh: right, I got that, but wouldn't it be better fo rhte adapter to be the thing raising the error ? [03:14] jamesh: lets users avoid confusion about what is wrong [03:15] lifeless: if that is a concern, I would consider including a code path that handles errors from the interpolation step. [03:15] jamesh: if you prefer a factory, I'll change it to want a factory, that happens to fit closer to LP because it already *has* such a factory; it will mean more glue in the wsgi case though. [03:16] mm [03:17] actually it has a factory which needs a guard because of other bugs. [03:17] but meh, its shallow either way. [03:17] here's how psycopg2 handles the percent sign: [03:17] >>> cursor.mogrify("SELECT %s LIKE 'foo%'", [u'foobar']) [03:17] "SELECT E'foobar' LIKE 'foo%'" [03:18] gar. imagine there is a double percent sign in the LIKE clause [03:18] on the >>> or the " starting lines ? [03:18] the first line [03:18] right [03:19] mogrify() is a psycopg2 specific API for invoking its interpolation code [03:23] jamesh: ok, so what now? I'm getting lost ;) [03:26] lifeless: okay. I think your paste looks like a good improvement, but (1) I'd prefer not to munge the statement in the pyformat backend case and (2) I think the actual interpolation stage should check for TypeError and use some other place holder string in that case. [03:26] wgrant: see anything new in debian domination? Our challenge for today is to get it to re-publish an SPR. [03:27] jtv: It looks OK, and we know that it handles the republishing case OK from my archivepublisher testing. [03:27] We could retest that with gina if we really want to, though. [03:27] jamesh: do we need to defend against unreprable variables ? [03:27] jamesh: to-database shold be sane, no ? [03:28] lifeless: I think we can depend on to_database() being sane: it gets called outside of the tracer in this code path anyway. [03:29] wgrant: hmm… intra-release domination is the same thing for gina domination and publisher domination, so yes, we can take that as validation. [03:29] jtv: So, any reason not to deploy it and watch the world burn? [03:30] The world won't burn. For that, I need to add that commit first. [03:30] True. [03:30] not sure about repr(). The existing DebugTracer grabs the repr() of the values and hasn't been a pain point so far (although it isn't using to_database()) [03:30] so it might be worth leaving it as is, and see how it works [03:31] jtv: Shall we deploy up to 13913, then? [03:31] Let me look that up. [03:32] Hmm, we should really get past 13917 today. [03:32] But 13914 is a feature-flagged blocker. [03:32] lifeless, can we have another go at bug 660264 now haproxy is live? [03:32] jamesh: typeerror - http://paste.ubuntu.com/688065/ [03:32] <_mup_> Bug #660264: bzr+ssh on launchpad should fork, not exec < https://launchpad.net/bugs/660264 > [03:32] jamesh: I'd like to leave the %% handling on postgresql alone for now [03:33] jamesh: get everything migrated and consolidated, then revisit. [03:33] lifeless: fair enough. The second paste looks good. [03:33] poolie: no, we need those two bugs I escalated with you addressed first. [03:33] smooth reconnect etc [03:33] ok [03:33] wgrant: 13913 is doable for me, although obviously I'd like to get that commit in with the rest. Can we treat cocoplum as if it were NDT now? [03:33] poolie: haproxy is only half-live, we're not actually in nodowntime mode yet. [03:33] poolie: yes, those. [03:34] jtv: gina isn't on cocoplum [03:35] jamesh: so, you're really against the threadinfo thing ? [/me asks with a vague hope :P] - it just seems like -all- the factories folk will write will be identical. [03:35] wgrant: where then? And is it NDT? [03:35] jtv: iron, and yes. [03:35] * jtv shuffles cards [03:35] * jtv eagerly waits for wgrant's message notification bubble to get out of the crucial spot where he needs to see. [03:35] Bubble bursts. [03:36] jtv: what was that? [03:36] jtv: I didn't quite hear you [03:36] jtv: Could you please repeat? [03:36] jtv: Please? [03:36] That's okay, I no longer need to see that precise spot. [03:36] But it's gratifying to see you go to all that wasted effort. [03:36] Curses. [03:37] wgrant: what's that? [03:37] I didn't quite hear you [03:40] what does 'half-live' mean? [03:40] it's in place but it doesn't fail over? [03:40] the project isn't complete [03:41] (because we can't deploy to it regularly, which was the goal) [03:44] meep [03:44] thats a worry [03:44] Hard / Soft Page ID [03:44] 902 / 227 ScopedCollection:CollectionResource:#message-page-resource [03:44] 870 / 21 Product:+bugtarget-portlet-bugfilters-stats [03:44] 820 / 158 BugTask:+index [03:44] 766 / 240 Distribution:EntryResource:searchTasks [03:45] 291 / 0 Distribution:+bugtarget-portlet-bugfilters-stats [03:45] 288 / 0 Person:EntryResource:searchTasks [03:45] 211 / 24 MaloneApplication:+bugs [03:46] lifeless: Indeed. I've wondered if the journal rollup isn't happening or something. [03:46] lifeless: I saw a new garbo job fly past this morning. [03:55] jamesh: http://paste.ubuntu.com/688073/ [03:59] select count(*) from bugsummaryjournal; [03:59] count [03:59] ------- [03:59] 875 [03:59] wgrant: ^ [03:59] wgrant: Have another look at https://code.launchpad.net/~stevenk/launchpad/denorm-bspph-model/+merge/75100 ? [04:02] lifeless: Well, there goes that :/ [04:02] Hmm. [04:02] What could it be, then. [04:04] StevenK: What about the other places that create [SB]PPH? [04:04] StevenK: I think there are some more. [04:04] StevenK: Although I tried to unify most of them, some slipped through. [04:04] Also, readonly=False? [04:04] While it's not exposed through the API now/yet, that seems like a bad start :) [04:05] lifeless: that does look like a better API to me. If we do find everyone is passing the same timeline_factory implementation in later on, perhaps we can revisit it. [04:07] https://code.launchpad.net/~lifeless/storm/timelinetracer/+merge/75109 [04:07] wgrant: I thought it was only new{Source,Binary}Publication :-( [04:07] StevenK: That's the aim. [04:07] StevenK: But it's not there yet. [04:08] StevenK: Also, at least publishBinaries has a batch interface that doesn't involve instantiating the class. [04:08] jamesh: ^ [04:08] lifeless: saw it. I'll review it in a sec. [04:09] thanks [04:11] lifeless: is there a way in storm to hook into an object lifecycle such that i can access any dirty properties' old and new values when a db update is done? [04:11] uhm, probably at least two. Why? [04:13] lifeless: i want to trigger a db update if someone changes a particular property and then saves the object [04:13] wouldn't a regular property be sufficient ? [04:14] i could hook into an IObjectModifiedEvent i suppose, but i'd rather do it with just storm [04:14] huh? [04:14] just foo = property(...) [04:16] that would work. i was wanting to not do any db work until the flush. but i could set a flag and hook into the storm flush event [04:16] perhaps some specifics would help the discussion [04:16] I'm struggling to understand the constraints [04:17] wallyworld_: Er? [04:17] wallyworld_: Isn't that what triggers are for? [04:17] when a branch has it's stacked_on branch changed or it's private property changed, i need to update the branch table to set transitively_private for other branches that may be affected [04:18] that sounds like a trigger case to me [04:18] ok. for some reason i thought we preferred to avoid trigegrs [04:18] running sql *just-before-a-flush* is going to be -fuuuun- [04:19] wallyworld_: I loath and fear triggers, but they are the right solution to this sort of thing while we use pgsql. [04:19] i share your view, hence trying to finf a non-trigger solution [04:19] wallyworld_: if we were using e.g. cassandra, the whole way the problem is approach would be different [04:20] any pointers to where we define and set up triggers for other things? [04:20] trusted.sql [04:20] though that really wants to DIAF [04:20] I would just do it as a regular patch I think, at least to start with. [04:21] wgrant: in my efforts to pick off some of the trivial fixes so you guys can focus on the criticals... with reference to bug 763820, would the text "with the Ubuntu keyserver" be better than "with an Ubuntu keyserver" iirc there is only one right? [04:21] <_mup_> Bug #763820: double "with" on +editpgpkeys < https://launchpad.net/bugs/763820 > [04:23] G: Indeed, that sounds better. [04:23] lifeless: the patch needs to be in db-devel? and have it's own patch number and all that? [04:23] wallyworld_: yes, most definitely. [04:23] not to mention, it should've been a not an, but thats by the point since you agree with the :) [04:23] cool. thanks [04:24] G: "an Ubuntu" is correct, not "a Ubuntu"... [04:24] wgrant: you don't say "an United Nations " you say "a United Nations " because it flows better (just looked it up) [04:24] G: Sure. [04:24] But the U is not the same. [04:24] oo-boon-too [04:25] Not yoo-boon-too [04:25] i bet some people do say "an United" [04:25] maybe not incorrectly [04:25] * wgrant blames the US [04:25] It is incorrect, I'm pretty sure. [04:26] yep, lets just blame the US for everything :) [04:26] RARGH! [04:26] CONFLICTS [04:26] HULK SMASH [04:26] You conflicted with stub's new garbo? [04:26] No, this is still the model changes [04:26] wgrant: you may have a point (w/ pronounciation) [04:26] But I'll probably have to cope with that too [04:27] * StevenK gets a rope. [04:29] for i in $(find lib/canonical/launchpad/mail | tac) ; do bzr resolve $i ; done [04:29] And that solves one problem [04:30] wow `make run` is much faster now [04:31] * StevenK waits for bzr pump [04:44] wgrant: And again? [04:45] Let's see. [04:49] wgrant: there you go, MR for you https://code.launchpad.net/~dev-nigelj/launchpad/bug-763820/+merge/75111 has to be the most trivial in a while [04:50] G: *MP* [04:50] Merge *Proposal* [04:50] StevenK: I realized that after I said it [04:50] StevenK: my mind is about 10 miles away from my body atm :) [04:51] Up, down, north, south, west or east? [04:51] StevenK: You didn't get publishBinaries? [04:51] wgrant: I did a grep [04:51] StevenK: somewhat South East [04:51] bzr grep "BinaryPackagePublishingHistory\(" | grep -v makeBinaryPackagePublishingHistory [04:52] StevenK: Like I said, it does a bulk inset. [04:52] insert [04:52] Rargh, annoying [04:52] Rather, but it's the only way to not have terrible performance. [04:53] * StevenK waits for sync-pipeline some more [04:53] G: By the way, if you haven't used bzr grep, you should -- it is love. [04:54] StevenK: what is bzr grep when you meet it in the street? [04:54] (still new to bzr, but I like it) [04:55] G: It runs grep over versioned files [04:55] G: It's useful for the Launchpad tree, since we have that whole annoying lib/lp versus lib/canonical split [04:55] ahhh I just normally do "grep -r lib/lp" :) [04:56] bzr grep is faster, ignores non-versioned files, can search history [04:56] G: If you search just lib/lp, you will miss stuff. As nigelb found out this morning. [04:56] G: Hence my service announcement. :-) [04:58] bzr grep doesn't support -c :-( [05:02] poolie: you got me at faster ;) [05:02] where do I get it from? ;) [05:02] lp:bzr-grep [05:02] should've guessed :) [05:02] Or apt-get install bzr-grep [05:02] On >= maverick, IIRC [05:02] cd .bazaar/plugins && bzr branch lp:bzr-grep grep [05:03] wgrant: thanks [05:03] Since bzr can't deal with plugin directories that contain a - [05:03] * G prefers packaged stuff :) [05:03] not packaged? [05:04] * StevenK prods wgrant for more review love. [05:04] poolie: it's packaged for Natty, because after wgrant's pointer I just aptitude install'ed it :) [05:05] StevenK: What about gina for SPPH? Or does it use newSourcePublication? [05:05] wgrant: It uses newSP [05:06] Approvalised. [05:06] G: Also approved. Want me to land it? [05:06] wgrant: might as well, thanks :) [05:07] Could you set a commit message on the MP, please? [05:07] Yippie, build fixed! [05:07] Project devel build #1,063: FIXED in 4 hr 10 min: https://lpci.wedontsleep.org/job/devel/1063/ [05:08] steven@liquified:~/launchpad/lp-branches/no-more-lazr-utils% for i in $(bzr grep -l canonical.lazr.utils) ; do sed 's/canonical.lazr.utils/lazr.restful.utils/' < $i | sponge $i ; done [05:08] steven@liquified:~/launchpad/lp-branches/no-more-lazr-utils% bzr di | wc -l [05:08] 745 [05:08] * StevenK hides [05:08] wgrant: set [05:09] Thanks. [05:10] wgrant: at some point can you take a look at https://bugs.launchpad.net/launchpad/+bug/306569/comments/2 as well and give me your thoughts? (I'm also now wondering if an AJAXy +help/foo page would also do the job instead of links to the wiki etc [05:10] <_mup_> Bug #306569: Link to https://help.launchpad.net/Code from project branch listing page < https://launchpad.net/bugs/306569 > [05:11] wgrant: lazr imports are the same level as zope and so on right? [05:11] StevenK: Yes. [05:14] StevenK: you might be interested in sed -i :-) [05:14] mwhudson: But then I can't use the awesomeness that is sponge! [05:14] StevenK: admittedly, i had to look up what sponge does === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [05:27] Bah, MPs needs a link to bug link [05:30] wgrant: https://code.launchpad.net/~stevenk/launchpad/no-more-lazr-utils/+merge/75117 [05:37] StevenK: r=me [05:45] psycopg2.OperationalError: fe_sendauth: no password supplied - halp? [05:46] * ajmitch saw some mention of needing ipv6 address in pg_hba.conf for that [05:47] Yeah, see one of my recent posts to launchpad-dev [05:48] Or rerun launchpad-database-setup [05:48] host all all ::1/128 trust [05:49] thanks [06:04] wgrant, how can i actually get your rabbitfixture fix active? [06:04] just put a checkout of that branch on my path? [06:04] poolie: It should be merged now.. let me check. [06:05] 13906 Launchpad Patch Queue Manager 2011-09-09 [merge] [r=gary][bug=845658] Upgrade rabbitfixture to be oneiric-friendly [06:24] Dapper has too many architectures. [07:08] jamesh: ok, so now we need to glue this to wski. [07:11] Morning. [07:18] lifeless: yeah. I wonder what the best way to slice things would be? A WSGI middleware that simply introduced a timeline object into the environment, and another one that configured the storm tracer based on that timeline and updated oops.context might work [07:18] could do a single one if you'd never want to use the timeline module without oops and storm [07:22] I think I'd start with a single one and refactor if we change our mind [07:22] I can't recall if I've pulled the timeline formatting stuff out of LP yet or not [07:23] (it is what generates the db_statements key in the oops [07:23] I'll look at that on thursday. [07:23] yep. [07:23] where should this wsgi module live [07:23] its storm + oops + wsgi specific [07:23] so, do you stick the timeline in the oops context and rely on an on_create hook to format db_statements for the report? [07:23] yes [07:24] because the oops itself has to be bson serializable [07:24] right. Was just wondering if you did the formatting prior to generating the report [07:25] nah, its lazy [07:25] so just-in-time, and no formatting if no report [07:25] I think the formatter can live in timeline itself [07:26] as it doesn't need to import oops by default [07:26] for packaging it can 'enhances: python-oops' [07:27] I wouldn't be opposed to making it a sub-package of storm, but it could also be its own module [07:28] [I assume you don't want this in python-oops-wsgi] [07:28] right, I don't :) [07:28] (because storm is the extending thing here - there can be many orms that need oops-wsgi glue, but only one oops-wsgi for now) [07:28] zomg, p-d-r didn't crash on DF [07:33] wgrant: Hi, could you please update DF for me? (And BTW, thanks for the review, I'll address your concerns shortly) [07:33] rvba: Did you see I QAed your resolved difference thing? [07:33] (on qastaging) [07:34] wgrant: yes I did. Thank you for that. [07:34] I've got p-d-r running on DF now, so it'd be nice if I didn't have to update. [07:34] But if you do need it, I can. [07:34] wgrant: no worries, I'll do that later today. [07:34] it should be done in ~1.5 hours. [07:34] Okay. [07:49] good morning === vila is now known as babune === babune is now known as vila [08:07] Hello [08:21] wgrant: sure [08:26] jml: [08:26] Er. [08:26] Thanks. [08:47] Now part 2 of demolishment can land? [09:09] StevenK: Yup. [09:12] StevenK: Hi. The confirmation overlay stuff has landed. I'm here to help if you need me for some dirty Javascript stuff ;) [09:17] Project devel build #1,064: FAILURE in 4 hr 9 min: https://lpci.wedontsleep.org/job/devel/1064/ [09:22] wgrant: oh hai [09:22] wgrant: still reviewing ? [09:22] lifeless: If necessary. [09:22] wgrant: if so, gpgfixtures review request is up [09:22] With pleasure. [09:23] Is it? [09:23] I think I have enough now that on thursday I'll be integrating it with LP, and with gpgverifyd [09:23] I don't see it. [09:23] Oh. [09:23] *For* gpgfixtures? [09:23] yes [09:23] Not quite so exciting, but it'll do. [09:26] Still no MP diff... [09:26] Worrying. [09:26] But no scriptactivity whinging yet. [09:31] rvba: I've pushed my branch up: lp:~stevenk/launchpad/private-bug-unsubscribe-confirm [09:32] rvba: If you bzr di -r submit: you can see what I've done, and where I've tried to add ConfirmationOverlay -- a helpful hint for that bit would be most welcome. [09:33] StevenK: looking. [09:33] .Hi [09:33] I'm trying to patch lazr.restfulclient [09:33] In the absence of hacking instructions, I'm running bootstrap then buildout [09:33] But buildout fails [09:33] Error: Couldn't find a distribution for 'lazr.restful==0.16.0'. [09:34] lifeless: assertNotEqual(None, [...])? [09:34] lifeless: Shouldn't it be assertIsNot? [09:34] allenap: In what circumstances will _loads get a byte string? [09:34] allenap: re: your Storm MP [09:35] rvba: It's 7:35pm here, so I'll be in and out [09:35] stub: Not sure :) Just being cautious because of weirdness in simplejson/json. [09:35] jml, wow good luck [09:36] allenap: Right. I suspect you only need to force it it the _dumps(). The _loads() worries me as you are hardcoding UTF-8, which is incorrect. [09:36] poolie: thanks. [09:36] *someone* has to do it :) [09:36] StevenK: okay. I'll send you an email with comments ... [09:36] i don't know about that, but i did run in to confusion caused by its pth file [09:36] it seems hard to run it from source if you also have the package installed [09:36] StevenK: but I'm surprised that you don't even pass a submit_fn function to ConfirmationOverlay. [09:37] stub: From what I can remember, that's what json.loads() assumes given a byte string containing non-ASCII characters. [09:37] wgrant: thats a shrug thing [09:37] wgrant: they are equivalent [09:37] stub: I'm happy to remove the _loads() stuff though; I only need the _dumps() fix. [09:37] allenap: If you do find byte strings being passed into _loads(), we need to know where they are coming from to confirm they are indeed UTF-8 (or what encoding, eg. if they are coming from a DB storing stuff in cp1252 [09:38] wgrant: (in this case) [09:38] StevenK: can you just give me an idea about how I can test this? [09:38] stub: evening [09:38] stub: Sorry about the shenanigans around pgbouncer [09:38] allenap: If the tests pass, I think that would be best. I'll mention this with the rest of the review. [09:38] stub: So, perhaps there should be an assertion in there, that value is unicode? [09:38] jml: you need a buildout cache [09:39] jml: or to specify to buildout that it can run online [09:39] jml: there is a shared cache like the lp one, for lazr libraries. [09:39] lifeless: it was downloading all of the other things slowly enough that I thought it was online [09:39] allenap: Fine with me. [09:39] jml: hmm, perhaps it is then. [09:39] stub: Cool, thanks. [09:39] jml: if so, is 0.16.0 still on pypi [09:40] jelmer: Anything special about your import-colocated-branches branch? [09:40] lifeless: No worries. I'd be interested in what jenkins saw. I doubt the stdout/stderr issue would be at fault, but perhaps the socket open caused problems in that environment? [09:40] jelmer: It is not making the MP diff generator happy. [09:40] At all. [09:40] lifeless: umm, where exactly? [09:40] stub: StevenK can hook you up with the hanging that happened [09:40] StevenK: You have a pastebin of anything interesting? [09:41] jml: http://pypi.python.org/pypi/lazr.restful [09:41] lifeless: I don't see any download links there [09:41] there is a link to lp's +download page there [09:42] lifeless: and buildout can figure out to download the tarball from there? [09:42] who knows [09:42] I don't :) [09:42] ok [09:42] Can we switch to jenkins yet? Supporting both buildbot and jenkins envs seems a pain as they seem to flake out in different ways. [09:42] stub: parallel test project may be a good time to switch [09:42] Any blockers apart from time? [09:43] I'm told IS are now actually running jenkins instances for other departments, so that hurdle is past. [09:43] wgrant: Hmm, not that I'm aware of [09:43] no blockers that I'm aware of; just need tuits to migrate processes across [09:43] stub: hey, so great work on fastdowntime [09:43] Yup. The second 90% [09:43] lifeless: It needs to run in the DC, and not on an unsupported cloud. [09:45] wgrant: I'm going to assume that you're no longer OCRing. [09:45] jelmer: Hm, and now it's recovered. [09:45] wgrant: We can cannibalise the buildbot env if we want. Its just time and losa/dev coordination. [09:45] (For the purposes of the /topic) [09:45] gmb: I was just about to remove myself. === gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 263 - 0:[########*** stack smashing detected ***: ./lp terminated [09:45] Thanks. [09:45] np [09:46] lifeless: Ta. Seems to be working as planned. [09:46] stub: http://www.postgresql.org/about/featuredetail/feature.213 looks handy. [09:46] stub: Is that what we needed for branchrevision? [09:46] wgrant: yes. [09:46] rvba: The easiest way to test it is to create a local user by using make-lp-user, and then create a private bug in a harness with the owner as the user you created. Then browse to the bug, log in as yourself, hit Edit bug mail, and then the unsubscribe link. [09:46] stub: You may be interested to know that we had similar lag spikes both times this week. [09:47] From :25-29 or so. [09:47] I think it's karma finishing. [09:47] stub: You wanted to know about the indexes I needed? [09:47] StevenK: okay, thanks. [09:47] is this week ubuntu beta or next? [09:47] lifeless: Beta 1 is already out, dude. [09:47] wgrant: Yup. I expect it somewhat. Did the last run have the lag high water mark set to 60 seconds? [09:47] stub: not 1. [09:47] bah [09:47] StevenK: not 1. [09:47] Fail :-P [09:48] Beta 2 is the 22nd [09:48] So next week. [09:48] lifeless: Look at the ReleaseSchedule? :-P [09:48] stub: I'm not sure; I didn't see numbers. [09:48] rvba: I'm surprised that made any sense :-P [09:48] actually https://dev.launchpad.net/DowntimeDeploymentSchedule is what I needed [09:48] we have a multi-day no-fdt period during ubuntu release weeks [09:49] So I'd love if there is a push button make-virtual-lp-dev-environment script for when I switch to Oneric, and it is an opertunity to get everyone into identical dev environments. [09:49] StevenK: ;) [09:49] stub: the lxc stuff is pretty close to that. [09:50] stub: Oh, Jenkins -- https://lpci.wedontsleep.org/job/devel/lastFailedBuild/consoleText [09:50] wgrant: care to give https://launchpad.net/~mvo/+archive/apt-ftparchive-lucid/+packages a spin? [09:50] stub: for FDT going forward - I would like us to be very strict one-patch-at-a-time for the next few weeks. [09:50] lifeless: agreed [09:50] stub: I wanted to get the indexes in http://bazaar.launchpad.net/~stevenk/launchpad/denorm-bspph-indices/view/head:/database/schema/patch-2208-87-1.sql applied to prod, what do you think? [09:50] stub: prove our reliability and get some feeling for how things behave. [09:51] stub: cool, thanks! [09:51] wgrant: it has a prerequisite which was already merged, perhaps that's confusing it? [09:51] StevenK: Fine. [09:51] wgrant: I got two "Launchpad internal failure" emails, which I couldn't explain. Would those perhaps be related? [09:51] ok, gnight everyone - see you thursday. [09:51] lifeless: g'night [09:51] StevenK: Is there somewhere to log the live patch requests? I forget. [09:51] jelmer: Do they have OOPS IDs? [09:51] lifeless: Night! [09:51] * jml downloads a likely looking tarball and stuffs it into a cache [09:51] lifeless: o7 [09:52] stub: So I should craft a script and prod a friendly LOSA? [09:52] jml: I wonder if 0.16.0 has migrated off the first +download batch, so buildout can't see it any more. [09:52] wgrant: that occurred to me also [09:52] stub: Which worked out *so* well for me last time :-( [09:52] StevenK: Nah, me or the losas do that. I'll get to it later, but if there is somewhere to log them then there is less of a chance of it being lost :) [09:52] wgrant: yep, OOPS-2082MPJ3 [09:53] stub: I'll give you a friendly prod in a few hours for an update? [09:53] StevenK: losa explicitly won't do these [09:53] StevenK: they want it automated before they touch it. [09:53] *sigh* [09:53] StevenK: This is all new processes so we expect issues. [09:53] Right. [09:54] so, ./bin/test is supposed to work after buildout has run successfully, right? [09:55] cjwatson: Looks good. [09:55] cjwatson: Doesn't hang, at least. [09:55] rvba: You've managed to get into a testable position? [09:55] Can't really give it a real test until it's on DF. [09:55] lifeless: So a minor screwup happened when a series of scripts were put together and losa run, but the first one failed (setting a statement timeout for concurrent index rebuilds is borked). I think I need to explicitly sign off scripts to be run by losas for a while until we work out the edge cases and everyone is comfortable. [09:56] StevenK: I'm just reading the code now. [09:56] stub: That sounds like a good plan. [09:57] StevenK: I reckon what you want to do is now exactly what ConfirmationOverlay was originally designed for. [09:59] StevenK: the only required parameter right now is a 'button' and AFAIK you won't be providing one. [09:59] StevenK: StevenK makes sense to me [10:00] bahhh [10:00] stub: makes sense to me [10:01] StevenK: I think I can modify the ConfirmationOverlay a little bit more and then all you will have to do is something like this http://paste.ubuntu.com/688208/ [10:04] rvba: Ah, you need to make button optional? [10:04] Exactly. [10:06] OK. [10:06] So if lazr.uri is in versions.cfg but not importable after buildout, what does that mean? === matsubara-afk is now known as matsubara [10:12] its not in setup.py [10:12] or in the transitive dependencies setup.py's. [10:13] wgrant: can you take care of that or do I need to ask for something else (e.g. copying into the Launchpad PPA)? [10:15] cjwatson: I can copy it into the Launchpad PPA, but someone needs to get it into CAT. [10:15] lifeless, jml: Or you are having namespace package issues with the lazr.* stuff in Ubuntu. [10:16] lifeless: But you aren't here, are you? [10:16] wgrant: I am here. I'm *guessing* I am. [10:16] lifeless: it's in versions.cfg. Isn't that enough? [10:16] StevenK: So your patch number is allocated to something different in the dbpatches branch [10:16] jml: It needs to be in buildout.cfg [10:16] Or setup.py. [10:16] Depending on where you want it. [10:16] versions.cfg just defines which version will be used if it's needed. [10:17] wgrant: I can do that via RT. Is that needed to get it onto dogfood? [10:17] StevenK: You or wallyworld_ need to change, and I suspect it is you since you're still around. [10:17] cjwatson: Probably. [10:17] (2208-87-2) [10:17] mthaddon: How can we test a new apt on mawson? [10:17] wgrant: I'm not. [10:17] jml: versions.cfg says 'when you need X, choose version Y' [10:17] jml: it does not say 'you need X' [10:19] StevenK: Also, your MP seems to have disappeared [10:19] wgrant: you can ask for it to be installed there... [10:19] stub: It has, yes. The branch still there [10:19] stub: I can resurrect it [10:19] mthaddon: Before it's in CAT? :) [10:19] StevenK: It needs a MP, as it needs to land on db-devel. [10:20] Adding it to install_requires and running buildout doesn't seem to change anything [10:20] wgrant: that would be part of what you're asking - for it to be in a -cat suite that's only on mawson [10:20] stub: Let me jump to -87-2 [10:21] mthaddon: :( [10:21] mthaddon: OK. [10:21] wgrant: why sad face? [10:22] mthaddon: I was hoping for a quick wget and dpkg -i to test the fix. Not unexpected that it would be denied, but inconvenient :) [10:22] yeah... [10:22] cjwatson: Can you file the RT? [10:22] cjwatson: I'm trying to not be here. [10:23] stub: https://code.launchpad.net/~stevenk/launchpad/denorm-bspph-indices/+merge/75149 [10:23] Or I could just unpack the deb on mawson and hack LP to use a non-packaged version, but that might be evil. [10:24] StevenK: Want me to allocate the patch number or are you doing that? [10:24] stub: I'll do it now. [10:25] wgrant: sure. [10:25] stub: Done. [10:25] cjwatson: Thanks. [10:29] * StevenK prods ackee [10:29] Can haz diff [10:30] Argh. [10:30] Maintenance people: merge-proposal-jobs is being slow and crashing sometimes. [10:30] pls fix. [10:30] gmb: ^^ [10:31] wgrant: Is there a bug for it? [10:32] gmb: Not for the stuff that's shown up tonight, no. [10:32] gmb: But abentley has been working on related stuff. [10:32] I would grab him, except he won't be around for 3 hoursish. [10:32] wgrant: Okay. I'll grab him when he appears. [10:32] Thanks for the heads-up [10:32] gmb: It may be more urgent than that. [10:33] Hrm. [10:33] stub: Requested a review of you on the MP, when you're ready [10:33] it needs to be watched. it may recover again in a few minutes. [10:33] But it took half an hour to work again when it died 2 hours ago. [10:33] wgrant: Okay. I'll keep an eye on it. [10:34] But my knowledge of it is close to 0, so I might be reduced to prodding and going "oh, it's dead" [10:34] But I'll do my best. [10:34] Hmm. OK. I think this *is* a namespace issue [10:35] my guess is that it's finding lazr.uri of the correct version on my system and thus not installing it. [10:35] jml: Yeah, that's been a problem sometimes :/ [10:35] jml: Python namespace package support is awesome, see. [10:35] wgrant: what's the solution? [10:35] And lazr does a spectacularly bad job at it. [10:35] Um. [10:35] I tended to remove python-lazr.uri. [10:35] But that's probably not practical any more. [10:36] wgrant: that removes a lot of stuff. apport, for example [10:37] Yeah, not very practical any more. [10:37] What if you run with python -S? [10:37] Like LP does. [10:37] Yes, i know, that's Zope-grade evil, but it might work. [10:37] ./bin/test already runs with python -S [10:37] I guess ./bin/buildout needs to be run with that... [10:37] Maybe,. [10:38] nope, it is too [10:39] jml is a lean mean bug filing machine [10:39] gmb: review pretty please w/cherry on top? https://code.launchpad.net/~jtv/launchpad/bug-844550/+merge/75150 [10:41] dpm: hi [10:41] what's a good time before a release to do a call for translations (for bzr)? [10:41] two weeks? [10:42] Riddell, yeah, 2 weeks is a good rule of thumb [10:45] StevenK: Can you please lp-land that branch? (no need to shove it through ec2) I'd do it, but lp-land is bitching about missing revisions [10:45] jtv: sure [10:46] thanks—feel free to skip much of the cover letter if it doesn't interest you. [10:46] Mostly just writing it for historical record, and as proof that this has been thought about and discussed. :) [10:48] * jml moves on to launchpadlib [10:48] cjwatson: what ever happened to your multi-arch translations branch? [10:48] Still got a ticket on my board for landing it once I get word that it's been updated. [10:48] It's landed and deployed. [10:48] But not active, because we're waiting on an apt-ftparchive fix. [10:49] jtv: ^^ [10:49] OK, then I'll retire the ticket. [10:52] dpm: and where's the place to announce it? [10:55] jtv: right, you can drop that ticket; I'll drive the apt-ftparchive deployment bits (though I'll need wgrant's help to test on dogfood once RT#47856 is resolved) and I'll deal with flicking the API switch at an appropriate time [10:55] <_mup_> Bug #47856: Screenshot needs to be updated < https://launchpad.net/bugs/47856 > [10:55] jtv: thanks [10:56] Already done, thanks. [10:56] cjwatson: also, we're very close to deploying the final commit that will make all Debian SPPHs Published instead of Pending. [10:57] * cjwatson nods [10:58] the ubuntu-dev-tools change to just do status=Published is already out [10:59] gmb: Hi, could you please review this mp? https://code.launchpad.net/~rvb/launchpad/confirmationoverlay-button-optional/+merge/75154 [10:59] rvba: Sure [10:59] Thank you. [11:07] jtv: I'm not sure whether to be worried or not: You branch is one of the clearest, best explained Soyuz branches I've ever read (though bigjools's branches are also usually equally clear). I must congratulate you, on the assumption that Soyuz hasn't got simpler and I haven't got any smarter - you've done an excellent job. [11:08] gmb: that's easy then—yes, you should be worried. Thanks. :) [11:08] :) [11:09] Riddell, I'd suggest launchpad-translators(AT)lists(DOT)launchpad(DOT)net and ubuntu-translators(AT)lists(DOT)ubuntu(DOT)com [11:13] jtv: approved, with one comment about making the test a bit easier to understand (at least for us lackwits) [11:15] gmb: thanks. Insert obrant about why it's a good thing that you asked for an improvement. :-) [11:15] :) [11:19] rvba: r=me with one minor tweak requested. [11:20] gmb: thanks. [11:22] * gmb lunches [11:36] wgrant: hi [11:36] wgrant: Were you able to reproduce the KHTML issue on your machine? [11:36] I can't see it in Maverick. [11:36] stub: Absolutely [11:36] StevenK: I just landed that branch [11:37] stub: How did you fix the missing revisions thing? [11:37] nigelb: I haven't tested. [11:38] Oh ok. I fear I may have to download debian sid just to test. [11:38] Hrm, I wonder... [11:38] StevenK: By using lp-land properly, as it only designed to land the branch you are in (so branch your branch and run lp-propose in that directory) [11:38] I could install it into a chroot and ask it to use the right display. [11:39] stub: Right, right. The indexes on are prod live now too? [11:40] StevenK: All except the master, which is blocked until gina finishes up its current transaction [11:40] Ah === henninge is now known as henninge-lunch [11:42] stub: Which could take hours [11:42] StevenK: The statement should complete fine when it commits. [11:43] StevenK: It won't take hours, as the transaction reapers are still enabled... [11:43] Heh [11:49] jelmer: Is anything blocking your two approved import branches from landing? [11:49] import-colocated-branches and http-git-support [11:49] wgrant: they're in ec2 at the moment [11:49] jelmer: Excellent, thanks. [11:49] wgrant: There was a test failure I had to fix and having a local lp setup was blocking me from that. [11:49] (yay for lxc) [11:50] Oh, you got it working? [11:50] * nigelb is tempted to upgrade to Oneiric. [11:51] nigelb: oneiric is the reason I'm trying lxc in the first place :) [11:51] Error in test lp.codehosting.puller.tests.test_scheduler.TestPullerMasterIntegration.test_mirror_with_destination_locked_by_another [11:51] Upcoming buildbot failure. :( [11:51] jtv: I thought wgrant was the nostradamus here. :P [11:52] I actually noticed it a couple of minutes ago, and was searching through the old builds to find what leaked. [11:52] Oh, there's a whole bunch more. :( :( [11:52] But I can't find anything. [11:52] This is spurious, but it means our diagnosis was wrong. [11:52] AttributeError: 'TestPullerMasterIntegration' object has no attribute '_lock_actions' [11:52] There's more broken than we thought. [11:52] This is going to hold up the commit for Gina. [11:52] Is the lxc setup pretty well scripted or documented, or does it require a clue? [11:52] stub: It's well-documented. [11:52] stub: Works best on oneiric, but mostly works on natty. [11:53] https://dev.launchpad.net/Running/LXC [11:53] This will be Oneiric [11:53] ta [11:53] wgrant: that AttributeError doesn't strike me as particularly spurious, especially given the number of errors. [11:53] jtv: You would think. [11:53] But it is. [11:54] jtv: This is one of the types of error that's been showing up for 3 weeks now. [11:54] We'll clean leaked processes from the buildbot slave, force the build, and it will be happy again. [11:54] And then we'll abandon buildbot in favour of Jenkins, and all will be good. === salgado_ is now known as salgado [12:06] rvba: Any news re: button becoming optional ? [12:06] StevenK: The branch is in ec2. [12:06] rvba: Nice, thanks! [12:07] StevenK: https://code.launchpad.net/~rvb/launchpad/confirmationoverlay-button-optional/+merge/75154 [12:07] StevenK: I've added an example on the MP. [12:07] I mean an example usage* [12:12] rvba: Love your example :) [12:12] nigelb: ;) === henninge-lunch is now known as henninge [12:23] bigjools, rvba, StevenK, wgrant: mind a dogfood update right now? [12:24] jtv: fine by me. [12:27] jtv: Go ahead, if you haven't already. [12:27] thx [12:41] Did I break buildbot? :( [12:41] jtv: Is this the failure you predicted? [12:41] nigelb: I don't think you broke it. [12:41] You may have broken one of the pieces that you see on the floor, but… [12:42] heh [12:42] But yes, this is the failure I predicted. Now bow before your oracle! [12:42] Ah, gary_poster! [12:42] gary_poster: buildbot is being friendly again, this time without an unnoticed failure in the previous run :( [12:43] wgrant, joyful [12:43] Rather. [12:51] Is there likely to be any fallout from running bzr upgrade lp:lazr.uri?> [12:53] wgrant, did you look at it? I have other things going on, but ISTM that lp.codehosting.puller.tests.test_scheduler.TestPullerMasterIntegration.test_mirror_with_destination_locked_by_another broke, for unknown fragility reasons, and everything else fell apart afterwards because of it. I'll simply disable the test and file a bug unless you or someone else has a better idea. [12:53] gary_poster: I hope so. [12:53] gary_poster: Sounds like a good plan. [12:53] cool [12:54] Any objections to me killing staging and qastaging for a few seconds to QA my Librarian outage behaviour revision? [12:55] allenap, thinking...yes... [12:55] allenap, oh we do that with eggs [12:55] so it's probably fine, actually [12:56] gary_poster: Cool. Let the mayhem begin... [12:56] (the only thing I know of that we have to worry about with bzr upgrade scenarios is buildbot and ec2 images for stuff we get in sourcecode) [12:56] That didn't last long; I can't write. [12:56] heh [12:57] LET THE MAYHEM BEG...oh. [12:57] odd that you can't write. Lemme look [12:57] gary_poster: It's PQM managed. Didn't realise before. [12:57] ah ok allenap [12:58] hm, I didn't think we had our "extras" under PQM control [12:59] Yeah, odd. Oh well. I think I'll gently put that can of worms back on the shelf (i.e. I don't want to break PQM). [13:00] k [13:00] jkakar: hey, fwiw, I'm trying to resurrect https://code.launchpad.net/~jkakar/launchpadlib/fake-launchpad/+merge/26391 [13:12] wgrant: I wonder if I shouldn't just remove Gina's dry-run mode, if it's not even tested anyway. Far too risky. [13:12] jtv: It's not tested? [13:12] It's clearly not tested very well. [13:12] But it may be tested. [13:12] Well… an unconditional commit did not break any tests. [13:13] It doesn't somehow abort earlier? [13:13] Nope, nope, nope. [13:13] Awesome. [13:13] Insert a commit somewhere in an obscure place to reduce transaction durations, and kaboom. [13:13] May already be happening for all we know. [13:13] That's quite useful. [13:14] bigjools: your guidance wanted. [13:14] whu what? [13:15] bigjools: Gina has a dry-run mode. [13:15] It seems to run the whole script in one huge transaction, and then not commit. [13:15] Not tested. [13:16] We don't know of it works as advertised. [13:16] ok [13:16] Want me to test it (script run in test, and who knows, fixes) or remove it? [13:16] first question, do we need a dry run mode? [13:17] IOW, how does it help us? [13:17] Well since young Will here had no idea it even existed, I was wondering whether you might know the answer. [13:17] I don't I'm afraid, the Gina code has been barely touched in years, well before I started working on LP [13:18] but I can help with some probing questions [13:18] which might be slighly leading [13:18] I was nowhere near the cottage. [13:18] Not that there was a cottage! [13:18] I hereby name you Geoff [13:19] Geoff? [13:21] I fully expected bigjools to give a Yoda-ish answer. bigjools, I am disappoint. [13:21] it was too risque, so I PMed it :) [13:22] lol [13:22] Yeah, channel' logged. Good idea. [13:22] This reminds me. Is #launchpad-reviewers used at all? [13:23] *I* was of course referring to the opening episode of The Black Adder. [13:23] nigelb: no, that's obsolete. [13:23] nigelb: no it's not [13:24] Hrm, okay. [13:24] bigjools: so about these probing questions you promised..? [13:24] I noticed it in the logs. [13:24] jtv: I asked the first above, no answer yet! [13:25] Does it help us? “Not me, not William, clearly not you. Someone else out there maybe, but who would know but Julian?” [13:25] jtv: I cannot think of a use for it either [13:26] So… zap it? [13:26] yup, blow it [13:26] away [13:27] More desctruction \o/ [13:27] *destruction [13:27] Well, with the "away" added, yes. [13:27] BWAHAHA [13:28] Yippie, build fixed! [13:28] Project devel build #1,065: FIXED in 4 hr 10 min: https://lpci.wedontsleep.org/job/devel/1065/ [13:35] abentley: Hi. I'd like your help to make codehosting run locally. I'm failing to push branches locally and see them on my local instance. [13:35] I'm reading https://dev.launchpad.net/Code/HowToUseCodehostingLocally. [13:35] rvba: on the phone [13:36] abentley: Okay, please ping we when you're available then (http://paste.ubuntu.com/688322/ is what I've done). [13:36] rvba: Are you using make run_codehosting ? [13:36] I also tried to create the missing directory manually but then nothing seems to be picked up by make sync_branches. [13:37] StevenK: yes. [13:37] rvba: bzr push lp://dev/~foo/bar/baz should work with the following .ssh/config snippet: http://pastebin.ubuntu.com/688323/ [13:40] Damn, sinzui is quick. [13:40] And he's not even here. [13:40] lol [13:41] wgrant: Did he reply to your email? [13:41] https://code.launchpad.net/~wgrant/launchpad/delete-more/+merge/75179 [13:41] Neat. [13:41] Its all a hidden plot to not make you sleep :) [13:41] He reviewed it within 2 minutes :( [13:42] wgrant: there's a subtle bug in that MP [13:42] you need dedent("""\ (with the backslash) [13:43] I hate that. [13:43] yep [13:43] So I called strip() instead. [13:43] hmm [13:43] missed that [13:43] dunno which is more ugly tbh [13:43] I know. But one doesn't involve a backslash, so I tend to go with that. [13:43] it's once place where I prefer it [13:43] I don't know. [13:44] dedent sucks [13:44] Derivation is done. [13:44] Yay [13:44] Interesting... [13:44] stalker [13:45] Well, DSD creation seems to be sort of screwed. [13:45] ? [13:45] https://launchpad.net/bilimbitest/angry/+localpackagediffs [13:45] Ahh, maybe the jobs haven't run yet. [13:45] So they could all be resolved in a few minutes. [13:45] StevenK: this is what I get now :( http://paste.ubuntu.com/688331/ [13:46] In fact, they're vanishing as I watch. [13:46] Or appearing. [13:46] And I can see the connection failing in the logs of make run_codehosting [13:46] it pulls from RELEASE remember [13:46] bigjools: Ah, and DSDs look at updates too. [13:46] yes [13:47] Yeah, the ones I saw first were the same version. [13:47] But the jobrunner killed those off quickly. [13:47] Now we are settling down into sensible -updates or -security diffs. [13:47] there's an argument to pull from -security as well I guess [13:48] gmb: Got time for a ~200 liner? https://code.launchpad.net/~allenap/launchpad/series-init-failure-explanations-bug-835024-db/+merge/75183 [13:48] allenap: For you? Sure [13:48] rvba: I am about to head to bed, but you want to run that against a DB that has had make-lp-user ran across it, and then mkdir foo ; cd foo ; bzr init ; bzr push lp://dev/~rvba/+junk/foo [13:48] gmb: You're very kind :) [13:48] StevenK: that's precisely what I did. [13:48] StevenK: good night :) [13:48] Or misguided :) [13:48] rvba: Then that's terrible. [13:49] StevenK: I'll ask abentley when he is available. [13:50] rvba: I think you have a stale socket file for the codehosting forker process in /tmp [13:50] rvba: Check that you don't have a stale forking service pid in /var/tmp [13:50] yeah, socket, not pid [13:50] What he said. [13:50] * rvba checks [13:53] abentley: wgrant that was it. Branch pushed all right ... let see if make sync_branches works. [13:57] abentley: StevenK wgrant make sync_branches worked! Thanks for your help guys. [13:57] rvba: You're welcome. [13:57] rvba: Excellent. [13:58] abentley: merge-proposal-jobs blew up a bit this evening, from around 5 hours ago. [13:58] abentley: You may want to check the logs to see if it's anything new. [13:58] As I see you have yet more improvements to this area. [13:59] allenap: Am I right in thinking that the reason for this branch is that it does most of the encode/decode work for us and we're left to just use loads() and dumps() as appropriate? [13:59] wgrant: Well done driving abently away :P [13:59] Oh... [14:00] allenap: Or does the Storm JSON type avoid us having to use loads() and dumps() at all? [14:00] * gmb might be getting confused by the diff [14:00] gmb: We don't have to do the loads() or dumps() either. [14:00] Right [14:00] gmb: There's a bulk job creation bit which still needs to dumps() because it composes SQL directly. [14:00] Okay [14:01] wgrant: none of my improvements have been deployed yet. I had to roll them back when QA failed. [14:03] abentley: Ah :( that would explain the failures that I thought were fixed. [14:03] allenap: All looks sane. r=me [14:03] gmb: Thanks! [14:03] np [14:08] jml: Awesome! I've basically ditched it... but I'm happy to help if need be. [14:08] jkakar: thanks. [14:08] jkakar: actually, I do have one question about _create_resource [14:08] jkakar: it seems that if you get something back from a method, you have no good way of determining if it's a collection or an entry. [14:08] jml: Am on a call, but ask here now, I'll take a look at the code again, and answer when I'm off the phone. [14:09] jkakar: ok. thanks. [14:10] When does devel get merged into db-devel? By buildbot? [14:10] nigelb: buildbot-poller merges stable into db-devel once buildbot passes it. [14:10] so, I have to wait because of builtbot breakage. [14:10] I hate browsers [14:11] nigelb: You can't land your DB patch until we have deployed your stuff, anyway. [14:11] Argh, ok. [14:11] Need to just work on js-oopsd then. [14:16] wgrant: I call conspiracy on that ;P [14:16] Oh? [14:17] It is, I admit, rather convenient, since I want the window tomorrow for meeeee. But it's also true! [14:17] HA! [14:17] Also, I don't think I'll ever forget about grepping the whole tree next time. [14:18] bzr grep is your friend. [14:18] I've lost count of the number of times StevenK and bigjools have already told me that. === almaisan-away is now known as al-maisan [14:35] gmb: perhaps you'd like to review this one as well? Not much to see, really. https://code.launchpad.net/~jtv/launchpad/bug-848954/+merge/75188 [14:35] jtv: Sure. [14:35] nigelb: Your db patch dropping BugTask.statusexplanation had test failures. Didn't look like anything taxing but I didn't have a chance to look today. [14:36] jtv: Points for referring to wgrant as "Young Will" [14:36] heheh [14:40] jtv: Approved with one question about a somewhat opaque (to me, anyway) error message. [14:41] :) [14:41] Thanks [14:42] gmb: I suspect nobody's going to know much more about that message, so I might as well try to do something about it. Hang on. [14:42] Ok === salgado is now known as salgado-lunch [14:46] gmb: if it's any consolation, I've already asked Julian for permission to be left alone in a locked room with Gina and Katie for a while, so I can give them a stern talking to. [14:46] ... [14:46] E_NO_CORRECT_RESPONSE [14:47] jtv: I'm not hung up on the idea of that message changing before it lands, but it seems like an opportune moment. [14:48] Yeah, this is stuff that can do with any drive-by improvement. [14:48] Including the one that this branch is about: “Oh, there may be a feature there. I think I broke it. Let's destroy it.” [14:51] gmb: the diff has updated. [14:51] * gmb looks [14:51] For some reason the page won't display very legibly on my browser. [14:52] But that's probably just a bad connection. [14:52] jtv: It looks good from here. Nice change, thanks! [14:53] Thank you. [15:12] jkakar: also, I think I'm going to kill the testresources stuff [15:16] Hrm, just missed stub === bigjools is now known as bigjools-otp [15:21] jml: That was a long call... am off now. === salgado-lunch is now known as salgado [15:22] jkakar: yay [15:22] jkakar: my earlier question still stands... [15:22] jml: Uhm, if I remember correctly, the reason for not knowing whether something is a collection or not is that you can't (or couldn't, maybe you can now) tell whether something is a collection from the WSDL. [15:22] jkakar: right. so leonardr's comment about trying to return a FakeCollection from methods is ... invalid? [15:22] Maybe there's a convention that you can use to tell... or something? I rememeber it being pretty confusing (WSDL in general, in addition to the way it's used by Launchpad). [15:22] * jkakar looks again [15:24] jkakar: I'm ignoring lifeless's suggestion about including a timestamp and doing IMS. Also ignoring suggestions to move to lazr.restfulclient. [15:24] jml: I don't understand leonardr's comment/question/suggestion. [15:24] jkakar: I'm currently preparing a smaller wadl file for testing [15:24] jml: Awesome! [15:24] jkakar: and have replaced the wadl file that you included with the official 1.0 wadl file [15:24] jml: Why do you want to drop testresources support...? [15:24] jkakar: because it makes it harder to use alternate wadls [15:24] jml: Yeah, flacoste was quite keen to have it be downloaded when tests run, as I recall. [15:24] jkakar: not "drop" per se, just not export it [15:25] jml: You could pass one in, I guess... but anyway, the testresources stuff is sugar, not a big deal. [15:25] jml: I'm not very happy with a test suite that *needs* net access, but I could live with it. [15:25] jkakar: I've also added FakeEntry and FakeRoot [15:25] jkakar: I'm not making it need net access [15:26] jkakar: just bundling 1.0 and putting a suggestion in the docs that you might like to download your own to test against. [15:26] jml: Cool... I meant that in reference to the (old) request from flacoste that the WSDL be downloaded automatically. [15:26] jkakar: oh right. ugh. [15:26] jkakar: also, I've expanded the docstring to http://paste.ubuntu.com/688401/ [15:27] jml: Anyway, I'm really happy you're picking up that branch. Sorry the code is so crap... it was a bit of a discovery process, since I discovered the WSDL file as I went. [15:27] jkakar: I'm going to ignore poolie's suggestions about changing the API [15:27] jkakar: and about not doing XML parsing [15:27] jkakar: the code is fine. I still haven't discovered WSDL yet, so maybe I'm behind :) [15:28] jml: I remember being surprised that wadllib didn't actually do much with WADL files. I expected it to be an API to the WADL file, but it wasn't (maybe that's changed, it's been a long time). [15:28] jkakar: oh yeah :) [15:28] jml: WSDL is, uhm, fantastic! :) [15:29] jkakar: I think I'll leave that particular box closed for now. [15:29] jml: Cool. Great work on the docstring, thanks. [15:30] hmm [15:30] does having the docs in the wadl actually *help* the client? [15:34] Now I'm totally confused about the difference between WADL and WSDL... uhm, I think I've been using them interchangeably... [15:34] I guess we care about WADL, not WSDL, only because we have a wadllib and not a wsdllib. :) [15:48] OK. Done. [15:48] gmb: Can you please review: https://code.launchpad.net/~jml/launchpadlib/fake-launchpad/+merge/75211 [15:48] jml: Sure. [15:48] gmb: thanks. [15:48] Hi! I'd like to run this by someone for sensibility. Javascript related. [15:49] Currently, we harvest bug links and send them to an internal API for checking if they're valid/accessible. [15:49] gmb: I have to go in 10m, fwiw. [15:49] Can I add a feature to pull out bug title from that? [15:49] jml: Okay, no woirries. I'll put any questions in the mp. [15:51] deryck: Hi, around? [15:52] nigelb, hi, I am. Just about to break for lunch though. but what's up? [15:52] deryck: I saw you were marked as javascript person, so I just wanted to run something by you [15:52] " Not doing this. If you really care about it, perhaps you could do it." <-- Awesome. :) [15:53] nigelb, ok, cool. go for it. [15:54] gmb: could you please review this mp: https://code.launchpad.net/~adeuring/launchpad/cronscript-for-hwdb-report-fixes/+merge/75214 ? === beuno is now known as beuno-lunch [15:54] jml: E_5000_LINE_DIFF [15:54] deryck: I'd like to add to the javascript that checks if the linked bugs in pages are valid by updating the "title" attribute of the with the bug's title [15:55] adeuring: I shall add it to my queue; not sure I'll get to it by EOD. [15:55] gmb: most of that is boring WADL diff. [15:55] gmb: ok, np [15:55] gmb: there's instructions on the linked mp for how to get a sane diff. [15:55] jml: Ah, good, I'm just waiting for that to load... [15:55] nigelb, ok, sounds fine [15:55] * gmb wonders if it's LP or his connection that's being odd [15:55] deryck: cool! I'll file a bug and start doing it :) [15:56] cool [15:56] deryck: Thanks! [15:56] nigelb, subscribe me to the bug please [15:56] and np! [15:56] okay :) === bigjools-otp is now known as bigjools [16:04] jml: The saner diff is still 979 lines. I'm afraid I won't be able to get through all of this before EOD, and I need to be gone at 6 on the dot tonight. [16:04] You might be better off finding someone at the start of tomorrow. [16:11] compiz/unity is very unstable today. I am restarting as a last resort to get control of my windows. [16:22] Is there documenation somwhere of what's returned by IBugTask.search? [16:23] I see how to call it, parameters, etc. [16:26] matsubara, hi, I can't see OOPSes from ackee-bzrsyncd in OOPS reports (eg OOPS-2075SMS19) that's in /srv/launchpad.net-logs/scripts/ackee-bzrsyncd/branch-scanner/2011-09-06 on devpad; are these directories perhaps ignored? [16:27] danilos, let me take a look [16:27] matsubara, thanks [16:31] sinzui, hi, do you think you'd have a minute to chat about bug 480123? basically, while it sounds the solution is "simple", I am sure we need to worry about what's going to break, and you probably have a few other ideas of what's to look out for? [16:31] <_mup_> Bug #480123: Milestone names/version should be unique to series < https://launchpad.net/bugs/480123 > [16:32] it is not simple [16:32] We tried to fix that in 2009 and failed,. we reverted the schema changes after 2 months on no progress === deryck is now known as deryck[lunch] [16:34] danilos, mumble, skype? [16:35] sinzui, skype works better for me, "danilo.segan" [16:36] adeuring: Approved, but you need to change the "# Disabled because of bug ..." comments to XXXs for clarity. [16:36] gmb: ah, right! thanks! [16:38] np [16:51] abentley, hi, we have an escalated bug which is a (non-DB) timeout in "ScanBranch" jobs, could you perhaps look at bug 808930 and comment if you have any ideas of where one would start (i.e. could we somehow look into speeding these operations up for gcc-linaro project, checking if they are using stacked repos and whatever gives us the best performance) [16:51] <_mup_> Bug #808930: Timeout running branch scanner job < https://launchpad.net/bugs/808930 > [17:06] danilos: I think the way to close this bug is to optimize bzr. [17:07] danilos: I would start by downloading the branch locally and profiling the script. [17:08] abentley, right, thanks for the input [17:10] danilos: it is already using the fastest bzrlib operations I know of. I wrote the script, and I also wrote the Graph operations, several years before that. [17:11] danilos: it's possible the algorithm could be improved. it's also possible that we have to switch to C or Pyrex to get that performance. [17:12] danilos: Or we may need to implement a greatest-distance-from-origin cache in order to get good performance. [17:12] danilos: jam has also done a lot of work in this area, and may have advice. [17:14] hi, can someone tell me what caching may be involved in producing/serving +temp-meeting-export? [17:14] hitting that URL repeatedly gives back results of varying staleness [17:14] I was just about to ask :) [17:14] :-) [17:15] abentley, right, at the moment I was just looking for some more info other than "this is slow"; I hope you don't mind me pasting your input on the bug? [17:16] danilos: feel free. === beuno-lunch is now known as beuno [17:21] abentley, thanks again [17:21] danilos: np [17:24] danilos, lp:~edwin-grubbs/launchpad/bug-174468-milestone-release-overlap should contain chunk of code it its history that made milestones unique to the series. I do not see that in the history though. The branch lived for many weeks and it is very confusing. [17:26] danilos, I can see from my discussion that changes to uniqueness will has a few themes of work: product-release-finder, project groups and ProjectMilestone, sorting milestones (wants debversion) [17:27] sinzui, right, thanks, I'll add that to my notes [17:30] sinzui, the DB patch in r7278 does change the unique constraint, fwiw === deryck[lunch] is now known as deryck [17:38] james_w, hi, do you think you'd have a few mins to talk about what you need out of bug 480123? [17:38] <_mup_> Bug #480123: Milestone names/version should be unique to series < https://launchpad.net/bugs/480123 > [17:38] danilos, hi, yes [17:38] but not now [17:38] sorry [17:38] I need to get some food [17:39] danilos, I'll forward you what I sent to flacoste, and then you can let me know if it's sufficient [17:39] james_w, ok, I am not going to be around for much longer today, so we can perhaps talk tomorrow [17:39] james_w, excellent, that's even better [17:40] danilos, sent [17:40] I'll be happy to talk if it's not clear from that [17:42] james_w, cool, thanks, this should give me a better idea of what you need, I'll have to wrap my head around it first :) [17:48] deryck: Hey, could you give me a quick hand with BugTask.search? How do I find out what it returns? [17:50] nigelb, I believe it returns a result set of bugtasks. Let me look to confirm.... [17:50] nigelb, how I'm checking is to go to the method in lp.bugs.model.bugtasks [17:50] I'm there as well :) [17:50] I'm looking at _search() [17:50] since that's what seems to be called. [17:50] I think storm is what's confusing me there. [17:51] nigelb, yeah, you're in the right place. and see the comment about what it returns. [17:52] hrm, yes === al-maisan is now known as almaisan-away === matsubara is now known as matsubara-lunch [18:41] gmb: I suspect you're no longer OCR. [18:42] abentley: You suspect correctly. I shall remedy this falsehood presently. === gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 263 - 0:[########*** stack smashing detected ***: ./lp terminated [18:43] deryck: Since there's no OCR, could you review https://code.launchpad.net/~abentley/launchpad/daily-build-disabled-archive/+merge/75239 ? [18:44] abentley, sure [18:47] abentley, r=me. nice, succinct, and good change. [18:47] deryck: thanks. [18:47] abentley, np === almaisan-away is now known as al-maisan === lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 263 - 0:[########*** stack smashing detected ***: ./lp terminated === matsubara-lunch is now known as matsubara [19:44] I thought you were supposed to be away. [19:58] deryck: Still around? [19:58] I er have an implementation confusion [20:05] nigelb, I am. just tending to a few things, but ask away. I'll answer as I can. [20:21] Hrm. I may have sorted this. Verifying. [20:22] Hrm. No. [20:22] Currently, we post all the branch URLs and all the bug urls to +check-links [20:22] This returns a JSON with invalid_branch_links and invalid_bug_links [20:23] I'll how to now modify how this works a bit more non-trivially than I thought. === al-maisan is now known as almaisan-away [20:55] is there a way to be subscribed to all bugs related to a product, but exclude selected tags. Example I want to free myself of all the apport bugs [20:55] they have the tag "apport-crash" [20:55] instead of +, use - I think. [20:56] in lazr.restful, is there a way to export a parameter, not an operation, as another name? [20:56] nigelb: where? [20:57] m4n1sh: URL [20:57] m4n1sh: what project is this? [20:57] nigelb: for this https://bugs.launchpad.net/ubuntu/+source/zeitgeist [20:57] want to make myself free of apport-crash bugs [20:58] hundreds of them are filed in a week [20:58] duplicates [20:58] due to zeitgeist being installed by default [20:58] m4n1sh: https://bugs.launchpad.net/ubuntu/+source/zeitgeist/+bugs?field.tag=-apport-crash [20:58] yes then? [20:59] that is just for filtering [20:59] but for subscription [20:59] AH. [20:59] looks like there is no such right now [20:59] need to file a bug - to be marked as wishlist [20:59] btw against which package should I file? === almaisan-away is now known as al-maisan [20:59] sure there is [20:59] I wonder if you can do -apport-crash in the subscription. [21:00] launchpad-foundations [21:00] use an advanced subscription [21:00] lifeless: used that [21:00] that is "include tags" [21:00] lifeless: I want all minus specific tags [21:00] ah, then perhaps file a bug yes. [21:00] against which module? [21:00] bugs.launchpad.net/launchpad [21:00] ah. I thought foundations [21:00] I don't think there are modules anymore. [21:00] I mean like lazr.restful [21:01] launchpad-foundations [21:01] etc etc [21:01] lifeless: Could you quickly review what I'm doing for the bug autolinkifying? [21:02] m4n1sh: lazr.restful is a piece of code, launchpad-foundations was a sub-team of the launchpad team, but it no longer exists post restructure [21:02] so right now how many pieces are there? [21:02] only launchpad? [21:02] m4n1sh: in what sense? [21:03] like lazr.restful, launchpad etc etc [21:03] organisationally or bits of software? [21:03] lazr.restful is not launchpad only. [21:03] things like malone, blueprints, are all launchpad. [21:03] bits of software on which launchpad is dependent on [21:03] m4n1sh: several hundred [21:03] which are part of launchpad, but developed as seperate project [21:03] m4n1sh: about 50 of which we are the primary developers of [21:04] I think I added one to that list :P [21:04] launchpadlib also comes under launchpad.net/launchpad ? [21:04] https://launchpad.net/launchpad-project [21:05] m4n1sh: no, only the launchpad source code is managed at /launchpad. Components etc all have their own bugtrackers. malone and so forth are not (currently) components, they are just part of the launchpad source code [21:05] Yep. JS OOPS Daemon. [21:05] ah yes [21:05] that is what I was asking [21:05] like loggerhead is developed seperate [21:05] lazr.restful [21:05] lazr.enum [21:06] wadllib etc [21:09] done [21:09] https://bugs.launchpad.net/launchpad/+bug/849429 [21:09] <_mup_> Bug #849429: Subscription: Allow the option of selectively blacklisting certain bug tags. In short add tag blacklisting < https://launchpad.net/bugs/849429 > [21:20] gmb: thanks anyway [21:21] I think I just murdered some javascript. Gah. [21:22] nigelb: as they say in Texas: it needed murdering [21:22] haha [21:23] I took some perfectly generic javascript and made it specific. [21:23] Just realized I can make it generic with my changes as well. So fixing that. [21:24] How evil am I? [21:24] We went from http://paste.ubuntu.com/688640 to http://paste.ubuntu.com/688639 [21:25] With changes in Javascript to deal with that. [21:48] bac: you got my unprompted review :-) [21:48] flacoste: great, thanks [21:49] Now I understand why debugging launchpad js is nightmare. [21:50] bac: well, you might not thank me after you read it :-) [21:50] flacoste: i'd read it. i was just being nice. [21:50] :) [21:51] bac: do these comments make sense? i might be dreaming [21:51] * flacoste does reality cehck === matsubara is now known as matsubara-afk [21:51] flacoste: i think so. i'll have to look at the db procedure that updates the date_last_message. shouldn't be a problem [21:52] flacoste: i'd assumed (incorrrectly) that the triggers for that were sensible and what we wanted... [21:53] bac: ok, thanks for working on that btw [21:53] flacoste: np. i'm off tomorrow but will wrap it up thursday [22:08] Anyone around for some evil javascript review? I don't need a full review, but just help on whether it looks okay. === salgado is now known as salgado-afk [22:16] flacoste: Do you have a quick few minutes? [22:31] I guess not. I'll grab some other javascript-y person tomorrow. [22:32] benji: re semver: you might also like reading the libtool soname rules [22:33] sounds like my kind of reading material [22:34] benji: Hey, could check something for evilness? :) [22:35] nigelb: if it's pretty quick, I have two chilli-cheese-onion-dogs with my name on them [22:35] benji: http://www.gnu.org/s/libtool/manual/html_node/Updating-version-info.html [22:36] "try to set the interface numbers so that they correspond to the release number of your package. This is an abuse that only fosters misunderstanding of the purpose of library versions." [22:36] benji: https://code.launchpad.net/~nigelbabu/launchpad/bug-title-849121/+merge/75267 [22:36] You don't need to actually do a full review [22:36] bah, 'Never ...' [22:36] thanks lifeless, I've put that in a tab in my reading-for-after-the-kids-are-in-bed window [22:37] benji: Its a WIP. There's some code to be deleted in that. And *lots* of tests to be fixed. And javascript needs testing. [22:37] But I need help with the sanity of my approach :) [22:39] nigelb: it looks good to me, the only questionable thing is hand-building the bug links (line 35 of the diff), there is a mechanism to build those links for you [22:39] benji: I don't think so. I can't use canonical_url for that. [22:40] nigelb: may be, it's not a big sin (but I worry about the day we want to change our URL structure and all of these one-off URL generation sites have to be changed) [22:40] I really have to go now. Later. [22:40] benji: Thanks! [22:41] I shall make it better over the week :) [22:41] Javascript - 0; Nigel - 1. [22:46] nigelb: is what you are doing going to make bug titles reappear when i mouse over "bug 1234" in text? [22:46] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts < https://launchpad.net/bugs/1234 > [22:47] mwhudson: Yes [22:47] nigelb: hooray [22:48] heh [22:48] nigelb: are you coming to orlando so i can buy you a beer? [22:48] No, I'm not :) [22:48] ah well, i'm sure i'll get the chance eventually [22:48] But I'll try to come for the next european one :) [22:50] mwhudson: I took the generic XHR updating framework and extended it to deal with valid and invalid. [22:50] * nigelb dreads broken tests === al-maisan is now known as almaisan-away