[00:00] Right [00:00] so no builds is a subset of no builds in the last 24 hours [00:00] mvoe the date constraint into th ejoin [00:00] as a > $earliest_build_date_we_would_consider [00:02] either http://pastebin.ubuntu.com/560426/ or [00:02] http://pastebin.ubuntu.com/560428/ [00:02] I think 50426 will work though; use that if possible - write tests to be sure [00:03] I think I have enough test cases [00:03] ok [00:04] * StevenK waits for druzhnaya to actually talk to him [00:05] lifeless: So with 560426, I should put an And() inside the LeftJoin? [00:06] Huh. [00:06] https://lpstats.canonical.com/graphs/PrivateArchiveTokens/20100201/20110201/ [00:06] What happened at the end of November? [00:08] lifeless: with your comment on Bug #435779 about changing staging to qastaging it can be done, but will it mean changing the push lines to bzr push lp://qastaging/~your-id/branch-name etc? I'm just looking at the sandbox "What's this?" dialogue: https://launchpad.dev/+help/home-page-staging-help.html [00:08] wgrant: SC, at a guess [00:08] StevenK: That was my thought, but I would have expected that a month or so earlier. [00:08] Perhaps apps only started really appearing in November. [00:09] huwshimi, lifeless: Also, qastaging updates should be fixed before we recommend it. [00:09] wgrant: I can think of someone you can ask. :-) [00:10] lifeless: Storm seems to eat my brackets :-( [00:12] huwshimi: yes [00:12] wgrant: perfect enemy of good [00:12] wgrant: thats really not a must do to suggest it rather than staging [00:13] StevenK: yes, and AND [00:13] lifeless: Great thanks for that [00:13] StevenK: what brackets is it eating [00:13] lifeless: It's awkward to try things on qastaging when your project probably isn't there. [00:14] wgrant: that applies equally for new projects to both staging & qastaging [00:14] wgrant: its also straight forward to fix [00:15] lifeless: http://pastebin.ubuntu.com/560435/ [00:15] StevenK: should be fine [00:15] StevenK: unless pg is bitching? [00:15] Except it doesn't work :-) [00:16] in what way [00:18] lifeless: My test case is create a recipe, then create two builds for the recipe, one created 24 hours ago, and then other 8, and then call makeDailyBuilds(), which should return [] [00:19] ... [00:21] StevenK: (and what is it returning) [00:21] StevenK: I'm not doing anything else while I help you [00:21] lifeless: Oh. It returns a new build [00:22] which of the two [00:22] Neither of them, a new one [00:22] huwshimi: hi [00:22] StevenK: sounds like you need more visibility into what its doing/seeing [00:22] thumper: Hey there [00:22] huwshimi: do you know where we are supposed to make CSS edits? [00:23] huwshimi: I'm wanting to make the yui3-ieditor-error not be 0.5em [00:23] can't read the freaking error :( [00:23] * thumper is supping on a lovely quad-shot flat white in a cafe [00:23] lovely [00:23] thumper: most of the css is in one of two files. I'll just grab you the location [00:23] huwshimi: ta [00:24] thumper: Are you adding something new or modifying something? [00:24] huwshimi: I think it is new as I can't find a style locally for it [00:24] huwshimi: does come from combo.css [00:24] whereever that is [00:25] yui? [00:25] I tried some css.in file... but it didn't end up showing [00:25] james_w: yeah [00:26] StevenK: also, do you need to restrict by archive? [00:26] lifeless: makeDailyBuilds() decides what to do based on the query, if the query returns a recipe when it shouldn't, it will create a build for it [00:27] thumper: I'm not sure of the best way to do it when it's dealing with the YUI stuff. [00:27] StevenK: I get that, but to figure out whats wrong we need more info. 'Transparency' [00:27] huwshimi: so what is the best way? [00:27] thumper: that .in file is the main one, but there are separate files that specifically deal with yui stuff [00:27] StevenK: e.g. perhaps log 'creating new build for recipe %s with prior build %s on %s' [00:28] huwshimi: do I need a special make target to make our css? [00:28] thumper: but they are in the lazr-js build directories and I'm not sure if we can touch them [00:28] lifeless: Sorry about the wrapping: http://pastebin.ubuntu.com/560436/ [00:28] huwshimi: I'm sure I can sort something out :) [00:29] for example there is this file: lazr-js/build/inlineedit/assets/skins/sam/editor-skin.css [00:29] thumper: ^ [00:29] lifeless: It's the earlier query where we moved date_created into the JOIN. I'd expect that to return zero rows, not two [00:30] thumper: which references .yui3-ieditor-errors [00:31] huwshimi: yes it does, and it says 0.5em [00:31] grr!!! [00:31] thumper: but if you change that file I'm not sure if it will get overwritten at some point if there is a lazr-js update [00:31] thumper: I don't really know how the lazr stuff works [00:31] * thumper thinks.... [00:31] StevenK: its returning 2 rows because you've unique data in the select clause [00:31] haha [00:32] huwshimi: the reason it is 0.5em is for the title errors [00:32] huwshimi: if you are editing an h1, then 0.5em is fine [00:32] huwshimi: but editing a multiline box where the text is 12pt [00:32] huwshimi: 0.5em sucks arse [00:32] lifeless: So removing BuildFarmJob.date_created, I still get one row [00:32] thumper: Ah right, yeah that would [00:33] huwshimi: seems like a general fail all round [00:34] huwshimi: where there is an implicit assumption on the text size [00:34] StevenK: add a constraint that date_created is NULL to the where [00:35] huwshimi: And now you know why text sizing is so difficult with em or % [00:35] * huwshimi is talking to myself [00:35] thumper: And now you know why text sizing is so difficult with em or % [00:36] huwshimi: yup [00:36] w00t [00:36] my widget refactoring branch just passed ec2 test [00:36] and is being landed \o/ [00:39] thumper: so you could add a specific rule for the situations where the font size will be too small [00:40] huwshimi: yeah, I'll be looking at something like that [00:40] huwshimi: I have a cunning plan [00:41] lifeless: Adding BuildFarmJob.date_created == None still has the test failing [00:41] hmm.... [00:42] * thumper bets that webservice_error values aren't inherited [00:42] StevenK: sigh, grumble. (Not at you) [00:42] StevenK: gimme a sec [00:43] thumper: I don't like the sound of this... often when I hear cunning plan it equals "dodgy hack" [00:43] huwshimi: trust me grasshopper :) [00:44] thumper: haha [00:45] huwshimi: what turns our css.in file into a real css file? [00:46] thumper: we have a build script. It will get built every time you run 'make run' or you can rebuild it while the dev server is running by using 'make css_combine' [00:46] huwshimi: ta [00:47] * thumper didn't even need to add a new css class [00:49] * thumper stabs the code in the face [00:49] my css fix worked [00:49] StevenK: ok [00:49] but not my webservice error annotation to existing exceptions [00:49] StevenK: I'm all yours, lets look harder [00:49] thumper: I don't think I even want to know what you just did [00:50] huwshimi: not rocket science: .lazr-multiline-edit .yui3-ieditor-errors { font-size: 100%; } [00:51] thumper: Ah ok that looks ok [00:51] lifeless: I have the test logging, but it doesn't help much, since it's query [00:52] huwshimi: although editing the programming languages of a project when there is an error will render unreadable error text [00:52] huwshimi: as it is a text line editor [00:52] huwshimi: however it does this now [00:52] so it isn't new [00:52] just still shit [00:53] StevenK: ok, so, we have 0 > N rows in bfj [00:53] Right [00:54] if we constrain(in the join) any of the relations such that no rows are emitted, the left join means that the spr will be returned [00:54] this applied to each left join expansion [00:55] Hm [00:56] lifeless: This is fine, for the no-builds case [01:01] ok [01:01] we *do* need the right join [01:01] because [01:01] oh FFS [01:01] we want to treat those three tables as inner joins [01:02] this works perfectly for me [01:02] and takes 6ms [01:02] lifeless: Can haz query you used? [01:02] just pasting [01:02] http://pastebin.com/5x6vkZx5 [01:03] on qsstaging, which has an updatish awn-testing recipe, it excludes it, and includes it when I drop the date back a day [01:04] the brackets in the join don't matter [01:04] I just had them in from before [01:05] lifeless: So expanding this out to the code: This means that BFJ and PackageBuild change from LeftJoin to Join and the other LeftJoin turns into a RightJoin? [01:05] yes [01:06] and that you need the right join as the outer one [01:06] RightJoin(Join(Join ? [01:06] StevenK: yes, I think so [01:07] * StevenK tries it [01:07] wgrant: btw, you need to be more paranoid about what users do [01:07] wgrant: I refer to bug 498642 [01:08] lifeless: Uh, I tried it. [01:08] Which page? [01:08] wgrant: put one space, or carriage return in the description [01:09] wgrant: I used bugs.qastaging.launchpad.net/launchpad/+filebug [01:09] Ahh, different bug. [01:09] lifeless: Crumbs, I think that worked. [01:09] wgrant: hmm? [01:09] lifeless: 498642 and two others that I just closed were filed when any error on the bug form caused an OOPS. [01:10] Having a whitespace-only body is a different thing. [01:10] wgrant: given that I filed 498642, I beg to differ [01:10] I know, but your description doesn't say that :) [01:10] wgrant: anyhow, I've reopened it for you [01:10] and linked in an oops [01:11] I will clarify the description. [01:11] However, given the timing, I'm pretty sure this is not the issue you initially reported. [01:11] We cannot log you on at the moment due to very high levels of usage [01:11] Please try again later [01:11] StevenK: ? [01:11] Dear NAB, you faiol [01:11] *fail [01:11] hah, eep [01:12] lifeless: So I think the query works for the 'we have builds' case, but not the 'no builds' case. [01:13] StevenK: show me the query being generated ? [01:13] oh the order_by is totally unneeded, I was using that for my edification [01:13] lifeless: I figured, which is why I ignored it [01:14] lifeless: http://pastebin.ubuntu.com/560449/ [01:15] lifeless: I think it's putting the right join in the wrong place [01:15] indeed [01:15] paste the python [01:15] http://pastebin.ubuntu.com/560450/ [01:15] * thumper is getting there... [01:16] lifeless: I was going to try Join(Join(RightJoin( [01:16] StevenK: you've got the wrong table in the joins [01:16] I do? [01:17] yes [01:17] you're inner joining spr and sprb [01:17] you want to right outer join spr and the other composite table [01:17] I'm just rearranging, one sec [01:18] http://pastebin.ubuntu.com/560451/ [01:18] my indenting is still whack, I just did enough to see what was binding to what [01:20] I think mine is worse, but let's see [01:22] lifeless: So I think I get why my code was wrong -- the right join was for *both* BFJ and PackageBuild together, right? [01:22] StevenK: a join joins two 'tables' together [01:23] StevenK: your code was wrong because it inner joined SPR and SPRB togehter. [01:23] StevenK: when what we want is an outer join on SPR + [all the rest] [01:24] I don't know if that makes sense to you [01:24] lifeless: Now we get http://pastebin.ubuntu.com/560452/ [01:25] lifeless: If that query looks sane, I'll throw it at the rest of the tests [01:25] StevenK: that looks sane [01:26] * StevenK bursts into flames to cool down [01:28] lifeless: That looks like all tests pass, \o/ [01:28] excellent [01:29] lifeless: Do you have a moment to EXPLAIN ANALYZE the top query on https://lp-oops.canonical.com/oops.py/?oopsid=1839G1380? [01:29] It upsets dogfood greatly; I hope qastaging may survive better. [01:30] * thumper sighs [01:30] time to relocate home [01:31] why the sigh? [01:32] Argh, it's getting hotter [01:32] Tomorrow is going to be worse :-( [01:32] wgrant: iz terribad [01:32] what temp is it? [01:33] lifeless: Clearly. [01:33] wgrant: jtv has suggested that a union of public + private will perform better [01:33] wallyworld: Currently, 33degC, feels like 37 [01:33] wgrant: (because they are typically lopsided) [01:33] lifeless: I've suspected that, yes. [01:33] yeah, it's humid here too. days like this i miss working in an office :-( [01:33] stub: hey [01:34] lifeless: Ah, it finished on DF... in slightly under 5 minutes. [01:34] stub: are you back on deck ? [01:34] lifeless: yo. back on deck. [01:34] cool [01:34] wgrant: That's better than the last query you got me to run on DF [01:34] I have a crazy idea I'd like to run past you [01:34] StevenK: Shh. [01:35] is it possible to use a plpython(or plsql) function to index on fields in other tables ? [01:35] wgrant: Is it hot down there today too? [01:35] If so, it would fix just about everything :) [01:36] StevenK: Only meant to be 34 today. [01:36] So, not really. [01:36] Hotter than here [01:36] Ah, it was around 40 yesterday. [01:36] wgrant: so, 200 seconds cold [01:36] 4.2 seconds hot [01:36] lifeless: 6s on DF, yeah [01:36] lifeless: Yes, but it is ugly and the indexes might lie (because you have to declare the function as stable rather than volatile, and thus the function definition is a lie too) [01:37] lifeless: A joining table might be more appropriate, either denormalizing or moving the columns if they are only used in tandem. [01:38] stub: would they like for reasons other than the referenced data changing ? [01:38] stub: so the specific case I'm thinking of is the one I discussed in last tuesdays perf tuesday mail [01:38] I also have a very similar case, which makes the publisher slow. [01:39] lifeless: Only when the referenced data changes (inserts, deletes, updates depending on what you are indexing). [01:39] lifeless: It will make inserts slow too of course. [01:40] stub: so, perhaps you could have a look at the case I analysed, see the mistakes I made ;). I'm curious what you mean by 'joining table' [01:40] stub: is a cross-table function better or worse than denormalisation [01:40] or is it case-by-case evil ? [01:42] cross table function can surprise you and shoot you in the foot. If your source data changes (maybe it is stable now, but can you promise about tomorrow?), then you start returning incorrect results. Denormalization is explicit and obvious, can be maintained with triggers, but makes tables wider so more storage and slower to query. [01:43] stub: yeah, thats about what I thought [01:43] stub: the particular case I'm thinking of the fields being referenced are immutable [01:44] lifeless: There was also a bug where index lookups on a function index where still calling the underlying function, so the approach was useless. Hopefully this has been fixed in 8.4 (I last checked around 8.1 or 8.2 I think) [01:44] stub: whee; thats not the case here, but we'd want to test to be sure I think. [01:47] wgrant: analyzing now [01:48] lifeless: Analyzing what? [01:48] http://pastebin.com/rx1F4KRE [01:48] you wanted an explain analyze [01:48] Oh, right, yes. [01:48] Thanks. [01:52] wgrant: moving product from prejoin to separate all-product query would help too I think [01:53] lifeless: In this case it's all NULL, but yes, it would probably help a little. [01:53] wgrant: it will reduce appserver time [01:53] lifeless: Did you want to actually review https://code.launchpad.net/~stevenk/launchpad/queue-recipes-better/+merge/47358 or shall I add the usual suspects? [01:56] wgrant: 1/2's the query time [01:56] Time: 2318.619 ms [01:56] wgrant: if I remove the product and spn relations [01:57] Huh. [01:57] wgrant: http://pastebin.com/he1NJvxx [01:58] Now that Open Office has forked, should we be putting resources into supporting their unique translations format, or should we be putting resources into moving Libre Office to a standard translations format? [01:58] heh [01:59] * thumper goes to work out how to install libre office [01:59] I'd make sure there is a bug upstream [01:59] but AIUI we have an importer from their format already, don't we? [02:02] IIRC we do one of mozilla and open office. I think open office. [02:02] We definitely do Mozilla. [02:02] That's the XPI stuff. [02:06] === Top 10 Time Out Counts by Page ID === [02:06] Hard / Soft Page ID [02:06] 365 / 8767 Archive:+index [02:07] 14 / 239 POFile:+translate [02:07] 14 / 4 Cve:+index [02:07] 13 / 305 Distribution:+bugtarget-portlet-bugfilters-stats [02:07] 13 / 24 NullBugTask:+index [02:07] 12 / 12 BugTask:+editstatus-page [02:07] 9 / 30 Distribution:EntryResource:searchTasks [02:07] bah freenode [02:07] hates [02:07] I bet that got filtered [02:10] * StevenK prods lifeless so he can go to lunch [02:10] StevenK: oh, sorry [02:11] StevenK: so [02:11] StevenK: there is a daily build archive [02:11] StevenK: but we're not filtering the builds against that. Does that matter? [02:11] StevenK: e.g. if I manually build a recipe into some other ppa/suite/whatever; does that invalidate the results we're getting? [02:12] If it's the same recipe, it will, but I don't think that's a bad thing [02:13] We need to restrict the search to the daily build archive. [02:13] StevenK: why would it be a good thing? [02:14] lifeless: Some sets up a daily build, and requests a build manually. The system then shouldn't request another build for that recipe for another 24 hours. [02:14] StevenK: if they do a test build into a different place, why ? [02:14] StevenK: I get it if they build into the same archive [02:14] Right, I get it [02:14] grr!!! [02:15] thumper: What are you trying to break? [02:15] Yeah, we can pull Archive into it [02:15] why can't we have our javascript not crippled [02:15] Heh. [02:15] StevenK: so, this can be a different patch; could you file a bug though so we don't forget ? [02:15] * thumper needs to debug some javascript [02:16] which firebug is normally pretty good at [02:16] actually [02:16] wgrant: care to review this; I will mentor your review [02:16] StevenK: go to lunch [02:16] lifeless: But finish reporting the bug first? :-) [02:17] StevenK: yes [02:17] lifeless: Looking. [02:19] lifeless: bug 710435 [02:19] I never get good numbers [02:19] anyone know how to non-compress our javascript? [02:28] thumper: deryck recently (probably less than a month ago) adjusted devmode to minify everything into a single file, since YUI otherwise wanted to request 500 JS files. [02:29] Tracking down that rev might give you a hint. [02:29] * thumper grunts [02:29] wgrant: I've emailed the list with the real problem [02:29] wgrant: and that is how to debug javascript [02:30] StevenK: when triaging you need to set status as well as importance ;) [02:32] StevenK, lifeless: Reviewed. [02:33] wgrant: Bah, lifeless agreed that could be done later, as long as filed a bug [02:33] I disagree :) [02:33] Also, I don't think the series issue was brought up. [02:33] But I wasn't really following your conversation. [02:34] wgrant: thumper and I spoke about this multiple times at the Thunderdome -- if they add another distroseries to an existing recipe, they can either wait or request a manual build -- I don't think it is going to happen very often [02:35] StevenK: I request a test build for Natty to the usual archive. [02:35] The other series are then skipped the next day, despite being stale. [02:36] * wgrant lunches. [02:37] Anyone available to review this: https://code.launchpad.net/~huwshimi/launchpad/get-started-text-435779/+merge/47958 (for #435779). [02:37] wgrant: The query in question only finds recipes that should be built -- it doesn't care about series. [02:37] * StevenK also lunches, finally === stub1 is now known as stub [03:08] StevenK: Sure, but it needs to check that all the series have been built. [03:09] StevenK: Or a build for a single series will cause no builds to be created for *any* series. [03:09] mwhudson: Did you get anywhere with that codebrowse auth issue? [03:10] lifeless: They're not already present in the tree. [03:10] wgrant: no [03:10] lifeless: We don't unset staleness except in the case of daily builds. [03:10] wgrant: didn't really try beyond what i said in the report [03:10] mwhudson: Ah :( [03:10] I guess I will try to reproduce it locally. [03:12] that would be great [03:13] c-i-p funtimes, yay. [03:16] * thumper has found a way [03:17] wgrant: Within 24 hours, yes [03:17] WTF :/ [03:17] WTF [03:17] c-i-p is just getting more impossible. [03:18] It now wants to talk to a 10.x.x.x host. [03:18] StevenK: Yes, but it's still a regression. [03:19] wgrant: I think it's one we can live with [03:19] Why? [03:19] Random people requesting builds of my recipe should not affect my builds of my recipe. [03:19] Random people can't write to your archive [03:20] Ah, if you do add the archive restriction, sure. [03:20] Then it's not quite so bad. [03:20] wgrant: I'll fix the lint, I think the join is more readable [03:21] StevenK: Were you able to avoid the RightJoin? [03:21] I'll look at the archive and Archive.default_component [03:21] wgrant: c-i-p ? [03:21] thumper: canonical-identity-provider [03:21] ha [03:21] ah [03:21] wgrant: lifeless and I have rewritten that query about 3 times [03:21] StevenK: Can't you just reverse the order and use a LeftJoin? [03:22] Oh good. [03:22] And the dev config files are private to ISD. [03:22] wgrant: But why are you trying to avoid RightJoin? [03:23] StevenK: Consistency, mainly. [03:23] Nowhere else in the tree uses it. [03:26] wgrant: I'm tempted to leave it, since lifeless and I have spent a while crafting it [03:29] wgrant: In terms of adding archive, I'm worried the tests are naive [03:29] And don't set daily_build_archive [03:30] Is this a concern? [03:31] wgrant: It could be [03:31] wgrant: Is http://pastebin.ubuntu.com/560480/ more to your tastes? [03:32] StevenK: Unity doesn't want me to see that. [03:32] But yes, that looks OK. [03:32] Haha [03:32] As for the RightJoin, the tests pass if I s/Right/Left and invert the first two arguments. [03:33] All of them? [03:33] test_sourcepackagerecipebuild [03:33] Drop the build [03:34] There's one or two pertinent tests in spr [03:35] + pip install -r ./requirements.txt -f 'https://launchpad.net/lazr.restful/+download?start=21' -f 'https://launchpad.net/lazr.restfulclient/+download?start=9' [03:35] wgrant? [03:36] StevenK: SSO's installation script seems to hardcode batch numbers. [03:37] Whee [03:38] StevenK: Lots of the SPRecipe tests fail because lazr.restful hates Natty, but all the relevant ones look good. [03:39] wgrant: See lifeless' comment on the MP, though [03:39] StevenK: http://pastebin.ubuntu.com/560481/ [03:39] Ah, hm. [03:40] I don't particularly buy that rationale. But perhaps I misunderstand. [03:41] You don't think information for a build is split between BFJ, PackageBuild, and SPRecipeBuild? [03:41] I do. [03:42] Still can't bring myself to say SPRB [03:42] But I have never seen a case where a right outer join is justified. Unless I seriously misunderstand what it is, it can be trivially replaced with a left outer join. [03:42] 'we can't left join with it because the condition for restricting interesting builds is to the right of one of the partitions' makes very little sense. [03:45] * thumper stabs CSS in the face [03:46] thumper: In a good way? [03:46] huwshimi: I'm finding lots of CSS stuff ups [03:47] huwshimi: go into any bug on qastaging [03:47] huwshimi: and delete the description [03:47] huwshimi: and try to save [03:47] huwshimi: I've worked out how to fix the "always loading" issue [03:47] huwshimi: but the error styling messes up how it looks "a lot" [03:48] huwshimi: for any multi-line editor, the tab gets an off by one error when you edit [03:48] huwshimi: the curved line gets an extra pixel [03:48] huwshimi: the edit box is one pixel too wide [03:48] (those are two different off by one errors) [03:49] huwshimi: and I told you about the off by one pixel issue on mouse over [03:49] thumper: ouch [03:49] thumper: oh, now I see what you mean by the error text too [03:49] the "always saving" issue is a lazr-js problem [03:49] I'll be submitting a fix for that soonish [03:50] but the styling is really annoying [03:50] * thumper fires up a lazr-js branch to mess around in [03:50] thumper: Might add that hover stuff to my queue for this afternoon [03:50] huwshimi: it may well be in lazr-js [03:51] huwshimi: let me look, since I'm there anyway [03:51] thumper: ok sure. [04:07] huwshimi: Yay for eliminating facet colours. [04:07] Although it does sort of invalidate our logo. [04:09] wgrant: Haha. We MUST keep all the colours, the logo says so. Whatever will we do!? [04:09] Exactly! [04:13] Hm [04:14] wgrant: Just don't mention that logo thing to anyone else alright! :P [04:15] I liked the facet colours [04:15] :( [04:15] what's changed? [04:16] huwshimi: I've fixed two 1px problems [04:16] now looking at the error one [04:19] thumper: Awesome. Nice work. [04:32] wgrant: Attempting to add packagebuild.archive == sprecipe.daily_build_archive isn't working. :-/ [04:34] StevenK: Oh? [04:34] What does it do? [04:34] And where are you putting it? [04:35] In the join of PackageBuild [04:36] Hmm [04:36] And it doesn't like it since SPRecipe isn't in the mix yet [04:41] wgrant: that aren't ? [04:42] lifeless: Pardon? [04:42] bah [04:42] wgrant: what defects are not already intree ? [04:42] * StevenK kicks AWS and attempts to extract an invoice from its website [04:42] wgrant: also right join is fine, left join would be wrong [04:43] lifeless: The ones I mentioned in the bug: creating a build for any series in any archive will prevent daily builds from being created. [04:43] This is not the case at the moment. [04:43] lifeless: So you keep saying, but I do not see why. [04:43] Could you explain? [04:43] wgrant: I don't see how it can be the case at the moment [04:43] lifeless: Now you have me confused. [04:44] wgrant: bah, I mean, why isn't the bug present in the tree at the moment [04:44] lifeless: Because it only checks for is_stale. is_stale is set when a change is made to the branch, and unset when a daily build is requested. [04:44] Manual builds do not affect the flag. [04:45] ok, Isee [04:45] Now, in addition to the flag being set, there must be no builds. [04:45] then yes, we need to constrain by archive to fix that [04:45] s/\./in the last day./ [04:45] Right. [04:45] wgrant: whats the left join that you think works ? [04:46] lifeless: The right join, except with the arguments reversed. [04:46] I pasted a diff somewhere above. [04:46] http://pastebin.ubuntu.com/560481/ [04:46] wgrant: what sql does that compile to ? [04:48] SELECT DISTINCT SourcePackageRecipe.build_daily, SourcePackageRecipe.daily_build_archive, SourcePackageRecipe.date_created, SourcePackageRecipe.date_last_modified, SourcePackageRecipe.description, SourcePackageRecipe.id, SourcePackageRecipe.is_stale, SourcePackageRecipe.name, SourcePackageRecipe.owner, SourcePackageRecipe.registrant FROM SourcePackageRecipe LEFT JOIN (SourcePackageRecipeBuild JOIN PackageBuild ON PackageBuild.id = ... [04:48] ... SourcePackageRecipeBuild.package_build JOIN BuildFarmJob ON BuildFarmJob.id = PackageBuild.build_farm_job AND BuildFarmJob.date_created > %s) ON SourcePackageRecipeBuild.recipe = SourcePackageRecipe.id WHERE SourcePackageRecipe.is_stale = %s AND SourcePackageRecipe.build_daily = %s AND BuildFarmJob.date_created IS NULL [04:49] Which looks fine. [04:49] ok, that would be ok [04:50] StevenK: you can switch to that if you want; I don't care. Otoh avoid right join just because it hasn't been used would be noddy [04:50] You really do like using the word 'noddy' recently, have you been reading the books? [04:51] which books? [04:51] lifeless: Avoiding divergence that cannot be explained sounds very reasonable to me. [04:51] lifeless: http://en.wikipedia.org/wiki/Noddy_%28character%29 [04:51] why do elephants have big ears? [04:51] The use of RightJoin confused everyone into thinking it was more complex than it was. [04:51] StevenK: no [04:51] because Noddy wouldn'y pay the ransom HAHAHAHAHA [04:51] When a perfectly good LeftJoin worked perfectly fine. [04:52] wgrant: its not complex; a left join with inner table is more complex (need brackets to express it) [04:52] wgrant: A LeftJoin and a RightJoin aren't any more complex than each other? [04:53] StevenK: No, they are identical. But some were arguing that a right join was the only way to do it. [04:53] that said, I don't care; its entirely irrelevant that right join hasn't been used so far. LP is only beginning its optimisation path. [04:54] lifeless: I'd want the right join parenthesised too, for clarity. [04:54] I'd stay with the right join at this point because its working, is correct, and produces more readable SQL. [04:54] Hm? [04:54] wgrant: for that, you need to patch storm [04:55] What is unreadable about "table LEFT JOIN (other table JOIN other table ...)"? [04:55] It expresses the intent more clearly. [04:55] We want table. [04:55] less readable [04:55] Not (other table JOIN other table ...) [04:55] this seems like a pointless debate [04:55] It is. [04:57] from a review standpoint, right join does the job and is correct, and no clearer than left [04:57] nor less clear [04:58] lifeless: To be frank -- so the fact that nothing else uses it in the tree is irrelevant? [04:58] indeed [05:00] identical plans [05:01] wgrant: the nothing-else-uses-it argument is irrelevant because left isn't intrinsically better than right, and there will always be things that happen for the first time. [05:01] viva la difference [05:02] lifeless: Things do happen for the first time, yes. But in this case there was precisely 0 benefit in introducing a new way to do things. [05:02] And I believe the left join expresses the intent more clearly. [05:02] So I argued for that. [05:02] wgrant: why do you think it expresses it more clearly? [05:03] Ugh, 33degC [05:03] Perhaps the other side of the apartment is cooler, but I doubt it [05:03] lifeless: Because the left one joins conditions onto the target table, rather than joining the target table onto the conditions. [05:03] wgrant: "Bikeshed" [05:03] Definitely. [05:04] I agree [05:04] I was not going to argue for it strongly until lifeless stated that a left join would not work. [05:04] For reviews, we need a massive increase in readability to cover the cost of a discussion [05:04] Then I feared that I had some deep misunderstanding of joins. [05:05] wgrant: I misspoke; I was having fumble-fingers in crafting manual sql [05:05] Right. [05:05] LEFT actually. [05:05] That is clear now. [05:05] But it didn't become clear until this argument was well underway :) [05:05] :) [05:06] wgrant: nice catch on bug 579987 [05:06] wgrant: are you cruising for oopses to fix ? [05:06] In other news, SSO has actually succeeded in being harder and more time consuming to install than the Launchpad that it is mean to be an improvement on. [05:06] Where did our bug bot go? [05:06] lifeless: I'm babysitting c-i-p for now, but plan to look at Archive:+copy-packages seriously next. [05:06] cip ? [05:06] howso? [05:07] canonical-identity-provider, so I can debug the private codebrowse issues. [05:07] \o/ [05:07] wgrant: O [05:07] Since they hit me a few times a day, and it is sort of getting old. [05:07] wgrant: I've pointed bigjools and sinzui at the 16K oopses from codebrowse; [05:08] lifeless: Yes, but loggerhead. [05:08] wgrant: you do look at /launchpad-project for bugs, right ? [05:08] Occasionally. [05:08] so, partial success \o/ [05:13] * thumper away cooking [05:24] lifeless: fwiw, the lp-architecture i was doing wasn't a complete redo. it re-used existing docstring and doctests. i was careful which doctests got included, though, since probably more than 90% of the existing doctest do a bad job at being documentation. it was also meant as a guideline of how to write new documentation. [05:27] BjornT_: kk; some of that nuance got lost in handover [05:52] lifeless, is lp planning to make a new api version snapshot some time? [05:53] i see people are now being advised "just point to /devel" which seems likely to cause the same problems as with beta all over again [05:53] poolie: yes [05:53] poolie: for things that they aren't shipping on cd-roms [05:54] we probably need to get a bit more rigorous about when to freeze things [05:54] probably [05:54] even just freezing whatever's in there every six months could be a start [05:54] (i don't know if supporting multiple versions is expensive in the code or something) [05:54] And more rigorous about what we freeze. [05:54] hugely [05:54] hugely expensive? [05:55] its awfully complex, prevents refactoring, freezes concepts that are mutable [05:55] sure [05:55] prone to failure, hard to report on. [05:55] it's like our api stability [05:55] poolie: its worse [05:55] oh, why? [05:55] poolie: because we have to support them all concurrently [05:55] hm, kind of [05:55] poolie: we can't say 'if you want the old api, don't upgrade your package' [05:56] i see what you mean, but in practice when people get a new ubuntu release, they get a new bzr [05:56] and either bzr or the plugins needs to cope [05:56] anyhow [05:56] istm that at the moment lp just says "there are no promises about apis" [05:56] which may actually be the most sensible way to do it [05:57] anyhow, it is hadr [05:57] my main concrete suggestion was just to do a snapshot once or twice per year [05:58] even if they're only supported for a year after that [05:58] tangentially, from max: [05:58] > Yes, it's really true - earlier launchpadlib versions only offered you the choice of edge or staging. [06:00] Well, lpnet didn't have the API for ages, because it was in beta. [06:01] i know [06:01] i just wonder if it would have been better to declare the url, even if it didn't work [06:01] maybe not [06:01] was from https://code.launchpad.net/~maxb/bzr/launchpadlib-service-root-api-compat/+merge/47885 [06:06] mwhudson: Naturally, codebrowse auth is completely reliable locally with a local c-i-p. [06:08] Hmm. [06:09] It's a bit of a wild guess, but I wonder if only one of the login.launchpad.net IPs is visible from wherever runs codebrowse. [06:09] so [06:09] lp had the crazy thing of 'beta means a different cluster' which had all sorts of negatives [06:09] I would have done it differently [06:10] but its history: no second guessing [06:10] s/would // [06:10] we're doing it differently now [06:11] lifeless: Who can check firewall rules? [06:11] losa + gsa I believe [06:12] well gsa only actually. [06:27] poolie: Oh, ugh, just read that MP. [06:27] That's really awful. [06:27] lifeless/lp hackers, congratulations on your timeout reduction! [06:32] poolie: thanks [06:33] (on behalf of the folk that did all the work) [06:51] bwah, no stub [06:52] spm: what LPCONFIG / dbuser does the garbo run under? [06:53] prod for 1 [06:53] garbo_daily & garbo_hourly for 2 [06:55] spm: you can do permission changes live, right ? [06:56] with extremely good reasons for, maybe. depends. [06:56] so yes, great. [06:57] spm: do we run security.py --incremental on nodowntime deploys yet? [06:58] not that I'm aware of. that'd require a manual intervention on the db servers [06:58] spm: shouldn't need to be manual. [06:58] I'll ask stub to RT up whats needed. [06:58] oh god yes it should. [06:58] spm: why? [07:26] i got a "Your message was rejected" mail in response to my mp comment [07:26] i guess this is because a list is subcribed, perhaps launchpad-bugs [07:27] yes [07:28] grrr [08:14] any reviewers around ? === stub1 is now known as stub [08:21] \o/ [08:21] https://code.launchpad.net/~lifeless/launchpad/bugtask+index/+merge/47969 [08:21] stub: ^ if you're around, I can has review? [08:22] k [08:24] Internet is still sucking :-P [08:24] Project devel build (404): FAILURE in 6 hr 54 min: https://hudson.wedontsleep.org/job/devel/404/ [08:25] well, thats bangkok isn't it ? :) [08:25] At least I have the excuse of living in the 3rd world. [08:34] Hah. [08:34] c-i-p boog. [08:35] wgrant: you've made progress ? [08:35] lifeless: I can reproduce it locally and see why it's doing what it's doing. [08:35] Now I need to go and read the spec :( [08:37] stub: how long will it take to add an index to BugMessage.index [08:38] lifeless: Any reason why indexMessages rewrites .index on all BugMessages, even if it is already set? [08:39] stub: its simpler than checking that all the unallocated ones have been allocated by the same algorithm [08:39] stub: e.g. if someone deletes a BugMessage it will handle that [08:39] There is already one on (bug, index)... [08:39] stub: yeah, but the garbo needs to find all with index is NULL [08:40] stub: for a few months while we let the garbo build the per bug indices [08:41] 6.5 seconds on staging for just an index on BugMessage.index [08:44] lifeless: I thought one of the points of this column was to keep stable message indexes? [08:45] stub: it is; needs to be phased in [08:46] Shouldn't take months. I would have thought fairly quick even with the current index (I think it will get used once a sizable percentage of the rows are filled, even if it isn't the optimal index). [08:46] stub: phase 1 - get the index approximately up to date; phase 2 - appservers / mail processing starts writing BugMessage.index too; phase 3 field mandatory garbo job removed; phase 4 start querying from the index [08:47] good morning [08:47] stub: looks to do a seqscan at the moment; we can wait for doing an index on bm.index specifically [08:50] It will do a seqscan until it is more efficient to use an index, which would mean a pretty high percentage of the rows have been updated. Until then, it is faster to do seqscan than use an index. [08:51] stub: indeed, and thats fine; I'm not sure that there *is* an index for it to use. [08:52] stub: because the (bug, index) index isn't selective on index unless bug is being considered (which it isn't for the populate case) [08:56] morning [08:56] lpmain_staging=# explain select bugmessage.id from bugmessage where index is null limit 50; [08:56] QUERY PLAN [08:56] --------------------------------------------------------------------------------------------------------------- [08:56] Limit (cost=0.00..2.03 rows=50 width=4) [08:56] -> Index Scan using bugmessage__bug__index__key on bugmessage (cost=0.00..149895.69 rows=3700397 width=4) [08:56] Index Cond: (index IS NULL) [08:56] (3 rows) [08:57] stub: *blink* [08:58] stub: that shows a seq scan fo rme [08:58] on staging [08:58] oh if you turn seq scan off it will force an index; doesn't mean its a good one :) [08:59] stub: I suggest we sit on the need for an index until this is running live [08:59] stub: and we can see how its going [08:59] I think they introduced that around 8.3 - before it could only use the index if you where selecting on the left most columns. [09:01] lifeless: You need to explicitly disable sequential scans (set enable_seqscan to false) [09:01] yeah [09:02] I can create the index live if we want, or we can add one in a db patch it we also open a bug stating it to be removed [09:02] stub: indeed [09:02] stub: either way I think deferring it till we have the garbo live makes sense, do you ? [09:03] yes [09:03] Do we still have an anal XXX policy or did we drop that? [09:03] Hehe... anal XXX [09:04] See what Google thinks of our IRC logs now. [09:04] thanks stub, I just lost a mouthful of coffee over my desk [09:05] stub: nothing in https://dev.launchpad.net/PythonStyleGuide about xxx :P [09:05] stub: even if we have something, I would argue that this one is going to last 4 months tops till the migration is complete. [09:06] then the garbo job goes away [09:06] Sure. Just wondering if it will trigger any XXX reporting tools someone is running that expects a bug number in there. [09:07] oh no [09:07] they are stale [09:07] Hi [09:13] lifeless: reviewed. A few niggly bits, most likely irrelevant if this code is going away in your stage 4. [09:14] lifeless: See my last comment in bug #676372. [09:14] I think we should just disable stateful association for now. [09:14] wgrant: I don't know what that means [09:14] stub: thanks [09:15] lifeless: Yay OpenID. [09:15] Who knows OpenID? [09:15] I used to [09:15] stub: I don't want have to deal with db constraint issues if someone plays silly buggers in the db between now and phase 4 - thats why I'm making them al the same [09:15] stub: do you see an issue with that ? [09:16] stub: separately, we don't have a bug yet for the separate phases; I don't feel much need to precreate them. Do you? [09:17] Its to make sure the task doesn't get lost or forgotten. [09:17] stub: it won't have that affect though :) [09:18] stub: 6000 items - anything > 1000 down has been effectively lost already [09:18] I do like todos or XXXs to link to the relevant discussion so if some person trips over them in 2 years time it is clear it is tech debt. [09:20] Referencing Bug #704446 is appropriate [09:21] sure, I can do that (though thats not a future bug, thats the current bug :)) [09:24] Anyone know about wireless boosting? I'm getting interference and moving the base station is going to be a pain. [09:25] you can use iwconfig to set power levels [09:25] you could try a different channel [09:25] or a second ap [09:25] new channel is best bet [09:28] Looks like I'm at max. I already rebooted this morning and got a new channel. [09:28] how does reboot <-> new channel ? [09:29] multiple APs? [09:29] Second AP might be best. Biggest problem is no power on the stairs. [09:30] lifeless: Its set to auto, so it detects what channel looks cleanest. Of course, what is cleanest on the ground floor isn't necessarily what I get on this side of the house on the 3rd floor. [09:30] stub: did you see the last couple of comments on the MP my for debversion changes? [09:30] bigjools: Yes. I was about to test an updated DB patch before lifeless distracted me with his review. [09:31] stub: great [09:31] bigjools: I'm preparing a branch based on yours anyway [09:31] all the tests pass apart from the db restore one [09:32] bigjools: I commented on that; I'm pretty sure its just trusted.sql you need to fiddle [09:34] I said that from the start but apparently I needed to put the change in the patch file ... [09:34] bigjools: you need both [09:34] bigjools: trusted for new dbs, patch to load it in prod [09:34] /o\ [09:35] * bigjools -> otp [09:35] bigjools: back in england? [09:35] yarp [09:39] lifeless, bigjools: I think I'll run it manually on production and staging, and add it to the baseline for devs (launchpad-2208-00-0.sql) [09:49] wheee 1727 sql statements [09:51] stub: you're talking about my patch? [09:51] bigjools: The debversion.sql stuff, yes. [09:52] ah ok [09:52] not the other stuff [09:52] stub: the other stuff takes 4h on dogfood, can you see a way of speeding it up? The SPRs take only a few minutes, the rest is the BPRs :/ [09:53] Gah... need that debversion package installed on staging. [09:54] http://paste.ubuntu.com/560548/ is the optimized version, and it will go a lot faster with suitable RAM (and workmem setting) [09:54] But we need an empirical test [09:55] gnight [09:58] stub: huh, didn't think changing types would work [09:58] nn lifeless [09:58] bigjools: It probably won't speed things up though - might save a few table scans but that isn't much compared to rewriting all the rows. [09:59] I suspect rebuilding the index is the big part [10:04] stub: so did you figure out how to include the contrib's sql without pasting it to the patch file? [10:04] or are you just literally running it manually? [10:05] bigjools: I'm currently testing manually. I will include it inline in the baseline .sql script (which will be exactly how it will be next time I dump the production schema to create a new baseline .sql). [10:06] stub: cool - so are you going to land the patch as well? If so I'll remove it from my branch (I have other code changes dependent on it) [10:07] bigjools: If you remove stuff from your branch, that will cause conflicts with my branch. [10:07] stub: you're confusing me [10:08] I've branched your branch. When I have sorted my end out, including what to do with contrib/debversion.sql I can land it or you can merge it back into your branch. [10:08] ok cool [10:09] I think these timings are not going to be happy and this is going to be a sucky two or three part process :-( [10:11] yes [10:12] 7 minutes just for spr, not including building the new index. [10:15] I don't see how we can upgrade any of it without a load of extra downtime [10:15] BPR will take an hour at least [10:19] Ok. There are some active jobs running, but I don't think they will affect things that radically. [10:26] howdy folks [10:26] bigjools: huh. or maybe not. [10:26] stub: que? [10:27] morning jml [10:27] bpr took 13 minutes [10:27] (setting work_mem to 3GB might be the win there) [10:27] stub: to change the column type or regenerate the index? [10:27] Change the column type [10:28] tell me when the index is done :) [10:28] using a different computer & OS today :\ [10:28] bigjools: Indexes took < 2mins to build. [10:28] !!! [10:29] Setting a high work_mem means indexes get done in ram rather than temporary files [10:30] awesome [10:30] So, is this good enough? [10:30] * jml continues experimenting w/ IRC clients [10:30] if we're going to be within budget, yesw [10:31] bigjools: http://paste.ubuntu.com/560560/ has the timings [10:32] * stub tries to remember what the budget is atm [10:32] 1h total but not sure what else we have [10:32] bugger all after the epic I suspect [10:33] those figures are on staging, how different to prod is that? [10:33] Yer - just dropping a column from blueprintnotification [10:33] looking good anuway [10:34] Add 50% for production because it has 3 nodes rather than stagings two, and you get a conservative timing (conservative because the production hardware is much faster) [10:35] oh... I just ran that on a single node. [10:35] So triple [10:35] I think we just squeeze in [10:35] 22 mins * 3 then? [10:35] minus hardware advantage [10:36] that is a squeeze [10:36] ahh, that's better [10:37] never been able to use Pidgin / Adium for IRC. [10:38] bigjools: And the fact staging was busy at the time I did the timing. [10:38] right [10:38] jml: are you being traitorous today? :) [10:38] bigjools: kind of [10:40] bigjools: my laptop is a bit buggy atm due to running natty upgrades. Now I'm using my other computer, which isn't running Ubuntu (although not for lack of trying) [10:47] work_mem != maintenance_work_mem [10:54] I have a feeling we're not in Kansas anymore [10:54] -bash: make: command not found [10:54] -bash: make: command not found [10:54] -bash: make: command not found [10:55] Af [10:55] Er. [10:55] Are you trying to run Launchpad on OS X again? [10:55] wgrant: no, not at all. [10:55] wgrant: and also, I don't recall trying before, unless it was four years ago [10:56] Hmm, must have been someone else. [10:57] wgrant: I had a Macbook when I started until about Oct 2008, but I'm pretty sure I dual booted into Linux for Launchpad development. the OS X partition was just for WoW. [10:58] in fact, IIRC, it was missing several core system files. There wasn't much room on that partition, and I had to get rid of *something* [11:03] stub: FYI I had to apply this patch to get database upgrading working on DF: http://pastebin.ubuntu.com/560565/ [11:06] bigjools: So it only works at the moment if the cwd is database/schema ? [11:07] stub: it worked previously from anywhere, dunno why it stopped working [11:07] wallyworld: attaboy :) [11:08] bigjools: context? my email? [11:08] wallyworld: yep [11:08] that's the way i've always approached such things :-) [11:11] Does anyone know if there's a way to get launchpadlib to stop trying to interact with the Gnome keyring? It always fails if you're in a screen session or accessing the machine remotely. [11:12] I hack the keyring egg. [11:12] There's a function in there that tries to import the GNOME keyring stuff. I adjust it to always fail. [11:13] wgrant: Well, I was hoping for something other than "HULK CRUSH", but that works. [11:16] * maxb lols at HULK CRASH [11:16] on a bus, so quietly :-) [11:17] gmb: set a config file [11:17] bigjools: Can you be a bit more specific? [11:17] yes, gimme some, was just looking it up [11:17] Cool, thanks. [11:22] gmb: http://pypi.python.org/pypi/keyring#customize-your-keyring-by-config-file [11:22] bigjools: Ah, thanks. [11:23] use the file backend [11:23] bigjools: lp:~stub/launchpad/debversion-denormalise [11:23] Right. [11:24] stub: ta [11:39] stub: so I need to put the contrib sql in trusted.sql now to make local stuff work....? [11:44] test_testSampledata still fails anyway === mrevell is now known as mrevell-lunch [12:24] Morning, all. [12:26] wgrant: https://bugs.launchpad.net/launchpad/+bug/710578 looks like what you were investigating [12:26] <_mup_> Bug #710578: Not able to see contents of private branch < https://launchpad.net/bugs/710578 > [12:41] bigjools: Nothing needs to go in trusted.sql [12:41] stub: ok, how do we fix test_testSampledata? [12:56] bigjools: Works for me with a freshly built database [12:57] :/ [12:57] I just did a make schema and tried it and .... fail [12:58] Doh... wrong tree [12:59] * bigjools keeps sanity - temporarily === mrevell-lunch is now known as mrevell [13:14] bigjools: Looks like a PostgreSQL bug [13:15] pg_restore --clean is dropping the type, then functions with parameters of that type (which fails, because the type no longer exists) === Ursinha is now known as Ursinha-lunch [13:43] mrevell: ping [13:43] Hi bac [13:45] stub: awesome [13:46] stub: can we work around it? === salgado is now known as salgado-lunch [13:59] bigjools: Bug #5857 upstream at http://archives.postgresql.org/pgsql-bugs/2011-01/msg00247.php [13:59] <_mup_> Bug #5857: Give clue to scope of changes when linking to changelogs < https://launchpad.net/bugs/5857 > [14:00] bigjools: work around will be annoying - rather than use clean, we need to create an empty database and restore into that without --clean [14:00] yay :/ [14:01] (so race conditions on database creation and tear down to deal with) [14:02] stub: what is that test actually testing? As in, where is that restore stuff used? Is it just tests? [14:03] gary_poster: got a minute to help me out with a question about twisted? [14:03] how would you go about telling people about expected mail volume when they "structurally" subscribe to something? [14:03] jtv, I can try [14:03] jml, history [14:03] gary_poster: voice might help… can we mumble or skype? [14:03] gary_poster: is that history in the db? [14:04] jtv, actually, no, I can't. :-) I have tonsillitis [14:04] Oh! That's not fun. [14:04] no :-/ [14:04] Hope that gets better soon. [14:04] thank you [14:05] On a sidenote, it's an affliction I pointedly fail to recommend for distant sprints. [14:06] jml, at a hand-wavy level, at least, yes: most of the things we are interested in filtering on for bugs appear to be visible when you view a bug [14:06] (status changes, and so on) [14:06] but it would be a manual thing [14:06] gary_poster: manual how? [14:06] jtv: #twisted is often helpful, fwiw. [14:07] Thanks. I'm looking to parallelize something, and wondering whether twisted is worth it. [14:07] jml, manual is the wrong term. um, expensive [14:07] bigjools: when we load the sampledata, all the constraints are disabled - including foreign key constraints. So if you edit the sampledata manually, you can end up with corruption. [14:07] gary_poster: ahh, I see. [14:07] unless we did code to make it less so, probably involving cacheing statistics [14:08] gary_poster: was just thinking that it might be a good way to mitigate the social concerns of subscription [14:08] bigjools: foreign key references pointing to non-existent rows in the database. This has happened in the past, thus the test. [14:08] ok [14:08] "You will get around 500 emails a day if you do this" [14:09] jtv: using twisted on the publisher?! [14:09] nonono [14:09] hmm. [14:10] bigjools: just thought I'd explore how stupid an idea it was before suggesting it. ☺ What's the reason? [14:10] jtv: way too hard for a quick fix [14:10] actually, that could be quite complex if you start taking a user's existing mail into account. [14:10] jtv: and it'll need to Popen the a-f process anyway [14:11] twisted won't give us any net win unless we need to block on external stuff [14:11] it's still single threaded [14:12] jml, yeah, I can see it. bdmurray also suggested, as I expect you saw. I'd say first step to explore feasibility would be to talk to gmb or deryck and see if they had any obvious "no no no, this is way expensive." If there were no solid answers then, I wouldn't feel comfortable estimating without commissioning some kind of exploratory spike [14:12] gary_poster: I reckon we should do a timeboxed spike. e.g. give someone a day to do a proof-of-concept [14:13] gary_poster: which is to say, that sounds like a sensible plan :) [14:13] :-) [14:13] cool [14:14] gary_poster: the LEP looks good, btw. Only unsure about one thing... [14:14] gary_poster: bdmurray says that he wants to get mail for all High & Critical bugs on Ubuntu. It seems that the "all bugs on Ubuntu" condition is met, but I can't tell if the "High & Critical" bit is part of the LEP or not. [14:15] jtv, I agree with bigjools that integrating Twisted into our Zope process is probably not a good quick fix, if that is what you mean. I have tried to get some people excited about making the "new" Twisted wsgi support allow for a WSGI result to be modified by postprocessing within Twisted but that is not hear now, nor have we integrated it. [14:15] bigjools: I'm all for doing it directly and easily, since I'm lazy. But I wouldn't want people to come back later and say "why, why, WHY didn't we do this in twisted?" I'm not all _that_ familiar with the thing. [14:16] jtv: twisted is the wrong thing to use here, so don't worry about that [14:16] Relieved to hear it. [14:16] Popen it stays then. [14:16] jtv: popen the a-f processes, wait, profit :) [14:16] jml, great, thanks. "High & Critical" are importances, so we can filter on them [14:16] ("Only subscribe to notifications that happen on bugs that have any of one or more selected importances." in Must) [14:17] ahh yes [14:17] I see it now. [14:19] gary_poster: cool. I'll give it a look over again & then send an email for the public record. [14:19] sigh, why do I misspell thing with homophones that I know perfectly well are incorrect when I am typing quickly? s/that is not hear/that is not here/ [14:19] awesome, thanks jml [14:20] heads up folks, I just registered a project with proprietary license: certify-hudson [14:21] gary_poster: I don't know, but one day I would love to read a study on typing mistakes made by highly proficient typists. [14:21] heh, that would be interesting :-) [14:25] abentley: https://lpstats.canonical.com/graphs/TranslationMessage/20100201/20110201/ [14:27] jtv: http://paste.ubuntu.com/560623/ is surprisingly doable, although there might be non-messages that still trigger emails and it doesn't take into account email batching (but better to over estimate than under) [14:27] stub: did you mean to tell someone else? [14:28] I'm a bit ENOCONTEXT on this. [14:28] jml: ^^^ [14:28] oh hi :) [14:29] stub: ooh, nice. [14:29] stub: isn't ~650ms a bit long though? [14:30] 2.5 secs for ubuntu, so certainly not in the web ui. But we can build caches maybe. [14:30] (11380 message rows in the last week...) [14:31] any chance someone can review https://code.launchpad.net/~jcsackett/launchpad/assertion-error-697294/+merge/47911 [14:32] bigjools: I'm tempted to say disable the test and open a bug saying it is disabled and referencing the upstream bug. [14:33] stub: if we have to take unreasonable workarounds, that sounds ok but when would we be likely to get a fix? [14:34] stub: fair enough. we would probably only want rough numbers anyway. === Ursinha-lunch is now known as Ursinha [14:40] deryck: i just noticed the bug tag entry widget on qastaging is not using JS. known? [14:40] Yippie, build fixed! [14:40] Project devel build (405): FIXED in 6 hr 16 min: https://hudson.wedontsleep.org/job/devel/405/ [14:40] * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=710360] Add a config schema section for [14:40] gina to import wheezy. [14:40] * Launchpad Patch Queue Manager: [r=stevenk, [14:40] thumper][ui=sinzui][bug=334336] Extend recent revision listing on the [14:40] branch index page to show additional information for each revision, [14:40] including the branch merged and any associated bugs for that branch. [14:41] 6 hours? *weep* [14:42] jml, mbp gave two LEP ideas in his reply on the thread that I think are worth your review. Since you are about to give an official blessing, this might be the last good chance, at least for a while. [14:42] I've put up the ideas here, with my comments [14:42] http://typewith.me/Y9qOZdZ6Kn [14:42] his idea is in "original" and I'm "Gary" ;-) [14:44] bac, for a bug page? [14:44] deryck: yep [14:45] bac, no, not known to me. And not sure what might have changed to cause this. [14:46] deryck: can you reproduce it [14:46] let me see.... [14:48] bac, works for me [14:48] hmm [14:49] bac, I tried Firefox on Ubuntu. What browser you using? [14:49] deryck: safari. trying ff now [14:50] bac, I can try Safari too === Ursinha is now known as Ursinha-sick [14:51] why would a code.l.n URL be running queries to get bugtasks? [14:52] ah nm [14:52] bac, works for me on safari too [14:53] deryck: on qastaging i see i was logged in using a test, unprivileged account [14:53] ah [14:53] when logged in as myself it works [14:53] gotcha [14:53] still unright [14:53] bac, I didn't realize we prevented tagging by unprivileged users [14:53] we don't. it takes you to the +edit page where it can be done [14:55] deryck: so i was able to add a tag, just didn't get the JS widget [14:56] hmmm, ok. That stills seem wrong. The js is expecting something to make that action inline, which it doesn't find with no-priv users. [15:05] henninge: Fancy a review? https://code.launchpad.net/~allenap/launchpad/bugs-with-blueprints-bug-707103/+merge/47866 [15:10] henninge et al: i have a translations-related question [15:10] i need to know if there are any objects published in the web service but not in the website [15:25] bigjools: I've pushed my branch with that test fixed. [15:25] stub: thanks === leonardr_ is now known as leonardr [15:26] it looks like structural subscriptions are published through the web service but not the website. can anyone confirm? [15:28] * leonardr has confirmed to his own satisfaction [15:30] leonardr: I think the closest you can get is //+subscribe or /~/+structural-subscriptions (but the latter is not linked to from anywhere yet). [15:33] former soyuz people: in addition to the artifacts we talked about on wednesday, it looks like IArchiveDependency is published on the web service but not on the web site. is this right? [15:33] leonardr: we can see dependencies in the UI [15:34] bigjools: i made a request to http://launchpad.dev/~cprov/+archive/ppa/+dependency/1 and got this error: [15:34] for example , https://launchpad.net/~julian-edwards/+archive/testing/+edit-dependencies [15:34] NotFound: Object: , name: u'index.html' [15:34] bigjools: i'm talking about a link to one specific dependency [15:34] oh, ISWYM [15:34] no, they don't exist [15:35] there's no reason why the canonical_url of every dependency couldn't be +edit-dependencies, but for now i will omit it from web_link [15:35] ok [15:35] where are you blacklisting those? [15:37] bigjools: [15:37] class IArchiveDependency(Interface): [15:37] """ArchiveDependency interface.""" [15:37] export_as_webservice_entry(publish_web_link=False) [15:38] ah great, so there's no surprise if we add a UI page later [15:42] right [15:48] bigjools: IBinaryPackagePublishingHistory also seems to have no working web link, is that right? [15:48] leonardr: yup [15:49] bigjools: but a build job does? [15:49] http://launchpad.../~cprov/+archive/ppa/+buildjob/26 [15:49] (it seems to work, i'm just sanity checking) [15:51] henninge, I assigned bug 710591 and added it to the kanban board. Just so you know. [15:51] leonardr: yeah that's relatively new, it was IBuild but we redirect that now [15:54] deryck: cheers [15:56] bigjools: PackageUpload also has no web link? [15:56] leonardr: it doesn't [15:56] maybe i should just ask you about all of these instead of testing them manually [15:56] heh [15:57] that would mean I need to remember them [15:58] bigjools: the only 2 that seem to be left are distro arch series (which i believe has a web link) [15:58] it does [15:58] and "source package publishing" (not sure what the name of the interface is, not sure if it has a webl ink) [15:58] it doesn't [15:58] sourcepackagepublishinghistory === salgado-lunch is now known as salgado [16:04] is sinzui still powerless? [16:04] henninge: Do you have time to review a branch of mine? https://code.launchpad.net/~allenap/launchpad/bugs-with-blueprints-bug-707103/+merge/47866 [16:05] He forgot to pick up his superpower from dragnob at the end of the Thunderdome. === beuno is now known as beuno-lunch [16:10] allenap: that's unfortunate. [16:10] he's been behaving oddly, perhaps it's just red kryptonite [16:10] jml: That he forgot the superpower, or my attempt at humour? :) [16:11] allenap: that he forgot the superpower. [16:46] former bugs people: it looks like there is no web url for a bug subscription or a bug nomination. is this right? === deryck is now known as deryck[lunch] === beuno-lunch is now known as beuno [17:06] bac, any chance i can trouble you for a review? https://code.launchpad.net/~jcsackett/launchpad/assertion-error-697294 [17:28] jml: hi, got 5 mins to help with a twisted test please? [17:40] similar question for registry: does a distribution source package have a web url? it looks like not [17:40] leonardr: yes it does [17:40] hmm... [17:41] ubuntu/+source/package [17:41] bigjools: ok, maybe i'm getting a 404 here because the distribution is private? [17:41] i'll try again with admin_browser [17:44] bigjools: if you say it has a web url i'll go along with it, but look at stories/webservice/xx-person.txt, around line 690 [17:44] supposedly the web_url is http://launchpad.dev/distribution327800/+source/fooix === henninge changed the topic of #launchpad-dev to: Topic for #launchpad-dev: https:/​/​dev.launchpad.net/​ | PQM is open | firefighting: - | On call reviewer: henninge | https://code.launchpad.net/launchpad-project/+activereviews [17:45] but when i GET that i get a 404 because distribution327800 doesn't exist. any idea why? [17:45] allenap: looking now [17:45] leonardr: in xx-person.txt? [17:46] bigjools: yes, lib/lp/registry/stories/webservice/xx-person.txt [17:46] the call to getBugSubscriberPackages [17:46] ok [17:47] leonardr: I've no idea why.... but the URL looks fine though [17:47] ok, i'll leave it as is for now [17:47] leonardr: does your webservice test set up everything the same was as in xx-person? that distribution looks like it was made on the fly for the test. [17:48] s/same was/same way/ [17:48] jcsackett: i added code to xx-person.txt, so it runs right after that code [17:48] leonardr: ah. that *is* weird. [17:50] * jcsackett looks closer. [17:52] leonardr: you've already tried with admin? the only thing i can think of offhand is your conjecture about it being private. === salgado_ is now known as salgado [17:52] jcsackett: yes, same result with admin. the distro itself is allegedly not there [17:55] leonardr: yeah, i just pdb'd in that test and tried to find fooix in a distribution set. nothing doing--bad hack in the setup, maybe. [17:59] jcsackett: do you know if a product release file should have a web link? i have it being the same as the web service link, and a link like this doesn't work: [17:59] http://launchpad.dev/firefox/trunk/0.9.2/+file/firefox_0.9.2.orig.tar [17:59] er, let me cut out the trunk and try again [18:01] no, that trunk should be there [18:02] leonardr: only link for those files i know of is http://launchpad.dev/firefox/trunk/0.9.2/+download/firefox_0.9.2.orig.ta [18:02] i'm not sure that's the sort of link you want. [18:03] jcsackett: maybe a project release file isn't the sort of thing that needs a distinct 'web link'? [18:03] what would you get if you hit that link? you'd download the file, right? [18:03] leonardr: yeah. [18:04] aside from web ui, wget is perhaps the only reasonable thing to be hitting it. :-P [18:05] and self_link would give you the file anyway, so it doesn't need a web_link too === deryck[lunch] is now known as deryck [18:11] henninge: are you still on call reviewer? [18:12] jcsackett: yes [18:12] got time for another (and possibly one teeny one after that)? [18:12] https://code.launchpad.net/~jcsackett/launchpad/assertion-error-697294/+merge/47911 [18:12] henninge^ [18:14] jcsackett: sure [18:14] henninge: thanks! i'll ping you with the second one in a moment (it's one line change + test) [18:25] mornink [18:25] hi lifeless === lifeless changed the topic of #launchpad-dev to: Performance Tuesday | https:/​/​dev.launchpad.net/​ | PQM is open | firefighting: - | On call reviewer: henninge | https://code.launchpad.net/launchpad-project/+activereviews [18:37] henninge: the seconde mp. https://code.launchpad.net/~jcsackett/launchpad/tags-portlet-708693/+merge/48029 [18:37] i'll leave you alone now. thanks. :-) [18:40] lifeless: have some time to chat about bug 702620? we've been leaving each other comments on it and the MP. i thought actually talking would be good. :-P [18:40] <_mup_> Bug #702620: Can't delete branches from the API that can be deleted from the web UI < https://launchpad.net/bugs/702620 > [18:41] jcsackett: hi [18:41] jcsackett: I collared sinzui last week [18:41] I think sinzui then filed a bug about the use case being unsatisfied [18:41] lifeless: ah, so then i can go ahead and land that branch as a fix against that bug? [18:41] yes [18:41] fantastic. :-) [18:42] sorry for causing friction [18:42] I have not files the bug yet... [18:42] lifeless: no, not at all. it was a reasonable question. [18:42] sinzui: are you going to, or would you like me to? [18:43] sinzui: (or would you like no such bug :P) [18:43] My self-esteem is near empty because I have not landed a branch in a week. I have been plagued by natty and power troubles [18:43] * sinzui needs a fortress of solitude to work [18:43] sinzui: \o/ [18:43] jcsackett: you still need a review? [18:43] sinzui: me too, I started a branch last tuesday that I landed last night [18:44] sinzui: so exactly one week end to end [18:44] bac: no, henninge is OCR and i have eaten his time. :-) [18:44] thanks tho. [18:44] sinzui: did you sort kernel issues today? [18:44] lifeless: I agree there should be a bug. The core issue is that there is no single place for a user to know what are the deps on an object, and how to remove them. Fixing this is beneficial to Lp engineers as well as external API users [18:45] I lost grub [18:45] wheeee [18:45] Booting from a usb sent me in a near spiral back to the bad grub [18:45] man, EST green squad has been plagued. [18:46] sinzui, you're good now? or still just limping along? [18:46] I think I will refuse updates for a week or so. I need to establish a rhythm to complete my branches [18:47] jcsackett: My computer is at 100% I think. I just need to keep the distractions away for 5 days to recover my balance [18:48] sinzui: dig. i will cease distracting you, and good luck. :-) [18:53] jml: could you perhaps ask matsubara to eyeball https://bugs.launchpad.net/oops-tools/+bug/710831 ? [18:53] <_mup_> Bug #710831: duplicate query detection not handling Bugtask Queries in OOPS-1857O1288 < https://launchpad.net/bugs/710831 > [19:06] flacoste: what did we agree our downtime budget would be? [19:08] lifeless: 90 minutes AFAIKR [19:08] lifeless: that's end-to-end [19:08] or total downtime [19:08] so we have to remove the constants from it [19:08] to get the DB upgrade budget [19:10] hey [19:10] so we should get librarian and loggerhead page renders into the PPR [19:10] what do you think ? [19:17] allenap, jcsackett: Please look at my reviews. [19:37] henninge: thanks. i've replied on the MP. [19:41] henninge: are you still around ? [19:41] lifeless: yes [19:41] henninge: btw we have login_celebrity, or the sampledata constants [19:41] henninge: so IIRC you know a bit about translations? [19:41] lifeless: I do ;-) [19:42] henninge: I wonder if you could triage bug 707895 [19:42] <_mup_> Bug #707895: LP - translation problem - inexisting terms shown as untranslated < https://launchpad.net/bugs/707895 > [19:42] * henninge looks [19:42] I can't tell if this is situation normal or fallout from recife [19:42] or something else [19:48] lifeless: it's a duplicate of bug 373269. I'll mark it as such. [19:48] <_mup_> Bug #373269: Message sharing and POFile statistics < https://launchpad.net/bugs/373269 > [19:49] henninge: awesome thanks [19:51] statik: sorry, missed my reminder === henninge changed the topic of #launchpad-dev to: Performance Tuesday | https:/​/​dev.launchpad.net/​ | PQM is open | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews [19:55] jcsackett: r=me [19:56] henninge: thanks! === salgado is now known as salgado-afk === gary_poster is now known as gary-sick [20:47] i'd love a review of https://code.launchpad.net/~leonardr/lazr.restful/web-link/+merge/48052 [20:52] henninge, ping. how goes the fix for overriding upstream translations? [20:53] deryck: it won't be done today, sorry, but it seems to tie in with the groundwork I was doing. [20:53] for the feature [20:53] at least this fix does. [20:56] james_w: did you mean to forward francis announcement to lp-dev ? [20:56] lifeless, nope [20:56] linaro-dev [20:56] :P [20:56] morning [20:57] (finally) [20:57] henninge, ok, well that's nice at least. Do you have an eta for a fix? [20:58] deryck: since I am not here tomorrow it will be on Wednesday. I will try to get something up for review by tonight. [21:01] mwhudson: How much do you know about codebrowse OpenID? [21:01] wgrant: i guess i knew a bit once [21:02] henninge, ok. if you can't get something up for review, then send us a hand off email. One of us can pick it up tomorrow. [21:02] ok [21:03] henninge, thanks! [21:03] mwhudson: I wonder if you have any thoughts on my last comment in bug #676372. [21:03] <_mup_> Bug #676372: "Server denied check_authentication" from bazaar.launchpad.net private branch since 11926 deployed < https://launchpad.net/bugs/676372 > [21:04] huwshimi: ok to have our call a bit early? [21:04] lifeless: will do [21:04] jml: Sure. When do you want to do it? [21:04] huwshimi: now, if possible. [21:05] wgrant: ah yes, i guess using a MemoryStore should be a bit of a giveaway [21:05] jml: Can you give me two min? [21:05] huwshimi: sure. [21:05] huwshimi: just skype me when you're ready [21:05] jml: Thanks [21:06] later on, everyone! [21:08] mwhudson: Do we disable association entirely, or use SQLite? [21:08] wgrant: Did you see my pointer about a possible dupe? [21:08] wgrant: what are the consequences of disabling the association entirely? [21:09] mwhudson: One extra HTTP request from the server to SSO per authentication attempt. [21:09] So, nothing. [21:10] wgrant: seems least effort [21:10] StevenK: Yeah, thanks. [21:25] wgrant: i guess i can review that branch rather easily [21:25] mwhudson: I haven't started yet, but I'll do it shortly. [21:26] cool [21:31] sinzui: hi; bug 710547 - what would i look for in his mbox ? [21:31] <_mup_> Bug #710547: Answers not accepting e-mails correctly < https://launchpad.net/bugs/710547 > [21:32] lifeless: I look at his reply and I cannot see why Lp has nothing more that the quoted part. [21:33] so, iz bug? [21:33] lifeless: I think next steps are to look at the production db, read the parsing rules or rendering rules to see what Lp thinks the message is and how to render it [21:34] lifeless: I am not certain if Lp or the message is at fault [21:35] sinzui: sure; but something is wrong ;) I'm going to mark it triaged [21:36] And if you discover that evo made a bad message or the user inserted an bad character you will mark it invalid [21:37] I think the bug is incomplete because I have never heard of message corruption as described in the bug, and there are enough messages in entering Lp to demonstrate Answers app and Message handling is working [21:38] sinzui: it should be incomplete if we want more data from david [21:38] sinzui: otherwise it will expire [21:38] no [21:38] it is incomplete if we do not now if it is a bug [21:38] lifeless: Ping me when you're free -- I'd like to deal with that join today, but I need to call my bank. [21:38] sinzui: this seems incompatible with bug expiry [21:39] If we wanted more information, then users and engineers would be switching bug status all the time, which is not what we intend [21:39] mpt has even cited the ambiguity of incomplete that causes users to think incomplete means "want information". [21:40] sinzui: but how do you explain bug expiry then ? [21:41] There bug/feature cannot be resolved because it cannot be understood or reproduced. But that is beside the point. I do not know there is a bug. I do not that triaged means I have enough information to work on the issue. I certainly do not [21:42] sinzui: thats not what triaged means though :) [21:42] sinzui: triaged means 'importance assigned' [21:42] It does [21:42] really it DOES [21:42] thumper: ping [21:42] jml: hey [21:42] thumper: up for a quick chat? [21:42] sure [21:42] mumble? [21:42] thumper: sure [21:42] triaged means someone understands the issue and correctly judge the priority. [21:44] Lp could know triaged without and ENUM. If an LP engineer sets a priority. It is triaged. The problem is that Engineers come and go, so we do not trust the implicit nature of triaged [21:48] sinzui: sorry for going quiet, I'm otp with flacoste [21:51] sinzui: ok, I'm off the phone [21:51] thumper, StevenK et al: https://code.launchpad.net/~leonardr/launchpad/web-link/+merge/47258, https://code.launchpad.net/~leonardr/lazr.restful/web-link/+merge/48052 [21:51] sinzui: so, if something is not *known* to be a bug, but the next step is an engineers, what status should it have? [21:51] sinzui: it cannot have incomplete or it will expire. [21:52] lifeless: We have 60 days to understand this [21:52] sinzui: but a poor queue to look at [21:52] sinzui: and any stall will result in expiry; this is undesirable. [21:53] lifeless: It will not expire if the bug is assigned to an engineer to triage it [21:53] sinzui: I'm ok with saying 'if someone is looking at it but not sure they will claim the bug' [21:54] sinzui: we don't currently say that [21:54] sinzui: would you like us to say & do that? [21:56] Claim? Do you mean the engineer cannot see he has a bug assigned? Engineers must unassign bugs that they are not committed to take to the next status because that causes users to think something is happening. [21:56] sinzui: claim/manager assigns are equivalent in terms of discussing the process [21:57] sinzui: I suspect I am, at best, confused here. Perhaps we could switch to voice, or start over, or something. [21:57] I do not permit my team members to have a lot of bugs. I think holding on to a bug that will not be fixed in a month leads to terrible miscommunications with the team, our stakeholders and our users [21:58] sinzui: I want to make sure that this report doesn't get expired when *we* were the folk that needed to look further. [21:58] I reguarlly unassign bugs that are not demonstrated to be progressing. [21:58] sinzui: I don't think leaving it incomplete and subject to expiry is sensible [21:59] lifeless: I really do that the bug, and email in my browser, but It cannot understand the issue at this moment, and I have a an 7 day-old branch. I need to move my branch before I can move the question [21:59] sinzui: ok; I'll get out of your hair. [22:00] sinzui: I think there is something to discuss more, another time. [22:03] If I replace 'devel' with 'stable' in bzr --no-plugins cat http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/utilities/rocketfuel-setup > rocketfuel-setup, will this download and run launchpad stable, instead of developement? [22:03] no [22:04] you need to start with devel, once you have that you can switch to stable (which is only a couple of days older) [22:04] I see, how then do I switch to stable? (I can't login on devel) [22:05] gerbilschool: stable is not stable like desktop software. there are not releases because Lp is always in development [22:06] I understand, thanks a lot! [22:06] No, you really dont :( [22:11] lifeless, :-D [22:15] gerbilschool: what do you want to achieve? [22:21] lifeless: I have this feeling that gerbilschool is trying to log in to a local instance using their production credentials [22:21] StevenK: who knows [22:21] StevenK: you pinged [22:21] StevenK: my stack is clean now, I'm looking for perf tuesday bugs and to help folk that need help [22:21] lifeless: sorry for the delay (I was forced to reboot) [22:22] gerbilschool: no problem [22:22] lifeless: I want to see if I can get a 'working' launchpad instance on my machine, [22:22] gerbilschool: you may have... [22:22] lifeless: Indeed. I'd like to fix this join to also check that PackageBuild.archive == SPRecipe.daily_build_archive, but that causes an issues since SPRecipe isn't in the mix when we're adding the PackageBuild join. [22:23] StevenK: hmm [22:24] lifeless: What I just thought about was I could do this in the ON section when we join in SPRecipe [22:24] sinzui: I followed the instructions at dev.launchpad.net, which were very clear and worked, except that if I tried to access the login screen, I got a launchpad 'Oops' screen [22:24] gerbilschool: Lp does not support account management/login/passowords. It uses OpenID. We test Lp either by logging in as users in sample data (test@canonical.com:test) or using tool (utilities/make-lp-user) [22:24] StevenK: this is another modelling glitch :( [22:26] sinzui: I tried to login, but got this mystery error as soon as I clicked 'login/register' [22:26] gerbilschool: Are you able to pastebin the error? [22:28] lifeless: How is it a modelling glitch? [22:29] wgrant: builds in general fall into the data space of daily builds [22:30] lifeless: http://pastebin.ubuntu.com/560759/ [22:30] lifeless: diff at the top, generated SQL at the bottom [22:30] lifeless: How would you model it? [22:31] lifeless: Daily builds are builds too. [22:34] StevenK: and what goes wrong? [22:34] wgrant: yes they are [22:34] wgrant, huwshimi, jcsackett: mumble? [22:34] wgrant: but we're not explicitly recording daily build [22:34] wgrant: we're saying we can infer it [22:34] wgrant: which is more complex [22:34] sinzui: anytime. think i got a burst of static from you a moment ago. [22:35] lifeless: Right. [22:35] lifeless: Nothing, I wanted you to eyeball the SQL if it looks sane and I'm joining it in the right way [22:35] wgrant: one way would be to record the nature of the build [22:36] lifeless: Although we also want to skip a daily build if there was a recent manual build with the daily parameters. [22:36] StevenK: I think its fine; it looks good to me; do your tests concur? [22:36] wgrant: according to another bug there is no way to do that [22:36] lifeless: All the tests I've run so far pass -- just writing another [22:36] wgrant: the auto builds are sufficiently special [22:40] StevenK: I'm now being redirected to 'testopenid.dev' rather than 'launchpad.dev/+login'. testopenid.dev works and I am now logged in. [22:42] StevenK: launchpad.dev/+login is redirecting to openid as well, so I cannot pastebin the error. Thanks for all the support! [22:44] jcsackett: Could you move your approved cards into QA/Landing? Development is now overfull. [22:44] Thanks. [22:45] wgrant: yeah; i'm not terribly comfortable doing that b/c they're not actually landing till after ec2 lets them, but close enough i suppose. [22:45] Also, Deployment/Ready tends to get overfull pretty easily... [22:45] sinzui: Why is there a limit on that? [22:45] wgrant: WIP [22:46] lifeless: Hm? [22:46] wgrant: the same reason there is a limit on any lane having a backlog there usually correlates to high latency and churn [22:46] In this case we have a limit of 6, and 5 cards that are waiting for a DB deploy. [22:46] wgrant: lifeless: we can easily exceed a low limit when there state staging changes [22:47] wgrant: ah [22:47] sinzui: forgot in standup; i also started and will soon be landing bug 708693 [22:47] <_mup_> Bug #708693: LocationError: 'tags_cloud_data' on project bugs' page < https://launchpad.net/bugs/708693 > [22:47] I think the older boards had no limit or it was set to something like 4 x count(team members) [22:48] StevenK: What's happening with your recipe merge thing? [22:48] jcsackett: locationError is also a traversal error, which is what I think you describe in your comment [22:48] sinzui: yes. [22:49] TALES catches lots of things and reraises them as LocationErrors. [22:49] wgrant: I'll be looking it at after I'm done with the queueing branch [22:49] StevenK: Great, thanks. [22:49] StevenK: Impending Debian release -> gina config schema change :( [22:57] wgrant: I've pushed my changes for queue-recipes-better [22:57] wgrant: *hint* [22:59] StevenK: k, looking. [23:00] mwhudson: ping [23:00] mwhudson: the branch mapping script; does it do xmlrpc or db access itself ? [23:02] StevenK: Your RightJoin still offends me, but I'll let it slide. Apart from that it looks fine, except for the indentation of the second line of the new condition. [23:02] wgrant: How would you prefer the indentation to look? [23:02] StevenK: I believe the second line is meant to be one level further in. Let's see if I can find a reference for that. [23:03] wgrant: no, its correct [23:03] wgrant: TBH, it looks like the And() that's a few lines above it [23:04] wgrant: even if it wasn't, its clear enough :) [23:04] lifeless: Eeh, I think it looks too much like there are three conjuncts, but OK. [23:04] wgrant: if you have a better layout, just give StevenK a diff [23:05] wgrant: standards mean bollux in this sort of thing [23:05] I know. But in this case it actually made it slightly less readable. [23:06] wgrant: right, so hand StevenK a diff and we can move on :) [23:11] wgrant: Is http://pastebin.ubuntu.com/560772/ better? [23:11] lifeless: db [23:12] mwhudson: https://bugs.launchpad.net/launchpad/+bug/433888/comments/11 - what do dyou think? [23:12] <_mup_> Bug #433888: Branch path mapping exceeding threshold regularly < https://launchpad.net/bugs/433888 > [23:23] lifeless: yes, that makes sense [23:23] the 10 second problem is a theoretical thing though, and not what the bug is really about [23:24] mwhudson: actually, losas are seeing very long responses up in it [23:24] mwhudson: but what is the bug really about then ? [23:24] lifeless: the limit that triggers the nagios check is 12.5 milliseconds [23:25] mwhudson: yes [23:25] mwhudson: and we're seeing what, 600 a day, or 1% ? [23:26] mwhudson: alternatively we could set a db limit of 25ms or something [23:26] lifeless: to step back [23:26] there is "the horrible edge case" i talked about [23:26] adding the 500ms timeout will alleviate that worry [23:27] but i don't think this has actually ever happened [23:27] mwhudson: they seem to say is has [23:27] mwhudson: *it* [23:27] mwhudson: up in the comments [23:28] the description of the bug is that a the nagios check that responses take longer than 12.5 ms, maybe 10 times a week [23:28] yes [23:28] lifeless: are you talking about the https://bugs.launchpad.net/launchpad/+bug/433888/comments/9 comment? [23:28] <_mup_> Bug #433888: Branch path mapping exceeding threshold regularly < https://launchpad.net/bugs/433888 > [23:28] i think that's only talking about the nagios check tripping [23:29] it is. it's a constant source of low grade "false alarms" - which is bad. as we get in the habit of ignoring them. [23:35] lifeless: i'll file another bug about getting the 500ms timeout in place and leave this one in peace to deal with the nagios check issue [23:35] mwhudson: sure [23:35] mwhudson: note that the description includes mention of 10 second lookups [23:36] oh right [23:36] spm: can i get you to look again at that? are you still seeing timeouts in the nagios alerts? [23:37] mwhudson: I believe so; let me see if I can get some science to bear here [23:42] mwhudson: ew. yes. around 9 a day on average. [23:42] given how infrequently nagios checks. that's a lot. [23:42] spm: 9 *timeouts* a day? [23:42] yarp. [23:42] as in, no response after 10 s [23:42] wow [23:43] i'm amazed our users aren't at the gates with pitchforks [23:43] Oh I see. hang a sec. I may be misreading the data. [23:43] these are critical events per the check. not necessarilly timeouts. [23:43] ah [23:43] that's less worrisome [23:43] (though obviously still not great) [23:44] yeah. these don't often result in an sms - need 3 in a row; but they do add a constant irregular stream of noise. [23:45] there's no obvious pattern I can see either. over the past 31 days, pretty even all day long. [23:47] thumper: You mentioned something on the stand-up call yesterday that would be useful to rename branches and recipes that conflict. Can you remind me? [23:47] thumper: ping === Ursinha-sick is now known as Ursinha-afk [23:54] thumper: unping [23:56] * mwhudson does some log foodling [23:56] of the last nearly 200k lookups that hit the db, about 150 exceeded the 0.0125ms threshold [23:56] mwhudson: we probably only need 99th percentile @ 12.5ms [23:56] er [23:57] lifeless: what do you mean exactly? that 99% complete < 12.5ms ? [23:57] yes [23:57] the odd outlier is tolerable [23:57] its sustained failure to reply in < 12.5ms that will mess us up [23:58] well, we're already at 99.9% of that it seems [23:58] although this measurement doesn't include backlog [23:58] sadl [23:58] sadly [23:58] yeah [23:59] mwhudson: https://code.launchpad.net/~wgrant/launchpad/bug-676372-codebrowse-openid/+merge/48086, if you could. [23:59] QA is going to be just about impossible, but it works locally against c-i-p, which is a start. [23:59] \o/