[00:00] wgrant: whats driving this; I thought we were happy with the owner/admin/member system [00:01] lifeless: Owners are awkward, because they're an easily forgotten special case and they need to be queried for specially when reporting on access. [00:02] And admins-can't-promote-admins confuses everyone, so needs to be abolished. And conflating admin+member is a bit silly and hard to display. Which means that ownership doesn't really have a purpose. [00:02] wgrant: but owners don't get access, so they don't need special handling [00:02] lifeless: Huh? [00:03] wgrant: we stomped that out 6 months ago [00:03] lifeless: My OEM project grants access to a project team. [00:03] owners no longer get benefits granted to the team [00:03] The project team's owner has resigned :( [00:03] the team owner doesn't get access to the project [00:03] But my disclosure reporting views don't show the owner. [00:03] and they don't need to. [00:03] Despite they fact that they can add themselves or others to the team. [00:04] The reports are pretty damn useless if they don't tell me that Joe Random Former Employee can do whatever he wants. [00:06] Joe Random could be in a private subteam with a legit sounding name and wouldn't be shown either [00:07] Sure, and that's the price we pay for supporting unstructured private teams. [00:07] But that can at least be detected. [00:07] If you hide the owner, it can't be. [00:07] so, if admin doesn't imply membership you need the same special case for admins [00:07] If you have an invisible private team in your access list, you have to trust the team. We know that. [00:08] Yes. [00:08] so, I don't think that removing owner is a good idea at the moment [00:08] I acknowledge it may make sense [00:09] but it needs some thought, reasoning and consultatoin [00:09] right now, my brain is full of u1 stuff, and its late for the folk I'm talking to about that, so I'm going to stay focused on that for nw. [00:09] What have they broken now? [00:10] as far as admin promoting admins; I think we need to check with our users there as well; particularly losa/gsa etc [00:10] wgrant: they have a growing userbase [00:19] wallyworld_, wgrant: Have you guys managed to have a chat about whether the manage-disclosure pages will need to be changed again due to the changes you were talking about yestereday? [00:19] We probably won't know for weeks. [00:20] wgrant: Thanks, I won't worry about it unless I hear something then [00:43] Bleh. I think these failing tests assume that nominations created by admins are not automatically approved. [00:57] poolie: no idea if that's the way to go: lp:~sladen/launchpad/launchpad-microdata-bug-person the way in which the data is dumped out doesn't immediately match up; ask you've got eg. _makeLink used around .unique_displayname [01:29] huwshimi: looking at your mp now. been having some stupid router issues [01:30] wallyworld_: Ah, awesome :) [01:46] wallyworld_: how hard do you think it would be to adapt https://github.com/marcello3d/node-buffalo to run (just the serializer) in chrome+ff [01:46] ? [01:46] loltpg [01:46] * wallyworld_ looks [01:47] StevenK: why loltpg? it's been hardware issues at my end :-( [01:47] lifeless: You haven't been turned off BSON yet? [01:48] wallyworld_: I saw 'router issues' and assumed. [01:48] StevenK: you know what they say about assuming :-) [01:48] wgrant: a bug in one implementation isn't sufficient to scare me off :P [01:48] Does anybody else use BSON? [01:48] At all? [01:48] Apart from in MongoDB? [01:48] we had a power outage last night and the router has been flakey ever since :-( [01:48] mongo folks :) [01:49] sourceforge uses it a bunch with their mongo stuff [01:49] lifeless: i've not seen that project before. i can't give you an immediate answer [01:49] lifeless: what breaks? should just be able to inline the bson.js with the extern/xx files for their long support [01:50] rick_h_: cool [01:50] The only benefits it seems to provide are obfuscation and storing binary data so our applications can crash. [01:50] rick_h_: I haven't tried yet [01:50] the only node parts are the require/packaging stuff [01:51] wgrant: I'm with you, clarity/debuggable ftw === Ursinha-lunch is now known as Ursinha [01:53] We've reinvented about 20 square wheels already, and used another 15 or so triangular wheels from other places. [01:53] Let's not add more... [01:53] wgrant: speaking of crashes, did you file a bug for that oops you ofund yesterday in +filebug ? [01:53] . [01:53] adfreakingsl [01:53] ... [01:53] lifeless: No, but matsubara id overnight. [01:53] did [01:54] wtf, this thing will serialize code? [01:54] heh, that's got to be interesting [01:58] rick_h_: I'd like to hook up an oops like thing in our js [01:59] rick_h_: to catch errors and report them immediately [02:00] lifeless: cool [02:01] I had something like that once for ajax requests in an app [02:01] glboal error handler that would then fire off an api request to log and notify of the error with a load of client info [02:02] huwshimi: on the new screenshot, the affected project is not shown. where is it displayed now? [02:02] wallyworld_: It's not [02:02] is that an issue? [02:03] wallyworld_: Well, my branch doesn't address that. The intention is that we revert to not showing the affected branch/project like we had previously except on pages that previously displayed it [02:03] ah ok. i didn't recall that we previously did not show it [02:04] wallyworld_: https://bugs.launchpad.net/launchpad [02:04] out of curiousity, if the user selects to show extra data like the project, it's in two lines then, right? [02:04] lifeless: Can we really catch all our js errors while we have in page scripts? [02:05] wallyworld_: Yeah, that's right [02:05] cool [02:05] wallyworld_: There's some helpful comments from Matthew on the bug about that [02:05] ok [02:05] wallyworld_: Pages like this show a package: https://bugs.launchpad.net/ubuntu' [02:06] so they do [02:07] wallyworld_: So those will hopefully still show a package (although I doubt the functionality exists yet as I believe the customisation of the columns is site wide) [02:07] it's hard looking at those pages when the new bug listings look sooo much nicer [02:12] rick_h_: exactly [02:13] huwshimi: all of? maybe not. More than we do today? Definitely. [02:13] lifeless: ok, I lied. It uses node buffers, which now needs node assert [02:13] wheee, dependency chaining here we go [02:13] rick_h_: yah :( [02:13] rick_h_: so I imagine there is some porting needed [02:14] lifeless: yea, and that needs util to do some inheritence binding [02:34] wallyworld__: Thanks heaps for the review [02:35] wallyworld__: I've been having router issues this week too, so I was gone for a sec then [02:36] lifeless: Will the js errors be logged in the oops database? I'm just asking cause I want to set up a service for logging a/b test results (via ajax) and am interested to know if the architecture would be similar [02:36] huwshimi: yes [02:36] lifeless: Ah ok [02:37] lifeless: I was hoping to steal some code :) [02:37] but this will have to be different [02:37] huwshimi: generic wsgi microservice that listens on http, sanitises some fields and forwards over amqp to the oops db [02:37] huwshimi: AIUI most a/b test frameworks use log files rather than actual services, but I am probably wrong [02:37] huwshimi: what do you want to have happen? [02:39] lifeless: To record the results of the test we'll need some js to test that a link has been clicked etc. The results need to be stored somewhere. I had imagined we would send off an ajax request to some kind of service and it would dump it in a db. [02:40] lifeless: And a tool that returns the results would be needed too [02:40] well, when the link is clicked, LP gets the request doesn't it ? [02:41] lifeless: We won't necessarily just be testing links, it could be that someone uses a bit of js interaction, or scrolls to the bottom of a page, the possibilities are endless [02:42] sure [02:42] the easiest to deploy thing is just to make a GET request to /+abtests/test/value with no referrer [02:42] this will go into our logs, and we can grep for it very easily [02:43] you can certainly do a service if you want [02:44] lifeless: OK, that seems simple [02:44] yea, just make things small enough to json/add to request [02:45] the no referrer will stop it oopsing [02:45] it will just be a random foreign request the appserveres and haproxy etc ignore [02:45] could almost just do something like dynamically add an image to the page and go through apache logs or something [02:45] are there real request logs out there? [02:46] yes, but restricted access (ip address is personal information) [02:46] however getting a script etc run on them is easy [03:01] Anyone know how to turn on the beta banner locally? [03:04] huwshimi: you need a feature flag with it limited in some way [03:04] deryck showed me today [03:04] set the buglisting flag for just your user, for instance [03:04] and that would trigger the beta banner [03:04] rick_h_: Ah right! [03:04] or just default 0 on [03:05] show it everywhere [03:05] right, but if it's default I think it doesn't show the banner right? [03:05] it should, it just checks on some pages/templates for the flag evaluating [03:05] to on/off [03:06] rick_h_: That worked [03:06] huwshimi: cool [03:06] lifeless: Wasn't working with default btw [03:06] ahm interesting [03:08] lifeless: Which means we can't have features in beta for everyone, or at least have a notification for it [03:08] hmm, it just means there is a small bug somewhere :) [03:09] -or [03:09] IIRC the theory is that 'when feature X is enabled for everyone it is out of beta' [03:10] yea, that's what I figured [03:10] hmmm [03:46] wgrant: In regards to the download-cache stuff we were talking about the other day, how do I actually commit changes? Do I do a bzr checkout of lp:lp-source-dependencies and just push the changes? [03:47] huwshimi: ~/launchpad/lp-sourcedeps/download-cache should be a bound checkout by default. You can commit straight to there, and it will push automatically. [03:47] wgrant: Oh right, thanks :) [03:57] A couple of reviews if someone wants them: [03:57] https://code.launchpad.net/~huwshimi/launchpad/update-cssutils-version/+merge/84199 [03:58] https://code.launchpad.net/~huwshimi/launchpad/beta-banner-design/+merge/84198 [04:02] huwshimi: Where'd you get that tarball? [04:02] They don't seem to distribute one, AFAICT. [04:02] wgrant: you're right [04:02] wgrant: I grabbed the tarball from the tagged branch [04:03] fwiw lp-land is the bomb [04:04] lifeless: Oh? [04:04] wgrant: Is there a problem with that tarball? [04:04] wgrant: handles prodconfigs ok [04:04] wgrant: I'd forgotten to use it :P [04:05] huwshimi: Doesn't match the 0.9.7 tag tarball that I got from bitbucket. We might be better off using the official 0.9.7 zip. [04:05] There's nothing wrong with it, besides not being official to being unreproducable and thoroughly confusing. [04:05] s/to being/so being/ [04:05] wgrant: Oh, I couldn't find an offical one. I got mine from bitbucket, but the only place I could find was from the tagged branches [04:06] huwshimi: Yeah, odd that its hash doesn't match. There's no official tar.gz, but there is an official zip which we can use. [04:06] oh and I removed the double containing folder [04:06] Ah [04:06] wgrant: Oh right, should we just use the zip? [04:06] That would do it. [04:06] Probably, yes. [04:06] wgrant: I actually didn't see the zip either [04:06] modifying upstream tarballs without labeling them as modified is a good way to get people upset :) [04:07] http://code.google.com/p/cssutils/downloads/detail?name=cssutils-0.9.7.zip&can=2&q= is one [04:07] I thought there was one on pypi too. [04:07] Although pypi makes it rather challenging to obtain a stable version... [04:07] wgrant: Oh right, I didn't look at the google code page [04:08] Looks like they moved to bitbucket recently, and didn't bring across the old downloads. [04:08] . [04:08] wgrant: Yeah ok, do you want me to replace it with the zip? [04:09] huwshimi: That would be cleaner, I think. [04:09] And sort of trivial. [04:09] wgrant: No problems [04:09] Thanks. [04:12] huwshimi: Ahhhhh CSS3 gradients. [04:12] That is wonderful. [04:13] :D [04:14] wgrant: OK that file should be replaced [04:15] huwshimi: Indeed, thanks. [04:21] wgrant: Thanks for the approve [04:22] wgrant: Is there any reason to not just lp-land the change to versions.cfg? [04:22] wgrant: Or should I be just as paranoid as I normally am [04:24] huwshimi: It's late on Friday, so we can't deploy for three days anyway... might as well just land. [04:24] It works fine here. [04:24] wgrant: OK :) [04:25] argh! [04:25] Uhoh. [04:25] wgrant: Any ideas? http://paste.ubuntu.com/756731/ [04:26] Hmm, that's pretty awesome. [04:26] Not one I've seen before. [04:27] wgrant: I seem to have a knack of coming across pretty awesome bugs [04:28] wgrant: Usually when it's friday afternoon and I want to land a few things :) [04:40] Hmm. [04:41] The beta banner doesn't seem to appear at all in IE9. [04:41] The page just sits there loading eternally. [04:41] Despite apparently having completely rendered otherwise. [04:41] Do we care? [04:44] wgrant: Is that a js thing then? [04:44] huwshimi: Probably. Other pages finish loading. [04:44] It's the same on prod. [04:45] wgrant: Strange [04:45] Unsurprisingly. [04:45] Yeash [04:45] yeah [04:45] oh, I have no idea about this lp-land thing [04:45] pqm-submit, I guess. [04:46] wgrant: https://bugs.launchpad.net/launchpad/+bug/894797 [04:46] <_mup_> Bug #894797: bug portlet ajax calls break in IE and break js for other features < https://launchpad.net/bugs/894797 > [04:46] wgrant: I tried to test some IE stuff and hit that [04:47] rick_h_: Aha. [04:47] Thanks. [04:47] as soon as it hits an error it stops all other JS and the portlet stuff is pretty up there [04:47] might be what you're hitting, so other pages without the portlets are ok [04:48] StevenK, wallyworld__: Could one of you review https://code.launchpad.net/~wgrant/launchpad/bug-728673/+merge/84205? [04:48] wgrant: oh, does that do a similar thing? [04:48] wgrant: sure [04:48] huwshimi: lp-land is a wrapper around pqm-submit. [04:48] huwshimi: lp-land grabs the details from the MP and invokes pqm-submit the right way. [04:48] wgrant: oh right [04:49] But normally if you're submitting to devel you can just say 'bzr pqm-submit -m '[r=wgrant] Blah blah blah I am a commit message' [04:49] wgrant: Should I just ec2 land this? :) [04:50] That might fail the same way as lp-land. [04:50] But maybe not. [04:50] wgrant: I'll give it a go [04:51] ec2 land will run ec2 test first [04:51] so beware it'll run for a bit if you were trying to avoid the test run [04:51] rick_h_: Yeah, but I'd rather that than accidentally screw something up :) [05:09] wgrant: why remove the sprb formatter instead of just adding the permission check? [05:09] wallyworld__: Because the only other difference between the two is that in one the archive was linked, while in the other it wasn't. [05:10] wallyworld__: Which I've wanted to fix for a while anyway. [05:10] wallyworld__: There's no reason for the SPRB one to exist separately. [05:10] but the sprb formatter displays different text [05:10] Does it? [05:10] it appears to from my reading of the code [05:10] If you look at the tests I changed, only the closing tag is differnt. [05:11] ah, i think you are right [05:11] i've misread the code i think [05:11] It's easy to do with some of the formatters we have :/ [05:12] yeah. thanks for humouring my question. i thought it best to double check [05:13] wgrant: r=me. also, did you see my email in reply to sinzui's email? [05:13] wallyworld__: I replied to it like 2 minutes later. [05:13] Thanks. [05:14] * wallyworld__ hits refresh on thunderbird [05:15] wgrant: ah, i see the problem now. [05:16] The private team implementation looks to have been a little lazy :) [05:16] That's interesting, actually. [05:16] wgrant: i think we have a hole in that the only protection is via travsrsal, no? [05:16] Person searches may be a little revealing. [05:16] Yes. [05:16] wgrant: So how will SPRBs show up with your change? [05:16] since my dicking with a test allowed me to see attrs [05:17] StevenK: the same as now afaiui [05:17] StevenK: Same as BPBs. Building _$title_ [$person/$archive] [05:17] Or 'Building private job' [05:17] Right, then the formatter was buggy and useless [05:17] Rather than the current 'Building _$title [$person/$archive]_' and crash. [05:18] wgrant: so if i fix this security issue, it will restore the current traversal protection and plug an access hole [05:18] wallyworld__: Well. [05:19] wallyworld__: You need to restrict all attributes to launchpad.View or launchpad.LimitedView rather than zope.Public. [05:19] This may cause a lot of fallout. [05:19] It remains to be seen. [05:21] it does. but in theory, moving the IpersonPublic stuff behind a security adaptor which allows full access for public teams and delegates to the limitedview security adaptor for private teams should be the right thing to do [05:21] It's certainly the right thing to do. [05:21] I just think it may well break stuff. [05:21] But we have to do it. [05:22] yes. i'll do it and see what breaks in ec2 :-) [05:22] Unlikely to catch everything, but not much more we can do. [05:22] IPersonPublic is not really the correct name anymore either [05:22] Indeed. [05:22] It hasn't been for a while. [05:22] Move stuff onto IPersonView/IPersonLimitedView [05:23] not limited view - we only want access to name, url, displayname for linited view [05:23] should be moved to IPersonRestrictedView perhaps [05:24] Well, yes, clearly only move the appropriate stuff onto LimitedView. [05:24] IPersonRestrictedView required launchpad.View permissions [05:24] which is what we want [05:24] Right. [05:24] and the security adaptor for that permission allows public teams unfetted access [05:24] which is what we want [05:25] here's hoping.... that not too much breaks [07:18] is it known the distro selection widget is broken? [07:18] on bugs that is [07:19] it shows the first one in the list as selected when trying to modify multiple values at once [07:21] micahg: I'll have a look in the open bugs. [07:21] jtv: thanks, I can file a bug if one doesn't exist [07:22] micahg: doesn't look like we have one open for this. So yes, please do file one! [07:24] jtv: stale page cache on my end, everything's fine :) [07:24] Heh [07:24] Unless the next person is going to have exactly the same problem, of course, in which case it doesn't really matter that things are fine in theory. :-) [07:26] well, my use case was old bugs open in my session for quite a while, refresh still showed the issue, forced refresh shift+f5 fixed it === wallyworld__ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2 [07:27] wallyworld__: trying to scare people :) [07:27] micahg: no? [07:27] you mean the bug count? [07:27] hi wallyworld__ — on your way to the weekend? [07:27] wallyworld__: heh, yeah :) [07:27] jtv: i wish :-( I have to finish some coding [07:28] Oh well [07:28] micahg: it was already like that. i just changed the reviewer :-) [07:28] wallyworld__: ah, ok, I must have missed that :) [07:28] jtv: but i plan on popping a cork to help :-) [07:28] micahg: but when it's written in that notation, it is scary for sure [07:29] wallyworld__: sorry, it's been like that for a while and I missed it :), yeah, I did a double take [07:30] np :-) [08:57] morning === almaisan-away is now known as al-maisan [09:44] good morning [09:45] bigjools: I have two callback chains that I need to interleave just so for my test. I would expect to have to orchestrate the events somehow. [09:45] hi adeuring [09:45] hi jtv [09:46] adeuring: are you reviewing today? If so, could you review one for me? It's https://code.launchpad.net/~jtv/launchpad/bug-849683-cloner/+merge/84222 [09:46] jtv: let me just check the API [09:46] jtv: I'll look [09:46] thanks === adeuring changed the topic of #launchpad-dev to: : https://dev.launchpad.net/ | On call reviewer: adeuring | Critical bugtasks: 3*10^2 [09:48] jtv: so you can call d.callback() to manually run the callbacks [09:49] And that will stop at the point where the callback chain makes another async request, I take it. [09:49] Do I then proceed with the new callback returned from the original callback? [09:49] if there are new Deferreds created then it gets harder, yes [09:51] jtv: I can't remember if Deferreds are processed in the order they are created in the reactor. It's probably best not to depend on that anyway [09:51] Right. ISTM any way I'm going to do this will be brittle: the interleaving will happen at the wrong point, and the test will either break in a mysterious way or become meaningless. [09:52] jtv: we can avoid that, we just need to make sure we fire Deferreds in a certain order [09:52] But the order will be tightly coupled to internals that may change. [09:53] jtv: no, I mean that you have a 2 deferreds in the test, the rest are incidental [09:54] The problem is that nothing interesting happens in the original deferreds. They return new deferreds, and so on. [09:54] but it would help if we could construct it such that there are no other deferreds created [09:54] I think we'd have to un-nest some functions. [09:55] A bit annoying given how they rely on local variables of the surrounding functions. [09:55] jtv: the other option is to just keep calling the Deferred until None is returned [09:55] see http://twistedmatrix.com/documents/current/api/twisted.internet.defer.Deferred.html [09:55] That's fine for one, but I need to get the interleaving right. [09:56] runCallbacks() [09:56] Thanks. [09:56] it will be file [09:56] fine [09:56] the chain of Deferreds only applies to a single builder [09:56] _runCallbacks? [09:56] yes [09:57] it stops when you get to a Deferred with no result, you'd just need to call _runCallbacks() on it [09:57] I guess we could follow the chain with a single builder, but it'll be less like the integration test you were hoping for. [09:57] jtv: slightly less, but still valid [09:57] the interleaving we want is still there [09:58] Then what exactly do we test for? Abort after every step and see that the changes are still there? [09:58] Or conversely, commit after every step, trigger a failure, and see that the changes are aborted? [09:58] we are testing the scenario I explained [09:59] storeBuildInfo() defers to a communication with the builder [09:59] in the meantime, another Deferred fires and aborts the txn [09:59] But how do we get it to just that stage? [09:59] where "another" is in a different builder chain [10:00] we make a fake builder than doesn't return the results that the storeBuildInfo() wants [10:01] we can make it do nothing so the deferred does not return right away [10:01] hmmm do we even need to do that [10:02] That's the question. The problem is, we have to dig through at least some closures to get to a state where anything like the bug can happen. [10:02] yes yes, I have it [10:03] then give it to me! [10:03] we use a fake builder that will sleep for a while when asked for the build info [10:04] Argh! [10:04] not a real sleep [10:04] it's a callback-based one [10:04] bear with me [10:04] then we set up the other builder that will abort [10:05] we can use a special reactor were you can wind the clock forwards but less than the sleep interval [10:05] it'll make the 2nd builder abort [10:05] but the first is still "waiting" [10:05] ok? [10:05] I can show you an example [10:06] Actually the part where the other builder fails can be simpler: we can call _scanFailed. [10:06] or that [10:06] it's easier to poke in a BrokenSlave [10:06] Already have that, but it saves some reactoring. [10:07] If we can just make the reactor return to us while storeBuildInfo is waiting to run, the rest should be easy. [10:07] look in lib/lp/buildmaster/tests/test_manager.py [10:07] search for Clock [10:08] it's a reactor that you can use instead of the testing one [10:08] let's you control how Deferreds are fired [10:08] by winding time forwards [10:08] task.Clock? [10:09] yes [10:10] I guess I need to adapt SlaveScanner.__init__ to accept a clock argument for testing, similar to the other scanners? [10:11] yes [10:11] Hmm… actually that only exists on NewBuildersScanner, which passes it to its LoopingCall. [10:12] it's to override the LoopingCall [10:12] The SlaveScanner has some equivalent to that? [10:12] yes [10:12] Ah, it has one too [10:12] it sets the clock on the LoopingCall [10:13] this allows you to wind forwards one scanner but not another [10:21] bigjools: I can see how the clock would let me force the LoopingCall into action, but why not just do that by calling scan()? The trouble is getting a simulated chain of interaction going and stopping it at the right point. [10:24] jtv: the changes look good, and thanks a lot for the nice reformatting. just one question: what about a test? [10:24] adeuring: good point — we know that the column is initialized, but it'd be nice to check it for correctness. Let me just see what the existing tests do. [10:25] jtv: great, thanks! [10:27] jtv: you need to set up a FakeBuilder so it pauses in the right place [10:27] then you advance it to the pause point [10:27]