[01:22] who is around [01:23] You want a roll call? [01:23] hmm, wgrant - hey, so - do we track enough detail to determine how often contact-this-team is used; by admins, by members, by non-members ? [01:23] StevenK: no, I wanted a victim [01:30] lifeless: Yes. [01:31] lifeless: The abuse:realuse ratio is roughly infinity, I believe. [01:33] if we can get a little data on that [01:34] I will happily drive a sharp scope reduction on it [01:38] my personal view is that it often shows up high in the UI, so if you're looking for help, then it's THE most obvious place folks see and hence "it's up here, must be important". I'd suggest just dropping it down the UI below lists or something and see what happens. [01:38] Hm [01:38] AJAX batchnaving probably shouldn't calculate the total every time. [01:43] wgrant: why not? [01:44] Because it's pointless? [01:44] batch lengths are dynamic [01:44] some collections more so than others [01:45] And their accuracy is probably not particularly critical. I'm not sure the client even respects it if it changes. [01:46] mmm, if a collection zeros out, it will get a bug report if we don't update it [01:46] I'm fairly sure gmail updates theirs, for instance. [01:46] Lets not paint ourselves into a corner either way. [01:46] lifeless: Oh sure, because gmail does it is a reason we should? [01:46] also, how to stop users reporting bugs [01:46] StevenK: gmail is a paginated ajax app with years of experience dealing with users and user expectations. [01:47] StevenK: observing what it does is merely one data source we should use. Not using it would be foolish. [01:47] lifeless: You hit a nerve. [01:48] StevenK: tl;dr - yes, because gmail does it *is* /a/ reason we should do it, transitively, because they also are trying to keep support costs down and user satisfaction up [01:48] StevenK: Did I now? I didn't mean to. Whats the nerve? [01:50] wallyworld_: O HAI [01:50] hello [01:51] anyhow, we know that few people click next anyhow [01:51] so optimising next() to be faster than first-load is less interesting than making first load faster [01:51] wallyworld_: I know Friday was a long time ago, but: http://pastebin.ubuntu.com/956524/ [01:51] lifeless: It's more the sorting that I'm hitting it on. [01:51] wgrant: count() doesn't sort though, does it ? [01:52] lifeless: No, but changing the sort order of a bug listing does an AJAX request for the new batch, which also returns the count. [01:52] So rather than 10ms of DB queries there's lotsams. [01:52] buglistings are a bit weird anyhow, not being an API call and all [01:52] AJAX batchnavs aren't API calls in general, are they? [01:53] Only the pickers are. [01:53] FIIK [01:53] I would like them to be [01:53] * lifeless dreams [01:53] But ++model++ is awesome layering-violation goodness :) [01:54] anyhow, the bugs batchnav currently caches too much anyhow, so if the count isn't updating, thats something we can poke deryck to fix at the same time ;) [01:55] Dammit mawson, vacuum faster [01:55] StevenK: looks good. i would use with FeatureFixture to avoid the separate cleaup call [01:56] you can also use self.useFixture(..) to avoid cleanup calls. [01:57] Not in a doctest I can't. [01:57] ALso 'with FeatureFixture' [01:57] spelt as f = self.useFixture(MyFixture()) [01:57] I knew what he meant, so meh. [01:57] hmm, i thought I or someone else had added cleanups support to doctests. [01:57] wallyworld_: Right, changed to 'with', commiting and pushing [01:57] StevenK: awesome thanks. happy landing [01:59] wgrant: Finally got around to loading up AA last night. Looks like I have to wait, since 1080p causes my 9500GT to melt. [01:59] lifeless: perhaps. most/all other doctests seem to still use 'with ...' [01:59] Kill all doctests :) [02:00] Agreed. [02:00] I should kill bug-change.txt and merge it into test_bugchanges.py [02:01] some doc tests are good though [02:02] wallyworld_: LIES [02:02] the ones which are, you know, api documentation are ok [02:03] That's a slippery slope. [02:04] Some would argue so was adding doctests. [02:19] lifeless: You might want to rephrase that self-notification thing to not be stupid [02:20] lifeless: Currently it complains that the feature to disable bug self-notifications doesn't disable answer notifications, which is clearly an invalid complaint. [02:20] Perhaps it wants the feature to be extended to all notifications. [02:30] perhaps; arguably though, a comment on a bug with that option set should not result in a notification [02:31] the fact we have naive pub-sub based notifications isn't their problem [02:38] wgrant: Is there anything stopping us jumping to rabbit 2.7.1? [02:39] No. [02:39] hippity hop [02:39] My precise laptop has rabbit held at 2.6.1, and apt keeps yelling at me. [02:40] Ah, yeah, I should fix that. Might just drop -management for now, since we're not using it yet [02:50] wgrant: Did you want my help, or you need to sit down and JFDI? [02:51] I'll hopefully get to it today. [02:52] * StevenK tries to figure out how to package auditor up as an egg [02:52] woo auditor woo [02:52] Yeah, I know it's been a few weeks [02:53] Sigh [02:54] This web page talks about the 3 python files with django projects and then skips straight into setup.py? [03:53] lifeless: Do you happen to know if the row length quoted by VACUUM FULL VERBOSE includes the tuple header? [04:01] no [04:01] also more freaking init discussions on d-d. Sob. [04:01] Oh yeah [04:01] Glanced over that this morning and decided I didn't care any more :) [04:15] * StevenK stabs apt on his laptop more. [04:16] The Partial Upgrade message from upgrade-manager is getting tiresome. [04:42] StevenK: https://code.launchpad.net/~wgrant/meta-lp-deps/no-rabbitmq-management/+merge/104055 [04:42] http://somethingofthatilk.com/index.php?id=407 <== wgrant [04:43] 1 guess for where I see you in that panel [04:43] Heh [04:43] That tends to work well for Launchpad, though :) [04:43] why do you think I posted it in *this* channel :-D [04:44] wgrant: r=me [04:44] lifeless: Can we upgrade to postgres 9.1 tonight? :) [04:44] Haha [04:44] StevenK: Thanks. [04:45] wgrant: Does that fix the 2.6.1 madness or is there another step? [04:45] That should be that. [04:45] spm: also hah - http://i.imgur.com/VC9Ye.png [04:45] That's terrible [04:45] wgrant: up to stub really; oops report looks decent enough [04:46] heh [04:46] I'd have no concerns about pulling the trigger if mthaddon is happy [04:46] What about DF? [04:46] what about tit? [04:46] Or do we just blow up the DB, get GSA to fiddle packages and then wait 48 hours for an import? [04:46] you can up grade whenever you like [04:46] mm tit [04:47] StevenK: I intend to refresh DF this weekend anyway [04:47] StevenK: combine with restore from prod [04:47] So I plan to upgrade to postgres 9.1 at the same time [04:47] Hopefully part of prod is done before then. [04:47] I usually refresh when ubuntu is released [04:48] I considered doing it on Saturday, but we basically need to do it for 9.1 anyway, so might as well wait [05:08] In place upgrade is fine too, which will take maybe 30 mins on that hardware plus fiddling time getting postgresql.conf, pg_hba.conf etc. sorted [05:54] StevenK: r-d-b should have sotred out rabbitmq for you [05:55] wgrant: I fixed it about 30 seconds after the meta package was published. :-) [05:55] Heh === jtv1 is now known as jtv [06:47] wallyworld: Your headers branch has hit qas. [06:48] wallyworld: If you start syncing the staging mailbox right now you should be able to QA the branch on Wednesday morning? :-) [07:04] StevenK: :-P [07:46] wgrant: the API is supposed to return a 401 when it requires authorization. strikes me as fairly buggy returning an empty set but a non-zero count [07:48] alexh: For collections it simply omits the inaccessible items, like a normal search. In this case it's probably a bug that the activity of a public bug requires authentication, but the non-zero count is not a bug. [07:48] Counting is very expensive; it is not necessarily correct. [07:49] wgrant: also not sure why that requires authentication, attachments, etc, do show up [07:49] As I said, probably a bug. [07:49] oh, ok [07:49] But in general, inaccessible items in collections are just hidden. [07:49] wgrant: thanks, I'll give it a try after authenticating [07:49] Oterhwise pretty much everything would 401 :) [08:14] aloha [08:21] hm, also struggling with the auth, [08:21] "The information provided by the remote application was incorrect or incomplete. Because of that we were unable to identify the application which would access Launchpad on your behalf. " [08:21] when visiting the authorize-token page [08:22] I'm sending oauth_consumer_key and oauth_signature{,_method} [08:22] (and I do get an oauth_token back) [08:23] alexh: Which oauth library are you using? [08:24] none so far, just a regular HTTP post to get the token in the first place [08:24] following https://help.launchpad.net/API/SigningRequests [08:24] alexh: Any reason not to use launchpadlib? [08:25] Which does all this for you? [08:25] I'm using ruby, not python [08:25] Ah [08:25] What is the URL you're using for authorize-token? [08:26] https://launchpad.net/+authorize-token?oauth_token=MVlGSWMKbZ6GhsBQwV5H [08:26] MVl... being the oauth_token I get back from POSTing to https://launchpad.net/+request-token === almaisan-away is now known as al-maisan [08:32] meh, pebkac [08:32] heh, what was the issue? [08:33] Just tried it manually, works for me. [08:33] doing GET instead of POST [08:33] sorry [08:33] yea, now that works [08:33] Great. === al-maisan is now known as almaisan-away [10:06] wgrant: you were right, it was indeed missing authentication [10:41] rvba: just checking, is your testtools "ContainsAll" equivalent to a (probably hypothetical) "IsSubset"? [10:43] jml: it is indeed. [10:43] rvba: ta, will get to the review shortly. [10:43] Cool. [11:14] oh wait, it's not [11:18] jml: why? We're using it on strings so IsSubSet would sounds strange but conceptually it is rather similar. [11:20] I'm typing it out in the MP, but I would have guessed from the name & the docstring that self.assertThat(X, ContainsAll(Y)) would mean that Y is a subset of X. [11:20] However, it apparently means: for x in X, for all y in Y, y in x [11:21] meep [11:21] that is indeed surprising [11:22] isn't that MatchesAll(Contains(Y)) ? [11:22] hmm, MatchesListwise(Contains(Y)) [11:22] MatchesAll(*map(Contains, Y)) [11:24] jml: All? *blink*, well you've read the code. [11:24] matchers could probably use a little more algebra [11:24] https://code.launchpad.net/~rvb/testtools/testtools-contains-all/+merge/104065 [11:25] I'll read tomorrow, if I should [11:25] for now, -> sleep [11:25] :D [11:27] MatchesAll should really be called And or something :\ [11:27] rvba: http://pastebin.ubuntu.com/957278/ in case you missed it. [11:28] jml: thanks. I was disconnected indeed. [11:46] jml: now it's my turn to be confused by your review. "self.assertThat([1, 2, 3], ContainsAll([3, 1]))" is exactly what this matcher does. [11:46] jml: and the tests prove that. [11:50] rvba: hmm. [11:50] Maybe the fact that I've written the tests with strings (instead of lists of ints) is confusing. [11:55] rvba: hmm, yeah, that and the way the matcher interface tests work [11:55] rvba: the problem was that I read this: [11:55] + matches_matches = ['foobar', 'foozbar', 'bar foo'] [11:55] as this: [11:55] + matches_matches = [['foobar', 'foozbar', 'bar foo']] [11:55] I see. [11:56] rvba: ok. sorry for the confusion. [11:57] jml: That's funny because I see testtools as a (really nice) was to have nice tests… and the way testtools tests itself is not really clear ;). I was myself confused by this matcher interface thingy. [11:57] Maybe that's a chicken and egg problem :) [11:58] rvba: yeah. sorry about that. [11:58] rvba: in this case, no. [11:59] jml: that's all right. As the creator/maintainer of testtools, you've earned my gratitude ;). I'm a happy user. [11:59] rvba: I think the matcher interface tests are one of the things that make perfect sense once you've figured them out. could probably be made a bit more approachable. [11:59] Right. [12:00] There is quite a bit of code which uses it so it's easy enough to understand how it works though. [12:01] crap crap crap [12:01] late for something. [12:01] brb [14:11] rvba: back. and have replied. [14:13] jml: ta. I'll fix the code as you suggest. [14:13] rvba: thanks. [14:34] jcsackett, Do you have time to review https://code.launchpad.net/~sinzui/launchpad/progressive-enhancement-ftw-2/+merge/103970 [14:35] jcsackett, I am waiting for allergy medication to work. I do feel very useful at the moment [14:43] jcsackett: ello ello [14:43] sinzui: oh hope you feel better [14:44] czajkowski, I am going to write something for the blog today. Danhg and yourself and ensure it makes sense [14:44] danhg is off but I can look over it [15:12] czajkowski: hello. :-) [15:12] sinzui: sure, i can review. [15:12] ...and he signs off just before that makes it through. [15:34] sinzui: r=me on that branch. [15:35] thank you [16:24] I'm working on bug 990219 and could use some advice on security. I think it would be reasonable for build scores to be editable only by launchpad-buildd-admins (an existing celebrity), rather than allowing the owner of a packageset to give themselves arbitrary bonuses (since build scores arbitrate access to a global resource, while packagesets are more local than that). Is the right way to do this to create a new ... [16:24] <_mup_> Bug #990219: Reprioritize package build scores based on packageset

