[00:53] wgrant: dogfood seems to have builders attached at the moment - is there a particular reason I shouldn't start buildd-manager to drive them, or are they busted? [01:01] cjwatson: They're not meant to actually be up [01:01] OK, I will pretend I didn't see them [01:06] cjwatson: buildd-manager probably hasn't been started since I restored the DB [01:06] Since I removed it from upgrade-dogfood-launchpad to avoid having to kill it every time I wanted a page to not timeout [01:07] Commented out in upgrade-dogfood-launchpad, and indeed I haven't seen it running === gary_poster is now known as gary_poster|away [08:58] good morning [09:43] How are we going with LP on Precise? Wondering if I need to back port something [09:44] stub: We have no immediate plans to upgrade prod [09:45] It'll be next year some time === almaisan-away is now known as al-maisan [10:35] adeuring: morning any advice on https://answers.launchpad.net/launchpad/+question/214223 [10:48] * adeuring is looking === al-maisan is now known as almaisan-away [11:17] adeuring: thank you === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On Call Reviewer: jcsackett | Firefighting: - | Critical bugs: ~200 [13:33] wgrant: my understanding is that we shouldn't be setting a proprietary branch as the productseries branch for a public productseries--you can have branches that are prop/priv whatever, but shouldn't set them as the series branch. [13:33] (from the MP you looked at) [13:34] jcsackett: That is breaking several years of existing practice, and puts every internal Canonical project into an illegal state. [13:34] It also doesn't make sense [13:34] Things can be more private than their container -- that's no problem [13:35] The problems arise when something is *less* private than its parent [13:38] wgrant: we're not forbidding proprietary branches for a product (the actual container); just the linked productseries. but your point is interesting. canonical is using proprietary productseriesbranches on public projects? those aren't projects that will be migrated to proprietary? [13:38] jcsackett: lp:foo is a productseries branch [13:39] wgrant: granted. that's not directly answering my question. do we have proprietary productseries branches on products that shouldn't be migrated to proprietary themselves? [13:39] and the intent is absolutely to stay that way. [13:40] jcsackett: Yes. The U1 and LS servers, for example, have proprietary code but are otherwise public [13:40] Launchpad until 2009/07/21 [13:40] etc. [13:40] wgrant: ah yes. of course. i am not thinking clearly. [13:42] wgrant: ok, i'll bring this up on our standup. this is meant largely to handle transitional issues, but i think there are edges that need more sorting. [13:43] Indeed [14:31] jcsackett, ping for standup [14:32] deryck: having plus problems--restarting the plugin. be there in moments. [14:32] jcsackett, no worries [14:34] abentley, adeuring, rick_h, jcsackett let's try http://tinyurl.com/orange-standup [14:35] heh [14:35] hey! bye! [14:35] deryck: Is it dying for everyone else, too? [14:35] abentley, no, just you and jcsackett [14:35] we're cursed. :-P [15:18] jcsackett, do you have time to review https://code.launchpad.net/~sinzui/launchpad/missing-potmsgset/+merge/134483 [15:31] adeuring: ping, do you know if the card you added I'm working on came from a bug somewhere? "filter private products in ProjectView.untranslatables" [15:32] rick_h: no, there is no bug or oops. I simply looked for methods that return products [15:33] adeuring: ok cool [15:33] rick_h: might be even worth to check if this method is used at all ;) [15:34] adeuring: yea, it's used but it's just projectgroup.products [15:34] which is already filtered and there's tests for that property with non-public projects [15:34] so just wanted to make sure I didn't need to add a note anywhere else [15:34] e.g. bug [15:34] rick_h: ah, ok, then just drop the card :) [15:34] so I'll note in the card the findings and move to done so we keep track that we looked there [15:35] * sinzui thinks project groups listing project work fine now [15:36] yep, should be good awesome card! :) [15:43] a lot of the cards remaining are like that.... i.e. just check to make sure we're safe in that area of the code/site. [15:45] ooi, what is the status of Barry's Lucid Python 2.7 PPA? Is that something LP is still looking at using? === deryck is now known as deryck[lunch] [17:20] abentley: you around, or off at lunch? questions from your MP. [17:24] abentley: comments left on MP. [17:26] jcsackett, do you have time to review https://code.launchpad.net/~sinzui/launchpad/publishbinary-without-publications/+merge/134527 [17:27] sinzui: you caught me just in time. :-) yeah, it's short enough i can take a look. [17:29] sinzui: r=me. [17:29] jcsackett, this is also short https://code.launchpad.net/~sinzui/launchpad/missing-potmsgset/+merge/134483 [17:29] sinzui: already did that one. :-) [17:29] thank you [17:30] you're welcome. :-) [17:30] * jcsackett lunches === deryck[lunch] is now known as deryck === yofel_ is now known as yofel [18:43] deryck: so build-not is having fun today [18:43] out of the last 4 runs, 3 times LP failed to come up and the next to last one was something out of the actual parallel testing layer [18:44] rick_h, yeah, I wondered just now based on your tweet if we have a serious problem. doesn't seem random now. [18:44] http://lpbuildbot.canonical.com/builders/lucid_lp_lxc/builds/294/steps/shell_9/logs/err.html [18:44] I just forced now, FWIW [18:44] to try to get my stuff in. [18:44] yea, but the lp not coming up is typical [18:47] grrr, it fails faster than I can force and land my branch. something seems borked now. [18:49] I see a reference to bug 504291 in the summary [18:49] <_mup_> Bug #504291: DisconnectionErrors (already disconnected) happening again

