[00:02] <sinzui> wallyworld: do you want to try mumble?
[00:04] <wallyworld> sinzui: now i have no mic. i got my sound working eventually (seems a recent kernel update killed it for others too). i ended up having to upgrade to natty. but now it won't recognise my mic anymore :-(
[00:04] <wallyworld> so i'm doing the phonon/pulse dance :-(
[00:05] <thumper> wallyworld: is your mumble working
[00:05] <wallyworld> thumper: ^^^^^^
[00:05] <thumper> i silent wallyworld is a good wallyworld
[00:05] <thumper> :)
[00:12] <wallyworld> sinzui: sorry, no work :-(
[00:14]  * wgrant deletes shipit.
[00:14] <wgrant> Yay, this even lets us delete a celebrity.
[00:27] <huwshimi> wgrant: As soon as I saw the announcement I knew you'd be happy :)
[00:29] <thumper>  how is it coffee time again already
[00:34] <wallyworld> thumper: at least you have a working coffee machine :-(
[00:34] <thumper> hahah
[00:39] <LPCIBot> Project windmill build #144: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill/144/
[00:59] <lifeless> gmb: did you find an OOPS for that bug 1 timeout ?
[00:59] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[00:59] <lifeless> gmb: I'd be happy to eyeball it and see if I can suggest a cause
[01:05] <lifeless> thumper: stacked branches
[01:05] <lifeless> thumper: I see the code is going well
[01:05] <thumper> lifeless: yup
[01:06] <lifeless> thumper: did I correctly read that private http branch access isn't supported?
[01:06] <thumper> lifeless: landing the branch id support now
[01:06] <thumper> yes
[01:06] <thumper> that is right
[01:06] <thumper> we don't support any private branches over http
[01:06] <lifeless> oh
[01:06] <lifeless> thats easy then
[01:06] <lifeless> I thought they worked in loggerhead
[01:06] <thumper> that's different
[01:06] <lifeless> well
[01:06] <lifeless> loggerhead backs onto http
[01:06] <thumper> it raises permission denied
[01:06] <lifeless> inside the dc
[01:06] <thumper> and loggerhead goes to https
[01:07] <wgrant> It uses internal by-ID HTTP, right?
[01:07] <thumper> lifeless: different rule
[01:07] <wgrant> Like, raw by-ID, not +branch-id
[01:07] <thumper> right
[01:07] <lifeless> wgrant: its mapped to that
[01:07] <lifeless> wgrant: I'm not sure how it handles stacked-on urls
[01:07] <lifeless> which is why I'm asking these questions
[01:08] <thumper> um...
[01:08] <thumper> it should be the same way
[01:08] <thumper> ...
[01:08]  * thumper thinks
[01:08] <thumper> I'll take a look
[01:08] <wgrant> It must translatePath, right?
[01:08] <lifeless> thumper: until we change the virtual policy file
[01:08] <lifeless> thumper: this isn't going to magically affect people
[01:08] <thumper> lifeless: yes, I'm not landing that pipe yet
[01:08] <lifeless> thumper: so I'd check it on qastaging or whatever
[01:08] <thumper> yep
[01:09] <lifeless> just worth noting 'private stacked branches should work in loggerhead still' :)
[01:09] <thumper> yes they should
[01:09] <lifeless> \o/
[01:09] <thumper> landing incremental support is good though
[01:09] <lifeless> totally
[01:09] <thumper> we can slam it on things like this
[01:14] <wallyworld_> thumper: i got my sound working again. if you are free at some stage, i'd like to mumble to discuss some code
[01:14] <thumper> wallyworld_: sure
[01:14] <thumper> now is fine
[01:14] <wallyworld_> ok
[01:26] <lifeless> aaaaaaaaaaaaaaaaaaaaaaaargh
[01:27] <lifeless> I just read '    def getBatches(self):' in lazr.batchnavigator
[01:35] <mwhudson> thumper/lifeless: loggerhead still uses that nasty transform_fallback_location hook i added to bzrlib i think
[01:43] <thumper> heh
[01:43] <thumper> mwhudson: ping
[01:43] <mwhudson> thumper: hello
[01:44] <thumper> mwhudson: I was going to ask you about how loggerhead talked
[01:48] <mwhudson> thumper: ah, i think i may have been lying above
[01:49]  * mwhudson tries to remember if he wrote this code
[01:51] <mwhudson> aaah right
[01:52] <mwhudson> thumper: basically, it uses translatePath under the hood, it actually accesses branches in a pretty similar way to how codehosting does now
[01:52] <thumper> right
[01:52] <thumper> it seems likely then that my change to the vfs to support +branch-id alias will work fine there too
[01:53] <lifeless> I wonder if we should look at openid support for bzr
[01:53] <lifeless>  / oauth
[01:53] <mwhudson> thumper: yes
[01:53] <thumper> \o/
[01:53] <poolie> rather than ssh keys?
[01:54] <poolie> http://productblog.37signals.com/products/2011/01/well-be-retiring-our-support-of-openid-on-may-1.html
[01:54] <mwhudson> thumper: it seems like loggerhead should survive almost any rearrangement of how virtual paths map to real ones, basically
[01:54] <mwhudson> (this is not true of the external http service)
[01:54] <thumper> I've tweaked the rewrite map code to work with the new alias
[01:54] <mwhudson> ah ok
[01:55] <poolie> seriously, lplib started silently sending me to staging in natty? :(
[01:55] <mwhudson> poolie: i realized the other week that what i wanted for openid to be useful was my browser to know to send me to my chosen OP whenever openid was offered as an option
[01:55] <lifeless> poolie: for https access to private branches
[01:56] <poolie> mwhudson, if it had been decently integrated into browsers it would have had a better chance
[01:56] <poolie> probably chicken/egg
[01:56] <lifeless> poolie: yeah, I saw that blog post
[01:56] <mwhudson> poolie: did anyone actually try that?  it sort of seems that the standard was at the wrong level for it to be feasible
[01:56] <lifeless> mwhudson: entirely wrong level
[01:57] <lifeless> mwhudson: I don't recall /any/ chatter on http-wg about it
[01:57] <poolie> well, exactly
[01:58] <wgrant> poolie: lplib has always defaulted to staging, AFAIK...
[01:58] <mwhudson> it works nicely enough, although with a bunch of unnecessary hair i guess, for canonical/ubuntu SSO
[01:58] <poolie> even if you specify a different root
[01:59] <poolie> i understand what it is; i'm filing a bug
[01:59] <poolie> adding new parameters to python methods other than at the end is not a good idea for api compatibility
[01:59] <wgrant> What's changed now?
[01:59] <wgrant> get_token_and_login?
[02:00] <lifeless> Distribution:+bugtarget-portlet-tags-content needs attention
[02:00] <wgrant> Yeah. It almost looks cold-cachey, but it's hard to say.
[02:01] <lifeless> wgrant: it probably just needs the countBugs aggregate function applied to it
[02:01] <lifeless> wgrant: I bet most of the queries are table scans
[02:01] <wgrant> lifeless: IIRC it's a single 10s query in a lot of cases.
[02:01] <wgrant> I looked at it a while ago.
[02:02] <lifeless> lets have a looksee
[02:02] <poolie> wgrant, https://bugs.launchpad.net/launchpadlib/+bug/752095
[02:02] <_mup_> Bug #752095: Launchpad constructor parameters changed incompatibly in natty <launchpadlib :New> < https://launchpad.net/bugs/752095 >
[02:02] <wgrant> Grar.
[02:03] <wgrant> "Organize your workflow with Launchpad.
[02:03] <wgrant> "
[02:03] <wgrant> From 37signals.com/accounts
[02:03] <lifeless> 1 5211.0 2
[02:03] <wgrant> Do people not Google these things :(
[02:03] <lifeless> wgrant: 2 x 5000ms queries
[02:03] <wgrant> poolie: Hm, is the constructor really a public API?
[02:03] <wgrant> poolie: I've never seen it recommended, I don't think.
[02:04] <lifeless> wgrant: also nonddy queries
[02:04] <lifeless> wgrant: totally identical
[02:04] <poolie> https://help.launchpad.net/API/launchpadlib recommends it
[02:04] <poolie> and, its name suggests it's public
[02:04] <lifeless> wgrant: and looking at every tag when in fact I think the portlet only shows official tags
[02:04] <poolie> for fks sake
[02:05] <poolie> how gratuituous, after all the pissing and moaning about compatibilyt
[02:05] <lifeless> wgrant: so, kill the duplicate call, constrain by the official tags, win.
[02:08] <wgrant> poolie: Bah :/
[02:11] <poolie> i know api stability is hard in python
[02:11] <poolie> this one is just a bit annoying because it doesn't just give a typeerror, it happily does nearly the right thing
[02:15] <lifeless> wgrant: ok, I've analyzed it up
[02:15] <lifeless> wgrant: we can make it a 300ms portlet
[02:15] <lifeless> https://bugs.launchpad.net/launchpad/+bug/736002
[02:15] <_mup_> Bug #736002: Distribution:+bugtarget-portlet-tags-content timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/736002 >
[02:29] <LPCIBot> Yippie, build fixed!
[02:29] <LPCIBot> Project windmill build #145: FIXED in 1 hr 2 min: https://lpci.wedontsleep.org/job/windmill/145/
[02:33] <wgrant> Hmmm.
[02:34] <wgrant> lifeless: I'm trying to QA the bugattachment LFC preloading thing.
[02:34] <lifeless> wgrant: e-pic fail ?
[02:34] <wgrant> The bug in question times out on qas, even without ?comments=all
[02:34] <wgrant> Looking at an OOPS, the query take 20ms.
[02:34] <lifeless> hit up ++profile++show
[02:34] <wgrant> But there is a 4s gap afterwards.
[02:34] <lifeless> wgrant: does it timeout on prod without ?comments=all
[02:35] <wgrant> lifeless: No, it only takes 5s.
[02:35] <wgrant> Erm.
[02:35] <wgrant> Got a 502 from qas when asking for a profile.
[02:36] <wgrant> Odd.
[02:37] <lifeless> wgrant: you've marked it ok, was that optimistic ?
[02:38] <wgrant> Erm, that must have been the wrong bug.
[02:39] <wgrant> lifeless: http://paste.ubuntu.com/590009/ only returns a few hundred rows on qas?
[02:43] <lifeless> wgrant: 750949
[02:43] <wgrant> Er....
[02:43] <lifeless> [Bug 750949] [NEW] BugTask:+index times out with lots of attachments .. ** Tags added: qa-ok
[02:43] <_mup_> Bug #750949: BugTask:+index times out with lots of attachments <qa-ok> <timeout> <Launchpad itself:Fix Committed by wgrant> < https://launchpad.net/bugs/750949 >
[02:43] <wgrant> Oh, right, bug number, not row count.
[02:43] <lifeless> ** Tags removed: qa-needstesting
[02:44] <wgrant> Fixed.
[02:44] <lifeless> 342 rows
[02:44] <wgrant> Right.
[02:44] <wgrant> So 4s after that is completely insane.
[02:44] <wgrant> Also, qas seems to be dead now.
[02:44] <wgrant> Maybe it's updating slowly.
[02:45] <lifeless> 40ms
[02:45] <wgrant> Right.
[02:45] <wgrant> That's slightly longer than the OOPses show, but still not too terrible.
[02:51] <wgrant> Ah, now it's sometimes timing out before it even gets to attachments.
[02:51] <wgrant> So I think it might just be generally unwell.
[02:52] <wgrant> Random multi-second sleeps in there too.
[02:52] <wgrant> So I'm going to re-OK this and blame it on asuka being shit.
[02:54] <lifeless> check the asuka load graph
[02:54] <lifeless> huwshimi: btw
[02:54] <lifeless> huwshimi: ajax log on qastaging is bokred
[02:54] <huwshimi> lifeless: Oh
[02:55] <wgrant> lifeless: Ugh, any idea what's got it so high?
[02:55] <wgrant> Spiked massively an hour ago.
[02:55] <lifeless> askalosa
[02:56] <wgrant> Huh.
[02:56] <wgrant> Interesting.
[02:56] <wgrant> spm: Hi.
[02:57] <spm> damn. why does my /ignore not work anymore. :-(
[02:57] <wgrant> spm: :(
[02:57] <wgrant> spm: Something made asuka reasonably angry load- and RAM-wise right around midnight UTC.
[02:57] <wgrant> any idea what that is?
[02:57] <wgrant> (it is somewhat recovering now, but still not ideal)
[02:58] <huwshimi> lifeless: Where abouts is it not working?
[02:58] <wgrant> In fact it appears to now have flattened out at a heightened level.
[02:59] <wgrant> Whereas it normally drops back down to normally quickly after this sort of spike.
[02:59] <spm> wgrant: hrm. not offhand. tho the load in general for asuka is pretty spiky. I'd suggest a combo of a rollout of something and/or cronjobs firing off
[02:59] <wgrant> spm: Spiky and *11*.
[02:59] <wgrant> I tried to use capital digits there.
[03:00] <wgrant> Sadly they don't exist.
[03:00] <spm> wgrant: heh, I see about 15 of those over the past week. :-/
[03:00] <wgrant> Indeed, but they're fairly irregular.
[03:01] <spm> ish
[03:01] <wgrant> I guess I'll see if it's less unhappy in a few hours.
[03:01] <spm> we should probably fork qas onto a separate box
[03:01] <wgrant> Or just toss the scripts elsewhere and see what happens.
[03:01] <wgrant> I hear we have at least two free appserver boxes now ;)
[03:02] <StevenK> Haha
[03:03] <wgrant> Maybe we can convince gandwana and potassium to serve their sentences on qas, too.
[03:03] <wgrant> Since I doubt anybody else wants them :)
[03:04] <spm> heh, I am not typically privy to the next hop destinations of servers. :-)
[03:05] <lifeless> spm: there is a ticket to move the scripts off
[03:05] <spm>  /forcenickchange lifeless ticketmaster
[03:05] <lifeless> huwshimi: huh, iz working now
[03:05] <lifeless> it wasn't working before
[03:05] <wgrant> lifeless: It just updated.
[03:05] <wgrant> lifeless: May have been icing skew?
[03:06] <lifeless> perhaps
[03:06] <lifeless> spm: I prefer KeyMaster, thanksverymuch
[03:06] <spm> sigh. delusions of grandeur.
[03:11] <lifeless> wgrant: and w/out ?
[03:11] <wgrant> 4s
[03:12] <wgrant> Slightly faster than prod.
[03:12] <lifeless> +1
[03:12] <wgrant> But not much.
[03:13] <lifeless> nie work
[03:22] <mwhudson> hee hee, http://bazaar.launchpad.net/+branch/linaro-android-build-tools/files/head:/ works
[03:27] <lifeless> mwhudson: of course
[03:28] <lifeless> mwhudson: or is that unexpected somehow ?
[03:28] <wgrant> It's pretty new.
[03:28] <wgrant> And probably an unintended side-effect.
[03:29] <mwhudson> lifeless: it's new-ish at least
[03:39] <thumper> bah!
[03:41] <thumper> I'm trying to make a unit test that does the equivalent of: http://pastebin.ubuntu.com/590022/
[03:41] <thumper> anyone got any ideas?
[03:42] <wgrant> You should be able to add a header to a testbrowser...
[03:42] <thumper> hmm...
[03:42] <wgrant> Using the remarkable browser.addHeader method.
[03:42] <thumper> right now it oopses
[03:42] <thumper> which is what i'm wanting to fix
[03:42]  * lifeless hates on doctests
[03:43] <StevenK> lifeless: Then remove them?
[03:43] <lifeless> StevenK: its the README
[03:43] <StevenK> Bwaha
[03:44] <lifeless> anyone see a reason for start=0 to be present on the first batch url ?
[03:45] <wgrant> No.
[03:48] <lifeless> may be some test fallout... shurg
[03:48] <lifeless> I've already caused that
[03:48] <wgrant> Test fallout is dealable with.
[03:50]  * lifeless loves matchers
[03:50]  * wgrant unbreaks publish-distro.d
[03:55] <wgrant> StevenK: You has QA.
[04:00] <wgrant> Hmm.
[04:00] <wgrant> We need a publisher on qastaging.
[04:03] <StevenK> wgrant: The QA tagger should move to someone else
[04:04] <wgrant> StevenK: Oh?
[04:04] <StevenK> Indeed, it's moved to r12746.
[04:04] <wgrant> Yeah.
[04:04] <wgrant> Waiting for my fixed publish-ftpmaster.py to run before I try PPA publishing.
[04:05] <StevenK> On DF?
[04:05] <wgrant> Yeah.
[04:05] <wgrant> I've turned on the run-parts things and made them work.
[04:05] <StevenK> That could take eons
[04:05] <wgrant> So we might get a full run.
[04:05] <wgrant> No!
[04:05] <wgrant> jtv deleted PublishingTunableLoop, so it should only take about 10 minutes to generate file lists now.
[04:05] <wgrant> Indeed, now into a-f itself.
[04:05] <StevenK> I wonder how much that will speed up the publisher on cocobanana
[04:06] <StevenK> wgrant: Do you need to land a branch of fixes for the run-parts fixes?
[04:06] <wgrant> Yes :(
[04:06] <wgrant> StevenK: Not by more than a minute or so, I don't think.
[04:06] <wgrant> But let me check.
[04:08] <wgrant> Seconds at most.
[04:08] <wgrant> Since wildcherry can keep the necessary indices in RAM.
[04:08] <StevenK> So the massive speed up is for DF's benefit only
[04:08] <wgrant> Right.
[04:09] <wgrant> I guess it'll be around a 15-20s improvement for natty on prod.
[04:09] <wgrant> ie. nothing at all.
[04:11] <lifeless> done
[04:11] <wgrant> gpg: signing failed: secret key not available
[04:11] <wgrant> :(
[04:11] <wgrant> lifeless: What's done? Batchnav?
[04:11] <lifeless> yeppers
[04:12] <lifeless> phase 1
[04:12] <wgrant> Nice work!
[04:12] <wgrant> Does it work>?
[04:12] <lifeless> who knows
[04:16] <wgrant> Argh.
[04:16] <lifeless> ?
[04:16] <lifeless> bzr+ssh://bazaar.launchpad.net/~lifeless/lazr.batchnavigator/keyoffset/ if you want to peek, mp coming up now
[04:17] <wgrant> publish-ftpmaster.py's signing hook doesn't work.
[04:17] <wgrant> Since the GPGHandler utility overrides GNUPGHOME to a temp dir.
[04:18] <lifeless> does this break the deply?
[04:18] <wgrant> No.
[04:18] <wgrant> this is the rev we didn't merge.
[04:18] <wgrant> And we weren't even planning to move to this new script immediately either.
[04:20] <lifeless> I can has review?
[04:20] <lifeless> https://code.launchpad.net/~lifeless/lazr.batchnavigator/keyoffset/+merge/56499
[04:21] <lifeless> StevenK: ^
[04:21] <wgrant> 1400 lines.
[04:21] <wgrant> That's almost into Soyuz territory.
[04:21] <lifeless> StevenK: if you whine that its too large, I'll whine that its using copied code from zope
[04:22] <lifeless> wgrant: I can halve it by deleting comments and tests.
[04:22] <lifeless> wgrant: Lines of code is a terrible complexity metric
[04:23] <lifeless> wgrant: particular because of context
[04:23] <lifeless>  12 files changed, 659 insertions(+), 209 deletions(-)
[04:23] <lifeless> is a better-but-still-not-great indicator
[04:24] <StevenK> lifeless: I think you linked the wrong bug
[04:24] <lifeless> StevenK: thats merge proposals being noddy
[04:25] <lifeless> StevenK: bug 726195
[04:25] <_mup_> Bug #726195: merge proposals show closed bugs <code-review> <Launchpad itself:Triaged> < https://launchpad.net/bugs/726195 >
[04:25] <lifeless> which is nontrivial
[04:25] <lifeless> because we should capture the bugs against the MP
[04:26] <lifeless> so the branch can get more links and not alter the MP
[04:26] <lifeless> this would also make some queries faster
[04:26] <StevenK> lifeless: I'm not sure about your choice of 'memo' as a variable name -- especially since it's shown in URLs
[04:27] <lifeless> StevenK: cosmetic and easy to change if you have a better label
[04:27] <lifeless> StevenK: its going to be base64 junk
[04:27] <lifeless> StevenK: not hand guessable or enterable
[04:27] <StevenK> Well, I'm not sure what you're trying to show with it
[04:28] <lifeless> StevenK: its the db constraints needed to get back to a particular batch, serialised.
[04:28] <lifeless> e.g. for a bug search it might be ABBD23427834EfJ
[04:28] <lifeless> meaning 'bug heat < 43 and bugtask.id > 34'
[04:29] <lifeless> http://en.wikipedia.org/wiki/Memoization
[04:30] <StevenK> Right
[04:31] <StevenK> lifeless: I'm ... I don't know, half-way? Breaking for lunch, so my stomach doesn't break out and insist.
[04:31] <lifeless> StevenK: thats cool
[04:31] <lifeless> StevenK: I'm going to start on a 'lets see if this breaks lp' branch of lp
[04:32] <wgrant> Aha! It no longer crashes!
[04:32] <wgrant> We may have victory.
[04:32]  * wgrant carefully publishes a few suites.
[04:39] <wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/bug-752149/+merge/56500
[04:40] <wgrant> Oh, actually, even simpler.
[04:41] <lifeless> wgrant: tell me when
[04:45] <lifeless> I kindof wish we'd done an april fools thing
[04:45] <lifeless> like skinning lp like sourceforge and announcing a merge
[04:45] <wgrant> Heh.
[04:46] <wgrant> Even Debian did one this time.
[04:46] <lifeless> I know
[04:46] <wgrant> lifeless: Diff updated.
[04:51] <lifeless> sadness, make schema day
[04:52] <lifeless> we should make that incremental
[04:52] <wgrant> lifeless: You mean like, say, running upgrade.py?
[04:52] <lifeless> mmm, or make it obvious how to do it incrementally if one knows how
[04:52] <lifeless> wgrant: well its not always safe
[04:52] <lifeless> wgrant: but yes, upgrade.py on launchpad_ftest_template etc
[04:52] <wgrant> Also, make schema isn't *that* slow any more.
[04:52] <lifeless> tell that to my wadl compiler
[04:53] <lifeless> I'm just wearing my curmudgeon hat today
[04:58] <wgrant> lifeless: Thanks.
[04:59]  * wgrant glares at mawson.
[05:03] <wgrant> spiv: Hi.
[05:10] <lifeless> ok, launchpad bugs needs to die
[05:10] <lifeless> can we just delete that catchall ?
[05:10] <lifeless> let folk use the shocking mute functionality ?
[05:10] <wgrant> We should probably blackhole it for now.
[05:11] <wgrant> I was hoping the bug subscription feature work would think about how to fix not just bug notifications, but apparently not :/
[05:13] <poolie> lifeless, i'm aware there's a "bugs i reported" function
[05:13] <poolie> nm, i'll comment on the bug
[05:13] <lifeless> wgrant: well, by removing the thing, I think we can subscribe things more directly and appropriately
[05:15] <wgrant> lifeless: I guess we'll also find out what's going there pretty quickly.
[05:15] <wgrant> And work out how to fix it.
[05:17] <Ursinha-afk> lifeless, hi, did you see any other occurrences of bug 727552?
[05:17] <_mup_> Bug #727552: when first rev is bad, with a later rollback, qatagger incorrectly reports it deployable atthe top <qa-tagger:In Progress by ursinha> < https://launchpad.net/bugs/727552 >
[05:17] <Ursinha-afk> I can't reproduce that
[05:22] <spiv> wgrant: hi?
[05:23] <wgrant> spiv: Your Codehosting Twisted evil needs QA.
[05:25] <StevenK> Eyes bleeding ...
[05:25] <spiv> wgrant: ok.  What would that look like?  Would verifying that 'bzr push' of a new branch still works, (to staging/qastaging) suffice?
[05:26] <lifeless> so
[05:26] <lifeless> sob
[05:26] <lifeless> GoogleBatchNavigator - facepalm
[05:26] <StevenK> lifeless: Burn it with Holy Fire?
[05:26] <StevenK> spiv: Well, how did you notice the slowness in the first place?
[05:26] <lifeless> Ursinha-afk: well I saw it right before I reported the bug, unless its been specifically fixed i suspect its still the case
[05:27] <lifeless> StevenK: jam noticed it locally in a vm
[05:27] <lifeless> spiv: pushing to qastaging is good - be sure to trigger some failures
[05:29] <spiv> StevenK: jam noticed it.
[05:31] <lifeless> StevenK: can't burn it trivially, it wants a refactor of the base class, for now I'll just copy and paste and cry
[05:31] <spiv> StevenK: I saw the profiling data he generated, applied my knowledge of which bits of Twisted are particularly crummy, jam did a crude hack confirming our hypothesis, I wrote a proper workaround (and proper fix for upstream, plus micro-benchmark for upstream).
[05:32] <spiv> lifeless: practically everything we do triggers failures
[05:32] <spiv> lifeless: that's the issue! ;)
[05:32] <spiv> lifeless: jam noticed this issue from a simple initialize BzrDir RPC.
[05:32] <lifeless> spiv: I know, familiar with it
[05:32] <lifeless> spiv: I mean trigger something we expect to return an error to you, the user.
[05:32] <spiv> Ok.
[05:33] <lifeless> spiv: because if its going to break, I'd expect that to be where it does.
[05:33] <lifeless> e.g. unknown project
[05:33] <spiv> So, 1) push up a new branch to somewhere that works, ~user/proj/branch, and 2) try a push that should fail, e.g. to ~user/no-such-project/foo ?
[05:33] <lifeless> or a project you don't have permissions to push into
[05:33] <lifeless> yes, exactly
[05:34] <spiv> Ok.  When will the code be on qastaging?
[05:34] <wgrant> It is now.
[05:34] <spiv> Great!  I'll do that QA now.
[05:35] <lifeless> spiv: when the qatagger comments on  abug saying 'x landed', its reached a staging server.
[05:35] <lifeless> spiv: the specific one depending on the branch it landed on
[05:35] <spiv> Sounds handy, although I'm sure to have forgotten that by the next time I have another LP change to land and QA.
[05:35] <StevenK> db-stable => staging, stable => qastaging
[05:36] <spiv> Or just as likely, the process is likely to have changed ;)
[05:36] <StevenK> Our QA process hasn't changed for a few months.
[05:36] <spiv> StevenK: yes, my point exactly
[05:36] <lifeless> spiv: I think we'll make it faster, but not change this aspect
[05:36] <spiv> StevenK: just how recently do you think I've landed something? :)
[05:36] <lifeless> the notify a human now aspect is very useful
[05:37] <lifeless> spiv: 6 weeks?
[05:37] <spiv> lifeless: and it didn't pass QA :P
[05:39] <spiv> (I'm not complaining, I think you have a good process that's working well: the fact that wgrant was able to ping me about this in a timely fashion shows this process is coping adequately with infrequent contribuors like myself)
[05:39] <StevenK> lifeless: Pass the bleach, r=me
[05:40] <lifeless> StevenK: thanks!
[05:40] <StevenK> lifeless: With a little caveat that you can ignore if you wish
[05:41] <wgrant> spiv: lifeless and I keep track of our QA status pretty closely,.
[05:41] <StevenK> I tend to watch it, I just don't nag.
[05:42] <spiv> StevenK: I don't need nagging, I just need my hand held because I don't have much familiarity with your processes any more.
[05:42] <StevenK> spiv: That was a dig at wgrant and lifeless, rather than you.
[05:48] <spiv> wgrant: my testing worked.  Do I just change the tag to qa-ok now?
[05:49] <wgrant> spiv: Yup.
[05:49] <spiv> wgrant: done.  Thanks!
[05:49] <wgrant> Thank you!
[05:50] <wgrant> Much better than me having to do it myself tonight :)
[05:50] <spiv> :)
[05:51] <lifeless> wgrant: is there anything you need from me ?
[05:51] <poolie_> lifeless, hi, i was looking at outstanding bugs assigned to me
[05:51] <poolie_> what do you think i should do on https://code.launchpad.net/~mbp/launchpad/690021-rlimit/+merge/43733
[05:51] <poolie_> your last comment seems to suggest 'land it'
[05:52] <poolie_> i think landing it and seeing what happens is probably the best option
[05:52] <poolie_> or just abandoning it
[05:52] <wgrant> lifeless: Don't think so.
[05:55] <lifeless> poolie_: I would like to see it landed
[05:56] <poolie_> as is?
[05:56] <lifeless> poolie_: we know the branch that causes this (linux ;))
[05:56] <lifeless> so we can see if it loops as tim fears it may
[05:56] <lifeless> I would be ok with landing it as is, as long as when we deploy this rev we know to look for this potential problem
[05:57] <lifeless> we can rollback just the import slaves *if* its a problem
[05:58] <poolie_> ok, that makes sense to me
[05:59] <poolie_> thanks; hooray for unsticking things
[06:02] <wgrant> The lucid non-release pockets are big :(
[06:03] <lifeless> StevenK: https://code.launchpad.net/~lifeless/launchpad/bug-752153/+merge/56505
[06:06] <StevenK> lifeless: Oh, and it copies code due to your earlier comment
[06:07] <StevenK> lifeless: r=me
[06:08] <lifeless> StevenK: thanks
[06:11] <lifeless> next step, migrate a real collection, like FTBFS, to use a custom IRangeFactory
[06:21] <thumper> simple fix: https://code.launchpad.net/~thumper/launchpad/fix-dud-referer/+merge/56508
[06:21] <thumper> I was trying to fix bug 44919
[06:21] <_mup_> Bug #44919: UnicodeDecodeError while POSTing forms with non-ascii characters. <infrastructure> <lp-foundations> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/44919 >
[06:22] <thumper> but the oopses I looked at weren't related to that failure
[06:22] <thumper> and I didn't notice
[06:22] <lifeless> I have a suggested tweak
[06:22] <thumper> so I filed bug 752218
[06:22] <_mup_> Bug #752218: Referer header with non-ascii oopses on not found page <oops> <Launchpad itself:In Progress by thumper> < https://launchpad.net/bugs/752218 >
[06:22] <thumper> lifeless: for me?
[06:23] <StevenK> thumper: r=me
[06:23] <lifeless> thumper: yeah, its on the revier
[06:23] <lifeless> *review*
[06:23] <thumper> ok
[06:24] <thumper> lifeless: the whole point of getting the referer is to show a link to the user to say "go back to where you came from"
[06:24] <thumper> if we replace the dud characters
[06:24] <lifeless> thumper: oh
[06:24] <thumper> it'll fail
[06:24] <lifeless> thumper: rightyho
[06:24] <thumper> and it's bogus anyway
[06:24] <thumper> normally spam
[06:24] <thumper> from the oopses I looked at
[06:24] <lifeless> thumper: yeah. the underlying bug here - which you might like to put a comment about
[06:24] <lifeless> is that we shouldn't be decoding the referrer at all
[06:25] <lifeless> urls that we did not generate can legitimately be in /any/ encoding
[06:25] <wgrant> The moral of the story: Python 2 sucks, let's use Python 3.
[06:25] <lifeless> because it makes this worse
[06:25] <thumper> the problem is that the http request has a byte string
[06:26] <thumper> but when we try to put it into the tales
[06:26] <thumper> it gets coerced into unicde
[06:26] <thumper> and dying
[06:26] <lifeless> it has to stay a byte string the whole way through
[06:26] <lifeless> I know thats way out of scope to fix
[06:26] <thumper> it will never though to include in the page
[06:26] <lifeless> and I'm ok with your branch
[06:26] <lifeless> I'm simply noting that if someone comes along and goes 'wtf we drop it' - it would be worth a mention at that point in the code
[06:27] <thumper> most the templating engines these days are unicde based
[06:27] <thumper> lifeless: I'll add a comment
[06:27]  * thumper wonders what happens to the 'o' in unicode
[06:27] <lifeless> its fine that they are unicode based, but they /render/ to something defined as bytes, not as ascii or utf8.
[06:27] <thumper> eventually yes
[06:27] <thumper> but the unicode intermediate step causes pain
[06:28] <lifeless> yuuuup
[06:28] <lifeless> oh, ffs, timeouts connecting to amazzzon again
[06:52] <lifeless> wgrant: that ftbfs collection timeout
[06:52] <lifeless> wgrant: has teh script been rewritten
[06:52] <lifeless> ?
[06:55] <lifeless> bug 730396 I think
[06:55] <_mup_> Bug #730396: DistroSeries:EntryResource:getBuildRecords timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/730396 >
[07:00] <wgrant> lifeless: Not yet.
[07:11] <lifeless> wgrant: 20ms batches of FTBFS
[07:11] <lifeless> wgrant: except for the last one, because the table structure is gnarly, as I keep whinging about
[07:12] <lifeless> wgrant: this is about 30 times faster
[07:12] <wgrant> lifeless: Nice!
[07:12] <lifeless> https://bugs.launchpad.net/launchpad/+bug/730396
[07:12] <lifeless> bah
[07:12] <_mup_> Bug #730396: DistroSeries:EntryResource:getBuildRecords timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/730396 >
[07:12] <lifeless> https://bugs.launchpad.net/launchpad/+bug/730396/comments/14
[07:12] <_mup_> Bug #730396: DistroSeries:EntryResource:getBuildRecords timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/730396 >
[07:17] <lifeless> poolie: I think its good to question the canned searches we have on bugs.l.n/+me
[07:17] <poolie> me too
[07:17] <lifeless> poolie: I may have come across as pushing back on you earlier; i didn't intend to
[07:17] <poolie> i was having a kinda irritable day
[07:17] <poolie> i'm finding unity really stunning in concept and rather flaky as actual software
[07:18] <poolie> oh, also the lplib thing was annoying
[07:18] <wgrant> Yes, it's really great to use, except that it crashes.
[07:18] <wgrant> Lots.
[07:18] <wgrant> And when it doesn't crash it glitches.
[07:18] <poolie> its failure mode of talking to staging instead of lpnet was a big timewaster
[07:18] <lifeless> wgrant: you need to ask the devs to take the if username=='' check out
[07:19] <poolie> anyhow, i agree about reconsidering the canned searches, but on the other hand this is probably not the most important change there
[07:19] <poolie> one thing i would like a lot is to make them show most-recent-first
[07:20]  * wgrant headdesks.
[07:20] <wgrant> lifeless: Have you looked at BugTargetBugTagsView?
[07:20] <wgrant>         popular_tags = [tag['tag'] for tag in sorted(
[07:20] <wgrant>             other_tags, key=itemgetter('count'), reverse=True)[:10]]
[07:21] <lifeless> wgrant: can you please take that blunt spoon out of my eyeballs?
[07:22] <wgrant> I knew it was bad, but wow...
[07:22]  * lifeless considers breaking list comprehensions in lp
[07:22] <lifeless> wgrant: there are 6K unique tags in lp
[07:22] <lifeless> sorry
[07:22] <lifeless> in ubuntu
[07:23] <wgrant> Yeah.
[07:23] <wgrant> It is stupid.
[07:23] <lifeless> wgrant: criminal
[07:23] <lifeless> wgrant: it looks like *product* bug tag portlets may show every tag
[07:23] <lifeless> wgrant: check out the launchpad portlet for instance
[07:24] <wgrant> lifeless: I don't think so.
[07:24] <lifeless> https://bugs.launchpad.net/launchpad -
[07:24] <wgrant> launchpad-project's is a little odd, because it inherits the old disabled ones.
[07:24] <lifeless> look at it.
[07:24] <wgrant> Hmm.
[07:24] <lifeless> do we really have ~100 official tags?
[07:25] <lifeless> including 'arm'
[07:25] <lifeless> and 'boobytrap'
[07:25] <wgrant> boobytrap is official.
[07:25] <wgrant> arm is official.
[07:25] <lifeless> so is arm
[07:25] <lifeless> wtf
[07:25] <wgrant> boobytrap is one of Julian's.
[07:25] <lifeless> well, apparently we do.
[07:25] <lifeless> we should nuke about half of these.
[07:25] <wgrant> story-better-bug-notification is unofficial, but probably in the top 10.
[07:26] <lifeless> oh, it shows the top 10.. yay
[07:26] <lifeless> uhm
[07:26] <lifeless> denormalisation time?
[07:27] <lifeless> possibly a better query will be faster
[07:27] <wgrant> Well, I was going to try to improve the query, and if that didn't work just drop the top 10.
[07:27] <lifeless> add a rank clause for starters
[07:27] <wgrant> Or drop the top 10 if there are official tags, or something like that.
[07:27] <wgrant> Why?
[07:27] <lifeless> 6K results back is pointless
[07:28] <wgrant> ORDER BY COUNT(Bug) LIMIT 10?
[07:28] <lifeless> count(tag); yeah
[07:29] <wgrant> Er, count(tag)?
[07:29] <wgrant> What good would that do?
[07:29] <wgrant> Oh, count(BugTag), you mean?
[07:30] <lifeless> bugtag.tag
[07:30] <lifeless> the point is to only return the 10 most popular
[07:30] <lifeless> wgrant: one change I think would be uncontentious
[07:31] <lifeless> wgrant: include official tags in the top 10 calculation
[07:31] <lifeless> wgrant: so that if (say) 5 of the official tags are also top 10, one sees 15 tags total.
[07:31] <wgrant> rofl, for the first 8 months it showed the bottom 10 instead of top 10.
[07:31] <lifeless> erm count(official) + 5
[07:31] <lifeless> wgrant: \o/
[07:31] <lifeless> yay testing.
[07:34] <wgrant>     def _getSearchURL(self, tag):
[07:34] <wgrant>         """Return the search URL for the tag."""
[07:34] <wgrant>         # Use path_only here to reduce the size of the rendered page.
[07:34] <wgrant>         return "+bugs?field.tag=%s" % urllib.quote(tag)
[07:34] <wgrant> :/
[07:34] <wgrant> I've not seen that reason used anywhere else.
[07:38] <lifeless> right, where was I before I knocked the battery out
[07:38] <StevenK> Fail
[07:39] <lifeless> thanks, I hadn't noticed
[07:40] <wgrant> ...
[07:40] <wgrant> Grar.
[07:41] <wgrant> That tag cloud is calculated after taking privacy into account.
[07:41] <wgrant> But is cached publicly.
[07:41] <lifeless> hmm
[07:42] <lifeless> the queries I saw had no privacy clause, just private=False
[07:42] <lifeless> or was that cause they were anonymous requests?
[07:42] <wgrant> User: Anonymous User
[07:43] <lifeless> k
[07:44] <lifeless> I don't know that memcache saves us much here anyhow
[07:44] <lifeless> same argument as usual: if misses suck, we're in trouble
[07:44] <lifeless> if misses don't suck, do we care
[07:45] <wgrant> If it wasn't loaded in a separate request I think it would be worth preserving it.
[07:53] <wgrant> Ah, getUsedBugTags* only has twoish callsites, fortunately.
[07:53] <wgrant> Because both of those methods are broken and need a rewrite :(
[07:55] <lifeless> wgrant: you might like my countBugs aggregat ehelper
[08:03] <LPCIBot> Project devel build #612: FAILURE in 5 hr 41 min: https://lpci.wedontsleep.org/job/devel/612/
[08:03] <StevenK> Baaaaaaaaaah, windmill
[08:03] <StevenK> When did you come back?
[08:04] <wgrant> If it's failed again, it is going to be killed again in 5 minutes.
[08:04] <wgrant> Although I guess it's not actually testfixed us yet, so it can stay for a while.
[08:04] <wgrant> But the moment it fails in buildbot I am killing it again.
[08:05] <StevenK> Heh
[08:07] <StevenK> wgrant: Not even a second chance?
[08:07] <wgrant> It has had three already :)
[08:08] <StevenK> The fact that it failed in Jenkins and not Buildbot makes me sad.
[08:08] <wgrant> Jenkins has always been better at exposing fragile tests :/
[08:09] <StevenK> Two time out errors makes me suspcious
[08:14]  * StevenK runs 'bzr rm lib/lp/soyuz/pas.py' to make him feel better.
[08:41] <lifeless> bug  740750 makes me very sad
[08:41] <_mup_> Bug #740750: API timeouts broken and returning no useful data... <regression> <Launchpad itself:Triaged> <lazr.restful:Triaged> < https://launchpad.net/bugs/740750 >
[08:44] <lifeless> anyhow, I need to talk to an api plumbing person
[08:54] <adeuring> good morning
[08:58] <lifeless> wgrant: I might grab a little of your time tomorrow to bounce ideas about glueing $stuff together
[09:00] <wgrant> lifeless: Sure.
[09:00] <wgrant> Oh, it's time.
[09:03] <lifeless> wgrant: on tags
[09:03] <lifeless> wgrant: is it constrained to open bugs only now ?
[09:03] <wgrant> lifeless: Yes, but it seems to fail to exclude dupes.
[09:03] <lifeless> s/open/only open/
[09:05] <mrevell> Hello, good morning
[09:05] <lifeless> I wonder if there is a poor non-api collection I could improve
[09:05] <lifeless> wgrant: is that ftbfs collection also in the web ui?
[09:06] <wgrant> lifeless: Something very like it, yes.
[09:06] <wgrant> lifeless: https://launchpad.net/ubuntu/+builds uses Distribution.getBuildRecords.
[09:06] <wgrant> /~wgrant/+archive/ppa/+builds for Archive.getBuildRecords.
[09:07] <lifeless> https://launchpad.net/ubuntu/natty/+builds?build_text=&build_state=failed&arch_tag=all
[09:08] <lifeless> https://launchpad.net/ubuntu/natty/+builds?arch_tag=all&build_state=failed&build_text=&start=3150&batch=75
[09:08] <lifeless> would seem to match the behaviour
[10:00] <mpt> Is there a graph anywhere of how much faster Launchpad has been getting?
[10:00] <mpt> lifeless? ^
[10:01] <lifeless> mpt: its a bit noisy
[10:01] <lifeless> but
[10:01] <lifeless> https://lpstats.canonical.com/graphs/PPR/
[10:02] <lifeless> this doesn't show the in-dc queueing problem which I discussed in my capacity email to the -dev list
[10:02] <lifeless> for isntance
[10:02] <lifeless> https://lpstats.canonical.com/graphs/PPR/20100407/20110407/
[10:04] <wgrant> And the in-DC queueing was a *big* problem.
[10:05] <mpt> thanks
[10:06] <lifeless> we don't yet have metrics for in-dc queuing
[10:06] <lifeless> we have a nagios check coming for one known symptom
[10:07] <jkakar> Maybe there's already a bug filed, but sometimes when Launchpad is in read-only mode I get two of the yellow notification boxes, when viewing a bug, that tell me Launchpad is in read-only mode.  It's seems to be consistent for particular bugs, I think, but there doesn't seem to be an otherwise obvious pattern.
[10:07] <lifeless> jkakar: I want to nuke readonly mode
[10:07] <lifeless> jkakar: its a source of longer downtime, ironically enough
[10:07] <jkakar> lifeless: That sounds like an excellent fix for the issue. :)
[10:08] <stub> jkakar: Are you using two browser windows by any chance?
[10:09] <jkakar> stub: Nope, one instance of Minefield (FF4) with several tabs open.
[10:10] <stub> jkakar: Several tabs open on Launchpad? Its a known issue that if you are using two browser windows to Launchpad the race conditions can cause notifications to pop up on the wrong browser
[10:10] <jkakar> stub: Ah, that could be it, yes.
[10:10] <jkakar> stub: It happened (sometimes) when I was viewing a milestone listing and Ctrl-clicked several bugs to open in new tabs.
[10:11] <stub> That would do it. The key to 'which notifications should I display' is a cookie, and that same cookie is used for all browser windows of course.
[10:14] <lifeless> mpt: for instance, see translations 99th percentile goes from 8 down to 4 seconds
[10:14] <lifeless> mpt: on the year-wide graph
[10:15] <lifeless> mpt: the red line is the over-everything metric, which is very slow to move (because > 50% of renders are API, and API is already generally pretty good
[10:15] <lifeless> )
[10:16] <mpt> lifeless, thanks, ivanka just wanted an answer to the question "Why is Launchpad down for maintenance", and that graph was the most effective rationale I could think of :-)
[10:16] <lifeless> heh
[10:17] <lifeless> mpt: so the the problem is the technology
[10:17] <wgrant> ... that covers most problems with Launchpad.
[10:17] <lifeless> mpt: schema changes are tricksy in postgresql w/replication
[10:17] <lifeless> https://dev.launchpad.net/Database/LivePatching
[10:17] <lifeless> https://dev.launchpad.net/LEP/ReliableDBDeploys
[10:19] <lifeless> mpt: both those links are technical, but I'm sure you can translate ;)
[10:19] <mpt> in my copious spare time
[10:19] <lifeless> we just gave you 90minutes of time ;)
[10:19] <mpt> zing!
[10:23] <lifeless> mpt: anyhow, short story, we've dropped nearly 2 seconds off the 99th percentile
[10:23] <lifeless> mpt: and 9 seconds off the hard timeout cap (which is set to maintain < 0.1% failure rate)
[10:23] <wgrant> And we'll hopefully drop it again tomorrow...
[10:26] <lifeless> wheee
[10:26] <lifeless> https://bugs.launchpad.net/ubuntu 1.91 seconds
[10:27] <wgrant> Ah, great. It was 2.8 when I tried before.
[10:27] <wgrant> Must have warmed up.
[10:27] <lifeless> 2.8 is still better than 11 :)
[10:27] <wgrant> Very true.
[10:27] <lifeless> https://bugs.launchpad.net/ubuntu/natty was 2
[10:29] <lifeless> https://bugs.launchpad.net/bzr 1.68
[10:29] <lifeless> https://bugs.launchpad.net/bazaar 1.81
[10:30] <lifeless> bzr 1.27 hot
[10:35] <lifeless> 2.16 for launchpad-project
[10:35] <lifeless> 1.58 hot
[10:36] <lifeless> before this change
[10:36] <lifeless> only 20% of page loads for the ubuntu bugs-index were under 5 seconds
[10:36] <lifeless> 50% under 8
[10:37] <lifeless> this is a massive win
[10:41] <lifeless> BugTask:+text needs a fixin
[10:48] <lifeless> wow
[10:48] <lifeless> Bug:+text - 65K hits a day
[10:51] <lifeless> ProjectGroupSet:+all is half fast and half slow
[10:52] <lifeless> I thought I fixed it :(
[10:52] <lifeless> oh, or maybe it wasn't deployed
[10:54] <lifeless> wgrant: I think Distribution:+bugtarget-portlet-tags-content needs fixing before we drop the timeout
[10:55] <lifeless> 12s 99th percentile
[10:57] <wgrant> lifeless: Whitelist whitelist.
[10:58] <lifeless> wgrant: I think we should wait till monday;
[10:58] <wgrant> lifeless: Do you have IP addresses for BugTask:+text? I suspect Debian.
[10:58] <jam> wgrant: fixing is better than whitelisting :)
[10:58] <lifeless> wgrant: that gives us a complete day on thurs->friday
[10:58] <wgrant> lifeless: True.
[10:58] <wgrant> lifeless: Plus we'll have an ndt before Thursday.
[10:58] <lifeless> yup
[10:59] <lifeless> so, logs will tell us
[10:59] <lifeless> I don't have an IP handy
[10:59] <jam> lifeless: so I saw that spiv qa'd his twisted patch, how does that work in a deployment sense?
[10:59] <jam> Since codehosting is still downtime required
[10:59] <wgrant> lifeless: lucas imports Ubuntu bugs into UDD, and I think that still uses BugTask:+text
[10:59] <jam> but you are trying to only do a db deploy during this downtime
[11:00] <lifeless> jam: we either schedule downtime, or it gets rolled out next db deploy
[11:00] <jam> lifeless: so currently codehosting *does* get rolled out during db deploy
[11:00] <jam> (even if that particular patch missed this downtime)
[11:00] <lifeless> yes
[11:01] <lifeless> its still a full deploy
[11:01] <lifeless> but I'm trying to get things detangled
[11:01] <lifeless> there are complicating factors
[11:07] <lifeless> hmm
[11:07] <lifeless> I think we need the PPR to go into 5ths of a second
[11:10] <wgrant> lifeless: Yeah :(
[11:34] <lifeless> night
[11:50] <henninge> rvba: r=me ;-)
[11:50] <rvba> henninge: \o/
[11:51] <wgrant> bigjools: Want to land your config branch now? I'll remove the schema keys tomorrow.
[11:51] <rvba> henninge: thank you for your patience and precious advices.
[11:51] <wgrant> henninge: Thanks for encouraging the proper use of structured()!
[11:53] <henninge> wgrant: welcome
[11:53] <henninge> wgrant: I was surprised, though, that .escapedtext has to be used explicitely.
[11:54] <wgrant> henninge: Yes :/ That's a bit silly.
[11:54] <henninge> it is
[11:54] <rvba> henninge: wgrant I've put the call to escapedtext in the template though
[11:54] <henninge> I saw that. I have no preference either way.
[11:55] <wgrant> It belongs in the template.
[11:55] <henninge> rvba: well done ;)
[12:01] <deryck> Morning, all.
[12:13] <jml> morning
[12:15] <jkakar> Hiya jml!
[12:16] <jml> jkakar: hello
[12:20] <rvba> danilos: Hi! Could you take a look at https://code.launchpad.net/~rvb/launchpad/dds-add-unique-packages/+merge/56548 for me?
[12:27] <danilos> rvba, hi, sure thing
[12:35] <danilos> rvba, is it intentional that this pages uses the same template as +localpackagediffs?
[12:36] <rvba> danilos: yes
[12:36] <danilos> rvba, if so, you'd probably want to rename the template so it better indicates what is it about
[12:36] <rvba> danilos: that's right.
[12:40] <rvba> danilos: actually the template name is distroseries-localdifferences.pt. The 3 pages sharing this templates are all used to display local differences ... of different types.
[12:40] <danilos> rvba, ok, then I guess it's fine to keep the name
[12:40] <rvba> yep
[12:41] <danilos> rvba, the branch looks pretty good otherwise, but I have another naming question: I believe it's our practice to name all our view classes as SomethingSomethingView, so it'd be nice to change that as well
[12:42] <danilos> s/as well//
[12:42] <danilos> rvba, other than that, r=me
[12:42] <rvba> danilos: great, I'll look into the naming thing.
[12:44] <danilos> rvba, basically, just append "View" to the class name, and, seeing there's more of them like that (for the other pages), we might want to fix those (in a different branch), or discuss this on the mailing list :)
[12:44]  * rvba is doing that right now.
[12:45] <danilos> cheers
[12:57] <jml> mrevell: could I please skype you to test out my new webcam?
[12:58] <mrevell> sure
[12:59] <mrevell> jml, please go ahead, caller
[12:59] <mrevell> jml, I see you
[13:00] <mrevell> but I don't hear you jml
[13:00] <bigjools> shakin that ...
[13:07] <bigjools> wgrant: around?
[13:07] <wgrant> bigjools: Mostly.
[13:08] <bigjools> wgrant: just wanted to run something by you quickly as it seems like I have a too-easy solution to something :)
[13:08] <wgrant> bigjools: Sure.
[13:08] <bigjools> wgrant: when we open a new distroseries, one of the steps taken is to run the publisher in careful mode
[13:09] <bigjools> wgrant: I am thinking that we can avoid that by creating all the publications as pending instead
[13:09] <wgrant> bigjools: That will take many hours to publish.
[13:09] <bigjools> there must be a catch
[13:09] <wgrant> bigjools: It will hash a hundred gigabytes or so.
[13:09] <wgrant> == slow
[13:09] <bigjools> hmmm
[13:09] <bigjools> why is careful publishing quicker
[13:10] <wgrant> Hmm. Is it a full -C publish?
[13:10] <wgrant> Or just -A?
[13:10] <bigjools> -A
[13:10] <wgrant> -A is indices only.
[13:10] <bigjools> yes
[13:10] <bigjools> so it avoids the file checks
[13:10] <wgrant> -C implies -P, which tries to rewrite all of the files from the DB.
[13:10] <bigjools> arse
[13:10] <wgrant> Yis.
[13:11] <bigjools> so there's the catch
[13:11] <wgrant> Yes.
[13:11] <wgrant> Explicit pocket dirtying would be nice.
[13:11] <wgrant> Can has?
[13:11] <bigjools> heh
[13:11] <bigjools> that would also force file publishing no?
[13:11] <wgrant> No.
[13:12] <wgrant> It would just mark an extra suite as dirty, requesting normal domination and index generation.
[13:12] <wgrant> (it would also make the publishable safely killable)
[13:12] <bigjools> yeah
[13:14] <bigjools> might have to do this - we need a way of making new distroseries "just work" with no shell access
[13:14] <wgrant> Yeah. It's pretty simple, too.
[13:15] <wgrant> New (archive, distroseries, pocket) table, set by the init job, unset at the end of the publisher.
[13:16] <bigjools> but.... pockets ... :/
[13:17] <bigjools> some distros don't have pockets, so it'd need to be (archive, suite)
[13:17] <wgrant> bigjools: Right, once we have explicit suites.
[13:18] <wgrant> But until then suite == (distroseries, pocket)
[13:18] <wgrant> I hope soon we'll delete pockets.
[13:18] <bigjools> that won't work for distros other than ubuntu
[13:18] <wgrant> But that's not how it is now.
[13:18] <wgrant> Sure, but neither will SPPH, BPPH, PackageUpload, PackageBuild, or just about anything.
[13:18] <bigjools> some distros want to keep updating the release "pocket" even after release
[13:19] <wgrant> They will all need s/(distroseries, pocket)/suite/, and that can be done when we have a Suite table.
[13:19] <bigjools> yay
[13:20] <wgrant> And then pockets can GTFO LP.
[13:21] <wgrant> I'm not sure whether Suite wants to include Archive... I guess we'll see what's best.
[13:21] <bigjools> probably not, there could be an archivesuite table later
[13:22] <bigjools> but... use cases first :)
[13:22] <wgrant> Yes.
[13:22] <bigjools> bug 174375
[13:22] <_mup_> Bug #174375: Distribution drivers permissions may need redesign <distributions> <lp-registry> <permissions> <ubuntu-platform> <Launchpad itself:Triaged> <ubuntu-community:Confirmed for techboard> < https://launchpad.net/bugs/174375 >
[13:22] <wgrant> D:
[13:22] <bigjools> *weep*
[13:23] <wgrant> Yes.
[13:23] <wgrant> I have quite deliberately avoided trying to analyse that :)
[13:44] <LPCIBot> Yippie, build fixed!
[13:44] <LPCIBot> Project devel build #613: FIXED in 5 hr 41 min: https://lpci.wedontsleep.org/job/devel/613/
[13:49] <henninge> deryck: I'll be relocating quickly now. I may be 5 minutes late for the call
[13:49] <deryck> henninge: np
[14:08]  * danilos -> away
[14:18] <deryck> Just FYI for everyone, I've asked abentley *not* to be on call reviewer today.
[14:18] <deryck> We have some work to get done on Orange Squad and I need him today.
[14:19] <deryck> I won't list myself as on call reviewer, but if anyone needs a review feel free to ping me.
[14:21] <jml> deryck: thanks for the heads up
[14:21] <deryck> np.  resending in email, too.
[14:36] <bigjools> sinzui: how's the allergy meds going? :)
[14:37] <sinzui> I am stoked to have survived the night after several choking bouts
[14:37] <sinzui> I think I need to move north or to a desert for a month
[14:37] <bigjools> sinzui: are you feeling up to talking about distro series permissions?
[14:38] <sinzui> sure
[14:38] <abentley> sinzui: you can come here, but it may not be north enough.
[14:38] <bigjools> sinzui: I want to let distro drivers add new series.  The pollen in the nose however is the Ubuntu team
[14:38] <sinzui> yes. That is a very large team
[14:39]  * bigjools recalls the epic warthogs email 4 years ago
[14:39] <abentley> deryck: chat?
[14:39] <deryck> abentley: sure.  mumble?
[14:39] <sinzui> bigjools: I believe IDerivativeDistro already supports this behaviour
[14:39] <abentley> deryck: yes.
[14:39] <bigjools> sinzui: ah... that old chestnut
[14:40] <bigjools> sinzui: addseries needs lp.append on IDerivativeDistribution
[14:41] <sinzui> I believe lp.append checks for admin, owner, or driver
[14:41] <bigjools> ok
[14:41] <bigjools> how does it decide that something is IDerivativeDistribution?
[14:41] <sinzui> there was something about lp.driver that scared me when I tried it
[14:41] <sinzui> I wish I could remember what the problem was
[14:43] <bigjools> ah, I have found the hack
[14:43] <bigjools>         if self.name == 'ubuntu':
[14:43] <bigjools>             alsoProvides(self, IBaseDistribution)
[14:44] <sinzui> bigjools: the same kind of hack we have in Person to be an ITeam
[14:44] <sinzui> I thought that hack was using full_functionality with checks the celebrity
[14:45] <sinzui> ^ bigjools
[14:45] <bigjools> in this case I might not need to worry about this
[14:45] <bigjools> sinzui: yes, it does I think
[14:46] <sinzui> bigjools: Do you still intended to introduce IRemixDistribution so that projects like balitx do not get builds and translations
[14:46] <bigjools> sinzui: so everything is an IDerivativeDistribution unless it's Ubuntu?
[14:47] <sinzui> bigjools: That is it
[14:47] <bigjools> sinzui: I wasn't planning on changing that at all
[14:47] <bigjools> soyuz is quite happy
[14:48] <bigjools> well, once you add some series and architectures
[14:48] <bigjools> sinzui: See https://dogfood.launchpad.net/deribuntu/dangerous
[14:48] <sinzui> bigjools, ah understood
[14:50] <sinzui> bigjools: you may have an awesome blog post to do. You may be celebrated by  the 101 Ubuntu derivatives.
[14:50] <bigjools> sinzui: well, possibly.  This stuff is being done for Linaro and OEM
[14:51] <bigjools> the derivative management will only be available if you get explicitly allowed to use it
[14:52] <abentley> deryck: http://people.canonical.com/~abentley/translations-usage.png
[14:53] <sinzui> So a driver of baltix could create a series that is based on natty. The series will be added with everything that automatically happens with a new series, but features exposed in the derivative UI will not be available?
[14:54] <bigjools> sinzui: right - there's a separate initialisation phase that copies the packages from the parent
[14:54] <bigjools> sinzui: BTW I just made myself a driver on a non-ubuntu distro and the addseries link disappeared
[14:55] <bigjools> but it worked if I was a maintainer
[14:55] <sinzui> oh.
[14:55] <sinzui> dear
[14:56] <sinzui> I bet the link needs to be guarded by append. I recall the link was added back to the page in haste and admin/owner may have been used
[14:56] <bigjools> actually I should say, the link disappeared when took myself out of the maintainer positionb
[14:56] <bigjools> +addseries gives a 403 as well
[14:56] <sinzui> :(
[14:58] <bigjools> this is odd then, I own it and I am a driver.
[14:58] <bigjools> but I can't edit it
[15:01] <sinzui> bigjools: did rvba change permission after changes distro owner rules. Distro owner cannot edit  their distro because for Ubuntu, that was hundred of people. Only admins could change the distro
[15:02] <sinzui> bigjools: I am sure we had IDerivativeDistros permissions working.
[15:02]  * sinzui looks for tests
[15:05] <sinzui> bigjools: lp/registry/browser/tests/distroseries-views.txt shows drivers creating series
[15:05] <bigjools> hmmm
[15:05] <bigjools> sinzui: https://dogfood.launchpad.net/deribuntu
[15:05] <bigjools> check out the driver
[15:06] <bigjools> I own that team
[15:07] <bigjools> I cannot get to +addseries
[15:09] <sinzui> bigjools: the test is wacky. I see check_permission('launchpad.Driver', view)
[15:09] <bigjools> sinzui: ah!
[15:10] <sinzui> We expect launchpad.Append
[15:11] <jcsackett> danilos: do you have time to review https://code.launchpad.net/~jcsackett/launchpad/hardwaredb-should-ignore-bad-data/+merge/56472
[15:11] <jcsackett> a big part of the diff is just a new sample data file being added and some tests being moved.
[15:12] <sinzui> bigjools: ModerateDistributionByDriversOrOwnersOrAdmins is now lp.Moderate
[15:12] <bigjools> sinzui: one sec, OTP
[15:13] <al-maisan> sinzui: OMG .. that name was almost Java-level verbose ;)
[15:16] <sinzui> bigjools: so drivers, owners, and a admins can create series because they have lp.Moderate, but the views and links check lp.Append. We broke this last August when we tried to remove exceptional permissions. We may need to revert this if we find that we cannot fix the lp.Append guards on the link and view
[15:17] <sinzui> al-maisan: security.py likes to live dangerously close to the 78 character length limit
[15:17] <al-maisan> so I see
[15:19] <danilos> jcsackett, sure thing, I can handle one more review today :)
[15:19] <jcsackett> danilos: awesome. thanks. :-)
[15:22] <danilos> jcsackett, is it important for test data to be this big? can you not cause the same problem with a much smaller input file?
[15:23] <jcsackett> danilos: possibly; i cribbed that file from the "good" sample data file. almost all elements in the rng appear to be required. :-/
[15:23] <danilos> jcsackett, ok, fair enough
[15:23] <jml> ducking out to get coffee
[15:24] <danilos> jcsackett, I won't be looking at the file in detail then, but I suppose at least long comment sections like the one containing XXX can be removed :)
[15:25] <jcsackett> danilos: sure; i'll do what i can to clean it up.
[15:25] <jcsackett> danilos: currently, it's literally the "good" file with a single bad dmi section.
[15:26] <danilos> jcsackett, that'd be much clearer if the file was potentially constructed on-the-fly: copy the good one, change one entry
[15:26] <jcsackett> danilos: that's certainly a thought. i'll confess to laziness. i'll see about doing that.
[15:26] <danilos> jcsackett, iow, I don't like that there's a huge file without it being clear that there's one tiny little bit inside that _is_ important
[15:27] <jcsackett> danilos: dig. i can certainly see the objection.
[15:27] <danilos> jcsackett, if you just feel too lazy, perhaps just add a big comment at the top indicating more of what we discussed here (though, I certainly prefer a better solution :))
[15:27] <danilos> anyway, off to the code now
[15:27] <sinzui> bigjools: This is my summary of the permission issue https://pastebin.canonical.com/45750/
[15:28] <jcsackett> danilos: in order, i'll try: modifying the data on the fly; cleaning everything possible out of the file; adding a big comment.
[15:28] <danilos> jcsackett, excellent, thanks a bunch :)
[15:38] <danilos> jcsackett, btw, is _logError used anywhere where you'd still want it to record an OOPS?
[15:39] <jcsackett> danilos: it's used in several places. that's why by default it still creates the oops. to my knowledge, right now the one call site that's been modified to pass create_oops=False is the only place we want to supress it, but we may discover more.
[15:40] <danilos> jcsackett, ok, sounds good then, with a minimal test case for the context manager (so nobody breaks it in the future), r=me
[15:41] <jcsackett> danilos: dig. i'll add that.
[15:41] <danilos> jcsackett, thanks! it seems a useful feature, worth emailing the list about I'd say :)
[15:42] <jcsackett> danilos: cool. i'll do that once it lands. :-)
[15:43] <jml> back
[15:49] <bigjools> sinzui: right sorry, off TP now
[15:50] <bigjools> sinzui: I'm not sure the analysis is entirely right since when I visit addseries I get a permission error, so it's not just a UI issue.  Or is this because I am tripping up on the view?
[15:51] <bigjools> ooo a patch, I like those :)
[15:51] <sinzui> bigjools: no one has launchpad.Append, the permission was removed for distros...but Lp lets you still use it for links and views :(
[15:51] <bigjools> sinzui: argh :/
[15:52] <bigjools> I'll hack mawson and see what happens
[15:59] <sinzui> I see maps.ubuntu.com arrived 9 months too late
[16:04] <bac> hi sinzui, i'm trying to isolate a windmill test failure following the instructions at https://dev.launchpad.net/Windmill
[16:05] <bac> sinzui: trying to run a single test with 'bin/test --test=test_bug_commenting' finds 0 tests.
[16:05] <bac> has it changed?
[16:06] <sinzui> bac: I do not know  you can run a single js test. the setup I wrote created a single test suite for all the files in the directory
[16:06] <bac> sinzui: the above is the example from the wiki.  perhaps it never worked?
[16:07] <sinzui> bac: deryck[lunch] did the last round of revisions.
[16:07] <timrc> Either there is some latency, http://maps.ubuntu.com is broken, or my IP does not translate correctly but I'm not seeing an Ubuntu badge over Austin, TX
[16:07] <sinzui> bac: the magic has to be in the test harness class. it may be that some harnesses were updated
[16:07] <bac> sinzui: ok.  thought i'd try you since you're here.  i'll wait for him to return from lunch
[16:08] <bac> sinzui: i'm reading through the thread from yesterday now to see if there are clues
[16:10] <sinzui> timrc: i see a single badge over Austin in  http://maps.ubuntu.com/map/
[16:10] <timrc> sinzui: hm not I… but it may be someone else (as I just broadcast this :))
[16:11] <timrc> sinzui: other ip geolocating say they can't figure out where I am :/
[16:11] <bac> sinzui: why did you say the maps are 9 months late?
[16:12] <sinzui> bac: I mispoke. I was hoping Ubuntu would get a OSM map implementation. That is was I proposed. Instead it got a Google implementation
[16:13] <bigjools> sinzui: your fix worked
[16:13] <bac> sinzui: ah
[16:13] <sinzui> bigjools: \o/
[16:13] <bigjools> indeed!
[16:13] <timrc> they should accept postal codes as well ;)
[16:15] <bigjools> maps.u.c hopelessly gets my location wrong too
[16:15] <sinzui> bac: I see that test_bug_commenting is a real windmill test
[16:16] <bac> sinzui: yes
[16:16] <sinzui> bac: the windmill layer is disabled at the the moment, or at leas when I checked it yesterday
[16:17] <sinzui> bac: you need to specify both the layer and the test to convince the testrunner to run it
[16:17] <bac> sinzui: really?  i got ec2 failures for windmill tests last night
[16:17] <bac> oh, i see
[16:18] <sinzui> bac: bin/test has a windmill and mailman exclusion rule
[16:19] <sinzui> bac: i tried to remove the mailman exclusion rule yesterday and failed. I saw windmill also had the same rule
[16:20] <bac> thanks sinzui, this works:   bin/test --layer=BugsWindmillLayer --test=test_bug_commenting
[16:20]  * bac updates wiki
[16:20] <sinzui> bac: you can just use --layer=Windmill
[16:20] <sinzui> layer matching is pretty generous
[16:21] <bac> even better
[16:27]  * sinzui loves multi-touch love handles
[16:44] <jcsackett> sinzui: can i ask you to take a look at https://code.launchpad.net/~jcsackett/launchpad/set-question-message-visibility/+merge/56588? it's the retarget of the set-question-visibility work to devel instead of db-devel so i can get it out and working.
[16:44] <sinzui> jcsackett: I just looked at it
[16:45] <sinzui> I have nothing to say. I can just approve it now
[16:45] <jcsackett> sinzui: that works for me. :-)
[16:46] <jcsackett> thanks.
[17:21] <deryck> well that took forever
[17:22] <deryck> sinzui, bac -- did you guys solve your testing questions I see in the scrollback?
[17:22] <sinzui> deryck: yes
[17:22] <bac> deryck: yes
[17:22] <deryck> awesome
[17:22] <bac> the wiki was out-of-date...but no more
[17:23] <sinzui> deryck: ./bin/test excludes the windmill and mailman layer by default. They must be explicitly passed as an arg
[17:23] <bac> deryck: i do have another problem.  test_duplicate_finder is failing for me in my branch (where i did make a mod) but also in trunk
[17:23] <deryck> sinzui: this should be fixed now with wallyworld_'s recent landing
[17:24] <deryck> bac: and you're up to date on trunk?  With the changes wallyworld_ landed?
[17:24] <bac> yep
[17:24] <bac> deryck: it fails waiting forElement on the dupe search field
[17:25] <deryck> bac: you on Firefox 4?
[17:25] <bac> deryck: nope, 3.6.16
[17:25] <deryck> hmmm, ok.
[17:26] <bac> are we to avoid upgrading to 4?
[17:26] <deryck> bac: for Windmill yes.  wallyworld_ and I are still trying to work out something going wrong there.  See his mail.
[17:26] <bac> ok
[17:27] <deryck> bac: as for the test, I can't run it yet.  Still futzing with my natty upgrade.
[17:27] <bac> deryck: no good deed...
[17:27] <deryck> bac: you could paste me the error, though.  I can look at that and see if anything stands out.
[17:50] <bac> deryck those windmill tests are passing now.  go figure.  i'll take my chances with ec2.  time for a super-quick review?
[17:51] <deryck> bac: sure, hit me!
[18:10] <bac> deryck: i'm still waiting on the MP to show up
[18:10] <deryck> bac: no worries.
[18:15] <cody-somerville> Why is the text area for further information on the filebug page so small? :(
[18:22] <benji> so users of Chrome or Firefox 4 feel special when they resize it?
[18:24] <bac> deryck: https://code.launchpad.net/~bac/launchpad/bug-751397/+merge/56617
[18:24] <deryck> bac: thanks.  got it and looking at it now.
[18:24] <bac> thx
[18:24] <bac> deryck: i'm going to step out for a bit
[18:24] <deryck> bac: no worries.  I've got TL call top of the hour, so if I don't finish by then, I'll catch the rest after.
[18:51] <jml> hey, can anyone spot a bug in this script? http://paste.ubuntu.com/590375/
[18:52] <jml> manual inspection says 20 critical bugs were closed in the last week, the script says 17
[19:11] <benji> jml: this modification http://pastebin.ubuntu.com/590387/ gives me this output http://pastebin.ubuntu.com/590388/
[19:12] <jml> benji: interesting
[19:12] <benji> I'm trying to figure out what the deal is with the date_closed on those three.
[19:12] <jml> benji: why add 'not t.date_closed'?
[19:13] <benji> because the comparison fails otherwise (I'm in hack mode at the moment so don't hold me to that)
[19:13] <jml> benji: ok thanks. I'll explore some more :)
[19:14] <benji> also note that the script will take quite a while longer to run this way
[19:15] <jml> yeah.
[19:18] <benji> jml: the three bugs that have date_closed == None are all status:Invalid
[19:18] <jml> benji: are they old, too?
[19:19] <benji> jml: you could say that: 2005 and 2006
[19:19] <jml> benji: date_closed data isn't consistent in old bugs.
[19:37] <jml> benji: thanks for helping, very much appreciated.
[19:37]  * jml is off for the evening.
[19:37] <benji> glad to help
[20:12] <jcsackett> sinzui: can you take over #launchpad?
[20:13] <jcsackett> also: mumble, or is our two-man standup later enough?
[20:16] <deryck> bac: r=me on the js cleanup + addition tal condition branch.
[20:16] <bac> thanks deryck
[20:17] <bac> hey deryck, what woes are you having with natty in vm?
[20:17] <bac> you running vmware?
[20:17] <bac> i haven't tried it yet...
[20:17] <deryck> bac: no, parallels and parallels tools won't build against natty kernel.  So worse than 2d Unity experience.  Really crappy desktop experience without a suitable video driver.
[20:23] <lifeless> flacoste: https://lpstats.canonical.com/graphs/PPR/20100407/20110407/ is looking nice now
[20:28] <flacoste> lifeless: indeed
[20:31] <sinzui> sorry jcsackett. I have lost what little sense I had because of allergies and drugs
[20:31] <lifeless> sinzui: get well soon
[20:32] <sinzui> jcsackett: lets do our talk at 5:00 since it will only be U and I about at that time
[20:32] <jcsackett> sinzui: sounds good. and i hope your allergy season ends soon. i remember having terrible allergies when i lived up your way.
[20:32] <sinzui> lifeless: I think the plants should get a room if they want to get it on
[20:32] <lifeless> sinzui: amen
[20:35] <lifeless> jkakar: http://www.rfc-editor.org/rfc/rfc6202.txt may interest you
[20:58] <lifeless> flacoste: hi
[20:58] <lifeless> flacoste: we have /huge/ numbers of official bug tags for lp
[20:58] <flacoste> lifeless: we do
[20:58] <lifeless> flacoste: I'd like to zerg through and zap a tonne; any objection in principle? if not I'll assemble a list and mail -dev for specific objections
[20:59] <flacoste> lifeless: be my guest!
[20:59] <lifeless> thanks
[20:59] <lifeless> flacoste: also, have you seen how fast https://bugs.launchpad.net/ubuntu is? woot
[21:01] <flacoste> indeed :-)
[21:05] <lifeless> flacoste: https://dev.launchpad.net/PolicyAndProcess/PreReleaseQAProcess looks stale too
[21:05] <flacoste> lifeless: yes
[21:05] <lifeless> flacoste: or perhaps poorly named
[21:05] <lifeless> flacoste: carte blanche ?
[21:07] <flacoste> lifeless: sure, i'll watch the edits and review
[21:39] <jkakar> lifeless: Ooh, thanks.  I've added it to my "to-read" list. :)
[23:04] <lifeless> yay deleting old wiki pages
[23:09] <lifeless> flacoste: I'm done on the doc sweep; mailed you about some pages I couldn't decide on
[23:21] <lifeless> sinzui: hi
[23:22] <sinzui> hi lifeless
[23:24] <lifeless> sinzui: heya
[23:24] <lifeless> sinzui: I wanted to touch base and confirm my understanding that jcsackett will be continuing with a button to hide spam in the UI ?
[23:24] <sinzui> lifeless: One of us will be doing that.
[23:24] <lifeless> sinzui: \o/
[23:25] <poolie> hi all
[23:25] <sinzui> He is still exposing some of api goodness needed to support it :(
[23:25] <lifeless> sinzui: I am thrilled to confirm that; for some reason I had started to doubt my memory
[23:25] <lifeless> hey poolie