[00:05] <lifeless> thumper: hoot
[00:05] <lifeless> thumper: *shoot*, or did you want voice? (can do that too)
[00:05] <thumper> you suggest using closures rather than functors
[00:05] <thumper> I'm not sure I get the subtleties
[00:05] <lifeless> mwhudson: I'll get someone else to review; need deeper restructuring to make the concept work
[00:06] <lifeless> thumper: oh, less code
[00:06] <thumper> lifeless: and here I was thinking you were hooting about my link in -ops
[00:06] <lifeless> uses more of the language facilities, which tends to feel more natural
[00:06] <lifeless> thumper: I linked that here last week :P
[00:06] <thumper> lifeless: can you give me an example
[00:06] <thumper> ah... ok
[00:06] <thumper> well it was new to me :)
[00:07] <mwhudson> lifeless: ok, thanks for letting me know
[00:07] <lifeless> so - a class with only __call__ is equivalent to a function
[00:07] <lifeless> mwhudson: (the symmetric vs asymmetric difference is biting here)
[00:07] <lifeless> mwhudson: e.g. product can be symmetric, branch.owner can't be, not for merge proposals
[00:07] <mwhudson> lifeless: oh right yes, duh
[00:08] <lifeless> mwhudson: kindof reflects some limits in the collections approach
[00:08] <lifeless> conceptually we might be better off with a merge proposals collection taking two branch collections as constraints, but then the constant folding will become *hard*
[00:09] <thumper> lifeless: I think I get your suggestion now...
[00:09] <lifeless> so, it makes me wonder more about whether ditching the layer would just be a net win.
[00:10] <lifeless> thumper: right - rather than implement N classes + factories, implement N functions, and for some of them use currying (or partial()) to capture whatever constraints you need
[00:10] <lifeless> wgrant: are you deploying us up ?
[00:11] <wgrant> lifeless: I shall.
[00:11] <lifeless> kk
[00:22]  * mwhudson gets ready to shuffle off
[00:55] <lifeless> http://pastebin.com/yVLXtDse
[00:57] <poolie> hi all
[01:04] <wgrant> spiv: The package importer was only changed to specify a reviewer three weeks ago, and that may have been deployed even more recently.
[01:05] <wgrant> lifeless: Actually, we can't really delete the code. Makes it impossible to test things without real DNS.
[01:05] <wgrant> Like, say, a development environment.
[01:05] <wgrant> Although I guess we could.
[01:06] <spiv> wgrant: well, the other curious part is it appears to only or at least mainly affect imports that had been affected by bug 726584, which was a bzr issue
[01:07] <_mup_> Bug #726584: flash-kernel import fails apparently mismatching maverick and natty branches <hpss> <udd> <Bazaar:Fix Released by spiv> <Ubuntu Distributed Development:New> < https://launchpad.net/bugs/726584 >
[01:07] <spiv> wgrant: but perhaps it's just more likely to trigger that situation with relatively stale imports
[01:07] <wgrant> spiv: It only creates MPs when there is a conflict.
[01:07] <wgrant> And it will affect all of them.
[01:07] <wgrant> The API usage is wrong.
[01:08] <spiv> What do you mean by "all of them"?  I don't see the number of import failures rising, so I presume most of them have been passing.
[01:09] <wgrant> spiv: It will affect anything with an import conflict.
[01:11] <lifeless> wgrant: how so? we can inject stuff into the client
[01:11] <lifeless> wgrant: and/or select the specific names we need a priori
[01:12] <wgrant> lifeless: I guess.
[01:33] <lifeless> can has review? https://code.launchpad.net/~lifeless/launchpad/bug-736008/+merge/55028
[01:45] <poolie> is it just my flakey network or is lp refusing ssh connections?
[01:45] <lifeless> poolie: works for me
[01:45] <lifeless> (just tested)
[01:46] <poolie> thanks
[01:46] <lifeless> spm: he's noticed, you can take the special case for poolie out now
[01:47] <spm> hmm?
[01:47] <spm> oh. right. yes. will do.
[01:48] <lifeless> StevenK: https://code.launchpad.net/~lifeless/launchpad/bug-736008/+merge/55028
[01:48] <lifeless> StevenK: I know you are around :)
[01:49]  * StevenK grumbles at lifeless
[01:54] <StevenK> lifeless: I note you're adding two methods getCandidateBranchesWith(). There is a little bit of duplicated code there, are you able to up-call from the more explicit one to the anonymous one?
[01:55] <lifeless> StevenK: no
[01:55] <lifeless> StevenK: anonymous(generic)  and visible(generic)
[01:55] <lifeless> the generic class does no filtering by user; the anonoymous one filters as though an anonymous user, the visible as though a user is logged in
[01:56] <lifeless> I think it should be refactored away from subclassing and into a strategy helper.
[01:59] <lifeless> nice 477 Time Outs
[02:00] <StevenK> lifeless: Sounds good, do that.
[02:00] <StevenK> :-P
[02:00] <StevenK> lifeless: If you want the refactoring to be done in another iteration, I'm happy enough to say r=me
[02:00] <lifeless> StevenK: I think it should be done, I have no plans to do it.
[02:01] <StevenK> lifeless: Okay, then I'd suggest you add an XXX to that effect.
[02:01] <lifeless> StevenK: I don't think thats useful to do:
[02:01] <lifeless>  - such XXX become stale all the time
[02:01] <lifeless>  - its not a 'bug'
[02:01] <lifeless>  - the refactoring might be wrong, until someone tries, who knows
[02:02] <StevenK> lifeless: I might just be overly grumpy, but you asked for a review, not an argument.
[02:03] <lifeless> StevenK: yes, and I appreciate that - you've mentioned two things; one that the *current code structure* isn't optimal and two that I record *one approach* to fixing it in the code base.
[02:03] <lifeless> for the former, I'm agreeing with you vigorously, but the thing I'm trying to achieve is orthogonal to the current code structure
[02:03] <StevenK> Then I withdraw my objection, r=me
[02:03] <lifeless> for the latter, I'm saying that encoding a guess about what might be better in the code base isn't a useful thing to do
[02:05] <lifeless> StevenK: thanks!
[02:06] <lifeless> StevenK: http://bazaar.launchpad.net/~lifeless/storm/with/revision/387 - is the change to storm I'm bundling
[02:07] <StevenK> I think I've read that before
[02:07] <lifeless> yeah, i pastebinned it, when it was in-tree in lp
[02:16] <huwshimi> Is it just me or do other people find that a lot of AJAX requests hang in Launchpad? Probably 60% of the time I do something it doesn't work and I have to refresh and do it again.
[02:17] <wgrant> huwshimi: I've not seen that.
[02:17] <huwshimi> wgrant: Really?
[02:17] <huwshimi> wgrant: What browser are you using?
[02:17] <wgrant> huwshimi: Chromium 11, mostly.
[02:18] <huwshimi> wgrant: Ah right. I thought it might be a chrome thing, but I guess not
[02:18] <huwshimi> It
[02:18] <huwshimi> It's really annoying
[02:18] <wgrant> huwshimi: Bug task actions?
[02:19] <huwshimi> wgrant: Yeah
[02:20] <wgrant> Er.
[02:20] <wgrant> Is something wrong with OOPS reporting?
[02:20] <wgrant> Our top two OOPSes have disappeared.
[02:20] <wgrant> Maybe the broken remote branch is fixed, and the package importer has unbroken...
[02:20] <wgrant> But hmm.
[02:21] <spiv> wgrant: the package importer has stopped retrying that failure
[02:21] <wgrant> spiv: Ah.
[02:21] <spiv> http://package-import.ubuntu.com/status/: “51 packages failed to many times to retry with key lazr.restfulclient.errors.HTTPError”
[02:22] <spiv> I can kick it over and over today if you'd like lots more OOPSes :)
[02:23] <wgrant> Yeah, the 717 critical OOPSes is a bit low. The extra 1400 will do us some good :)
[02:26] <lifeless> huwshimi: possibly you're hitting lots of timeouts + the poor reporting we have of those class of errors
[02:27] <wgrant>         1 /    2  BugTask:EntryResource
[02:27] <wgrant> Not likely.
[02:41] <poolie> is it just me or are there no longer tick/cross buttons when editing mp descriptions?
[02:41] <poolie> nm, just me, they probably failed to load
[02:49] <lifeless> huwshimi: I guess you need to track the requests and see what happens
[02:50] <huwshimi> lifeless: Yeah next time it happens I'll take more notice :)
[02:54] <lifeless> wow
[02:54] <lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=1912O253#statementlog is special
[02:55] <wgrant> I was looking at that before.
[02:55] <lifeless> https://bugs.launchpad.net/launchpad/+bug/743970
[02:55] <_mup_> Bug #743970: ProductSet:+all timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/743970 >
[02:55] <wgrant> I don't understand what it's trying to do.
[02:56] <wgrant> There were some pretty slow queries for what should be a fairly trivial operation.
[02:56] <lifeless> so the first clause is 'direct teams for person X with membership status 3'
[02:57] <lifeless> the second clause is 'all active team memberships
[02:57] <lifeless> the first clause can probably be radically simplified
[02:57] <wgrant> Well, I didn't look at the queries in depth. I mostly just scanned the log and saw some 800ms queries that didn't make sense for listing products.
[02:57] <wgrant> So I decided that I might come back to it later.
[03:07] <huwshimi> My apologies to whoever is getting notifications for all the bug changes I'm making today.
[03:07] <wgrant> How dare you try to fix our UI.
[03:11] <lifeless> huwshimi: I'm not sure easy-ui is a sensible tag though :(
[03:13] <lifeless> huwshimi: if you see js error bugs - per the list thread - they should be criticaled
[03:13] <huwshimi> lifeless: sure.
[03:14] <huwshimi> lifeless: It is a bit of a misnomer, but I couldn't think of a better one
[03:14] <lifeless> huwshimi: what is the intent you want to convey?
[03:15] <lifeless> wallyworld: hey, web_service_request_to_notification_request - seems to be entirely redundant. Can't you just use the INotificationRequest directly ?
[03:15] <wallyworld> lifeless: probably. i'm a bit clueless when it comes to zope and adaptors
[03:16] <wallyworld> i'll give it a go
[03:16] <huwshimi> lifeless: They should be fairly straight-forward, only take a few hours and not really require much discussion. The sort of thing that can be just picked up and done.
[03:17] <lifeless> huwshimi: I suggest tagging them easy, ui
[03:17] <lifeless> huwshimi: a search for easy & ui will bring them back trivially
[03:19] <huwshimi> lifeless: The problem with that is that implies that they are actually easy. I think I need to pick another word instead of that
[03:19] <lifeless> huwshimi: shallow trivial simple tech-debt friction polish
[03:20] <wallyworld> lifeless: i can't use your suggestion because INotificationRequest is lp specific and the implementation code is in lazr restful
[03:20] <lifeless> wallyworld: you have an adapter registration with a factory line
[03:20] <lifeless> wallyworld: in the one merge proposal
[03:21] <lifeless> wallyworld: why can't you put the factory as ....INotificationRequest
[03:22] <wallyworld> lifeless:  ah. i think i understand now. you mean "factory=canonical.launcpad.webapp.interfaces.INotificationRequest"
[03:22] <wallyworld> ?
[03:24] <lifeless> wallyworld: that seems like a trivial inlining
[03:24] <lifeless> wallyworld: yes
[03:24] <lifeless> wallyworld: def foo(bar): return quux(bar)    is equivalent to foo=quux, after all
[03:24] <lifeless> you may be able to do better, but I was just pointing out the direct simplification I thought I saw
[03:25] <lifeless> lib/lp/registry/browser/product.py makes baby jebus sad
[03:25] <wallyworld> lifeless: thanks. i'll make the zcml change
[03:26] <lifeless> wgrant: check line 1014
[03:26] <lifeless> wgrant: and ask yourself, why would this show up in projects/+all
[03:27] <wgrant> lifeless: It surely is not invoking ProductView for every project.
[03:28] <lifeless> wgrant: :) :) :) :)
[03:29] <lifeless> configure.zcml 1434
[03:31] <lifeless> +listing-detailed is the culprit
[03:32] <wgrant> Yay
[03:41] <wgrant> Hmm.
[03:41] <wgrant> Damn.
[03:41] <wgrant> I had merged MixedFileAliasView into LibraryFileAliasView.
[03:41] <wgrant> But that's not safe.
[03:43] <wgrant> Because we may leak restricted LFAs in various places, which is safe at the moment because the code needs to explicitly ask for the token view.
[03:44] <lifeless> yeah
[03:45] <lifeless> btw
[03:45] <lifeless> I *thought* I saw lp asking for appserver verification of public bug attachments or something the other day
[03:45] <lifeless> that could be streamlined
[03:45] <wgrant> Right, ProxiedLibraryFileAlias always goes to the appserver first.
[03:46] <lifeless> for public files, we should bypass that
[03:46] <wgrant> What if they become private?
[03:46] <lifeless> will make branding load faster
[03:46] <lifeless> wgrant: they they will get a 404
[03:46] <wgrant> What? Branding doesn't go through ProxiedLibraryFileAlias.
[03:46] <lifeless> wgrant: mmm, perhaps, I could swear it was
[03:46] <lifeless> anyhow, there are two classes of links
[03:46] <lifeless> current and persistent
[03:47] <lifeless> for bug mail using the appserver redirect is appropriate
[03:47] <wgrant> Right.
[03:47] <lifeless> for web pages rendered, its very unlikely that the bug will go private before the user clicks - and if it does, shrug.
[03:47] <lifeless> the race exists regardless because we don't hand out tokens for public files
[03:48] <lifeless> the bug might go private between asking for the real url and actually requesting the content from the librarian
[03:49] <lifeless> wgrant: different thing than what you're doing
[03:49] <wgrant> I know.
[03:49] <lifeless> wgrant: I only mention it so you can bear it in mind in any refactoring you do.
[03:51] <thumper> wallyworld: you realise that Javascript doesn't have method overloading?
[03:52] <wallyworld> thumper: :-( i thought it did
[03:52] <thumper> wallyworld: nope, it is more like python
[03:52] <wallyworld> thumper: you mean the recipe text xss branch?
[03:52] <thumper> yep
[03:53] <wallyworld> ok. will do a fix
[03:53] <thumper> wallyworld: just check for undefined
[03:54] <thumper> wallyworld: if someone calls a function with one param when it takes two, the second is undefine
[03:54]  * wallyworld nods
[03:54] <thumper> d
[03:54] <thumper> wallyworld: did you want a voice catchup?
[03:54] <wallyworld> thumper: ok.
[03:54]  * wallyworld plugs stuff in
[03:54] <thumper> wallyworld: with no leonardr now, we can do it at a more convenient time for you
[03:54] <wallyworld> team of 2
[03:55] <wallyworld> :-)
[03:55] <wallyworld> thumper: i can hear you
[03:55] <thumper> I no hear you
[03:56] <lifeless> and yay - prejoining fail again
[03:56] <wallyworld> thumper: not muted but no sound
[03:56]  * wallyworld restarts :-(
[03:56] <thumper> mic plugged in?
[03:56] <wallyworld> thumper: yes!
[04:02] <thumper> wallyworld: time to try something different?
[04:03] <thumper> wallyworld: mumble doesn't seem to be working for you, how about skype?
[04:04] <wallyworld> thumper: just testing with skype now and it works fine
[04:08] <lifeless> anyone know why cve:+index has edit widgets for the bug tasks?
[04:09] <lifeless> can has review? https://code.launchpad.net/~lifeless/launchpad/bug-743970/+merge/55033
[04:13] <lifeless> StevenK: ^ its tiny, if you feel like it.
[04:13]  * lifeless will bbiab
[04:42] <lifeless> StevenK: thanks!
[04:43] <StevenK> wgrant: I think I've come up with a tiny fix for python-debian's permissiveness
[04:45] <wgrant> StevenK: Oh?
[04:45] <StevenK> wgrant: http://pastebin.ubuntu.com/586329/
[04:46] <wgrant> StevenK: Looks reasonable.
[05:08] <lifeless> ok, why can't I ssh to ec2...
[05:15] <StevenK> wgrant: Bleh, it isn't quite that simple. :-(
[05:15] <StevenK> lifeless: What does ssh -v say?
[05:17] <lifeless> debug1: Connecting to ec2-75-101-221-93.compute-1.amazonaws.com [<IP_ADDRESS>] port 22.
[05:18] <StevenK> I don't think your instance is up
[05:18] <lifeless> Instance i-c201daad starting.......................................... started on ec2-75-101-221-93.compute-1.amazonaws.com
[05:18] <lifeless> Started in 3 minutes 37 seconds
[05:18] <StevenK> I think the default security group allows ICMP
[05:20] <lifeless> couldn't ping it either, and it should be in the ec2test group
[05:20] <StevenK> lifeless: Do you have ElasticFox?
[05:20] <StevenK> That should allow you to see what Amazon thinks about this
[05:21] <spiv> StevenK: "ka-ching", I expect
[05:21] <StevenK> spiv: Two drums and a cymbal fall off a cliff
[05:22] <huwshimi> StevenK: I thought it was two elephants
[05:23] <StevenK> huwshimi: Not heard that one
[05:23] <StevenK> (Okay, that was bad)
[05:30] <lifeless> I think its a routing issu
[05:31] <lifeless> *issue*
[05:31] <lifeless> http://developer.amazonwebservices.com/connect/entry.jspa?externalID=609&categoryID=88 fails to connect too
[05:32] <StevenK> lifeless: Hm, works for me
[05:33] <lifeless> just came good, will see whats up
[05:35] <lifeless> in the mean time
[05:35] <lifeless> would someone like to ec2land https://code.launchpad.net/~lifeless/launchpad/bug-743970/+merge/55033 and https://code.launchpad.net/~lifeless/launchpad/bug-736008/+merge/55028 ?
[05:36] <lifeless> ulp, nevermind
[05:36] <lifeless> it really is happier now
[05:48] <wgrant> Can I tell a testbrowser not to follow redirects?
[05:50] <StevenK> wgrant: Sadly, it wasn't that simple. But http://pastebin.ubuntu.com/586340/ makes it work
[06:08] <StevenK> wgrant: So, do you think resolved DSDs should lose the diff?
[06:10] <wgrant> StevenK: I'm not sure.
[06:11] <StevenK> wgrant: I was going to get DSD.update() to lose them if the status is NEEDS_ATTENTION so they can be re-requested
[06:25] <StevenK> Has anyone seen http://pastebin.ubuntu.com/586348/ ? Or should I fix it?
[06:25] <wgrant> Didn't I see that in one of your branches/diffs last week?
[06:26] <StevenK> A diff
[06:27] <StevenK> I'm just surprised it's gone unfixed
[06:36] <wgrant> Could I convince someone to look at an oversized branch?
[06:36] <wgrant> 948 lines (+108/-606)
[06:36] <wgrant> https://code.launchpad.net/~wgrant/launchpad/delete-librarian-streaming/+merge/55039
[06:43] <StevenK> wgrant: r=me, with a niggle
[06:44] <StevenK> https://code.launchpad.net/~stevenk/launchpad/apihelpers-imports/+merge/55040
[06:44] <wgrant> StevenK: Bah, yes, people fail at sorting imports.
[06:45] <StevenK> Haha
[06:46] <wgrant> The test fallout from this could be *amusing*.
[06:46] <StevenK> Oh, NFS, DIALCF.
[06:46] <wgrant> What's it doing?
[06:47] <wgrant> It can't be as flaky as nfsv4+krb5.
[06:47] <StevenK> % ls -lh /media | tail -n 1
[06:47] <StevenK> d????????? ? ?      ?         ?                ? media
[06:47] <wgrant> Well then.
[06:48] <StevenK> I finally managed to find an operation that actually told me what was going on, which was Stale NFS file handle
[06:49] <StevenK> Except now the client thinks it's mounted, but the server and client are playing no-speakies. Awesome.
[06:51] <StevenK> % sudo start portmap
[06:51] <StevenK> start: Job failed to start
[06:51] <StevenK> Could I have a clue, Upstart? Please?
[06:57] <lifeless> StevenK: they cost more
[06:57] <StevenK> lifeless: Hmph.
[06:57] <StevenK> lifeless: Can haz review?
[07:10] <lifeless> sure
[07:11] <StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/apihelpers-imports/+merge/55040 if you missed it
[07:15] <henninge> Good morning!
[07:20] <wgrant> Morning henninge.
[07:23] <henninge> Hi wgrant! ;)
[07:23] <StevenK> henninge: Hai!
[07:23] <henninge> And hello StevenK! :)
[07:24] <StevenK> henninge: You guys switched to daylight savings on the weekend?
[07:24] <henninge> Yes we did.
[07:24] <StevenK> Means we probably lose ours in about a week.
[07:26] <henninge> oh
[07:32] <stub> This should be fun - I've got a branch that consistently fails with KeyboardInterrupt
[07:32] <StevenK> stub: Stop bashing Ctrl-C during the test, then? :-P
[07:33] <stub> StevenK: The keyboard is in another continent ;)
[07:33]  * wgrant stabs germanium.
[07:33] <wgrant> Stop being so slow.
[07:38]  * wgrant stabs mizuho too.
[07:40] <StevenK> wgrant: Same reason, or a different one?
[07:41] <wgrant> StevenK: Same one.
[07:41] <StevenK> germanium has an excuse, I didn't think mizuho did.
[07:42] <wgrant> Maybe the DC just hates me.
[07:42] <wgrant> I can't get more than 100KB/s from mizuho.
[07:42] <wgrant> (substantially less from germanium. and request latency is terribly)
[07:44] <StevenK> What's your path to the DC?
[07:45] <wgrant> Optus->L3(US)->Canonical
[07:46]  * spm leaves the "throttle wgrant" block in place for another day
[07:46] <wgrant> :(
[07:46] <spm> wgrant: have you done any sniffs locally and seen the effect on a Time Sequence graph?
[07:47] <wgrant> A hwhat?
[07:47] <spm> woooo!  :-P
[07:51] <spm> heh, I was actually looking for the windows version... /blush
[07:51] <StevenK> Hah, fail
[07:54] <spm> wgrant: so the trick you're looking for - is your tcp window saturated; or are you getting lots of normal flow then big gaps; multiple acks can be bad; etc. it depends.
[07:56] <spm> also, getting a similar view off a different spot can be helpful. I've used my VPS in the USA to debug server woes in Oz, completely different network path and that can eliminate some imponderables.
[07:56] <wgrant> From my US VPS it's fine.
[07:56] <spm> I'd blame your ISP then. ;-)
[07:57] <StevenK> wgrant: Oh, you also have a Linode?
[07:57] <wgrant> I guess I don't grab much other big stuff from Europe.
[07:57] <wgrant> StevenK: Of course!
[07:57] <StevenK> wgrant: Fremont?
[07:57] <wgrant> Indeed.
[07:57] <StevenK> wgrant: Win
[07:57]  * StevenK looks up his host
[07:58] <StevenK> fremont35
[07:58] <wgrant> I seem to be on fremontreallyslowio
[07:58] <StevenK> Haha
[07:59] <wgrant> aka fremont87
[07:59] <StevenK> Haha
[08:00] <StevenK> wgrant: If it's a problem, open a ticket
[08:00] <wgrant> It's not really an issue at the moment.
[08:01] <StevenK> lifeless: SIGH! I've not been able to self-review before, but thanks.
[08:01] <StevenK> lifeless: Should have realised
[08:03] <wgrant> Huh, it looks like -backports is going to be usable in natty.
[08:11] <jkakar> thumper: Still there?
[08:12] <nigelb> Would a server editiion Ubuntu be alright for lp install?
[08:12] <StevenK> henninge: I have one for you -- https://code.launchpad.net/~stevenk/launchpad/dsd-lose-diffs/+merge/55059
[08:12] <wgrant> nigelb: No, it only runs on Windows Server.
[08:12] <stub> bzrlib.errors.InvalidHttpResponse: Invalid http response for https://code.launchpad.net/~stub/launchpad/trivial/%2Bmerge/54692/.bzr/branch-format: Unable to handle http code 405: expected 200 or 404 for full response.
[08:12] <nigelb> wgrant: Har har
[08:13] <wgrant> stub: bazaar.launchpad.net, not code.launchpad.net?
[08:13] <stub> wgrant: This is from ec2 land
[08:13] <nigelb> wgrant: I didn't want to kill my processor with a full install
[08:13] <stub> Gah... pebkac
[08:13] <huwshimi> rvba: Morning
[08:13] <rvba> huwshimi: morning
[08:14] <huwshimi> rvba: I have some icons for you
[08:14] <huwshimi> rvba: Well if they're ok
[08:14] <rvba> huwshimi: nice!
[08:14] <StevenK> henninge: I have one for you -- https://code.launchpad.net/~stevenk/launchpad/dsd-lose-diffs/+merge/55059
[08:15] <nigelb> wgrant: In revenge, I'll pick your brains, when I finish the installation.
[08:16] <henninge> StevenK: looking
[08:16] <wgrant> nigelb: Sounds like a good idea.
[08:16] <StevenK> nigelb: Feel free to ask anyone, rather than just picking on wgrant?
[08:17] <wgrant> That could work too.
[08:18] <nigelb> StevenK: Sure :)
[08:20] <henninge> StevenK: Shouldn't you also test for parent_package_diff being None?
[08:21] <StevenK> henninge: I can, if you wish
[08:22] <StevenK> henninge: http://pastebin.ubuntu.com/586364/
[08:22] <henninge> StevenK: Looks good. Why did you chagne to Equal?
[08:23] <StevenK> henninge: Because it was bugging me before I asked for the review
[08:23] <henninge> StevenK: but why only on the second assert?
[08:24] <StevenK> henninge: Because that one was assertTrue(... is None) which is effectively Equal. The former is assertFalse(... is None)
[08:24] <wgrant> StevenK: assertIs(None, foo)
[08:24] <wgrant> Not assertEquals.
[08:24] <StevenK> Fixed
[08:25] <henninge> Yes, that's what I would have expected.
[08:25] <wgrant> And assertIsNot
[08:25] <StevenK> henninge, wgrant: http://pastebin.ubuntu.com/586365/
[08:26] <henninge> StevenK: r=me
[08:26] <StevenK> henninge: Thanks!
[08:26] <henninge> thanks wgrant ;)
[08:40] <StevenK> jelmer: Ping!
[08:41] <jelmer> StevenK: goooood morning
[08:41] <StevenK> jelmer: Hai!
[08:41] <adeuring> good morning
[08:41] <henninge> Moin adeuring!
[08:41] <adeuring> hi henninge
[08:41] <StevenK> jelmer: Did you know the Version class in debian.changelog isn't strict enough?
[08:42] <jelmer> hi henninge, adeuring
[08:42] <jelmer> StevenK: No, I didn't. In what regard is it not strict enough?
[08:42] <henninge> Hey jelmer ;)
[08:42] <adeuring> hi jelmer
[08:43] <StevenK> jelmer: The regex allows : in the upstream character class -- that is only allowed if the epoch is not None. I have a patch at http://pastebin.ubuntu.com/586340/
[08:45] <jelmer> StevenK: ah, nice catch
[08:46] <StevenK> jelmer: Okay, so you like my patch. :-) What's the next step?
[08:47] <jelmer> StevenK: a test would be nice, and sending it upstream
[08:48] <StevenK> jelmer: Just file a bug in the Debian BTS?
[08:49] <jelmer> StevenK: Yep; we should probably poke James or one of the other devs to have a look, my last patch was sent to the mailing list but hasn't seen much attention.
[08:49] <jelmer> (I'm not upstream)
[08:50] <StevenK> jelmer: Ah, I thought you were, sorry.
[08:50] <StevenK> jelmer: How do I run the test suite?
[08:51] <StevenK> Ah, there's even a Makefile
[08:51] <jelmer> StevenK: Yep, that's specific to Launchpad's friendly fork though
[08:52] <StevenK> It helped me check the test I wrote, so win
[09:09] <bigjools> morning all
[09:16] <wgrant> Morning bigjools.
[09:17] <LPCIBot> Project windmill build #110: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill/110/
[09:17] <wgrant> bigjools: Do you have an opinion on bug #740892?
[09:17] <_mup_> Bug #740892: Ownership of package sets doesn't get preserved when a new series gets initialized <Launchpad itself:Triaged> < https://launchpad.net/bugs/740892 >
[09:19] <bigjools> wgrant: I agree with your last bug comment.  Also, he's not stated exactly why changing the owner is a problem.
[09:19] <wgrant> bigjools: Because the DMB is given several of the packagesets.
[09:19] <wgrant> bigjools: So they can administer them without involving the TB for every single thing.
[09:19] <bigjools> ok
[09:20] <bigjools> is DMB anywhere on the distro data?
[09:20] <wgrant> No.
[09:20] <bigjools> hm
[09:20] <wgrant> The TB should be, but the DMB probably shouldn't be.
[09:20] <bigjools> in that case they need to set it manually
[09:20] <wgrant> Why?
[09:20] <bigjools> hmm actually
[09:21] <bigjools> we can preserve it for the same distro, change it for new distros
[09:21] <wgrant> That's what I was suggesting, yeah.
[09:21] <wgrant> I think that should work.
[09:21] <bigjools> cool
[09:22] <wgrant> bigjools: Also, archivepublisher's tests suck.
[09:23] <bigjools> wgrant: tell me something I don't know
[09:24] <wgrant> bigjools: I was changing Release file generation, and it looks like it's only slightly tested in soyuz-upload.txt and nowhere else.
[09:24] <wgrant> Sigh.
[09:24] <bigjools> blame celso :)
[09:25] <wgrant> Mmm. I think it's probably mostly just old, complex code. Other bits of LP were also pretty bad.
[12:02] <deryck> Morning, all.
[12:04] <henninge> Hi deryck!
[12:16] <mrevell> Hello everyone. Has anyone here tried working through the getting started guide for daily builds?
[12:16] <wallyworld> deryck: hi. you tried to run windmill tests with firefox 4? the Launchpaduser.ensure_login() method fails for me. "current_url = client.commands.execJS(code='windmill.testWin().location;')['result']['href']" fails
[12:16] <deryck> wallyworld: ah, no, I haven't tried it with 4 yet.
[12:17] <deryck> wallyworld: that sucks :(
[12:17] <wallyworld> deryck: yeah :-( i don't want to reinstall ff3
[12:17] <deryck> wallyworld: is the site actually broken in 4?  Or the test just fails?
[12:18] <wallyworld> deryck: the site/page loads but the javascript inside the call to ensure_login() fails
[12:18] <wallyworld> deryck:  client.commands.execJS(code='windmill.testWin().location;') returns a near empty dict
[12:19] <wallyworld> i mean the 'result' value is a near empty dict
[12:19] <deryck> wallyworld: ah.  hmmm, let me look more closely at this now....
[12:19] <wallyworld> hence there is no 'href' key and it barfs
[12:23] <wallyworld> deryck: thanks. i had a quick look at the windmill devs google group but nothing jumped out. if now is not convenient for you to look, that's fine. it's way past eod for me  and i was hoping to take a shortcut in asking you :-)
[12:25] <deryck> wallyworld: yeah, I don't know without looking.  Sorry.  I don't mind digging in the innards of the windmill js objects today.
[12:25] <deryck> wallyworld: it might also be better to see if we can get the url in an easier way.
[12:26] <wallyworld> deryck: np. i'll look tomorrow also. thanks
[12:28] <danilos> henninge, hi, I've got a very nice branch that requires your both reviewer and ui expertise :)
[12:28] <danilos> henninge, https://code.launchpad.net/~danilo/launchpad/bug-740640/+merge/55123
[12:28] <danilos> henninge, most of the UI visible in https://devpad.canonical.com/~danilo/screencasts/inline-validation-error.ogv
[12:29] <henninge> danilos: I am watching it right now ;)
[12:29] <henninge> cool
[12:29]  * henninge replays
[12:29] <danilos> heh :)
[12:29] <deryck> wallyworld: np!
[12:30] <danilos> henninge, fwiw, I am unsure about "select all" after re-focusing on the field with the problem
[12:32] <jml> wgrant: have to say again that I really appreciate you making the PQM step much faster. It makes a big difference to landing branches.
[12:33] <lifeless> jml: quick chat?
[12:34] <jml> lifeless: sure.
[12:35] <lifeless> skype? voip? mumble is still very crackly
[12:35] <wgrant> jml: Indeed. It is pretty nice.
[12:35] <danilos> henninge, and whoops, lint issue due to code I should have removed (an unneeded nested function definition)
[12:36] <henninge> danilos: np, just push it
[12:36] <danilos> henninge, done already :)
[12:36] <lifeless> jml: ^
[12:36] <henninge> danilos: wow, you're quick!
[12:37] <jml> lifeless: skype is trying to connect as we speak
[12:37] <lifeless> s/as we/so we can/ :P
[13:13] <LPCIBot> Yippie, build fixed!
[13:13] <LPCIBot> Project db-devel build #497: FIXED in 5 hr 16 min: https://lpci.wedontsleep.org/job/db-devel/497/
[13:14] <jam> I have a question about config overlays, anyone feel expert enough to help out?
[13:15] <jam> (basically, I'm trying to create a custom development config, without having to actually modify the source tree, so I can run LP in a VM)
[13:15] <jml> I'm getting 'cat: lib/canonical/launchpad/icing/yui/dom/dom-style-ie.js: No such file or directory' errors when running 'make schema' in db-devel
[13:16] <henninge> danilos: is the UI review for the whole dialog?
[13:16] <jam> jml: rm -rf lazr-js/build ; make ?
[13:16] <jam> I've had a lot of problems there
[13:16] <danilos> henninge, nope
[13:16] <jam> may not have anything to do with you
[13:16] <danilos> henninge, just the validation bits :)
[13:16] <henninge> ok
[13:16] <jam> but the build script seems to assume the targets must exist
[13:16] <jam> if the dir does
[13:17] <jam> jml: though that specifically sounds like somebody forgot to add a file
[13:17] <jml> jam: I'll run 'make clean', see what happens.
[13:21] <jkakar> Sometimes I think bug descriptions should be optional... so many of the bugs I file have a descriptive enough subject so I just end up writing 'Yep, we need this' as the description.
[13:23] <jam> jkakar: you must have really shallow bugs :)
[13:24] <jkakar> jam: Sometimes, yes... For example, I just filed one like 'Need a way to migrate foo's from the old schema to the new one'.
[13:24] <jkakar> jam: There isn't really anything more worth describing... I guess the issue is that I'm using bugs, in this and possibly the common case, to track work as opposed to for describing a problem with symptoms, workarounds, etc.
[13:25] <jam> you could still put context
[13:25] <jam> where it is useful
[13:25] <jam> etc
[13:25] <jam> but sure, I see your point
[13:26] <jkakar> jam: Yes, for sure.  It's important to provide context when, er, it's important.  I just find I end up filing a lot of bugs with 'Yep, we do' as the description... maybe I'm just being too lazy.  Hmm.
[13:27] <jam> jml: quick twisted question. If you call 'addCallbacks' on a deferred, it will trigger the call immediately if the data is already present, right?
[13:27] <jml> jam: yes.
[13:28] <jam> I'm trying to track through an lsprof, though twisted seems to destroy the call tracking
[13:28] <jam> but 50% of the time is in "addcallback" I figure that is just actually running the function
[13:28] <jml> jam: http://paste.ubuntu.com/586438/
[13:29] <jam> jml: sure. In this case I'm dealing with Launchpad xmlrpc stuff, which I don't think is actually deferred
[13:29] <jml> jam: tbh, I've never had to seriously profile Twisted code. #twisted will probably have someone who has.
[13:29] <jml> jam: it uses Deferred, at least on the client side
[13:30] <jam> jml: It is guaranteed to be exactly as synchronous as the passed-in  proxy.
[13:30] <jam> but since the trigger is happening under the callback, I'm pretty sure it is synchronous
[13:30] <jml> it's synchronous, but it uses Deferred
[13:31] <jam> jml: right. But I think the point of abstracting via Deferred is because they wanted to allow async (at least, avoid blocking)
[13:31] <jml> yeah.
[13:31] <jam> ATM, I'm thinking XMLRPC might be killing some of the codehosting perf
[13:31] <jam> given that the request is sync
[13:31] <jam> and is *blocking* everyone else at the same time
[13:31] <jml> the sftp server uses exactly the same code, but uses an async client
[13:31] <jml> hmm
[13:31] <jml> jam: I'd really doubt that
[13:32] <jml> jam: the XMLRPC takes place in the server for auth, and that uses an async xmlrpc client
[13:32] <jml> jam: then the spawned bzr processes use a sync client, and that wouldn't block anyone else.
[13:32] <jam> jml: well, running "initialize_on_transport_ex" on my VM is 30ms, under launchpad's implementation, it is 500ms, on Prod, we saw it ~3s
[13:32] <jam> jml: you're right about probably not blocking others
[13:33] <jam> so far, I've only been able to track it to the twisted layer. It also looks like handling exceptions is extra expensive
[13:33] <jam> because twisted opportunistically expands the current stack
[13:33] <jam> to give 'nice tracebacks'
[13:33] <jam> but --lsprof lies, too :)
[13:33] <bac> allenap: sorry i didn't get to your big branch on friday
[13:34] <jml> jam: interesting.
[13:35] <jam> https://bugs.launchpad.net/launchpad/+bug/740759
[13:35] <_mup_> Bug #740759: creating bzrdir on launchpad is slow (BzrDirFormat.initialize_ex_1.16) <codehosting-ssh> <hpss> <lp-code> <performance> <Launchpad itself:Triaged> < https://launchpad.net/bugs/740759 >
[13:35] <jam>  29 0 0.4081 0.2940 twisted.python.failure:416(__getstate__)
[13:35] <jam> out of ~0.6s for run_argv
[13:35] <jam> so 400+ms spent in failure.__getstate__
[13:36] <jam> again, lsprof sometimes lies, and makes things that are super fast in locals slow while traced
[13:36] <jam> jml: but 29 calls to __getstate__ generated 35k calls to safe_repr
[13:40] <jml> jam: that seems an unreasonably large number.
[13:41] <jam> jml: it walks self.frames, and calls safe_repr() across all objects it finds
[13:41] <jam> AFAICT
[13:41] <jam> so, walk the current stack
[13:41] <jam> and safe_repr every live object available
[13:41] <jml> jam: as an experiment, you could patch out cleanFailure to do nothing, and then see what affect that has on the run time.
[13:42] <jam> jml: something worth trying, I was going to try to just avoid exceptions-as-return-codes, but I'll start with your idea
[13:43] <jam> of course, the flip side is that it probably starts leaking references to other objects
[13:43] <jml> jam: well, yes.
[13:43] <jam> since it no longer indirects via safe_repr
[13:46] <jam> a lot better under lsprof, trying without
[13:53] <LPCIBot> Project windmill build #111: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill/111/
[13:53] <jam> jml: http://paste.ubuntu.com/586444/
[13:54] <jam> not 100% definitive, but averaging <300ms vs >450ms
[13:54] <jam> for just changing "cleanFailure: return"
[13:54] <jml> jam: yeah, interesting.
[13:59] <jml> jam: I'm not sure if we could tolerate the memory leak on production. On the one hand, the processes have a fairly short lifespan, on the other, bzr is already very memory hungry.
[13:59] <jam> jml: yeah, I'm not thinking that is a production change. But finding some way to avoid calling it at all would be worthy
[13:59] <jam> It seems like it is about "nice failure tracebacks"
[14:00] <jam> which is great, but costing us half our runtime isn't so nice
[14:00] <jml> jam: a version of Failure which didn't keep the traceback would be interesting and maybe even generally useful.
[14:01] <jam> jml: how would you inject it, though?
[14:01] <jam> (tell the Deferred it really wanted to use *this* class of failure)
[14:02] <jml> jam: you would have to monkey-patch.
[14:02] <jml> jam: i.e. it's not supported
[14:02] <jam> jml: yipee !
[14:02] <jml> jam: another option would be to have a flag on Failure like 'debug', except that it said "don't store tracebacks at all"
[14:11] <allenap> bac: No worries, it is oversize and I wasn't able to stay around.
[14:16] <abentley> adeuring: Have you made any further changes that I should merge?
[14:16] <adeuring> abentley: not yet
[14:16] <abentley> adeuring: cool.
[14:38] <danilos> henninge, hi, how's the review going? anything I can help clarify perhaps?
[14:43] <henninge> danilos: sorry for the delay, I got a bit distracted ...
[14:49] <danilos> henninge, no worries, as long as you don't give up on me :)
[14:58] <jam> jml: if I change Failure to not walk the stack frame and traceback frame, it drops all the way down to 30ms like I expected
[14:58] <jam> Twisted Failure is just *way* more expensive than Exception
[14:58] <jml> jam: :(
[14:59] <jam> jml: Failure starts by walking the traceback and stack frames and copying all global state
[14:59] <jam> well, the state leading to local
[14:59] <jam> but that is locals.copy() and globals.copy()
[15:00] <jml> jam: this sounds like something that ought to be raised on<EMAIL_ADDRESS>[15:20] <henninge> danilos: err, all those tests ...
[15:20] <henninge> danilos: they are quite repetitive, aren't they?
[15:20] <danilos> henninge, indeed they are, but I was lazy to factor them out more nicely :)
[15:21] <danilos> henninge, if you really insist, though,... :)
[15:21] <henninge> danilos: I think I do. :-P
[15:21] <danilos> henninge, oh well, that's the life of a developer... I mean sure thing! :)
[15:23] <henninge> danilos: also, this looks very likely to break:
[15:23] <henninge>  196	+            field_container.get('parentNode').get('parentNode').setStyles(
[15:23] <henninge> 197	+                {height: 'auto'});
[15:24] <danilos> henninge, well, what I actually need there is to trigger a recalculation of height (it is already set to 'auto'): any suggestions on that front?
[15:24] <jam> jml: so I was wrong it my measurements, it is only 183ms. So the big cost is cleanFailure but __init__ is a little expensive, too.
[15:24] <danilos> henninge, when I add a new element, it doesn't properly resize
[15:24] <henninge> that's bad :(
[15:25] <danilos> henninge, yeah, it is, and this was the only solution I could come up with
[15:25] <henninge> danilos: but my issue was more about finding the right element to apply the style to.
[15:25] <danilos> henninge, I know, but I am using the opportunity to pick your brain as well :)
[15:26] <danilos> henninge, anyway, how would you suggest to do it? actually get the ID for the element in question?
[15:26] <henninge> or the class, maybe?
[15:26] <henninge> you could have a clase "resizeme" or similar.
[15:27] <henninge> and you could simply apply the style to all of them (because there are two in the overlay).
[15:27] <henninge> It won't hurt where it is not needed.
[15:28] <danilos> henninge, I believe CSS selectors don't have a nice "find me a parent which has 'resizeme' class on it", which is why I didn't bother
[15:28] <danilos> henninge, as far as not hurting where it's not needed, so much is true with how it is already :)
[15:29] <henninge> danilos: I did not mean to search for a parent of the input by class but for a child of the overlay.
[15:29] <henninge> Y.all(overlay_id + ' class=sizeme')
[15:30] <henninge> I am not sure that selector is correct, though.
[15:30] <danilos> henninge, right, I don't like the implicit "it might be any 'resizeme' element in the overlay"
[15:30] <henninge> hence the "won't hurt" comment from me ... ;-)
[15:30] <danilos> henninge, well, it should be Y.all(overaly_id + ' .sizeme')
[15:30] <henninge> rightg
[15:30] <henninge> t
[15:30] <danilos> henninge, and hence my reply on that :)
[15:31] <henninge> just my suggestion
[15:31] <danilos> henninge, anyway, if you think that's better, I am fine
[15:31] <danilos> henninge, in general, I don't like any of the solutions too much, because it's basically a hack to work-around an observed problem
[15:32] <henninge> it's "possible side effects" vs. "fragility"
[15:32] <danilos> henninge, "pick one"? :)
[15:33] <danilos> henninge, anyway, sure, I'll go with your suggestion (or something along those lines)
[15:34] <henninge> cool
[15:37] <jam> jml: I was blocked from posting to twisted. Should I really subscribe for this?
[15:37] <jam> Or can I send you the email and you post it for me.
[15:44] <jam> I went ahead and subscribed
[15:46] <jml> jam: asking on #twisted, everyone seems to like the idea of a version of Failure that implemented the same API but minimally, perhaps based on whether debug is set.
[15:47] <jml> jam: filing a ticket & including benchmarks would help, or maybe commenting on http://twistedmatrix.com/trac/ticket/2466
[15:47] <jam> jml: of course, I think that requires an account as well :)
[15:47] <jml> jam: yes. technology is terrible.
[15:49] <jml> jam: oh right, just saw your email to twisted-python
[15:51] <danilos> benji, hi, henninge was already looking at https://code.launchpad.net/~danilo/launchpad/bug-740640/+merge/55123 (I noticed that you claimed it)
[15:51] <benji> danilos: ah, thanks for letting me know
[15:52] <henninge> benji: sorry, forgot to claim it.
[15:52] <benji> henninge: np, I've reassigned it
[15:52] <jml> jam: also, dropping our sftp support would let us re-write the lpserve thing without Deferreds
[15:54] <jml> jam: I'd be OK with that, I think.
[15:59] <henninge> danilos: what's this for? I don't see it appearing when I use the dialog.
[15:59] <henninge> > +        overlay.showError(
[15:59] <henninge> > +            'Value for ' + error_text + ' is invalid.');
[16:07] <danilos> henninge, when you try to save with the errors still present, it should show up at the bottom of the overlay
[16:07] <danilos> henninge, save == "submit checkbox"
[16:07] <henninge> duh
[16:07] <henninge> thanks ;)
[16:15] <henninge> danilos: code review done.
[16:21] <henninge> danilos: both reviews done, r=me
[16:36] <danilos> henninge, thanks
[16:38] <jml> sinzui: hi
[16:39] <sinzui> hi jml
[16:39] <jml> sinzui: we said we were going to have a call.
[16:39] <jml> sinzui: but I forgot. got time for a quick call now?
[16:39] <sinzui> yes. I am on mumble now
[16:39] <sinzui> I do
[17:29] <LPCIBot> Project windmill build #112: STILL FAILING in 1 hr 1 min: https://lpci.wedontsleep.org/job/windmill/112/
[18:00] <adeuring> abentley: I have new version of the branch with the "set branch links" for the translation sharing settings page
[18:00] <abentley> adeuring: Cool.
[18:01] <abentley> adeuring: by "new version", do you mean that it's a new branch, or just new revisions on the old one?
[18:01] <adeuring> abentley: a new version of the existing branch
[18:01] <adeuring> abentley: lp:~adeuring/launchpad/js-translation
[18:02] <adeuring> abentley: The links are now quite often hidden
[18:02] <adeuring> for anon users and non-privileged users
[18:02] <adeuring> and when no packagaing links exists
[18:02] <abentley> adeuring: I see.
[18:16] <abentley> adeuring: It looks like you don't need to import getMultiAdapter in browser/sourcepackage.py.
[18:17] <adeuring> abentley: gahh, right
[18:17] <abentley> adeuring: same for ILink.
[18:17] <adeuring> rigtt
[18:19] <abentley> adeuring: Also, I think you don't mean "If a product ls linked", but "If a product is linked" in edit_branch_link docstring.
[18:19] <adeuring> yes ;)
[18:22] <abentley> adeuring: could you please submit this branch for review, but not land it?  I'll land it as part of this work.
[18:22] <abentley> adeuring: actually, if you want to land it, that's fine, too.
[18:23] <adeuring> abentley: ok, I'll submit it.
[18:23] <abentley> adeuring: thanks.
[18:28] <abentley> deryck[lunch]: chat (when you're back) ?
[18:45] <jcsackett_> benji: can i request a review of https://code.launchpad.net/~jcsackett/launchpad/affects-before-bug-email/+merge/55184 ?
[18:45] <benji> jcsackett_: sure
[18:46] <jcsackett> benji: thanks!
[18:49] <benji> jcsackett: done
[18:49] <jcsackett> benji: my, but you're speedy. thanks again. :-)
[18:49] <benji> :)
[19:32] <deryck> abentley: have call with flacoste now, but can chat after that.
[19:33] <abentley> deryck: cool.
[19:36] <lifeless> moin
[19:36] <lifeless> gary_poster: hi
[19:37] <gary_poster> lifeless, hi.  thank you for email.  was very good.  I've been doing allhands review stuff today so have not gotten to that except for reading it.  I am going to review what I've done in light of what you said also
[19:37] <lifeless> gary_poster: kk
[20:07] <lifeless> statik: ping
[20:32] <deryck> hi abentley.  I can mumble now if you wants to.
[20:32] <abentley> deryck: cool.
[20:57] <lifeless> flacoste: yo
[20:57] <flacoste> hi lifeless
[20:57] <flacoste> skype time?
[20:57] <lifeless> yarp
[21:22] <nigelb> 3% rocketfuel
[21:22] <nigelb> I guess its a good idea to run it overnight
[21:51] <LPCIBot> Project windmill build #113: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill/113/
[22:01] <wallyworld> thumper: mumble?
[22:02] <thumper> wallyworld: aye
[22:11] <lifeless> deryck: http://people.canonical.com/~huwshimi/ajax_time_log.ogv
[22:23] <deryck> Later on everyone.
[23:13] <thumper> sinzui: still around?
[23:13] <sinzui> thumper: yes
[23:13] <thumper> mumble?
[23:40] <sinzui> thumper: https://bugs.launchpad.net/launchpad/+bug/417100
[23:40] <_mup_> Bug #417100: ajax picker for distro source packages needs to display better info <lp-registry> <packages> <search> <Launchpad itself:Triaged> < https://launchpad.net/bugs/417100 >
[23:41] <sinzui> thumper: bug 618366 and  bug 736014
[23:42] <_mup_> Bug #618366: Question:+huge-vocabulary is often slow (10% of requests) <lp-answers> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/618366 >
[23:42] <_mup_> Bug #736014: BugTask:+huge-vocabulary timeout <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/736014 >