[00:00] <lifeless> wgrant: whats driving this; I thought we were happy with the owner/admin/member system
[00:01] <wgrant> 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] <wgrant> 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] <lifeless> wgrant: but owners don't get access, so they don't need special handling
[00:02] <wgrant> lifeless: Huh?
[00:03] <lifeless> wgrant: we stomped that out 6 months ago
[00:03] <wgrant> lifeless: My OEM project grants access to a project team.
[00:03] <lifeless> owners no longer get benefits granted to the team
[00:03] <wgrant> The project team's owner has resigned :(
[00:03] <lifeless> the team owner doesn't get access to the project
[00:03] <wgrant> But my disclosure reporting views don't show the owner.
[00:03] <lifeless> and they don't need to.
[00:03] <wgrant> Despite they fact that they can add themselves or others to the team.
[00:04] <wgrant> The reports are pretty damn useless if they don't tell me that Joe Random Former Employee can do whatever he wants.
[00:06] <lifeless> Joe Random could be in a private subteam with a legit sounding name and wouldn't be shown either
[00:07] <wgrant> Sure, and that's the price we pay for supporting unstructured private teams.
[00:07] <wgrant> But that can at least be detected.
[00:07] <wgrant> If you hide the owner, it can't be.
[00:07] <lifeless> so, if admin doesn't imply membership you need the same special case for admins
[00:07] <wgrant> If you have an invisible private team in your access list, you have to trust the team. We know that.
[00:08] <wgrant> Yes.
[00:08] <lifeless> so, I don't think that removing owner is a good idea at the moment
[00:08] <lifeless> I acknowledge it may make sense
[00:09] <lifeless> but it needs some thought, reasoning and consultatoin
[00:09] <lifeless> 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] <wgrant> What have they broken now?
[00:10] <lifeless> as far as admin promoting admins; I think we need to check with our users there as well; particularly losa/gsa etc
[00:10] <lifeless> wgrant: they have a growing userbase
[00:19] <huwshimi> 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] <wgrant> We probably won't know for weeks.
[00:20] <huwshimi> wgrant: Thanks, I won't worry about it unless I hear something then
[00:43] <StevenK> Bleh. I think these failing tests assume that nominations created by admins are not automatically approved.
[00:57] <sladen> 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] <wallyworld_> huwshimi: looking at your mp now. been having some stupid router issues
[01:30] <huwshimi> wallyworld_: Ah, awesome :)
[01:46] <lifeless> 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] <lifeless> ?
[01:46] <StevenK> loltpg
[01:46]  * wallyworld_ looks
[01:47] <wallyworld_> StevenK: why loltpg? it's been hardware issues at my end :-(
[01:47] <wgrant> lifeless: You haven't been turned off BSON yet?
[01:48] <StevenK> wallyworld_: I saw 'router issues' and assumed.
[01:48] <wallyworld_> StevenK: you know what they say about assuming :-)
[01:48] <lifeless> wgrant: a bug in one implementation isn't sufficient to scare me off :P
[01:48] <wgrant> Does anybody else use BSON?
[01:48] <wgrant> At all?
[01:48] <wgrant> Apart from in MongoDB?
[01:48] <wallyworld_> we had a power outage last night and the router has been flakey ever since :-(
[01:48] <rick_h_> mongo folks :)
[01:49] <rick_h_> sourceforge uses it a bunch with their mongo stuff
[01:49] <wallyworld_> lifeless: i've not seen that project before. i can't give you an immediate answer
[01:49] <rick_h_> lifeless: what breaks? should just be able to inline the bson.js with the extern/xx files for their long support
[01:50] <lifeless> rick_h_: cool
[01:50] <wgrant> The only benefits it seems to provide are obfuscation and storing binary data so our applications can crash.
[01:50] <lifeless> rick_h_: I haven't tried yet
[01:50] <rick_h_> the only node parts are the require/packaging stuff
[01:51] <rick_h_> wgrant: I'm with you, clarity/debuggable ftw
[01:53] <wgrant> We've reinvented about 20 square wheels already, and used another 15 or so triangular wheels from other places.
[01:53] <wgrant> Let's not add more...
[01:53] <lifeless> wgrant: speaking of crashes, did you file a bug for that oops you ofund yesterday in +filebug ?
[01:53] <lifeless> .
[01:53] <lifeless> adfreakingsl
[01:53] <lifeless> ...
[01:53] <wgrant> lifeless: No, but matsubara id overnight.
[01:53] <wgrant> did
[01:54] <rick_h_> wtf, this thing will serialize code?
[01:54] <rick_h_> heh, that's got to be interesting
[01:58] <lifeless> rick_h_: I'd like to hook up an oops like thing in our js
[01:59] <lifeless> rick_h_: to catch errors and report them immediately
[02:00] <rick_h_> lifeless: cool
[02:01] <rick_h_> I had something like that once for ajax requests in an app
[02:01] <rick_h_> 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] <wallyworld_> huwshimi: on the new screenshot, the affected project is not shown. where is it displayed now?
[02:02] <huwshimi> wallyworld_: It's not
[02:02] <wallyworld_> is that an issue?
[02:03] <huwshimi> 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] <wallyworld_> ah ok. i didn't recall that we previously did not show it
[02:04] <huwshimi> wallyworld_: https://bugs.launchpad.net/launchpad
[02:04] <wallyworld_> out of curiousity, if the user selects to show extra data like the project, it's in two lines then, right?
[02:04] <huwshimi> lifeless: Can we really catch all our js errors while we have in page scripts?
[02:05] <huwshimi> wallyworld_: Yeah, that's right
[02:05] <wallyworld_> cool
[02:05] <huwshimi> wallyworld_: There's some helpful comments from Matthew on the bug about that
[02:05] <wallyworld_> ok
[02:05] <huwshimi> wallyworld_: Pages like this show a package: https://bugs.launchpad.net/ubuntu'
[02:06] <wallyworld_> so they do
[02:07] <huwshimi> 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] <wallyworld_> it's hard looking at those pages when the new bug listings look sooo much nicer
[02:12] <lifeless> rick_h_: exactly
[02:13] <lifeless> huwshimi: all of? maybe not. More than we do today? Definitely.
[02:13] <rick_h_> lifeless: ok, I lied. It uses node buffers, which now needs node assert
[02:13] <rick_h_> wheee, dependency chaining here we go
[02:13] <lifeless> rick_h_: yah :(
[02:13] <lifeless> rick_h_: so I imagine there is some porting needed
[02:14] <rick_h_> lifeless: yea, and that needs util to do some inheritence binding
[02:34] <huwshimi> wallyworld__: Thanks heaps for the review
[02:35] <huwshimi> wallyworld__: I've been having router issues this week too, so I was gone for a sec then
[02:36] <huwshimi> 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] <lifeless> huwshimi: yes
[02:36] <huwshimi> lifeless: Ah ok
[02:37] <huwshimi> lifeless: I was hoping to steal some code :)
[02:37] <huwshimi> but this will have to be different
[02:37] <lifeless> huwshimi: generic wsgi microservice that listens on http, sanitises some fields and forwards over amqp to the oops db
[02:37] <lifeless> huwshimi: AIUI most a/b test frameworks use log files rather than actual services, but I am probably wrong
[02:37] <lifeless> huwshimi: what do you want to have happen?
[02:39] <huwshimi> 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] <huwshimi> lifeless: And a tool that returns the results would be needed too
[02:40] <lifeless> well, when the link is clicked, LP gets the request doesn't it ?
[02:41] <huwshimi> 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] <lifeless> sure
[02:42] <lifeless> the easiest to deploy thing is just to make a GET request to <current-site>/+abtests/test/value with no referrer
[02:42] <lifeless> this will go into our logs, and we can grep for it very easily
[02:43] <lifeless> you can certainly do a service if you want
[02:44] <huwshimi> lifeless: OK, that seems simple
[02:44] <rick_h_> yea, just make things small enough to json/add to request
[02:45] <lifeless> the no referrer will stop it oopsing
[02:45] <lifeless> it will just be a random foreign request the appserveres and haproxy etc ignore
[02:45] <rick_h_> could almost just do something like dynamically add an image to the page and go through apache logs or something
[02:45] <rick_h_> are there real request logs out there?
[02:46] <lifeless> yes, but restricted access (ip address is personal information)
[02:46] <lifeless> however getting a script etc run on them is easy
[03:01] <huwshimi> Anyone know how to turn on the beta banner locally?
[03:04] <rick_h_> huwshimi: you need a feature flag with it limited in some way
[03:04] <rick_h_> deryck showed me today
[03:04] <rick_h_> set the buglisting flag for just your user, for instance
[03:04] <rick_h_> and that would trigger the beta banner
[03:04] <huwshimi> rick_h_: Ah right!
[03:04] <lifeless> or just default 0 on
[03:05] <lifeless> show it everywhere
[03:05] <rick_h_> right, but if it's default I think it doesn't show the banner right?
[03:05] <lifeless> it should, it just checks on some pages/templates for the flag evaluating
[03:05] <lifeless> to on/off
[03:06] <huwshimi> rick_h_: That worked
[03:06] <rick_h_> huwshimi: cool
[03:06] <huwshimi> lifeless: Wasn't working with default btw
[03:06] <lifeless> ahm interesting
[03:08] <huwshimi> lifeless: Which means we can't have features in beta for everyone, or at least have a notification for it
[03:08] <lifeless> hmm, it just means there is a small bug somewhere :)
[03:09] <lifeless> -or
[03:09] <lifeless> IIRC the theory is that 'when feature X is enabled for everyone it is out of beta'
[03:10] <rick_h_> yea, that's what I figured
[03:10] <huwshimi> hmmm
[03:46] <huwshimi> 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] <wgrant> 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] <huwshimi> wgrant: Oh right, thanks :)
[03:57] <huwshimi> A couple of reviews if someone wants them:
[03:57] <huwshimi> https://code.launchpad.net/~huwshimi/launchpad/update-cssutils-version/+merge/84199
[03:58] <huwshimi> https://code.launchpad.net/~huwshimi/launchpad/beta-banner-design/+merge/84198
[04:02] <wgrant> huwshimi: Where'd you get that tarball?
[04:02] <wgrant> They don't seem to distribute one, AFAICT.
[04:02] <huwshimi> wgrant: you're right
[04:02] <huwshimi> wgrant: I grabbed the tarball from the tagged branch
[04:03] <lifeless> fwiw lp-land is the bomb
[04:04] <wgrant> lifeless: Oh?
[04:04] <huwshimi> wgrant: Is there a problem with that tarball?
[04:04] <lifeless> wgrant: handles prodconfigs ok
[04:04] <lifeless> wgrant: I'd forgotten to use it :P
[04:05] <wgrant> 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] <wgrant> There's nothing wrong with it, besides not being official to being unreproducable and thoroughly confusing.
[04:05] <wgrant> s/to being/so being/
[04:05] <huwshimi> 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] <wgrant> 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] <huwshimi> oh and I removed the double containing folder
[04:06] <wgrant> Ah
[04:06] <huwshimi> wgrant: Oh right, should we just use the zip?
[04:06] <wgrant> That would do it.
[04:06] <wgrant> Probably, yes.
[04:06] <huwshimi> wgrant: I actually didn't see the zip either
[04:06] <wgrant> modifying upstream tarballs without labeling them as modified is a good way to get people upset :)
[04:07] <wgrant> http://code.google.com/p/cssutils/downloads/detail?name=cssutils-0.9.7.zip&can=2&q= is one
[04:07] <wgrant> I thought there was one on pypi too.
[04:07] <wgrant> Although pypi makes it rather challenging to obtain a stable version...
[04:07] <huwshimi> wgrant: Oh right, I didn't look at the google code page
[04:08] <wgrant> Looks like they moved to bitbucket recently, and didn't bring across the old downloads.
[04:08] <lifeless> .
[04:08] <huwshimi> wgrant: Yeah ok, do you want me to replace it with the zip?
[04:09] <wgrant> huwshimi: That would be cleaner, I think.
[04:09] <wgrant> And sort of trivial.
[04:09] <huwshimi> wgrant: No problems
[04:09] <wgrant> Thanks.
[04:12] <wgrant> huwshimi: Ahhhhh CSS3 gradients.
[04:12] <wgrant> That is wonderful.
[04:13] <huwshimi> :D
[04:14] <huwshimi> wgrant: OK that file should be replaced
[04:15] <wgrant> huwshimi: Indeed, thanks.
[04:21] <huwshimi> wgrant: Thanks for the approve
[04:22] <huwshimi> wgrant: Is there any reason to not just lp-land the change to versions.cfg?
[04:22] <huwshimi> wgrant: Or should I be just as paranoid as I normally am
[04:24] <wgrant> huwshimi: It's late on Friday, so we can't deploy for three days anyway... might as well just land.
[04:24] <wgrant> It works fine here.
[04:24] <huwshimi> wgrant: OK :)
[04:25] <huwshimi> argh!
[04:25] <wgrant> Uhoh.
[04:25] <huwshimi> wgrant: Any ideas? http://paste.ubuntu.com/756731/
[04:26] <wgrant> Hmm, that's pretty awesome.
[04:26] <wgrant> Not one I've seen before.
[04:27] <huwshimi> wgrant: I seem to have a knack of coming across pretty awesome bugs
[04:28] <huwshimi> wgrant: Usually when it's friday afternoon and I want to land a few things :)
[04:40] <wgrant> Hmm.
[04:41] <wgrant> The beta banner doesn't seem to appear at all in IE9.
[04:41] <wgrant> The page just sits there loading eternally.
[04:41] <wgrant> Despite apparently having completely rendered otherwise.
[04:41] <StevenK> Do we care?
[04:44] <huwshimi> wgrant: Is that a js thing then?
[04:44] <wgrant> huwshimi: Probably. Other pages finish loading.
[04:44] <wgrant> It's the same on prod.
[04:45] <huwshimi> wgrant: Strange
[04:45] <wgrant> Unsurprisingly.
[04:45] <wgrant> Yeash
[04:45] <wgrant> yeah
[04:45] <huwshimi> oh, I have no idea about this lp-land thing
[04:45] <wgrant> pqm-submit, I guess.
[04:46] <rick_h_> 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 <bugs> <ie> <javascript> <markup> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/894797 >
[04:46] <rick_h_> wgrant: I tried to test some IE stuff and hit that
[04:47] <wgrant> rick_h_: Aha.
[04:47] <wgrant> Thanks.
[04:47] <rick_h_> as soon as it hits an error it stops all other JS and the portlet stuff is pretty up there
[04:47] <rick_h_> might be what you're hitting, so other pages without the portlets are ok
[04:48] <wgrant> StevenK, wallyworld__: Could one of you review https://code.launchpad.net/~wgrant/launchpad/bug-728673/+merge/84205?
[04:48] <huwshimi> wgrant: oh, does that do a similar thing?
[04:48] <wallyworld__> wgrant: sure
[04:48] <wgrant> huwshimi: lp-land is a wrapper around pqm-submit.
[04:48] <wgrant> huwshimi: lp-land grabs the details from the MP and invokes pqm-submit the right way.
[04:48] <huwshimi> wgrant: oh right
[04:49] <wgrant> 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] <huwshimi> wgrant: Should I just ec2 land this? :)
[04:50] <wgrant> That might fail the same way as lp-land.
[04:50] <wgrant> But maybe not.
[04:50] <huwshimi> wgrant: I'll give it a go
[04:51] <rick_h_> ec2 land will run ec2 test first
[04:51] <rick_h_> so beware it'll run for a bit if you were trying to avoid the test run
[04:51] <huwshimi> rick_h_: Yeah, but I'd rather that than accidentally screw something up :)
[05:09] <wallyworld__> wgrant: why remove the sprb formatter instead of just adding the permission check?
[05:09] <wgrant> 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] <wgrant> wallyworld__: Which I've wanted to fix for a while anyway.
[05:10] <wgrant> wallyworld__: There's no reason for the SPRB one to exist separately.
[05:10] <wallyworld__> but the sprb formatter displays different text
[05:10] <wgrant> Does it?
[05:10] <wallyworld__> it appears to from my reading of the code
[05:10] <wgrant> If you look at the tests I changed, only the closing tag is differnt.
[05:11] <wallyworld__> ah, i think you are right
[05:11] <wallyworld__> i've misread the code i think
[05:11] <wgrant> It's easy to do with some of the formatters we have :/
[05:12] <wallyworld__> yeah. thanks for humouring my question. i thought it best to double check
[05:13] <wallyworld__> wgrant: r=me. also, did you see my email in reply to sinzui's email?
[05:13] <wgrant> wallyworld__: I replied to it like 2 minutes later.
[05:13] <wgrant> Thanks.
[05:14]  * wallyworld__ hits refresh on thunderbird
[05:15] <wallyworld__> wgrant: ah, i see the problem now.
[05:16] <wgrant> The private team implementation looks to have been a little lazy :)
[05:16] <wgrant> That's interesting, actually.
[05:16] <wallyworld__> wgrant: i think we have a hole in that the only protection is via travsrsal, no?
[05:16] <wgrant> Person searches may be a little revealing.
[05:16] <wgrant> Yes.
[05:16] <StevenK> wgrant: So how will SPRBs show up with your change?
[05:16] <wallyworld__> since my dicking with a test allowed me to see attrs
[05:17] <wallyworld__> StevenK: the same as now afaiui
[05:17] <wgrant> StevenK: Same as BPBs. Building _$title_ [$person/$archive]
[05:17] <wgrant> Or 'Building private job'
[05:17] <StevenK> Right, then the formatter was buggy and useless
[05:17] <wgrant> Rather than the current 'Building _$title [$person/$archive]_' and crash.
[05:18] <wallyworld__> wgrant: so if i fix this security issue, it will restore the current traversal protection and plug an access hole
[05:18] <wgrant> wallyworld__: Well.
[05:19] <wgrant> wallyworld__: You need to restrict all attributes to launchpad.View or launchpad.LimitedView rather than zope.Public.
[05:19] <wgrant> This may cause a lot of fallout.
[05:19] <wgrant> It remains to be seen.
[05:21] <wallyworld__> 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] <wgrant> It's certainly the right thing to do.
[05:21] <wgrant> I just think it may well break stuff.
[05:21] <wgrant> But we have to do it.
[05:22] <wallyworld__> yes. i'll do it and see what breaks in ec2 :-)
[05:22] <wgrant> Unlikely to catch everything, but not much more we can do.
[05:22] <wallyworld__> IPersonPublic is not really the correct name anymore either
[05:22] <wgrant> Indeed.
[05:22] <wgrant> It hasn't been for a while.
[05:22] <wgrant> Move stuff onto IPersonView/IPersonLimitedView
[05:23] <wallyworld__> not limited view - we only want access to name, url, displayname for linited view
[05:23] <wallyworld__> should be moved to IPersonRestrictedView perhaps
[05:24] <wgrant> Well, yes, clearly only move the appropriate stuff onto LimitedView.
[05:24] <wallyworld__> IPersonRestrictedView required launchpad.View permissions
[05:24] <wallyworld__> which is what we want
[05:24] <wgrant> Right.
[05:24] <wallyworld__> and the security adaptor for that permission allows public teams unfetted access
[05:24] <wallyworld__> which is what we want
[05:25] <wallyworld__> here's hoping.... that not too much breaks
[07:18] <micahg> is it known the distro selection widget is broken?
[07:18] <micahg> on bugs that is
[07:19] <micahg> it shows the first one in the list as selected when trying to modify multiple values at once
[07:21] <jtv> micahg: I'll have a look in the open bugs.
[07:21] <micahg> jtv: thanks, I can file a bug if one doesn't exist
[07:22] <jtv> micahg: doesn't look like we have one open for this.  So yes, please do file one!
[07:24] <micahg> jtv: stale page cache on my end, everything's fine :)
[07:24] <jtv> Heh
[07:24] <jtv> 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] <micahg> 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
[07:27] <micahg> wallyworld__: trying to scare people :)
[07:27] <wallyworld__> micahg: no?
[07:27] <wallyworld__> you mean the bug count?
[07:27] <jtv> hi wallyworld__ — on your way to the weekend?
[07:27] <micahg> wallyworld__: heh, yeah :)
[07:27] <wallyworld__> jtv: i wish :-( I have to finish some coding
[07:28] <jtv> Oh well
[07:28] <wallyworld__> micahg: it was already like that. i just changed the reviewer :-)
[07:28] <micahg> wallyworld__: ah, ok, I must have missed that :)
[07:28] <wallyworld__> jtv: but i plan on popping a cork to help :-)
[07:28] <wallyworld__> micahg: but when it's written in that notation, it is scary for sure
[07:29] <micahg> wallyworld__: sorry, it's been like that for a while and I missed it :), yeah, I did a double take
[07:30] <wallyworld__> np :-)
[08:57] <bigjools> morning
[09:44] <adeuring> good morning
[09:45] <jtv> 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] <jtv> hi adeuring
[09:45] <adeuring> hi jtv
[09:46] <jtv> 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] <bigjools> jtv: let me just check the API
[09:46] <adeuring> jtv: I'll look
[09:46] <jtv> thanks
[09:48] <bigjools> jtv: so you can call d.callback() to manually run the callbacks
[09:49] <jtv> And that will stop at the point where the callback chain makes another async request, I take it.
[09:49] <jtv> Do I then proceed with the new callback returned from the original callback?
[09:49] <bigjools> if there are new Deferreds created then it gets harder, yes
[09:51] <bigjools> 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] <jtv> 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] <bigjools> jtv: we can avoid that, we just need to make sure we fire Deferreds in a certain order
[09:52] <jtv> But the order will be tightly coupled to internals that may change.
[09:53] <bigjools> jtv: no, I mean that you have a 2 deferreds in the test, the rest are incidental
[09:54] <jtv> The problem is that nothing interesting happens in the original deferreds.  They return new deferreds, and so on.
[09:54] <bigjools> but it would help if we could construct it such that there are no other deferreds created
[09:54] <jtv> I think we'd have to un-nest some functions.
[09:55] <jtv> A bit annoying given how they rely on local variables of the surrounding functions.
[09:55] <bigjools> jtv: the other option is to just keep calling the Deferred until None is returned
[09:55] <bigjools> see http://twistedmatrix.com/documents/current/api/twisted.internet.defer.Deferred.html
[09:55] <jtv> That's fine for one, but I need to get the interleaving right.
[09:56] <bigjools> runCallbacks()
[09:56] <jtv> Thanks.
[09:56] <bigjools> it will be file
[09:56] <bigjools> fine
[09:56] <bigjools> the chain of Deferreds only applies to a single builder
[09:56] <jtv> _runCallbacks?
[09:56] <bigjools> yes
[09:57] <bigjools> it stops when you get to a Deferred with no result, you'd just need to call _runCallbacks() on it
[09:57] <jtv> 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] <bigjools> jtv: slightly less, but still valid
[09:57] <bigjools> the interleaving we want is still there
[09:58] <jtv> Then what exactly do we test for?  Abort after every step and see that the changes are still there?
[09:58] <jtv> Or conversely, commit after every step, trigger a failure, and see that the changes are aborted?
[09:58] <bigjools> we are testing the scenario I explained
[09:59] <bigjools> storeBuildInfo() defers to a communication with the builder
[09:59] <bigjools> in the meantime, another Deferred fires and aborts the txn
[09:59] <jtv> But how do we get it to just that stage?
[09:59] <bigjools> where "another" is in a different builder chain
[10:00] <bigjools> we make a fake builder than doesn't return the results that the storeBuildInfo() wants
[10:01] <bigjools> we can make it do nothing so the deferred does not return right away
[10:01] <bigjools> hmmm do we even need to do that
[10:02] <jtv> 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] <bigjools> yes yes, I have it
[10:03] <jtv> then give it to me!
[10:03] <bigjools> we use a fake builder that will sleep for a while when asked for the build info
[10:04] <jtv> Argh!
[10:04] <bigjools> not a real sleep
[10:04] <bigjools> it's a callback-based one
[10:04] <bigjools> bear with me
[10:04] <bigjools> then we set up the other builder that will abort
[10:05] <bigjools> we can use a special reactor were you can wind the clock forwards but less than the sleep interval
[10:05] <bigjools> it'll make the 2nd builder abort
[10:05] <bigjools> but the first is still "waiting"
[10:05] <bigjools> ok?
[10:05] <bigjools> I can show you an example
[10:06] <jtv> Actually the part where the other builder fails can be simpler: we can call _scanFailed.
[10:06] <bigjools> or that
[10:06] <bigjools> it's easier to poke in a BrokenSlave
[10:06] <jtv> Already have that, but it saves some reactoring.
[10:07] <jtv> If we can just make the reactor return to us while storeBuildInfo is waiting to run, the rest should be easy.
[10:07] <bigjools> look in lib/lp/buildmaster/tests/test_manager.py
[10:07] <bigjools> search for Clock
[10:08] <bigjools> it's a reactor that you can use instead of the testing one
[10:08] <bigjools> let's you control how Deferreds are fired
[10:08] <bigjools> by winding time forwards
[10:08] <jtv> task.Clock?
[10:09] <bigjools> yes
[10:10] <jtv> I guess I need to adapt SlaveScanner.__init__ to accept a clock argument for testing, similar to the other scanners?
[10:11] <bigjools> yes
[10:11] <jtv> Hmm… actually that only exists on NewBuildersScanner, which passes it to its LoopingCall.
[10:12] <bigjools> it's to override the LoopingCall
[10:12] <jtv> The SlaveScanner has some equivalent to that?
[10:12] <bigjools> yes
[10:12] <jtv> Ah, it has one too
[10:12] <bigjools> it sets the clock on the LoopingCall
[10:13] <bigjools> this allows you to wind forwards one scanner but not another
[10:21] <jtv> 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] <adeuring> jtv: the changes look good, and thanks a lot for the nice reformatting. just one question: what about a test?
[10:24] <jtv> 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] <adeuring> jtv: great, thanks!
[10:27] <bigjools> jtv: you need to set up a FakeBuilder so it pauses in the right place
[10:27] <bigjools> then you advance it to the pause point
[10:27] <bigjools> then run the other builder scan to completion
[10:28] <bigjools> jtv: you need a callLater() in the FakeBuilder to make it wait a bit
[10:28] <jtv> That means that the _runCallbacks will stop at that point?
[10:28] <bigjools> don't use runCallbacks
[10:29] <jtv> Oh
[10:29] <bigjools> use the Clock() as the reactor
[10:29] <jtv> And I guess I need a FakeSlave?
[10:29] <bigjools> yes
[10:29] <jtv> Not a FakeBuilder?
[10:29] <bigjools> sorry, yes
[10:35]  * gmb just realised that there's no TLA equivalent of "OTP" for "Having a conversation with another human being in real life"
[10:36] <jtv> How on Earth did we get by all this time?
[10:37] <nigelb> full sentences I guess ;)
[10:37]  * gmb -> real life
[10:38] <jtv> gmr irl omg
[10:48] <allenap> bigjools, anyone: Do you think mbp will get miffed if I change the trunk branch of txfixtures (to one owned by ~launchpad instead of ~mbp)?
[10:49] <wgrant> ~canonical-launchpad-branches, not ~launchpad
[10:49] <jtv> allenap: knowing him, no, as long as it's (1) well thought-out and (2) clearly documented and notified.
[10:49] <bigjools> I would not think so
[10:49] <bigjools> probably just an oversight
[10:49] <allenap> wgrant, jtv, bigjools: Cool, thanks all :)
[10:50] <jtv> bigjools: meanwhile, back on the broad and twisted path to hell, I just discovered that the triggering event just before the simulated problem comes from the Librarian, not from the slave.
[10:50] <wgrant> allenap: https://dev.launchpad.net/CreatingNewProjects has setup instructions
[10:50] <allenap> Ta.
[10:51] <bigjools> jtv: really?  I thought it was "        d = build.getLogFromSlave(build)"
[10:52] <jtv> bigjools: and you were right.  But, and this is exactly why I went with those narrow read-write policies, that call hides async calls to both slave and librarian.
[10:53] <jtv> Or maybe that's synchronous…  I'm not really seeing things clearly.
[10:54] <jtv> Ahhh no, I think that's synchronous.
[10:55] <bigjools> jtv: it calls getFile() on the slave first and then does a blocking upload to the librarian.  Which is a bit crap.
[10:55] <jtv> But in this case another welcome simplification.
[10:55] <jtv> Even though I imagine eventually we would change it, and thus break the test.
[10:55] <mrevell> Welcome danhg_
[10:56] <jtv> This is all so much SA-80 and so little AK-47…
[10:56] <jtv> hi mrevell
[10:56] <mrevell> Hey there jtv
[10:58] <jtv> bigjools: when I say SA-80 I'm referring mainly to how you're free to fire it left-handed, but it'll spit hot brass at you from the left and smash your nose from the front if you do.
[10:59] <jtv> Actually surprisingly reasonable design choices when you look at the tradeoffs, but not foolproof.
[11:01] <bigjools> jtv: you have a way with words
[11:02] <jtv> bigjools: not implying you're a fool.
[11:03] <bigjools> jtv: but are these footguns?
[11:03] <jtv> If you like.  But the SA-80 probably more so, since it's a bullpup.
[11:04]  * jtv has a particular thing against people who don't mind where they point their assault rifles, especially when he ends up in front of them.
[11:05] <jtv> That's enough ramblings from my overheated brain.  I must go.
[11:08] <bigjools> jtv: sounds like you need a good dose of paracetamol and bedrest
[11:08] <jtv> bigjools: unfortunately I have a train to catch.  Promised to take care of my friends' house.
[11:08] <jtv> On the bright side, I sleep better on those night trains.
[11:08] <bigjools> I remember thoes
[11:09] <bigjools> those
[11:09] <bigjools> no station stop announcements!
[11:09] <jtv> I think they do announce them _sometimes_…
[11:09] <jtv> …probably to lull you into a false sense of security.
[11:11] <nigelb> heh
[11:12] <bigjools> well it lulled me into a sense of no sleep
[11:12] <nigelb> bigjools: You've visited India yet?
[11:12] <bigjools> I have no plans
[11:13] <nigelb> aww :(
[11:14] <bigjools> wgrant: yay you are fixing bug 728673
[11:14] <_mup_> Bug #728673: BuilderSet:+index crash (/builders) <oops> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/728673 >
[11:18] <stub> jtv: Good luck with the train. Its a long weekend so will be packed!
[11:21] <jtv> stub: I booked ahead, thanks
[11:22] <jtv> good weekend everyone
[13:16] <rick_h_> morning
[13:17] <bac> morning rick_h_
[14:10] <jcsackett> morning, all.
[14:11] <rick_h_> morning jcsackett
[15:03] <sinzui> gmb, deryck, allenap: Do either of you have time to talk about renaming BugTaskSearchParams.bug_supervisor or structural_subscriber ?
[15:05] <deryck> sinzui, I'm sprinting and have two calls already this morning....
[15:05] <deryck> sinzui, but if no one else can help, I can try.
[15:06] <gmb> sinzui: I have a little time. What do you need to know?
[15:07] <sinzui> gmb, I think I cannot remove  BugTaskSearchParams.bug_supervisor because it is in the api. I probably need to add structural_subscriber to support older api
[15:07]  * gmb refreshes his memory
[15:07] <sinzui> gmb. search is actually looking at structural subscriptions, not bug supervisor in *most* cases
[15:09] <sinzui> gmb. The only case that may be interesting to search bug_supervisor is if you search from  team/user advanced search page and want to see all the bugs in all the projects the person supervises...
[15:09] <gmb> sinzui: Right, I'm with you.
[15:09] <gmb> I think you're right; I don't think bug_supervisor can be removed.
[15:09] <gmb> (At least until version 2.0)
[15:10] <sinzui> gmb: I can add a new param, and then fall back to the bug_supervisor is it was provided
[15:10] <sinzui> *if* it is provided
[15:11] <gmb> sinzui: Yes, I think that would work.
[15:12] <jml> random fact: 1.2GB of space on my system was being taken up by postgresql logs in a hardy chroot that I made for LP hacking and then forgot about
[15:12] <sinzui> gmb: bug_supervisor search will fail in many current cases because the default supervisor is the maintainer; the supervisor field is null. I think we should drop this case. We want to search for structural subscriptions on projects instead
[15:13] <gmb> sinzui: I agree.
[15:13] <sinzui> gmb: dropping the bug_supervisor column clause will make most searches faster because we already search ubuntu.bug_supervisor when the user is only looking for package subscriptions
[15:14] <gmb> Nice
[15:14] <sinzui> okay. I am going to try this and hope the api tests like me
[15:16] <gmb> sinzui: Best of luck to you :)....
[15:16] <sinzui> thank you very much
[15:16]  * gmb can't take the feeling that he's managed to let sinzui talk himself into a footcannon
[15:17] <sinzui> s/footcannon/disclosure/
[15:17] <rvba> adeuring, bac, could one of you guys please have a look at https://code.launchpad.net/~rvb/launchpad/authorize-bug-898237/+merge/84269 ?
[15:17] <adeuring> rvba: sure, i'll look
[15:18] <rvba> ta
[15:31] <deryck> abentley, standup time now ok?
[15:31] <deryck> adeuring, can you hear me on mumble?
[15:32] <adeuring> deryck: seems that mmle does use the tright sound output. just a second...
[15:34] <deryck> adeuring, still no sound luck?
[15:34] <deryck> adeuring, we hear you fine, FWIW.
[15:34] <adeuring> deryck: right...
[15:34] <adeuring> deryck: let me try another machine...,
[15:35] <deryck> adeuring, ok
[15:38] <deryck> adeuring, now we don't hear you at all.
[15:38] <adeuring> deryck: wierd... on this machine, all sounds goes to the headset -- only mumble does not use it...
[15:38] <deryck> adeuring, we need to start, so we'll go ahead.  we can chat with you via irc.  sorry.
[15:39] <adeuring> deryck: ok, sorry for the mess...
[15:47] <deryck> adeuring, we did hear you that time though.
[15:48] <deryck> adeuring, right.
[15:48] <deryck> adeuring, is mumble audio going to the right device?
[15:49] <adeuring> deryck: yes...
[15:50] <deryck> adeuring, I guess we lost you again?
[15:53] <deryck> mrevell, my entire team will join for the check point.  will we skype or conf call in?
[15:55] <mrevell> deryck, Hey, I'm happy with Skype but I can also do the conference call. Is Skype okay for the Orange squad?
[15:55] <deryck> mrevell, yup, skype works for us.
[15:56] <mrevell> Great
[15:57] <dobey> deryck: i'm surprised you're not meeting on PSN Home ;)
[15:58] <deryck> dobey, dude, if I could! :)
[16:00] <mrevell> Okay, calling now. I don't have adeuring or rick_h_ in my Skype contacts.
[16:01] <adeuring> mrevell: try "adeuring"
[16:01] <rick_h_> mrevell: mitechie
[16:01] <bigjools> HALP.  Running tests here and it gets as far as "Set up canonical.testing.layers.AppServerLayer" and then hangs.... anyone else seen that?
[16:02] <mrevell> Sorry jcsackett, accident.
[16:03] <jcsackett> mrevell: what was an accident?
[16:03] <mrevell> jcsackett, I thought I added you to a Skype conference.
[16:03] <jcsackett> mrevell: huh; i'm not on skype right now, so now worries. :-)
[16:04] <jcsackett> s/now worries/no worries/
[16:04] <mrevell> ok :)
[16:20] <mrevell> deryck, abentley flacoste danhg rick_h_ adeuring matsubara https://launchpadlibrarian.net/86370773/single_line_bugs.png
[16:27] <rvba> Hi gary_poster, the branch that refactors LaunchpadSecurityPolicy to have it cache sub checks performed by classes inheriting from DelegatedAuthorization is up for review! (that's the one we talked about a few days ago).  Gavin is reviewing it but maybe you will be willing to have a look, out of curiosity if nothing else ;).
[16:27] <rvba> https://code.launchpad.net/~rvb/launchpad/private-ppa-bug-890927-2/+merge/84243
[16:30] <mrevell> matsubara, "A way to specify the information displayed and ordering via the URL (bug 124342)"
[16:30] <_mup_> Bug #124342: It should be possible to specify bug list sort order via the URL <bug-columns> <lp-bugs> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/124342 >
[16:31] <matsubara> thanks mer
[16:31] <matsubara> thanks mrevell
[16:38] <mrevell> deryck, https://dev.launchpad.net/Projects/CustomBugListings/Design
[16:55] <adeuring> rvba: r=me (sorry for the delay)
[16:55] <rvba> no worries, thanks for the review adeuring.
[16:56] <bigjools> can I bug one of you guys for a review please
[16:56] <gary_poster> rvba, awesome! what kind of performance improvement to you expect?
[16:58] <rvba> gary_poster: well, the page ~canonical-isd-hackers/+archive/ppa/+index spends 8 sec doing the checks that will be cached now…
[16:59] <rvba> So I expect it the performance improvement to be pretty serious in this case, and hopefully it will help else were as well.
[16:59] <rvba> s/expect it/expect/
[17:00]  * bigjools hi-fives rvba
[17:00] <rvba> bigjools: you should wait till this passes QA ;)
[17:01] <gary_poster> rvba, cool, me too.  I was hoping for hard (& exciting) numbers and I will look forward to them soon :-) ... have you timed this on qastaging so that you can get a relatively accurate comparison?
[17:01] <bigjools> I can merge it on DF right now if you want to test
[17:02] <rvba> gary_poster: well, this will fix repeated statements so it's pretty easy to guess what the gain will be (that is if everything does well).
[17:02] <gary_poster> right
[17:03] <gary_poster> I just like hard numbers :-)
[17:03] <gary_poster> (so bigjools' offer sounds good to me, but I'm a bystander)
[17:04] <rvba> gary_poster: hard numbers: https://launchpad.net/~canonical-isd-hackers/+archive/ppa spends ~6000 doing the repeated checks that will now hopefully be cached.
[17:05] <rvba> 6000ms that is.
[17:05] <rvba> bigjools: why not… but I'll have to go in ~30 minutes.
[17:06] <bigjools> ok, doing a load test on DF pre-patch
[17:06] <bigjools> rvba: which branch?
[17:07] <rvba> bigjools: lp:~rvb/launchpad/private-ppa-bug-890927-2
[17:07] <bigjools> that private PPA you posted *cough* takes 1.5 seconds pre-patch
[17:08] <rvba> bigjools: on df yes.
[17:08] <rvba> bigjools: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-d84aaa754e954254c44f803f45871daf  https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1baf5eff75609f641e53992c0023acb6
[17:09] <rvba> bigjools: can you access https://launchpad.net/~canonical-isd-hackers/+archive/ppa/+index ?
[17:09] <rvba> (Not on df that is)
[17:09] <bigjools> yes
[17:09] <bigjools> v quick, because I am commercial admin
[17:10] <rvba> bigjools: hum, also, on DF, we are admins so unless I'm mistaken the security checks are by passed…
[17:10] <rvba> Am I right?
[17:11] <bigjools> rvba: not bypassed, just different
[17:12] <rvba> bigjools: right, so it's not a good test.
[17:15] <gary_poster> https://qastaging.launchpad.net/~canonical-isd-hackers/+archive/ppa takes 8 secs once it loads at all
[17:15] <gary_poster> s 7.63 seconds
[17:15] <rvba> Right.
[17:16] <bigjools> gary_poster: can you try https://dogfood.launchpad.net/~canonical-isd-hackers/+archive/ppa
[17:18] <gary_poster> trying
[17:18] <gary_poster> bigjools, 1.57 s
[17:18] <bigjools> woo :)
[17:19] <gary_poster> so that is post-patch bigjools?
[17:19]  * bigjools hi-fives rvba
[17:19] <rvba> That's without the patch?
[17:19] <bigjools> with patch
[17:19] <bigjools> I can remove it to compare
[17:19] <rvba> I'd like to see how it goes without the patch
[17:19] <gary_poster> yeah
[17:20] <bigjools> ok try now
[17:20] <gary_poster> k
[17:21] <bigjools> unfortunately puppet is hammering DF
[17:21] <gary_poster> 2.77 s, 1.71 s, 1.51 s
[17:21] <gary_poster> so no proof yet
[17:21] <bigjools> there must be something else going on here
[17:21] <bigjools> need to find a slow one
[17:22] <rvba> Any private ppa with lots of different packages in it.
[17:24] <bigjools> that you are a member of
[17:27]  * deryck lunches with rick_h_ 
[17:42] <tumbleweed> bigjools: re sponsor-syncs-bug-827555: I assume "UI changes" includes visibility in source_package_publishing_history API objects?
[17:42] <bigjools> tumbleweed: no, web UI
[17:42] <bigjools> the API will be good
[17:43] <tumbleweed> Laney had a look at it and thought this merge wouldn't cover API visibility
[17:43] <bigjools> oh bugger actually I forgot one thing
[17:43] <bigjools> well then he's wrong :)
[17:44] <tumbleweed> :)
[17:44] <bigjools> I forgot to make the syncer known in the spph... darn.  Will fix that Monday.
[17:45] <bigjools> good night all, have a nice weekend
[17:45] <tumbleweed> bigjools: thanks
[17:56] <jcsackett> bac: you free to review https://code.launchpad.net/~jcsackett/launchpad/redundant-message-is-redundant/+merge/84308 by any chance?
[18:03] <bac> jcsackett: sure
[18:20] <bac> jcsackett: done
[18:21] <cjwatson> real    3m23.752s
[18:21] <cjwatson> ^- first cut at replacement for most of cron.germinate
[18:21] <cjwatson> running on my laptop with some stuff involving networking, so I expect cocoplum will be able to do it faster
[18:37] <jcsackett> thanks, bac.
[18:38] <cjwatson> 3m9s once I ensure everything's mirrored locally
[18:39] <cjwatson> that's with the major structural optimisations; there's surely still room for profiling
[18:57] <deryck> bac, hi.  rick_h_ and I have a branch for review if you have the time.
[18:57] <bac> deryck: sure do
[18:57] <deryck> bac, Thanks!  https://code.launchpad.net/~deryck/launchpad/buglists-loading-885272-final/+merge/84183
[18:59] <deryck> bac, and sorry for the length, but it's new js code, so not as much there as the line number indicates.
[18:59] <bac> yowzer!  :)
[18:59] <deryck> heh :)
[19:01] <deryck> rick_h_, https://dev.launchpad.net/Orange/NewStarter
[19:14] <deryck> rick_h_, https://dev.launchpad.net/MaintenanceRotationSchedule
[19:42] <bac> rick_h_, deryck: i don't understand this sentence:
[19:42] <bac> This is using the YUI concept of class extensions to get us min-in like
[19:42] <bac> 225	+     * features from the Widget classes.
[19:42] <bac> "min-in like" ??
[19:42] <rick_h_> max-in
[19:42] <rick_h_> mix
[19:43] <rick_h_> that's me, meant mix-in
[19:43] <rick_h_> typo, but we actually ripped that out
[19:43] <bac> oh, ok
[19:43] <rick_h_> so that comment shold go away
[19:43] <rick_h_> should...if I could type
[19:43] <bac> :)
[19:47] <abentley> rick_h_: Nobody's prefect.
[19:48] <abentley> deryck: AFAICT person/+portlet-otherpackages is completely unused, but would be accessible via URL hacking.  Kill it with fire?
[19:49] <deryck> abentley, death die dying dead kill it :)
[19:55] <bac> rick_h_: Did Deryck write this or are you speaking Southern now?  "// Mess with the position of target div."
[19:56] <deryck> heh
[19:56] <rick_h_> bac: lol, I don't know, it is late in the week and I've been hearing too much twang this week
[19:56] <deryck> I think I wrote that, bac
[19:56] <flacoste> bac: there is https://code.launchpad.net/~flacoste/launchpad/self-hosted-3rd-party-js/+merge/84319 in needs of a reviewer when you are free
[19:57] <bac> flacoste: ok.
[19:58] <bac> deryck: I see this a few times:  Assert.isFalse(this.indicator.get('visible'), 'visible is not set');
[19:58] <bac> Isn't the error message backwards?  The assert fails because visible is set.
[19:58] <rick_h_> the message was more a helper for us to see in the log that it came back wrong
[19:58] <rick_h_> because that onlyshows when it failed
[19:59] <bac> rick_h_: right, but it seems the message is backwards
[19:59] <rick_h_> so "what we did wrong" vs "what is the actual check"
[19:59] <deryck> bac, yeah, what rick_h_ says. I'd prefer to drop the message.  It is backwards, but it was meant more has "did the visible check fail or the other assert fail"
[19:59] <deryck> s/has/as/
[20:06] <bac> flacoste: is the diff correct?  1921 lines?  (i suspect it is)
[20:08] <flacoste> bac: probably, i haven't checked the number of lines, but most is ignorable, unless you want to review obfuscate Google GS code ;-)
[20:09] <flacoste> JS
[20:09] <bac> GoogleScript -- its coming
[20:16] <jcsackett> bac: isn't it called Dart? :-P
[20:18] <bac> flacoste: what is this doing, in the CSS?
[20:18] <bac> src: local('Ubuntu Italic'), local('Ubuntu-Italic'), url('https://themes.googleusercontent.com/static/fonts/ubuntu/v3/kbP_6ONYVgE-bLa9ZRbvvvesZW2xOQ-xsNqO47m55DA.woff') format('woff');
[20:18] <bac> flacoste: it is still loading from google, no?
[20:18] <flacoste> bac: is is, but that's the web font specification
[20:18] <bac> but just the font file, so it is ok?
[20:18] <flacoste> which shouldn't be a problem
[20:18] <flacoste> right
[20:18] <flacoste> only the font file
[20:19] <bac> ok, that was the only suspect thing i saw
[20:19] <flacoste> CSS can be used to load JS extensions
[20:19] <flacoste> so that's why we removed the external CSS loading
[20:19] <bac> right
[20:19] <flacoste> but i'm not aware of any such vulnerability in woff
[20:20] <flacoste> so there have been a bunch of vulnerability in woff decoders over the years
[20:20] <flacoste> but that's usually in the form of a local exploit, rather than an attack against the site linking to it
[20:21] <flacoste> although one could say that if I root your browser, it's as good as if I could execute JS in it
[20:21] <flacoste> but i don't think we should care about that
[20:28] <rick_h_> flacoste: did we look at caja or adsafe for running 3rd party JS safely?
[20:28] <rick_h_> flacoste: or just mandate it's not friendly regardless of method of inclusion?
[20:30] <flacoste> rick_h_: we haven't
[20:32] <nigelb> jml: Can you turn off the logging to errors only?
[20:32] <nigelb> jml: Nevermind, stale scrollback :/
[20:32] <flacoste> rick_h_: caja looks nice
[20:33] <rick_h_> flacoste: yea, watched a yui video from crockford that mentioned those last night
[20:33] <rick_h_> and wondered if they might help us keep some 3rd party js in a safe manner
[20:38] <flacoste> i think it does
[20:38] <flacoste> since you can deny the contained JS access to the user cookies
[20:38] <flacoste> which is what we are protecting for
[20:39] <flacoste> because if you have the user's cookie, you can basically do anything you can over the API or web as that user
[20:39] <flacoste> which is a lot
[21:06] <sinzui> If we had a charm to setup caja scripts, we could call it cajajuju. I would put a Kajagoogoo easter egg on the page. The "Too shy" song would play when your mouse crossed the 3rd party cookies text the description
[21:09] <abentley> bac: could you please review https://code.launchpad.net/~abentley/launchpad/packagebugs/+merge/84329 ?
[21:10] <bac> abentley: yes
[21:10] <abentley> bac: thanks.
[21:48] <bac> abentley: done,  thanks.
[21:49] <deryck> bac, FWIW img is a naturally self closing tag. ;)
[21:49] <bac> deryck: :)
[21:49] <deryck> bac, but I changed div to match.  I'm actually not that strongly opinionated about that, despite any past statements of mine. :)
[21:50] <bac> deryck: it is not something to get too worked up about!
[21:50] <deryck> indeed
[21:50] <deryck> YUI itself uses both forms.
[21:51] <abentley> bac: thanks.
[21:52] <abentley> bac: I extracted that code with minimal changes, but I'm happy to tweak its handling of "advanced".
[21:52] <bac> abentley: your call.
[21:53] <abentley> bac: I think it actually makes more sense to do that by doing params['advanced'] = '1'
[21:53] <bac> abentley: +1
[23:18] <wgrant> flacoste: I don't believe you can do that.
[23:18] <wgrant> flacoste: The font names are not meant to be staitc.
[23:21] <wgrant> I'm glad we're going to send all our private URLs and other data to Google again :)
[23:32] <lifeless> wgrant: you know we have google dcs etc
[23:32] <lifeless> *docs*
[23:32] <lifeless> wgrant: ga getting our data wasn't ever an issue; the risks around site compromise were
[23:33] <wgrant> Sure, but I still don't like it at all :)