[00:00] <wallyworld_> ah right, glad we found out how it was happening
[00:01] <StevenK> Let me toss that ec2 and then forage for some breakfast.
[01:04] <RyuGuns> Hey guys.
[01:05] <RyuGuns> I've been in the process of registering a new account...
[01:06] <RyuGuns> But I am not allowed to.,.
[01:06] <RyuGuns> Wait, actually, nevermind.
[01:07] <RyuGuns> How do I merge accounts?
[01:07] <bobweaver> RyuGuns,  https://help.launchpad.net/YourAccount/Merging
[01:07] <bobweaver> :)
[01:08] <RyuGuns> :)
[01:24] <RyuGuns> Funk.
[01:24] <RyuGuns> How do I change my ID?
[01:24] <RyuGuns> Nevermind.
[01:54] <lifeless> RyuGuns: bobweaver: you might prefer #launchpad for customer support
[01:56] <RyuGuns> https://launchpad.net/ubuntu+mobile+phone
[01:56] <RyuGuns> Anyone interested?
[05:16] <StevenK> wgrant: Free to review, or still distracted by *redacted*?
[05:25] <StevenK> And no wallyworld.
[05:25] <StevenK> Maybe bigjools' tech has broken TPG.
[05:25] <wgrant> StevenK: 'sup?
[05:25] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/hack-itemwidget/+merge/104202
[05:26] <wgrant> oh god
[05:26] <wgrant> StevenK: Why are you setting term.name now?
[05:27] <StevenK> wgrant: Because the test in test_itemswidgets requires it
[05:27] <StevenK> And I'd rather just use self.assertRenderItem
[05:30] <wgrant> StevenK: r=me before lp melts again
[05:30] <StevenK> Haha
[06:59] <wallyworld> wgrant: StevenK: have you seen bug emails with the same info twice? eg "** Visibility changed to: Private" is listed twice in the one email
[07:00] <wallyworld> i seem to recall i may have seen this but am not sure
[07:00] <StevenK> I can't recall that one, personally.
[07:01] <StevenK> I a note to track down why information type: Public -> Private turns up twice when you change the information type via JS.
[07:02] <wallyworld> StevenK: that's what i'm seeing also but i'm fairly sure it happened before the info type field was introduced
[07:09] <wgrant> I don't recall seeing that before.
[07:09] <wgrant> I would suspect a regression.
[07:29] <wallyworld> wgrant: i seem to recall it may have happened for eg "** Visibility changed to: Private" which was before disclosure
[07:29] <wallyworld> but i can't be 100% sure
[07:30] <wgrant> That stuff was dangerously refactored a few months ago
[07:30] <wgrant> It may have been a regression then.
[08:14] <czajkowski> aloha
[08:23] <jml> czajkowski: hi
[08:24] <czajkowski> morning
[08:40] <jml> ok.
[08:40] <jml> so I'm going to do some Launchpad hacking.
[08:40] <jml> stand back.
[08:40] <wgrant> Uhoh
[08:40] <jml> does it work in precise yet?
[08:40] <wgrant> We're doomed
[08:40] <wgrant> Um
[08:40] <wgrant> Well
[08:40] <wgrant> Maybe.
[08:41] <wgrant> You'll need python2.6
[08:41] <jml> I have Python 2.6!
[08:41] <wgrant> It might Just Work™, then.
[08:41] <wgrant> I fixed the other issue yesterday.
[08:41] <wgrant> But haven't retried since.
[08:43] <czajkowski> wgrant: was sure that was one of the resonas why gmb was setting up an Ec2 for uds lp clinic was it not working on precise just yet
[08:43] <jml> KeyError: 'STORM_CEXTENSIONS'
[08:44] <wgrant> Doing what?
[08:44] <wgrant> How old is the tree?
[08:44] <jml> I just pulled
[08:44] <jml> but I've forgotten everything I need to do to update
[08:44] <wgrant> make clean build, to be safe
[08:44] <jml> ah, ok.
[08:45]  * wgrant tries.
[08:51] <jml> Error: pg_config executable not found.
[08:51] <jml> I get that in the middle of a 'make build'
[08:53] <wgrant> Do you have launchpad-developer-dependencies installed?
[08:54] <wgrant> I shall return after dinner. Hopefully germanium will give me everything I need while I eat.
[08:56] <jml> wgrant: heh
[08:56] <jml> wgrant: ta
[08:56] <jml> wgrant: no, I don't. It seems to be broken.
[09:03] <jml> ah, you need python2.6-dev
[09:04] <jml> I've just got python2.6 from https://launchpad.net/~fkrull/+archive/deadsnakes
[09:10] <wgrant> jml: Yeah, I'll probably replace it with python-all-dev and co. once I check it functions without 2.6
[09:10] <wgrant> We mostly just use the default version, but some things still point at 2.6, I believe.
[09:12] <wgrant> Everything of note has been updated to just use the default, so it will hopefully work.
[09:13] <jml> coole.
[09:13] <jml> I'll keep hacking in my lxc for the moment.
[09:13] <wgrant> Probably better for your sanity anyway.
[09:21] <jml> yeah.
[09:30] <wgrant> Interesting
[09:30] <wgrant> pg_createcluster now fails if it's run in a nonexistent locale.
[09:30] <wgrant> dpkg doesn't notice.
[09:31] <wgrant> lifeless: Any objections to dropping !precise host support from /Running/LXC?
[09:31] <wgrant> The instructions are like half the size.
[09:32] <lifeless> +1
[09:32]  * wgrant mauls.
[09:54] <wgrant> jml: Just ran various tests successfully without 2.6, so I'll drop it from the deps.
[10:01] <jml> wgrant: yay
[10:28] <jml> wgrant: do you know why TestArchivePrivacySwitching is in LaunchpadZopelessLayer?
[10:28] <wgrant> jml: Probably because whoever wrote it was wrong.
[10:29] <jml> wgrant: heh.
[10:29] <wgrant> jml: It should be ZopelessDatabaseLayer or DatabaseFunctionalLayer, since it probably doesn't need librarian etc.
[10:29] <jml> wgrant: yeah, trying DFL now.
[10:29] <wgrant> The difference between those two is now pretty much just the permission model.
[10:29] <wgrant> Zopeless is still PermissiveSecurityPolicy
[10:30] <jml> ah cool.
[10:31] <jml> wgrant: how much work does "pretty much" hide?
[10:31] <wgrant> jml: Working out what FunctionalTestSetup etc. does that is different.
[10:32] <wgrant> I merged most of it in a large branch series in September, but am yet to obtain the courage to complete the merge.
[10:32] <wgrant> Becauze Zope testing setup stuff is somewhat intimidating.
[10:32] <wgrant> It's also not clear quite how it's best to do it.
[10:33] <jml> yeah.
[10:33] <wgrant> But I suspect an attribute on the test class to specify the security policy might work.
[10:33] <wgrant> s/work/not be as terrible/
[10:33] <jml> that's what I was thinking
[10:33] <jml> and then one by one change the test classes to do something better.
[10:34] <jml> I wonder if there's a better mechanism than attribute (subclassing maybe?)
[10:35] <wgrant> StupidLegacyTestCase? :)
[10:35] <jml> well, we need to separate concerns
[10:35] <jml> StupidLegacyPermissiveTestCase
[10:35] <wgrant> Heh
[10:36] <jml> actually, you could probably do something with testtools's `run_tests_with` thing.
[10:36] <jml>         publisher.prepareBreezyAutotest()
[10:36] <wgrant> That's actually not a terrible idea.
[10:36] <wgrant> Run away
[10:36] <jml> oh yeah, that needs the librarian
[10:36] <wgrant> It does, yeah.
[10:37] <wgrant> Because inserting fake LFAs is hard, I guess.
[10:37] <wgrant> It tries to upload chroots.
[10:39] <wgrant> It could be taught not to participate in such stupidity, though.
[10:40] <wgrant> I'm not sure if our test suite's antics are back to being hilarious rather than depressing yet.
[10:45] <jml> I'm guessing getPubSource has side-effects that belie its name
[10:45] <wgrant> Oh yes
[10:46] <wgrant> makePubSourcePlusSomeOtherBitsActually
[10:46] <wgrant> You can usually get away with the factory's makeSourcePackagePublishingHistory these days
[10:46] <wgrant> SoyuzTestPublisher is deprecated and new usage of it incurs wrath.
[10:49] <jml> oh
[10:49] <jml> that's nice
[10:49] <jml> ISTR the last time I tried this sort of thing the accepted wisdom was "use SoyuzTestPublisher because you'll never be able to get it right any other way"
[10:52] <jml> is there a safe way to use the Librarian in tests without using a layer that provides it?
[10:59] <lifeless> no
[10:59] <lifeless> the layer is a thin shim on the fixture now
[10:59] <wgrant> jml: The appropriateness of STP depends on the test.
[10:59] <lifeless> but you still need all the bits joined together
[10:59] <wgrant> You can sometimes use the FakeLibrarian.
[11:00] <wgrant> Translations uses it for something in like one test.
[11:02] <jml> If there were a safe way, then lots of test runs could be made a bit faster easily. I could, for example, switch this test to ZopelessDatabaseLayer and then just use that safe way to run this test with the librarian.
[11:02] <lifeless> zopeless is no cheaper than zopeful
[11:03] <jml> lifeless: I wasn't contending that point.
[11:03] <jml> ZopelessDatabaseLayer is heaps cheaper than LaunchpadZopelessLayer though.
[11:04] <jml> librarian, memcache and rabbit all take their toll.
[11:09] <cjwatson> I don't seem to have much luck with FakeLibrarian, usually.  Maybe I'm not smart enough.
[11:09] <cjwatson> I tend to get incomprehensible storm tracebacks.
[11:25] <jml> battery threat!
[11:30] <jml> https://code.launchpad.net/~jml/launchpad/narrow-commercial-celebrity/+merge/104236 up for review.
[11:30] <jml> rick_h_: poor chap, you always seem to end up with my sad offerings.
[11:30] <rick_h_> jml: hah, all good
[11:30] <jml> I have to go find electricity. Will be back sooner than you'd like.
[11:30] <czajkowski> and yet he comes back for more
[11:30] <czajkowski> cant be that bad
[11:31] <rick_h_> jml: ok, going to grab some grub, so will take me longer than you'd like :P
[12:00] <jml> ok. I'm back.
[12:02] <jml> rick_h_: are you far into reviewing that branch, because I thought of some cleanups that I can tack on to it.
[12:02] <czajkowski> jml: we have date/times now for the LP clinic at uds https://wiki.ubuntu.com/UDS-Q/LaunchpadClinic
[12:03] <rick_h_> jml: I'm peeking at it, but please go ahead and update and I'll get back to it in 10 then
[12:28] <jml> rick_h_: ok, finally done
[12:28] <rick_h_> jml, ok, working on another review atm, but will get to it shortly
[12:28] <jml> rick_h_: 30s per test run has a surprisingly strong negative effect on speed.
[12:29] <rick_h_> jml: tell me about it :/
[12:30] <wgrant> jml: I'm pretty sure it hasn't become worse since you defected. I guess you've just repressed the tramautic memories :(
[12:31] <jml> wgrant: oh, I'm sure that's the case.
[12:31] <StevenK> The brain does repress bad memories.
[12:31] <jml> otoh, the nice thing with working on LP is there's so much obvious stuff to do
[12:31] <jml> it's very hard to get stuck.
[12:31] <wgrant> Indeed.
[12:31] <wgrant> Indeeeeeeed.
[12:31] <wgrant> So much to delete.
[12:32] <wgrant> Like Translations, Answers, Blueprints.
[12:32] <wgrant> And Soyuz to rip out.
[12:32] <jml> or update, or fix, or refactor.
[12:32] <jml> yeah
[12:32] <jml> ripping out the buildmaster would be fun
[12:32] <jml> step 1, rationalize the transactions
[12:32] <wgrant> It, Soyuz and Translations have no business at all being in LP core.
[12:32] <wgrant> The others might have some justification.
[12:32] <jml> step 2, xmlrpc (or whatever) interface
[12:32] <jml> step 3, yoink!
[12:33] <wgrant> Yep
[12:33] <wgrant> It just turns into a process which bridges the LP and buildd XML-RPC interfaces.
[12:33] <jml> chunks of lp.codehosting could be ripped out pretty easily too.
[12:33] <wgrant> I'm likely to rip out lp.services.sshserver into a separate project in the next few months.
[12:33] <wgrant> As part of destroying poppy.
[12:33] <wgrant> It's mostly self-contained.
[12:33] <jml> wgrant: oh, I made lp:txsshserver once upon a time with roughly that intent
[12:33] <jml> wgrant: maybe you should take over that project when you do it?
[12:34] <wgrant> Maybe indeed.
[12:34] <jml> it has no users.
[12:34] <wgrant> All the better!
[12:34] <jml> hmm. maybe I killed it :\
[12:34] <wgrant> One thing I do like about Code(hosting) is that the architecture isn't entirely stupid, unlike say most of the rest of LP.
[12:34] <wgrant> apart from branchrevision.
[12:35] <jml> wgrant: aww shucks.
[13:03] <jml> is the a graph of LP LoC over time?
, but cjwatson had a better one of the delta
[13:04] <wgrant> I'm not sure how accurate ohloh's is.
[13:05] <rick_h_> heh, wasn't ready to seem my name up there in that
[13:06] <rick_h_> but as a re=me so it's ok :)
[13:07] <rick_h_> jml: so you're not removing the concept of commercial ppas, but this single getCommercialPPA helper then?
[13:07] <jml> rick_h_: that's right.
[13:08] <rick_h_> ok, cool
[13:08] <StevenK> ohloh's one tends to be out-of-date and imprecise
[13:08] <jml> rick_h_: if we remove the commercial concept entirely, well, this is half (hah!) the work
[13:08] <rick_h_> jml: just making sure I'm following, saw the sea of red but some bits left and wanted to make sure I was 'getting' it right
[13:08] <jml> :)
[13:08] <StevenK> jml: The Soyuz's team blood, sweat and tears (mostly tears) went into making IArchive.commercial!
[13:09] <jml> StevenK: sunk cost fallacy.
[13:09] <wgrant> Woah
[13:09] <jml> StevenK: Sorry, I meant to say that we really appreciate it and hope some day we can return the favour.
[13:09] <wgrant> Never seen someone brave enough to invoke that on LP before :)
[13:09] <StevenK> jml: Oh, I know it's a sunk cost, I'm just saying think of our tears. :-)
[13:09] <rick_h_> tears wash away easily with some soap and water...all good
[13:10] <StevenK> wgrant: You mean what I said?
[13:10] <wgrant> No, the sunk cost fallacy.
[13:10] <StevenK> Ah.
[13:10] <wgrant> It could be applied to harmlessly remove 90% of our functionality :)
[13:10] <rick_h_> how dare you use logic and management terminology in here! :)
[13:11]  * StevenK removes 90% of the JS, thereby removing the need for convoy or jsbuild.
[13:11]  * rick_h_ watches the site go boom!
[13:11] <StevenK> It already was earlier today.
[13:12] <rick_h_> phew, glad I missed it then
[13:12] <wgrant> Production thrice, qastaging once.
[13:12] <jml> wgrant: well, there you'd compare cost/benefit of deleting with cost/benefit of user migration
[13:12] <wgrant> Fun day.
[13:12] <rick_h_> ugh, what went kaput?
[13:12] <jml> oh, also, perplexing thing: https://code.launchpad.net/~jml/txsshserver/trunk (200); https://code.launchpad.net/txsshserver (404)
[13:13] <wgrant> jml: Deactivated project, probably.
[13:13] <jml> ah ok
[13:13] <wgrant> "This project is currently inactive"
[13:13] <jml> rick_h_: anyway, I don't have commit so if you approve of that branch please land it for me.
[13:13] <rick_h_> jml: ah ok will do
[13:13] <rick_h_> going to have to footnote you on my ec2 bill :P
[13:14] <jml> rick_h_: I left two LP instances running accidentally, I think to support some pair programming. I have a $300+ bill from last month.
[13:14] <rick_h_> ouch!
[13:14] <jml> wgrant: how come you are so low on ohloh?
[13:14] <wgrant> jml: Hm?
[13:15] <rick_h_> I'm constantly afraid of that. I have two of my own I keep running to have to keep thinking "hmmm, 2 ok, >2 doh!"
[13:15] <sinzui> wallyworld, got a bill for $1,500
[13:15] <sinzui> It ran for 45 days
[13:15] <rick_h_> oooh...45 days?!
[13:15] <wallyworld> sinzui: for ec2?
[13:15] <rick_h_> that must have been pre the large instances?
[13:15] <jml> wgrant: you don't appear on http://www.ohloh.net/p/launchpad/contributors
[13:15] <sinzui> yes
[13:15] <wallyworld> ah, my bill
[13:15] <rick_h_> I'd have thought 45 days would be higher
[13:15] <wgrant> jml: I'm probably on like the third page.
[13:15]  * wgrant hunts.
[13:15] <jml> wgrant: 2nd
[13:16] <rick_h_> when I see these start ups with 100s of ec2 servers I cringe at that monthly bill
[13:16] <wgrant> Ah, not too bad.
[13:16] <wgrant> I am the top committer of the last 12 months, though :)
[13:16] <StevenK> I think I'm on like the 6th page. :-(
[13:16] <sinzui> We can all run starry-eyed into the arms of canonistack
[13:16] <wgrant> Although sinzui is close behind.
[13:16] <jml> hmm.
[13:17] <rick_h_> sinzui: yea, are there instructions for that?
[13:17] <jml> I don't know how to get that report from ohloh
[13:17] <StevenK> sinzui: Sounds good to me. Except no one seems to care.
[13:17] <wgrant> jml: Code Analysis
[13:17] <wgrant> jml: You can click on people in the legend to turn them off.
[13:17] <wgrant> (ie. to dispose of PQM)
[13:17] <wgrant> I'm not quite sure how it picks who to show.
[13:17] <wgrant> Looks vaguely like the top 5 of the last year and then the top 5
[13:18] <wgrant> of all time
[13:18] <sinzui> me? I have done bugger all for 12 months. I am atrifying.
[13:18] <rick_h_> jml: so side curiousity here, is this how people are getting listed in the software center? They have a commercial ppa and that's listed out as apps in software center?
[13:19] <jml> rick_h_: yeah, that's right.
[13:19] <jml> rick_h_: but only for commercial (i.e. they cost money) apps
[13:19] <rick_h_> jml: right, the newish paid apps stuff
[13:19] <jml> yep
[13:20] <rick_h_> ok, just curious, wasn't sure how that stuff worked and this review has the brain thinking
[13:20] <wgrant> jml: Aren't the proprietary free apps also there?
[13:20] <wgrant> eg. Vendetta Online
[13:20] <wgrant> Or whatever that free one is
[13:20] <jml> this work we're doing with LP now is aimed at people being able to upload apps to developer.ubuntu.com and have them packaged and published to a PPA automatically
[13:21] <jml> wgrant: I don't know about proprietary free.
[13:21] <cjwatson> wgrant,jml: http://people.canonical.com/~cjwatson/tmp/loc.png is a currently-up-to-date graph of delta per commit.  But it's kind of hard to read; it looks mostly nice and negative but the net change over that time period is in fact +2755.
[13:21] <jml> wgrant: I know that libre+gratis goes to extras (or the archve)
[13:21] <wgrant> jml: I like to pretend that extras doesn't exist :)
[13:21] <jml> :)
[13:21] <wgrant> cjwatson: :(
[13:22] <jml> cjwatson: do you have a graph of the integral of that?
[13:25] <cjwatson> jml: that's ohloh's graph, isn't it?
[13:25] <cjwatson> I guess you might want zoomed in and zero-based
[13:25] <jml> oh yeah.
[13:25] <jml> I think I'll just hook up bzr & ggplot2 in my own spare time :)
[13:25] <StevenK> Some counter on lpqateam.c.c would be nice.
[13:25] <jml> what I want is a command that tells me my score.
[13:26] <rick_h_> haven't you heard, you need graphite graphs these days to be cool
[13:26] <StevenK> I just want to see if I'm negative.
[13:26] <rick_h_> with hourly commit points and fancy colored moving charts
[13:27] <rick_h_> and we all put them on a display on the wall over our desks
[13:27] <StevenK> rick_h_: Speak for yourself, hipster.
[13:27] <rick_h_> lol
[13:27] <rick_h_> I'm on LP, I think that disqualifies me for any hipster movements
[13:27] <StevenK> Haha
[13:28] <wgrant> Nah
[13:28] <wgrant> GitHub's too mainstream
[13:28] <rick_h_> when we get some BDD JS going then we'll chat about rushing house hipster
[13:28] <jml> StevenK: yeah, if I'm negative that's a good thing to know. But I also want to be able to compete with people
[13:28] <rick_h_> where's jono when you need some new achievement badges
[13:29] <rick_h_> "negative LoC leader for month of May"
[13:29] <StevenK> If we hook the LOC metric into Ubuntu Achievements, someone will get fired.
[13:29] <rick_h_> lol
[13:29] <jml> StevenK: how so?
[13:29] <StevenK> ... or I'll quit in disgust.
[13:30] <StevenK> jml: There's an implied :-P
[13:30] <cjwatson> jml: but, http://people.canonical.com/~cjwatson/tmp/loc-cum.png
[13:30] <jml> StevenK: oh, I just didn't (don't yet) get the joke.
[13:31] <jml> cjwatson: thanks!
[13:31] <StevenK> I'm waiting for my UI work to end on prod.
[13:31] <wgrant> I wonder how it changes if we filter out database/schema
[13:31] <wgrant> Since that's append-only.
[13:32] <StevenK> Then I can rip out 2,000 lines of stuff.
[13:33] <cjwatson> jml: (easy once I remembered 'smooth cumulative'.  gnuplot is ugly as sin but quick to hook trivial stuff up in.)
[13:33] <jml> cjwatson: ah cool.
[13:34] <wgrant> bzrlib + matplotlib ftw
[13:35] <jml> yeah. I've enjoyed the stuff I've done recently with R & ggplot2
[13:35] <wgrant> Enjoying R? I think you're doing it wrong.
[13:35] <jml> webulating graphs is too hard though
[13:35] <jml> i.e. taking a one-off graph made and turning into something that can be hit on the web and is always relatively up-to-date
[13:37] <jml> wgrant: the thing I really like is that it's really easy to use my data analysis again at a later point. Mostly my Python graphing stuff doesn't seem to work out like that.
[13:37] <wgrant> Yeah
[13:37] <jml> Maybe I should try that panda thing GvR posted on G+ about.
[13:37] <jml> also, R is actually pretty good for interactive mucking around with data
[13:38] <jml> even if it's rather poor considered as a language.
[13:39] <jml> distributionmirror_prober: is that a candidate for splitting out?
[13:40] <wgrant> Yes.
[13:40] <wgrant> It should in all probability be a separate database.
[13:40] <wgrant> The interactions with LP internals are minimal.
[13:40] <wgrant> But it should probably be deleted and replaced with an existing third-party solution
[13:41] <jml> ooh
[13:42] <jml> its tests are an affront.
[13:43] <jml> I'd like to fix them, but removing them & the code they test entirely would be much better.
[13:44] <wgrant> Exactly.
[13:45] <wgrant> Lots of Launchpad components like to pretend they're solving a unique problem.
[13:46] <wgrant> So stuff like that happens :)
[13:46] <jml> :)
[13:46] <jml> james_w: hello
[13:46] <james_w> hi
[13:46] <jml> I'm wondering whether I should make a celebrity team for which membership means "you can set commercial"
[13:47] <jml> or whether I should re-purpose the software_center_agent celebrity somehow
[13:47] <wgrant> Or add a field to distribution which permits it.
[13:47] <jml> wgrant: e.g. Distribution.commercial_team
[13:48] <jml> ?
[13:48] <wgrant> nasty_proprietary_software_people, but yeah :)
[13:48] <jml> hmm.
[13:49] <deryck> wgrant, hey.  I saw something in scrollback about lp being down for you guys.  are there incident reports for this?  or anything I can look at.
[13:49] <jml> I need a better name than either of them.
[13:50] <wgrant> deryck: https://wiki.canonical.com/IncidentReports/2012-04-26-LP-release-performance-issues covers the first two of the day's issues, the other one is in the hands of IS, I believe.
[13:50] <jml> 'commercial_admin' would be pretty good if it weren't already a heavily-loaded term
[13:50] <wgrant> Yeah
[13:50] <deryck> wgrant, thanks!
[13:50] <wgrant> deryck: Alternatively we can replace commercial with a shut_up flag that anyone can set, I guess.
[13:51] <wgrant> s/anyone/the archive owner/
[13:51] <wgrant> Bah
[13:51] <wgrant> jml: ^^
[13:51] <deryck> heh.
[13:51]  * deryck votes for shut_up flah, too, FWIW. :)
[13:51] <deryck> flag
[13:51] <wgrant> jml: I thought my team name was pretty catchy, though.
[13:51] <jml> bigjools seemed to dislike the idea
[13:52] <jml> wgrant: sure, it has zing. It could be easily misunderstood though.
[13:52] <rick_h_> abentley: ping, can you take a peek at this for me when you get settled? https://code.launchpad.net/~wallyworld/launchpad/revoke-access-delete-subscriptions-job/+merge/104198
[13:53] <abentley> rick_h_: Yes, I'll have a look at that.
[13:53] <rick_h_> abentley: want to make sure it's all celery approved, not sure about the any special needs/better ways of doing things for that.
[13:53] <rick_h_> thanks!
[13:53] <jml> wgrant: as it would read to me as "all of the propriety uploaders to d.u.c" rather than "the d.u.c bots"
[13:53] <wgrant> True, true.
[13:53] <james_w> jml, I'd lean towards re-using the celebrity, but wouldn't be against a field on distribution I don't think
[13:54] <jml> james_w: one thing about the celeb is that (I think) it's a Person not a Team
[13:54] <wgrant> jml: It can be either.
[13:54] <jml> wgrant: I mean that currently it is a Person.
[13:54] <wgrant> People are teams, war is peace, etc.
[13:54] <wgrant> Ah
[13:54] <jml> wgrant: I don't know what the fallout of changing it would be.
[13:55] <wgrant> It would break.
[13:55] <wgrant> I think.
[13:55] <jml> well, yeah, that's generally what we mean by "fallout of change"
[13:55] <wgrant> Since I believe the XML-RPC API may actually set up an interaction as it.
[13:55] <wgrant> Which won't work if it's a team.
[13:55] <wgrant> But I may be misremembering, and it just passes it in as arguments to horrid methods, in which case it might work.
[13:56] <wgrant> There's one easy way to find out...
[13:56] <jml> I'm more worried about how we use it on our side
[13:56] <jml> that's harder to co-ordinate.
[13:56] <wgrant> Howso?
[13:56] <wgrant> How do you use it on your side?
[13:56] <wgrant> I thought you mostly poked the xmlrpc-private API
[13:57] <jml> I don't know.
[13:57]  * jml looks
[13:58] <wgrant> Ah
[13:58] <wgrant> There's a single xmlrpc-private call, getOrCreateSoftwareCenterCustomer
[13:58] <wgrant> Rest must be through lazr.restful.
[13:58] <jml> yeah
[13:58] <wgrant> So, you could create a team, add the agent to it, then make that team the celeb.
[13:59] <rick_h_> jml: have a bug to tie the MP against please?
[13:59] <rick_h_> well guess there's not a lot of QA for this removed is there :/
[14:01] <jml> rick_h_: https://bugs.launchpad.net/launchpad/+bug/992622
[14:01] <_mup_> Bug #992622: getCommercialPPAs is not needed <tech-debt> <Launchpad itself:New> < https://launchpad.net/bugs/992622 >
[14:01] <jml> rick_h_: as you wish.
[14:02] <rick_h_> jml: yea, that ec2 land wants things to all be setup right, picky little thing. :) thanks. Landing now
[14:02] <jml> rick_h_: thanks! :)
[14:08] <jml> hmm
[14:09] <jml> I have to write this code somehow.
[14:11] <jml> I prefer the 'shut_up' field approach, but suspect that it'll be rejected as Whiggery.
[14:12] <jml> james_w: am probably going to start implementing it as field on Distro
[14:12] <wgrant> My vote goes to shut_up.
[14:12] <wgrant> I don't see a good reason to restrict it.
[14:13] <james_w> shut_up on archive, or subscription?
[14:13] <wgrant> Probably archive.
[14:13] <wgrant> But I'm not quite sure.
[14:13] <james_w> either way I think I prefer that too
[14:14] <james_w> assuming it's roughly similar in implementation time
[14:14] <sinzui> jcsackett, ping
[14:14] <james_w> no need for this to be special
[14:14] <jml> I guess one archive owner could use it to secretly upload evil stuff to a PPA without other owners finding out
[14:14] <jcsackett> sinzui: pong
[14:14] <jml> james_w: I think they are both similar and both fairly small.
[14:14] <wgrant> jml: Hm?
[14:14] <jcsackett> rick_h_: enjoying your first day of full reviewing? :-)
[14:14] <sinzui> jcsackett,  is there a card on the board that interests you?
[14:14] <rick_h_> jcsackett: wheeeeee
[14:14] <wgrant> jml: AIUI the flag would just control subscription notifications.
[14:14] <james_w> if it has to be available in the UI then it will probably be more work to implement, and be quite LOC-positive
[14:14] <jcsackett> sinzui: i was looking at banners without javascript.
[14:15] <wgrant> jml: "subscription" refers to packages from the archive, not upload notifications.
[14:15] <jml> wgrant: ah, not upload notifications.
[14:15] <wgrant> Upload notifications go to the uploaders, which are the owner and anyone with an ArchivePermission
[14:15] <sinzui> jcsackett, do you want to talk about it?
[14:15] <jcsackett> sinzui: yes. hangout?
[14:15] <sinzui> yes
[14:15]  * sinzui looks for headphones
[14:17] <jml> so, it would just be suppress_subscription_notifications or something to that effect.
[14:17] <jml> ok.
[14:18] <jml> I'm going to relocate to somewhere that serves food & has internet.
[14:18] <sinzui> jcsackett, I am in the google messenger  hangout
[14:19] <jcsackett> hm. it's telling me you're offline
[14:19] <sinzui> My head is
[14:19]  * sinzui tries again
[14:54] <rick_h_> abentley: thanks for checking that out, appreciate the assist
[14:54] <abentley> rick_h_: no problem.
[15:17] <jml> I haven't submitted a db patch since we switched to nodowntime stuff. what do I need to know?
[15:20] <jml> https://dev.launchpad.net/Database/LivePatching doesn't seem to mention anything about adding, removing or renaming columns
[15:27] <jml> james_w: so I'm thinking of doing this shut-up patch by re-purposing 'commercial' and then following up with a db patch to rename it.
[15:27] <jml> james_w:  thoughts?
[15:28] <jml> anyone?
[15:34] <rick_h_> jml: looking for the doc
[15:35] <rick_h_> my understanding is you need to have a MP against the devel-db branch and get it ok'd by db peeps (lifeless/etc) and then it has to land first
[15:35] <cjwatson> jml: https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
[15:36] <rick_h_> there you go and https://dev.launchpad.net/WorkingWithDbDevel
[15:36] <jml> that doc doesn't say anything about removing or renaming columns
[15:36] <cjwatson> adding columns comes under cold patches
[15:36] <jml> nor is there anything I can see that categorizes new columns as either 'hot' or 'cold'
[15:36] <jml> cjwatson: ah
[15:36] <cjwatson> by virtue of not being explicitly under hot patches
[15:37] <jml> right.
[15:37] <cjwatson> so it'll be a fastdowntime thing
[15:37] <jml> thanks.
[15:38] <cjwatson> if you're removing columns, you'll need to make sure that no appservers are using the old columns first via a nodowntime deployment (I don't know if there are stricter requirements beyond that)
[16:30] <jml> just got a weird error trying to run 'ec2 test': http://pastebin.ubuntu.com/960374/
[16:31] <jml> does the erstwhile Launchpad team hang out somewhere else these days?
[16:32] <rick_h_> sorry, no idea there
[16:33] <rick_h_> repeatable error? e.g. not temp bzr connection issue?
[16:33] <jml> I'm trying to repeat it now.
[16:33] <jml> just repeated it.
[16:33] <jml> it happens in the initial connection.
[16:34] <rick_h_> k, sec, pulling that branch ( was going to peek at it for review anyway) and I'll test it
[16:36] <cjwatson> jml: public IP problem again?  what does checkip.amazon.com say?
[16:36] <cjwatson> sorry, checkip.amazonaws.com
[16:36] <jml> heh, it might be because...
[16:37] <jml> cjwatson: yeah, that seems to be it.
[16:37] <cjwatson> when I was landing a branch from Millbank last week I hardcoded Millbank's external address in ec2test/account.py
[16:37] <jml> cjwatson: I'm actually in a pub tethered to my phone
[16:38] <rick_h_> what's the 'public ip problem'?
[16:38] <jml> cjwatson: but checkip says 10.92.29.164 and mumak.net (which I'm ssh'd into) says something else
[16:38] <jml> cjwatson: I'm angry enough to patch lp-dev-utils to have an option for that.
[16:38]  * jml hulks out
[16:38] <rick_h_> ruh roh
[16:39] <rick_h_> ok, well running fine here so glad it's something special
[16:42] <jml> rick_h_: thanks.
[16:42] <cjwatson> I have no idea why checkip thinks it's clever to honour X-Forwarded-For.
[16:43] <jml> Well, what is honour, if not an occasional rejection of the pragmatic?
[16:44] <cjwatson> We could use http://whatismyip.akamai.com/ instead
[16:45] <cjwatson> WFM
[16:46] <jml> me to
[16:46] <jml> oo
[16:47] <cjwatson> rick_h_: the problem is that amazon's checkip service is stupid and if you're connecting to it through an HTTP proxy it returns the address that the proxy sees (via the X-Forwarded-For HTTP header)
[16:47] <cjwatson> this is useless if you're trying to find the address amazon will see for you, since proxies are often on private networks
[16:47] <rick_h_> cjwatson: ah ok, and this is setup as the address you can ssh from to the new instance?
[16:47] <cjwatson> right
[16:47] <rick_h_> gotcha
[16:58] <rick_h_> bah, can't edit a review comment after the fact? oh well
[16:58] <rick_h_> jml: small note on my end, but yea the others will be better to go over things.
[16:59] <james_w> jml, +1 on repurposing commercial
[16:59] <james_w> jml, if we strip away the other meanings of it, rename it, and allow anyone to set it if they own the PPA then it works for us, is a pretty minimal change, and IMO reduces the maintainence burden by taking something special-purpose and arcane and makes it pretty obvious
[16:59] <james_w> rick_h_, looks like your comment on https://code.launchpad.net/~jml/launchpad/drop-special-commercial-permissions/+merge/104270 got truncated
[16:59] <jml> james_w: yeah. and we've actually got line count credit on this already from deleting getCommercialPPAs
[16:59] <rick_h_> james_w: well, I was going to say I'll invite people from the permissions/etc squad but then realized they were already up there and missed hitting delete before submitting
[16:59] <rick_h_> and I can't edit it back out, so I fail
[16:59] <james_w> rick_h_, cool
[17:04]  * jml has to go soon :(
[17:07] <jml> ok. this doesn't seem to actually *work*, but it's a start: https://code.launchpad.net/~jml/lp-dev-utils/public-ip/+merge/104273
[17:07] <jml> I have to go.
[19:09] <lifeless> flacoste: hiya
[19:10] <flacoste> hi lifeless
[19:14] <lifeless> flacoste: hows the sprint going ?
[19:24] <lifeless> bwah... deryck: around ? if so, could you put bug 901892 as the external board # on https://canonical.leankitkanban.com/Boards/View/14028616/101173433
[19:24] <_mup_> Bug #901892: bug search cache makes next/prev return old data <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901892 >
[19:26] <deryck> hi lifeless
[19:27] <deryck> lifeless, done
[19:33] <lifeless> deryck: thanks
[19:35] <jelmer> hi deryck, lifeless
[19:35] <deryck> hi jelmer
[19:35] <jelmer> lifeless: I'm wondering if it would make sense to kill the code review notification emails; they just seem to be noise at this point. Do you have any opinions on that?
[19:36] <jelmer> IIRC you brought it up a while ago, but I can find the relevant log at the moment to confirm.
[19:38] <lifeless> code imports ?
[19:39] <lifeless> yes, I proposed removing at minimum all the non-action ones (successes, initial-failures)
[19:39] <lifeless> I have no particular opinion about non-initial failures.
[19:41] <jelmer> It's probably easiest to remove both at the same time
[19:41] <jelmer> I've stopped paying attention to the non-initial failures, and I haven't seen anybody else use them.
[19:58] <lifeless> sure
[19:58] <lifeless> mpt: hoya
[19:58] <mpt> hi lifeless
[19:58] <lifeless> so, what questions are you and ev trying to answer with this mtbf thing ?
[20:12] <mpt> lifeless, for the MTBF specifically, the first question: (1) How reliable is Ubuntu?
[20:13] <mpt> For example: Is it more reliable than it was last week? Is it more reliable than the previous release? And how much of a difference would it make if all Ubuntu users had installed all updates?
[20:25] <sinzui> what is MTBF? mounted tabernacle bee floggers
[20:29] <lifeless> yes
[20:29] <lifeless> mpt: those are good questions
[20:29] <lifeless> mpt: I have one; how do we define reliable, and is it a definition users would agree with ?
[20:30] <mpt> lifeless, that introduces the issue that our definition of reliability will expand over time
[20:31] <mpt> lifeless, in Ubuntu 12.04 it is "programs other than the kernel don't crash"
[20:31] <mpt> In Ubuntu 12.10 it may be something like "programs (including the kernel) don't crash, and don't hang for more than 20 seconds"
[20:33] <mpt> Depending on time and difficulty, it may also include other kinds of errors: package installation failures, debconf prompts, etc
[20:35] <mpt> So, one thing we've discussed is keeping track of when we started recording error type, to fairly answer questions like: "Is Ubuntu 13.04 more or less reliable than Ubuntu 12.10, using the same standards that we were using for Ubuntu 12.10?"
[20:36] <mpt> otherwise each successive release would seem less reliable than the last, even if it's more reliable. :-)
[20:37] <mpt> lifeless, but there will always be swathes of problems that aren't caught in an automated way, e.g. "this program thinks it copied all these files but it didn't".
[20:38] <mpt> And a user might classify that under "reliability".
[20:39] <mpt> If a test suite is the fence at the top of the cliff, Whoopsie and Daisy are the ladies with pens and clipboards standing at the bottom.
[20:44] <lifeless> mpt: I like that image
[20:45] <lifeless> mpt: so, are you factoring in time in your equations? And how?
[20:48] <mpt> lifeless, no, we'd completely overlooked it
[20:49] <mpt> If by "time" you mean "uptime"
[20:49] <mpt> The current formula implicitly assumes that every machine is running 24/7
[21:03] <lifeless> mpt: perhaps the client could report TSLF in each report, or some approximation thereof.
[21:06] <mpt> lifeless, I think it will have to, yes. Which means we run the risk that the system clock changed in the intervening period, but oh well.
[21:06] <lifeless> mpt: that should be rare though
[21:06] <lifeless> mpt: and rare events should be discarded as outliers
[21:07] <mpt> I suppose system clock adjustments will be roughly normally distributed anyway :-)
[21:19] <david0rk> hi all
[21:20] <david0rk> anyone on?
[22:22] <david0rk> nevermind.  I figured out using a bit of common sense and tinkering.   BAZAAR IS AWESOME!
[22:23] <SpamapS> hrm, I want to make sure I understand. bug #915505 means we can't use bzr builder format 0.4, right?
[22:23] <_mup_> Bug #915505: bzr: ERROR: exceptions.AttributeError: 'cStringIO.StringI' object has no attribute 'split' <launchpad-buildd:Triaged> <Open Sesame: libaccounts-glib:New> < https://launchpad.net/bugs/915505 >
[22:23]  * SpamapS is sad, that would let him automate stable releases building into a PPA
[22:29] <bac> hi lifeless
[22:35] <jelmer> SpamapS: yes
[22:36] <SpamapS> jelmer: and will LP have to be migrated to precise before that works?
[22:36] <jelmer> SpamapS: no, it will just need to be updated to a newer python-debian or we can update bzr-builder to support the older python-debian.
[22:36] <SpamapS> ah
[22:38] <jelmer> SpamapS: the fix for bzr-builder would be trivial, it's mostly the management around it to get it deployed to the builders that's more complicated.
[22:41] <SpamapS> Will probably be easier to just automate my packaging branch to have a new debupstream every time I commit to my stable branch
[22:42] <SpamapS> but, thats a pity, as 'latest-tag' is really cool
[22:43] <lifeless> bac: hi there
[23:04] <aquarius> I have a program, not of my creation, which calls launchpadlib. Launchpadlib, if you've not been authed to use LP, opens up LP in a browser and then blocks, waiting for you to auth the token. Is there some envar or similar I can set so that launchpadlib will just fail that request instead because it's not being run interactively?
[23:07] <cjwatson> aquarius: It uses the webbrowser module in Python's standard library, which honours BROWSER, so you could set that to ... err, something appropriate
[23:07] <aquarius> aha! sneaky :)
[23:08] <cjwatson> Not entirely sure how to make that fail immediately rather than spinning.
[23:08] <StevenK> export BROWSER=/bin/false ?
[23:08] <StevenK> That might be a little mean.
[23:08] <aquarius> I shall see if it works :)
[23:08] <cjwatson> I don't think that will work; webbrowser will notice the non-zero exit code and fall back to its next option, as I read it.
[23:09] <cjwatson> But /bin/true might work.
[23:09] <cjwatson> Hopefully you'll get EndUserDeclinedAuthorization.
[23:10] <cjwatson> I don't see another way to control it in an entirely different process.  If you can modify the program then you can pass in a different authorization_engine.
[23:11] <cjwatson> You might have to write a miniature browser that actually interacts with the URL it's given and presses the Decline button or whatever it's called.
[23:11] <aquarius> doesn't seem to honour BROWSER, afaict :(
[23:11] <wgrant> You won't get a button -- you'll be redirected to the login page.
[23:11] <aquarius> ah, I'll try the /bin/true trick :)
[23:11] <cjwatson> Really?  It's right there in webbrowser.py.
[23:12] <cjwatson> Mm, maybe launchpadlib will just think you haven't got round to logging in and deciding yet. :-(
[23:12] <aquarius> that's what happens
[23:13] <aquarius> no browser opens (no problem there), but then lplib just sits about waiting for me to finish authing.
[23:13] <aquarius> darn.
[23:13] <aquarius> and I can't see how to get out of that code, either
[23:13] <cjwatson> Are you trying to do something headlessly?
[23:13] <aquarius> yep
[23:13] <aquarius> specifically, run the test suite for quickly
[23:14] <cjwatson> That sounds like a bug in the test suite, then.  Surely it shouldn't fail without a Launchpad login.
[23:14] <cjwatson> (Or hang.)
[23:14] <aquarius> it *is* a bug in the test suite
[23:15] <aquarius> but the test suite's a terrifying mass of shell scripts which I do not have time to entirely rewrite from scratch :P
[23:15] <aquarius> so I was hoping for a semi-quick fix to make the tests fail, rather than just hang indefinitely :)
[23:16] <cjwatson> Quickest fix would be to give them a login someho. :-)
[23:16] <cjwatson> *somehow
[23:16] <aquarius> that's approach number 2 if I can't find a way to do this, which is fractionally vanishingly more proper a solution :)
[23:17] <aquarius> and I don't think this is doable, annoyingly enough. Ah well.
[23:17] <cjwatson> I thought bribing didrocks was the traditional answer to quickly problems, anyway
[23:18] <aquarius> s/didrocks/mterry/ in this particular case, and he said "yeah the test suite is weird, feel free to just put in a separate test which is not tied to it" :-)
[23:18] <aquarius> so I have plenty of get-out clauses
[23:19] <aquarius> I just thought I'd try and do things properly (well, sorta) rather than super-hackily for once, and lo! I am thwarted. there is a lesson here :)