[00:15] <StevenK> wallyworld_: I've had breakfast, but I think I need at least one cup of tea before our chat.
[00:16] <wallyworld_> StevenK: np
[00:16] <StevenK> Also got distracted by finishing my double-word-death branch
[00:16]  * StevenK tosses it at ec2
[00:18] <lifeless> wgrant: ?
[00:19] <wgrant> lifeless: You said "heh, doit." but didn't actually vote.
[00:20] <lifeless> twill be clear to onlookers :>
[00:20] <wgrant> And the subsequent 6 lines were about that tag subscription bug that you commented on.
[00:20] <lifeless> ah yes
[00:20] <lifeless> which is beautiful win
[00:25] <StevenK> wallyworld: Sorry, now I'm waiting for the jerk with the leaf blower to move
[00:25] <wallyworld> StevenK: what? can't hear you over the noise
[00:26] <StevenK> Or I get annoyed enough to go downstairs and ... re-position the nozzle
[00:26] <wgrant> lifeless: Can we migrate to SQLAlchemy now please?
[00:26] <StevenK> Add it sourcedeps. I dare you.
[00:27] <lifeless> wgrant: raise it on the list
[00:27] <wgrant> Hah
[00:27] <StevenK> lifeless: You have no objections?
[00:27]  * StevenK deals lifeless a penalty card for 'Lying'
[00:28] <lifeless> StevenK: oh?
[00:28] <lifeless> StevenK: deal yourself one
[00:28] <lifeless> StevenK: then ask Francis what I've said in the past.
[00:28] <StevenK> lifeless: You have strong opinions on everything we use, so I find it hard to believe you don't have one about this.
[00:28] <lifeless> I never claimed no opinion
[00:28] <rick_h> wgrant: is my new hero for that comment
[00:39] <StevenK> if( vs if (
[00:40] <rick_h> pep8 says if (
[00:42] <StevenK> wallyworld: http://pastebin.ubuntu.com/852074/
[01:01]  * StevenK stabs Firefox
[02:04] <abentley> wgrant: it looks like bulk.create with a 0-length values will perform an execute and get a ProgrammingError.  What do you think about changing it to handle 0-length values by returning?
[02:05] <abentley> wgrant: Also, is it efficient to load when the values aren't needed?
[02:06] <wgrant> abentley: Much like the rest of Storm's SQL compilation stuff it is a bit fragile, yeah.
[02:06] <wgrant> And loading should indeed probably be made optional.
[02:06] <wgrant> So, yeah, 0-length values should probably just be a no-op, and loading should be disablable.
[02:07] <abentley> wgrant: Cool.
[02:07] <abentley> wgrant: The 0-length values is the only reason I kept insert_many in my latest branch.
[02:07] <wgrant> abentley: I'm intrigued as to how your experiment was so slow.
[02:07] <wgrant> Perhaps sqlvalues is awful.
[02:08] <wgrant> abentley: How fast is the original code, btw?
[02:08] <wgrant> Without any bulk optimisations.
[02:08] <abentley> wgrant: I'm curious too, but I've got lots of things piling up at the moment.
[02:08] <wgrant> s/fast/slow./
[02:08] <wgrant> Yeah
[02:09] <abentley> wgrant: I took over from gmb, so I didn't try it.  I know it exceeded the branch scanner job timeout.
[02:09] <wgrant> Heh
[02:09] <mwhudson> which bit of the scanner is timing out?
[02:09] <lifeless> the wrapper
[02:09] <wgrant> Both BranchRevision and Revision insertion have been problematic.
[02:09] <mwhudson> ok
[02:10] <wgrant> And there was a libreoffice non-DB timeout yesterday.
[02:10] <wgrant> I didn't investigate.
[02:10] <abentley> mwhudson: The db insertions of Revisions and BranchRevisions.
[02:10] <mwhudson> i worked on BranchRevision pretty hard at one point
[02:10] <mwhudson> as you have probably noticed
[02:10] <wgrant> Yeah
[02:10] <wgrant> IIRC it uses manual string SQL now?
[02:10] <wgrant> Like the rest of LP's existing bulk inserts.
[02:10] <wgrant> Which I'm going to port to the new shiny tomorrow, probably.
[02:10] <mwhudson> yeah
[02:10] <mwhudson> that'll be good
[02:10] <abentley> wgrant: Are you fixing the same bug as me?
[02:10] <mwhudson> (even if it doesn't end up being faster)
[02:10] <wgrant> abentley: No.
[02:10] <wgrant> abentley: I'm working on disclosure stuff.
[02:11] <wgrant> abentley: jelmer is working on the bzr side of scanner timeouts, though.
[02:11] <abentley> wgrant: I've ported it over to insert_many already.
[02:11] <wgrant> abentley: I informed him of your potential conflicts.
[02:11] <wgrant> abentley: Yeah, but there are other places that do manual bulk inserts.
[02:11] <wgrant> BPPH creation and a few others.
[02:11] <abentley> wgrant: Oh, I misread you.
[02:11] <wgrant> I'm not going to touch your stuff :)
[02:12] <abentley> wgrant: Well, if you insist on doing it better than  me, I'll grumble, but not too much :-)
[02:12] <wgrant> Heh
[02:13] <wgrant> abentley: You've wrapped create() rather than fixed it directly?
[02:13] <wgrant> The initial version will land in about 90 minutes, so I'll land a quick followup with the changes you suggested unless you already have one.
[02:13] <abentley> wgrant: No, I hadn't seen create.  I was using "Store.execute(Insert( ..."
[02:13] <wgrant> Ah
[02:14] <wgrant> I'll make those two changes now, then.
[02:14] <wgrant> Thanks.
[02:15] <wgrant> Hopefully this will make people avoid bulk creation a bit less.
[02:15] <wgrant> 'cause there are a lot of places that could use it.
[02:16] <wgrant> abentley: I apologise for colliding with you. I didn't realise you were working on this until I was proposing my Storm branch and saw yours.
[02:17] <abentley> wgrant: No worries.  Strange coincidence that we both tried to fix this longstanding gap in the same month.
[02:18] <wgrant> Indeed.
[02:21]  * wgrant benchmarks the old one too, just for curiosity's sake.
[02:24] <abentley> wgrant, jelmer: In last week's profiles of lp:s~irar/gcc-linaro/slp-for-any-nops-4.6/, only 13% of branch scanner time was spent in getBazaarRevisions, so I wasn't too concerned about it.
[02:25] <abentley> wgrant, jelmer: Though wgrant's bulk-insert will make the db side faster.
[02:25] <wgrant> wgrant@lucid-test-lp:~/launchpad/lp-branches/devel$ ls -lh /var/tmp/lperr
[02:25] <wgrant> total 191M
[02:25] <wgrant> drwxr-xr-x 2 wgrant wgrant 189M 2012-02-22 13:24 2011-12-05
[02:25] <wgrant> That can't be good...
[02:27] <StevenK> A 189M dentry? Niiiiiiiiice
[02:27] <wgrant> Yeah
[02:27] <wgrant> I think that's the day I reproduced the poppy rabbit explosion.
[02:27] <wgrant> Which could mean there are millions of files in there.
[02:27] <StevenK> Likely
[02:28] <StevenK> ls -1 /var/tmp/lperr/2011-12-05 | wc -l ? :-)
[02:28] <wgrant> I unfortunately already deleted part of it, but I'm already doing that.
[02:28] <wgrant> Been going for 3 minutes...
[02:28] <StevenK> Haha
[02:28] <wgrant> It's probably statting all the children :*(
[02:28] <StevenK> It will, yes
[02:29] <wgrant> Might write something to just readdir instead.
[02:29] <wgrant> Oh no
[02:29] <wgrant> It's still calling getdents
[02:29] <wgrant> 512 at a time
[02:29] <StevenK> Bwahaha
[02:30] <wgrant> ls is only using 3% of my RAM so far, though.
[02:40] <wgrant> Ew
[02:40] <wgrant> At least 4 statements per Revision insert in devel.
[02:41] <wgrant> And often 7
[02:41] <wgrant> And oh look it timed out.
[02:42] <wgrant> Less than half way through.
[02:46]  * wgrant starts it without a timeout and goes away for 15 minutes.
[02:51] <wgrant> Huh
[02:51] <wgrant> It doesn't really seem to be inserting them in any kind of order.
[03:06] <wgrant> abentley: Just tested on lp:launchpad. 9:00 without bulk inserts, 1:45 with mine.
[03:07] <wgrant> Probably doesn't improve the normal case much, but the initial scan of a large new history is 5x faster even with no DB latency.
[03:13] <wgrant> Yeah, doesn't help the 0:47 new branch with existing Revisions case at all.
[03:15] <wgrant> mwhudson: Did you ever look at sharing history?
[03:17] <wgrant> eg. bisect to find the latest shared history and then delegate to that.
[03:29] <lifeless> wgrant: it was examined, based on the work jam had done in history-db
[03:30] <lifeless> lol, pybars has had 65 downloads
[03:30] <lifeless> interesting
[03:30] <wgrant> s/interesting/google/
[03:30] <lifeless> you think?
[03:31]  * wgrant finds out.
[03:34] <mwhudson> wgrant: for branch revision?
[03:34] <wgrant> mwhudson: Yeah
[03:34] <wgrant> It would presumably reduce the table size by something like 99%.
[03:35] <wgrant> lifeless: Oh, bah, hosted on PyPI rather than LP?
[03:35] <wgrant> No referers for me :(
[03:36] <lifeless> pypi -> centre of the python universe
[03:36] <wgrant> Yeah, but often our downloads are hosted on LP.
[03:38] <StevenK> wgrant, lifeless: Can I Disapprove https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-migration-script/+merge/93883 ?
[03:38] <StevenK> garbo job or API script, damn it
[03:39] <wgrant> As I said a couple of days agoo, I think it should be an API script. But it needs discussion.
[03:39] <lifeless> I recommended garbo to salgado a week or two back
[03:40] <StevenK> All of three of us are in agreement about "Oh god, not that>"
[03:40] <StevenK> s/>/./
[03:40] <lifeless> I think its reasonable to say that you want to discuss it
[03:40] <lifeless> and yes, I agree, API or garbo makes much more sense
[03:42] <StevenK> lifeless: "I'm going to disapprove this. This requires discussion, and certainly doesn't require a one-shot script -- the usual modus operandi for migrations like this is either a garbo job or an API script."
[03:46] <StevenK> lifeless: Sound fine?
[03:46] <mwhudson> wgrant: i'm not sure how that would help things like mapping a revision to a branch
[03:46] <lifeless> StevenK: personally, I would needs-info rather than disapprove, but if you're reviewing, do what you prefer
[03:46] <mwhudson> you can do cleverer things that BR of course, but you end up doing something like historydb i think
[03:46] <lifeless> StevenK: I'll note that its a tunableloop already
[03:46] <mwhudson> there is a wiki page somewhere about being cleverer than BR, come to think of it
[03:47] <lifeless> StevenK: which means it can trivially sit in the garbo
[03:47] <wgrant> wallyworld__: Om nom nom XSS
[03:47] <wallyworld__> hmm?
[03:47] <wgrant> Your new sharing picker thing is nice and XSSable.
[03:47] <StevenK> lifeless: Meh, needs fixing
[03:47] <wgrant> And not feature-flagged :(
[03:47] <lifeless> StevenK: sure, or that
[03:48] <wallyworld__> wgrant: it's on a view that is not used
[03:48] <mwhudson> wgrant: https://dev.launchpad.net/Code/BranchRevisions
[03:48] <wgrant> wallyworld__: That's only barely mitigation.
[03:48] <lifeless> wallyworld__: if someone can craft a url to it, they can exploit it
[03:48] <lifeless> (if there is an xss hole...)
[03:49] <wallyworld__> i'm not sure if the view is featured flags or not
[03:49] <wgrant> It's not.
[03:49] <wallyworld__> so we need to ff the view
[03:50] <StevenK> lifeless, wgrant: You both chimed in on https://code.launchpad.net/~sinzui/launchpad/team-titles/+merge/93675 ? Do you have any remaining objections or were you just commenting?
[03:50] <lifeless> StevenK: sinzui took my suggestion into account
[03:50] <wgrant> I'm OK as long as the bug title changes are reverted.
[03:50] <lifeless> StevenK: the title is now preserved - see his QA instructions
[03:51] <lifeless> wgrant: they aren't reverted, but titles are shown in the page title
[03:53] <wallyworld__> lifeless: i'm in iharness and using Launchpad.login_with(). but there's no get() or named_get() method on the lp instance that is returned. what's the best way to get an instance of WebServiceCaller with those methods?
[03:53] <wgrant> Launchpad.login_with() is a full launchpadlib
[03:53] <wgrant> Heh
[03:54] <wgrant> This is actually a two-layer XSS
[03:54] <wgrant> Cool
[03:54] <StevenK> wgrant: Are you okay with the MP given what lifeless said?
[03:54] <wallyworld__> wgrant: there's no get or named_get methods though it seems
[03:54] <wgrant> wallyworld__: No, launchpadlib uses attribute access instead.
[03:55] <wallyworld__> so how to i get something i can invoke named_get or get on?
[03:55] <wgrant> Do you want to do that, or do you just want to experiment with the API?
[03:56] <wallyworld__> i have a service i think  have exposed and  i want to try and call it
[03:56] <StevenK> Write a webservice test, then?
[03:56] <wgrant> Might as well just use launchpadlib. It's a nicer interface than WebServiceCaller
[03:56] <wgrant> And I don't know if one can use WebServiceCaller from outside AppServerLayer
[03:57] <wgrant> lp = Launchpad.login_with(fewfwefwehfuwef)
[03:57] <wgrant> obj = lp.load('/path/to/your/resource')
[03:57] <wgrant> obj.someattribute
[03:57] <wgrant> obj.someMethod(some=arg)
[03:57] <wallyworld__> .load is what i was missing
[03:57] <wallyworld__> it's not a domain object though
[03:57] <wgrant> Have you regenerated your WADL?
[03:57] <wallyworld__> yes
[03:57] <wallyworld__> i'm treating it as a service
[03:58] <wgrant> You should be able to access it by lp.<whatever name you registered it as>
[03:58] <wgrant> But note it's the top-level collection name, not its URL.
[03:59] <wallyworld__> so i assume export_as_webservice_entry() is the correct way to register it
[03:59] <wgrant> wallyworld__: Anyway, these XSSes are now blocking deployment.
[03:59] <wgrant> No.
[03:59] <wgrant> Collections aren't entries.
[03:59] <wallyworld__> it's not a collection
[03:59] <wallyworld__> it's a service
[03:59] <wgrant> Hm, so it's a singleton entry?
[03:59] <wgrant> I guess that's OK, then.
[04:00] <wgrant> These things generally get exported as collections, but I guess your way makes more sense.
[04:00] <wallyworld__> the ws api is geared to export entries and collections sadly
[04:00] <wgrant> Just means there's no way to access it without lp.load
[04:00] <wallyworld__> ideally i'd like to say something like lp.get('/myservicename?ws.op=something')
[04:01] <wallyworld__> or lp.post(/myservicename?ws.op=something&data=foo)
[04:01] <wallyworld__> it that possible?
[04:04] <wallyworld__> wgrant: so where's the xss hole? in the picker config passed to the client from the view?
[04:04] <wgrant> wallyworld__: LaunchpadWebServiceCaller is the interface you get in tests.
[04:04] <wgrant> It looks like it speaks TCP
[04:04] <wgrant> So you can probably use it.
[04:05] <wgrant> LaunchpadWebServiceCaller(protocol='https') should work
[04:05] <wgrant> I hope
[04:06] <lifeless> wallyworld__: so why do you want that rather than lp.thing.something() and lp.thing.something(foo) ?
[04:06] <wallyworld__> lifeless: whatever works. i tried that and couldn;t get it to work
[04:06] <wallyworld__> that would be my preferred way
[04:06] <wgrant> Oh
[04:06] <wgrant> Then make that work :)
[04:06] <wgrant> What's the error?
[04:07] <lifeless> wallyworld__: so, suggestion, and I'm not being snarky - don't talk about what you don't want. Talk about what you do want!
[04:07] <wallyworld__> sure.
[04:07] <wallyworld__> the error is that lp has no attribute thing
[04:07] <wgrant> What's the expression?
[04:07]  * StevenK distracts wgrant with something shiny
[04:08] <wgrant> StevenK: Oh?
[04:08] <StevenK> wgrant: Are you okay with the MP given what lifeless said?
[04:08] <wallyworld__> so i'm not registering something properly. actually it's using the system launchpadlib
[04:08]  * wgrant reads the diff
[04:08] <wgrant> wallyworld__: You sure you're connected to dev and not prod?
[04:09] <wallyworld__> yep lp = Launchpad.login_with('testing', service_root='https://api.launchpad.dev', version='devel')
[04:09] <wgrant> And what is failing, and what is the exact text of the error?
[04:09] <wallyworld__> <launchpadlib.launchpad.Launchpad object at 0x85c4e90> object has no attribute 'accesspolicies'
[04:09] <wgrant> Right, you didn't register it as a top-level collection, so it won't appear there.
[04:09] <wallyworld__> clearly i haven't set something up correctly
[04:10] <wgrant> You have to use lp.load to get at it.
[04:10] <wallyworld__> so how do i avoid the lp.load() step?
[04:10] <wgrant> You can't.
[04:10] <wgrant> Unless you say define it as an empty collection.
[04:10] <lifeless> well
[04:11] <wallyworld__> ideally lp.accesspolicies would map to my AccessPolicyService
[04:11] <lifeless> what are the methods that you will have on this thing
[04:12] <wallyworld__> at the moment, i have foo()
[04:12] <wallyworld__> just to test it
[04:12] <lifeless> ok, but really
[04:12] <lifeless> help me understand
[04:12] <wgrant> StevenK: Bug titles are missing a colon
[04:12] <wgrant> It's now "Bug #1 blah blah blah"
[04:12] <wallyworld__> ok, getAccessPoliciesForProducts(product_collection, user)
[04:12] <_mup_> Bug #1: Microsoft has a majority market share <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <LibreOffice Productivity Suite:New> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Invalid by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS Project:In Progress> <metacity:In Prog
[04:12] <wgrant> Which doesn't make sense.
[04:13] <wallyworld__> lifeless:  so i want to go lp.accesspolicies.getAccessPoliciesForProducts(product_collection, user)
[04:13] <wallyworld__> or something like that
[04:13] <StevenK> wgrant: Right, noted in my +1, thanks
[04:14] <wallyworld__> lifeless: and in the browser, there'd be an XHR call to the same api to get the data for the view
[04:14] <lifeless> wallyworld__: you want to pass *in* a vector of products?
[04:14] <wallyworld__> a set based interface
[04:15] <wallyworld__> but there'd be just the one normally
[04:15] <lifeless> so, I'm hugely in favour of set based calls, as you know
[04:15] <lifeless> but all our existing api stuff would just make that a method on IProduct and IProject and IDistribution
[04:15] <wallyworld__> noooooooo
[04:15] <lifeless> (or IPillar probably)
[04:15] <wallyworld__> putting service methods in domain objects is just so wrong
[04:16] <wallyworld__> and i'd rather avoid that in this new tranch of work if possible
[04:17] <wallyworld__> so i want to try a service based approach
[04:17] <lifeless> That sounds good, but I htink then you need to commit to fixing the environment so that your new work is no worse than the current (which swimming upstream would be)
[04:18] <lifeless> specifically, you'll need to teach launchpadlib about named objects or some such
[04:18] <lifeless> one hack you could use is to create a collection of services - IService or something
[04:18] <wallyworld__> right, that's what i didn;t know - i didn't realise it couldn't do that
[04:18] <wgrant> Or just define this as a collection with [] as the default content.
[04:18] <wgrant> collections have methods too
[04:19] <lifeless> you'd need to fix the launchpadlib bug where the interface the wadl specifies the type of collection members even when they return a more specific type (and self-annotate as such)
[04:19] <wgrant> I'm not actually sure if /branches is usefully iterable, for example.
[04:19] <lifeless> or as wgrant says, an empty collection will get you a named service fairly cheaply
[04:19] <wallyworld__> and i'd still need .load() right?
[04:20] <wgrant> No
[04:20] <wgrant> Top-level collections show up as lp.foo
[04:20] <lifeless> wallyworld__: note though that the web API /only/ exports domain objects as far as its concerned, there isn't a separation there - and in most restful things I've seen there isn't a service layer as such
[04:20] <wgrant> See eg. IBranchSet.
[04:20] <lifeless> wallyworld__: so I'm not-at-all-sure your approach makes sense for the *external* API.
[04:20] <lifeless> wallyworld__: I'd kind of like to talk it through with you and curtis
[04:20] <lifeless> wallyworld__: I'd like to understand the vision
[04:21] <lifeless> wallyworld__: where you want to take it
[04:21] <wallyworld__> lifeless: i haven't talked to much to curtis about it
[04:21] <wallyworld__> lifeless: want to jhoin our standup tomorrow?
[04:21] <wgrant> This is very un-lazr.restful-ish.
[04:21] <wgrant> But I think that's probably a good thing.
[04:21] <wallyworld__> i'm experimenting a bit first to see what can be done
[04:22] <lifeless> wallyworld__: I probably have conflicting calls; I have 3 in a row; what time is it ?
[04:22] <wallyworld__> 8:00am AEST
[04:22] <wgrant> So 11:00am
[04:22] <wgrant> Damn Queenslanders.
[04:22] <wgrant> Oohoohoo
[04:22] <lifeless> 11am? surely you jest, he's not 3 hours out from you is he ?
[04:22] <wgrant> Just realised what time the TL call is going to be for bigjools.
[04:23] <wgrant> lifeless: He's 3 hours from you.
[04:23] <lifeless> so, 11am I can do
[04:23] <wgrant> One hour from us.
[04:23] <StevenK> wgrant: Do share?
[04:23] <lifeless> 6am
[04:23] <lifeless> at the moment
[04:23] <wgrant> lifeless: 6am for you, right?
[04:23] <lifeless> no
[04:23] <wgrant> Which makes it 3am for bigjools :)
[04:23] <wgrant> Oh
[04:23] <lifeless> 9am at the moment
[04:23] <lifeless> hugely civilised
[04:23] <wgrant> When did that change?
[04:24] <wgrant> Disappointing.
[04:24] <lifeless> when mrevell said roughly 'uhm, I need to put my kids to bed at the current time, can we change it'
[04:24] <wallyworld__> lifeless: so i want to try and adopt a service oriented approach, using popo for the business model objects, separate from the storm db layer objects, and views getting flattened data from api calls etc
[04:25] <wallyworld__> and still support "sensible" api access from launchpadlib
[04:26] <lifeless> so this in some ways fits with where I want to take LP itself: remember I want to gut the server render layer to have no DB access at all
[04:26] <wallyworld__> it's how i've always built these types of systems previously
[04:27] <lifeless> however I think it would be good to separate the discussion into what you want the API to do and look and feel, and what you want to do in the appserver; because all the appserver work will be irrelevant as we move to more SOA backends
[04:27] <lifeless> thats not a reason not to do appserver work - because some things pay for themselves very quickly, and improvements now are improvements now
[04:27] <lifeless> but I still want to get a handle on the specifics you're intending
[04:27] <wallyworld__> sure, np. it's still handwavy
[04:28] <lifeless> and how we'll measure the success of the experiment; and how we'll roll all the way forward, or roll back (depending on the assessed success)
[04:28] <wgrant> Anyway, we need to revert this picker thing.
[04:28] <wallyworld__> wgrant: what's the xss issue?
[04:28] <wgrant> wallyworld__: Put some stuff in a product title
[04:28] <wgrant> s/title/displayname/
[04:28] <wgrant> And visit +sharing
[04:29] <wallyworld__> so the json from the view doesn't get escaped properly?
[04:29] <wgrant> Correct.
[04:29] <wallyworld__> i thought it did?
[04:29] <wgrant> You may recall that I strongly discourage ever encoding JSON manually.
[04:29] <wgrant> And always using JSONRequestCache wherever possible.
[04:30] <wallyworld__> wgrant: rather than revert, it's a simple one line fix to get the product title out of the picker header
[04:30] <wgrant> That's not a fix.
[04:30] <wallyworld__> why?
[04:30] <wgrant> It's getting the one bit of bad data that I've found so far out of the unescaped section of the page.
[04:31] <wgrant> Rather than removing the injection of user-provided data into unescaped section of the page.
[04:31] <wallyworld__> we do that same pattern in a few other places in lp too
[04:31] <wgrant> Yes, and they're all bugs.
[04:31] <wallyworld__> eg the inline picker widget
[04:32] <wgrant> Just because something is embarrasingly terrible already doesn't mean we should perpetuate it.
[04:32] <wallyworld__> sure. that's the trouble when it's in the code - the pattern can be reused
[04:32] <wgrant> Hmm, I'm sure I've posed that point before and you've debated it :)
[04:33] <wallyworld__> so given the product title is the only user editable exploit, we could simply remove that for now
[04:33] <lifeless> wallyworld__: it is the problem, and thats why we need to finish our transitions and migrations more
[04:34] <wallyworld__> lifeless: well, i'm sure people thought the lazr picker work was finished when they did it
[04:34] <lifeless> wallyworld__: software is never finished ;)
[04:34] <wallyworld__> that's an answer to a slightly different question
[04:34] <lifeless> wallyworld__: we can only hope to put some of it in the ground soon :)
[04:35] <lifeless> wallyworld__: ok, so what was the question ?
[04:36] <wallyworld__> i was merely saying that the work in question was probably considered to be "finished", without the expectation there was still stuff to do
[04:36] <wgrant> It was finished.
[04:36] <wgrant> It was just wrong.
[04:36] <wgrant> fg
[04:36] <StevenK> No jobs running
[04:36] <wallyworld__> wgrant: or the jsonrequestcache encoder could be used in this case
[04:37] <wallyworld__> rather than stuffing new stuff in the cache
[04:38] <wallyworld__> so the json would be properly escaped
[04:38] <wgrant> That's what we've done in the past.
[04:38] <wgrant> But nobody remembers.
[04:38] <wgrant> This is why manual encoding is no longer permitted.
[04:39] <wallyworld__> i'll do that then for now
[04:39] <wgrant> (this is all because Microsoft are fucking morons, btw)
[04:40] <wallyworld__> so manual encoding works if done properly using the right encoder
[04:40] <wgrant> Yes.
[04:40] <wgrant> But I wasn't going to say that, because it's always a bad idea.
[04:41] <wallyworld__> and in this case, i forgot to use the right encoder
[04:41] <wgrant> That's why it's always a bad idea.
[04:41] <wallyworld__> wonder if we patch something  to force the correct encoder to be used by default
[04:41] <wgrant> There's also a second layer of XSS after this.
[04:41] <wgrant> So please just revert the whole thing :)
[04:42] <wallyworld__> wgat's the other xss?
[04:42] <wgrant> (an XSS I pointed out a few months ago during code review, but I was assured it would never be a problem)
[04:42] <wallyworld__> which is?
[04:42] <wgrant> The picker title is treated as HTML.
[04:42] <wgrant> So even once you encode the JSON properly, the product title is then injected unescaped into the picker.
[04:43] <wgrant> => revert it all until someone looks through it thoroughly.
[04:43] <wallyworld__> i'd have to look to check, but the picker title is in the json data so should be escaped
[04:43] <wgrant> Bonus points for deleting the rest of the pickers, but that seems unlikely.
[04:44] <wgrant> That's not how escaping works :)
[04:44] <wallyworld__> hmm? we use the correct encoder and the json data is all properly escaped
[04:44] <wgrant> Right, when using the correct encoder the JSON is escaped fine.
[04:45] <wgrant> But the JSON isn't really relevant for the second one.
[04:45] <wallyworld__> so that's what i was saying - i'd have to check but i thought the picker title was in the json data
[04:45] <wallyworld__> so would be escaped
[04:45] <wgrant> It is.
[04:45] <wgrant> That doesn't mean it's escaped properly in the picker.
[04:46] <wallyworld__> but if it comes from json data that is escaped....
[04:46]  * wgrant reverts it.
[04:46] <wallyworld__> hang on a minute
[04:47] <wallyworld__> the issue can be easily corrected using the proper encoder
[04:47] <wgrant> The first issue.
[04:47] <wallyworld__> and thye second issue is moot
[04:47] <wgrant> Oh?
[04:47] <wgrant> It happens, so it's not moot.
[04:48] <wallyworld__> it is since the title is escaped in thje json
[04:48] <wgrant> The JSON is escaped.
[04:48] <wgrant> The title is not escaped in the JSON.
[04:48] <wgrant> The point of escaping the JSON is to get the JSON through unharmed.
[04:48] <wallyworld__> if that's the case, then ALL of our pickers have this issue
[04:48] <wgrant> That doesn't meant he contents of the JSON are escaped.
[04:48] <wgrant> Yes.
[04:49] <wgrant> But few/none have variable data in the title.
[04:49] <wgrant> Most have no variable data in the config at all.
[04:49] <wgrant> Otherwise I would have started reverting every picker branch a year ago until it was fixed.
[04:49] <wallyworld__> ok, i'll revert this one.
[04:49] <wgrant> Thanks.
[04:53] <wgrant> This is similar to the reason I want to patch our mustache implementations to replace {{{ with {IAcknowledgeThatWgrantWillProbablyMaulMe{
[04:53] <StevenK> s/Probably//
[04:59] <lifeless> wgrant: s/mustache/handlebars/
[04:59] <lifeless> wgrant: and I know where the plumbing is to do that
[05:00] <wgrant> Heh
[05:05] <wgrant> Tempting to try making the factory more declarative at some point.
[05:05] <wgrant> Probably cut 40% off the test suite time.
[05:07] <StevenK> 2.4 hours is better than 4 :-)
[05:13] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bulk-insert-2/+merge/94084
[05:20] <StevenK> wgrant: +1
[05:22]  * StevenK wonders if he can force a bug to be a dupe
[05:22] <StevenK> Since dupe.markAsDuplicate(bug) doesn't work since dupe.owner can't see bug
[05:22] <wgrant> (one X crash later): StevenK: Thanks
[05:22] <StevenK> Haha
[05:23] <StevenK> Perhaps we need to bribe huwshimi to 'pay a visit' to RAOF.
[05:24] <huwshimi> StevenK: I can be there in 7 minutes
[05:24] <StevenK> Haha
[05:29] <wgrant> huwshimi: You worked on the current loggerhead theme, right?
[05:30] <huwshimi> wgrant: I'm not sure how to appropriately answer that question...
[05:30] <huwshimi> wgrant: Hypothetically, yes. If-stabbing-is-a-possibility, no.
[05:30] <wgrant> Heh
[05:31] <wgrant> Just wondering if you'd complain if I removed the 4px of padding around each line.
[05:31] <wgrant> I only stab for security holes :)
[05:31] <huwshimi> wgrant: Let me take a look
[05:31] <StevenK> (Pdb) p user
[05:31] <StevenK> <lp.registry.model.personroles.PersonRoles object at 0xfd81990>
[05:31] <StevenK> BAH
[05:33] <wgrant> wallyworld__: Any luck with bending launchpadlib to your will?
[05:34] <wallyworld__> wgrant: not yet, had to revert that branch and redo the mp
[05:34] <wgrant> Ah
[05:36] <huwshimi> wgrant: So you want to remove the 4px from the tds?
[05:37] <wgrant> huwshimi: Yeah
[05:37] <huwshimi> wgrant: Why would you want to do that?
[05:37] <wgrant> The code is pretty unreadable at present.
[05:38] <wgrant> It is currently at a density of 0.5
[05:38] <huwshimi> wgrant: Oh, you're not talking about the file listing then...
[05:39] <wgrant> Oh, no, http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/bootstrap.py
[05:39] <wgrant> Sorry
[05:39] <StevenK> wgrant, wallyworld__: Do either of you want to review https://code.launchpad.net/~stevenk/launchpad/bug-limitedview/+merge/94088 ?
[05:39] <wallyworld__> i can do it
[05:39] <wgrant> The file listing and changelog are pretty dense.
[05:39] <StevenK> wallyworld__: Thanks. How long before you need to disappear?
[05:40] <wallyworld__> StevenK: gotta go to soccer in about 90 mins
[05:40] <huwshimi> wgrant: I have no problem with that at all :)
[05:40] <wallyworld__> got a reprieve from picking up the kid today
[05:40] <wgrant> huwshimi: Thanks.
[05:40] <huwshimi> wgrant: It may require a little padding, but I'll leave that up to you
[05:40] <huwshimi> wgrant: Just check you don't break the other listings at the same time
[05:41] <StevenK> wallyworld__: If it takes you 90 minutes to review, I'd be concerned. :-P
[05:41] <wallyworld__> yep
[05:41] <wgrant> huwshimi: Yeah, I think 1px either side is possibly OK
[05:41]  * wgrant checks what other sites do.
[05:41] <huwshimi> wgrant: (I might have inadvertently added that spacing when I was trying to fix the other padding)
[05:41] <wgrant> Ah, indeed.
[05:41] <huwshimi> wgrant: I'll leave it to your judgement :)
[05:41] <wgrant> Thanks.
[05:41] <huwshimi> wgrant: Thanks that had been bothering me too
[05:42] <wallyworld__> StevenK: typo line 88
[05:43] <wallyworld__> StevenK: are there existing tests for the bugs security adaptor?
[05:43] <wgrant> wallyworld__: Oh, that reminds me, you misspelt duration in that commit too :P
[05:43] <wgrant> huwshimi: I might also try to make that view more friendly for copying.
[05:43] <wgrant> I wonder if side-by-side <pre>s works.
[05:43] <StevenK> wallyworld__: I'm not certain
[05:43] <wgrant> Rather than a terrifying table.
[05:44] <huwshimi> wgrant: yeah, you could easily float divs next to each other with numbers in one and code in the other
[05:45] <StevenK> wallyworld__: I've added another test: http://pastebin.ubuntu.com/852269/
[05:45] <wallyworld__> StevenK: the new unit tests that are there are good but are incomplete. perhaps a comment on the test case would be good explaining that mainly limitedView is being tested
[05:46] <StevenK> wallyworld__: Incomplete? You think I'm missing a scenario?
[05:46] <wallyworld__> StevenK: get_bug_privacy_filter() is the method that is used
[05:46] <wallyworld__> to see if someone can view the bug
[05:47] <wallyworld__> it covers subscribers also i think
[05:47] <wallyworld__> IBug.userCanView() calls get_bug_privacy_filter()
[05:49] <StevenK> wallyworld__: You've lost me
[05:50] <wallyworld__> StevenK: so the security adaptor calls IBug.userCanView() to check for view permission
[05:50] <wallyworld__> and IBug.userCanView() calls get_bug_privacy_filter()
[05:50] <wallyworld__> which checks for subscribers
[05:50] <wallyworld__> which the tests don't currently do
[05:51] <StevenK> wallyworld__: Okay, I'm fairly sure that should be well-tested, so I can drop my unittests, except for the last one?
[05:52] <wallyworld__> StevenK: i think so. just add a comment on the test case that just limitedview access is being tested
[05:52] <wallyworld__> and leave it as an exercise for the reader to figure out where the other stuff is tested :-)
[05:53] <StevenK> wallyworld__: http://pastebin.ubuntu.com/852278/
[05:53] <wallyworld__> StevenK: looks good to me
[05:54] <StevenK> wallyworld__: Pushing
[05:57]  * wallyworld__ still waiting for diff
[05:58] <StevenK> wallyworld__: Its updated for me
[05:59] <wallyworld__> StevenK: just updated for me too. took a while. r=me
[06:01]  * StevenK fills up QA-Landing
[06:26] <wgrant> huwshimi: http://people.canonical.com/~wgrant/launchpad/lh-view/old-view.png -> http://people.canonical.com/~wgrant/launchpad/lh-view/new-view.png
[06:27] <wgrant> (the new one is copyable, since it's a table of two <pre>s)
[06:27] <huwshimi> wgrant: Awesome
[06:28] <wgrant> Although there's still too much space above the top line
[06:28] <wgrant> StevenK, wallyworld__: Any comments?
[06:29] <wgrant> Trying to make loggerhead a bit less painful for reading code
[06:29] <wallyworld__> wgrant: +1 from me, looks nice
[07:13] <wgrant> fail
[07:13] <wgrant> The great LP bug migration corrupted things.
[07:29] <mrevell> Hi!
[07:33] <poolie> mrevell, hi there
[08:40] <adeuring> good morning
[09:35] <al-maisan> Good morning adeuring, how are things?
[09:35] <adeuring> hi al-maisan! things are fine here. how about you?
[09:36] <al-maisan> doing well, thanks :)
[09:53] <gmb> lifeless, Around?
[10:47]  * jml keeps hitting refresh
[13:30] <jelmer> 'morning abentley
[13:30] <abentley> jelmer: morning.
[13:31] <jelmer> abentley: I heard you're working on fixing the scaling issue in the branch scanner?
[13:31] <abentley> jelmer: Yes, mainly by fixing the DB access.
[13:31] <jelmer> abentley: cool
[13:32] <jelmer> abentley: I'm working on removing the use of Branch.revision_history and Repository.get_ancestry from the lp codebase, and as such was also touching that bit of the code
[13:32] <jelmer> it sounds like our changes shouldn't overlap though
[13:32] <abentley> jelmer: No, I don't think I touched the bzr side.
[13:33] <abentley> jelmer: It was only 13% of runtime when I profiled it.
[13:33] <abentley> jelmer: lp:~abentley/launchpad/bulk-insert
[13:33] <abentley> jelmer: You're just wanting to avoid deprecated interfaces?
[13:34] <czajkowski> are there any plans in the works to support proxy on launchpad? have two bugs today with issues about using launchpad in one country and having to use a proxy
[13:34] <jelmer> abentley: mostly, yeah. In the process I'm also changing things to not access all of the branch history/ancestry if it doesn't have to
[13:35] <abentley> czajkowski: I haven't heard of any plans, but I hadn't heard of any issues, either.
[13:36] <czajkowski> abentley: https://bugs.launchpad.net/launchpadlib/+bug/938542  and https://bugs.launchpad.net/launchpad/+bug/938580
[13:36] <_mup_> Bug #938542: launchpadlib doesn't support system proxy <launchpadlib :Triaged> < https://launchpad.net/bugs/938542 >
[13:36] <_mup_> Bug #938580: launchpad not opening in Syria.. <Launchpad itself:Triaged> < https://launchpad.net/bugs/938580 >
[13:36] <abentley> czajkowski: Oh, launchpadlib.
[13:37] <czajkowski> well one is launchpadlib and the other cant use LP without going through a proxy
[13:38] <abentley> czajkowski: I would be surprised if they were related.
[13:41] <abentley> czajkowski: So it sounds like one issue is that lazr.restfulclient (which launchpadlib uses) may not respect the system proxy settings.
[13:42] <abentley> czajkowski: And the other issue is that access to Launchpad in Syria doesn't work, *except* when a proxy is used.  Which may be due to government interference with the Internet.
[13:43] <czajkowski> nods
[13:44] <abentley> czajkowski: I would ask webops about the second one.
[13:44] <czajkowski> ok cheers
[13:46] <abentley> czajkowski: The first one needs investigation, but can certainly be fixed if true.
[13:47] <czajkowski> abentley: thanks
[14:03] <salgado> mrevell, hey there. did you have a chance to talk to huw/dan about that new page we'd like to implement in LP?
[14:32] <deryck> adeuring, abentley -- https://plus.google.com/hangouts/extras/talk.google.com/orange-standup
[14:32] <deryck> rick_h, I'm recalling you being away today, if not, see ^^
[15:49] <danilos> mrevell, heya, we have a chat scheduled in ~11 mins
[15:50] <mrevell> danilos, We do
[15:51] <danilos> mrevell, ok, just confirming, let's do mumble
[15:52] <mrevell> danilos, Dude, it's not 2010 any more.
[15:52] <mrevell> :)
[15:53] <danilos> mrevell, ah, right, sorry, proprietary software is "in" again ;)
[15:53] <mrevell> heh, Mumble it is, then.
[15:53] <salgado> mrevell, oh, is that the recurring one for which I've never gotten the invite?
[15:54] <danilos> salgado, you don't deserve one
[15:54] <mrevell> salgado, It's the recurring one, yeah. Let me see if I can fix the invite problem.
[15:54] <salgado> danilos, I know I don't but with mrevell being English and all I thought I'd get one if only for his politeness ;)
[15:54] <danilos> salgado, it's supposed to be in your canonical.com calendar
[15:55] <mrevell> haha
[15:55] <danilos> salgado, fair point
[15:56] <mrevell> I've sent an invite to your Linaro.com address, salgado
[15:56] <salgado> aha, now I got it
[15:57] <mrevell> great
[17:12] <lifeless> gmb: hi
[17:13] <gmb> lifeless, Hi. W.r.t my earlier ping, I was checking whether the fix for bug 518016 was in the subunit 0.0.8beta that's in the LP sourcedeps. From what I can tell from commit timestamps it is (you added the snapshot 9 minutes after committing the bugfix) but I just wanted to be sure.
[17:13] <_mup_> Bug #518016: No public API for tagging on TestProtocolClient <paralleltest> <Launchpad itself:Fix Committed> <subunit:Fix Committed> < https://launchpad.net/bugs/518016 >
[17:13] <gmb> (I assumed "yes" for the purposes of marking the bug fixed)
[17:19] <lifeless> gmb: yes makes sense to me :)
[17:19] <lifeless> gmb: or even fix released, as its not something that needs deploying to be fixed
[17:20] <gmb> lifeless, Righto, works for me. Thanks.
[17:22] <lifeless> abentley: AWS SWF looks interesting
[17:23] <abentley> lifeless: yes, indeed.
[19:25] <danhg> When is Pay Day? Does anyone know?
[19:34] <lifeless> http://blog.fastmail.fm/2012/02/20/building-the-new-ajax-mail-ui-part-2-better-than-templates-building-highly-dynamic-web-pages/
[19:36] <lifeless> gary_poster: 24061
[19:36] <lifeless> bah
[19:36] <lifeless> bug 24061
[19:36] <_mup_> Bug #24061: GPG error with apt-get/aptitude/update-manager behind proxy (BADSIG 40976EAF437D05B5) <apt (Ubuntu):In Progress> <update-manager (Ubuntu):Won't Fix> <apt (Ubuntu Precise):In Progress> <update-manager (Ubuntu Precise):Won't Fix> < https://launchpad.net/bugs/24061 >
[19:37] <gary_poster> lifeless, ah-ha, with workaround included! thanks
[19:37] <lifeless> gary_poster: basic troubleshooting is - remove the files from /var/cache/apt/ etc
[19:38] <lifeless> gary_poster: if that doesn't work, you're into figuring out what host is serving inconsistent data
[19:38] <lifeless> HTH
[19:38] <gary_poster> lifeless, do you agree with workaround listed in bug?
[19:51] <lifeless> the Acquire::BrokenProxy thing? if it works yes ;)
[19:52] <lifeless> gary_poster: ^
[19:53] <gary_poster> lifeless, heh
[19:53] <lifeless> I don't recall the code changes that triggers, but working >> most anything else
[19:54] <lifeless> you may, when running precise, naturaly encounter skew mid-archive-push, but the archive update scripts work hard to make the skew interval sub-second
[22:10] <abentley> lifeless_: Is https://code.launchpad.net/~abentley/launchpad/callgrind/+merge/94283 also worthy of a LOC waiver?
[22:10] <czajkowski> flacoste: should all questions end up being 'solved' rather than marked as 'answered' after a length of time
[22:24] <lifeless_> abentley: It seems to me that if the bzrlib lsprof module supported just a little more glue, you could delete the entire profiling support for scripts from LP and not miss it
[22:25] <wgrant> sinzui, jcsackett: https://wiki.ubuntu.com/Bugs/Status
[22:32] <sinzui> StevenK, wallyworld, jcsackett, wgrant: http://pastebin.ubuntu.com/853310/
[22:48] <lifeless> james_w: hey, so, django
[22:48] <james_w> hey
[22:49] <lifeless> james_w: what does your group do when getting a new django API/site up and running; do you use packages of django (are they in lucid-backports or a PPA) , ....
[22:49] <james_w> yes, we use packages
[22:49] <james_w> from lucid-cat currently
[22:50] <james_w> (to get django 1.3)
[22:50] <lifeless> do you use buildout or anything, or do sysadmins manually manage settings.py?
[22:50] <lifeless> (+ mod-wsgi glue?)
[22:51] <james_w> django.wsgi is delivered by puppet
[22:51] <james_w> we *may* use buildout, but we don't currently
[22:52] <james_w> settings are stored in a hierarchical way
[22:52] <james_w> main.cfg for settings used everywhere
[22:52] <james_w> dev.cfg and production.cfg for settings that are only appropriate in those environments, with a switch between them
[22:53] <hingo> Hello #launchpad-dev. Is it possible my launchpad ppa ignores the epoch number given in .changes file?
[22:53] <james_w> production_credentials.cfg delivered by puppet for secrets
[22:53] <james_w> hingo, I doubt it
[22:53] <james_w> all settings via django-configglue
[22:54] <hingo> I'm trying to: dput ppa:drizzle-developers/ppa drizzle_7.1.31~rc-1~oneiric1_source.changes
[22:54] <james_w> dependencies via a mix of packages (most things) and branches (things we develop that are tightly bound to the service)
[22:54] <hingo> ...but nothing (not even a failure) appears at https://launchpad.net/~drizzle-developers/+archive/ppa/+builds
[22:55] <james_w> devstaging deployments in ec2/canonistack using fab and some custom puppet (not related to memento unfortunately)
[22:55] <james_w> hingo, do you get an email about the upload?
[22:55] <hingo> The thing is, oneiric ships with drizzle_2011.03.13-something. So I have increased epoch to 1.
[22:55] <hingo> james_w: No.
[22:55] <flacoste> czajkowski: nah, answered is fine in the end, since it's up to the reported to mark them solved
[22:55] <wgrant> czajkowski: Users mark questions as solved once they confirm the answer.
[22:55] <wgrant> czajkowski: We should generally not set them to Solved ourselves.
[22:55] <james_w> hingo, then it is 99% likely that the .changes file is incorrectly signed
[22:56] <james_w> hingo, what is your LP username?
[22:56] <hingo> james_w: Ok. I created a generig GPG key. Do I need to use my own / matching email address?
[22:57] <hingo> james_w: hingo
[22:57] <czajkowski> flacoste: wgrant ok, just wondered as there are many not set as solved there. just curious
[22:57] <wgrant> czajkowski: A lot of users don't do it.
[22:57] <wgrant> But it doesn't matter much.
[22:57] <james_w> hingo, you need to register the GPG key that you are signing the upload with: https://launchpad.net/~hingo
[22:58] <wgrant> GPG verification of /srv/launchpad.net/ppa-queue/incoming/upload-ftp-20120222-215212-001713/~drizzle-devel
[22:58] <wgrant> opers/ppa/ubuntu/drizzle_7.1.31-rc-1_source.changes failed: Verification failed 3 times: ["(7, 9, u'No public key')", "(7, 9, u'No public key')", "(7, 9
[22:58] <wgrant> , u'No public key')"]
[22:58] <hingo> james_w: Ok, this makes sense. I'll upload the public key.
[22:59] <hingo> james_w: That explains it. Thanks a lot!
[22:59] <james_w> np
[23:00] <wgrant> StevenK: You also need to QA your double word thing.
[23:01] <wallyworld_> what happened to buildbot?
[23:01] <wgrant> webops: did someone kill it?
[23:02] <thedac> wgrant: that was me. We had defunct processes that needed cleaning up
[23:02]  * wgrant forces.
[23:06] <abentley> lifeless: I can see how you could reduce the number of lines of profiling support for scripts, but how would you remove it entirely?
[23:12] <hingo> There she goes: https://launchpad.net/~drizzle-developers/+archive/ppa/+builds?build_text=&build_state=pending
[23:13] <hingo> james_w: Thanks.
[23:13] <lifeless> abentley: If bin/py -m bzrlib.lsprof cronscripts/foo .... profiled cronscripts/foo in the same way bin/py -m pdb cronscripts/foo ... profiles it, then you don't need the script to know that it is being profiled
[23:13] <lifeless> .
[23:14] <james_w> lifeless, does that cover your questions?
[23:14] <wgrant> lifeless, poolie: I want to make the soft timeout flaggable like the hard timeout is. But unfortunately the feature controller is destroyed before the soft timeout is checked.
[23:15] <wgrant> I'm considering simplifying things by just storing the hard and soft timeouts in thread-locals at the start of the request.
[23:15] <wgrant> Rather than relying on the feature controller for every timeout check.
[23:15] <abentley> lifeless: Ah, I hadn't seen that before.  Yes, that might be worthwhile.  (Though profililing via bzrlib is a somewhat strange idea anyhow.)
[23:16] <wgrant> A lot of bzrlib seems like it should be called "this should really be in the standard library"
[23:16] <poolie> yeah
[23:17] <poolie> especially osutils
[23:17] <poolie> arguably also transport
[23:17] <abentley> wgrant: IIRC, the lsprof module was rejected from the standard library.
[23:17] <wgrant> Hah
[23:17] <poolie> wgrant, so you're saying you'll basically get it from the feature controller and remember it
[23:17] <poolie> oh also selftest
[23:17] <wgrant> poolie: Yeah
[23:17] <wgrant> poolie: We already preread it at the start of the request
[23:18] <james_w> if a language had excellent distribution support then I think it would take over the world, but that may be naive
[23:18] <wgrant> To get it cached so it doesn't require DB access later.
[23:18] <wgrant> But it relies on the feature controller surviving.
[23:18] <lifeless> james_w: I think so, basically if you look at oops-tools is uses buildout to drop a local copy of django
[23:18] <lifeless> so its not getting bugfixes
[23:18] <lifeless> james_w: is there a ppa with django 1.3 in it ?
[23:18] <james_w> lifeless, yes
[23:18] <wgrant> I could make the controller destruct later, but the way it's done now is reasonably nice.
[23:18] <james_w> https://launchpad.net/~canonical-ca-hackers/+archive/production/+packages contains the stuff we use from CAT
[23:18] <abentley> wgrant: The problem with the "batteries included" approach is when the batteries are all the same size :-)
[23:19] <wgrant> Heh
[23:19] <lifeless> james_w: any objection to e.g. LP using that, or nabbing packages from it ?
[23:19] <james_w> lifeless, none, we stole them from CAT after all :-)
[23:20] <lifeless> :P
[23:20] <james_w> obviously co-ordination is encouraged, as we all end up having to share again when things are pushed back to CAT
[23:20] <lifeless> yah
[23:20] <lifeless> I was more checking you're not tossing known-broken stuff in there
[23:21] <james_w> lifeless, I have all the dependencies of oops-tools packaged fwiw
[23:21] <lifeless> cool
[23:21] <james_w> lifeless, that PPA contains only what is deployed in production
[23:21] <james_w> lifeless, we have a staging PPA for the packages we are waiting for copying to CAT
[23:21] <james_w> so it's all very much things we expect to work
[23:34] <poolie> wgrant, thanks for the loggerhead improvements
[23:36] <wgrant> :)