[00:00] <wgrant> cjwatson: How are we going to produce the C translations files?
[00:00] <wgrant> (also, your LongDescription interpretation is inverted, AFAICS)
[00:00] <cjwatson> C as opposed to en?
[00:00] <wgrant> Well, do we produce the ones it's going to look for by default?
[00:02] <cjwatson> inverted> oh bugger, you're right, silly inscrutable docs
[00:08] <cjwatson> apt-ftparchive defaults to writing to Translation-en, and mvo told me he'd just stop uploading -en in the i18n custom uploads.  But perhaps it ought to be C, or perhaps the client ought to be a bit smarter here ...
[00:09] <wgrant> Note that it is currently not possible to create these files with apt-ftparchive.
[00:09] <wgrant> From the manpage.
[00:09] <cjwatson> Not in my version
[00:10] <wgrant> Ahem. I was looking at carob accidentally.
[00:10] <wgrant> Indeed, natty's is a bit more encouraging.
[00:11] <cjwatson> hmm.  I wonder if this is going to need YA lucid backport though ...
[00:12] <wgrant> That stuff should be somewhat self-contained, if we want to convince mvo to backport the patch...
[00:12] <cjwatson> I'll discuss the question of using Translation-C with mvo.  At worst it would just be a matter of setting TreeDefault::Translation / Tree::blah::Translation
[00:13] <cjwatson> backporting the patch will happen
[00:13] <cjwatson> both mvo's manager and his tech lead want this :-)
[00:13] <wgrant> Heh
[00:13] <wgrant> Useful.
[00:14] <cjwatson> I'll fix the inversion.  Should I rename the database column as well?  I kind of like having the new column be False by default, though
[00:15] <cjwatson> so split_long_descriptions True => LongDescription "false"
[00:15] <wgrant> I'm not sure. Possibly include_long_descriptions defaulting to True would work...
[00:15] <wgrant> Hmmm
[00:16] <cjwatson> oh, there's default= in Bool
[00:17] <cjwatson> I'm OK with that if it seems less confusing
[00:17] <cjwatson> anything else from a first pass that I should sort out?
[00:19] <wgrant> cjwatson: Looks reasonable.
[00:25] <cjwatson> Cool, thanks.  I'll work on that tomorrow then
[00:25] <wgrant> Great!
[00:29] <wgrant> wallyworld_: Is your last comment in bug #803996 a regresion on qastaging?
[00:29] <_mup_> Bug #803996: person picker widget doesn't show link to unassign myself <disclosure> <exploratory-testing> <person-picker> <Launchpad itself:Triaged> < https://launchpad.net/bugs/803996 >
[00:29] <wallyworld_> wgrant: not sure if it's a regression
[00:30] <wallyworld_> but it pertains to that bug so i added it as a comment to ensure the full scope of the issue was fixed
[01:02] <wgrant> StevenK: How goes the vocab?
[01:09] <StevenK> wgrant: *RARGH*
[01:10] <wgrant> As expected!
[01:13] <lifeless> wallyworld_: should it hold up deploying?
[01:14] <wallyworld_> lifeless: not imho. it's a minor usability issue (page refresh fixes it) and i'm not even sure it's a regression
[01:14] <wallyworld_> i just noticed it doing some unrelated qa
[01:14] <lifeless> wallyworld_: then you might like to file a new bug for it, to fit the qa process
[01:15] <wallyworld_> lifeless: there's a bug already. i just augmented the bug details to provide extra info
[01:15] <lifeless> wallyworld_: but its the bug that will be closed when we deploy on thursday
[01:16] <lifeless> wallyworld_: if you land another incremental branch for it between now and then, we'll be unable to qa it, and the downtime deploy will get more hairy
[01:16] <wallyworld_> lifeless: ? the bug is associated with a kanban card that is in the todo list
[01:16] <lifeless> and... we're qa-bad for it now
[01:16] <lifeless> rev 13392 is broken
[01:17] <wgrant> I thought it would be.
[01:17] <wgrant> But where?
[01:17] <lifeless> compare https://launchpad.net/~launchpad-dev/+members and https://qastaging.launchpad.net/~launchpad-dev/+members and then click next in both on the 'active member' batch
[01:17] <wallyworld_> lifeless: bug 803996 is only triaged. that's the one i added the extra info for based on by observations when playing with qas
[01:17] <_mup_> Bug #803996: person picker widget doesn't show link to unassign myself <disclosure> <exploratory-testing> <person-picker> <Launchpad itself:Triaged> < https://launchpad.net/bugs/803996 >
[01:18] <wgrant> lifeless: Ah, indeed.
[01:18] <lifeless> wallyworld_: ah, cool
[01:18] <lifeless> wallyworld_: sorry for my confusion
[01:18] <wallyworld_> lifeless: np. it was well worh the question
[01:18] <wallyworld_> worth
[01:18] <lifeless> wgrant: the memo is not being adapted, so the memo for nav A is affecting the content for nav B
[01:18] <wgrant> Yup.
[01:19] <lifeless> frell
[01:19] <wgrant> Revert or fix?
[01:19] <lifeless> revert
[01:19] <wgrant> I think revert.
[01:19] <wgrant> Yeah.
[01:19] <lifeless> unknown number of instances
[01:19] <lifeless> wgrant: how would you feel if I asked you to do the honours ?
[01:20] <lifeless> I've been chasing emails and stuff so far today - I only just got to doing qa on this
[01:20] <wgrant> Like I've done that a bit too much in the last week, but okay.
[01:20]  * wgrant does it.
[01:20] <lifeless> I will dig up the MP and explain the situation on it
[01:21] <wgrant> I have 6 reversion branches in ~/launchpad/lp-branches :(
[01:21] <wgrant> :( conflicts
[01:21] <lifeless> in a .txt file
[01:22] <wgrant> Yeah
[01:22] <wgrant> Which is merged.
[01:22] <lifeless> its shallow - just keep the trunk version
[01:22] <lifeless> the change was from explicit url to ...
[01:22] <lifeless> but oh the pain - if it makes your eyes bleed, I will do it
[01:23] <lifeless> hmm
[01:23] <lifeless> the alternative is to not back this out
[01:23] <lifeless> lets talk through it for a second:
[01:24] <lifeless>  - for any given navigator, it will work to navigate it as long as you don't switch navigators half way through things
[01:24] <lifeless>  - multi-navigator pages are the exception
[01:24] <lifeless>  - and switching should be rarer still
[01:24] <wgrant> But if we revert now, we can deploy it on Friday and be able to easily revert if something goes wrong.
[01:24] <lifeless> so, what about filing a critical and rolling forward
[01:25] <wgrant> This change is scary and hard to verify completely.
[01:26] <lifeless> there may be other unintended side effects
[01:27] <lifeless> or this one may go deeper than thought
[01:27] <wgrant> We lose little by reverting it now.
[01:27] <wgrant> We gain flexibility.
[01:28] <wgrant> And, given the mess that the last 1.5 weeks have been, I think that is a good thing.
[01:29] <lifeless> I'm not worried about it landing later
[01:29] <lifeless> I was thinking about the headache of the reversion branch
[01:29] <lifeless> thats all
[01:30] <lifeless> wgrant: how fugly does the reversion look ?
[01:30] <wgrant> Not very. Just running the tests now.
[01:32] <lifeless> so bug batches look fine
[01:32] <lifeless> though 'Last' still times out (because the order reversing stuff is not yet hooked up to any lp batches)
[01:47] <wgrant> lifeless: Shall I land the revert?
[01:48] <lifeless> wgrant: it was fairly clean? if so yes.
[01:49] <Ursinha> !2
[01:49] <wgrant> I just --take-other on the story, and it passes fine.
[01:52]  * wgrant lands.
[01:54] <wgrant> Bah, forgot r-c
[02:14] <nigelb> 220?
[02:14] <nigelb> :(
[02:18] <lifeless> jtv: this may be fallout from red's current work - https://bugs.launchpad.net/launchpad/+bug/808950
[02:18] <_mup_> Bug #808950: DistroSeries:EntryResource:searchTasks AssertionError: wrong You exported name as an IChoice based on an SQLObjectVocabularyBase, you should use lazr.restful.fields.ReferenceChoice instead <api> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/808950 >
[02:19] <lifeless> jtv: I don't know if it is|isn't
[02:21] <lifeless> mpt: hi
[02:22] <lifeless> mpt: how would you feel if your transcribed talk was edited - treated as a live doc? E.g. where you give the example of having the word 'should', I would like to add 'add', 'remove', 'change', and perhaps more as other 'words to be wary of'
[02:51] <wgrant> wallyworld_: Around?
[03:09] <wgrant> lifeless: Can I add X-Lazr-OopsId headers to webapp OOPSes too?
[03:10] <wgrant> (to display less useless errors when pickers fail)
[03:11] <lifeless> wgrant: can you rename it?
[03:11] <wgrant> The other one is set in lazr.restful, I believe.
[03:11] <lifeless> wgrant: X-LP-OOPSID everywhere would make me happy.
[03:12] <wgrant> Sadly I guess clients may depend on it.
[03:12] <wgrant> And it is not overridable without lazr.restful changes.
[03:15] <lifeless> so there are I guess 3 q's
[03:15] <lifeless> can we add a header: absolutely
[03:15] <lifeless> should it be the same as the API one? I dunno
[03:15] <lifeless> does the name matter? not really, but X-LP-OOPSID is or even X-OOPSID would be a lot better
[03:17] <lifeless> wgrant: you could add whatever name and rename it later
[03:17] <lifeless> wgrant: I don't mean to inflae the work you have to do
[03:21] <wgrant> Grar
[03:21] <wgrant> I hate Soyuz.
[03:22] <wgrant> Stop deleting evidence.
[03:24] <lifeless> no sequitur ?
[03:25] <wgrant> Yes
[03:25] <wgrant> Soyuz will let you delete a publication multiple times.
[03:25] <wgrant> Each attempt will overwrite the last date.
[03:25] <wgrant> So I can't see what this user actually did to break their archive.
[03:33] <lifeless> https://dev.launchpad.net/LEP/FastDowntime for those liking 'agile'
[03:35] <wgrant> yay
[03:35] <poolie_> indeed
[03:44] <wgrant> poolie_: I'm pretty sure both frontends are broken mimetype-wise.
[03:44] <wgrant> poolie_: But not all of them have the bad data cached all the time.
[03:44] <wgrant> I've seen text/html from both.
[03:44] <lifeless> stub: hiya
[03:44] <stub> Hi
[03:45] <wgrant> poolie_: Indeed, there are logs in the bug to show it happening from both.
[03:46] <lifeless> stub: I'm just filing bugs for fastdowntime at the moment
[03:46] <stub> Cool.
[03:46] <lifeless> stub: Thanks for landing batchnav! however we've had to roll it back - found a corner case
[03:46] <lifeless> when we have two navs on one page the new variables need their name mangled
[03:47] <stub> I think the pgbouncer config on prod is setup, but waiting on pgbouncer installation on sourcherry to proceed. Silly losas think testing is a good thing or something!
[03:47] <spm> mad buggers
[03:47] <lifeless> spm: can we get it on sourcherry then ?
[03:47] <stub> We have 2 batchnavs on one page?
[03:47] <lifeless> stub: yeah - e.g. ~launchpad-dev/+members
[03:47] <stub> last I heard the rt was with stephan
[03:48] <lifeless> so its an easy fix, I commented in the MP
[03:48] <poolie_> wgrant, oh i see
[03:48] <spm> stub: installed
[03:49] <poolie_> that is easier to explain than having persistently different behaviour between what should be identical machines
[03:49] <stub> spm: And permissions on /etc/pgbouncer contents set so I can configure it?
[03:49] <spm> i assume at this stage we're not pulling pgbouncer into the lp-db-deps?
[03:49] <wgrant> poolie_: Yes. :/
[03:50] <wgrant> Perhaps we should go poking in squid caches or logs or something.
[03:50] <stub> spm: No. Maybe one day if the rollout script is tested with out test suite in the -dev packages.
[03:50] <spm> oki
[03:50] <lifeless> bbiab
[03:50] <spm> normally we object violently to 'install package' unless it's in the meta, but I'll let this ride for once.
[03:50] <spm> where violently == 4x2.
[03:50] <poolie_> wgrant, in that case it actually is a dupe
[03:50] <spm> where violently == 4x2/ip
[03:51] <wgrant> poolie_: I've already fixed that up :)
[03:51] <poolie_> thanks
[03:51] <stub> spm: I'm not fussed, but we will only need it installed on at most two machines so similar to haproxy.
[03:51] <poolie_> it occurred to me it would be interesting to have a losa look directly at the backend and see what it answers
[03:51] <stub> (+staging)
[03:51] <poolie_> presumably always the correct thing
[03:51] <wgrant> poolie_: We've never seen the backend return bad data.
[03:51] <wgrant> poolie_: But it possibly only does it in response to certain request headers.
[03:52] <spm> stub: have at it
[03:52] <poolie_> how would you know if the backend returned bad data?
[03:53] <wgrant> poolie_: With manual testing, this is.
[03:53] <poolie_> iow what i said has already been tried?
[03:53] <spm> stub: I'm not sure of your  meaning wrt machines similar to haproxy, wrt staging?
[03:53] <wgrant> poolie_: Yes.
[03:54] <stub> spm: At most, we want pgbouncer running on two production machines + staging, similar to our HAProxy dependency. So putting it in the -db meta package didn't occur to me.
[03:56] <stub> Probably more a puppet thing since it one package + several customized configs
[03:56] <spm> oh I see. right.
[03:58] <lifeless> whats the name of the codebrowse url mapper thingy?
[03:58] <stub> lifeless: Are you expecting me to sort the batch navigator branch or is it punted to a bugs team?
[03:59] <wgrant> lifeless: branch-rewrite
[03:59] <lifeless> stub: Its in limbo
[03:59] <lifeless> stub: a bugs team working on batch related timeouts would have motivation to do it
[03:59] <lifeless> stub: if you want to do it, be my guest; not expecting you to do so (or not to do so)
[04:00] <stub> lifeless: It is a dependency of a bug abel is assignedl
[04:00] <stub> I'll checkout the required work after breakfast.
[04:00] <lifeless> stub: I think abel should do it then, it should be pretty easy.
[04:01] <lifeless> but sure, EIDONTCARE :)
[04:02] <stub> I'm going to pull out our reliance of transaction-persistent cursors from garbo.py so we can run pgbouncer in transaction mode rather than session mode.
[04:03] <stub> Which is a bit sucky, as I thought that code was rather cool ;)
[04:03] <stub> Think I'll need to replace it with two connections to remain efficient.
[04:04] <lifeless> stub: it was cool, but I totally endorse that change
[04:06] <lifeless> stub: could we do a brief voice call ?
[04:07] <lifeless> stub: I want to check I didn't miss anything for round one of fast downtime
[04:07] <stub> Sure. I'll just plug stuff in.
[04:16] <lifeless> https://dev.launchpad.net/LEP/FastDowntime
[04:40] <lifeless> wgrant: has lazr.amqp had its non-longpoll expunged? ready for rename ?
[04:41] <wgrant> lifeless: It hasn't.
[04:42] <wgrant> I might look at that this afternoon.
[04:42] <lifeless> bug 809132
[04:42] <_mup_> Bug #809132: lazr.amqp is overly broad <longpoll> <lazr.amqp:New> < https://launchpad.net/bugs/809132 >
[04:56] <wallyworld_> wgrant: hi. i had to go out and sort out some car issues :-( back now
[04:58] <wgrant> wallyworld_: Was wondering how to mock out HTTP requests in the picker for unit testing.
[04:58] <wallyworld_> wgrant: we have about 3 different Y.io mocks
[04:59] <wallyworld_> the bugs js uses one style
[04:59] <wgrant> I saw MockIo, but it's only used in one place.
[04:59] <wgrant> Seems to be from lazr-js.
[04:59] <wallyworld_> there's also mickio.js brought across from lazr-js
[05:00] <wallyworld_> in other places, a js object is constructed with just the method (eg patch) that is to be patched implemented
[05:00] <wallyworld_> in most cases, the mock io object is passed to the js business logic
[05:00] <wgrant> pickerpatcher uses Y.io directly.
[05:00] <wgrant> I want to test the handling of errors.
[05:00] <wallyworld_> yes, see ^^^
[05:00] <wgrant> Ah
[05:01] <wallyworld_> the most common approach seems to be to pass an optional io object to the business lgoic
[05:01] <wallyworld_> if io[05:01] <wallyworld_> else use the mock
[05:01] <wallyworld_> there's implementations in out code base that allow the expected api call to be chacked and a return result to be provided
[05:02] <wallyworld_> if you search for IOStub you'll see some examples
[05:02] <wallyworld_> but I'd rather get a good, reusable implentation into our testing framework
[05:02] <wallyworld_> and have everything use that
[05:02] <lifeless> wgrant: where is longpoll deployment at?
[05:03] <wgrant> lifeless: Yes.
[05:03] <lifeless> would a bug be helpful ?
[05:03]  * lifeless makes one
[05:04] <wgrant> Possibly.
[05:07] <poolie> wgrant, huh, well spotted with the 304
[05:07] <poolie> that's pretty perverse
[05:07] <poolie> does it give you a body, or just the header?
[05:08] <wgrant> poolie: lifeless did the real diagnosis :)
[05:08] <wgrant> It just gives the header.
[05:09] <lifeless> ok, ciao
[05:15] <wgrant> Well, that lazr.amqp pruning was easy.
[05:15] <sidnei> poolie, hi!
[05:16] <poolie> hi sidnei
[05:17] <sidnei> poolie, i had a question about branch splitting earlier, not sure you saw it
[05:18] <poolie> hi
[05:18] <poolie> there is 'bzr split'
[05:18] <poolie> wgrant, couldn't it just not give a content-type header?
[05:20] <wgrant> poolie: Possibly very true.
[05:20] <sidnei> poolie, so after splitting a directory from the tree, does it get removed from the original tree or does that need to be done manually?
[05:21] <wgrant> "Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body."
[05:21] <wgrant> poolie: So, looks like we can omit it.
[05:21] <wgrant> Particularly since we have no entity-body.
[05:21] <wgrant> grarr
[05:21] <wgrant> Just ran into this bug when trying to build lazr.amqp :(
[05:23] <wgrant> Blah.
[05:23] <poolie> right
[05:23] <poolie> i thought it was normally omitted
[05:23] <wgrant> twisted.web.server.Request.process sets it to text/html at the start of the request :/
[05:23] <wgrant> So we'd need to delete it...
[05:23] <poolie> sidnei, you will then have one tree with the subdirectory excised, and underneath it another checkout with that tree present
[05:23] <poolie> hm that's a bit presumtuous
[05:24] <poolie> i guess it depends if you want to fix this in twisted or to work around it
[05:24] <wgrant> Would be nice to fix it in Twisted, but not sure how to do that in a backwards-compatible manner.
[05:25] <wgrant> Or we could just declare the existing behaviour broken.
[05:25] <wgrant> Perhaps.
[05:25] <poolie> 304 could perhaps just squash the ct
[05:25] <wgrant> Indeed.
[05:25] <poolie> it seems unlikely anyone would really want that behaviour
[05:25] <wgrant> Probably a good idea.
[05:28] <wgrant> A self.responseHeaders.setRawHeaders("content-type", []) after the self.setResponseCode(NOT_MODIFIED) seems to work sensibly.
[05:28] <wgrant> Is a little ew, though.
[05:29] <sidnei> twisted was designed with POMA in mind (as opposed to POLA - http://en.wikipedia.org/wiki/Principle_of_least_astonishment)
[05:29] <wgrant> Heh
[05:30] <poolie> sidnei, anyhow i suggest you at least try split
[05:30] <poolie> what are you going to want to do with these branches in future?
[05:31] <poolie> wgrant,  it should possibly be more general than just c-t and 304 but ...
[05:31] <poolie> this would be the main case i guess
[05:32] <sidnei> poolie, https://bugs.launchpad.net/graphite/+bug/501828
[05:32] <_mup_> Bug #501828: Create separate branches for the webapp, carbon, and whisper <Graphite:Triaged by chrismd> <Graphite 1.0:Triaged by chrismd> < https://launchpad.net/bugs/501828 >
[05:34] <sidnei> poolie, which, btw, is still using pack-0.92. guess it's time for upgrade :)
[05:36]  * wgrant stabs buildout in the eye.
[05:36] <wgrant> FASTER
[05:37] <StevenK> Haha
[05:38] <wgrant> lifeless: txamqplongpoll, maybe?
[05:51] <lifeless> wgrant: sure
[05:51] <lifeless> though txlongpoll is a bit snappier
[05:51] <wgrant> lifeless: It is, but it's also more generic.
[05:52] <wgrant> Although possibly reasonable.
[05:53] <lifeless> txhttpamqp ?
[05:54] <wgrant> That's even more syllables.
[05:54] <wgrant> Perhaps we should just do txlongpoll, as you say.
[06:19] <wgrant> Hmm.
[06:20] <wgrant> Maybe we should just run txlongpoll from a package.
[06:20] <wgrant> Since all its runtime deps are in main.
[06:21] <wgrant> Hm, no, python-txamqp is not in main, but it's in some PPA I have, but I can't think which.
[06:21] <wgrant> s/have/had/
[06:21] <wgrant> Must have been u1 or something.
[06:29] <lifeless> wgrant: no, because we can't sanely upgrade from packages (now, if ever)
[06:29] <wgrant> Bah.
[06:30] <spiv> danilos: bmp-inline-diffs has the wrong cursor for the expander link... it looks to me like perhaps the CSS needs to be adjusted so that .expander-node.js-action has the cursor:pointer style, or something like that?
[06:30] <spiv> danilos: or is there something my branch is missing?
[06:33] <lifeless> wgrant: we need to address that eventually, but I'd rather not put 'fix python packaging upstream' in our criticalpath
[06:34] <lifeless> wgrant: btw, has your revert landed ?
[06:35] <wgrant> lifeless: It passed buildbot 10 minutes ago.
[06:35] <lifeless> how are we on assessing 13391
[06:36] <wgrant> An indeterminate point between "handwave" and "kill me now"
[06:38] <wgrant> Ah.
[06:38] <wgrant> It says "Remove Person", when it shouldn't be talking about removing people and should be sentence case.
[06:38] <wgrant> I don't trust it any more.
[06:38] <wgrant> Tempting to revert.
[06:38] <lifeless> page?
[06:40] <wgrant> Any person chooser on a traditional form. eg. the bug supervisor field on https://launchpad.net/launchpad/+configure-bugtracker
[06:40] <wgrant> Or assignee on +filebug
[06:40] <lifeless> wallyworld_: ^ is that intentional ?
[06:41] <wallyworld_> i think so
[06:41] <wgrant> Sentence case looks and is wrong.
[06:41] <wgrant> "remove person" is a bit violent.
[06:41] <wgrant> But it seems to mostly work.
[06:41] <wallyworld_> it's config - it can be changed
[06:41] <lifeless> Person is wrong too
[06:41] <wgrant> s/Sentence/Title/
[06:41] <lifeless> (teams are not people outside of LP's schema :))
[06:42] <wallyworld_> it should say Remove Assignee for bug task pickers and whatever the default text is elesewhere (unless overridden)
[06:43] <wallyworld_> so i guess the default text is wrong plus some overrides are required
[06:43] <lifeless> oh, there is a regression
[06:43] <wgrant> I've just been reading the code so far.
[06:43] <lifeless> on https://qastaging.launchpad.net/launchpad/+configure-bugtracker
[06:43] <wgrant> What's the regression?
[06:43] <lifeless> go to the bottom - e.g. security contact
[06:43] <lifeless> click on 'Choose...'
[06:43] <wgrant> Hm.
[06:43] <wgrant> If you reopen it goes away.
[06:43] <lifeless> then click on the search widget (don't change the text)
[06:43] <lifeless> now try to remove the assignee
[06:44] <lifeless> however the regression is live on prod already
[06:44] <lifeless> so its not a new problem
[06:44] <lifeless> ah, except
[06:44] <lifeless> on prod if you reopen the picker
[06:44] <lifeless> you get the buttons back to remove assignee etc
[06:45] <lifeless> I have to run - can you two - wallyworld_ , wgrant - decide if this is really a regression or not, and revert or file a bug accordingly? cheers,
[06:45]  * lifeless goes
[06:45] <wallyworld_> that issue i am looking at now - the remove/pick me buttons not reappearing after a search
[06:45] <wallyworld_> it's not a regression
[06:45] <wgrant> wallyworld_: They also don't appear if you reopen the picker while the textbox is empty, AFAICT.
[06:45] <wgrant> It is very odd.
[06:46] <wallyworld_> they won't appear if a search has been done
[06:46] <wgrant> So, the UI text is pretty bad and needs fixing, but rolling back is expensive...
[06:46] <wallyworld_> it's not a regression, so rolling back won't help
[06:47] <wallyworld_> the issue was present in the original work john did afaict
[06:47] <wgrant> Which isn't a regression?
[06:47] <wallyworld_> the buttons disappearing
[06:48] <wallyworld_> after a search
[06:48] <wgrant> Ah.
[06:48] <wallyworld_> i have a simple fix for the disappearing buttons issue but writing a test is a bitch
[06:48] <wallyworld_> without any io stubs :-(
[06:48] <wallyworld_> the wrong Remove Person text is also not a regression
[06:48] <wallyworld_> i can'r recall when that branch landed
[06:49] <wgrant> It's currently "Remove assignee" on production.
[06:49] <wgrant> Which is correctly capitalised, and only questionably worded, not outright wrong :)
[06:49] <wallyworld_> Removee assignee everywhere?
[06:49] <wgrant> Yes.
[06:49] <wgrant> https://launchpad.net/launchpad/+configure-bugtracker
[06:50] <wallyworld_> ok. the branch that changed the wording was done to address a bug that said "Remove assignee" was wrong
[06:50] <wgrant> It's less than ideal.
[06:50] <wallyworld_> so it's wrong differently
[06:50] <wgrant> But "Remove Person" is doubly wrong.
[06:51] <wallyworld_> don't be a case nazi :-). we can live with "incorrect" case, no?
[06:51] <wgrant> It is terribly ugly.
[06:51] <wallyworld_> it's just the use of the word Person in cases where it's a team?
[06:51] <wgrant> That too.
[06:51] <wallyworld_> beauty is in the eye of the beholder
[06:51] <wallyworld_> i honestly can't see why this is such a showstopper
[06:52] <wallyworld_> it's easily fixed i'm sure
[06:52] <wgrant> Because I don't trust the branch and am looking for excuses to revert it.
[06:52] <wallyworld_> why don't you trust the branch?
[06:53] <wallyworld_> besides cosmetics, is there anything *functionally* wrong?
[06:54] <wgrant> Because I've had to revert it once already, along with 6 other things in the last week, it uses string concatenation to create HTML, the text is wrong, there are underlying bugs with the previous branch that aren't yet resolved, suggesting everything is more fragile than we can imagine...
[06:55] <wallyworld_> there was one reverted due to a true/True issue but this is a different branch now afaik. the concat and etc and text don't warrent a rollback. they can be fixed
[06:56] <wgrant> This is a relanding of the true/True issue branch.
[06:56] <wallyworld_> not exactly - it also has other stuff in there if i am correct
[06:57] <wgrant> Sure.
[06:57] <wgrant> But it is a superset of the branch that was rolled back.
[06:57] <wgrant> + fixes
[06:57] <wallyworld_> yes, believe so
[06:58] <wallyworld_> so we have 3 outward facing issues - text, wording and the disappearing buttons issue.
[06:58] <wallyworld_> disappearing buttons i have a fix for but need to figure out what effort i should expend writing the %@^!$ test without a io stub
[06:59] <wallyworld_> the text case is ugly but cosmetic
[06:59] <wallyworld_> the wording is unfortunate and we can land a fix quickly
[06:59] <wgrant> (three *known* outward facing issues, but OK)
[07:00] <wallyworld_> i don't think any others have come up so far?
[07:00] <wgrant> Right, so any other problems are as-yet unknown.
[07:00] <wallyworld_> there's only a finite number of use caases to check
[07:00] <wgrant> lol
[07:00] <wallyworld_> where finite is not that large
[07:01] <wallyworld_> i mean in terms of how pickers are wired up
[07:02] <wallyworld_> rather than actual instances on all lp pages
[07:26] <jtv> lifeless: hi.  That API bug you ran into looks like a Bugs problem, not apparently related to our derivation work.
[07:32] <wgrant> jtv: You haven't been playing with distroseries vocabs at all?
[07:33] <jtv> hi wgrant: you're talking about that Bugs API problem?
[07:33] <wgrant> jtv: Yeah.
[07:33] <wgrant> It looks like it may be a distroseries vocab change, which rvba has been touching a bit lately IIRC.
[07:34] <jtv> I think so, yes
[07:59] <adeuring> good morning
[08:01] <mrevell> Bom dia
[08:07] <wgrant> I think I almost understand buildout!
[08:15] <wgrant> bigjools: Morning.
[08:15] <bigjools> morning wgrant
[08:16] <StevenK> wgrant: Are we deployable *now*?
[08:16] <wgrant> StevenK: Has qastaging updated?
[08:16] <wgrant> bigjools: lazr.amqp is to be torn apart and renamed.
[08:16] <StevenK> qas is running r13405
[08:17] <wgrant> As we don't use anything except for lazr.amqp.async
[08:17] <wgrant> lifeless suggests deleting everything else and renaming to txlongpoll
[08:17] <bigjools> dramatic
[08:23] <wgrant> Yay, batchnav is no longer broken.
[08:24] <wgrant> We may be deployable.
[08:24] <wgrant> If we are very lucky.
[08:54] <stub> Did batchnav get fixed or are you talking about the rollback?
[08:55] <wgrant> stub: The latter.
[08:57] <stub> wgrant: Nah. Never seemed worth the trauma or load.
[09:15] <lifeless> jtv: its a bugs call, but it looks like a distroseries thing
[09:15] <jtv> lifeless: yes — you could ask le stigue if his vocab work might have played a role, but he's unavailable today.
[09:18] <jtv> lifeless: the method smelled like IHasBugTasks.
[09:18] <lifeless> sure, I was just grabbing the closest red teamer :)
[09:18]  * jtv wonders idly what connotations "red teamer" might have in English
[09:19] <jtv> Still, probably safer than "scarlet brigade."  That sounds positively filthy.
[09:19] <lifeless> night night
[09:19] <jtv> night!
[09:35] <danilos> adeuring, hi, I suppose you don't want to finish reviewing https://code.launchpad.net/~danilo/launchpad/replace-expanders-2/+merge/67314 and I should reassign back to lp-reviewers?
[09:35] <adeuring> danilos: sure, I can do it
[09:46] <danilos> adeuring, cool, thanks (I've fixed the problem with the focus event, should be fine now)
[09:46] <adeuring> danilos: yes, I already noticed it!
[09:47] <danilos> adeuring, yeah, the problem was not fixing the issue, but keeping the keyboard focus behaviour :)
[09:48] <adeuring> dar=me (had to raid my desk to find my notes from friday ;)
[09:50] <adeuring> danilos: r=me
[09:50] <danilos> adeuring, cool, thanks
[10:03] <wgrant> allenap, bigjools: Any objections to the pruning, renaming, and removal from LP?
[10:03] <bigjools> wgrant: of amqp?
[10:03] <wgrant> bigjools: Yes.
[10:04] <bigjools> no
[10:04] <wgrant> Thanks.
[10:04] <mpt> lifeless, I'm not sure how I feel about others editing it, but it's quite short, so perhaps there could be a Comments/Discussion section underneath? W.r.t. "add"/"remove"/"change", really any imperative summary falls into that category ("Make this work this way"). Excellent for issues classed as to-dos, not so good for issues classed as defects.
[10:04] <wgrant> I have a deployment strategy now too.
[10:09] <StevenK> wgrant: For lazr.whatevernameyoupicked or LP itself?
[10:09] <wgrant> StevenK: txlongpoll (née lazr.amqp)
[10:11] <bigjools> wgrant: what's the "tx" bit?
[10:11] <wgrant> bigjools: Twisted extensions
[10:11] <wgrant> https://launchpad.net/tx
[10:11] <bigjools> ...
[10:12] <bigjools> is it moving out of lazr?
[10:12] <wgrant> That's apparently the plan.
[10:12] <bigjools> k
[10:12] <wgrant> It is de-Zoped and now entirely twisted.
[10:13] <bigjools> https://launchpad.net/txamqp
[10:13] <bigjools> arf
[10:13] <wgrant> txamqp is the AMQP library it uses.
[10:13] <bigjools> yeah
[10:13] <bigjools> which begs a question ...
[10:13] <wgrant> Oh?
[10:13] <bigjools> WTF didn't anyone think to use tx-something in the first place!
[10:13] <wgrant> Well, it had all the Zopey crap in it initially.
[10:13] <bigjools> where anyone == landscape guys
[10:14] <wgrant> Ah
[10:14] <bigjools> anyway, all's well
[10:15] <wgrant> I also now understand buildout.
[10:15] <wgrant> Which is handy for this sort of thing.
[10:21] <al-maisan> is anything special going on at present? I am trying to add a tag to https://bugs.launchpad.net/openquake/+bug/803419 but launchpad will not let me
[10:21] <_mup_> Bug #803419: permission denied for relation geography_columns <database> <OpenQuake:Confirmed> < https://launchpad.net/bugs/803419 >
[10:22] <bigjools> yes, something Is Bad
[10:23] <al-maisan> also, when I refresh the bug page it will say "Log in/Register" although I *am* logged in..
[10:23] <StevenK> al-maisan: You're not anymore
[10:23] <StevenK> The session DB was just ... cleansed
[10:24] <al-maisan> how interesting ;)
[10:24] <StevenK> Ah no, we do have an issue
[10:24] <StevenK> al-maisan: Wait a few?
[10:24] <al-maisan> sure
[10:32] <wgrant> al-maisan: Should be OK now, if you log in again.
[10:32] <al-maisan> wgrant: thank you!
[10:32] <wgrant> The session DB switch was a little more troublesome than expected.
[10:33] <danilos> mrevell, hey, I wonder if I should say things like "they is" for the "singular they" :P
[10:33] <al-maisan> I was able to add the tag FWIW .. thanks again !!
[10:33] <danilos> mrevell, also, are we seriously on British English for LP?
[10:35] <mrevell> danilos, Singular they is perfectly acceptable English :) As for British English ... well ... maybe this needs more discussion on the list but the company standard is British English and we are rebranding LP to fit more in line with the company brand.
[10:35] <wgrant> Canonical code seems to be American English, while our text seems to be British English... I don't know why we'd use American anywhere :/
[10:35] <mrevell> For a long time, I think the interface text was a case of personal choice, then we settled on a policy of American English (I forget the reasons why) but for a couple of years now our company policy has been explicitly to use British English.
[10:36] <danilos> mrevell, "they is" sounds very weird to me, but then again, my English is better than yours :P
[10:36] <jpds> There's.... a singular they?
[10:37] <danilos> mrevell, should we make use of the scripts different en_GB teams have to switch the hood to the bonnet across the board?
[10:37] <mrevell> danilos, Oh, I thought you were joking. Singular they still takes "are". It's a compromise. It's better than using "he" everywhere, it's also better than using "she" every now then as a token effort.
[10:37] <mrevell> danilos, Such scripts exist?
[10:37] <danilos> mrevell, right, I was joking but I didn't realise you were as well :)
[10:37] <mrevell> haha
[10:38] <danilos> jpds, a recent invention, I am sure :)
[10:38]  * mrevell goes to find the Oxford Style Manual
[10:38] <bigjools> can we please nuke the Oxford Comma from orbit?
[10:38] <danilos> mrevell, good excuse to be gone for hours, good luck and enjoy the beer :)
[10:38] <nigelb> On a positive note, we'll have lots of "How do I fix the color for that box?" "Add a u"
[10:38] <mrevell> It was right next to me. I'm just finding the right page.
[10:38] <henninge> Is there such a thing as a "webservice console"
[10:38] <henninge> ?
[10:39] <henninge> I mean a script that uses launchpad lib to query the webservice for testing?
[10:40] <danilos> henninge, I've seen it mentioned a few times, if there is, it's probably hosted as a project on LP :)
[10:40] <danilos> henninge, perhaps lpshell by poolie
[10:40]  * henninge looks
[10:41] <poolie> henninge, there is a gui client in wrested
[10:41] <poolie> and there is lpshell in lptools
[10:41] <poolie> it depends what specifically you want to do
[10:42] <henninge> poolie: lpshell sounds like what I am looking for. Thanks
[10:44] <henninge> poolie: only there is no lpshell in lptools
[10:44] <maxb> henninge: lp-shell
[10:44] <maxb> oh, and ubuntu-dev-tools
[10:48] <mrevell> danilos, Basically, singular they, otherwise known as "generic they" has been used in English for hundreds of years. The alternative is to use generic "he", which is nowadays unacceptable for appearing to refer to one gender only (rather than being used in place of a neuter). From what I've read over the years, dislike of singular they appears to be an American hang-up.
[10:49] <wgrant> poolie: Thanks for forwarding that.
[10:50] <danilos> mrevell, oh, that's nice, I've only seen increased use of it in the last few years in the day-to-day communication (I've seen it used in literary works from way past)
[10:51] <poolie> +1 to they
[10:51] <poolie> s//hooray for they
[10:51] <mrevell> danilos, I think it's used increasingly as a way to avoid any unintended gender bias. I think it works well for that and it's a bonus that Shakespeare used it.
[10:51] <mrevell> heh
[10:51] <mrevell> :)
[10:51] <danilos> mrevell, anyway, what I was trying to say with the comment was that you may want to explain that "singular they" is still used with "are" for those non-English developers such as me, just so we don't have to think twice :)
[10:52] <danilos> mrevell, I used to use "they" just as if it were the plural they, so the term "singular they" confused me
[10:52] <mrevell> danilos, Ah, thanks, yes.
[10:53] <mrevell> danilos, I shall change it to "generic they" and give a usage example.
[10:53] <wgrant> jml: What is https://blueprints.launchpad.net/lazr.amqp/+spec/silly-blueprint?
[10:53] <danilos> mrevell, cool, thanks
[10:53] <henninge> danilos, maxb, poolie: lp:ubuntu-dev-tools/lp-shell is what I was looking for. Thanks!
[10:54] <poolie> mrevell, the more examples actually taken from lp text, the better, imo
[10:56] <mrevell> poolie, Cool. I'm always tempted to use "That and a pair of testicles" as an example of what we're trying to move away from.
[10:56] <wgrant> Has that been removed yet?
[10:56] <mrevell> But, yeah, I'll use some real world examples. Any suggestions gratefully received :)
[10:56] <wgrant> I recall its abolition was considered a couple of years back.
[10:57] <mrevell> wgrant, Yeah, it went quite a long while back AFAICR>
[10:57] <mrevell> s/>/.
[10:57] <wgrant> Good, good.
[10:57] <poolie> mrevell, that is a perfect example
[10:58] <poolie> i might have even excised them
[11:02] <mrevell> poolie, I'm probably missing something but I'm not sure I understand the problem with "Read about uploading"-style links.
[11:02] <mrevell> Can you help me understand?
[11:02] <poolie> i will try
[11:03] <poolie> should it be "Tell me about uploading" or "Read about uploading"?
[11:03] <poolie> it's not a critical bug
[11:03] <poolie> it just kind of sticks out to me as possibly inconsistent
[11:03] <poolie> or should it be "Help on uploading"
[11:04] <mrevell> Oh, I see.
[11:04] <poolie> the question is, is it just a noun phrase describing what's at the end of the link, or is either lp or the user the subject of an imperative
[11:06] <mrevell> I think that in line with mpt's guidance "As a user, you interact with the control, so it speaks as your voice", it should be "Tell me about..." The imperative seems to make the link more personal; maybe even friendlier.
[11:07] <poolie> right, though perhaps "tell me about" is verging on too cute
[11:08] <poolie> but i think the essential thing is that most hyperlinks, as opposed to buttons, don't have verbs at all
[11:08] <poolie> (is this true?)
[11:09] <mrevell> poolie, We have "Report a bug", "Ask a question" etc as hyperlinks, rather than buttons.
[11:10] <mrevell> So, if there is a tendency not to have verbs in links then we don't have it as rule, I'd say.
[11:10] <poolie> yeah, i was just thinking that
[11:11] <poolie> we have a weak pattern of links that appear in button-like places being phrased more like actions, and those that appear in text being more like real hyperlinks
[11:11] <mrevell> We tend to use a verb, I think, where there's a definite action, rather than just a request to list information.
[11:11] <mrevell> s/definite action/something that changes data
[11:11] <poolie> right, perhaps that's the rule
[11:12] <poolie> that it shouldn't be "Tell me about blah" or "show blah" or "list blah"
[11:12] <poolie> maybe there's even a rule for that?
[11:13] <mrevell> I don't think it's a written rule. I'll trawl the dev wiki and elsewhere for anything else and attempt to bring it all together. I'm also going to go read up on what other people have done with the wording of help links :)
[11:13] <poolie> ok
[11:14] <poolie> i don't want to cause people to get stuck on that particular question
[11:15] <mrevell> I think it's an interesting point though and I bet other people have handled it in ways that we can borrow.
[11:17] <poolie> there are probably a lot of other style guides that cover it
[11:18] <poolie> it seems like the current wording page assumes that only buttons are actions, which is not ture
[11:20] <danilos> mrevell, btw, you should talk to en_GB people about the script, I am sure they have a few handy
[11:22] <mrevell> danilos, Cheers. Do you have an idea of who I should speak to?
[11:23] <danilos> mrevell, http://live.gnome.org/BritishEnglish is a good starting point (there's a script there as well)
[12:17] <jml> wgrant: you noticed my attempt to get top contributor :)
[12:17] <wgrant> jml: Heh
[12:17] <wgrant> Then I turned off blueprints.
[12:19] <jml> good thought.
[12:23] <benji> flacoste: I think lp:~benji/launchpad/bug-781600 is ready for you to look at; do you want to do a formal review or an informal one?
[12:44] <cjwatson> OK, how do I sign files in lib/lp/archiveuploader/tests/data/suite/?  The existing ones are signed with key ID 6C64A8C5, and I *know* I've done this before but I can't remember how.  I've found lib/canonical/launchpad/ftests/gpgkeys/foo.bar@canonical.com.sec, but it has a password I don't know, and lib/canonical/launchpad/ftests/gpgkeys/foo.bar@canonical.com-passwordless.sec has a different key ID.
[12:45] <cjwatson> lib/lp/archiveuploader/tests/data/secring.gpg looked plausible but doesn't contain this key.
[12:53] <cjwatson> that's confusing, the last time I did this apparently I got it from lib/canonical/launchpad/ftests/gpgkeys/ - but where did I get the passphrase?
[12:53] <henninge> which script do I need to run on dev to create a diff for a merge proposal?
[12:54] <cjwatson> bigjools,wgrant: do either of you know the answer to my gpg question?
[12:54] <bigjools> cjwatson: the password is "test"
[12:55] <bigjools> IIRC
[12:55] <wgrant> That is also my recollection.
[12:55] <bigjools> NFI why someone decided it was a good idea to add a password
[12:55] <cjwatson> aha!  thank you
[12:56] <bigjools> henninge: run_jobs in the right job source
[12:56] <cjwatson> (I'm fixing up dpkg-xz-support)
[12:56] <bigjools> I forget the name but you have powers to find out :)
[12:57] <henninge> bigjools: thanks, looking
[12:58] <bigjools> henninge: there's a mergeproposaldiffpreview or similar
[12:58] <bigjools> job, I mean
[12:58] <wgrant> henninge: make sync_branches
[12:58] <wgrant> Or cronscripts/mergeproposaljobs.py
[12:58] <wgrant> Or you could run the job directly, but I don't know if that actually works these days.
[12:59] <bigjools> ah that's it
[13:00] <henninge> wgrant: cronscript/merge-proposal-jobs does not do it, neither does make sync_branches :(
[13:00] <wgrant> henninge: We found during the sprint that some occasionally got stuck somehow... perhaps the job has failed?
[13:00] <wgrant> Try resubmitting or deleting and recreating.
[13:03] <bigjools> ok I can't stare at this issue any longer, I need help.  What are the usual reasons a security adapter is not called?
[13:03] <wgrant> bigjools: The object is not proxied.
[13:03] <wgrant> Diff?
[13:03] <bigjools> it is
[13:04] <bigjools> http://pastebin.ubuntu.com/642617/
[13:04] <bigjools> I am fixing an existing problem I found when realising a permission test was in the zopeless layer
[13:05] <bigjools> makePlainPackageCopyJob() is returning a proxied object
[13:06] <wgrant> Does test_extendMetadata_is_privileged still pass?
[13:07] <bigjools> not any more
[13:07] <bigjools> that's the one that was in the zopeless test layer
[13:07] <bigjools> it only passed because the zcml was fucked
[13:07] <wgrant> Hmm. Possibly relevant is that your adapter is for IPackageCopyJobEdit. It should normally be for IPackageCopyJob, but that's hopefully not what's breaking this.
[13:07] <bigjools> ah...
[13:07] <wgrant> It's still odd and should be fixed.
[13:08] <bigjools> let's see
[13:09] <bigjools> didn't fix it, no
[13:09] <wgrant> Try the adaption manually, and see if gets the right adapter?
[13:11] <bigjools> I can't remember the runes
[13:12] <wgrant> Let me see.
[13:12] <bigjools> sleep deprivation does that
[13:13] <wgrant> I've been up since 3am :)
[13:13] <wgrant> (Pdb) queryAdapter(pcj, IAuthorization, name='launchpad.Edit')
[13:13] <wgrant> <canonical.launchpad.security.EditPackageCopyJob object at 0xeff4c90>
[13:16] <bigjools> ta
[13:17] <bigjools> so that worked, but ... :/
[13:17] <wgrant> It's really like it's running with PermissiveSecurityPolicy...
[13:19] <bigjools> yes
[13:19] <bigjools> the zcml looks ok though
[13:20] <gary_poster> flacoste, https://bugs.launchpad.net/launchpad/+bug/775691 : should we contact david planella with danilos's analysis or should we treat the migration as escalated?  danilo says the migration will be pretty tough, and there are workarounds
[13:20] <_mup_> Bug #775691: Empty translations on one side do not get translated by the other side <escalated> <not-pie-critical> <upstream-translations-sharing> <Launchpad itself:Triaged by yellow> < https://launchpad.net/bugs/775691 >
[13:24] <wgrant> bigjools: Ahahahah
[13:25] <wgrant> bigjools: It's a PlainPackageCopyJob, not a PackageCopyJob.
[13:25] <bigjools> :/
[13:25] <wgrant>     <!-- PlainPackageCopyJob -->
[13:25] <wgrant>     <class class=".model.packagecopyjob.PlainPackageCopyJob">
[13:25] <wgrant>       <allow interface=".interfaces.packagecopyjob.IPackageCopyJob" />
[13:25] <wgrant>       <allow interface=".interfaces.packagecopyjob.IPlainPackageCopyJob" />
[13:25] <wgrant>     </class>
[13:26] <bigjools> of course - it's bloody delegating
[13:26] <bigjools> gnargh
[13:26] <bigjools> thanks wgrant
[13:26] <cjwatson> Hmm, I'm trying to fix my dpkg-xz-support branch and getting very confused about tests.  I have a testXZDebUpload test defined right after testLZMADebUpload, and basically cargo-culted from it.  testLZMADebUpload tests for package uploads in the NEW queue, so I did the same in testXZDebUpload.  But apparently the upload ends up in ACCEPTED instead, suggesting that something isn't being torn down properly.  How do I get ...
[13:26] <cjwatson> ... rid of the stale state from the previous test?
[13:26] <cjwatson> this is in lib/lp/archiveuploader/tests/test_uploadprocessor.py
[13:27] <bigjools> cjwatson: it's likely to be the upload policy, not test isolation
[13:27] <cjwatson> wouldn't the same policy apply to both lzma and xz uploads?
[13:28] <bigjools> paste a diff
[13:28] <wgrant> cjwatson: You're sure you cloned the right upload?
[13:28] <wgrant> All DB state should be reset between tests, unless scripts are doing something bad.
[13:28] <bigjools> it's probably a package with ancestry
[13:28] <cjwatson> I *think* so ...
[13:28] <bigjools> so gets auto-accepted
[13:28] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/dpkg-xz-support-619152/+merge/32868
[13:29] <cjwatson> er, bollocks, that's stale, one moment
[13:37] <cjwatson> bigjools: the MP's being slow to update, but http://paste.ubuntu.com/642636/ is my current diff against devel
[13:41] <flacoste> benji: i'll do a formal one
[13:42] <flacoste> gary_poster: let's leave that decision to david
[13:42] <benji> flacoste: cool, in that case I'll write up an MP and ping you when it's ready
[13:42] <flacoste> benji: great
[13:42] <cjwatson> oh, yes, and it doesn't look like test isolation because 'bin/test --pdb -t lp.archiveuploader.tests.test_uploadprocessor.TestUploadProcessor.testXZDebUpload' shows the same thing
[13:42] <bigjools> cjwatson: the one in accepted will be the source
[13:43] <gary_poster> flacoste: ack will do
[13:43] <bigjools> cjwatson: looks like a genuine upload failure
[13:44] <bigjools> check what processUpload returns
[13:44] <cjwatson> Aha.  Is the upload log left anywhere, or do I just need to pdb it?
[13:44] <bigjools> it probably gets cleaned up unless you can see something hiding in /tmp
[13:45] <bigjools> I'd pdb it
[13:46] <cjwatson> OK, thanks
[13:57] <cjwatson> SystemError: "E:This is not a valid DEB archive, it has no 'data.tar.gz', 'data.tar.bz2' or 'data.tar.lzma' member"
[13:57] <cjwatson> We need an apt backport too, it seems :-(
[14:21] <bigjools> cjwatson: bugger
[14:29] <benji> flacoste: ok, the MP and MP-inspired polishing is done: https://code.launchpad.net/~benji/launchpad/bug-781600/+merge/67704
[14:31] <bigjools> cjwatson: heh, that point was raised in April on the MP as well
[14:33] <cjwatson> bigjools: that was python-apt, and I'm testing with that
[14:33] <cjwatson> but there's a bit of relevant code in apt too
[14:33] <bigjools> ah ok, thought you meant the former
[14:55] <flacoste> benji: i'll probably only review after lunch
[14:55] <benji> sounds good
[15:34] <henninge> adeuring: I found the error cause.
[15:34] <henninge> adeuring: it is not revision ids.
[15:35] <adeuring> henninge: cool, what was the problem?
[15:35] <henninge> adeuring: diffstat is defined as a Text field but it contains a dict.
[15:35] <henninge> {u'__init__.py': (1, 0)}
[15:35] <adeuring> henninge: argh...
[15:36] <henninge> adeuring: the standard marshaller applies a blanket unicode cast to all values.
[15:36] <henninge> so it becomes u"{u'__init__.py': (1, 0)}"
[15:36] <adeuring> henninge: interesting... I'm wondering why nobody noticed this before in API applications...
[15:37] <henninge> adeuring: as I said, it simply converted to unicode which our marshaller doesn't do
[15:37] <henninge> I guess nobody ever used this particular value
[15:38] <adeuring> henninge: right, seems so
[15:38] <henninge> adeuring: I have to leave now, I will think about a proper fix tomorrow.
[15:38] <henninge> probably just do the same thing ...
[15:38] <adeuring> henninge: schönen feierabend
[15:38] <henninge> danke
[17:08] <jtv> Nobody here to review https://code.launchpad.net/~jtv/launchpad/bug-809211/+merge/67731 ?
[17:14] <jml> jtv: tl;dr. sorry.
[17:18] <m4n1sh> is valc-0.14 actually vala git HEAD?
[17:18] <m4n1sh> s/valc/valac
[17:18] <m4n1sh> sorry
[17:18] <m4n1sh> wrong channel
[17:18] <m4n1sh> oops
[17:24] <jml> cross-posted from canonical/#tech, is there a way of using virtualenv without it downloading packages from the internet all the time?
[17:26] <jml> gary_poster: you know about this stuff, right?
[17:27] <jcsackett> jml: as in someone wants to use virtualenv and locally install eggs themselves?
[17:28] <jml> jcsackett: yeah. I've got the eggs from *previous* runs of virtualenv, and sometimes like creating new branches and hacking on them without internet access.
[17:28] <gary_poster> jml, somewhat.  Making a new virtualenv without downloading packages might or might not be supported.  Once it is installed,
[17:28] <gary_poster> I'm pretty sure that setuptools/distribute allows you to specify where to look for eggs
[17:28] <gary_poster> buildout uses those options itself
[17:29] <gary_poster> I'm not sure what those options are, but that's where I'd start
[17:29] <jml> gary_poster: ok, thanks.
[17:29] <gary_poster> np
[18:19] <flacoste> sinzui: http://approvaltests.sourceforge.net/
[18:32] <flacoste> sinzui: pycharm includes image diff support in 1.5, so would probably be possible to have good tool support there
[18:32] <sinzui> :)
[19:27] <lifeless> morning
[19:30] <nigel> already? Unfair!
[19:31] <lifeless> nigel: happens like clockwork
[19:33] <nigel> heh
[19:40] <lifeless> flacoste: ping
[19:56]  * abentley finds it depressing that "[] !== []" in JavaScript.  Also finds !== depressing.
[19:57]  * maxb blinks, and cries
[19:57] <maxb> seriously, wtf?
[19:58] <maxb> Oh, because Array does define sensible equality :-/
[19:58] <jtv> In python, "[] is []" also evaluates to false.  Makes sense to me.
[19:58] <cjwatson> !== is object identity rather than equality IIRC
[19:59] <jtv> That's right.
[20:00] <nigel> Isn't !==, the not of [20:01] <abentley> cjwatson, jtv: No, ![20:01] <nigel> s/equality/identity
[20:01] <cjwatson> oh dear god how many operators
[20:01] <cjwatson> and I'm speaking as somebody who likes writing perl
[20:02] <flacoste> hi lifeless
[20:02] <flacoste> benji: i sent you a bunch of comments on your branch
[20:03] <benji> flacoste: thanks, I'm looking at them now
[20:03] <flacoste> benji: let me know if there is anything confusing in them
[20:03] <lifeless> flacoste: I forgot to ask you about my emeritus idea on the call yesterday
[20:03] <abentley> cjwatson: I tell a lie.  You are correct.  However, [] != [] too.
[20:03] <benji> flacoste: on first reading everything looked good
[20:03] <flacoste> lifeless:  i liked it!
[20:04] <lifeless> I'll take it to -dev ?
[20:05] <lifeless> maxb: btw, I think that duping you did is incorrect
[20:05] <lifeless> maxb: before I undo it, can you explain why they are dupes?
[20:05] <maxb> The merged proposed team membership?
[20:06] <maxb> It seemed like both bugs were complaining about being unable to operate on merged proposed team members
[20:06] <lifeless> bug 204002 is about proposals after doing  amerge
[20:06] <_mup_> Bug #204002: can't approve/decline a member with a merged user <404> <lp-registry> <merge-deactivate> <Launchpad itself:Triaged> < https://launchpad.net/bugs/204002 >
[20:06] <lifeless> bug 393914 is about actual membership after a merge
[20:06] <_mup_> Bug #393914: ~team membership of ~X-merged can not be deactivated <404> <canonical-losa-lp> <lp-registry> <merge-deactivate> <Launchpad itself:Triaged> < https://launchpad.net/bugs/393914 >
[20:07] <lifeless> AFAICT that is
[20:10] <lifeless> maxb: ^
[20:11] <maxb> Oh. I figured they both must be talking about proposed membership, on the assumption that actual memberships would have been fixed up by the merge process
[20:24] <lifeless> benji: on bug 809470, did you mean 'triaged low' ?
[20:24] <_mup_> Bug #809470: Wishlist: Time and Taskplanning <gantt> <pert> <planning> <task> <time> <Launchpad itself:Won't Fix> < https://launchpad.net/bugs/809470 >
[20:25] <lifeless> benji: I only ask because setting an importance seems redundant when wontfixing :)
[20:25] <benji> lifeless: I meant "N/A" but that wasn't an option
[20:26] <lifeless> gmb: oh hai :P
[20:26] <benji> I almost used "Wishlist" but I don't think we really wish it to happen, and Undecided didn't seem to make sense.
[20:26] <gmb> lifeless: Wotcher.
[20:26] <lifeless> benji: it may be a linaro request;
[20:26] <lifeless> gmb: since you are hanging around, want to sort out this linked_branches thing?
[20:27] <gmb> lifeless: I won't be around for much longer, but we can give it a stab, sure.
[20:27] <lifeless> benji: If rephrased into a symptom based report, I think that that bug would look closer to jmls timelines/todo lists/thingy concept, which we do want to do
[20:27] <lifeless> gmb: so its a bait-and-switch on the implementation, the contract stays unaltered
[20:28] <gmb> Right.
[20:28] <lifeless> gmb: make new getter with one parameter(user); unpublished linked_branches in the API, publish the new thing as linked_branches with the user parameter auto-bound
[20:29] <gmb> lifeless: Okay. I don't know enough about how the API is exposed in WADL, etc., but might that not break callsites?
[20:29] <gmb> e.g:
[20:29] <benji> lifeless: could be
[20:29] <gmb> if it's currently:
[20:29] <gmb> branches = bug.linked_branches
[20:29] <lifeless> gmb: stays the same, because you're publishing it as a getter, not as a function
[20:29] <gmb> Won't that break when we turn it into a getter? (i.e. wouldn't it require linked_branches())?
[20:30] <gmb> Okay.
[20:30] <gmb> lifeless: I think there's a cognitive gap here that I need to fill in, but I'm with you now.
[20:30] <lifeless> there are examples that can be cargo culted, its the API version of 'property(get_fn)'
[20:30] <gmb> lifeless: Okay. I'll dig up an example and rip it off liberally tomorrow am.
[20:30] <gmb> Thanks for taking the time to explain things :)
[20:31] <lifeless> I'm probably describing it slightly wonky ;)
[20:32] <lifeless> benji: I might put it incomplete and follow up with some questions
[20:32] <gmb> lifeless: Well, we'll see. If I get it right first thing tomorrow then I was paying attention wonkily :)
[20:33] <lifeless> gmb: \o/
[20:33]  * gmb goes to do evening stuff
[20:33] <lifeless> benji: I'm confused by 809508 vs 809511
[20:34] <benji> lifeless: how so?
[20:34] <lifeless> aren't they the same thing ?
[20:35] <benji> that would be confusing :)  nope, one is about viewing a bug and associating it with a branch, the other is about viewing a branch and associating it with a bug
[20:35] <benji> same result, different contexts
[20:36] <lifeless> ah, cool
[20:41] <flacoste> lifeless: deployment-stable.html shows 13405 as QA-OK, are we good to deploy and reopen PQM?
[20:42] <lifeless> cr3: have you tried your API yet ?
[20:43] <flacoste> lifeless: -emeritus and asking -dev, good idea
[20:43] <lifeless> flacoste: I need to touch base with wallyworld/wgrant, rev 13391 also had some questions around it
[20:43] <flacoste> lifeless: ok, thanks, would have been nice to have an email to the list about the status of the queue
[20:43] <flacoste> as everything was green
[20:43] <flacoste> it wasn't clear without reading the IRC backscroll what was the status
[20:44] <lifeless> flacoste: indeed; I asked wallyworld and wgrant to decide and sort it out last night
[20:44] <lifeless> I had parenting class
[20:44] <flacoste> that was one thing that having a rotating release manager eased out
[20:44] <lifeless> agreed, its easier for that to be lost now
[20:48] <cr3> lifeless: yep, I commented on bug #801334 and set the tag to qa-ok
[20:48] <_mup_> Bug #801334: IHWSubmissionSet.search should be available in the API <qa-ok> <Launchpad itself:Fix Committed by cr3> < https://launchpad.net/bugs/801334 >
[20:48] <lifeless> cr3: great, thanks
[20:52] <lifeless> does anyone remember what jmls .., ah dashboards
[20:54] <cr3> benji: if you happen to have a moment, might you know how a project is able to find a project_series under it when accessing /<project.name>/<project_series.name> in the api? wouldn't IProduct have to define a default collection for that to work?
[20:54] <lifeless> cr3: project.active_series
[20:56] <lifeless> sinzui: isn't bug 95419 in your todo list ?
[20:56] <_mup_> Bug #95419: Record dependencies between bugs <lp-bugs> <oem-services> <Launchpad itself:Triaged> < https://launchpad.net/bugs/95419 >
[21:04] <cr3> lifeless: aha! lazr.restful probably calls upon ProductNavigation which has: traverse(name): return self.context.getSeries(name)... that must be it
[21:04] <flacoste> lifeless: btw, we have the green-light from statik on killing the lazr brand
[21:05] <lifeless> flacoste: sweet
[21:05] <cr3> what's this about killing lazr?
[21:05] <lifeless> flacoste: I'll document creating projects on the wiki shortly
[21:05] <lifeless> cr3: not killing as such, but de-emphasising its use for new projects
[21:06] <lifeless> cr3: aiming for good snappy names, avoiding issues with namespace packages
[21:06] <cr3> lifeless: for my edification, what's wrong with namespace packages?
[21:07] <lifeless> that they exist?
[21:07] <lifeless> cr3: in debian/ubuntu they can't be imported unless the package above exists, but the upstream packaging doesn't include that, or if it does include that multiple packages are then including the same file on disk.
[21:08] <lifeless> cr3: its a right PITA
[21:09] <cr3> lifeless: I was planning to split my launchpad-results project into namespace packages, for client and server to share a common name for example, it was a pain indeed and I'm reassured that it wasn't just me :)
[21:22] <rockstar> Why are the fonts on Launchpad so small now?
[21:22] <sinzui> lifeless, it is not truly in scope. I hope that a simple enum can be used so that dependencies are cheap to do (a week of work)
[21:23] <lifeless> sinzui: could you unpack that for me ?
[21:23] <sinzui> rockstar, the css is now Ubuntu Web Guidelines.
[21:24] <sinzui> rockstar, There may be a switch back to em's which is easy to do after the normalisation I did to get it to px.
[21:24] <rockstar> sinzui, so are you saying there are bugs with sizing that need to be worked out, or that they are correct (because I debate that)
[21:24] <lifeless> rockstar: they are correct per the guidelines we're getting. Some users (e.g. me and you :P) find them impossible to read.
[21:25] <sinzui> lifeless, we are making a is b, a duplicate that is not presented as a duplicate because we want separate conversations
[21:26] <rockstar> lifeless, than the guidelines are wrong.  :) I like small fonts, and those are still painful to read on my 23" 1080p monitors.
[21:26] <sinzui> rockstar, no. I *believe* that the Canonical accessibility/WAI drive requires a review of the px rule
[21:26] <rockstar> sinzui, okay.  Just as long as someone is looking to correct that.
[21:27] <rockstar> I first noticed it on "Propose for merging" which seems the LAST thing you want to be tiny and out of the way.
[21:27] <lifeless> sinzui: hmm, I had thought we were doing 'a depends on b' which combined with privacy addresses the OEM use case as well, but is more generally useful
[21:27] <sinzui> rockstar, the assumption of px was that all browsers have fixed the zooming rules for control++ and control+-. The assumption did not consider that users do not know about the feature
[21:28] <sinzui> lifeless, you and I want directionality, but stakeholders have only discussed confidential conversations.
[21:29] <lifeless> sinzui: concretely, I think an 'a is b' relation is something we wouldn't do if we did 'a depends on b', and so its a false economy to build it - we'll have to undo the work later
[21:29] <rockstar> sinzui, well, I think there should be sensible defaults as well though.
[21:29] <sinzui> lifeless, We will review and revise the requested feature in a few weeks.
[21:29] <lifeless> sinzui: ok; if its ok with you I'd like to be part of that review
[21:30] <sinzui> rockstar, the default happens to be the same as the Ubuntu OS defaults. The issue is that browsers always apply their own scaling rules based on 16pt.
[21:30] <sinzui> lifeless, yes please
[21:30] <lifeless> sinzui: \o/ - ok, ping me whenever and I'll come to you.
[21:31] <sinzui> lifeless, If we can agree that the bug.duplicate column does not scale, that we need a relational table, we can solve a lot of problems once we have the migration script settled
[21:33] <lifeless> sinzui: we need to know the answer to questions like 'do we need to search on the relation?' 'is it a tree (A is unique in the set of all existing (A,B) tuples), or a graph (there can be many (A,B) tuples for a given A'
[21:33] <wgrant> lifeless: I believe it is not worth rolling back.
[21:33] <lifeless> ok
[21:33] <lifeless> so we're green
[21:33] <rockstar> sinzui, I'd assert that this is a problem with CSS: http://ubuntuone.com/p/14Ad/
[21:34] <lifeless> wgrant: one of us should hav emailed the list about the status
[21:34] <lifeless> wgrant: not saying you or wally specifically, but as a group we dropped the ball
[21:34] <rockstar> The line height is 18px, to make space for the sprite, but then the text is 12px.  At least make it fill the line-height a bit more.
[21:34] <wgrant> lifeless: I had failed to notice that the downtime was a day earlier than normal.
[21:34] <wgrant> lifeless: So I thought we still had >24 hours.
[21:35] <lifeless> yah
[21:36] <flacoste> Language:
[21:36] <flacoste>     English ▼
[21:36] <flacoste> Copyright ©1999-2011 SurveyMonkey
[21:37] <sinzui> rockstar, most of Lp sprite issues were solved by the CWG's normalised font/line-height rules. Lp's sizes were impossible to predict using YUI-font
[21:38] <rockstar> sinzui, I guess I'm still unclear as to whether or not this is a known bug or a "this is acting as advertised and if you have a problem with it, tough"
[21:38] <sinzui> rockstar, I believe there are a few places trying to make the text very small in Lp. I changed the rules to ensure they could never be less than 10px. I am not sure any text other than the footer should ever be smaller than the base font.
[21:39] <sinzui> rockstar, it is not a bug. It is by design
[21:39] <lifeless> wgrant: I mean a status update, not a conclusion
[21:39] <lifeless> wgrant: we left everyone hanging not sure
[21:39] <lifeless> wgrant: and not sure if they should be not sure
[21:39] <rockstar> sinzui, so it's going to be left like that?
[21:40] <lifeless> rockstar: unless the canonical design department change the rules, or we make a case for not following the rules
[21:40] <flacoste> rockstar: for the moment yes
[21:40] <lifeless> rockstar: we believe they are doing a review now, so there is little point making a specific case right now
[21:41] <sinzui> You sample page was reviewed two weeks ago and it needs a redesign. When that page knows it is working with a temporary or permanent branch, the repetitive and odd heading, list, actions will be gone
[21:41] <flacoste> rockstar: we are working on a visual refresh of Launchpad, I'll let huwshimi know about the font issue
[21:42] <rockstar> Okay, so I guess the take-away is that I need to STFU for a few weeks and let things wiggle out.
[21:42] <sinzui> flacoste, huwshimi discussed the WAI+font-size issue with me 4 weeks ago.
[21:43] <rockstar> Am I correct here?
[21:43] <flacoste> rockstar: might be a few months unfortunately :-)
[21:43] <flacoste> rockstar: you have a too big monitor anyway :-)
[21:43] <rockstar> flacoste, okay, as long as there's an acknowledgement that we're not "done" yet.
[21:43] <flacoste> get a normal size screen like the rest of us
[21:43] <flacoste> who needs more than 12"!
[21:43] <wgrant> This hasn't changed in months, anyway.
[21:44] <rockstar> wgrant, maybe my cache just got cleared then, because it wasn't like this yesterday when I submitted my branches for review.
[21:44] <sinzui> rockstar, the fonts *are* done. The rules for the fonts *may not* be done. The refresh id the opportunity to get CWG revised
[21:45] <lifeless> flacoste: my new monitor - 24" 1080p :P
[21:45] <lifeless> flacoste: and I know poolie has larger :>
[21:45]  * rockstar highfives lifeless 
[21:45] <flacoste> you damn gamers!
[21:46] <poolie> mines' 27
[21:46] <rockstar> sinzui, okay, let me just register my opinion as "No call to action should ever be that small"
[21:46] <flacoste> 27" that's bigger than my TV
[21:46] <sinzui> rockstar, exactly!
[21:46] <poolie> ah canada :)
[21:46] <rockstar> poolie, I have 2 23" monitors, does that mean I win?
[21:46] <poolie> i'm thinking about retiring the smallest one and going to the largest dell model
[21:46] <poolie> only if you have two heads
[21:46] <rockstar> sinzui, okay, you agree, so I'll STFU and go back to work.
[21:46] <poolie> i can not get used to having a gap in the middle of my visual field
[21:46] <poolie> though you do win from having a standing desk
[21:47] <rockstar> Yeah, I was trying to think of a condescending way to let you know I'm still in the standing desk club, so obviously better than you.  :)
[21:48] <lifeless> poolie: smallest one ?
[21:49] <wgrant> rockstar: Are you sure you didn't zoom out or something?
[21:49] <poolie> S has my old 24in
[21:49] <rockstar> wgrant, positive.
[21:50] <poolie> rockstar: i stood up with my laptop on a bar yesterday
[21:50] <poolie> that was pretty good
[21:50] <poolie> may take some getting used to
[21:50] <rockstar> poolie, it certainly does.  Once you get used to it, you'll need to pick up barefoot running.  That's the next step in being condescendingly forward thinking.  :)
[21:51] <wgrant> rockstar: The last font size changes were made at the start of March.
[21:51] <wgrant> rockstar: And there have been none at all for at least a month.
[21:51] <wgrant> s/last/last significant/
[21:51] <lifeless> we did reset the session db over night
[21:51] <rockstar> Yes, and I did have to log back in.
[21:51] <lifeless> which also should have been announced - we've users affected by it
[21:51] <wgrant> With spectacular side-effects, but this shouldn't be one of them.
[21:52] <lifeless> never say shouldn't ;)
[21:52] <wgrant> lifeless: It was also entirely avoidable.
[21:52] <lifeless> :(
[21:52] <wgrant> It would have taken roughly 120 seconds to copy the contents of the DB over.
[21:53] <rockstar> I sent a branch page example out to others who all agree it's too small, so it's not just me.
[21:53] <wgrant> rockstar: A page, or a screenshot?
[21:53] <rockstar> wgrant, page.
[21:54] <flacoste> rockstar: standing desk is so passé, the future is threadmill desk!
[21:54] <flacoste> which you should obviously use barefoot :-p
[21:54] <rockstar> flacoste, threadmill? Like, multiple treadmills with some mutex?
[21:54] <rockstar> :)
[21:55] <flacoste> rockstar: ask gary for some pictures :-)
[22:40] <wgrant> lifeless: Did you see my txlongpoll deployment proposal?
[22:41] <lifeless> buildout.cfg? sure, I don't care particularly how its done.
[22:41] <lifeless> It will still be rsync based
[22:41] <wgrant> Yeah.
[22:43] <wgrant> I'm wondering how we should approach OOPS integration in general.
[22:43] <wgrant> Since we really don't want to force *oops into every upstream project we come across..
[22:43] <lifeless> sure we do
[22:43] <lifeless> catchall exception handler for most stacks is doable
[22:44] <lifeless> I looked at using wsgi-oops but its *sob* a namespace package, doesn't selftest for me, and has all sorts of unrelated stuff (like storm glue) in it.
[22:44] <wgrant> Yeah.
[22:44] <wgrant> Hmm.
[22:44] <wgrant> Maybe we can inject into sitecustomize or something.
[22:45] <lifeless> no
[22:45] <lifeless> its a http stack specific thing
[22:45] <lifeless> wsgi being one stack, twistd anther
[22:45] <lifeless> twisted another
[22:45] <lifeless> java and scala containers have analagous concepts
[22:45] <lifeless> its a small amount of work compared to manually checking log files
[22:46] <lifeless> wallyworld_: hi
[22:50] <wallyworld_> lifeless: hello
[22:52] <lifeless> wallyworld_: I'm curious why in https://code.launchpad.net/~wallyworld/launchpad/private-branch-unsubscribe-283167/+merge/67651 owner members cannot unsubscribe people ?
[22:52] <wallyworld_> lifeless: i thought that it would be too permissive
[22:53] <wallyworld_> but i can change it
[22:53] <lifeless> wallyworld_: its inconsistent with what owner means elsewhere
[22:53] <wallyworld_> ok. i'll fix it
[22:53] <lifeless> thanks!
[22:53] <wallyworld_> np. thanks for pointing it out
[22:53] <lifeless> no worries
[22:54] <lifeless> its really awesome we're polishing so many privacy related things
[22:54] <wallyworld_> there's a *lot* more to do
[22:54] <wallyworld_> one step at a time
[22:55] <lifeless> indeed
[23:02] <sinzui> StevenK, mumble?
[23:07] <cjwatson> phew.  finally have dpkg-xz-support working, with a combination of lucid-proposed, mvo's PPA, and a further python-apt change of my own
[23:07] <cjwatson> (the last not in oneiric yet ...)
[23:18] <wgrant> cjwatson: Excellent. How much work is this going to be to backport?
[23:28] <cjwatson> wgrant: I've just sent mail about that
[23:29] <cjwatson> we might as well deal with this and the LongDescription configuration work at the same time
[23:30] <cjwatson> LP machines pull from lucid-updates, don't they?
[23:31] <lifeless> possibly, same as other dc machines
[23:32] <wgrant> I believe they do.
[23:32] <sinzui> StevenK, http://pypi.python.org/pypi/zope.formlib
[23:33] <cjwatson> the xz support will go there (min delay a week from when mvo processes my mail, though); not sure about the LongDescription change, we might ask that that go into the LP PPA instead
[23:33] <cjwatson> but mvo's already backported it
[23:34] <cjwatson> if we do that in a PPA, the xz support will have to be merged into it
[23:54] <StevenK> wallyworld_: Seriously, your microphone sounds like a *kettle*
[23:55] <wallyworld_> StevenK: i was muted for most of the time unless i wa speaking
[23:55] <wgrant> No, it's a sonic screwdriver.
[23:56] <wallyworld_> wgrant: did you raise a bug to fix the person picker wording issues?
[23:58] <wgrant> Not yet.
[23:58] <wgrant> lifeless: Are we out of RC yet?
[23:58] <lifeless> ask losa; I requested it a while back
[23:59] <wgrant> LOSA pingaling