< https://launchpad.net/bugs/990219 > [16:24] ... interface that just has the score setter in it, and add a new class for that in security.py? [16:25] IPackagesetBuild or something === deryck is now known as deryck[lunch] [16:54] Or should I be using some specialised permission like launchpad.Moderate or something for that instead? === matsubara is now known as matsubara-lunch [17:13] cjwatson, We want to normalise the check to a permission like launchpad.Moderate or launchpad.Admin where we check for membership/identity of the celebrity [17:14] cjwatson, We have had trouble with this in the past when the object/interface has many users working with it. I do not think that is the case here [17:15] The thing I'm unsure about is that this is a permission applied to only one member of Packageset; most of the other members want to work with the packageset owner [17:15] I'm not clear on how best to express this [17:15] yes, this does get tricky [17:15] I suppose it could be launchpad.Admin since that's currently unused for Packageset, but it seems like a hack [17:17] cjwatson, maybe not. Does this celebrity have more knowledge and and skill than a member of Launchpad Admin? [17:18] Yes, this celebrity consists of people at the coal-face of running buildds [17:18] There are several permission in security.py where membership in one of several teams suffices, and we might think of ~registry as equivalent as ~admin for example? [17:18] Oh, that wasn't what I meant [17:19] AdminByBuilddAdmin already exists, that much is fine [17:19] What I meant was is that it seems like a hack to use launchpad.Admin on IPackageset to control access to setting score, because at some point somebody might want to use launchpad.Admin on IPackageset for something more central to its functionality [17:19] Or at least something with different requirements [17:20] I see [17:20] So I was wondering if I ought to break out a separate interface for this, and if there are any similar patterns elsewhere I could look to [17:21] Maybe I'm just borrowing trouble and should apply YAGNI? [17:22] cjwatson, I do not see .Moderate used and I think that is appropriate if the celeb has limited control of some properties [17:22] OK, thanks, I'm happy with that === deryck[lunch] is now known as deryck === matsubara-lunch is now known as matsubara [18:35] abentley: ping, can I borrow some eyeballs for a sec? [18:35] rick_h_: sure. [18:35] abentley: http://paste.mitechie.com/show/653/ [18:36] abentley: so trying to move tests from doctest to unit tests and moving this exception to assertRaises, but it's still blwoing up the test and I can't see why here [18:37] rick_h_: That's surprising. [18:37] ok, just wondering if I've got a case of the Monday's and I'm blind to something [18:38] rick_h_: An alternative way to express this is testtools.testcase.ExpectedException. It's a ContextManager, so you can write the code a bit more naturally. [18:38] ah ok, I tried to use the unittest context mgr but it's py2.7 only [18:38] I'll check that out, thanks [18:39] rick_h_: e.g. http://pastebin.ubuntu.com/958176/ [18:41] abentley: awesome, that passed [18:41] rick_h_: So the thing is that Unauthorized is generated by attempts to *access* transitionToStatus, not by attempts to *execute* it. [18:42] ic, so maybe the unittest assertion is wired a bit wrongly to catch that case [18:42] rick_h_: Yes. [18:42] abentley: very cool, thanks again. Headache averted wahoo! [18:43] rick_h_: Or you can pass in getattr as the callee. E.g. assertRaises(Unauthorized, getattr, upstream_task, "transitionToStatus") [18:44] ah, gotcha. That shows it a bit better. Makes more sense. [18:47] rick_h_: Although I think it would be far more intuitive, zope.security doesn't provide a way to defend against execution, which is why the restrictions on methods are actually permissions on accessing the methods. === matsubara is now known as matsubara-afk [22:21] sinzui: hey, got a few minutes to chat about contact this user ? [22:22] lifeless: We are on our stand up, feel free to join. [22:23] ok, though I don't want to chew up all your times [22:23] bah, plurals hard [22:25] wallyworld_, I cannot think, but I recall the examples in this page was not good enough: maybe You can make this work for staging inbox for date range: http://stackoverflow.com/questions/3180891/imap-deleting-messages [22:26] thanks, will look [22:43] pause@! [22:43] I have no mumble [22:58] * StevenK stabs buildout [22:58] It's been running for eight minutes with no output. [23:01] wgrant: The privacy portlet contains the code for changing the background colour of ... well, any privacy portlet. [23:01] Sigh, privacy javascript [23:02] StevenK: That should all die. [23:02] It's not used any more. [23:04] wgrant: Do you think it's worth writing a test for, or just rip it out and see that nothing breaks? [23:04] Oh, look at that. buildout now takes twelve minutes. :-( [23:24] * StevenK attempts to get wgrant's attention again. [23:25] StevenK: Writing a test for the absence of some code is silly. [23:25] YOu must have a nice CPU, if a fresh buildout only takes 12 minutes [23:26] wgrant: I upgraded to Precise yesterday afternoon, still watching for issues. That could be one. [23:27] The only on-going issue is that gnome-do has broken into tiny pieces. [23:29] StevenK: Oh, that'll probably mean you're building with 2.7 now, if you weren't already. [23:29] Ah ha [23:30] yay 429 is official [23:30] lifeless: Hm? [23:30] http://www.rfc-editor.org/rfc/rfc6585.txt [23:31] The loss of gnome-do is affecting my muscle memory :-( [23:32] lifeless: Ah, finally. [23:44] wallyworld_: Due to wgrant being a little preoccupied, do you want to quickly review https://code.launchpad.net/~stevenk/launchpad/privacy-portlet-colour-change/+merge/104188 ? [23:44] StevenK: sure. === wgrant changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: wgrant | Firefighting: - | Critical bugs: 3.47*10^2 [23:44] wallyworld_: Thanks [23:44] StevenK: do you recall, on qas the bug notification scripts are now run via cron right? [23:45] wallyworld_: I don't, I'm afraid. [23:46] StevenK: do we know why the recent privacy portlet changes triggered this bug? were we not calling hide_privacy_notification() before? [23:48] wallyworld_: It does call it. [23:49] StevenK: so why is the issue showing up now and not before the info type ui changes? [23:49] I seem to recall jcsackett being involved in turning that off, but I'm not certain what he did. [23:51] StevenK: np. i just wanted to be extra cautious deleting code we were not 100% sure of [23:52] wallyworld_: wgrant is certain it should die, at least. [23:53] wallyworld_, StevenK: That code dates from back when the privacy banner was hideable. [23:53] You could click X on it and it would hide, and turn the privacy portlet red instead. [23:53] That went away when hiding was disabled, but the code was never removed. [23:53] However. [23:53] We should track down why this is only showing up now. [23:56] wgrant: Ah ha. [23:56] The old privacy switching code doesn't have that bug. [23:56] wgrant: The hide JS looks for .portlet.private, and the legacy code changes the portlet class to public before calling that hide code. [23:56] StevenK: ok. r=me [23:56] Ah [23:56] Erm. [23:56] Wut? [23:57] wgrant: var privacy_portlet = Y.one('.portlet.private'); [23:57] wgrant: That's in the privacy JS [23:57] I was wuting at the message from wallyworld followed less than a second later by a 180s timeout [23:57] Ah [23:58] StevenK: That's what I suspected, except I was expecting body.private instead of .portlet.private [23:58] Yes, that is somewhat interesting. [23:58] wgrant: i docked the laptop and that hickups the network for some reason [23:58] wallyworld_: I'm not sure if you saw my explanation as to why this code is being hit now. [23:59] StevenK: no, missed it [23:59] [09:56] < StevenK> wgrant: The hide JS looks for .portlet.private, and the legacy code changes the portlet class to public before calling that hide code.