< https://launchpad.net/bugs/504291 > [18:52] deryck: well looks like the normal beanch is in an ok state but the db one failed now [18:52] rick_h, yeah, I'm asking in our ops channel to see if there's something we can do to kick buildbot. [18:53] jcsackett: Yes, I was on lunch. Thanks for the review. [19:25] abentley: thanks for responding on the MP. [19:25] rick_h: can i bother you to look at https://code.launchpad.net/~jcsackett/launchpad/filter-private-products-vocabulary/+merge/134542 ? [19:27] deryck: bug #1078410 can be marked invalid and its card deleted, right? [19:27] <_mup_> Bug #1078410: Embargoed Products are not setup correctly when created < https://launchpad.net/bugs/1078410 > [19:27] deryck: Or were you going to change it to just be about adding embargoed for bugs? [19:27] abentley, well, we need a bug for BugSharingPolicy.EMBARGOED_OR_PROPRIETARY.... [19:27] abentley, right [19:28] abentley, or else mark it invalid and add another bug. either way is fine. [19:39] i think rick_h is not here. deryck or abentley, can one of you review https://code.launchpad.net/~jcsackett/launchpad/filter-private-products-vocabulary/+merge/134542 for me? [19:39] jcsackett: On it. [19:39] abentley: thanks. :-) [19:40] yeah, thanks, abentley :) [19:43] jcsackett: Is test_search_respects_privacy_no_user actually testing the case of no logged-in-user, or an arbitrary one? I could have sworn setUp gave us the latter. [19:44] the former. [19:45] abentley: it actually looks like the setUp for this testcase doesn't cover an arbitrary user either, but no user vs no user with rights shouldn't be different given the filter clause. [19:51] jcsackett: Please add a descriptive comment to your tests. Other than that, r=me. [19:51] abentley: you got it. thanks. [20:58] deryck: can you think of anyway that you would be searching for a milestone where you wouldn't have access to the product? i think all of the milestone access points require you to already access the product. [20:59] been reading through the milestone tests and callsites, and i don't see anything that violates that idea...but a second opinion is welcome. [21:00] actually, i'll just open the above question up to anyone. [21:01] yeah, sinzui would absolutely know that. :) But there is the project group milestone case. [21:01] jcsackett, so you could have access on a group and the group's milestone but an individual project could be private [21:02] I think this is handled already though [21:02] by group you mean projectgroup, right? [21:03] deryck: yeah, i think that's handled, and i don't believe it's using the MilestoneVocabulary. [21:03] I think abentley addressed the cases where milestones from a private project are filtered when instantiating ProjectGroupMilestones [21:03] * sinzui looks on qastaging for early tests [21:03] right, he did, IIRC [21:03] jcsackett, and yeah I meant projectgroup. I was lazy typing. :) [21:04] jcsackett, and I agree, I can't think of any case where you'd be using the vocab and not have project access. [21:04] deryck: ok, i think i'll move this card out of in progress then, as i think there's no further work to be done. [21:04] nice! [21:04] cards are dropping like that all over today. :) [21:05] i'm not sure if rick_h knows it, but we're having a race. [21:05] because he doesn't know it, i think i have a competitive advantage. which is just as well, as it's the only way i'll win. :-P [21:10] jcsackett, I always go for the win, whether the opponent knows it or not. :) [21:10] deryck: :-P [21:54] deryck: Hi, have you verified the future scaling performance of your bug search changes? [21:54] wgrant, no, I have not. Are you concerned? [21:54] deryck: Very [21:54] wgrant, and hi, btw. [21:55] The work we did earlier in the year was to *eliminate* joins, but this adds three or four more [21:55] And it's to handle a circumstance that probably shouldn't ever exist [21:55] So it seems like a lot of risk for minimal gain [21:56] wgrant, yeah, I did consider the extra join could cause problems. I was going to be careful in qa and if it looked risky back it out. [21:57] Well, it *is* risky and it *will* cause some problems eventually, but it's difficult to say on qastaging as bug search timeouts there are often dismissed as cold cache [21:57] But I would be extremely wary about making this change [21:58] wgrant, ok, fair points. I wouldn't dismiss timeouts as cold cache, FWIW. I usually look at an OOPS and see what it tells me. And compare to staging oops even. [21:58] The bug search queries were redesigned and tweaked for performance, so making unnecessary changes which quadruple the number of considered tables needs to be considered and tested very carefully [21:59] wgrant, I've been a bit nervous about this change anyway. for that same reason. and stuff I saw in tests had me nervous too. [21:59] wgrant, so I'm fine to just revert for paranoia's sake. [21:59] Why are we search for impossible data? privacy is transitive, you cannot ever have public data in a confidential container. [22:00] well it will be impossible. it's not currently. [22:00] Right, so it sounds like it should be reverted [22:01] I think we can fix the data faster than writing code...I bet it can be run in 2.5 seconds in sql by webops [22:01] yeah, agreed. [22:01] (though we really should have been enforcing the privacy invariants before rolling out the beta, it's pretty easy to fix up later) [22:01] * sinzui would do the same with his current bug if he could workout what the right state is :( [22:01] sinzui: Which bug is this? [22:02] wgrant, https://bugs.launchpad.net/launchpad/+bug/1077351 [22:02] <_mup_> Bug #1077351: SourcePackageRecipeBuild:+index LocationError build

< https://launchpad.net/bugs/1077351 > [22:02] Aha [22:02] I wanted to make the three items be build failed/success, but I need to look for evidence of success [22:02] wgrant, I'm about to go offline for some family stuff. but I'll revert when I get back tonight. [22:03] wgrant, if you get anxious about it, I don't care if you revert it. [22:03] Well, there's some interesting stuff I'd like to deploy this morning, so I might revert it now [22:03] wgrant, sure, feel free. sorry about that. just don't have the time to hang around now. [22:03] np [22:04] later, everyone. === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: ~200 [22:36] whaawmp | 0.2.10.1-py24 | 32517 | 899 [22:36] StevenK: ^^ [22:39] SELECT product.name, milestone.name, productrelease.id, COUNT(*) FROM product JOIN milestone ON milestone.product = product.id JOIN productrelease ON productrelease.milestone = milestone.id JOIN productreleasefile ON productreleasefile.productrelease = productrelease.id GROUP BY product.id, milestone.id, productrelease.id ORDER BY COUNT(*) DESC LIMIT 200; [23:01] good morning [23:02] wgrant, are my qa instructions sane: https://code.launchpad.net/~sinzui/launchpad/publishbinary-without-publications/+merge/134527