[00:00] any reason we can't run it right after ? [00:01] It'd run into the 0902 run, so that wouldn't happen. [00:03] wgrant: can has review? [00:03] lifeless: Sorry, missed that. Will look in a sec. [00:03] Just fixing test failures from yesterday's largish branch series. [00:23] lifeless: Could you do the sort of query that jtv asked for https://code.launchpad.net/~jtv/launchpad/bug-613823/+merge/75773? [00:23] lifeless: The approver is cronned on staging. [00:23] wgrant: hmm ? [00:24] lifeless: There are QA instructions in that MP. [00:24] I don't have staging DB access. [00:24] sorry to be a nuisance, but can you translate to sql ? [00:25] SELECT * FROM translationimportqueueentry WHERE error_output IS NOT NULL AND status = 5 ORDER BY date_status_changed DESC LIMIT 10; [00:25] 0 [00:26] That's upsetting. I guess I will check it with hloeung later. [00:29] lifeless: Does oops-timeline really only lose us two lines of code? [00:30] wgrant: yes, but it saves duplication for other folk glueing them together [00:30] Two lines of duplication? [00:31] about 10 [00:31] stsly? [00:31] duplication has never been about size of code though [00:31] srsly? [00:35] lifeless: Do our consumers cope with the s/db_statements/timeline/? [00:36] https://code.launchpad.net/~mwhudson/launchpad/feature-flag-xmlrpc/+merge/75673 if anyone is bored... [01:09] wgrant: oops-tools is a version locked buildout project. [01:10] wgrant: it uses datedir-repo which this change doesn't affect, because its not a labelled key in the rfc822 format [01:11] wgrant: that said, I have a branch for it which updates-and-corrects [01:12] wgrant: that also needs a review :) - code.launchpad.net/~lifeless/oops-tools/timeline/+merge/75941 [01:15] mwhudson: ping [01:16] lifeless: hello [01:17] want to talk (you know, by airwaves) about branch access? [01:18] ah sure [01:18] lifeless: mumble/skype/pots [01:18] ? [01:18] the second door [01:18] mwhudson, just a random idea [01:19] is it cleaner to pass a dict that can contain a username and possibly other stuff? [01:19] i don't know if that will be easier to evolve or not [01:19] poolie: what would the values in the dictionary be? [01:19] objects! [01:19] username='mbp' client_ip='1.2.3.4' [01:19] etc [01:19] ah [01:19] bzr_version='2.4.4' [01:19] lifeless: haha, this is xmlrpc [01:23] #quotes [01:27] lifeless: Ahh, so it doesn't actually make a difference in the serialised format? [01:34] right [01:59] wgrant: were you going to review the oops-tools one too ? [02:01] lifeless: Done. [02:05] Oh look, pocketlint deals with JS. [02:05] If only I knew that on Friday. [02:05] heh [02:06] What happened on Friday? [02:06] Also, I thought pocketlint dealing with JS was one of its biggest advantages. [02:07] I was dealing with the same JS branch, but I had broken the JS badly so Firefox didn't love me and refused to render the page [02:07] Ouch. [02:07] Didn't firebug help? [02:07] No, it just told me I had a syntax error on line 68,000 something [02:08] Which wasn't very handy [02:08] Yeah. [02:08] I like how firebug throws a weird bug when you make a mistake in JSON. [02:08] I spent about 20 minutes for that, until I discovered jsonlint helps. [02:09] StevenK: But if you click on the error it should take you to that line, letting you debug it. [02:09] Not like that's easy either. [02:09] Anyway, pocketlint has solved my issue. [02:10] :) [02:10] I hope noone stabs me for the number of revisions I've made undeployable. [02:11] You've only made 13 undeployable, which is probably the least I've seen from non-APAC breakage. [02:11] I get stabby when it gets above 50. [02:11] non-APAC? [02:12] APAC is Asia-Pacific [02:12] US/EU breakage often gets nasty. [02:12] "technically" I live in APAC [02:12] Well, yeah. [02:12] Just! [02:12] easily [02:12] asia goes -way- west [02:12] Shh. [02:13] Middle east is west of me. [02:13] So, i'm not "just" Asia :P [02:14] isn't it to the bosphorus? [02:14] Yeah [02:14] beautiful river [02:15] lifeless: At some point I need to pick your brain further re:js-oopsd [02:15] But at a later point when I'm not sleep deprived! [02:18] reprocess-hwdb-submissions is doing well for itself. [02:18] 90272 None: None [02:19] nigelb: ok [02:22] lifeless: can you tell me the code that gets invoked when serving loggerhead pages like to http://bazaar.launchpad.net/~johndoe/project/files [02:22] wallyworld___: You're trying to add the privacy overlay thing? [02:22] yes [02:22] Run away. [02:23] We have no loggerhead customisation story these days :/ [02:23] * wallyworld___ starts running === wallyworld___ is now known as wallyworld [02:23] Which means we have to copy the LP-specific template and JS into the loggerhead tree. And have it there polluting everyone's installations. [02:23] Even though it's only relevant to us. [02:23] And our theme. [02:23] yuck [02:23] Can't fork it? === wallyworld is now known as Guest73189 [02:24] Forking it is not a good option. [02:24] Like have a branch with launchpad changes, and keep merging trunk into it. [02:24] We should have an alternate theme. [02:24] Well. [02:24] Really we should use LH as a service. [02:24] erm [02:24] And import it into the LP UI. [02:24] right [02:24] if request is a ILaunchpadRequest, what is request.principal? [02:24] But that may happen in three decades. [02:24] the ideal thing is to make LH a background service. [02:24] Until then we need something better. [02:24] mwhudson: *probably* an IAccount. [02:24] in the mean time, we a) maintain loggerhead, b) deploy trunk. [02:24] mwhudson: Or it may have an adapter to IAccount. [02:25] AH [02:25] Guest73189: your nick is bust :) [02:25] yeah :-( [02:25] keeps happening [02:25] So logggerhead won't actually show files form a private branch? [02:25] nigelb: It does. [02:25] nigelb: It just doesn't say that it's private. [02:25] AHH. [02:26] wgrant: ah, it's a ILaunchpadPrincipal [02:26] Stupid question - Isn't loggerhead already a service? [02:26] (well, if it's not unauthenticated) [02:26] mwhudson: Does that handle stuff like IWeaklyAuthenticatedPrincipal? [02:27] (which should really be INotActuallyAuthenticatedAtAllPrincipalButSomePeopleApparentlyCannotHandleEmailSigningBecauseTheyLikeToUseGmail, but that's a bit long) [02:27] heh [02:28] wgrant: basically [02:28] i have a request [02:28] i want a person, or None [02:28] I remember doing this elsewhere. [02:28] nigelb: it is but it displays a web UI of its own [02:29] nigelb: using different templates, middleware, and web stack. [02:29] nigelb: its not a *backend* service that the LP web app can consume [02:29] AHH. [02:29] nigelb: its just a sibling website that happens to be themed the same way [02:29] That means loggerhead should first expose such a service in trunk and then we need to grab that and use that? [02:29] it has a bit of such a service [02:29] it needs more [02:30] and it needs to be -much- faster [02:30] Agree on that one. [02:30] its fast-path is tolerable but its slow path needs to be two orders of magnitude faster [02:34] interesting https://www.facebook.com/notes/facebook-engineering/making-facebook-self-healing/10150275248698920 [02:34] (fwiw, i think IPerson(request.principal, None) is what i want) [02:38] wallyworld__: Can I force an overlay to the top? [02:38] StevenK: you mean so that it always stays on top? [02:39] wallyworld__: Give me a tick, preparing screenshots [02:39] ok [02:41] wallyworld__: http://people.canonical.com/~stevenk/Subscribe-popup.png [02:41] * wallyworld__ looks [02:42] wallyworld__: That's the "before" shot -- it's a private bug and I've clicked the "subscribed to all notifications" link for the popup [02:42] and the confirm overlay appears beneath? [02:42] wallyworld__: http://people.canonical.com/~stevenk/Subscribe-popunder.png [02:42] Needs z-index magic :-) [02:42] StevenK: overlays have a zIndex propety [02:42] * wgrant invokes mpt. [02:42] StevenK: default is 0 [02:43] Oh no, I've angered wgrant. [02:43] Nested overlays... this doesn't seem right. [02:43] StevenK: http://yuilibrary.com/yui/docs/overlay/ [02:43] wallyworld__: Higher is on top, or lower is? [02:44] StevenK: ummmm. higher i *think* [02:45] Higher. [02:45] * nigelb helpfully links to http://www.w3schools.com/cssref/playit.asp?filename=playcss_z-index&preval=2 [02:45] StevenK: sort of agree with wgrant though. i'd like to see the click in the "remove" link result in the confirmation exapnding out below the link via an animation [02:45] Right. [02:45] sort of like for the stuff i did for confirming bug assignees [02:45] The dialog mutate by expanding, or using a second step. [02:45] s/mutate/should mutate/ [02:46] You two suck, or something. [02:46] Dialogs are bad the best of times. [02:46] you've been peeking in my window again haven't you [02:46] Actually, I'll agree with them as well. [02:46] * wallyworld__ needs to close the curtains [02:46] s/two/three/ [02:46] So, StevenK wasted 2 days of JS hacking only to be mpt'd :P [02:47] Not really [02:47] Since there are two callsites [02:47] I always expect a few days of hacking on a new technology to have to be thrown out at least a couple of times. [02:48] And while feature squads seem to like introducing tech debt and terrible UI, I think we should try to do this at least vaguely properly. [02:48] what's tech debt? I see that used in tags. [02:49] Launchpad. [02:49] Heh. [02:49] Launchpad is mostly tech debt. [02:49] http://c2.com/cgi/wiki?TechnicalDebt [02:50] wgrant: I've seen worse. [02:50] lifeless: Huh? [02:50] Where? [02:50] COBOL doesn't count. [02:50] Ah. [02:50] wgrant: minestar [02:50] wgrant: Micropay [02:50] OK, software that isn't meant to be enterprisey? [02:50] wgrant: .... unlike LP ? [02:51] wgrant: win32 api :-) [02:51] Isn't LP the enterprisey codehosting website? ;-) [02:51] LP isn't meant to be enterprisey, I don't think. It is, but I don't think it was meant to be. [02:51] wgrant: and yeah, a few things do come to mind that rival LP for 'wants refactoring soooo bad' [02:51] It may not be meant to be enterprisey, but some of the best features are enterprisey. [02:51] (lp) [02:51] wgrant: see rule #1: all software sucks. [02:52] lifeless: We just have no way to make it not suck. [02:52] Because nobody wants to reduce tech debt. [02:52] Delete more code. That's code that's guaranteed to not suck :-) [02:52] Maintenance squads can't fix it, and feature squads won't. [02:52] => we are fucked [02:52] :) [02:52] Everything will be better when we have no criticals. [02:52] OH WAIT [02:52] Hahahahahahahhaa [02:53] Bwahaha [02:53] I could not help myself ... [02:53] Speaking of which,. [02:53] 390 bugs with tech-debt :/ [02:53] nigelb: And that's mostly just the really bad stuff. === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: -| Critical bugs: 260 - 0:[########*** stack smashing detected ***: ./lp terminated [02:54] Bleh, still 260. [02:54] We are going *backward* [02:54] wgrant: Some seem to be not very had. [02:54] *hard [02:54] nigelb: Some aren't, no. [02:54] nigelb: And even the big stuff is not hard. [02:54] I spent a few hours yesterday and very nearly disposed of Zopeless. [02:54] wgrant: How did that turn out? [02:55] StevenK: Some test failures in the last branch in the series. [02:55] Which removes ZTM's commit/abort/begin methods, and initZopeless' return value. [02:55] Leaving ZTM to be moved into DBConfig in the next branch. [02:55] Still have to strip out Zopeless mail somehow. [02:56] But it's all pretty well detangled now. [02:56] great [02:56] initZopeless' callsites are limited to core base classes and buildd-manager. [02:56] Which means we can finally untangle the damned dbuser handling. [02:56] Which is roughly quadruplicated at the moment. [02:57] poolie: is there a reason that there are scopes team:foo but server.edge? [02:57] And it also means the Zopeless layers can die, which simplifies things a bit. [02:57] i.e. ':' vs '.' [03:01] mwhudson, i don't think there's any really good reason [03:01] you could look at it as 'server_edge=True' vs 'server=edge [03:03] o/ 90K hwdb exceptions [03:04] Yup, the reprocessing seems to be going well... [03:04] 181 AttributeError: 'LaunchpadTimeoutError' object has no attribute '__traceback__' looks suspect [03:04] lifeless: I pointed that out last week, yeah. The attempted reraising is bad. [03:04] __traceback__ was added in 2.7, wasn't it? [03:04] wgrant: did you file a bug ? [03:04] Maybe even 3.x. [03:04] No. [03:04] wgrant: or reopen it ? [03:04] I had three production breakages. [03:04] I'm not criticising [03:05] I'm asking so I don't duplicate work. [03:05] You should have been :P [03:05] I haven't, no. [03:05] Well, really I wanted to see if anyone else would pick it up. [03:05] IIRC benji worked on it ? [03:05] I think that's right. [03:05] lifeless: So, for science, I'd like to leave it a couple of days and see if a maintenance squad notices. [03:06] well [03:06] I've mailed benji [03:07] :( [03:07] SUCCESS! [03:07] My confirmationoverlay works for +subscriptions [03:08] wallyworld__: *prod* [03:08] StevenK: ouch!~ [03:08] StevenK: excellent [03:09] StevenK: you are now a yui expert :-) [03:09] Trapped! :P [03:09] and i'll assign all the js bugs to you! [03:09] wallyworld__: Suggestions about how to break up the form_content in http://pastebin.ubuntu.com/692723/ ? [03:09] * wallyworld__ looks [03:09] wgrant: Deploying today? [03:10] StevenK: you can use a join [03:10] give me a sec and i'll find an example [03:10] nigelb: Funny you should ask. [03:10] 13:09:58 < wgrant> hloeung: We need to do a nodowntime rollout today so we can turn gina on. [03:10] nigelb: So, you weren't quite perfectly timed, but 'tis acceptable. [03:10] wgrant: Almost immediately? :-) [03:11] what channel was that? Canonical IRC? [03:11] Maybe. Some preparation to do, and we are down to one LOSA this week. [03:11] nigelb: Yes, a private one. [03:11] Yeah, that was #launchpad-ops on the Canonical network. [03:11] mwhudson: don't you hate all the boilerplate glue to say 'this code at that endpoint' ? [03:11] lifeless: YES [03:11] StevenK: ah, I have an example of join somewhere I think. [03:11] i used a bit less boilerplate than some though [03:11] StevenK: search for join('') or join("") in js [03:11] there's quite a few places [03:12] some endpoints have the xml-rpc methods in a view on the application endpoint object [03:12] StevenK: you can use string concat if it's only 2-3 lines. [03:12] i just put the methods on the application endpoint object [03:12] StevenK: ['foo', 'bar'].join('') [03:12] but any longer, a join is recommended [03:12] where foo and bar are 50 to 70 chars each. [03:13] wgrant: I'm technically a jQuery person more, but YUI is quite neat :-) [03:13] err [03:13] wallyworld__: ^ [03:14] nigelb: ? [03:14] wallyworld__: I played around a lot with it for that bug title fix. Its different, but now I think in a better way. [03:16] nigelb: oh, you mean you like yui. it's not too bad actually. i think it's 2nd most popular framework behind jQuery [03:16] wallyworld__, nigelb: Fixed, thanks. [03:16] StevenK: \m/ [03:17] I think I need to revert bug_subscription_portlet changes while I work out how to expand it [03:17] Perhaps I'll do the changes in two branches [03:18] mwhudson: I've done a review [03:19] mwhudson: its probably a bit opaque. Two key things - please don't duplicate code (team: magic string handling), and a bit fuzzier one that you may want to ping me on [03:19] lifeless: you have? i don't see a review [03:19] mwhudson: process-incoming.py [03:19] ah [03:19] lifeless: did you see my response to poolie's comments? [03:20] wallyworld__: I'll grab you after lunch on how to test this thing? [03:20] StevenK: ok [03:20] YUI tests! Fun! :-) [03:20] wallyworld__: No promises on where I'll grab you [03:20] yes, I think dict for scopes was confusing (because scopes are containers), but coming from the same place I am [03:20] :-P [03:20] oh, one can only hope [03:21] mwhudson: docs are in docstrings. [03:22] lifeless: were you under the impression that i know what you're talking about? [03:23] mwhudson: yes! [03:23] mwhudson: poolie pointed you at docs, you found an empty file. [03:23] well, i still don't know what needs to be _updated_ [03:23] mwhudson: I believe they are in module docstrings instead [03:23] all the code i added has docstrings [03:23] yes, but nothing points at your code; thats the point I think. [03:24] ah oik [03:24] __init__.py [03:27] lifeless: were you reviewing the originally proposed version, or r13974 ? [03:27] mwhudson: the mailed out version [03:27] lifeless: ok, look again please [03:29] much better [03:45] mwhudson: back to you :) [03:46] lifeless: lol, guess what my working copy looks like [03:47] default_scopes = (DefaultScope(),) [04:00] mwhudson: :) [04:02] lifeless: back to you (hopefully not much more of this) [04:04] mwhudson: your example is missing a : [04:04] 'codehosting.use_forking_server', ['user:' + user_name]) [04:04] -> [04:04] 'codehosting.use_forking_server', ['user:' + user_name]): [04:05] ah [04:05] ok [04:07] lifeless: thanks [04:08] i wonder if i can still land code ... [04:08] should be able to [04:08] have I put you in the emeritus team yet ? [04:08] don't think so [04:09] want me to? [04:09] lifeless: are you aware of a bug report about this? [04:09] about what? [04:09] oh [04:09] uhm [04:09] there may be one [04:09] lifeless: what impact does being the emeritus team have? [04:09] ok, i'll search [04:09] you'll get review mail which we don't [yet] have a good offswitch for [04:10] you get bugcontrol privs, and push privs to ~canonical-launchpad-branches [04:10] mwhudson: ah you are in it [04:10] oh ok [04:10] https://launchpad.net/~canonical-launchpad-emeritus [04:10] i don't get review mail... [04:10] No PQM access? [04:11] (which i am happy with, before you do anything about that :p) [04:11] mwhudson: its not fully setup up :) [04:11] mwhudson: the intent is to get you review privs, which currently implies mail. [04:11] mwhudson: [sorry] [04:11] lifeless: i appear to be able to approve merge proposals [04:12] i am still in ~launchpad mind [04:12] mwhudson: ah, well then :P [04:12] mwhudson: its moot till you leave that [04:12] ok [04:14] StevenK: yes, if pqm is integrated with LP (which it was till the code decided their old automation design was wrong) [04:15] lifeless: Right, so the intent is that canonical-launchpad-emeritus members continue to have PQM? [04:16] StevenK: the intent is that emeritus devs lose nothing if they are still @ canonical, and lose write-to-deployed-branches only, if they are not. [04:16] e.g. be as close to an open source project as we can with our current constraints [04:19] wallyworld__: *grab* [04:19] wallyworld__: Let me just get some tea [04:19] StevenK: oooh. a little hiher [04:19] * StevenK goes to scrub his hands with solvol and steel wool [04:28] StevenK: so you got your tea? [04:29] wallyworld__: Indeed. Ready when you are. [04:30] StevenK: ok, so you want to write a yui test for your confirmation overlay functionality? [04:30] wallyworld__: Yup. I'm on mumble if that makes it simpler. [04:30] StevenK: ok. i'll just grab my headset. one of the kids has nicked it [04:31] Hah [04:42] Ah, finally. [04:42] ~jans has added their OpenPGP key. [04:43] They've uploaded 18 packages this morning. [04:43] Over several hours. [04:43] Causes lots of process-upload cronspam :( [04:43] Hah [04:43] But maybe it will stop now. [04:50] wgrant: Don't you have filters for that sort of thing? [04:52] nigelb: That's one of the few user errors that still generates emails. [04:53] nigelb: I tried to fix it one day, but then found terrible security holes and never visited that code again. [04:54] Ah, I see that sinzui had a productive anti-tech-debt Sunday as well. [04:58] :) [04:58] wgrant: Oh? [04:58] StevenK: You might recall I was talking about pagetitles last week on the call. [04:58] StevenK: sinzui deleted much of it. [04:59] Neat [05:05] wgrant: can you talk to sinzui about blueprints next? [05:05] Heh [05:05] Haha [05:05] Just delete the folder? [05:05] I can do that. :P [05:05] mwhudson: You want blueprints deleted? [05:05] Damn, ZTM will probably fall tomorrow. Then I'll need to find another target for my wrath :( [05:06] wgrant: lib/canonical [05:06] StevenK: canonical.lp no longer exists in devel... will that do? [05:06] WHAT [05:06] !! [05:07] canonical.lp, not canonical.launchpad :( [05:07] Ah! [05:07] wgrant: actually, talk to him about ILaunchBag [05:07] I did wonder if I patched something in canonical.launchpad only for you to delete it. [05:07] mwhudson: I've tried to rip out bits of that myself, but it's not easy :( [05:08] ZTM was pretty easy, just very involved and tedious. [05:08] ILaunchBag needs to die [05:08] Wait ILaunch*Bag*? [05:08] I first read it as Bug and I was WTF. [05:08] It's like a global variable, except more subtly hidden. [05:08] wgrant: s/getUtility(ILaunchBag).user/IPerson(get_current_browser_request(), None)/ should do a bunch of it [05:09] but you might get a million tests to fix [05:09] mwhudson: Also doesn't catch non-browser users. [05:09] eg. the email interface uses LaunchBag in places. [05:09] Because why not. [05:09] ah, this relates to that other bug [05:09] scripts don't do participations rite [05:10] Scripts do a lot of things not right. [05:10] I need to talk to Zope people about zope.app.testing.functional.FunctionalTestSetup, too. [05:10] Or maybe just replace FunctionalLayer with ZopelessLayer and see what blows up. [05:10] https://bugs.launchpad.net/launchpad/+bug/623199 [05:10] <_mup_> Bug #623199: scripts do not establish valid zope partiticipations < https://launchpad.net/bugs/623199 > [05:10] Ah [05:16] * mwhudson evaporates [05:17] * wgrant gets the condensor. [05:30] wallyworld__: How can I determine what to put in Y.one() for the overlay? [05:30] StevenK: Y.one('#id') where id is the overlay id if you know it [05:30] StevenK: or Y.one('.yui3-overlay-xxxx') where xxx is the class [05:31] Yes, my question is how to determine the overlay id, since I don't [05:31] StevenK: you can set the id. give me a minute to check [05:33] StevenK: you have a content_box which you create -eg Y.Node.create("
") [05:33] StevenK: then you can create the overlay, telling it to use this content_box [05:34] see picker_patcher.js around line 54 [05:34] this creates an Activator but the concept is the same I think [05:36] var co = Y.one('.yui3-overlay-confirmationoverlay'); [05:36] Y.Assert.isNull(co); [05:36] wallyworld__: ^ [05:36] StevenK: are you saying the asset fails? or passes? [05:37] I'm not saying either yet, I'm saying that the code I have at the moment. [05:37] or that's what you are proposing [05:37] ? [05:37] ah. that will work if there's only one confirmation overlay [05:38] otherwise you will need to set the content box [05:38] in the initialisation params [05:38] of the overlay [05:39] If the subscription js is creating two confirmation overlays, that is news to me [05:40] StevenK: i mean on the page. so long as the node used as the root for .one() is correctly set it will work [05:40] ie use can use Y.one() which is for the whole page or [05:41] node.one() which just looks at children of the node [05:41] No failures [05:41] Let me break it [05:53] wallyworld__: So I get failures, but none about my code [05:53] StevenK: what sort of failures? [05:54] http://pastebin.ubuntu.com/692789/ [05:55] * wallyworld__ looks [05:58] StevenK: the test invokes test_unsubscribe_with_warning_action which clicks the link and looks at the mocked io values [05:58] StevenK: so with the confirmation dialog there, it doesn't get to do the expected io [05:58] wallyworld__: Right, so that's fine that it fails -- but test_on_unsubscribe_updates_info doesn't fail [05:58] but since your test is failing, it may be that the Y.one(.xxxx) is wrong [05:58] My test is failing to fail [05:58] i would use firebug to inspect the css class used [05:59] for the confirmation overlay [05:59] class="pretty-overlay-window yui3-widget yui3-overlay yui3-pretty-overlay yui3-lazr-formoverlay yui3-lp-app-confirmationoverlay yui3-widget-positioned yui3-widget-stacked" [05:59] That bit? [06:00] yep, use 'yui3-lp-app-confirmationoverlay' [06:00] With no dot? [06:00] sorry, with a dot [06:01] StevenK: to be pedantic, you could use Y.one('.yui3-overlay .yui3-lp-app-confirmationoverlay') [06:01] which will require both classes to be present [06:01] but try the simple case first [06:19] wallyworld__: Which still doesn't fail how I want [06:20] StevenK: how does it fail now? [06:20] wallyworld__: The same way [06:20] Which means Y.Assert.isNull(co) is true [06:21] StevenK: and you are sure the overlay is always being created [06:21] wallyworld__: Well, I'd like to debug this somehow, but I have NFI how [06:22] StevenK: you open the html harness in chrome and use firebug [06:22] or firefox [06:22] but for yui tests, chrome seems to work better [06:22] run the tests one to load the scripts, then switch to the test_xxxx.js script and set a breakpoint [06:22] and hit refresh [06:29] o/ wallyworld__ [06:29] hi poolie [06:33] StevenK: i may have mislead you. to test for both classes, you use Y.one('.foo.bar') <- without the space, slip of the fingers [06:34] poolie: how can i help? [06:36] just saying hi [06:37] poolie: just checking, just in case :-) [07:01] hi mrevell! [07:01] Morning! [07:02] mrevell: we just rolled out a small but hopefully helpful Translations change that may be worth announcing. [07:02] Any suggestions for how/where I ought to do that? I haven't kept track. [07:03] jtv, I'd always favour a blog post. We can then reference that elsewhere. [07:04] wgrant: closing in on u1; up for 2 tiny reviews in the same theme ? [07:04] Top notch, btw. [07:04] thanks mrevell [07:05] wgrant: Hi, if you haven't (re-)reviewed my branch yet, I'll split the changes like you suggest. [07:06] rvba: That would be great -- as it stands it's pretty impractical to see what's what, as I'm sure you've found. [07:06] lifeless: Possibly. Links? [07:06] https://code.launchpad.net/~lifeless/python-oops-wsgi/timeline/+merge/75960 https://code.launchpad.net/~lifeless/python-timeline/wsgi/+merge/75959 [07:06] wgrant: Indeed. I'll do that this morning. [07:26] wgrant: ^ [07:27] wallyworld__, hey thanks for grabbing bug 696954, that has bothered me in the past [07:27] <_mup_> Bug #696954: Allow persons in project roles to access private bugs < https://launchpad.net/bugs/696954 > [07:27] poolie: np. it's on the disclosure todo list :-) [07:28] hm [07:29] kinda seems like some scope creep there [07:29] but i'm happy it's getting done [07:29] i think there may be dupes or near dupes of it [07:29] no need to find them now i guess [07:29] poolie: disclosure covers who has access to information just as much as who doesn't [07:30] i'll try and see that any dupes are linked to this bug [07:32] wallyworld__: you'll need to be very careful about query changes - lots of room for foot-gun on performance in this area; OTOH brad snuck some of it in already before the re-org, so we may be lucky. [07:33] lifeless: the accepted pattern seems to be union of sub queries. i've put up a mp this afternoon along those lines and was going to do something similar here [07:33] wallyworld__: its not so much a matter of patern, as bug queries being right on the cliff face of timeouts [07:34] wallyworld__: so adding more work to them has a high probability of pushing them over the cliff [07:34] wallyworld__, so it's kind of a beer conversation but it kind of seems like tackling every bug kinda related to the feature may cause features to run long and starvation of other areas [07:34] wallyworld__: -> need to make it as much faster as the extra work you are asking it to do. [07:34] but i am really happy to see this one fixed [07:34] wallyworld__: I'd allow several days for dealing with performance impacts alone [07:35] wallyworld__, oh the one i filed was bug 746887 [07:35] <_mup_> Bug #746887: private bugs get stuck invisible to developers < https://launchpad.net/bugs/746887 > [07:35] which is a direct dupe of yours, i'd say [07:35] but now duped against bug 696973 [07:35] <_mup_> Bug #696973: There are no roles that can see all private artifacts in (public or private) projects < https://launchpad.net/bugs/696973 > [07:36] lifeless: recently, bug task assignee was added to the allowed viewers of private bugs. i've taken the same approach for https://code.launchpad.net/~wallyworld/launchpad/pillar-owners-private-bug-visibility-702429/+merge/75961 i can give you some sql to run on staging if you want [07:37] poolie: i'll see if yours is a dup and link it [07:37] wallyworld__: its not that simple :) - you'll find you need to look at prod (because its in the grey area), and compare bug search timeout counts before/after you go live, and see if there is a regression, and if so toggle it off. [07:38] lifeless: actually, i can optimise it a bit - only do the sql depending on which pillar is not none [07:39] lifeless: ok. i'll make the optimisation before i land. and gather some stats as you suggest [07:39] wallyworld__: how? (We have queries that cover all pillars - site wide bug queries) [07:39] wallyworld__: one big thing you can do to make this safer is feature-flag the new query. [07:39] easy to do, big rewards, I mean. [07:40] lifeless: yes ok. optimisation not feasible as you say. but i will do a ff [07:41] actually, i could do the project roles work as per 969793 behind the same ff perhaps [07:41] bug 969793 [07:42] no mup? [07:42] um, 696954 [07:42] sorry [07:42] wrong bug [07:42] bug 696954 [07:42] <_mup_> Bug #696954: Allow persons in project roles to access private bugs < https://launchpad.net/bugs/696954 > [07:49] wallyworld__: cool; if you need specific stuff tested, yes I'd be happy to help. [07:50] wallyworld__: we can only get pretty gross results from staging as I mentioned though :( - clearly good and clearly bad, but its poor on 'maybe' [07:50] lifeless: thanks. i guess i'll need you if it all blows up on prod and we have to turn off the ff :-) [07:51] wallyworld__: trivial queries will always be fine. You'll have trouble, if you do, on: project queries (e.g. launchpad-project), and Ubuntu queries, and site-wide queries. [07:53] lifeless: well fingers crossed. if you are interested, https://pastebin.canonical.com/52955/ the unions after bug task assignee are the new ones [08:04] good morning [08:09] wgrant: I know you're busy right now and this is not urgent at all, but I've refactored the branch: the first one is https://code.launchpad.net/~rvb/launchpad/sync-bug-827608-credit-copy/+merge/74769 and the second one is https://code.launchpad.net/~rvb/launchpad/sync-bug-827608-credit-copy-2/+merge/74958 [08:25] lifeless: are you around in about 20 minutes to talk about python-oops? [08:25] I think so [08:26] thanks, just need to do my team call [08:30] wgrant: sorry to be a nag, was that yes or no to the reviews? [08:30] lifeless: Sorry, unexpectedly busy. I can look tomorrow (I'm OCR), but I guess you want to toss them at someone else. [08:31] I'm nearly EOD too, I may just nab you in the morn [08:31] I need to finish the storm component before it all becomes relevant. [08:31] thats nearly done === almaisan-away is now known as al-maisan [08:46] lifeless: hi [08:46] skype? [08:47] sure [08:49] ok, what the heck does https://launchpad.net/ubuntu/+source/clang/2.9-11ubuntu1/+build/2792745 mean [08:49] "Currently building" "Finished 7 hours ago (took 18 hours, 12 minutes, 50.6 seconds)" [08:50] definitely still going, still getting build output [08:50] it's a bug [08:50] cjwatson: confused [08:50] hi bigjools [08:50] * bigjools looks up the bug [08:50] yo thumper [08:50] cjwatson: Yeah, came upon that earlier... it finished on celbalrai, but then $something happened and it was redispatched. I haven't seen that happen for 18 months... [08:51] cjwatson: It is building now, and should upload as normal in ~22 hours, at which time it will look sensible again,. [08:51] I think it's part of bug 717969 [08:51] <_mup_> Bug #717969: storeBuildInfo is sometimes ineffective < https://launchpad.net/bugs/717969 > [08:51] ah, ok, I wouldn't have been able to find that bug :) [08:51] That's a possibility, yes. [08:51] It's not a case of that bug that we've seen before, but it is a similar sort of thing. [08:51] the bug title needs to change [08:52] might it have been to do with the FDT? [08:52] bigjools: No, this was hours ago. [08:52] The initial issue was 6 or 7 hours ago. [08:52] should I add a screenshot or something to that bug? The evidence will go away in the near future [08:52] ok [08:53] cjwatson: That would probably be useful. Also useful is the API representation of the build: add /api/devel to the start of the path to get that. [08:53] OK [08:53] lifeless: ok ready when you are, can't see you on skype [08:55] I'm rbtcollins [08:56] * bigjools blind dials === dpm_ is now known as dpm [09:58] lifeless, hi, where's the code for ppr pages? I assume it process launchpad appserver log files, right? [09:58] s/process/processes/ [10:02] StevenK, whatever it was I did, I apologize [10:03] danilos: ztrace files yes [10:03] danilos: its in the lp tree [10:05] lifeless, oh right, thanks [10:07] lifeless, btw, how would you feel if we add the request duration to the apache log files as well? [10:08] danilos: no particular opinion; I thought apache log format had that anyeway [10:09] lifeless, it doesn't, unfortunately, common format only lists request *end* time afaict [10:09] lifeless, ok, I'll bring it up with LOSAs since this may affect our log processing scripts as well [10:11] and actually it's the time request was received, some stale reference for my previous claim :) [10:18] StevenK, fwiw, I can't see what's in the "Unsubscribe" overlay on that screenshot, but it looks reasonably probable that fixing bug 795180 would make it unnecessary. [10:30] mpt: I'm fixing a seperate bug -- if a user is unsubscribing themselves from a private bug, they should be warned. [10:32] StevenK, oh, then I'll have to agree with wgrant then. :-) That warning could be indented under the one of those three commands that deprives you of access. [10:33] mpt: I've already been convinced. I just need more JS knowledge. [10:34] k [10:51] Ah, good, so I invoked mpt correctly, and shall not incur too much of his wrath. [11:49] stub: I wonder if garbo should report how many iterations and “items” a job got through before being killed. Nice to know if we're making progress, and whether a job is still needed. [11:50] jtv: Sounds useful. Would need to be in DBLoopTuner but that is fine. [11:51] Yeah. [11:51] stub: Can we abolish database/schema/pending? [11:53] danilos, hey there, the script that loads oops into the oops-tools database caught up during the weekend and those SMS oopses should now be available for viewing [11:55] wgrant: Replacing it with what? [11:57] stub: Well, it seems to have been used roughly twice in the last two years. [11:57] wgrant: I guess it can go - nothing in there at the moment that is useful [11:57] It should at least be emptied out. [11:58] Nothing in there is useful now, and I don't really think there's much of a case to put stuff in there. [11:58] wgrant: yer. Will need to find somewhere for templates etc. for data migration type scripts. That is going to happen more and more with fastdowntime. [11:58] That's true. [11:58] jamesh: https://code.launchpad.net/~lifeless/storm/wsgi closes the loop [11:58] Nothing in there deserves to stay, but I'm not sure if the directory itself should... [12:01] matsubara, cool, thanks [12:02] danilos, you're welcome [12:21] rvba: I think those two branches look fine. [12:21] rvba: It's hard to say for sure, but the test changes look pretty sane. [12:21] wgrant: Okay. Thanks for looking at it again. === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Critical bugs: 260 - 0:[########*** stack smashing detected ***: ./lp terminated [12:40] stub: Do you recall why our store names include the config section name? We never change it outside tests... [12:42] I guess it may have been a WHUI attempt to permit usage of multiple concurrent configs. [12:43] * wgrant deletes it to see what breaks. [12:44] Ah, of course. It's the only way to get the section name into LaunchpadDatabase. [12:44] Unless I just fix it to always use canonical.config.dbconfig... [12:44] Which it already does, because the other case is WHUI. [12:51] hey benji—I've got a gigantic lint branch up for review. Not expecting anyone to read it in full, but since I don't see how it could be Q/A'ed, I'd prefer not to make it self-reviewed as well. [12:51] jtv: sure, I'll take a look [12:51] thanks [12:53] cjwatson: There are some complexities to exporting changeOverride, sadly. [12:53] cjwatson: Permissions are one difficult bit. [12:53] Another is getting the same source+binaries behaviour. [12:58] I looked at permissions and that part looked OK; launchpad.Edit permissions on SPPH/BPPH already look sane [12:58] i.e. basically archive owner with a few warts [12:58] wgrant: I suspect the code you are looking at was assembled (I won't say 'designed') before canonical.config.dbconfig existed. [12:59] bigjools, wgrant: I want to create a set of BinaryPackageBuilds for all possible values of BuildStatus. When I then create a +builds view, the resultset of the view is sometimes empty: http://paste.ubuntu.com/693006/ I get empty results set for the statuses built, building, pending. Any suggestions? [12:59] wgrant: and surely the source+binaries behaviour could be handled by the caller? [12:59] I would've thought lib/lp/soyuz/scripts/changeoverride.py could basically be transmogrified into an API script [12:59] cjwatson: Probably, yes, assuming the relevant methods on SPPH are exposed. [13:00] SPPH.getPublishedBinaries or whatever it is. [13:00] cjwatson: The API's SPPH.requestDeletion does source+binary implicitly, but that makes less sense for overrides, as they may differ. [13:01] requestDeletion's implicit behavior is annoying; it's too constrained to implement lp-remove-package.py over the API [13:01] we need to do things like deleting individual NBS binaries, deleting only a source package when its binaries have been taken over by another package, ... [13:01] stub: Possibly. Since nothing seems to use LaunchpadDatabase or a DBPolicy with anything other than the current section, I'm hoping this ec2 run will succeed. Then I can move ZTM's remaining user handling crap into DBConfig, and it can finally die. [13:02] cjwatson: Indeed. [13:02] cjwatson: I forget if we expose BPPH.requestDeletion. [13:02] and yes, only being able to overrides for everything in a source package at once would be so limiting as to be useless [13:02] cjwatson: But do you ever want to delete a source without deleting binaries from that source? [13:02] *do overrides [13:03] wgrant: only if those binaries have been taken over by some other source. I'm never sure whether LP will notice that correctly on removal [13:03] did the +activereviews page change? The organization looks different -- and less useful :( [13:03] lp-remove-package normally does seem to, admittedly [13:03] cjwatson: We identify BPPHs for BPRs that were built from a build for the SPR that's being deleted. [13:03] the other use case for deleting binaries is when they fail to build (even if they aren't actually NBS) and we don't want to ship unsupportable stuff [13:03] cjwatson: Names aren't used at all. [13:04] OK, that would be safe [13:04] Yeah, deleting binaries I can understand, and is easily supportable. [13:04] Deleting sources without their binaries would require slightly more creative API construction. [13:04] I can see why you might not want to expose API methods that produce orphaned BPRs [13:04] Exactly. [13:05] oh! it's because it doesn't know who I am, I need to log in [13:06] benji: those are two independent statements, there should be no comma, between, them, how are you, I am fine? [13:07] jtv: this is true; my IRC copy editor is on vacation today so you'll have to deal with small imperfections [13:07] Morning, all. [13:08] benji: I see. Now compare your case to deryck's, who seems to be verbless at the moment. [13:08] Hi deryck. :) [13:08] hi [13:08] jtv: I guess he accidentally a word. [13:08] Not sure I get the verbless comment. ;) [13:10] deryck: I was being a pedantic prick with benji, and when he made up a semi-plausible excuse, I started using you as a bad example instead. :) [13:10] The “verbless” refers to the absence of verbs in “morning, all.” [13:11] ah [13:11] Ah, that invented Victorian grammar. :-) [13:12] Arguments about language on the Internet always end well. ;) [13:13] I'll just cite http://languagelog.ldc.upenn.edu/nll/?p=3338 and leave it at that :-) [13:15] heh === Ursinha is now known as Ursinha-brb [13:30] abentley, hi. we're back to mumble this week. [13:37] cjwatson: I stopped reading Language Log ages ago when it went through a period of being a blog about how badly the BBC do science reporting. I'd forgotten how good it can be. === jtv is now known as jtv-afk === al-maisan is now known as almaisan-away === bdmurray_ is now known as bdmurray [14:51] sinzui: available to mumble? [14:51] yes. === Ursinha-brb is now known as Ursinha [14:52] excellent. [15:10] deryck: chat? [15:10] abentley, sure. let me grab coffee and then meet you in mumble. [15:10] deryck: cool. [15:17] sinzui: morning. [15:17] hi lifeless === salgado is now known as salgado-lunch [15:18] sinzui: did you see the rollback of subscription-changes-on-toggling-private-flag-in-bugs ? [15:18] I did. [15:18] sinzui: there is some confusion about whether a) wallyworld was confused or b) I was confused about the design [15:19] I told wallyworld that OEM has direct subscriptions removed so I thought he did the right thing [15:19] sinzui: I promised him I would touch base with you directly to clear things up [15:19] sinzui: do you mean they do the following with the old code: a) make private; b) remove the resulting direct subscriptions ? [15:19] We can cut that feature and land the structural subscription part only. OEM can report a bug if they believe the behaviour is still broken [15:20] lifeless, OEM removes anyone they do not know to be associated with their projects [15:20] It has nothing to do with direct/indirect. It is simply a matter of disclosing info [15:21] sure, but the indirect-become-direct behaviour is a part of the story [15:21] in that it requires an explicit act to become a subscriber without that [15:21] [for a non-project-person] [15:23] sinzui: anyhow, the result of ditching -all- direct subscribers is that we can't have symmetrical code as we designed : we would have to special case according to increasing or decreasing sensitivity [15:23] Sure, but disclosing private/secure information costs millions, and users who cannot see who is subscribed (api/email) are trusting Lp to do the right thing [15:24] agreed on the result of a mistake, but we're talking about the case of taking a bug that was open, private, which clearly means that the info in it was public at one point. [15:25] such super sensitive things should be created private to start with, so there is no chance of disclosure, and the transition code becomes irrelevant [15:25] But the subsequent private conversation was never public [15:25] This case might better be solved by bug linking [15:25] the transition code flow we discussed was designed for dealing with private-security becomes private-non-security, and vice verca. [15:26] yes, I think a private discussion about a bug reported by a person outside the project should be done with a lnked private bug [15:27] is there an option to say 'bugs on this project cannot be filed open' ? [15:27] As I wrote to wallyworld, we will only deal with structural subscriptions (remove the direct changes) so that the common case works as users expect (and Lp claims to do) [15:27] ok [15:28] I think I know what that means, and will look over someones shoulder when v2 of it goes up :) [15:28] to make sure I understand, so I have a clue and don't trigger a late rollback :) [15:29] lifeless, was also cut the unsubscribe-security-contact-bug-supervisor rule when a bug because public/non-security because there was disagreement. I just want to land what we agree solves most of the problem [15:30] sinzui: oh, thats surprising. [15:30] sinzui: I agree on landing the uncontentious bits [15:30] sinzui: but am also curious what the disagreement was [15:31] wgrant believed the security contact may want to follow the conversation after the issue was made non-security, or even choose to re-secure it if it is decided the change was a mistake [15:31] btw, I have a sneaking suspicion we might be able to address some performance issues if we materialize subscriptions (like we do teamparticipation). IMBVW [15:32] wgrant, is planing for that :) [15:32] sinzui: (re-securing - a test that they receive the 'it is now public' notification would cover that (and be a solid expectation too)) [15:32] sinzui: following-the-conversation : tough. :) [15:33] sinzui: they can subscribe when they get the notification that says 'xyz is now public and you are no longer subscribed' [15:33] lifeless: 1. wth are you still doing awake, and 2. any objections to me throwing the management rabbit plugins in the LP PPA? [15:33] lifeless, yes, ensuring notification may be the correct way to handle this. [15:33] bigjools: 1. Cynthia. 2. No objections. [15:33] copy! [15:35] bigjools: btw, I think one of the bugs confused you [15:35] quite possibly [15:35] write better descriptions then :) [15:35] bigjools: the ..139 bug is about snarfing issues from *rabbit*, not longpoll [15:35] the ...136 bug is about issues from longpoll. [15:36] I realised that much [15:36] so how is 136 a pre-req for 139 ? [15:36] did I get them the wrong way around? [15:36] they are unrelated [15:36] hmm [15:37] two separate services, both need tell-us-what-went-wrong integration of some sort, to avoid a human going and looking at log files. [15:38] yer right, I'm confused. My bad. [15:38] no worries :) [15:38] the management interface is quite neat BTW [15:38] cool [15:38] I am poking messages through and the web page updates almost instantaneously :) [15:53] james_w: https://launchpad.net/testr_recipe is a 404 [15:53] james_w: the url is on your pypi page [15:57] looks interesting that [15:59] well where did that go then? [15:59] I wonder if I ever actually registered it [15:59] ah https://launchpad.net/testr-recipe === deryck is now known as deryck[lunch] [16:13] lifeless: https://code.launchpad.net/~wallyworld/launchpad/branch-privacy-trigger/+merge/75189 might interest, as it is a DB patch that should land with code changes (the tests for the trigger behaviour) === salgado-lunch is now known as salgado [16:48] jtv: Could you take a look at https://answers.launchpad.net/launchpad/+question/171451 for me? I don't know the answer. [16:48] this one, also: https://answers.launchpad.net/launchpad/+question/171450 [16:49] where do I set the default reviewer for a project? [16:49] well, trunk branch [16:50] nm found it eventually === beuno is now known as beuno-lunch === deryck[lunch] is now known as deryck [17:36] jcsackett, do you have a moment to discuss http://pastebin.ubuntu.com/693202/ on mumble? [17:37] sure. [17:58] off hand is there an easy way to get get a bug object via a .getBugByURL()-like API call :)? === beuno-lunch is now known as beuno [18:07] timrc, the lp object has a top-level bug collection. You only need the id from the URL [18:08] lp.bugs[284141] will get bug #284141 regardless without need of knowing the projects it affects [18:08] <_mup_> Bug #284141: PPA upload permissions should be decoupled from its team membership. < https://launchpad.net/bugs/284141 > [18:08] sinzui, okay that can work [18:08] sinzui, thanks [18:37] jtv: Hey, do you know why your MP (the one linked on your blog post) turns up with an empty diff? [18:37] s/your/Launchpad [18:37] That's probably going to be confusing for everyone who clicks through :) [18:55] sinzui: Heh, after much fun with regressions, I finally fixed the bug title feature :-) [18:55] s/fun/fail/g works as well. [18:57] nigelb, I saw. Thank you for following up [18:58] sinzui: Embarassing mistakes. But learned YUI testing well now :-) [18:59] nigelb, You have nothing to be embarrassed about. Now wrongly closing 10,00 bugs in production does cause some embarrassment. [18:59] ...wow [19:23] nigelb: yes, now 4 years since that event, but sinzui is still talking about it :-) [19:23] I was traumatised [19:25] When I am described as "legendary", I think "what? Who knows me?", then I remember the 10,000 bugs. [19:35] haha [19:37] sinzui: I was traumatised with nightmares of wgrant stabbing me for making a bunch of revs undeployable :P [19:39] nigelb, :) [19:45] sinzui: I think someone new has more "fame" now with the accidental auto-sync that happened this cycle :P [19:45] :) [20:20] flacoste: hi; will be with you soon [20:21] lifeless: no worries, working on the QBR stuff [20:29] james_w: ah, should be simple to fix the pypi ref then :) [20:30] lifeless, already done [20:30] james_w: I wanted to look at the code to see if you setup a run --parallel config [20:30] james_w: but IIUC you use the .testr.conf in the tree, so thats still manual ? [20:30] it also has code to generate .testr.conf [20:31] cool! [20:31] does it setup a parallel conf or the older run-without-knowing style? [20:40] it's old [20:48] if you have a look at testtools .testr.conf, or even testrepositories itself, you can see the changes quite easily. [20:48] should I file a bug ? === matsubara is now known as matsubara-afk === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 260 - 0:[########*** stack smashing detected ***: ./lp terminated [21:49] lifeless, go ahead [21:52] 'morning lifeless [21:53] morning... wait a minute. [21:53] jelmer: aren't you somewhere in Europe? :) [21:54] lifeless: you approved one of my bzr-search branches and spoke the ever legendary word "doit", but you own lp:bzr-search; is there any chance you can merge it for me or change ownership to ~bzr/~bzr-search? [21:54] jelmer: no I don't :) [21:55] lifeless: :-) thanks [21:56] nigelb: Yeah :-) I think it's evening for both of us, right? [21:56] I've passed the point where I can call it evening ;) [21:57] I still haven't slept so I'll claim evening :P [21:58] sleep well, nigel [21:58] and sleep enough [21:58] :) [21:59] Thanks poolie! === salgado is now known as salgado-afk === lifeless changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 260 - 0:[########*** stack smashing detected ***: kees pinged [23:22] wgrant: reviews plox === wgrant changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: wgrant | Critical bugs: 256 - 0:[########*** stack smashing detected ***: kees pinged [23:56] wgrant: https://code.launchpad.net/~lifeless/python-oops-wsgi/timeline/+merge/75960 https://code.launchpad.net/~lifeless/python-timeline/wsgi/+merge/75959 [23:58] lifeless: Sorry, on a call right now. [23:58] kk