[00:01] <StevenK> wallyworld_: Haha, did you miss buildbot on purpose?
[00:02] <wallyworld_> StevenK: yes. i didn't want to risk any failure
[00:02] <wallyworld_> you never know...
[00:03] <StevenK> Heh, fair enough
[00:47]  * StevenK re-reads the feature flag destruction diff, trying to figure out how to QA it
[01:11] <StevenK> wgrant: Hm, neither https://qastaging.launchpad.net/ubuntu/+source/evolution/+sharing-details or https://qastaging.launchpad.net/ubuntu/precise/+source/evolution/+sharing-details works, and I'd expect them too
[01:13] <wgrant> StevenK: You fail at vhosts
[01:13] <StevenK> Oh, bloody translations!
[01:13] <StevenK> wgrant: You need to land your branch to remove them all already
[01:18] <wgrant> Heh
[01:22] <StevenK> wgrant: I've done my QA, the deployment report is full green.
[01:27] <wgrant> StevenK: Great.
[02:54] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/no-ibug-private-default/+merge/118661
[02:56] <StevenK> wgrant: r=me
[02:59] <wgrant> StevenK: Thanks
[03:02] <cody-somerville> wgrant, is that going to break PES scripts again? ;)
[03:02] <StevenK> It is not.
[03:03] <lifeless> cody-somerville: you know we have 'break PES today!' printed out above our desks...
[03:03] <wgrant> It's the proper fix to the quick fix that sinzui did this morning.
[03:03] <wgrant> It doesn't delete the tests he added, fortunately.
[03:03] <cody-somerville> :-)
[03:03] <cody-somerville> love you guys
[03:03] <StevenK> Oh, you're just saying that.
[03:04] <wgrant> In related news, Launchpad is not software; it's a minefield of fail-open, non-defensive, untested hacks. :)
[03:15] <wgrant> lib/lp/bugs/tests/test_bugtarget2.py
[03:15] <wgrant> wut
[03:16] <wgrant> test_bugtarget2?
[05:50] <wgrant> StevenK: Mildly oversized (due to largely mechanical test changes) cleanup MP at https://code.launchpad.net/~wgrant/launchpad/createBugParams-target/+merge/118673, if you're still reviewing
[05:51] <StevenK> wgrant: Swap you, https://code.launchpad.net/~stevenk/launchpad/format-imports-once-more/+merge/118674
[05:52] <wgrant> About half of those are my fault
[05:52] <wgrant> But I ran it...
[05:52] <wgrant> oh, not after I moved that last thing from model to interfaces
[05:52] <wgrant> r=me, anyway
[05:57] <StevenK> WTF, I see what you mean about test_bugtarget2
[05:59] <wgrant> I might merge them later.
[05:59] <StevenK> I'm not really happy about IBugTarget.createBug(), but bloody heck, it's tons better than what was there.
[06:00] <wgrant> StevenK: Well, compare to the product/distribution/distributionsourcepackage implementations
[06:00] <wgrant> Which all reduce to that in the new API
[06:00] <StevenK> Yes, that's exactly what I mean.
[06:01] <StevenK> Why not move IllegalTarget out to bugs.errors? Branch too large already?
[06:02] <wgrant> StevenK: The other similar bugtask edit errors are in interfaces.bugtask
[06:02] <wgrant> They should probably all be moved eventually.
[06:02] <wgrant> But not now.
[06:03] <StevenK> wgrant: Not fair that you keep finding problems with my branches, and I can't with yours. :-)  r=me
[06:03] <wgrant> Heh
[06:03] <wgrant> Thanks.
[06:04] <wgrant> Next I'm going to fix the factory method that I mentioned (which has irked me for years -- makeBugTask takes target=, makeBug doesn't), and I hate to think how big the branch will be...
[06:11] <StevenK> wgrant: QA, and then we can deploy again.
[06:14] <wgrant> StevenK: Indeed.
[07:21] <adeuring> good morning
[10:48] <lifeless> what are the exact cross-domain limits on JS based POSTs?
[10:48] <lifeless> (for error reporting via JS) - doing massive gets is unappealing.
[10:48]  * lifeless goes - will look for replies in morning
[11:05] <rick_h_> lifeless: proxy on the server in the end: http://stackoverflow.com/questions/6812331/cross-domain-ajax-post-call has most of the details but browser support for the headers are limited
[11:58] <rick_h_> jcsackett: ping morning, got questions for you when you get a sec
[13:46] <jcsackett> rick_h_: Pong. PM, or G+?
[13:47] <rick_h_> jcsackett: I'll G+ you in a sec, trying to get these rollbacks going
[13:47] <jcsackett> Ok.
[13:47] <rick_h_> meh, diffs taking forever to update, should be quick.
[13:51] <rick_h_> jcsackett: invite sent
[17:28] <rick_h_> sinzui: ping
[17:32] <sinzui> hi rick_h_
[17:32] <sinzui> hi rick_h_
[17:33] <rick_h_> sinzui: hey, PM
[17:34] <sinzui> I have no meeting tomorrow so PM is fine
[17:34] <rick_h_> sinzui: ok cool thanks
[17:35] <rick_h_> sinzui: deryck is afk so can't verify, but told him to expect to set aside some time so should be good
[18:35] <lifeless> rick_h_: thanks
[18:36] <rick_h_> lifeless: np, something I've battled and just a pita :/
[18:36] <rick_h_> wish we were a true middleware shop and could just build a wsgi middleware to include that could catch/handle all JS error/debug requests and do the proxy for you
[18:38] <lifeless> rick_h_: well, we can trivially
[18:38] <lifeless> rick_h_: but I'd like to offer a single instance forall canonical sites by preference
[18:39] <rick_h_> yea, looked at building something like that at my last job using a wsgi middleware on a pylons stack that required a js library and wsgi middleware hookup to function
[18:41] <Ergo^> rick_h_, sounds a bit like errormator i need to work on JS client though ;-)
[18:41] <rick_h_> Ergo^: yea, to an extent
[18:42] <rick_h_> http://www.olark.com/spw/2012/03/dont-break-the-internet-with-your-javascript/ is an interesting read along the lines
[18:49] <lifeless> rick_h_: this is for lp:js-oopsd btw, considering tweaks + we need the JS side of it
[18:50] <rick_h_> lifeless: cool, assumed it was oops related. Will peek at the project
[19:26] <jam> abentley: quick question about the branch scanner (the new celery based code
[19:26] <jam> are they long-lived processes?
[19:26] <abentley> jam: all ears.
[19:27] <abentley> jam: Not generally.  Sometimes branch scans are long, but otherwise no.
[19:28] <abentley> jam: Well, actually, the worker threads and daemon are long lived.
[19:28] <abentley> jam: But they're managed by celeryd and we can control how often they expire.
[19:30] <jam> abentley: https://pastebin.canonical.com/71417/
[19:30] <jam> I'm confused by the '-idle-'
[19:31] <jam> I was trying to figure out some of the recent 'things are swapping' issues. It claimed to be swapping at 1GB, but it seems ilke it 'idles' at 500MB
[19:31] <abentley> jam: I'm confused that they're running at all.
[19:32] <jam> those might be celeryd processes vs branch scanner processes?
[19:32] <abentley> jam: I talked to a webops like a week ago and said we should kill them until we are ready to do branch scanning via celeryd
[19:32] <abentley> jam: It looks like a worker process that hasn't done anything yet.
[19:40] <jam> abentley: so we aren't actually doing branch scanner in celery, we just have a celeryd worker group that is sort of sitting around?
[19:40] <jam> I guess running: CeleryRunJobIgnoreResult
[19:40] <abentley> jam: That's right.
[19:41] <abentley> jam: Yeah, I suppose that dates from the last time we tried enabling it.
[19:43] <abentley> jam: Actually, the Feature Flag still shows branch scan jobs enabled.  I don't understand why.  (jobs.celery.enabled_classes)
[20:09] <abentley> jcsackett: ping
[20:16] <lifeless> rick_h_: wow, the w3c have really forgotten how to write specs.
[20:16] <lifeless> http://www.w3.org/TR/cors/#preflight-request is giving me a headache
[20:17] <Ergo^> lifeless, yeah cors is PITA and doesnt work in every browser as advertised ;-)
[20:22] <lifeless> Ergo^: its the green and blue presentation that is breaking me
[20:22] <lifeless> and clauses like "If the field name of each header in author request headers is not an ASCII case-insensitive match for one of the header field names in headers and the header is not a simple header, apply the cache and network error steps."
[20:22] <lifeless> Would be much better done as:
[20:23] <lifeless> * header field names are compared insensitively between CORS supplied references and actual HTTP headers.
[20:24] <lifeless> * If a complex header is named in the author request headers but not supplied in the response, apply cache and network error handling.
[20:24] <lifeless> or something
[20:25] <lifeless> 'if not A and not B =>' <==> 'not (A OR B)'
[20:25] <lifeless> I shouldn't need to do boolean rearrangements to their rules to make them understandable! :)
[20:40] <sinzui> jcsackett: about out branch in review. the issue is not about read-only
[20:41] <sinzui> jcsackett: as a driver of a project, I can see who the project shares with, but I cannot edit
[21:04] <jcsackett> sinzui: the "clickable_content" on +sharing is the little tag thing that shows the information.
[21:04] <jcsackett> with this change, it doesn't look editable, which it shouldn't, per the reported bug.
[21:05] <jcsackett> clickable_content is how our flag works, which is why i mentioned writable in the MP.
[21:18] <sinzui> jcsackett: yep, and I see that is what the sharing table used. I think we have another bug. drivers should be seeing that page and they cannot edit. I suspect our code does not know what to do with drivers at all
[21:25] <jcsackett> sinzui: they can't edit on production, or at all?
[21:25] <sinzui> qastaging
[21:25] <sinzui> permission denied getting to the page.
[21:26] <sinzui> I see lots of things wrong with drivers that our squad needs to discuss. We will also discuss going to maintenance instead of working on disclosure
[21:33] <jcsackett> sinzui: dig. so we actually have new issues, not an issue with this branch.
[22:03] <wgrant> Um
[22:03] <wgrant> what
[22:03] <wgrant> jam: To clarify, we've been running branch scan jobs through celery on production for at least several weeks.
[22:03] <wgrant> jam: The processes are meant to be long-running.
[22:03] <wgrant> They're daemons.
[22:27] <wallyworld_> sinzui: wgrant: jcsackett:     @enabled_with_permission('launchpad.Driver')
[22:27] <wallyworld_>     def sharing(self):
[22:27] <wallyworld_>         text = 'Sharing'
[22:27] <wallyworld_>         enabled_readonly_flag = 'disclosure.enhanced_sharing.enabled'
[22:27] <wallyworld_>         enabled_writable_flag = 'disclosure.enhanced_sharing.writable'
[22:27] <wallyworld_>         enabled = (bool(getFeatureFlag(enabled_readonly_flag))
[22:27] <wallyworld_>             or bool(getFeatureFlag(enabled_writable_flag)))
[22:27] <wallyworld_>         return Link('+sharing', text, icon='edit', enabled=enabled)
[22:35] <jam> lifeless: ^^ see wgrant's comments. So should we a) change them from long-lived because they waste the memory, or b) just shove more RAM into the box?
[22:36] <jam> the long-livedness means as time => infinity, we're likely to see all the processes get pretty darn big
[22:36] <jam> (if we still have the ulimit set, I guess that kills them off eventually)
[22:36]  * jam sleeps
[22:37] <wgrant> jam, lifeless: Killing the processes is probably stupid; we need a few spare workers to avoid paying the startup time for every scan. But they shouldn't grow infinitely, and it should probably only keep a few around.
[22:37] <wgrant> But I believe it handles that automatically.
[22:40] <wgrant> (I'll talk to Aaron and Abel tonight about this, since they were the ones that set it up on prod, but seem to not know that it's set up on prod)
[22:40] <cgoldberg> hello.  I am trying to run the tests for pageperformancereport.  looks like I need to run buildout first?  all I've done so far is an initial checkout/branch.. any tips on how to run buildout/bootstrap so I can run `bin/test`?
[22:42] <cjwatson> 'make' should do it, if you've used rocketfuel-get or an equivalent.
[22:43] <wgrant> cgoldberg: If you haven't used rocketfuel-setup, you'll need to 'bzr branch lp:lp-source-dependencies download-cache', utilities/update-sourcecode, make compile
[22:44] <cgoldberg> wgrant, thanks.. will give that a try..
[22:44] <cgoldberg> wgrant, cjwatson, what's rocketfuel-* ?
[22:45] <wgrant> cgoldberg: The LP dev setup script that most people use
[22:45] <wgrant> As described on https://dev.launchpad.net/Running
[22:45] <cgoldberg> wgrant, should i go that route, or just branch and compile?
[22:46] <cgoldberg> wgrant, thanks.. *thats* the page i was looking for
[22:46] <wgrant> As the page says, it's recommended to run LP in a Lucid LXC container on a Precise system, using rocketfuel-setup.
[22:48] <cgoldberg> i'm just working with pageperformance reports.  it's a utility, so not sure I need a running LP.  thanks though.
[22:49] <lifeless> cgoldberg: btw this is why I said to move it to lp-dev-utils first :)
[22:49] <lifeless> cgoldberg: gets you out of the heinous LP environment
[22:50] <cgoldberg> lifeless... what does bin/test do?  how can I port the tests so it works in lp-dev-utils?  what kinda test runner will I need?
[22:50] <lifeless> lp-dev-utils should have a test runner already
[22:50] <lifeless> but if it doesn't, just use python -m testtools.run
[22:51] <cgoldberg> lifeless, ah perfect.. I'm gonna go that route (move to lp-dev-utils)
[22:51] <lifeless> cgoldberg: if you have trouble, I can do the initial move for you if you want.
[22:51] <cgoldberg> lifeless, doubt I'll have trouble.. but that would certainly be helpful, as I'm not quite sure where you want them
[22:52] <lifeless> cgoldberg: ok, I'll do it later today
[22:52] <cgoldberg> lifeless.. sweet.. thanks much