[00:01] wallyworld_: Haha, did you miss buildbot on purpose? [00:02] StevenK: yes. i didn't want to risk any failure [00:02] you never know... [00:03] Heh, fair enough [00:47] * StevenK re-reads the feature flag destruction diff, trying to figure out how to QA it [01:11] 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] StevenK: You fail at vhosts [01:13] Oh, bloody translations! [01:13] wgrant: You need to land your branch to remove them all already [01:18] Heh [01:22] wgrant: I've done my QA, the deployment report is full green. [01:27] StevenK: Great. [02:54] StevenK: https://code.launchpad.net/~wgrant/launchpad/no-ibug-private-default/+merge/118661 [02:56] wgrant: r=me [02:59] StevenK: Thanks [03:02] wgrant, is that going to break PES scripts again? ;) [03:02] It is not. [03:03] cody-somerville: you know we have 'break PES today!' printed out above our desks... [03:03] It's the proper fix to the quick fix that sinzui did this morning. [03:03] It doesn't delete the tests he added, fortunately. [03:03] :-) [03:03] love you guys [03:03] Oh, you're just saying that. [03:04] In related news, Launchpad is not software; it's a minefield of fail-open, non-defensive, untested hacks. :) [03:15] lib/lp/bugs/tests/test_bugtarget2.py [03:15] wut [03:16] test_bugtarget2? === michaelh is now known as michaelh|away [05:50] 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] wgrant: Swap you, https://code.launchpad.net/~stevenk/launchpad/format-imports-once-more/+merge/118674 [05:52] About half of those are my fault [05:52] But I ran it... [05:52] oh, not after I moved that last thing from model to interfaces [05:52] r=me, anyway [05:57] WTF, I see what you mean about test_bugtarget2 [05:59] I might merge them later. [05:59] I'm not really happy about IBugTarget.createBug(), but bloody heck, it's tons better than what was there. [06:00] StevenK: Well, compare to the product/distribution/distributionsourcepackage implementations [06:00] Which all reduce to that in the new API [06:00] Yes, that's exactly what I mean. [06:01] Why not move IllegalTarget out to bugs.errors? Branch too large already? [06:02] StevenK: The other similar bugtask edit errors are in interfaces.bugtask [06:02] They should probably all be moved eventually. [06:02] But not now. [06:03] wgrant: Not fair that you keep finding problems with my branches, and I can't with yours. :-) r=me [06:03] Heh [06:03] Thanks. [06:04] 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] wgrant: QA, and then we can deploy again. [06:14] StevenK: Indeed. [07:21] good morning === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban* (rvba) | Firefighting: - | Critical bugs: 4.0*10^2 [10:48] what are the exact cross-domain limits on JS based POSTs? [10:48] (for error reporting via JS) - doing massive gets is unappealing. [10:48] * lifeless goes - will look for replies in morning [11:05] 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] jcsackett: ping morning, got questions for you when you get a sec [13:46] rick_h_: Pong. PM, or G+? [13:47] jcsackett: I'll G+ you in a sec, trying to get these rollbacks going [13:47] Ok. [13:47] meh, diffs taking forever to update, should be quick. [13:51] jcsackett: invite sent === abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban* (rvba), abentley | Firefighting: - | Critical bugs: 4.0*10^2 === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugs: 4.0*10^2 [17:28] sinzui: ping [17:32] hi rick_h_ [17:32] hi rick_h_ [17:33] sinzui: hey, PM [17:34] I have no meeting tomorrow so PM is fine [17:34] sinzui: ok cool thanks [17:35] sinzui: deryck is afk so can't verify, but told him to expect to set aside some time so should be good [18:35] rick_h_: thanks [18:36] lifeless: np, something I've battled and just a pita :/ [18:36] 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] rick_h_: well, we can trivially [18:38] rick_h_: but I'd like to offer a single instance forall canonical sites by preference [18:39] 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] rick_h_, sounds a bit like errormator i need to work on JS client though ;-) [18:41] Ergo^: yea, to an extent [18:42] http://www.olark.com/spw/2012/03/dont-break-the-internet-with-your-javascript/ is an interesting read along the lines [18:49] rick_h_: this is for lp:js-oopsd btw, considering tweaks + we need the JS side of it [18:50] lifeless: cool, assumed it was oops related. Will peek at the project [19:26] abentley: quick question about the branch scanner (the new celery based code [19:26] are they long-lived processes? [19:26] jam: all ears. [19:27] jam: Not generally. Sometimes branch scans are long, but otherwise no. [19:28] jam: Well, actually, the worker threads and daemon are long lived. [19:28] jam: But they're managed by celeryd and we can control how often they expire. [19:30] abentley: https://pastebin.canonical.com/71417/ [19:30] I'm confused by the '-idle-' [19:31] 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] jam: I'm confused that they're running at all. [19:32] those might be celeryd processes vs branch scanner processes? [19:32] 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] jam: It looks like a worker process that hasn't done anything yet. [19:40] 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] I guess running: CeleryRunJobIgnoreResult [19:40] jam: That's right. [19:41] jam: Yeah, I suppose that dates from the last time we tried enabling it. [19:43] jam: Actually, the Feature Flag still shows branch scan jobs enabled. I don't understand why. (jobs.celery.enabled_classes) [20:09] jcsackett: ping [20:16] rick_h_: wow, the w3c have really forgotten how to write specs. [20:16] http://www.w3.org/TR/cors/#preflight-request is giving me a headache [20:17] lifeless, yeah cors is PITA and doesnt work in every browser as advertised ;-) === mbarnett` is now known as mbarnett [20:22] Ergo^: its the green and blue presentation that is breaking me [20:22] 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] Would be much better done as: [20:23] * header field names are compared insensitively between CORS supplied references and actual HTTP headers. [20:24] * 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] or something [20:25] 'if not A and not B =>' <==> 'not (A OR B)' [20:25] I shouldn't need to do boolean rearrangements to their rules to make them understandable! :) [20:40] jcsackett: about out branch in review. the issue is not about read-only [20:41] jcsackett: as a driver of a project, I can see who the project shares with, but I cannot edit === abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2 === michaelh|away is now known as michaelh [21:04] sinzui: the "clickable_content" on +sharing is the little tag thing that shows the information. [21:04] with this change, it doesn't look editable, which it shouldn't, per the reported bug. [21:05] clickable_content is how our flag works, which is why i mentioned writable in the MP. [21:18] 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] sinzui: they can't edit on production, or at all? [21:25] qastaging [21:25] permission denied getting to the page. [21:26] 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] sinzui: dig. so we actually have new issues, not an issue with this branch. [22:03] Um [22:03] what [22:03] jam: To clarify, we've been running branch scan jobs through celery on production for at least several weeks. [22:03] jam: The processes are meant to be long-running. [22:03] They're daemons. [22:27] sinzui: wgrant: jcsackett: @enabled_with_permission('launchpad.Driver') [22:27] def sharing(self): [22:27] text = 'Sharing' [22:27] enabled_readonly_flag = 'disclosure.enhanced_sharing.enabled' [22:27] enabled_writable_flag = 'disclosure.enhanced_sharing.writable' [22:27] enabled = (bool(getFeatureFlag(enabled_readonly_flag)) [22:27] or bool(getFeatureFlag(enabled_writable_flag))) [22:27] return Link('+sharing', text, icon='edit', enabled=enabled) [22:35] 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] the long-livedness means as time => infinity, we're likely to see all the processes get pretty darn big [22:36] (if we still have the ulimit set, I guess that kills them off eventually) [22:36] * jam sleeps [22:37] 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] But I believe it handles that automatically. [22:40] (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] 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] 'make' should do it, if you've used rocketfuel-get or an equivalent. [22:43] 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] wgrant, thanks.. will give that a try.. [22:44] wgrant, cjwatson, what's rocketfuel-* ? [22:45] cgoldberg: The LP dev setup script that most people use [22:45] As described on https://dev.launchpad.net/Running [22:45] wgrant, should i go that route, or just branch and compile? [22:46] wgrant, thanks.. *thats* the page i was looking for [22:46] As the page says, it's recommended to run LP in a Lucid LXC container on a Precise system, using rocketfuel-setup. [22:48] i'm just working with pageperformance reports. it's a utility, so not sure I need a running LP. thanks though. [22:49] cgoldberg: btw this is why I said to move it to lp-dev-utils first :) [22:49] cgoldberg: gets you out of the heinous LP environment [22:50] 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] lp-dev-utils should have a test runner already [22:50] but if it doesn't, just use python -m testtools.run [22:51] lifeless, ah perfect.. I'm gonna go that route (move to lp-dev-utils) [22:51] cgoldberg: if you have trouble, I can do the initial move for you if you want. [22:51] lifeless, doubt I'll have trouble.. but that would certainly be helpful, as I'm not quite sure where you want them [22:52] cgoldberg: ok, I'll do it later today [22:52] lifeless.. sweet.. thanks much