[00:00] StevenK: Indeed. I wonder if the removeSecurityProxy is really required, then. [00:04] wgrant: I think without it you get Unauthorized [00:05] StevenK: I'd like that rechecked -- if it's the case, please try to work out why. [00:05] That shouldn't be happening. [00:06] wgrant: http://pastebin.ubuntu.com/899838/ [00:07] StevenK: I speak of lib/lp/bugs/tests/test_bug_mirror_access_triggers.py [00:07] StevenK: There was no removeSecurityProxy, now there is. [00:08] wgrant: Right. I think the rSP() is just so we don't have to make sure we have lp.Edit on the bug by faffing around with with {person,celebrity}_logged_in. [00:08] StevenK: Try removing it. [00:09] From that test. [00:09] Since it wasn't there before. [00:10] wgrant: Hmmm, right, so, I'm wrong. [00:10] wgrant: I guess I added the rSP thinking I was avoiding failures. [00:19] is there a test helper to run a job ? [00:22] "Personal receieved 10590 new messages." [00:23] * StevenK stabs the messaging indicator for lying. [00:24] Machine id 525? When did that happen? [00:24] wgrant: You can kill AMI in 522 [00:33] StevenK: Is gone. [00:34] Now to pester bac [02:14] hmm [02:14] what deletes executed jobs? [02:14] lifeless: So why are you looking at the job system when abentley is rewriting it? [02:15] I'm not [02:15] I'm making sure what I write works with the stuff in play today [02:16] StevenK: also, AIUI the job specific stuff in LP is staying there, so the new system will be DB backed. There may be little changes on that stuff. [02:23] why might launchpad-dependencies not be installable on oneiric currently? [02:25] postgres 9.1 at a guess [02:25] I've not investigated yet [02:26] What does apt say? [02:26] Mornin. [02:28] i think it might be pg 9.1 too [02:28] * mwhudson tries to remember how to drive apt [02:28] apt-get upgrade keeps things back if installing them is only possible by removing packages? [02:29] and the answer is, nothing [02:29] we have 1.7M jobs in our history [02:30] 350K answers jobs created and not pruned [02:30] mwhudson: That's the main cause, yes. [02:30] mwhudson: Try explicitly installing. [02:30] lifeless: Time: 0.72 seconds [02:30] The following packages will be REMOVED: [02:30] postgresql-8.4-slony1 slony1-bin [02:30] lifeless: For a launchpad/+sharing batch on prod. [02:30] wgrant: congrats [02:30] So we can do sub-second. [02:30] Just. [02:31] Has +sharing landed? behind a pref? [02:32] nigelb: We'll hopefully enable it for beta testers early this week. [02:32] It's only on for ~launchpad on prod so far. [02:32] Aww, ok [02:32] I wish I could see on qastaging [02:32] Everyone can see it on qastaging, but only if you're a driver/owner of a project with something shared. [02:33] We can probably fiddle it on qas for a bit so nigelb can have a look. [02:33] It's been on for everyone on qas for weeks :) [02:33] Oh cool. [02:33] I'm seeing it. [02:34] oh [02:34] https://code.djangoproject.com/ticket/17062 [02:34] no [02:34] The following NEW packages will be installed: [02:34] launchpad-database-dependencies-8.4 postgresql-8.4-slony1-2 slony1-2-bin [02:34] so this is a package name change, basically? [02:35] mwhudson: Yup [02:35] mwhudson: New version of slony. [02:35] This is cool. Except hrm, probably slightly confusing. [02:35] And the pg version added to the package name. [02:35] nigelb: Oh? [02:35] cool [02:35] * mwhudson hits Y [02:36] wgrant: Even after reading the help text, it "feels" complicated. Maybe if we have enough explanation when we launch, it should be good. [02:37] nigelb: The UI is RO on production at the moment, and will be for at least a few weeks. [02:37] It'll hopefully become clearer as we rework that UI and integrate the new terminology throughout the site. [02:38] wgrant: Oh, that's cool then. [02:38] nigelb: Just wait until I change the bug UI [02:40] and thus bug 964935 [02:40] <_mup_> Bug #964935: answerpersontransfer/etc jobs are accumulating without bound < https://launchpad.net/bugs/964935 > [02:41] StevenK: woah. [02:42] But that's like two weeks away. I'm dealing with the model and surrounding changes. [02:54] * nigelb looks forward to the changes. [04:32] lifeless: O HAI [04:35] * nigelb pins bigjools to IRC. [04:35] STICK! [04:36] * StevenK hands nigelb a staple gun. [04:37] I disappear once for 10 mins and you want to pin me? [04:37] good lord! [04:38] bigjools: Obviously, nigelb missed you a lot. [04:38] heh [04:43] StevenK, wallyworld_: https://code.launchpad.net/~wgrant/launchpad/bug-962912/+merge/99252 (fixes the duplicate query on +sharing) [04:45] wgrant: Why are you removing lib/lp/services/database/tests/test_decoratedresultset.py ? [04:45] " Drop test_decoratedresultset. It's just a wrapper around a doctest that's already run by test_doc. [04:45] " [04:45] wgrant: great. i'd also update the accesspolicy tests to decrement the query count by one [04:45] I feel loved [04:45] bigjools: fuck off [04:46] wallyworld_: This is why I generally use Equals for my query count tests. [04:46] I knew I could count on wallyworld_ [04:46] wallyworld_: Otherwise someone else will halve the page's query count, and then the other optimisations can regress without anyone noticing :/ [04:46] wgrant: doesn't work here. the product view uses one or 2 more queries [04:46] so less than is better [04:46] Ah, probably the session thing. [04:47] the commercial subscription thing [04:47] The first request in a new process will issue an extra query to get the session secret. [04:47] Ah [04:47] That suggests you're not invalidating caches properly. [04:47] * StevenK stabs buildbot again. [04:47] But anyway. [04:47] wgrant: no, the product view does indeed use one more query [04:47] i use a helper method for both cases [04:48] Oh, right. [04:48] i guess i could have passed in the expected count [04:48] but i like lessthan because it's more robust [04:49] but does need updating if we reduce the query count, that's true [04:56] wallyworld_: I wonder if we should inhibit the rough_length EXPLAIN, since we're not showing total size in the UI at all. [04:56] Did you look at that? [04:57] Also, can one of you please approve my MP? :) [04:58] I thought wallyworld_ was reviewing. [04:58] StevenK: i will but have to pick up the kid from school first [04:59] Whee, memcache._ConnectionDeadError on ec2 too [05:00] StevenK: Yeah, saw that twice last week. [05:00] See my email to launchpad-dev. [05:00] I might revert the python-memcached upgrade. [05:00] I'm actually not sure if that alone is enough to fail buildbot. [05:01] I believe it is for ec2, but I don't think I've ever seen buildbot fail just on that. [05:01] So it's possible it's happening more often than we see. [05:01] wgrant: See the last db-devel failure -- it looked like just it failing. [05:02] StevenK: There was a rabbitmq failure up the top IIRC [05:02] Yeah [05:02] File "/srv/buildbot/slaves/launchpad/lucid-db-devel/build/orig_sourcecode/eggs/rabbitfixture-0.3.2-py2.6.egg/rabbitfixture/server.py", line 260, in check_running [05:02] raise Exception("RabbitMQ server is not running.") [05:02] Exception: RabbitMQ server is not running. [05:03] Ah [05:31] Bah, testr needs a way to pass options to the test command it runs. === almaisan-away is now known as al-maisan [05:39] wgrant: the doctest change doesn't really appear to test bot result sets, or? [05:41] eparse [05:41] wallyworld_: ^^ [05:41] I think he means 'both' [05:41] wgrant: the doc test have been changed but it doesn't appear to test any of the next stuff [05:42] wallyworld_: The doctest tests DecoratedResultSet [05:42] Not StormRangeFactory. [05:43] sure, but we are changing rs.config and the doctest invokes that [05:43] so it should be tested [05:43] in the doc test [05:43] Confused [05:43] What's not tested? [05:43] calling config with return_both = true causes both rs to be returned [05:44] And return_both = False is the default. [05:44] So it's tested throughout the rest of the file. [05:44] It seems not particularly valuable to test that explicitly, but I guess I could.; [05:45] but the doc test explicitly makes a config call with return_both=true and then doesn't test anything related to that [05:45] it tests the same thing as if return_both = false [05:45] Huh? [05:45] so it's not really testing the new expected behaviour [05:45] Look at the results of the iteration. [05:45] It's returning both. [05:46] (.config doesn't copy -- it changes in place and returns self) [05:46] ah, right, i think i get it. it's hard to tell from a few lines of diff [05:47] Indeed. You can see what the decorated output is like in the context at the top of that hunk. [05:47] The decorator returns "Dist name is: %s" % result.name. [05:48] right. clear now. [05:51] wallyworld_: Thanks. [05:51] np. sorry for confusion [05:51] np [05:52] wonder how much benefit it will have [05:52] 600ms for Ubuntu [05:52] 20ms for everyone else. [05:52] what was the time for ubuntu before mod? [05:52] 1.2s [05:52] Maybe 1.3s [05:52] we it's now 1/2 [05:52] It's roughly halving it, anyway. [05:53] yeah, cool [05:53] might make it to qas before tomorrow if bb plays nice [05:53] bb is currently running [05:53] for how long before erroneous error [05:54] Do not say that. [05:55] Does anybody have a good reason for me to not revert the python-memcached upgrade? [05:56] wgrant: Doeet [05:56] (As in, do the revert.) [05:58] StevenK: hi [05:59] wallyworld_: you can use Or(Equals(1), Equals(2)) [05:59] wallyworld_: or you could write a simple Between(1,2) [06:00] wgrant: ^ [06:00] lifeless: ECONTEXT [06:00] wallyworld_: LessThan vs Equals [06:00] wallyworld_: you're not limited to simple comparators [06:00] lifeless: Can you set launchpad-security as the bug supervisor and security contact on the auditor project? [06:00] sure. you can't ? [06:00] lifeless: handy. good to know [06:01] StevenK: also have set the answers option to lp [06:01] lifeless: pretty happy to write a test with query count < 6 where some of those are updating session data etc [06:01] lifeless: I can not, no, since I'm not an admin of -security. [06:02] wallyworld_: That's only because the caches are not invalidated. [06:02] wallyworld_: AFAICS [06:02] wallyworld_: I've no objection, I was merely noting an oversight in your 'cannot use Equals' conversation [06:02] sure, np [06:02] lifeless: so you had a car accident yet with the new road rules? [06:03] nope [06:03] i bet a few people do though [06:03] perhaps [06:03] should have less in the long run or thats the theory [06:05] well, it's only tourists i guess who would have been caught out [06:05] """Backport of Python 2.6 logging handlers. [06:05] Hmmm [06:05] I wonder if that can be dropped now. [06:07] StevenK: (thats done) [06:07] lifeless: Thanks. === al-maisan is now known as almaisan-away [07:58] good morning === almaisan-away is now known as al-maisan [08:55] hello [08:56] I updated my MP over the weekend: https://code.launchpad.net/~jml/lazr.restfulclient/multiple-instance-safe/+merge/98873 [08:57] wgrant: IIRC, it can. === jam1 is now known as jam [09:04] jml: It's in EC2 now, so we'll see. [09:24] loggerhead :( [09:38] jml: What about it? [09:38] it was 503ing before [09:38] jml: crowberry's Apache has been collapsing a bit the last couple of hours. [09:38] loggerhead is not the problem here, for once. [09:43] hurrah [09:43] FSVO === jam3 is now known as jam === al-maisan is now known as almaisan-away === mabac_ is now known as mabac === almaisan-away is now known as al-maisan === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugtasks: 4*10 [12:27] jelmer: Heh, thanks, was about to do that myself. [12:27] It's caused us some problems before. [12:29] wgrant: :) [12:29] wgrant: the buildbot plugin for bzr is also using a few API calls that cause unnecessary traffic [12:29] (and slowness) [12:29] jelmer: See carob:~wgrant/shadowrobot for logs [12:30] thanks [13:02] Morning, all. [13:10] abentley: could you have a look at this MP: https://code.launchpad.net/~adeuring/lazr.jobrunner/early-reference-to-job.fail-test/+merge/99312 ? [13:11] adeuring: sure. [13:11] thanks [13:17] adeuring: r=me. [13:17] abentley: thanks === rick_h_ is now known as rick_h [14:03] hey all; getting https://lp-oops.canonical.com/?oopsid=ae5111a6e4ae33b1e2c60a6dc72164e7 when trying to search for a person/team in the bug assignee dialog [14:08] wallyworld_, go to sleep [14:11] sinzui: wallyworld_ never sleeps. [14:11] neither does lifeless wgrant or sinzui or StevenK [14:11] :) [14:11] czajkowski: putting aside lifeless, that's everyone else on my team. [14:12] i'm the only one that sleeps...no wonder i question if our team has a full ration of sanity. :-P [14:12] hah [14:13] jcsackett, I can lp-land branches for people; they do not need to stay up waiting for the review [14:16] benji, do you have time to review https://code.launchpad.net/~sinzui/launchpad/front-page-layout/+merge/99121 ? It has pictures [14:16] sinzui: I concur; certainly there's no need for wallyworld_ to stay up. But he always seems to. :-P [14:16] sinzui: well, if it has pictures how can I refuse? [14:17] sinzui: can you have a quick look at something for me [14:17] lp:sharing-picker-title-959417 [14:18] wallyworld_, yes [14:18] in _display_step_two(data) the click callback refuses to use the latest value of data passed to the function [14:19] so there's a scoping issue i can't quite solve [14:19] oh dear [14:19] it always uses the value passed in when the function is first invoked [14:19] * sinzui nods [14:19] it's for bug 965197 [14:19] <_mup_> Bug #965197: sharee picker always uses first selected person < https://launchpad.net/bugs/965197 > [14:20] the click callback is the delegated one for .next [14:20] thanks in advance [14:21] * wallyworld_ off to bed [14:21] * wallyworld_ doesn't like javascript today [14:24] czajkowski, the the notes on the whiteboard were generated by Lp when the user set and OTHER license. The i don't know are a problem because they are not open source. We would disable them after 6 months if there was an automated way to do it [14:25] czajkowski, some of the messages you are seeing shows that the user was trying other opensource, then read the rules in the email and selected a different type of license [14:26] czajkowski, so no human left a not on the board...we leave out names. [14:26] sinzui: ahh right re the mail I sent [14:26] sinzui: well assumed it's you as you do a lot of the liceince reviews. [14:26] czajkowski, When you see such a note and a proper license, the user understood the instruction in the email and fixed the license [14:27] I only review other/open source and proprietary [14:27] ok [14:27] cheers [14:28] most I don't knows will fail on their own. they are not worth anyone's time to fix the license. We only care about them also being used for spam [14:28] ok, sinzui: I've looked at the pretty pictures. [14:30] thank you benji [14:30] any time === al-maisan is now known as almaisan-away [15:00] benji, hi there. if you have some time today, I could do with a review on https://code.launchpad.net/~linaro-infrastructure/launchpad/team-engineering-view/+merge/99342 :) [15:00] salgado: sure [15:08] deryck: got a sec to do a quick pre-impl? [15:10] rick_h, on call now, ping when free [15:10] deryck: k === matsubara is now known as matsubara-lunch [15:35] adeuring: I've pushed the updates to download-cache. Sorry for the delay. [15:42] rick_h, I can chat now. let me start a hang out. [15:43] rick_h, https://plus.google.com/hangouts/extras/talk.google.com/go-for-deryck [15:48] deryck: love the url! [16:03] czajkowski, :) [16:03] deryck: thanks for covering tomorrow as well [16:05] czajkowski, yeah, no problem at all. === deryck is now known as deryck[lunch] [16:27] hi folks, how can I request that a project (and all its bugs) become private? [16:31] cr3: what is the project? [16:32] czajkowski: hw-labs [16:33] cr3: made bugs private [16:33] as for making the project private hmm [16:34] sinzui: is it possible to make the project private I dont seem to be able to do that, or is making the bugs private enough [16:35] czajkowski: yeah, we noticed that checkbox after asking the question but we'll see if the project as a whole could also be marked as private === matsubara-lunch is now known as matsubara [16:35] I suspect it's something webops will have to do [16:39] czajkowski, there is no such thing as a private project [16:39] hmm [16:40] cr3: ^^ [16:40] cr3, as the maintainer of a project with a commercial subscription, you can configure the bug tracker to have private-by-default bugs. all new bugs will be private [16:42] cr3, I can give /checkbox a commercial subscription, then you can enable private bugs [16:43] sinzui: this is for the /hw-labs project though, not /checkbox. however, we'd like the project as a whole private if possible [16:44] cr3, as I said, no such thing [16:45] I have been working the private projects for 22 months. and we are still 6 months away from saying a project can be private [16:45] sinzui: ah, misssed that part. thanks! [16:45] czajkowski: I guess we're all good with private bugs then, thanks! [16:46] cr3, the project already has a commercial subscription...the maintain can enable private bugs [16:46] sinzui: yeah, czajkowski helped with that. I was under the impression that the project as a whole could be private though, all clear now. [16:46] okay [16:47] sinzui: cheers === salgado is now known as salgado-lunch === deryck[lunch] is now known as deryck [17:18] deryck: Would you like to review a very short lazr.jobrunner branch? https://code.launchpad.net/~abentley/lazr.jobrunner/fix-celeryd-tests/+merge/99378 [17:19] abentley, sure. [17:21] abentley, easy peasy that one. :) r=me. [17:21] deryck: Thanks. [17:21] np! === salgado-lunch is now known as salgado [17:40] benji, would you be able to land that branch for me? I think I remember last time your VM was not setup to run ec2-land or something so I thought I'd check [17:41] salgado: sure (I've gotten it straightened out since then) [17:41] oh, cool. thanks! === almaisan-away is now known as al-maisan [17:50] abentley: thanks (no problem with the delay) [17:50] adeuring: I've also landed a fix for those test failures. [17:50] abentley: cool === al-maisan is now known as almaisan-away [18:08] salgado: hi [18:08] hi lifeless [18:08] salgado: I've just commented on your MP, I thought I'd ping you here to make sure you understand the comment ;) [18:09] benji: you may want to see that comment too - its a mis-pattern to watch for with storm use [18:10] * benji looks. [18:10] this is the culprit I'm referring to: [18:10] + results = store.using(*origin).find( [18:10] + (WorkItem, Milestone, Specification, Person, Product, [18:10] + Distribution), [18:11] a milestone with 10 workitems, each with different assignees, and the spec with an 11th assignee, will return 20 rows [18:12] and you'd parse and update storm metadata for the same distro or product 20 times, for the spec assignee 10 times, for the spec 20 times, for the milestone 20 times, for the workitem twice per workitem. [18:13] if the workitems had the same person a lot, which is much more common, the redundant work level will increase [18:16] benji: salgado: do you see why this happens? [18:17] lifeless: yep; it's not pretty [18:18] salgado: I'm going to kill the landing, if you don't object [18:19] lifeless, I don't understand why in that scenario it'd return 20 rows [18:19] because of the coalesce on person [18:19] salgado: even without that its still an exmaple of the anti pattenr [18:20] salgado: DecoratedResultSet is designed for this - the pre_iter_hook can bulk load all the related objects, at one query per *type*, the collection is still slicable and still looks like it returns just Workitems, or whatever. [18:20] salgado: the issue is that sql flattens a graph to a table, which leads to redundancy, the more types you include in the result, the higher the waste [18:21] if it was nearly free to parse and assemble storm objects, it wouldn't matter, but its not. [18:22] lifeless, ok, I can use a pre_iter_hook, but I'm curious as to how the coalesce on person does that? [18:25] the coalesce increases, its not the only cause [18:25] it says 'make a row for person where milestone.foo or spec.foo' [18:25] bah workitem [18:26] I understood it's not the only cause [18:26] if the workitem person and the spec person are different, you'll get two rows, one with the workitem person and one with the spec person [18:26] all the other fields will be identical [18:26] brb [18:27] actually, I'm wrong about the coalesce [18:27] the rest I'm right on :) [18:27] thje coalesce will pick just one. Fuzzy morning thinking. [18:27] ok, I understand what the issue is with storm, but the coalesce didn't make sense so I thought I was missing something [18:28] yeah, you're spot on :) [18:28] I was nutty there [18:39] benji: so yes, stopping the landing would be good; or salgado could do a follow up branch - I'm happy either way. [18:39] just kill it and I'll fix it on this same branch [18:40] 'E's expired and gone to meet 'is maker! [19:09] deryck: The cross-format stacked branches bug #828409 won't be fixed until the RT has been performed. [19:10] <_mup_> Bug #828409: cross-format stacked branches can't be accessed < https://launchpad.net/bugs/828409 > [19:10] deryck: We're not fixing the bug by changing code, we're fixing it by ensuring there are no cross-format stacked branches. [19:19] flacoste: I can talk anytime that suites [19:19] s/e// [19:27] 984758 [19:29] abentley, ok, cool. So I'll move the card all the way to done done for us. since we're done coding.... [19:29] abentley, and do you mind commenting that the bug will be fixed with RT #XXX in the bug itself? [19:30] deryck: sure. [19:31] abentley, thanks! [19:39] flacoste: inviting you back in [19:39] flacoste: modem crashed AFAICT === jml_ is now known as jml [20:24] hi all [20:25] lifeless, does http://paste.ubuntu.com/901105/ look ok to you? [20:25] hi poolie! [20:27] morning poolie [20:28] salgado: nice [20:28] salgado: I think you can change your origin list now [20:28] salgado: as you're not constraining by Person etc [20:28] salgado: IMBW [20:28] lifeless, I am: Person.id.is_in(self.participant_ids) [20:29] salgado: uhm, where is that MP again, so I can get more context? [20:29] I can get rid of Product/Distribution from there, though [20:29] lifeless, https://code.launchpad.net/~linaro-infrastructure/launchpad/team-engineering-view/+merge/99342 [20:30] now my origin joins only Specification, Person and Milestone [20:30] salgado: this is in getAssignedSpecificationWorkItemsDueBefore ? [20:30] yes [20:31] yeah, you don't need Person :) [20:32] Or(WorkItem.assignee_id.is_in(self.participant_ids), Specification.assigneeID.is_in(self.participant_ids)) [20:32] would be an exact translation [20:32] oh, indeed [20:33] it may be that you want just WorkItem.assignee_id.is_in(self.participant_ids) though [20:33] no, that's not what I want [20:35] [I wouldn't know :P] [20:36] so, milestone workitem and specification are the tables you need [20:37] yep, and those are all I have in origin now :) [20:37] cool [20:37] you can inner join to workitem [20:37] because you are returning the workitems, a NULL workitem won't be useful for you [20:43] lifeless, how can that return a NULL workitem, though, if that's the only thing I'm selecting on? [20:43] you're selecting on milestone & workitem|spec person [20:44] ah, I may have misread, one sec [20:45] you have workitem join spec, coalesce join milestone [20:45] so its all inner [20:45] cool, ignore me :) [20:45] * lifeless puts that on hotkey [20:46] haha [21:26] StevenK: have you added any more types to enterpriseid ? === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10 [22:01] lifeless: Not yet. [22:02] cool [22:03] jcsackett, mumble? [22:03] sinzui: having a little trouble getting it to launch. [22:03] be there in a moment. [22:20] lifeless: Except that fixtures.TempDir doesn't support that. [22:20]