[00:04] <salgado> wallyworld, hey, thanks for that review!  would you mind landing it for me as well as I don't have ec2-utils setup?
[00:04] <wallyworld> salgado: np. will do it today. thanks for doing the work :-)
[00:07] <sinzui> StevenK, after looking at formlibs processing of the form, visibility is excluded from the data because the input == false. So while the widget got input that we recognise as valid, it is ignored because of this "input" flag. I think "input" means the field is read-only
[00:09] <StevenK> sinzui: I set readonly=true in the visibility attribute
[00:09] <StevenK> I remember Zope de-praming its toys if it wasn't
[00:10] <sinzui> correct, but I think out mutator rules are in conflicts with form lib
[00:11] <sinzui> We may need to check the state of the widget ourselves, or as we have done before...copy a writeable field into the ITeamCreation schema
[00:11] <StevenK> sinzui: I've just removed readonly=True, let's see what Zopes does.
[00:12] <sinzui> StevenK, mutator will kill startup
[00:12] <StevenK> Indeed
[00:12] <StevenK> TypeError: Only a read-only field can have a mutator method.
[00:12] <sinzui> StevenK, We know at the time of creation, we can do what we want because there is no mutation
[00:12] <wgrant> Ah, yes, that's right.
[00:12] <wgrant> You need to override the readonlyness in setUpFields
[00:13] <sinzui> wgrant, StevenK I see the widget got the value and it was valid. are you saying setupfields did something else to say do a lot of work, but I intend to ignore it later
[00:13] <sinzui> ?
[00:14]  * sinzui must eat
[00:14] <StevenK> sinzui: Thanks for the pointer
[00:14] <StevenK> wgrant: How do I do that?
[00:15] <wgrant> StevenK: See BugSecrecyEditView for a way to do it without customising setUpFields
[00:15] <wgrant> The copy_field business
[00:16] <StevenK> I'm tempted to do it in conditionallyOmitVisibility()
[00:16] <StevenK> Then everything gets it
[00:16] <wgrant> It's not appropriate to do it there.
[00:17] <StevenK> class schema? Wow, really?
[00:17] <wgrant> ?
[00:18] <StevenK> That's what under BugSecrecyEditView does copy_field()
[00:18] <wgrant> Yes.
[00:18] <wgrant> I'm just wondering why you question it.
[00:18] <StevenK> Seems like a horrid hack :-P
[00:19] <wgrant> It's a horrid problem with a not particularly horrid solution.
[00:19] <StevenK> Hmm, but TeamAddView already defines schema = ITeamCreation
[00:20] <wgrant> Yay, top OOPS fixed.
[00:22] <StevenK> That was Product:+index?
[00:22] <wgrant> No, loggerhead's DownloadUI
[00:22] <wgrant> Product:+index rarely times out now, it's just 30% slower than it needs to be.
[00:22] <wgrant> And that fix is not on production yet.
[00:23] <StevenK> Or even qas?
[00:23] <wgrant> Correct
[00:23] <StevenK> ValueError: ('Duplicate name', 'visibility')
[00:23] <StevenK> :-(
[00:27] <wgrant> Oh, that fixed oops #5 too
[00:27] <lifeless> wgrant: so the question is where folk were getting bad links from
[00:28] <wgrant> lifeless: I would tend to suspect spiders, but loggerhead OOPSes don't contain any info.
[00:28] <wgrant> The access logs might.
[00:28]  * wgrant hunts.
[00:28] <lifeless> spiders don't make up urls though
[00:29] <lifeless> so if its spiders, something is broken
[00:29] <lifeless> somewhere
[00:29] <wgrant> Why?
[00:29] <wgrant> These are referring to fileids in head:
[00:29] <wgrant> That easily linkrots.
[00:29] <lifeless> true
[00:29] <lifeless> downloadUI is quite new though
[00:29] <lifeless> that one in particular...
[00:29] <wgrant> DownloadTarballUI is now
[00:29] <wgrant> DownloadUI isn't, is it?
[00:29] <wgrant> s/now/new/
[00:29] <lifeless> ah, right right
[00:31] <wgrant> Interesting.
[00:32] <wgrant> There's far fewer requests in the logs than there are OOPSes.
[00:33] <wgrant> All the problematic requests are from Android
[00:33] <wgrant> So I wonder if the app is looking at that URL for updates.
[00:34] <lifeless> wgrant: the garbo job change landed?
[00:34] <lifeless> wgrant: I take it we're doing a one-off ?
[00:35] <lifeless> wgrant: hah, an android app updating from loggerhead. Aieee!!!! !!
[00:35] <wgrant> lifeless: No, just the DB patch so far.
[00:35] <lifeless> oh phew
[00:35] <wgrant> Will be deployed on Monday
[00:35] <lifeless> \o/
[00:35] <wgrant> Oh, blah.
[00:36] <wgrant> This is going to take forever to branch.
[00:36] <wgrant> Because it has Java disease.
[00:36] <wgrant> Dozens of embedded jars.
[00:36] <lifeless> head-spike
[00:36] <wgrant> Perhaps we can alter the LP ToS
[00:36] <wgrant> To state that if you embed dependencies, your forfeit your access to LP
[00:39] <wgrant> alert, alert
[00:39] <wgrant> We are in the green for criticals in the last week :/
[00:40] <StevenK> Isn't that a good thing?
[00:42] <wgrant> It can only mean one thing: our OOPS reporting system is broken.
[00:54] <lifeless> how wrong is it to call functions via exec function.__code__ in custom_globals
[00:55] <wgrant> That ranks at roughly 11/10 evil points
[00:57] <lifeless> it is sad when language docs need to say things like:
[00:57] <lifeless> In some cases, a fruitful optimization is to assign the attribute to a local variable and call that local variable.
[00:58] <lifeless> anyhow, func_code is the support attribute. win.
[00:58] <wgrant> It is sad when the project is 10MB but the branch is 150MB because of the jars.
[00:58] <wgrant> collectionista-library/res/values/strings-versioncheck.xml:    <string name="version_file_url">http://bazaar.launchpad.net/%7Epjv/collectionista/trunk/download/head:/collectionista_versi-20110605182324-0nll835704egr1kc-219/collectionista_versions.xml?file_id=collectionista_versi-20110605182324-0nll835704egr1kc-219</string>
[00:58] <wgrant> woot
[01:00] <lifeless> headdesk deskhead
[01:00] <wgrant> It's a reasonably strategy.
[01:00] <lifeless> not with that url
[01:00] <wgrant> Strategy, not implementation :)
[01:27]  * StevenK stabs NFS, and then twists the knife.
[01:42] <lifeless> its a bit disappointing that the vm bypasses __getitem__
[01:54] <wgrant> Grar
[01:54] <wgrant> Too many bug statuses
[01:55]  * wgrant becomes murderous.
[01:59] <lifeless> win 3658  OOPS-11d83b82cd4d682e6c5cd63a9326e9db  Unknown
[01:59] <wgrant> It's always in the top 5
[02:00] <lifeless> top today
[02:00] <wgrant> With a count like that I would certainly hope so :)
[02:04] <wgrant> Ah, process-apport-blobs
[02:04] <wgrant> Hmm
[02:05] <wgrant> I think it may have a somewhat serious bug.
[02:05] <wgrant> 3658 queries, 3200 of which are made up of two massively duplicated librarian reads.
[02:06] <wgrant> Ah, possibly it's chunked.
[03:00] <wgrant> lifeless: So, simply realising the join removes the Ubuntu FTI issue.
[03:01] <wgrant> I have most sensible orders with FTI pretty fast now, even on DF.
[03:01] <wgrant> I wonder if I can make a guess at how many rows there are and disable insane orders if there are too many.
[03:43] <wgrant> aaaaah launchbag
[03:45] <StevenK> Kill it, it's moving!
[04:08] <wgrant> I have to say, it is somewhat pleasing to see dogfood reliably faster than production.
[04:12] <wgrant> Oh no :(
[04:12] <wgrant> My launchpad shared repo is now tainted.
[04:13] <wgrant> I accidentally branches collectionista into it, so it's now covered in revolting embedded jar residue :(
[04:53] <wgrant> lifeless: How are we looking for bug index bloat?
[04:54] <wgrant> Oh, blah.
[04:54] <wgrant> Nevermind.
[04:54] <wgrant> The massive PPR regression is the bug listings release.
[04:56] <wgrant> However, we have a serious xmlrpc-private regression start on the 26th and escalating since then.
[04:58] <wgrant> Hm, unless it actually started on the 30th, when the session DB was put through pgbouncer.
[04:58] <wgrant> But it seems to have been going slightly badly since the 27th.
[05:29] <lifeless> is it just me or is js calling conventions a tad idiosyncratic
[06:34] <wallyworld> StevenK: can't recall your previous issue exactly, but i can't create_initialized_view for a team with a rootsite specified eg https://blueprints.launchpad.dev/~teamname and have it render correctly
[06:34] <wallyworld> is that something you ran into before?
[11:24] <rick_h> morning
[11:43] <jelmer> hey rick_h
[11:52] <jml> hello
[11:52] <jml> I have a couple of questions:
[11:53] <jml> Is there an IRC bot that can announce when new MPs are up on Launchpad (for a user-defined set of projects)
[11:53] <wgrant> jml: I think Landscape has one.
[11:53] <jml> Would it be OK if I amend an existing IRC bot to do this? Are there any guidelines for the inevitable polling that I will have to do?
[11:53] <stub> jml: Rabbit FTW
[11:54] <jml> stub: Rule Britannia.
[11:54] <stub> jml: txlongpoll + rabbit if not running in our DC
[11:55] <jml> stub: do you mean that I can actually set something up today that wait for events from Launchpad and not run in the DC?
[11:56] <stub> jml: It is used by the merge proposal page at the moment to load the diff as soon as it is available, so all the pieces are in place.
[11:56] <jml> stub: I don't see that behaviour...
[11:57] <wgrant> It's restricted to ~launchpad until it's ready.
[11:57] <jml> stub: also, that sounds suspiciously like a "No, not yet"
[11:57] <stub> jml: It means in theory yes, in practice ask the people who implemented it :)
[11:57] <jml> stub: heh, ok.
[11:58] <jml> wgrant: ok. I'll make a note to come back and ask about this some time in the future.
[11:58] <jml> wgrant: I feel a bit stupid for asking, but, any guess on when it'll be opened up to a broader group?
[11:59] <wgrant> jml: There's one current show-stopping bug which I might get bored and illicitly fix at some point.
[12:02] <jml> wgrant: ok, thanks.
[12:09] <wgrant> In fact, why don't I try to fix that now.
[12:09]  * wgrant fixes.
[12:13] <matsubara> hey guys, I replied to a merge proposal by email but my reply didn't show up in the web ui. should I have signed the email?
[12:36] <bac> hello adeuring
[12:37] <bac> matsubara: i did the same yesterday with this MP:  https://code.launchpad.net/~frankban/charms/oneiric/buildbot-slave/02-09/+merge/92340 . you'll see my second comment showed up just fine.  the email was unsigned.
[12:38] <bac> but i wondered as i hit 'send'
[12:39] <matsubara> how strange. In any case I copy and pasted my reply into the MP
[12:44] <adeuring> morning bac
[12:49] <StevenK> rick_h: O hai. You agree with my Evil Plan?
[12:53] <rick_h> StevenK: your plan works for me I believe
[12:54] <rick_h> and I can start landing fixes like a mad man once that's there and we get some testers
[12:54] <StevenK> rick_h: One thing I'd love for you to look at is why the AJAX drop-down doesn't work.
[12:55] <rick_h> orly? ok, where is this?
[12:55] <rick_h> is there a bug to look at?
[12:55] <StevenK> rick_h: On any page, it's the green "AJAX log" next to your name.
[12:56] <rick_h> oh that, ok. I'll peek
[12:56] <StevenK> rick_h: It's only shown for us, but it hasn't worked since our fixes from the epic were deployed
[12:56] <StevenK> rick_h: I'm guessing it's something trivial
[12:56] <rick_h> StevenK: ok, I had hoped it was part of the single LPJS thing
[12:56] <StevenK> So had I
[12:56] <StevenK> It wasn't. :-(
[12:56] <rick_h> if it's still broken today, then I'll peek at it
[12:56] <StevenK> rick_h: I'm not sure if there is a bug. wgrant may have filed one.
[12:57] <rick_h> k, I'll look, thanks for the heads up
[12:57] <StevenK> rick_h: Do you also want to prod sidnei to review my convoy branch? :-)
[12:58] <rick_h> ah ok, I haven't peeked over there. Will do.
[12:58] <rick_h> StevenK: he's in Brazil so should be mid day now I tink
[12:58] <rick_h> think*
[13:06] <rick_h> StevenK: ok, didn't see a bug, so added one and got the card on the board
[13:07] <StevenK> rick_h: I'd be very curious to find out what the issue was.
[13:10] <jelmer> what's the best way to check if a call exercises the database again?
[13:11] <StevenK> In a test?
[13:11] <jelmer> StevenK: yep
[13:11] <jelmer> I'm testing to see if something that's supposed to cache will actually cache
[13:12] <StevenK> jelmer: Right, we have an existing pattern for that. Have a grep for StormStatementRecorder
[13:13] <jelmer> StevenK: I don't recall seeing that before, is it new?
[13:13] <jelmer> StevenK: either way, that seems to be exactly what I'm looking for - thanks!
[13:13] <StevenK> I think it's been around for a little while
[13:13] <rick_h> StevenK: sidnei is +1'ing your MP
[13:14] <StevenK> rick_h: Sweet. Feel free to merge it in
[13:14] <rick_h> will do
[13:14] <StevenK> Then we should automagically get a new version of convoy in the PPA.
[13:14] <rick_h> StevenK: awesome
[13:18] <gary_poster> jelmer, hi.  Congrats on colocated branches!  Where do we read about how to use them?
[13:22] <jelmer> gary_poster: Hi
[13:22] <jelmer> gary_poster: they're not really prime-time material yet; most of the documentation there is can be found in my last post on them to the bazaar mailing list
[13:23] <gary_poster> jelmer, ok.  So should we not try to rely on them?
[13:23] <jelmer> gary_poster: their format is stable, but the support in the UI is still a bit awkward
[13:24] <gary_poster> jelmer, hm, ok.  I'll review the post and see if we can give it a whirl.  I'm guessing testers would be good. :-)
[13:25] <gary_poster> thank you
[13:26] <jelmer> gary_poster: yep, definitely - thanks :)
[13:26] <jelmer> gary_poster: see also the list of bugs tagged 'colocated' in bzr
[13:28] <wallyworld_> jelmer: colocated branches are not new are they? i've been using branches switching between a single working tree ever since i started
[13:29] <wallyworld_> lp is too large to do anything else imo
[13:29] <wallyworld_> plus it suits modern IDE's
[13:30] <jelmer> wallyworld_: colocated branch support in bzr itself is new
[13:30] <jelmer> wallyworld_: perhaps you mean bzr-colo?
[13:31] <wallyworld_> yes, i think that's what i meant
[13:41] <bigjools> wallyworld_: jelmer: bzr switch I suspect?
[13:41] <wallyworld_> bigjools: yes, i use bzr switch
[13:41] <bigjools> me also
[13:41] <wallyworld_> with a single working tree, and no-tree branches
[13:42] <wallyworld_> i'm not 100% sure what colocated branch support is, have to rtfm
[13:56] <jelmer> wallyworld_: switching a single working tree between multiple branches has been supported for a long time
[13:56] <jelmer> this is just the support for having the branches live in the same location as the tree
[13:56] <jelmer> rather than having to have a separate shared repo with the branches elsewhere
[13:57] <wallyworld_> ah, ok. i follow now. thanks for the extra explanation.
[13:57] <jelmer> hi adeuring, bac
[13:57] <wallyworld_> although for my use, i want the branches and working tree separate
[13:57] <adeuring> hi jelmer
[13:57] <bac> hi jelmer
[13:57] <jelmer> would either of you have time for the review of a small branch?
[13:57] <jelmer> https://code.launchpad.net/~jelmer/launchpad/branchjob-cache-authors/+merge/92470
[13:58] <adeuring> jelmer: sure
[13:58] <jelmer> wallyworld_: why do you need to have them separate?
[13:58] <jelmer> adeuring: thanks!
[14:00] <wallyworld_> jelmer: i like the working tree to be "pure" and not have extra VCS directories in it like with svn or cvs. but i guess if they are hidden then it's ok
[14:01] <wallyworld_> jelmer: so now i have a lp-branches dir, and all my branches are directories named after the branch containing .bzr etc, and my working tree sandbox is nicely uncluttered
[14:02] <jelmer> wallyworld_: that's still the case with colocated branches, they all live under .bzr/branches
[14:02] <wallyworld_> ah, ok. then that sounds cool :-)
[14:03] <wallyworld_> although now i can ls to see what my branches are easily
[14:03] <wallyworld_> and use ls -lort to see what the most recently checked out one is
[14:03] <adeuring> jelmer: r=me
[14:04] <jelmer> adeuring: merci :)
[14:05] <jelmer> wallyworld_: the difference once it's set up is quite small
[14:05] <jelmer> wallyworld_: we have a 'bzr branches' command that can list all branches and pinpoint which one is active at the moment
[14:05] <jelmer> wallyworld_: the main advantage in colocated branches vs the the traditional setup with a lightweight checkout and shared repository, is that it requires less setup
[14:06] <jelmer> wallyworld_: you can just go "bzr branch lp:foo" and then run "bzr switch -b newbranch" in the resulting directory
[14:08] <wallyworld_> makes sense. atm i just go "bzr switch ../foo" to changes branches so i guess it comes down to what you are used to
[14:09] <wallyworld_> the setup was a one time thing, not too onerous from memory
[14:09] <wallyworld_> but anything to make it easier is good :-)
[14:10] <wallyworld_> the reason i like ls -lort is that sometimes i need to recall what the last few branches were that i worked on because i need to switch back to one and can't recall it's name
[14:28] <deryck> adeuring, abentley, rick_h -- https://plus.google.com/hangouts/extras/talk.google.com/orange-standup
[14:28] <deryck> superspeed standup today.
[14:28] <rick_h> deryck: ok
[14:28] <deryck> I'm stuck waiting on plugin in FF.  switching
[15:21] <deryck> abentley, adeuring, rick_h -- I'm back now.
[15:21] <adeuring> ack
[15:22] <abentley> deryck: Cool.
[15:22] <rick_h> deryck: yay
[15:26] <deryck> rick_h, hey, so just to be clear, you don't need reviews from me now, thanks to wallyworld_ right?
[15:28] <rick_h> deryck: not for those two, I'm making the changes there and will put up the next set for you :)
[15:28] <deryck> rick_h, rockin'! :)
[15:29] <rick_h> deryck: 3 is up, 4 says conflicts to looking into that
[16:00] <abentley> deryck: talk in 2 minutes?
[16:01] <deryck> abentley, yup.  firing up a hang out now.
[16:01] <deryck> abentley, actually, warming coffee.  but here's the link….  https://plus.google.com/hangouts/extras/talk.google.com/go-for-deryck
[16:28] <rick_h> deryck: ok, branch 4 is fixed and pushed as well and setup for review
[17:11] <deryck> rick_h, I'm working on them now.
[17:13] <rick_h> deryck: let me know where to send the beer to in payment
[17:14] <deryck> rick_h, not necessary. :) It's actually easy to review this stuff to me.
[17:14] <rick_h> hah, you say that now! I know my steam is slowing down in writing it, I'll bet the review does as well :P
[17:16] <deryck> rick_h, r=me for #3 branch.
[17:16] <rick_h> deryck: ty much
[17:17] <deryck> rick_h, it helps that I'm a really fast reader anyway, and I know these tests really really well. :)
[17:18] <rick_h> I like to remind myself that the worst I can do is cause a test failure because I broke it really
[17:24] <deryck> rick_h, yup. it's really a very safe change, despite the diff size.  r=me on #4.
[17:24] <rick_h> deryck: ok thanks.
[17:24] <rick_h> deryck: since 5 is just the html files getting a lot more files into there, still working. Almost done with /bugs/
[17:25] <rick_h> so I'll be back! bwuhahahaha
[17:25] <rick_h> lol, there's a 'test_me_too.js' never noticed that one
[18:19] <sinzui> bac, do you have time to review changes to commercial subscription rules: https://code.launchpad.net/~sinzui/launchpad/apply-commercial-subscription/+merge/92547
[18:19] <bac> sinzui: yes
[18:19]  * james_w curses incompatible bson libraries
[18:25] <salgado> rick_h, hi there. when you have a minute, we could do with another review on https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-model-classes/+merge/92174 :)
[18:26] <rick_h> salgado: loading up
[18:47] <beuno> so
[18:47] <beuno> this new thing of not changing the URL when a merge proposal is files
[18:48] <beuno> *filed
[18:48] <beuno> and it still being +register-merge
[18:48] <beuno> is tehre a bug yet?
[18:51] <rick_h> salgado: looks good, passed onto jcsackett for final ok
[18:51] <rick_h> salgado: thanks for both of you for the updates to the storm way vs sqlobject way.
[18:52] <salgado> rick_h, thank you for the reviews! :)
[18:58] <lifeless> james_w: patches...
[19:00] <james_w> lifeless, unpossible!
[19:01] <james_w> I think we'll just have to cut oops-* over to pymongo everywhere
[19:02] <lifeless> james_w: I'm no particular objection to that
[19:02] <james_w> yeah
[19:03] <james_w> I'm just not sure how for the tendrils will stretch yet
[19:03] <lifeless> everywhere.
[19:03] <lifeless> muhhahahhahhahahha
[19:03] <james_w> for instance, we may end up deleting the rfc serializer as part of the change
[19:04] <lifeless> why ?
[19:05] <lifeless> I mean, no great loss IMO, but why?
[19:05] <james_w> because this will change the semantics of what you get back from oopses
[19:05] <lifeless> how so ?
[19:05] <james_w> pymongo always returns naive datetimes
[19:06] <lifeless> what?!
[19:06] <lifeless> thats totally bogus
[19:06] <lifeless> also error prone
[19:07] <lifeless> do they have a fixed point of reference? or does stuff build on mongo vary by the tz of your server?
[19:07] <lifeless> so, ok, I do have an objection.
[19:07] <lifeless> *this*
[19:08] <james_w> everything in the serialized form is UTC
[19:08] <james_w> with the rule that you can't put a naive datetime with a non-UTC tz as input
[19:10] <lifeless> naive has no tz
[19:10] <lifeless> so that rule doesn't make sense to me
[19:11] <james_w> it has an unrecorded tz
[19:11] <lifeless> you *can't tell* if someone is messing up if you accept naive tz's
[19:11] <james_w> "everyone that decodes the bson will assume that datetimes are UTC, so don't break that assumption for them"
[19:11] <lifeless> hahahahahaha
[19:12] <james_w> so we're back to...
[19:12]  * james_w curses incompatible bson libraries
[19:12] <lifeless> if they were here, I would say to the authors: "There is a way to do that in python, its called tz aware datetimes"
[19:12] <lifeless> I mean really, it is astonishingly bad
[19:13] <james_w> lifeless, you do realise that the bson library already in use does pretty much the same thing?
[19:13] <james_w> it just returns non-naive datetimes
[19:14] <james_w> http://paste.ubuntu.com/836939/
[19:14] <lifeless> yes, thats the right way
[19:15] <lifeless> strict on emission, broad on acceptance but tell folk they are being daft
[19:15] <james_w> they just add a warning, and return a non-naive datetime with the same assumptions
[19:15] <lifeless> yes
[19:15] <lifeless> the wire protocol is defined as being utc
[19:15] <lifeless> which is great
[19:16] <lifeless> so, we could warap pymongo, we could give them a patch providing an option for folk that want nicer coding environmens
[19:18] <james_w> aha
[19:18] <james_w> there's an option
[19:22] <lifeless> cool
[19:27] <james_w> https://code.launchpad.net/~james-w/python-oops-datedir-repo/bson-compat/+merge/92560
[19:28] <lifeless> amqp coming soon I presume ?
[19:34] <james_w> already done
[19:34] <lifeless> \o/
[19:34] <lifeless> james_w: wait, what? :)
[19:34] <james_w> https://code.launchpad.net/~james-w/python-oops-amqp/bson-compat/+merge/92389
[19:55] <timrc> flacoste, I must be living in the past because it says this policy was approved 17th Feb 2012.. https://dev.launchpad.net/PolicyAndProcess/MaintenanceCosts :)
[20:05] <flacoste> lol
[20:05] <flacoste> timrc: nah, it's only lifeless living in the future
[20:06] <timrc> flacoste, that oddly makes sense..
[20:06] <timrc> :)
[20:06] <flacoste> but he's usually only one day ahead
[20:06] <flacoste> i think he must have made a breakthrough in his timewarp machine
[20:22] <bac> sinzui: done.  sorry for the delay
[20:23] <sinzui> That okay, I almost have my next branch complete
[20:29] <lifeless> bah no
[20:29] <lifeless> its me confounding dates
[20:54] <sinzui> The cursing and screaming upstairs in English, German, and Japanese, can mean onyl two things. Firstly, I taught my daughter well, and secondly, she has reached the mind-f**k ending of Evangelion You Shall Not Advance.
[20:59] <jelmer> sinzui: :)
[21:00] <sinzui> I just advanced the film to the closing scene after the credits. She at lease knows that world will not end.
[21:04] <lifeless> sinzui: :)
[21:05] <lamalex> Hey, is this right place to ask questions about the API usage, or is that better suited for #launchpad
[21:06] <lamalex> i'm trying to copy from a PPA into another from a jenkins job, a python script seems best (but if there's a better way please let me know!)
[21:14] <lifeless> lamalex: #launchpad
[21:48] <sinzui> bac: I think you are about to EOD, but if you have time I have a branch that could be reviewed: https://code.launchpad.net/~sinzui/launchpad/contact-team/+merge/92589
[21:50] <bac> sinzui: probably.  otp atm
[21:59] <bac> sinzui: i don't understand this comment in the MP
[21:59] <bac> ADDENDUM: I cannot 'hit' the cancel link. I do not think the cancel
[21:59] <bac>       is a verb and suffices.
[21:59] <bac> sinzui: can you clarify?
[22:01] <sinzui> bac The text instructs me to "hit" "cancel"
[22:01] <bac> ohhh
[22:01] <sinzui> bac https://launchpad.net/~lifeless/+contactuser
[22:01] <sinzui> ^ We might have had a Cancel button in the past
[22:01] <bac> it should read 'hit lifeless' ?
[22:02] <bac> sinzui: thanks.  that makes sense now.
[22:02] <sinzui> I press keys and tap buttons. maybe I should tap lifeless
[22:05] <bac> hmm, maybe not
[22:05] <bac> sinzui: done
[22:06] <bac> sinzui: my stupid irc client won't let me edit the topic.  would you remove abel and me from the topic, please, while i go search for a less dumb client?
[22:08] <sinzui> done
[23:28] <lifeless> rick_h: ola!
[23:39]  * wgrant glares at the Web.
[23:39] <wgrant> But I think I have three ways of inter-tab communication that cover all major browsers except maybe IE...
[23:40] <wgrant> s/cover/together cover/
[23:42] <lifeless> wgrant: sweet
[23:42] <lifeless> wgrant: evil. But sweet.
[23:43] <lifeless> wgrant: and if you are around; I have some js questions; up for a [briefish] voice call ?
[23:43] <wgrant> lifeless: Well, since we can't reasonably maintain one connection per tab, there's not much other choice. And only one of the ways is evil.
[23:43] <wgrant> Sure
[23:44] <lifeless> hangout invite sent
[23:45] <wgrant> I've not used one before, but let's see how it goes...
[23:46] <lifeless> ah, you'll be a minute installing the binary blob plugin then
[23:46] <lifeless> (yes, twitch)
[23:46] <wgrant> wtf
[23:47] <wgrant> Do invites show up somewhere?
[23:47] <wgrant> I don't have an email.
[23:47] <wgrant> Ah
[23:47] <wgrant> In the unified Google bar of stupidity.
[23:48] <wgrant> "Installing Google voice and video chat will add the Google voice and video chat repository so your system will automatically keep Google voice and video chat up to date."
[23:48] <wgrant> wtf is this shit
[23:48] <lifeless> its the HTML5 web
[23:48] <wgrant> I wonder if I can apparmor this to death.
[23:48] <wgrant> wtf plain http download link
[23:49] <lifeless> if you do, submit a patch to the ubuntu apparmour config!
[23:49] <wgrant> Aha, there's one on the wiki already.
[23:50] <lifeless> internal?
[23:51] <wgrant> Yeah :(
[23:54] <wgrant> Firefox has hung twice, but it seems to be loading...
[23:57] <lifeless> wgrant: anything in dmesg ?
[23:58] <lifeless> wgrant: also check top; precise has a horrible habit of *not killing hung things*