[00:02] <wgrant> Someone linked to bug #1234 on the ISO tracker.
[00:02] <wgrant> I expect.
[00:02] <wgrant> Also, ubuntuqa uses edge.
[00:08] <lifeless> another bug to file
[00:46]  * StevenK grumbles at TALES being useless.
[00:59] <lifeless> .
[01:04] <StevenK> lifeless: http://pastebin.ubuntu.com/730574/
[01:09] <lifeless> win
[01:09] <lifeless> uhm, nothing jumps out at me
[01:14] <StevenK> What's annoying me is that I saw it last week, and I fixed it, and I can't remember how.
[01:15] <StevenK> wgrant: Do you have any clues from the above traceback?
[01:16] <wgrant> Not really.
[01:23] <StevenK> No traceback when not logged in. Curious.
[01:26] <wgrant> Hardly.
[01:26] <wgrant> It's in all probability the user info in the top right corner.
[01:27] <wgrant> That's what uses link-display-id or whatever it is the most.
[01:27] <StevenK> But factory.makePerson() should set all of that up, surely ...
[01:28] <wgrant> Which layer are you in?
[01:28] <StevenK> DatabaseFunctional
[02:10] <StevenK> wgrant: Is DatabaseFunctional too low?
[02:27] <wgrant> StevenK: shouldn't be.
[02:32] <StevenK> wgrant: Same error with LaunchpadFunctional :-(
[02:32] <StevenK> Oh, damn it, I know what I'm missing
[02:47] <huwshimi> Is anyone else getting sporadic "Exception: RabbitMQ server is not running." errors when trying to run 'make run'?
[03:09] <lifeless> huwshimi: not I
[03:09] <lifeless> huwshimi: but make run isn't a common thing for me atm
[03:09] <lifeless> huwshimi: poolie had that recently, but I don't know what was causing it for him
[03:09] <wgrant> I use make start and make run frequently.
[03:09] <wgrant> No trouble.
[03:09] <wgrant> But this is lucid.
[03:10] <huwshimi> hmmm
[03:11] <StevenK> AssertionError: queries do not match: 0 != 1817
[03:11] <StevenK> Whee!
[03:11] <lifeless> can has review ? https://code.launchpad.net/~lifeless/python-oops-twisted/bug-873030/+merge/81427
[03:11] <poolie> haha yes
[03:11] <StevenK> And 200 SPPH queries, so success
[03:11] <poolie> huwshimi, that's actually launchpad's cute way of saying "rabbitmq server *is* running" :)
[03:12] <lifeless> bbiab, -> shopping
[03:12] <poolie> i put up a patch to make it give a better message but i think it's not deployed yet
[03:12] <poolie> look for a stray rabbit process and kill it
[03:12] <huwshimi> poolie: Oh right. That is cute
[03:12] <StevenK> poolie: It doesn't need to be deployed, it just needs to be on devel
[03:12] <poolie> apparently our tone of voice is 'extremely sarcastic'
[03:12] <poolie> StevenK, does that come from a branch?
[03:13] <StevenK> poolie: lp:launchpad
[03:13]  * poolie goes to look
[03:13] <poolie> no, it needs to be fixed in rabbitfixture
[03:13] <StevenK> Ah
[03:13] <StevenK> Where does that live?
[03:13] <poolie> huwshimi, was that in fact your problem?
[03:14] <wgrant> It's an egg.
[03:14] <poolie> if so that nudges me to make sure my thing lands
[03:14] <huwshimi> poolie: I'm not sure, I'll try next time it complains
[03:14] <wgrant> The only things that come from branches are bugs.
[03:14] <poolie> by 'deployed' i meant 'packaged updated etc'
[03:14] <poolie> huwshimi, if there's an orphaned instance i think it will happen again next time until you do kill it
[03:15] <huwshimi> poolie: it hasn't complained for a while
[03:15] <poolie> wgrant, ha ha
[03:15] <poolie> but, what are the things in sourcecode/ then?
[03:16] <StevenK> poolie: We have three ways of adding dependencies.
[03:16] <wgrant> poolie: They're bugs.
[03:16] <wgrant> poolie: They shouldn't be branches.
[03:16] <poolie> i know this
[03:16] <poolie> StevenK, i know there are 3 ways
[03:16] <poolie> is this wgrant's way of saying that one of those ways is deprecated?
[03:17] <wgrant> Or at least generally discouraged, yes.
[03:17] <wgrant> (also, there's a fourth way: including them in the tree)
[03:18] <poolie> that's what you mean by saying they're bugs?
[03:18] <wgrant> Yes.
[03:19] <StevenK> Oh, ugh, I didn't know we linked from lib into sourcecode.
[03:19] <wgrant> That's how sourcecode works :)
[03:19] <StevenK> That's disgusting, kill it.
[03:20] <StevenK> wgrant: I have a test that works!
[03:20] <StevenK> wgrant: It's a bit evil at the moment since it creates 100 BugNominations, but it proves the query count is excessive
[03:23] <StevenK> Oh, it's even worse. lib/mailman is a copy of sourcecode/mailman
[03:25]  * StevenK tries to work out how to prefetch the entire batch to seed Storm's cache
[03:30] <huwshimi> I'm guessing in Launchpad there is no intelligent way to create user icons from there logos or mugshots right?
[03:31] <wgrant> huwshimi: No.
[03:31] <huwshimi> #$%
[03:31] <wgrant> huwshimi: For projects we ask them to upload a separate 14x14 image.
[03:31] <wgrant> Particularly since you can't sensibly scale much down to 14x14
[03:31] <huwshimi> well you can, we just don't have the infrastructure
[03:32] <lifeless> image scaling without jaggies is not -all- that simple. We might have been better off asking for a single svg.
[03:33] <wgrant> O_o
[03:33] <wgrant> not sure if serious
[03:33] <huwshimi> No,
[03:33] <huwshimi> this is ridiculous
[03:34] <huwshimi> why do we have to overthink everything
[03:34] <huwshimi> this the web
[03:34] <huwshimi> people scale images ALL THE TIME
[03:34] <wgrant> Yes.
[03:34] <huwshimi> and they don't have massive scaling SVG mega frameworks, just to do the simplest of things
[03:35] <wgrant> Using SVG here is entirely ridiculous.
[03:36] <wgrant> But I'm not convinced that we can usefully scale normal sized images all the way down to our 14x14 icon format.
[03:36] <lifeless> it all depends on what the criteria you're aiming for are. If we are happy with browser scaling, just set attributes on the image.
[03:37] <wgrant> Anything below 32x32 tends to be pretty hideous, IME.
[03:37] <lifeless> If we aren't happy with browser scaling, I think its a safe assumption we won't be happy with unattended resizing either.
[03:37] <lifeless> (Because browsers keep iterating on their scaling logic to make things look good, so they are pretty solid)
[03:38] <huwshimi> lifeless: Really and use all the extra bandwidth, you really think that's the best practice here?
[03:38] <huwshimi> lifeless: And how about background images?
[03:39] <huwshimi> lifeless: Shall we exclude older browsers from having scaled images too?
[03:39] <lifeless> huwshimi: I don't know - I'm not *setting* the goals here -
[03:39] <lifeless> huwshimi: you'll know much better than I the limitations of the browsers we're dealing with
[03:40] <huwshimi> lifeless: Right, but this is a solved problem. Let's not invent a new ethos for handling images
[03:40] <lifeless> huwshimi: thats great
[03:41] <lifeless> huwshimi: I didn't realise it was so well solved :)
[03:42] <wgrant> Hmm? Server-side thumbnailing isn't exactly an uncommon, new concept...
[03:42] <huwshimi> wgrant: Thankyou
[03:42] <StevenK> Perhaps lifeless is one of our four IE6 users.
[03:43] <lifeless> wgrant: not down to 14x14
[03:43] <wgrant> I recall implementing it in some of my early web projects in like 2002, and it was probably popular before then and 10-year-old me just didn't realise.
[03:43] <wgrant> No.
[03:43] <wgrant> Not down to 14x14.
[03:43] <wgrant> I agree that we can't do that.
[03:43] <lifeless> thumbnailing is one thing
[03:43] <lifeless> but extremely large, or extremely small scales are damn tricky
[03:44] <huwshimi> lifeless, wgrant: You seriously think we shouldn't scaled down to ~14 (or 20 or whatever we want for small icon sizes)? You seriously think most people aren't just going to scale it before they upload it anyway (if they're a project)
[03:44] <lifeless> heck, Next machines in 1997 happily thumbnailed images in a directory listing, if memory serves.
[03:44] <wgrant> It is a rare website that uses small icons like that.
[03:44] <wgrant> We should probably stop.
[03:45] <wgrant> huwshimi: No, I argue that we shouldn't be using 14x14 icons for projects and people.
[03:45] <wgrant> I don't think anyone else does.
[03:45] <wgrant> They use more sensible stuff of at least 20x20, from what I've seen.
[03:45] <lifeless> huwshimi: I know that its hard to get a good representation of a logo at 14x14 without manual fixups - e.g. an icon editor
[03:46] <lifeless> huwshimi: I don't know if our users care about that
[03:46] <lifeless> huwshimi: and I don't know if we need 14x14 for any reason other than having it already.
[03:46] <wgrant> Exactly.
[03:46] <lifeless> huwshimi: I am not about to argue for complexity we don't need : see francis bug report for the cost of complexity on us as a team.
[03:46] <huwshimi> right, but that shouldn't stop us from forcing users and ourselves into set sizes (192, 64, 14)
[03:47] <lifeless> huwshimi: one answer, for instance, is to scale by default and allow overrides for folk to fix things up
[03:48] <lifeless> stub: https://code.launchpad.net/~lifeless/python-oops-twisted/bug-873030/+merge/81427 (OCR penance time)
[03:48] <lifeless> huwshimi: if your new design will permit a larger micro size, it may make a substantial difference to auto-scaled images [experimentation or citatin needed]
[03:50] <StevenK> My prefetch query doesn't impact the query count :-(
[03:50] <huwshimi> Ugh, it just turns my job into a pipe-dream, as everything I design requires weeks of work to implement the simplest thing (and would never get priority over other work)
[03:50] <StevenK> It could just be a stupid query
[03:52] <stub> lifeless: k
[03:52] <lifeless> StevenK: might be the cache size as well
[03:52] <wgrant> StevenK: dev runs with a storm cache of only 100 objects.
[03:52] <wgrant> StevenK: Product uses 10000
[03:52] <wgrant> Production, that is.
[03:53] <lifeless> huwshimi: are there js only scaling libraries? I assume there must be
[03:53] <lifeless> huwshimi: you could scale on the client and upload three things from one js form
[03:53] <lifeless> huwshimi: s/you could/could you/?
[03:53] <StevenK> wgrant: Right, so my test might just be too large at the moment
[03:53] <huwshimi> lifeless: Well there kind of are, but they still require the client to download the full-size image
[03:53] <lifeless> StevenK: or just about right
[03:53] <StevenK> wgrant: TBH, I'm tempted to just blame my current query
[03:54] <lifeless> huwshimi: I meant in the edit form for the person; do all the prep on the client
[03:54] <StevenK> lifeless: I'm creating 100 bug nominations, and then browsing the view with ?batch=100. It seems excessive to me, and I wrote it.
[03:54] <lifeless> huwshimi: that would avoid nearly-all backend changes
[03:54] <huwshimi> lifeless: Oh, I see. Well there's no javascript version of PIL, Imagemagick etc. no.
[03:54] <lifeless> huwshimi: which is where we are not really prepped to do dynamic stuff
[03:56] <lifeless> huwshimi: we have reasonable tools to run e.g. imagemagick in the backend, but they aren't trivial to use if you're not familiar with them, which IIRC was one of your goals
[03:57] <stub> lifeless: So you do want a grammar and coding style review, or wait for someone who knows a bit about twisted and wsgi?
[03:57] <lifeless> stub: jamesh is eyeballing it
[03:57] <lifeless> stub: I hope he's wiring it up to test in the u1 stack
[03:57] <lifeless> stub: as much of a review as you want to give would be great.
[03:57] <huwshimi> lifeless: I'm not sure quite what you mean. It's pretty easy to set up PIL for thumbnailing etc. (it even has .thumbnail())
[03:58] <lifeless> huwshimi: I would expect that to be done in a 'job' straight after the upload succeeds, to avoid timeout issues.
[03:59] <lifeless> huwshimi: which involves a new table; a new config entry to run under the shared job environment, some tests for your code, and a Job definition
[03:59] <StevenK> And 64 million interfaces
[04:00] <lifeless> we're iterating towards this being lighter still
[04:00] <huwshimi> lifeless: Sure, or it is often set up as a service when required (e.g. launchpad.net/thumbnail-service/14/14/file.jpg)
[04:00] <lifeless> and, pick yourself off the flow, it used to be much worse
[04:00] <lifeless> huwshimi: s/flow/floor/
[04:01] <lifeless> huwshimi: I'd have some scaling worries about a JIT service, though yes we could do one.
[04:01] <stub> lifeless: what is the number after your name in NEWS?
[04:01] <lifeless> stub: did I forget the # ? its a bug number
[04:01] <huwshimi> lifeless: Right, but anyway, I'll stop talking about this now as it is only a frustrating mental exercise
[04:02] <stub> lifeless: And the word 'Bug' :)
[04:02] <lifeless> stub: not needed ;)
[04:02] <lifeless> stub: the rest of the file - and in other projects too  - just does #1234
[04:03] <stub> Yay for confusing
[04:03] <lifeless> seen a Debian/changelog recently ? :)
[04:03] <stub> 'Better than a Debian changelog' is damning with faint praise
[04:04] <stub> But at least with the '#' it won't look like you are giving your body measurements or date of birth
[04:04] <lifeless> :)
[04:13] <StevenK> Hm, my query doesn't help with only 10 bug nominations either, still 197 queries.
[04:13] <lifeless> StevenK: is your theory that they *can* come out of cache false?
[04:14] <lifeless> StevenK: if the deeper code is doing anything *other* than attribute traversal, you can't optimise by cache loading.
[04:14] <lifeless> StevenK: you would need to actually setify the logic (which is a good thing anyhow)
[04:14] <StevenK> lifeless: I thought I could cache the bugnominatons themselves in the first case.
[04:15] <StevenK> But it seems that is pointless
[04:16] <StevenK> lifeless: So, I'm tempted to declare that cache seeding won't help, but then I'm stuck about what I can do instead
[04:16] <lifeless> have you identified the cause of the problem ?
[04:17] <StevenK> I've identified what is causing the masses of SPPH queries.
[04:17] <lifeless> go on
[04:17] <StevenK> I'm not sure if that is the cause, but it's one thread to tug on.
[04:19] <wgrant> StevenK: This is for latest_published_component?
[04:19] <lifeless> StevenK: ok, so can you pastebin the call stack ?
[04:19] <StevenK> wgrant: So latest_published_component wants SPPH, and I then I think verifyUpload() does too
[04:19] <wgrant> StevenK: How are you preloading it?
[04:19] <wgrant> You'll need to turn it into a cachedproperty.
[04:20] <wgrant> And populate it manually in a set-based manner.
[04:20] <StevenK> wgrant: Currently, I was trying to cache the bug nominations themselves first, but that hasn't changed anything.
[04:20] <wgrant> Are there lots of BugNomination queries?
[04:21] <StevenK> wgrant: 2 per row
[04:21] <wgrant> That doesn't make much sense.
[04:21] <wgrant> Do you have a query log?
[04:21] <StevenK> Yup
[04:22] <StevenK> wgrant: http://people.canonical.com/~stevenk/test_query_log.txt
[04:23] <lifeless> none of those are attribute access queries
[04:23] <wgrant> Ah, so SPPH isn't really the problem at all.
[04:23] <wgrant> The whole thing is.
[04:23] <lifeless> they are all explicit lookups from procedural code AFAICT in a quick glance
[04:23] <StevenK> Heh
[04:23] <lifeless> cache cannot help you at all
[04:23] <wgrant> Well, the built-in Storm cache can't.
[04:23] <lifeless> ^storm ...
[04:23] <wgrant> cachedproperty can
[04:24] <wgrant> So, you are going to need to radically setify canApprove.
[04:24] <wgrant> Unless you want to do it all manually beforehand, which I would discourage.
[04:25] <StevenK> Right, so canApprove() is the crux of the problem. I certainly agree.
[04:25] <lifeless> so what you need to do is write a set based version of it
[04:25] <wgrant> s/crux of/
[04:25] <lifeless> that takes many nominations (or something like that) and figures out the answer for all of them.
[04:25] <wgrant> Exactly.
[04:25] <lifeless> make the existing canApprove forward to that new function
[04:26] <lifeless> and finally migrate this code path over to use the new function directly with all of the nominations for the page
[04:27] <StevenK> But canApprove() is hideous :-P
[04:27] <lifeless> yes
[04:27] <lifeless> take small bits
[04:27] <lifeless> *bites*
[04:27] <StevenK> Hm, there is a BugNominationSet ...
[04:28] <StevenK> So there are two issues I can see.
[04:28] <StevenK> 1. My batch in the view is bugtasks.
[04:28] <StevenK> 2. canApprove() sucks
[04:29] <lifeless> the other alternative is to eliminate nominations; is possible that the new security rules mean they are not useful now.
[04:29] <lifeless> so 1) is something that cachedproperty may help with
[04:31] <StevenK> Oh, sure, eliminating nominations doesn't sound controversial *at all* :-P
[04:46] <StevenK> wgrant: Can I beg you for a pre-impl about this new method?
[04:47] <wgrant> It's pretty simple really, but OK.
[05:03] <poolie> wgrant, re bug 435905, i wonder if you would agree we should just close it
[05:03] <poolie> and keep wrapping roughly where we currently do
[05:03] <poolie> until we get proper markup
[05:04] <lifeless> 3K timeouts. Hmm
[05:04] <wgrant> lifeless: Network outage overnight.
[05:04] <lifeless> stub: so no review results ?
[05:04] <lifeless> stub: or just the # is it ?
[05:05] <wgrant> poolie: Do you really mean me?
[05:06] <poolie> i do; istr you had some opinion about always using greasemonkey before
[05:06] <poolie> and your 'fix the defaults' reminded me of it too
[05:06] <wgrant> Ah.
[05:06] <wgrant> Well, I think the fix for it is markup.
[05:06] <stub> lifeless: Getting there, distractions distractions
[05:06] <poolie> then i agree
[05:06] <poolie> thanks
[05:06] <lifeless> stub: ;)
[05:07] <lifeless> aieee, gmail, what have you done
[05:07] <wgrant> poolie: The current uploads work mostly. We shouldn't keep hacking it to make various special cases work. We should do what the rest of the world does.
[05:07] <wgrant> We should follow what the rest of the world does for an awful lot of things.
[05:07] <wgrant> We needed to do our own thing 7 years old.
[05:07] <wgrant> s/old/ago/
[05:08] <wgrant> But it's no longer 7 years ago, and the world has moved on.
[05:08] <poolie> 'current uploads'?
[05:08] <wgrant> Er.
[05:08] <wgrant> Sorry, multiple conversations.
[05:08] <poolie> current css?
[05:08] <wgrant> Yes.
[05:08] <poolie> i agree with the general thing anyhow
[05:09] <poolie> i do wonder how much say feature flags or timelines are available externally in other frameworks
[05:09] <lifeless> rpm.net
[05:10] <poolie> ?
[05:10] <poolie> it lapsed?
[05:11] <lifeless> huh
[05:11] <lifeless> let me find their current home
[05:11] <poolie> did you mean rpmfind?
[05:11] <wgrant> Was that the fork, or the not fork?
[05:11] <wgrant> I can't remember.
[05:12] <poolie> the description of the hardware on http://rpmfind.net/ is awesome
[05:12] <poolie> though i bet we have some that is older
[05:12] <lifeless> http://newrelic.com/
[05:12] <lifeless> huh, they have added python since I last strolled by
[05:14] <lifeless> http://newrelic.com/docs/python/instrumented-python-packages
[05:14] <poolie> mm
[05:14] <poolie> there may even be free versions
[05:15] <poolie> s//alternatives
[05:15] <lifeless> well, oops-tools & sentry are in that space, though neither is anywhere -near- as advance.
[05:16] <lifeless> oops-tools is the most metric enabled open end-to-end one I know of for Python
[05:17]  * stub wonders why magic asynchronous tests are a good idea
[05:19] <lifeless> stub: magic?
[05:19] <poolie> is there any kind of trick about $PYTHONWARNINGS?
[05:19] <stub> test methods returning deferreds with callbacks that the test runner somehow executes because the test case class has a property set to a particular value
[05:20] <lifeless> stub: well, you need *something*
[05:20] <lifeless> stub: this has the nice property that its extensible to different async environments in one library (vs e.g. twisted trial)
[05:21] <stub> because tests being nearly the ultimate in synchronous code require asyncronicity
[05:22] <lifeless> yeah, they very much do when the code is callback based
[05:22] <lifeless> and the callback engine doesn't guarantee pause/resume/single step facilities
[05:22] <stub> but a helper invoked explicitly would remove the magic
[05:23] <stub> And would even allow you to test post state without registering these tests as callbacks.
[05:24] <lifeless> see under callback engine guarantees
[05:24] <stub> d.addCallback(lambda _: self.assertEqual(expected, self.calls)) would be much more readable as just self.assertEqual(expected, self.calls)
[05:25] <stub> That doesn't mean anything to me.
[05:26] <poolie> but there's a difference ,right
[05:26] <poolie> the assertion is: _eventually_ when this is called, there are N calls
[05:28] <lifeless> stub: I agree that it would be nicer if it was single stepped and looked just like regular python
[05:28] <stub> I don't see the difference between 'd.addCallback(lambda: blah blah assert blah); return d' and 'self.run_deferred(d); self.assert'
[05:28] <lifeless> in principle inlineCallbacks could be used.
[05:28] <huwshimi> A review for some lovely person, if possible: https://code.launchpad.net/~huwshimi/launchpad/avatars-everywhere-712894/+merge/81430
[05:29] <stub> Yer, just the more I see twisted code the more I think that twisted was a bad idea and should never have been shoe horned into Python.
[05:30] <stub> Code that makes you go 'blergh' when you haven't gone through the indoctrination process keeps you isolated.
[05:35] <lifeless> huwshimi: I've given it a once over
[05:35] <poolie> ah, the trick is it's new in 2.7?
[05:35] <lifeless> poolie: what is new in 2.7 ?
[05:36] <poolie> $PYTHONWARNINGS
[05:36] <lifeless> ah, dunno.
[05:36] <poolie> added by one B. Warsaw
[05:45] <nigelb> *yawn*, morning
[05:50] <poolie> hi nigel
[05:50] <nigelb> Hey poolie :)
[05:50] <poolie> is there some easy way to override buildout and make it use a dependency from a tree, while i'm futzing with it?
[05:50] <poolie> i guess replace the egg with a symlink
[05:52] <wgrant> poolie: You should be able to symlink the tree into the root of your LP tree, then add the dir name to the 'develop' setting in buildout.cfg.
[05:53] <lifeless> poolie: bin/buildout buildout:develop=". ../path/to/tree"
[05:54] <lifeless> wgrant: no need to symlink
[05:54] <wgrant> Oh, or that.
[05:54] <wgrant> Didn't know that worked.
[05:56] <poolie> wow, ok
[05:57] <poolie> so those two trees come before everything else?
[05:58] <wgrant> develop should just be '.' by default... what do you mean?
[05:58] <poolie> huwshimi: whoa!
[05:59] <poolie> wgrant, i meant before things pulled in from eggs
[05:59] <poolie> huwshimi, that would be a good thing to add behind a user 'labs' switch
[05:59] <poolie> though i'm not suggesting you block on adding one
[05:59] <wallyworld_> stub: hi, i have a sql question for you if you have a moment sometime
[05:59] <huwshimi> poolie: Yeah, we'll see how much it breaks launchpad :)
[06:00] <StevenK> wgrant: http://pastebin.ubuntu.com/730709/
[06:00] <poolie> at least a flag would be good
[06:00] <StevenK> wallyworld_: Just ask, it may not be stub that answers.
[06:00] <huwshimi> poolie: Wouldn't labs be similar to launchpad-beta-testers?
[06:00] <wallyworld_> StevenK: it's a performance related thing
[06:01] <StevenK> wallyworld_: Then lifeless or wgrant would probably also have opinions
[06:01] <wallyworld_> fair enough. although i didn't want to bug them :-)
[06:01] <wallyworld_> but anyway, i think this will be ok, hopefully: https://pastebin.canonical.com/55351/
[06:02] <wallyworld_> it is to check whether a given person owns any pillar
[06:02] <wallyworld_> and i'm looking to use it amongst other places in a storm validator
[06:02] <wallyworld_> so i want it to perform well
[06:03] <wallyworld_> there's a similar query for isSecurityContact
[06:03] <poolie> huw, it would be similar with a few differences
[06:03] <poolie> - the ui is more obvious than joining/leaving a team
[06:03] <poolie> - teams are kind of used for too many things
[06:04] <poolie> - we can have more than one concurrent experiment
[06:04] <stub> wallyworld_: That query seems very odd.
[06:04] <poolie> - we could hook it up to feedback
[06:04] <poolie> - oh, users would have a clearer idea what things were experimental
[06:04] <wallyworld_> stub: maybe. the unit tests pass :-)
[06:04] <wallyworld_> but if it can be improved...
[06:04] <poolie> at the moment they just see everything (though i believe they're going to get some kind of systematic indication in future)
[06:04] <wgrant> wallyworld_: I'd prefer that it was in a setter, not a storm validator.
[06:05] <stub> Yes, but selecting the first row from the person table if the EXISTS matches, throwing it away and returning true...
[06:05] <wallyworld_> stub: the only reason is use select from person was to keep dtore.find happy
[06:06] <wallyworld_> stub: i can constuct sql without any table "select exists ...." but storm complains
[06:06] <wallyworld_> i guess i could do a store.execute() with raw sql?
[06:06] <wallyworld_> by complains i mean store.find() says "there's no table"
[06:07] <wallyworld_> if i try and run something like "select exists (select something where condition)"
[06:08] <wallyworld_> wgrant: storm validators are bad?
[06:08] <wallyworld_> they seem to be used in the type of thing i'm doing already
[06:08] <wallyworld_> eg is_valid_person and friends
[06:09] <wgrant> Lots of things are already used for lots of types of things :)
[06:09] <wgrant> I think Storm validators impede clarity.
[06:10] <wgrant> And are often used to do very bad things.
[06:10] <wallyworld_> i don't agree that they hinder clarity
[06:10] <wallyworld_> anything can be misused
[06:11] <wgrant> Storm validators become problematic when eg. you want to pass an argument into them.
[06:11] <wgrant> For example, admins might be allowed to override some restrictions.
[06:11] <stub> https://pastebin.canonical.com/55352/ might work better
[06:11]  * wallyworld_ looks
[06:12] <lifeless> huwshimi: I suspect it will need the eager loading changes I reference done before you can enable the flag :(
[06:12] <lifeless> huwshimi: Its very cool to see it being done
[06:12] <wgrant> lifeless, huwshimi: It also has an XSS hole or two.
[06:12] <stub> wallyworld_: But what you have is just as fast despite looking a bit WTF?
[06:13] <wallyworld_> stub: thanks. i'll use that. although the one i pasted also works, but your is easier to grok i guess.
[06:13] <huwshimi> lifeless: Oh, sorry I mis-understood
[06:13] <wallyworld_> stub: i guess i was trying to avoid the count(*)
[06:13] <stub> wallyworld_: I'm not sure of how to shoe horn it into Storm
[06:13] <lifeless> huwshimi: I was probably unclear
[06:13] <huwshimi> lifeless: It's all good
[06:13] <lifeless> huwshimi: Landing with a flag is fine, I just think its near-certain that enabling it will make things timoeut
[06:13] <huwshimi> lifeless: Sure
[06:13] <lifeless> huwshimi: so you could, if you think I'm wrong try it and possibly save yourself some time
[06:13] <stub> wallyworld_: If you go for yours, change the UNION to UNION ALL
[06:13] <wallyworld_> stub: i think because yours does a select from... i can get it in
[06:13] <lifeless> (IMBW)
[06:14] <lifeless> I don't think I am, in this case.
[06:14] <huwshimi> lifeless: What's involved in making the eager loading changes?
[06:14] <wallyworld_> stub: ok. i'll have a look at it. if it all goes pear shaped, i can always revert to my original sql since the performance is ok
[06:14] <wallyworld_> thanks
[06:15] <huwshimi> lifeless: Is it something I can take a look at?
[06:15] <stub> wallyworld_: We are looking at <10ms, so whatever ;)
[06:15] <wallyworld_> stub: cool. the perf figure is what i was after. thanks :-)
[06:15] <wallyworld_> wgrant: i agree about the argument passing thing. so validators are good for invariant conditions
[06:16] <wgrant> wallyworld_: It's *presently* invariant.
[06:17] <huwshimi> wgrant: Where are the XSS holes? This is mostly just existing code, but I'm happy to fix it up a bit
[06:17] <wallyworld_> yes. i don't see this one changing though
[06:17] <wallyworld_> but perhaps it could
[06:17] <lifeless> huwshimi: the key function is the one I mentioned in my review
[06:17] <wgrant> StevenK: if reason is not None and not (is_new and getComponentsForUpload)
[06:17] <lifeless> getPrecachedPersonsFromIDs
[06:17] <lifeless> which calls
[06:17] <lifeless> _getPrecachedPersons
[06:18] <lifeless> the related but separate cacheBrandingForPeople already grabs all three sizes
[06:18] <lifeless> so you don't need to touch that
[06:19] <huwshimi> lifeless: Ah I see
[06:19] <wgrant> huwshimi: The URL contains user-controlled content (in the filename), and it's now in the page unescaped. cgi.escape is also no good for attribute values -- it doesn't escape quotes by default.
[06:20] <wgrant> huwshimi: I recommend that you use structured()
[06:20] <wgrant> In c.l.w.menu
[06:20] <huwshimi> lifeless: I have to go deal with a whinging baby, but I'll take a look at this tomorrow.
[06:20] <huwshimi> wgrant: Thanks, I'll take  a look
[06:21] <StevenK> wgrant: http://pastebin.ubuntu.com/730715/
[06:22] <lifeless> huwshimi: cool. Please feature flag it *anyway* because we may well find that this change causes brand new late evaluations
[06:22] <huwshimi> lifeless: Sure, no problems. Thanks for that
[06:22] <lifeless> huwshimi: I may seem to be being overly cautious here, but believe me, LP is designed to be slow
[06:22] <lifeless> so we're fighting all the time
[06:22] <huwshimi> lifeless: Haha, no I totally understand
[06:27] <poolie> lifeless,  thanks for the tip about setup.py
[06:28] <poolie> the one in oops-repository was trivially broken
[06:28] <poolie> i pushed a fix
[06:30] <lifeless> oh thanks
[06:38] <poolie> i get a warning about extras_require and install_requires
[06:38] <poolie> but perhaps they're used by one of the other cluster of tools
[06:42] <lifeless> yah
[06:48] <lifeless> thanks for the review stub
[07:15] <lifeless> stub: shall we catchup ?
[07:29] <stub> lifeless: sure.
[07:29]  * stub boots laptop
[07:31] <poolie> lifeless, still here?
[07:32] <poolie> i thought i would need to dpkg txfixtures so it could be installed on the buildd guests
[07:48] <lifeless> poolie: ah possibly. I don't know enough there sorry :(
[07:48] <poolie> pretty sure
[07:48] <poolie> at any rate if we're going to split this out as a dependency of buildds it will need to get there somehow
[08:35] <lifeless> stub: d/c ?
[08:54] <adeuring> good morning
[09:40] <jelmer> does anybody know what is up with strawberry (qastaging's code importer) ? It doesn't seem to be processing code imports.
[09:43] <StevenK> jelmer: Ah, you're attempting to QA r14243?
[09:44] <StevenK> Hm, no rvba today.
[09:44] <jelmer> StevenK: no, I was hoping to QA bug 485932
[09:45] <StevenK> jelmer: Yes, which is linked to stable r14243. :-)
[09:45] <StevenK> allenap: Could you try and QA r14234, r14250 and r14260 today at some point?
[09:46] <wgrant> jelmer: qastaging had some download-cache issues earlier. Might want to poke a LOSA to poke strawberry.
[09:46] <bigjools> jelmer: are you able to do some QA please? http://launchpad.net/bugs/485932
[09:46] <StevenK> bigjools: He just said he was ...
[09:46] <bigjools> ah, /me reads backscroll
[09:46] <jelmer> wgrant, StevenK: I'll check with a LOSA, thanks
[09:46] <StevenK> bigjools: Have you bugged rvba for the three revisions he has to do? :-)
[09:47] <bigjools> StevenK: I see you're on the same jihad as me
[09:47] <lifeless> bigjools: what rt should I tweak to add the oopses exchange to the txlpongpoll permissions (on all three sites)
[09:47] <StevenK> bigjools: Yes. The deployment report has been Red Squaded.
[09:47] <lifeless> s/to add/to get losas to add/
[09:47] <bigjools> lifeless: I'd do a new one
[09:48] <bigjools> lifeless: but failing that, 48109
[09:50] <lifeless> new one done
[09:55] <lifeless> allenap: hi; why ez-setup ?
[09:55] <lifeless> allenap: oh, I see - why don't we put that in the shared LP download cache ?
[09:55] <allenap> lifeless: Otherwise it tries to get it from the network.
[09:56] <allenap> lifeless: D'oh, ignore that.
[09:57] <allenap> lifeless: I assume you're talking about txlongpoll? I recently added ez_setup to Storm too.
[09:57] <lifeless> yes
[09:58] <allenap> lifeless: For txlongpoll I want it to be standalone, and not depend on the LP download cache. It's meant for Landscape to use too, though I have no idea if they have plans to do so.
[09:59] <lifeless> allenap: mmm sure
[09:59] <lifeless> allenap: these things are not actually related.
[09:59] <lifeless> allenap: e.g. LP deployment target can assume someone has done bzr checkout ... deployment cache
[09:59] <lifeless> allenap: without compromising use of bootstrap + any other deployment cache.
[10:01] <lifeless> allenap: separately, how would you feel about us dropping zope.testrunner from it (or at least making subunit.run a supported target, so I can use testrepository :))
[10:01] <allenap> lifeless: So I should put ez_setup.py into download-cache/dist then refer to it there in Makefile.
[10:01] <lifeless> allenap: I think it would avoid some duplication
[10:01] <allenap> lifeless: Very happy about that.
[10:03] <allenap> lifeless: I think moving ez_setup.py will make it harder for non-LP folk to use txlongpoll, but perhaps bootstrap.pt DTRT.
[10:03] <allenap> lifeless: Also, Launchpad itself has ez_setup.py in it.
[10:03] <allenap> But I guess that's a candidate for moving to the cache.
[10:03] <lifeless> allenap: python ./bootstrap.py will download from the internet; only we care about that :)
[10:03] <lifeless> allenap: (and other folk that can reasonably use the lp download cache, like landscape)
[10:04] <lifeless> allenap: (or setup their own)
[10:04] <lifeless> allenap: its only a thought
[10:04] <allenap> lifeless: I don't see that it buys much.
[10:05] <lifeless> allenap: I fear and loath ez_setup; having it in one place would reduce the amount of evil in the world
[10:05] <lifeless> allenap: also I don't want to have to add it to oops, oops-amqp, oops-wsgi, oops-twisted, oops-datedir2amqp, oops-tools, ...
[10:05] <lifeless> allenap: (I'm being selfish :P)
[10:06] <lifeless> bigjools: rt 48999 if you didn't get a CC from rt
[10:06] <bigjools> got it
[10:09] <lifeless> allenap: the README claims manual egg location is needed, but it Just Worked for me; are the docs old, or does the LP downloadcache make things easier ?
[10:10] <allenap> lifeless: Hehe, okay.
[10:10]  * allenap reads the README
[10:10] <jtv> We're getting silly warnings from the packaging_translations job that it's skipping translations for Lenny.  Anyone mind if I downgrade that to "info"?
[10:11] <jtv> bigjools: (I know I said there was no time for me to get into a new item today, but there was only 1 bug to triage :)
[10:11] <allenap> lifeless: Ah, yes, the README is slightly wrong, and it should Just Work with the LP download-cache.
[10:11] <allenap> It should read tarball instead of egg.
[10:13] <lifeless> allenap: in the options in the twisted plugin
[10:13] <lifeless> allenap: how do you not do a short option - pass None instead of "o" ?
[10:15] <allenap> lifeless: You mean you want a null OOPS prefix? Sorry if I'm being stupider than usual today, I had a rough night :)
[10:17] <lifeless> I'm adding amqp oops support to txlongpoll
[10:17] <lifeless> which is a bit fugly because its not a twisted publisher, but nevermind that :)
[10:18] <lifeless> I am running out of single letters that are not used by twistd
[10:18] <lifeless> e.g. -e is encrypted
[10:22] <allenap> lifeless: Yes, None seems to do the trick.
[10:22] <lifeless> coolio
[10:22] <lifeless> uhm
[10:22] <lifeless> Will need your advice on whether to test this or not in ~ 5 minutes
[10:22] <lifeless> also hope you have a better day than night
[10:33] <allenap> Thanks :)
[10:42] <lifeless> allenap: https://code.launchpad.net/~lifeless/txlongpoll/oops-amqp/
[10:43] <lifeless> allenap: I have no idea whether this is sanely testable or not.
[10:43] <allenap> lifeless: Okay, looking.
[10:44] <lifeless> thanks!
[11:03] <lifeless> allenap: I'm going to halt()
[11:03] <lifeless> allenap: that branch should work as-is, I'm sure you can play with it more to see ;)
[11:05] <allenap> lifeless: Okay. There are a couple of syntax errors in there. I'm inclined to say that all it needs is something to verify that publishers are set up correctly after calling setUpOopsHandler.
[11:05] <lifeless> ah there are aren't there
[11:05] <lifeless> interesting that the plugin isn't tested at all then :)
[11:06] <lifeless> allenap: perhaps we should move all this code out of the plugin, make it testable, and just import it from the plugin to activate it
[11:06] <allenap> lifeless: Yeah, agreed.
[11:07] <lifeless> allenap: would you have the bandwidth to run with this ? I wanted to solve the bits that had changed while you guys were building stuff
[11:07] <allenap> lifeless: Yeah, I guess so. I'll need to run it by bigjools.
[11:08] <lifeless> if you can, great. if you can't, thats ok too.
[11:08] <bigjools> you rang
[11:08] <lifeless> bigjools: I put amqp support for oopses in a branch of txlongpoll
[11:08] <bigjools> cool
[11:08] <lifeless> bigjools: this, by virtue of syntax errors uncovered txlongpoll's twistd plugin being untested - entirely untested.
[11:08] <lifeless> bigjools: (because the test suite still passes)
[11:09] <bigjools> awesomery
[11:09] <lifeless> bigjools: I was asking allenap if he had the bandwidth to fix that (by moving its contents into the main module where its testable), incorporating my otherwise trivial branch as he goes.
[11:09] <lifeless> bigjools: he said possibly-but-ask-you
[11:09] <bigjools> I am ok with it as long as he is
[11:09] <lifeless> more-or-less
[11:09] <allenap> Yes, I'm good with it. Deal.
[11:10] <lifeless> sweet, thanks!
[11:16] <jtv> Who's up for a really easy review?  https://code.launchpad.net/~jtv/launchpad/bug-887063/+merge/81439
[11:18] <jelmer> jtv: it seems you're just changing from warning to warn?
[11:18] <jelmer> jtv: The proposed fix says you're changing to info
[11:19] <jtv> Oh God I got that wrong didn't I?  Thinko.
[11:19] <jtv> This is why we need reviews even on “trivial” changes.  :)
[11:20] <jelmer> :)
[11:20] <jtv> Fix is being pushed.
[11:20] <jtv> Done
[11:24] <jtv> jelmer: the diff has updated.  Note there's also a change to the imports; that's from the automatic imports-formatting script.
[11:24] <jtv> Unsurprisingly, tests, still pass.
[11:28] <jtv> Except for, very surprisingly, an unrelated test that breaks even on devel.  What is it _now_?
[11:29] <jtv> And I can't really investigate with my system needing unrelenting restarts.
[11:29] <jelmer> jtv: which test?
[11:29] <jtv> test_splits_and_merges
[11:30] <jelmer> jtv: r=me, if that failure isn't spurious I'm curious how your change breaks it..
[11:30] <jtv> It's not my change.  I get the failure even in devel.  :(
[11:31] <jtv> Argh!  No wait.  I applied the same change in devel.  Something's wrong with me today, clearly.
[11:31]  * jtv reverts & reruns
[11:32] <jtv> Reverting my change doesn't fix the breakage in devel.  WTF.
[11:32] <jtv> Probably a test isolation failure then, I'm guessing.
[11:33] <jtv> jelmer: are you getting a failure there?  ./bin/test -vvc lp.translations.tests.test_translationpackagingjob -t test_splits_and_merges
[11:39] <jtv> thanks jelmer — I'll file a separate bug for that breaking test, assuming my own branch gets through EC2.
[11:39] <jelmer> jtv:   Ran 1 tests with 0 failures and 0 errors in 3.503 seconds.
[11:39] <jtv> Oneiric?
[11:39] <jelmer> lucid
[11:40] <jtv> That may be it then.
[11:40] <jelmer> (I'm on precise but running a container with lucid)
[11:40] <jtv> Ah.
[11:40] <jtv> Call for Help: Could someone try this on oneiric?  ./bin/test -c lp.translations.tests.test_translationpackagingjob -t test_splits_and_merges
[11:44] <StevenK> jtv: Ran 1 tests with 0 failures and 0 errors in 1.609 seconds.
[11:44] <jtv> thanks StevenK
[11:45] <jtv> Oh, StevenK: what revision is that on?
[11:45] <StevenK> jtv: r14262
[11:45] <jtv> Hmm… on 14261.
[11:46] <jtv> Who knows—let's try.
[11:46] <jtv> Ah no wait, I've got a bus to get onto.  :(
[11:48] <jtv> nn folks!
[12:59] <benji> https://dev.launchpad.net/ | On call reviewer: benji | Critical bugtasks: 266
[12:59] <benji> heh
[13:51] <deryck> Morning, all.
[13:53] <jelmer> Arvo, Deryck
[14:00] <jml> jelmer: tee hee
[14:05] <jelmer> jml: hmm?
[14:05] <jml> jelmer: that's a very Australian way of wishing someone a good afternoon.
[14:06] <jelmer> ah, hmm
[14:06]  * jelmer wonders where he picked that up
[14:23] <allenap> benji: Fancy a Storm review? It already has a +1, but needs another. https://code.launchpad.net/~allenap/storm/django-disconnection-errors/+merge/80717
[14:23] <benji> allenap: my pleasure
[14:23] <allenap> Thanks!
[14:52] <benji> allenap: https://code.launchpad.net/~allenap/storm/django-disconnection-errors/+merge/80717 looks good
[14:52] <allenap> benji: Thanks.
[16:53] <bigjools> jelmer: still around?
[16:57] <jelmer> bigjools: jup
[16:57] <bigjools> jelmer: hurray! did you manage to QA r14243?
[16:58] <jelmer> bigjools: no :-( the code importer on qastaging is down and I couldn't find a losa earlier
[16:58] <jelmer> bigjools: I see mbarnett is around now, so I'll ask him
[16:58] <bigjools> jelmer: mbarnett is around
[16:58] <bigjools> jelmer: great, thanks!
[17:05] <abentley> benji: could you please review https://code.launchpad.net/~abentley/launchpad/yui-navigator/+merge/81470 ?  It's overlength, but that's just from indentation changes.
[17:08]  * mbarnett hides 
[17:25] <timrc> bigjools, are there any plans of releasing a 2.0 api for this LTS?
[17:28] <bigjools> timrc: I have not heard of any
[17:28] <bigjools> but we should look at it
[17:28] <timrc> bigjools, I don't think we have any pressing needing for it, devel suits us just fine, so it's more out of own personal curiosity ;)
[17:30] <timrc> er need... damn you -ing
[18:42] <benji> abentley: I was away for lunch when you asked, but I just finished your branch.
[18:42] <abentley> benji: thanks.
[18:42] <benji> my pleasure
[18:48] <abentley> benji: Updated per your suggestions.
[18:49] <benji> abentley: cool
[19:19] <lifeless> morning
[19:19] <timrc> howdy
[19:29] <m4n1sh> is there a command line tool where I can access bug info from LP
[19:29] <m4n1sh> and also initiate merge requests?
[19:37] <lifeless> there is a thing called hydrazine
[19:38] <lifeless> and bughugger
[19:38] <lifeless> and lp-tools
[19:44] <m4n1sh> thanks
[19:57] <m4n1sh> lifeless: not in archives?
[19:57] <m4n1sh> its in a PPA
[20:08] <lifeless> sinzui: do you have time for a catch up today ?
[20:08] <sinzui> I do.
[20:09] <sinzui> maybe in 30 minutes when I complete this review
[20:09] <lifeless> coolio
[20:19] <jelmer> lifeless: lp-tools is in the archive
[20:19] <jelmer> s/lifeless/m4n1sh/
[20:19] <m4n1sh> ahh. it is called lptools
[20:21] <jcsackett> hey, lifeless! i updated the MP you marked needing fixing. care for a second look? (https://code.launchpad.net/~jcsackett/launchpad/open-delegate-subscription-problems/+merge/81090)
[20:21] <lifeless> sure thing
[20:23] <lifeless> jcsackett: line 169 in the diff is very suspect
[20:25] <lifeless> jcsackett: thats the bit where you delete a Makefile and replace it with a symlink to somewhere on your hard disk.
[20:25] <jcsackett> lifeless: yeah, i just saw that.
[20:25] <jcsackett> lifeless: fixing that now, sorry for the time waste. :-p
[20:26] <lifeless> jcsackett: np, I've reviewed the rest :)
[20:26] <lifeless> jcsackett: I have one suggestion to avoid duplication further
[20:26] <jcsackett> lifeless: i'm all ears.
[20:26] <lifeless> jcsackett: which should be in your mailbox by now :)
[20:26] <lifeless> delegation!
[20:27] <jcsackett> lifeless: oh, i do like that. we are likely to be doing that check a fair bit.
[20:27] <jcsackett> consider it done, and thanks. :-)
[20:27] <lifeless> de nada
[20:34] <flacoste> lifeless: hi
[20:34] <flacoste> lifeless: available for our call?
[20:34] <flacoste> early this week
[20:35] <lifeless> I sure am
[20:35] <lifeless> sinzui: will in a little bit later be ok ?
[20:35] <lifeless> sinzui: if I talk to the boss first :)
[20:36] <lifeless> flacoste: skype ?
[20:37] <sinzui> lifeless, ping me when you are ready
[20:37] <flacoste> lifeless: yes, i'm trying a new headset, let's see how it goes
[20:37] <lifeless> sinzui: great, will do
[20:56] <bac> hi abentley, i'm getting an error from bzr lp-submit.  it's the first time i've tried it on a new oneiric machine.  are you familiar with any problems like: http://pastebin.ubuntu.com/731374/
[20:57] <abentley> bac: Sorry, I'm not familiar with that.  It looks like a password/launchpadlib issue.
[20:59] <maxb> dbus error talking to your gnome-keyring-daemon
[21:00] <maxb> Though quite what's broken such that g-k-d is not responding, I don't know
[21:22] <allenap> lifeless: lp:~allenap/txlongpoll/oops-amqp is what I did with your branch of the same name.
[21:23] <allenap> lifeless: It depends on lp:~allenap/txlongpoll/bootstrap-without-net, and some revisions have been mixed up a bit between those branches. I'll remedy that now.
[21:24] <allenap> lifeless: Actually, no, they're not mixed up, I was being paranoid.
[21:28] <lifeless> sinzui: ping
[21:28] <sinzui> hi lifeless
[21:28] <lifeless> allenap: sounds great, do you need anything from me ?
[21:28] <lifeless> sinzui: skype ?
[21:28]  * sinzui starts skype
[21:29] <thumper> flacoste: hi
[21:29] <flacoste> hi thumper
[21:29] <thumper> flacoste: busy?
[21:29] <allenap> lifeless: Nope, I'll get it reviewed tomorrow unless you want to +1 it at some point :)
[21:30] <lifeless> allenap: cool; I may, will see how the day pans out
[21:30] <flacoste> thumper: more or less, general post-UDS catchup
[21:30] <flacoste> thumper: what can i do for you?
[21:30] <thumper> flacoste: can I call you for some questions?
[21:30] <flacoste> sure, skype
[21:36] <allenap> lifeless: Thanks, have a good day :) Night all.
[22:08] <wallyworld___> sinzui: jcsackett: you guys around for the standup?
[22:08] <jcsackett> oh right, time changed.
[22:08]  * jcsackett gets on mumble
[22:09] <sinzui> wallyworld___, sorry, my call with lifeless got very interesting
[22:09] <wallyworld___> np :-)
[22:09] <wgrant> sinzui: That's worrying.
[22:19] <timrc> 266 critical bug tasks, I guess it may be time for a new "super critical" category :)?
[22:19] <thumper> HAHA
[22:19] <timrc> Thank you, thank you, I'll be here all night
[22:19] <wgrant> timrc: It's even better :)
[22:21] <timrc> ouch
[22:28] <wgrant> jcsackett: http://webnumbr.com/launchpad-critical-bugs
[22:31] <wgrant> https://lpstats.canonical.com/graphs/LPProjectCriticalFiled/20101108/20111108/
[22:34] <timrc> July was a good month for you
[22:38] <wallyworld___> sinzui: we are looking to finish the standup, we can talk again tomorrow?
[22:39] <sinzui> wallyworld___, thanks.
[22:39] <wallyworld___> np
[23:02] <allenap> wgrant: I have a couple of txlongpoll branches that need reviewing. Do you fancy taking a look? The only catch is that I'm going to bed in a minute so I won't be around to discuss things.
[23:03] <allenap> They are:
[23:03] <allenap> https://code.launchpad.net/~allenap/txlongpoll/bootstrap-without-net/+merge/81323
[23:03] <allenap> https://code.launchpad.net/~allenap/txlongpoll/oops-amqp/+merge/81504
[23:05] <wgrant> allenap: Sure, I'll do them today.
[23:05] <allenap> wgrant: Thank you :)
[23:05] <lifeless> timrc: ubuntu has more ;)
[23:06] <timrc> lifeless, ever have the urge to mark them all "Won't Fix" ;)?
[23:28] <lifeless> timrc: no, but the rest, yes
[23:59] <lifeless> allenap: http://pypi.python.org/pypi/python-subunit