[00:19] <lifeless> StevenK: I -really- prefer stub to get a lookin with the narrow exception of him being away for an extended period; he is back today.
[00:21] <StevenK> lifeless: I would have really prefered to already have it landed, but you disappeared yesterday afternoon. Fine, I will wait for stub.
[00:22] <lifeless> StevenK: I EOD'd at 1700 here :)
[00:22] <lifeless> StevenK: and cynthia has a cold, so it really was EOD
[00:22] <lifeless> StevenK: in any event, I would have said the same thing yesterday
[00:27] <lifeless> so bigjools, tell me about messaging servers
[00:32] <StevenK> Do we have some report that reports if any patch in db-stable/devel isn't applied to prod?
[00:49] <lifeless> no, but we have a bug asking for one
[00:52] <StevenK> wgrant: Product done. Would about Distribution?
[00:53] <wgrant> StevenK: Yes
[00:53] <StevenK> Bah, okay.
[00:54] <wgrant> You expected otherwise?
[00:54] <StevenK> I didn't, actually.
[01:23] <StevenK> wgrant, wallyworld__: https://code.launchpad.net/~stevenk/launchpad/product-distribution-accesspolicy/+merge/96499
[01:25]  * wallyworld__ has a look
[01:27] <wallyworld__> StevenK: you probably also need to create a proprietary policy when a product has a commercial subscription created for it
[01:30] <StevenK> Hmmm
[01:31] <StevenK> wallyworld__: So I'm not sure if products go from non-commercial to commercial, or if they are created as commercial
[01:32] <wallyworld__> StevenK: i *think* they are created as non commercial and then the subscription is added by an admin
[01:32] <wallyworld__> ?
[01:33]  * StevenK can't see what method on IProduct is called for that.
[01:34] <wallyworld__> i don't think it's on IProduct
[01:35] <wallyworld__> StevenK: didn't you add a factory method to create a subscription?
[01:35] <StevenK> That just creates a CommercialSubscription
[01:36] <StevenK> We don't have CommercialSubscriptionS{et,ource}, just it.
[01:37] <wallyworld__> i think redeemSubscriptionVoucher does it perhaps?
[01:37] <wallyworld__> which is on IProductPublic
[01:37] <StevenK> Have you managed to read that function without your eyes bleeding?
[01:37] <wallyworld__> not yet
[01:38] <wallyworld__> yes, it looks like that is the one
[01:39] <StevenK> Right
[01:39] <StevenK> The garbo job doesn't handle that process either
[01:40] <wallyworld__> not sure what to do when the subscription expires though. do we remove the policy?
[01:40] <StevenK> Right, that's the tricky question.
[01:40] <wallyworld__> wgrant: ? ^^^^
[01:42] <wgrant> wallyworld__: We don't know how that will work yet.
[01:42] <wgrant> wallyworld__: This is just for the initial migration.
[01:42] <wallyworld__> ok, just checking :-)
[01:42] <wgrant> At what stage we create the policies once the New World is complete, we don't know.
[01:43] <bigjools> lifeless: helleau
[01:43] <lifeless> bigjools: hellauo
[01:44] <bigjools> like the accent
[01:44] <bigjools> what do you want to know then?
[01:45] <lifeless> were they useful, what interface did they have, would you use one again, and whatever you think I should know about them
[01:46] <wallyworld__> wgrant: so, for StevenK's branch, do we want to add a proprietary policy when a voucher is redeemed?
[01:46] <wgrant> wallyworld__: No, proprietary doesn't exist yet.
[01:46] <wgrant> wallyworld__: We'll redefine at what point any policies are created at all later on.
[01:47] <wgrant> The first step is to get bugs onto the new model, which just needs these two created at all times.
[01:47] <wallyworld__> ok. the current work i've done in the ui shows proprietary as an option in the disclosure picker for commercial projects
[01:47] <wgrant> This is just a dirt cheap way to achieve that.
[01:47] <lifeless> bigjools: can go voice if that would be easier ;)
[01:47] <bigjools> lifeless: can do
[01:47] <bigjools> lifeless: I'll make it quick - I am starving :)
[01:48] <lifeless> skype/hangout?
[01:48] <wallyworld__> StevenK: r=me
[01:49] <bigjools> lifeless: I'll skype you
[01:50] <bigjools> lifeless: well I would do if you were on
[01:50] <bigjools> ah skype is being crap
[01:52] <lifeless> I despair about my ADSL
[01:53] <bigjools> I despair about random desktop lockups
[01:54] <StevenK> lifeless: In your case, the A is not Asynchronous, but Abominable.
[01:56] <bigjools> lifeless: frozen
[02:00] <bigjools> lifeless: for f....
[02:03] <bigjools> lifeless: reliable internets in NZ then?
[02:03] <lifeless> will be if you answer, switching to tablet's skype rather than faildsl
[02:04] <bigjools> lifeless: not geting your call
[02:04] <bigjools> tried to call you and you didn't answer either :)
[02:44] <wgrant> StevenK: Any test failures from that branch yet?
[02:44] <wgrant> StevenK: I'd expect some in test_bug_mirror_legacy_access_triggers
[02:48] <bigjools> wallyworld__: are you at home?
[02:48] <wallyworld__> yeeees?
[02:49]  * wallyworld__ is nervous now
[02:49] <bigjools> wallyworld__: eeeexcellent, can I pop round in a bit and print and scan sumting pleez :)
[02:49] <wallyworld__> it will cost you
[02:49] <bigjools> wine?
[02:49] <bigjools> I can pay in wine
[02:49] <wallyworld__> we'll discuss it
[02:51] <bigjools> ooerr missus
[02:51]  * bigjools out
[03:19] <stokachu> could someone check out my headers and see if im missing anything when doing an authenticated call to me?ws.op=searchTasks? http://pastebin.ubuntu.com/873995/
[03:20] <stokachu> it times out, but doing an anonymous call works
[03:25] <stokachu> i dont have OAuth realm="https://api.launchpad.net/" but that is optional according to the oauth specs
[03:26] <wallyworld__> wgrant: StevenK: what would i need to do to get a review of a branch which merely renames stuff, but the line count is high
[03:26] <lifeless> timeout -> do you get an OOPS in the response headers ?
[03:26] <StevenK> wallyworld__: Beg.
[03:26] <stokachu> lifeless: yea
[03:26] <lifeless> ... which is ?
[03:26]  * wallyworld__ is on his knees
[03:27] <wallyworld__> https://code.launchpad.net/~wallyworld/launchpad/fix-sharing-terminology-948083/+merge/96506
[03:27] <stokachu> lifeless: one sec :)
[03:27] <stokachu> lifeless: apparently a code update is in progress at this very moment
[03:28] <stokachu> im not sure how long those take
[03:30] <lifeless> stokachu: you're testing on staging ?
[03:30] <stokachu> lifeless: yea
[03:30] <lifeless> try qastaging
[03:30] <stokachu> ok
[03:30] <lifeless> it should be up
[03:31] <stokachu> lifeless: OOPS-7f4c62461a1ee30fcb05df7f03a8a3ef
[03:31] <stokachu> lifeless: fwiw i just tried on production and it worked
[03:33] <wgrant> Heh, GitHub seems to have lost all their CSS
[03:33] <stokachu> they had ssh problems earlier
[03:33] <wgrant> stokachu: Bug searches except in small projects will tend to time out on staging.
[03:33] <StevenK> wgrant: So I have an attribute that requires view to see and edit to change. Do I need a decorator for that?
[03:33] <wgrant> And qastaging.
[03:33] <wgrant> StevenK: That applies to most attributes in Launchpad.
[03:33] <wgrant> StevenK: It goes on IBugView
[03:34] <wgrant> We don't usually use interfaces to specify edit permissions.
[03:34] <stokachu> wgrant: ok, is this not the correct approach i should take then?
[03:34] <StevenK> wgrant: Okay, so the IBugEdit I'm making is pointless?
[03:34] <wgrant> StevenK: Although in some simple cases (eg. if launchpad.Edit grants edit privileges on everything that launchpad.View can see) you can use interfaces.
[03:34] <wgrant> StevenK: IBugEdit would conventionally be things that you require launchpad.Edit to see.
[03:34] <wgrant> stokachu: I don't know... what are you trying to do? :)
[03:35] <StevenK> wgrant: There's a bunch of methods you need .Edit to call
[03:35] <stokachu> wgrant: im just trying to get my profile and see bugs (public/private) im assigned to
[03:35] <wgrant> StevenK: Then they belong on IBugEdit
[03:35] <stokachu> so far ive just been investigating searchTasks
[03:35] <wgrant> Also, it should be illegal to have two people talking with the same first two letters.
[03:35] <stokachu> then ill append like &assignee='adam-stokes' ?
[03:35] <wgrant> One of you needs to go awawy :)
[03:35] <stokachu> LOL
[03:36] <stokachu> it is getting late i could go play some dawn of war
[03:36] <wgrant> stokachu: So, if you just want assigned bugs, specify assignee=, yeah
[03:36] <StevenK> Let's get stub in here too!
[03:36] <StevenK> Then we can have three!
[03:36] <wgrant> stokachu: By default it will do things like search by bugs you've commented on.
[03:36] <wgrant> stokachu: Which can be very very slow.
[03:36] <stokachu> wgrant: ah ok
[03:37] <lifeless> stokachu: so yeah, thats a simple code/performance issue for us
[03:37] <stokachu> so with assignee can it be just my name? like searchTasks&assignee=adam-stokes
[03:37] <lifeless> stokachu: however
[03:37] <lifeless> User: Anonymous User
[03:37] <lifeless> DB id: Anonymous
[03:37] <wgrant> stokachu: Probably needs to be assignee=/~admin-stokes
[03:37] <lifeless> -> it hasn't logged you in
[03:37] <wgrant> Er
[03:37] <wgrant> s/admin/adam/
[03:37] <stokachu> wgrant: ok :)
[03:38] <stokachu> lifeless: ah i didn't get new credentials on qastaging
[03:38] <stokachu> can never have to many staging servers i guess :)
[03:38] <lifeless> stokachu: so you probably should if you want confirmation that the auth works ;)
[03:38] <stokachu> lifeless: haha ok ill re-auth, in your opinion is it better to test against qastaging or staging?
[03:39] <stokachu> i dont want to anger the gods by messing with production
[03:40] <lifeless> you can use either
[03:40] <stokachu> ok cool.. thanks for everyones help :D
[03:41] <StevenK> wallyworld__: I think this branch I'm in the middle of will turn out bigger.
[03:43] <wgrant> wallyworld__: addPillarSharee -> sharePillarInformation?
[03:43] <wgrant> I've already tried to make nouns out of these; it doesn't work well :)
[03:43] <wallyworld__> wgrant: that sounds reasonable
[03:43] <wallyworld__> i have bigjools here at the moment
[03:43] <StevenK> wallyworld__: Why did you remove 2011 from the copyright in sharingservice?
[03:43] <wallyworld__> because i only started that file in 2012
[03:43] <StevenK> But it's a renamed file :-)
[03:44] <wallyworld__> the original file was started in 2012 also
[03:44] <StevenK> Not according to the copyright :-)
[03:44] <wallyworld__> it was just a drive-by
[03:44] <wallyworld__> the copyright was originally wrong
[03:44] <wallyworld__> cut and paste
[03:44] <wallyworld__> from elsewhere
[03:44] <StevenK> Fine
[03:44] <StevenK> I was mostly trolling
[03:45] <wallyworld__> :-)
[04:06] <StevenK> Hmmmm.
[04:07] <StevenK> A bunch of methods that are in IBugEdit are mutators for properties in IBugView.
[04:07] <StevenK> I might split them all out into IBugPrivacy
[04:14] <wgrant> confused
[04:14] <wgrant> StevenK: What?
[04:17] <StevenK> wgrant: So private and security_related are defined in IBugView, but there are few methods in IBugEdit that opperate on them
[04:18] <StevenK> Same for duplicateof, which is in IBugView, but markAsDuplicate is in IBugEdit and marked as a mutator of it.
[04:20] <wgrant> StevenK: Right, that's normal.
[04:21] <wgrant> Or does lazr.restful really not like cross-interface mutator_fors?
[04:21] <wgrant> It should work...
[04:21] <wgrant> As long as you define them in the right order/
[04:22] <StevenK> wgrant: pyflakes is complaining
[04:22] <wgrant> Oh?
[04:22] <StevenK> lib/lp/bugs/interfaces/bug.py:840: undefined name 'private'
[04:22] <StevenK> lib/lp/bugs/interfaces/bug.py:841: undefined name 'private'
[04:22] <StevenK> And so on
[04:23] <wgrant> Well, yes, that's not going to work.
[04:23] <wgrant> IBugView['private']
[04:23] <wgrant> This is Python, not magic :)
[04:23] <nigelb> haha
[04:23] <StevenK> But, it should be!
[04:24] <wallyworld__> bigjools has left the building
[04:26] <StevenK> Right, fixed.\
[04:26] <StevenK> So now pyflakes is happy.
[04:26]  * StevenK tries 'make'
[04:28] <StevenK>     @mutator_for(IBugView['private'])
[04:28] <StevenK>   File "/home/steven/launchpad/lp-sourcedeps/eggs/zope.interface-3.5.2-py2.6-linux-x86_64.egg/zope/interface/interface.py", line 552, in getDescriptionFor
[04:28] <StevenK>     raise KeyError(name)
[04:28] <StevenK> KeyError: 'private'
[04:28] <wgrant> IBugPublic['private']
[04:29] <StevenK> Oh damn it, I should have realised that myself.
[04:32] <bigjools> wallyworld__: back now and I can't stop thinking about your special offer
[04:33] <StevenK> Oh, bwahaha
[04:34]  * StevenK tries VERY hard to not quotefile that comment
[04:34] <StevenK> wgrant: http://pastebin.ubuntu.com/874044/ Zope hates me
[04:34] <wallyworld__> bigjools: i've been thinking about you too
[04:34] <bigjools> and other things beginning with w
[04:35] <stokachu> watermelon!
[04:35] <wgrant> StevenK: One of your interfaces probably inherits another one.
[04:35] <wgrant> StevenK: That is wrong.
[04:35] <wgrant> And bad and evil.
[04:35] <wgrant> And won't even work.
[04:35] <StevenK> I don't think
[04:35] <StevenK> so
[04:36] <StevenK> wgrant: http://pastebin.ubuntu.com/874045/
[04:36] <wgrant> Perhaps the wrong interface is inherited IPrivacy?
[04:36] <wgrant> StevenK: Recall that one of those interfaces redefines bits of IPrivacy
[04:37] <wgrant> So declaring access on both won't work.
[04:37] <StevenK> Right, and linked_branches is probably in the exactly same boat
[04:37] <wgrant> I would assume so.
[04:44] <StevenK> wgrant: Working, but I'm not sure about IBugPublic inheriting from IPrivacy.
[04:45] <wgrant> It's fine if it's OK.
[04:45] <stokachu> wgrant: are you or anyone else able to see private bugs assigned to me specifically?
[04:45] <stokachu> i keep pulling up 0 bugs
[04:46] <wgrant> stokachu: How are you filtering to private bugs?
[04:47] <stokachu> 'request' => 'GET /1.0/~adam-stokes?ws.op=searchTasks&assignee=https%3A%2F%2Fapi.launchpad.net%2F1.0%2F%7Eadam-stokes
[04:47] <stokachu> thats my urlencoded request being made, after ive retrieved my oauth token
[04:50] <stokachu> http://pastebin.ubuntu.com/874054/ heres my full response request
[04:50] <wgrant> stokachu: https://launchpad.net/api/1.0/~adam-stokes?ws.op=searchTasks&assignee=https%3A%2F%2Flaunchpad.net%2Fapi%2F1.0%2F~adam-stokes shows a private bug for me (it uses normal webapp cookies, so you can use your browser rather than an OAuth client)
[04:50] <wgrant> So I suspect you're not authing properly.
[04:52] <wgrant> stokachu: Alternatively, are you sure you authorized your token for private data?
[04:52] <stokachu> hmm I have a header defined with my Authorization credentials
[04:52] <stokachu> i used the change anything button
[04:52] <wgrant> That should be fine.
[04:52] <wgrant> What happens if you just "GET /1.0/~" with appropriate auth headers?
[04:53] <wgrant> Hm
[04:53] <wgrant> I'd expect the Authorization header to start with 'OAuth ', I think.
[04:54] <stokachu> so OAuth realm is not optional?
[04:54] <StevenK> wgrant: I'm getting a bunch of ForbiddenAttribute failures, including one that is in the ZCML, but not the interface.
[04:54] <stokachu> http://pastebin.ubuntu.com/874061/ here is the response to a /~
[04:56] <wgrant> stokachu: That's a response to /~adam-stokes
[04:56] <wgrant> stokachu: Which?
[04:56] <wgrant> Bah
[04:56] <wgrant> StevenK: Which?
[04:57] <StevenK> Oh, hahaha. maybeConfirmBugtasks is listed in the ZCML, not in the interface, but is defined in the model.
[04:57] <wgrant> stokachu: 'OAuth realm' isn't an atom. 'OAuth' is the authorization scheme, realm is a field like oauth_nonce
[04:57] <StevenK> wgrant: ForbiddenAttribute for things like name, tags, date_last_updated
[04:57] <wgrant> You may be able to omit the realm field
[04:57] <wgrant> StevenK: On what operation?
[04:58] <StevenK>     current_bug.date_last_updated = now
[04:58] <StevenK> ForbiddenAttribute: ('date_last_updated', <Bug at 0xcefb390>)
[04:58] <wgrant> StevenK: Right, you need to define set_schema or set_attributes
[04:58] <stokachu> wgrant: http://pastebin.ubuntu.com/874063/ :(
[04:58] <wgrant> stokachu: That's more like it
[04:58] <StevenK> wgrant: I should keep the enormous list of set_attributes for lp.Edit?
[04:58] <wgrant> stokachu: Prepend 'OAuth ' to your Authorization value
[04:59] <wgrant> StevenK: Probably, yes.
[04:59] <wgrant> StevenK: Note that some of them are obsolete.
[04:59] <wgrant> Particularly on BugTask
[04:59] <wgrant> Attributes that don't exist any more.
[04:59] <StevenK> I'll try setSchema IBugView
[05:00] <wgrant> No.
[05:00] <wgrant> Unless all those attributes were formerly settable.
[05:00] <wgrant> But I suspect they were not.
[05:00] <StevenK> You spoil all of my fun
[05:00] <wgrant> See Branch for a reasonable example of how to do things.
[05:00] <StevenK> But okay, grabbing the list
[05:02] <StevenK> I think it's only hits{,timestamp}
[05:02] <StevenK> Oh, community{score,timestamp}
[05:03] <wgrant> See what I mean?
[05:03] <StevenK> And a few others
[05:03] <StevenK> Right, so there's 9 left
[05:03] <StevenK> I think that's a reasonable list
[05:03] <wgrant> Most should have setters.
[05:03] <wgrant> So not too many should need naming explicitly.
[05:05] <stokachu> SUCCESS!
[05:05] <StevenK> Hm, this branch isn't too bad. It's just going to be hell to get reviewed.
[05:05] <wgrant> stokachu: It works better when you specify an auth scheme? :)
[05:06] <stokachu> wgrant: lol sooo much better
[05:06] <StevenK> wgrant: My branch that makes ProductSet add AccessPolicy fails with missing db perms. :-(
[05:06] <wgrant> StevenK: I am unsurprised.
[05:06] <wgrant> StevenK: Grant INSERT on AP to anything with INSERT on Distribution or Product
[05:06] <wgrant> Problem solved.
[05:07] <StevenK> That's disgusting.
[05:07] <StevenK> But yeah.
[05:09] <StevenK> Looks like just write and updateremoteproduct
[05:09] <StevenK> Oh, bah
[05:10] <StevenK> Forgot to add maybeConfirmBugtasks to IBugSomething
[05:33] <StevenK> wgrant: I think I've got it working.
[05:33] <StevenK> Which is kind of awesome, considering what I did to IBug.
[05:35] <wgrant> :)
[05:36] <StevenK> Sadly, the branch is 1215 lines, but I don't think that can really be helped given just how big IBug is.
[05:38] <wgrant> Indeed.
[05:38] <wgrant> I won't kill you.
[05:38] <StevenK> Oh, are you offering to review it, then? :-)
[05:38] <wgrant> Depends on when it's proposed :)
[05:38] <wgrant> I'll be reading the diff anyway...
[05:39] <StevenK> Passed tests:   1159
[05:39] <StevenK> Failed tests:      2
[05:39] <StevenK> 1 failed test due to the fact that the stream is still being written to, and another which I've fixed.
[05:40] <StevenK> I think that's enough to prove the changes are okay enough to toss at ec2.
[05:42] <wgrant> Sounds reasonable.
[05:43] <StevenK> I'm not in danger of the instance terminating after 20 minutes because make failed, or getting the dreaded message that it tried to send a mail and failed because the message was so damn large.
[05:48] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/force-ibug-into-line/+merge/96513
[06:02] <StevenK>         linux_source_bug_dupe.syncUpdate()
[06:02] <StevenK>     ForbiddenAttribute: ('syncUpdate', <Bug at 0xfb78dd0>)
[06:02] <StevenK> I can't see syncUpdate() in either the model or interface, but the ZCML allows it.
[06:03] <wgrant> StevenK: Done
[06:03] <wgrant> syncUpdate is probably an SQLObject method
[06:03] <wgrant> Anything using it is probably wrong
[06:03] <wgrant> Delete the call and see if the test still works.
[06:04] <StevenK> There's a bunch of them
[06:04] <wgrant> Does the test explain why they're there?
[06:05] <StevenK> I've not checked, just noticed they were failing
[06:05] <wgrant> No
[06:05] <wgrant> So, delete them.
[06:05] <wgrant> Flushes are largely implicit now.
[06:05] <StevenK> wgrant: maybeConfirmBugtasks is in the model, and was in the ZCML, so by rights it should be on the interface?
[06:07] <wgrant> StevenK: You're probably not going to be confirming tasks due to an edit if you can't edit the bug.
[06:08] <StevenK> Hmmm, it's only called by the bug model itself
[06:08] <wgrant> Not by BugTask?
[06:09] <wgrant> No
[06:09] <wgrant> So kill it from the interface.
[06:09] <cody-somerville> Are there any plans to rename the arm restricted arch family to armel?
[06:10] <wgrant> It's unprecedented manual SQL with minimal benefit.
[06:10] <wgrant> Doable, but there are no plans.
[06:11] <cody-somerville> How much trouble would it be to do? With it being 'arm' currently, I have to special case the arch in our automated project setup code.
[06:11] <StevenK> wgrant: personIs{DirectSubscriber,AlsoNotifiedSubscriber,SubscribedToDuplicate} were also declared under IBugSet, their docstrings meantioned IBug and they were in IBug's ZCML.
[06:12] <wgrant> bigjools: Around?
[06:12] <bigjools> yes
[06:12] <cody-somerville> wgrant, or alternatively, would it be possible to introduce armel and just leave arm there as legacy?
[06:12] <wgrant> cody-somerville: No
[06:13] <wgrant> bigjools: UPDATE processorfamily SET name='armel' WHERE name='arm'?
[06:13] <wgrant> (see above)
[06:13]  * bigjools tries to think what that will break
[06:13] <wgrant> The DAS archtags are already all armel.
[06:14] <bigjools> yeah
[06:14] <wgrant> The only people it can break are commercial admins.
[06:14] <wgrant> And I don't care about them :)
[06:14] <bigjools> pfff
[06:14] <bigjools> wth can see proc family?
[06:14] <StevenK> But PFs should not change. :-(
[06:15] <bigjools> y'know
[06:15] <bigjools> this should not change, as StevenK says
[06:15] <wgrant> Why not?
[06:16] <wgrant> It's wrong, and nothing except the UI and API use the anem.
[06:16] <wgrant> name
[06:16] <bigjools> why is there not an armhf?
[06:16] <cody-somerville> There is an armhf.
[06:16] <wgrant> arm is armel
[06:16] <wgrant> armhf is armhf
[06:16] <bigjools> oh ok - feh I was looking at dev data not prod
[06:17] <wgrant>   6 | arm     | ARM Processors                        | The ARM family of processors, primarily used in embedded applications. | t
[06:17] <wgrant>   9 | armhf   | ARM hard float processors             | ARM processors with an FPU                                             | t
[06:17] <StevenK>   File "/home/steven/launchpad/lp-branches/force-ibug-into-line/lib/lp/bugs/model/bug.py", line 2071, in _markAsDuplicate
[06:17] <StevenK>     duplicate_of.maybeConfirmBugtasks()
[06:17] <StevenK> ForbiddenAttribute: ('maybeConfirmBugtasks', <Bug at 0x159d31d0>)
[06:17] <StevenK> wgrant: ^
[06:18] <StevenK> That is what prompted me to add it to the interface.
[06:18] <wgrant> StevenK: Ah, of course. It's called from the other bug.
[06:18] <cody-somerville> Also, does anyone know why https://api.launchpad.net/1.0/unr/+milestone/unr-9.10 is returning a HasBug object instead of Milestone object?
[06:18] <bigjools> wgrant: ok do it
[06:18] <wgrant> cody-somerville: launchpadlib is thpecial
[06:19] <StevenK> wgrant: Okay, I'll re-add it to the interface.
[06:19] <cody-somerville> wgrant, lol. say again?
[06:19] <wgrant> cody-somerville: unr is a project group
[06:19] <wgrant> Project groups are evil.
[06:19] <wgrant> Don't do it :)
[06:22] <StevenK> wgrant: So I drop IBugAdmin, where should heat_last_updated and setHeat() go?
[06:23] <wgrant> StevenK: Well, I was going to say to just drop them from the interface. But setHeat seems to be entirely unused.
[06:23] <wgrant> Except by tests.
[06:23] <StevenK> And heat_last_updated is used by garbo
[06:23] <wgrant> Yes.
[06:23] <bigjools> what download limits does internode have?
[06:23] <wgrant> But not through the interface.
[06:23] <wgrant> bigjools: About 10 different ones.
[06:24] <StevenK> wgrant: Right, so I should remove the setHeat tests and then IBugAdmin can just die?
[06:24] <wgrant> Ranging from probably 10GB to a terabyte.
[06:24] <bigjools> oh well, hope I don't blow this place's limit
[06:24] <StevenK> You can probably ring up and ask
[06:24] <wgrant> StevenK: Assuming the tests aren't doing anything interesting, yep.
[06:25] <StevenK> wgrant: It seems to just be doc/bug-heat.txt
[06:27] <StevenK> wgrant: So I can drop those sections of the doctest
[06:27] <wgrant> StevenK: Sounds reasonable.
[06:29] <wgrant> cody-somerville: Should be renamed.
[06:29] <cody-somerville> wgrant, Okay, thanks.
[06:30] <bigjools> wgrant: is there a broadband comparison/guide site that lists all providers instead of just the crappy ones?
[06:31] <StevenK> Haha
[06:31] <wgrant> bc.whirlpool.net.au
[06:31] <wgrant> Although I can't talk to it...
[06:32] <wgrant> Whirlpool down. That's amusing.
[06:32] <bigjools> broadbandguide is a joke
[06:33] <wgrant> Looks like it's been down for about 15 minutes.
[06:33] <nigelb> bigjools: I heard broadband down there is a joke anyway ;)
[06:33] <wgrant> How odd.
[06:34] <bigjools> nigelb: an ISP walked into a bar ...
[06:34] <nigelb> hehe
[06:35] <StevenK> wgrant: Now where people complain about NBN?
[06:35] <wgrant> Coalition headquarters?
[06:35] <StevenK> Haha
[06:36] <StevenK> Which is even more pointless than complaining about it on Whirlpool.
[06:39] <bigjools> odev setup, why u wear out my ssd
[06:51] <StevenK> wgrant: I've had to remove a bunch of bug-heat.txt
[06:57] <StevenK> Ah crap. I need IHasLinkedBranches on IBugView due to linked_branches, but that causes a test failure because linkBranch and unlinkBranch require Edit
[06:59] <wgrant> StevenK: Probably best to have IHasLinkedBranches inherited by IBug directly, and name the attributes in configure.zcml
[07:01] <wgrant> bigjools: Whirlpool is back, btw
[07:01] <bigjools> wgrant: yeah looking at it
[07:02] <bigjools> wgrant: it's a bit confusing for a newb
[07:02] <bigjools> I dunno what half the terms are
[07:04] <StevenK> bigjools: Did you search?
[07:05] <bigjools> StevenK: for what?
[07:05] <StevenK> bigjools: From bc.whirlpool.net.au there's a "or your can search for ..." which is a link
[07:05] <StevenK> wgrant: http://pastebin.ubuntu.com/874142/
[07:06] <StevenK> wgrant: Oh, this is not helped that IBugView has its own definition of linked_branches
[07:06] <bigjools> is it worth doing the phone via internode?
[07:07] <StevenK> wgrant: And IBugView['linked_branches'] is subtly different
[07:08] <bigjools> StevenK: don't see that link
[07:08] <wallyworld__> internode is expensive
[07:08] <StevenK> bigjools: Oh, bc.whirlpool -> QLD, search
[07:08] <bigjools> StevenK: ta
[07:08] <bigjools> wallyworld__: you're a stuck record :)
[07:09] <wallyworld__> but it's true
[07:09] <wallyworld__> it's your money i guess
[07:09] <bigjools> wallyworld__: I'm comparing all on offer before I decide
[07:10] <StevenK> Just note that TPG couldn't run a reliable network if their lives depended on it.
[07:10] <wallyworld__> np. i'm just trying to stir up StevenK
[07:10] <bigjools> wallyworld__: +1
[07:10] <wallyworld__> StevenK: tpg has been 10000% reliable for me
[07:10] <wallyworld__> not one issue
[07:10] <bigjools> only 10000?
[07:10] <wallyworld__> fast and unlimited
[07:11] <bigjools> what d/l speeds?
[07:11] <StevenK> And yet you ping timeout at least 4 times a day and your IRC nick keeps growing underscores.
[07:11] <nigelb> pwned.
[07:11] <bigjools> hah
[07:12] <bigjools> 10000 is not enough of a superlative, let's say 1000000%
[07:14] <wallyworld__> bigjools: i get about 9000Mbps
[07:14] <wallyworld__> StevenK: i don't timoeout
[07:15] <wallyworld__> i disconnect when i change rooms etc
[07:15] <wallyworld__> nothing to do with tpg
[07:15] <wallyworld__> sometimes my wireless router craps out also
[07:15] <wallyworld__> tpg is innocent
[07:16] <bigjools> they are popular on whirlpool
[07:16] <wallyworld__> for good reason
[07:16] <StevenK> Yes, they're cheap and crap.
[07:18] <wallyworld__> why do you say crap?
[07:18] <wallyworld__> evidence?
[07:18] <bigjools> StevenK: be specific?
[07:18] <StevenK> wgrant: Right, the only thing I can't figure out how to solve with my current horrible solution is the @accessor_for() for getVisibileLinkedBranches()
[07:18] <wallyworld__> i know several people who use them
[07:18] <wallyworld__> and they are all very happy
[07:19] <StevenK> I have had a few friends here who got random dropouts, slow speeds, and the support would follow a script
[07:19] <bigjools> I miss my UK ISP
[07:20] <wgrant> It depends on region.
[07:20] <wallyworld__> i reckon 9000Mbps is ok given i'm a fair way from the exchange
[07:20] <wgrant> They're massively oversubscribed on most Melbourne nodes.
[07:20] <wallyworld__> and have a rats nest of cabling to the socket
[07:20] <wgrant> People struggling to get 1Mbps
[07:20] <wgrant> Don't know how it is in QLD
[07:20] <wgrant> StevenK: What about it?
[07:21] <wgrant> StevenK: This should be no different from before.
[07:21] <StevenK> wgrant: http://pastebin.ubuntu.com/874160/
[07:22] <StevenK> wgrant: I had to remove linked_branches from IBugView, since IHasLinkedBranches also defines it.
[07:22] <wgrant> StevenK: Just move it into IBug
[07:22] <StevenK> I did
[07:22] <wgrant> What's with that insane "Please Zope" thing, then?
[07:23] <StevenK> wgrant: Because with linked_branches in IBugView and IHasLinkedBranches under IBug, Zope de-pramed its toys with the protectName traceback
[07:24] <wgrant> StevenK: That's why I said to move it to IBug
[07:24] <StevenK> Oh, move everything, right.
[07:24] <StevenK> And getVisibleLinkedBranches ?
[07:24] <wgrant> Everything that conflicts.
[07:27] <StevenK> Right, that looks ... acceptable.
[07:28] <StevenK> Certainly a fuckload better than it was.
[07:29] <StevenK> Hey wow, due to ripping out most of bug-heat.txt, I think I can remove dangerousGetAllBugs()
[07:30] <wgrant> Did you only rip out the relevant bits?
[07:31] <StevenK> wgrant: http://pastebin.ubuntu.com/874168/
[07:31] <StevenK> It uses setHeat with gay abandon
[07:32] <wgrant> StevenK: And the award for test that is rendered useless for no good reason goes to...
[07:32] <StevenK> Oh, so I can just remove the whole thing then? :-)
[07:32] <wgrant> I suggested that you rip it out, not remove every block that uses setHeat and then mangle the expected output of every other block to fit :)
[07:33] <StevenK> wgrant: Oh, you wanted me to delete the entire test?
[07:33] <wgrant> No
[07:33] <StevenK> I thought so. :-(
[07:33] <wgrant> Delete the *relevant* bits of the test.
[07:33] <wgrant> Not delete parts of it, and render the rest useless.
[07:34] <StevenK> Well, setHeat is still on the model, so I can just rSP call it
[07:34] <wgrant> Where that is unavoidable, yes.
[07:34] <wgrant> In most cases you don't need to use setHeat, however.
[07:34] <StevenK> I don't see how
[07:34] <StevenK> Given my reading of the test
[07:35] <wgrant> -First, we'll set the heat of all bugs so that none of them are out of
[07:35] <wgrant> -date.
[07:35] <wgrant> That doesn't not require setHeat
[07:35] <StevenK> Oh, IStore(Bug).set(heat=0) ?
[07:35] <StevenK> I *think*
[07:35] <StevenK> It's been a while
[07:35] <wgrant> Read the test.
[07:35] <wgrant> It cares about the timestamp.
[07:35] <wgrant> Not the heat value.
[07:37] <wgrant> (Your solution is almost valid, but it's probably not what the test wants to test.)
[07:39] <StevenK> Right, so I should set all heat_last_updated = now
[07:39] <wgrant> Most likely.
[07:40]  * StevenK tries to work out how to do that with Storm
[07:41] <StevenK> And then dangerousGetAllBugs() can die too
[07:41] <wgrant> IStore(Bug).find(Bug).set(heat_last_updated=UTC_NOW)
[07:45] <StevenK> stub: Hai, can you look at https://code.launchpad.net/~stevenk/launchpad/db-add-information_type/+merge/96290 ?
[07:51] <stub> k
[07:55] <stub> StevenK: Is it possible to describe what an InformationType is?
[07:55] <stub> Its a very 'long cat is long' type comment description at the moment :-P
[07:58] <stub> 'Enum describing what type of information is stored and used to determine how the access policy is applied', or something like that if that isn't quite riht
[07:59] <stub> I do see that it will not be changing frequently, so I guess adding yet another column to Bug and Branch is fine.
[07:59] <wgrant> It will change infrequently and we're about to stop doing searches over Bug anyway :)
[08:00] <wgrant> It replaces the private and security_related flags.
[08:08] <StevenK> wgrant: Do you agree with stub's comment for the two columns?
[08:08] <wgrant> I haven't looked at the MP.
[08:08]  * wgrant looks.
[08:09] <StevenK> I meant the SQL comment above
[08:09] <StevenK> 'Enum describing what type of information is stored and used to determine how the access policy is applied'
[08:09] <wgrant> There's a better one in the MP
[08:09] <StevenK> Right, I'll update the comment
[08:11] <StevenK> stub: Thank you for the review.
[08:11] <stub> np
[08:13] <wgrant> stub: FYI, https://code.launchpad.net/~wgrant/launchpad/bugtaskflat-db/+merge/96520 will be happening once StevenK's stuff is finalised and migrated on prod.
[08:13] <wgrant> Be afraid.
[08:14] <nigelb> I feel like a lot of conversations in this channel should be preserved in a QDB.
[08:18] <stub> Think I've seen most of that already.
[08:18] <wgrant> Yeah
[08:20] <wgrant> stub: We can't set user-specific connection limits in pgbouncer, can we?
[08:20] <wgrant> stub: That was garbo's problem.
[08:22] <stub> Bug #949740
[08:22] <_mup_> Bug #949740: No connection timeout makes transaction timeout unreliable <Storm:New> < https://launchpad.net/bugs/949740 >
[08:23] <wgrant> Ah, interesting.
[08:23]  * stub looks into user-specific connection limits
[08:23] <wgrant> Although there's no timeout in garbo.
[08:23] <wgrant> stub: I couldn't see any way to do it.
[08:23] <wgrant> But you may have more luck.
[08:25] <stub> We can, but we need to define it as a separate database (so connection to session_prod_garbo rather than session_prod)
[08:27] <stub> But we still need nagios checks that the pools are not full, so I don't think we gain much except complexity.
[08:27] <stub> Well... maybe protect against processes with potentially unlimited numbers of connections like the Librarian or django servers
[08:36] <lifeless> stub: hey
[08:37] <stub> ho
[08:37] <lifeless> stub: so, cynthia is having a terror night, going to pass on catching up if thats ok
[08:37] <stub> No probs. Want to make a time for tomorrow?
[08:37] <lifeless> stub: lets give it a shot :)
[08:37] <lifeless> my 4pm would be great
[08:38] <stub> You're at +13 now?
[08:38] <lifeless> stub: https://bugs.launchpad.net/launchpad/+bug/948786 - I spoke with Tom; if we automate master-slave cutovers we can allow safer upgrades of pg etc rather than squashing it into the schema change window
[08:38] <_mup_> Bug #948786: add an option to full-update.py to not restart pgbouncer when finished <canonical-losa-lp> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/948786 >
[08:38] <lifeless> stub: yeah
[08:38] <lifeless> (+13)
[08:40] <stub> Ok. In bed by 1:30am :)
[08:40] <lifeless> *snort*
[08:40] <lifeless> ok, /wave then see you tomorrow
[08:42] <stub> lifeless: Switching master/slave is pretty heavyweight, and if all you are doing is upgrading PG to a new point release way overkill.
[08:43] <stub> lifeless: Also, I certainly would want to defer any automated switchover to PG 9.1 + new replication
[08:44] <wgrant> Switchover with WAL streaming involves a bit of rsync.
[08:44] <wgrant> But I trust it to be a bit more reliable.
[08:44] <stub> lifeless: But it might just be a big catch-22, as switching master/slave roles requires a bit of downtime
[08:46] <wgrant> A neutered version of readonly mode would work extraordinarily well here :)
[08:46] <stub> (at least until we are able to use transaction pooling across the board, at which point we could pause db access, wait for all transactions to complete or kill them, switch roles, reconfigure pgbouncer, reenable access)
[08:48] <wgrant> stub: Can't we tell eg. pgbouncer to hold new connections, wait a few seconds for old ones to clear, then do the switch?
[08:48] <wgrant> That sounds nearer-term than letting us switch to transaction mode.
[08:48] <stub> (although I just opened a bug that would cause requests to OOPS if their connection attempts timed out)
[08:48] <StevenK> wgrant: Er, so, I think we should allow date_last_updated
[08:48] <StevenK> wgrant: steven@liquified:~/launchpad/lp-branches/force-ibug-into-line% grep Forbidden lp.log | cut -d\' -f2 | sort | uniq -c | sort -k1 -rn | head -n 1
[08:48] <StevenK>     300 date_last_updated
[08:48] <wgrant> StevenK: What broke?
[08:48] <StevenK> LOTS
[08:49] <wgrant> eunhelpful
[08:49] <stub> wgrant: Thats what I wrote. But it requires transaction pooling mode, as pgbouncer only notices when a transaction completes in that mode. It won't interrupt transactions in session mode as that might be interrupting cross-transaction resources like cursors or temporary tables.
[08:50] <StevenK> wgrant: Not sure how to get a list of failing tests from a subunit stream.
[08:50] <wgrant> stub: Bah, I meant s/pgbouncer/haproxy/
[08:50] <wgrant> stub: To avoid that issue
[08:50] <wgrant> Still requires that we turn evil scripts off.
[08:50] <stub> Yes. And appservers, as they don't reopen connections each transaction
[08:51] <stub> oh nm.
[08:51] <wgrant> Make haproxy hang, wait $TIMEOUT, stop pgbouncer, switch, reconfig pgbouncer, start pgbouncer, unhang haproxy
[08:52] <wgrant> (hopefully timeout will be <5s by then :))
[08:52] <stub> you can replace haproxy with pgbouncer there
[08:52] <wgrant> Can we?
[08:52] <stub> oic.
[08:53] <wgrant> Maybe if we taught the appserver that connection start hangs were to be expected.
[08:53] <wgrant> But ideally we'd somehow just hang master connections.
[08:53] <wgrant> Since slave connections aren't a problem.
[08:53] <adeuring> good morning
[08:54] <stub> wgrant: They are, which is why this is rather pointless for the most part. When we do a point release, we do it everywhere.
[08:54] <stub> pg point release upgrade
[08:54] <StevenK> wgrant: Failing tests: http://pastebin.ubuntu.com/874240/
[08:54] <wgrant> stub: But we don't have to do them all at the same time.
[08:54] <stub> No. If we want, we could do it three times with more downtime.
[08:54] <wgrant> Assuming we rework our store management to be HA
[08:54] <wgrant> Rather than failxploding
[08:55] <wgrant> stub: LP should pick an available slave or the master if no slave is available.
[08:55] <wgrant> Then we can murder slaves at will.
[08:55] <wgrant> And nobody will notice.
[08:55] <wgrant> StevenK: Tracebacks?
[08:55] <wgrant> s/s//
[08:56] <stub> With a suitably complex system, we might be able to catch all the states. But a system that complex will have more overall downtime because it is more complex.
[08:56] <StevenK> wgrant: I can copy the log to carob/something else if you like.
[08:56] <wgrant> StevenK: No. How widespread are the calls?
[08:56] <StevenK> wgrant: It's 2.3MiB uncompressed.
[08:57] <StevenK> wgrant: Like the count above, there are 300 calls to set date_last_updated that fail.
[08:57] <wgrant> StevenK: There are 300 tests that fail.
[08:57] <wgrant> StevenK: They won't all be distinct calls.
[08:58] <StevenK> No, there are 165 tests that fail, 300 calls.
[08:58] <wgrant> s/calls/callsites/
[09:00] <StevenK> A fair whack of them are in doctests.
[09:00] <StevenK> Where they are calling it directly.
[09:00] <lifeless> StevenK: cat stream | subunit-filter --no-skips | subunit-ls
[09:00] <wgrant> StevenK: Setting it directly!?
[09:01] <wgrant> stub: How is basic client-side DB failover complex? :)
[09:01] <StevenK> wgrant: Yes, setting date_last_updated directly.
[09:01] <StevenK>   File "/home/steven/launchpad/lp-branches/force-ibug-into-line/lib/lp/bugs/subs
[09:01] <StevenK> cribers/buglastupdated.py", line 31, in update_bug_date_last_updated
[09:01] <StevenK>     current_bug.date_last_updated = now
[09:01] <StevenK> That's another callsite.
[09:01] <StevenK> ForbiddenAttribute: ('date_last_updated', <Bug at 0xf0b63d0>)
[09:01] <lifeless> StevenK: or load it into testr
[09:01] <wgrant> StevenK: Oh, directly except not.
[09:02]  * lifeless goes again (someone rang our house phone... at 10pm!)
[09:02] <wgrant> StevenK: That function is probably the source of 99% of the exceptions.
[09:02] <StevenK> It is not
[09:02] <StevenK> From unittests, sure. doctests are fiddling with date_last_updated directly
[09:03] <wgrant> $ bzr grep '\.date_last_updated =' | grep -v tests | grep -v doc | grep -v translations | grep -v stories | grep -v answers | wc -l
[09:03] <wgrant> 1
[09:03] <stub> wgrant: scripting haproxy + pgbouncer was what I was talking about.
[09:03] <wgrant> (and that one is update_bug_date_last_updated)
[09:04] <StevenK> wgrant: Which is probably that callsite then
[09:04] <StevenK> wgrant: Right, but I can't rSP that :-(
[09:05] <wgrant> StevenK: Why not?
[09:05] <stub> wgrant: client-side db failover? yer, but that is for unexpected slave outages. For expected outages, we just do the redirections in pgbouncer.
[09:05] <wgrant> subscribers do it occasionally
[09:05] <StevenK> I don't like using rSP in non-test code
[09:05] <wgrant> StevenK: Sometimes it's justified. When there's a single callsite that's outside the model class only because someone thought subscribers were awesome, I think it's justified.
[09:06] <wgrant> stub: Why do them in pgbouncer? ISlaveStore can pick the first available slave. IMasterStore can pick the master, or display a "come back in 10 seconds" page if it's not available.
[09:08] <stub> wgrant: Because then the clients need to know where all the slaves actually *are* so it can make that choice. And because one use case is for reshaping the cluster, that means pushing configuration changes out and having them take effect.
[09:10] <wgrant> stub: Well, yeah, would need some means for determining the master dynamically. Not entirely sure how that would work. It may be by pgbouncer, but it would be nice to not have to reconfig pgbouncer in a reshape situation.
[09:12] <stub> We have to reconfigure something. pgbouncer is easy because it is running on the same host as we are run these admin scripts from.
[09:13] <wgrant> At minimum we have to reconfigure the databases to have a new master, so the ideal situation is that the appservers get that from postgres.
[09:13] <wgrant> But that seems like it could be hilariously awful.
[09:14] <stub> Yer. complex, leading to downtime because this sort of thing always breaks unless you invest hugely in all the testing.
[09:14] <wgrant> Anyway, I mainly suggested the sensible client-side slave fault tolerance as a solution to the 3x pg upgrade issue.
[09:15] <wgrant> If we can take a slave down without anybody noticing, things become easier.
[09:15] <stub> Except the other half of the connections that need a master :)
[09:16] <wgrant> It means that we no longer need to SSH across 3 hosts during downtime.
[09:17] <wgrant> And it paves the way to full nodowntime :)
[09:17] <stub> We can take a slave down with nobody noticing with pgbouncer. We just redirect launchpad_prod_slave_1 to a different database and deal with the existing sessions.
[09:18] <stub> And that is easy to automate, and even easier if we are running in transaction mode and have server connections returned to the pool after every transaction.
[09:19] <wgrant> That handles scheduled downtime, indeed.
[09:20] <wgrant> And admittedly the DB servers have been rather more reliable than the rest.
[09:21] <wgrant> But it seems sort of odd that we have this nice replicated DB setup, yet if any one of the three nodes goes down, LP goes down with it.
[09:23] <stub> It takes a lot of work and resources to do automated failover properly. It is pretty rare to be able to justify those sorts of resources, and because of this more often than not you end up causing downtime than stopping it.
[09:26] <stub> redundant slaves is the easier problem, and can be handled by the connection pool
[09:26] <stub> (in pgbouncer's case, it involves putting haproxy between pgbouncer and the databases)
[09:30] <wgrant> Perhaps.
[09:31] <wgrant> But we want things like SSO to get their noses out of our DB, which really requires us to have good availability.
[09:31] <wgrant> Read availability, that is.
[09:38] <wallyworld__> wgrant: can you recall the lp way to disable anchor? add "disabled" to the class? or something like that?
[09:40] <wgrant> wallyworld__: This isn't client-side rendered?
[09:40] <wallyworld__> wgrant: yes, but i need to dynamically disable a link depending on what the user clicks
[09:41] <wgrant> wallyworld__: The bug "Also affects" links use private-disallow, so perhaps there's not a real convention.
[09:41] <wgrant> wallyworld__: Or do you mean something other than hiding?
[09:42] <wallyworld__> wgrant: i want the "Submit" link to be there but greyed out until the select at least one info type
[09:43] <wgrant> Do we have any existing things like that?
[09:43] <wgrant> All I know of is disabled buttons.
[09:43] <wallyworld__> ah, the auto bug/branch linking code disables links
[09:43] <wallyworld__> i'll look at that
[09:44] <wgrant> Mm
[09:44] <wgrant> Sort of.
[09:44] <wgrant> They're not really disabled.
[09:44] <wallyworld__> link.addClass('invalid-link')
[09:44] <wgrant> Just greyed out and making odd popups.
[09:44] <wallyworld__> clicking is disabled and they are grey
[09:44] <wallyworld__> perfect :-)
[09:45] <wallyworld__> well, not sure about clicking, but i;ll handle that in my code. the css class works
[09:48] <wgrant> Is this going into the picker infrastructure, rather than something specific to disclosure?
[09:48] <wgrant> We already have about 4 submit patterns in pickers.
[09:48] <wgrant> Would be nice to not introduce more.
[10:01] <dpm> hi all, I've got a couple of launchpadlib/API questions: given a project name, is it possible to find out if that project has any distro packages in Ubuntu?
[10:02] <dpm> I've read the api docs, but I couldn't figure that one out
[12:22] <dpm> hi all, would anyone have an aswer to the earlier question re: the Launchpad API?
 hi all, I've got a couple of launchpadlib/API questions: given a project name, is it possible to find out if that project has any distro packages in Ubuntu?
[12:22] <dpm> I've read the api docs, but I couldn't figure that one out
[12:22] <jelmer> hi dpm
[12:23] <dpm> hey jelmer :)
[12:23] <jelmer> dpm: I'm pretty sure the reverse is possible (ubuntu pkg -> project), not sure about project -> ubuntu pkg
[12:23]  * dpm looks at the reverse in the API docs, which might be a workaround
[12:26] <jelmer> dpm: lp.distributions["ubuntu"].getSourcePackage(name="bzr").upstream_product
[12:26] <dpm> hm, at a quick glance I cannot see how the reverse is possible from https://api.launchpad.net/devel.html#source_package
[12:26] <dpm> ah, cool, thanks jelmer :)
[12:26] <dpm> I was looking for project instead of product
[12:27] <jelmer> product is the old name for project
[12:51] <salgado> sinzui, around?  did you get a failure email from that ec2-land you did for me yesterday?
[13:42] <benji> I'm getting an error submitting a branch using either pqm-submit or ec2 land, has anyone seen this one: https://pastebin.canonical.com/61922/
[13:44] <benji> heh, my AWS newsletter includes a new instance type that might work for our buildbot stuff: m1.medium.  It's half the cost of the m1.large we're using now.
[13:47] <jelmer> benji: your bzr is too old for your version of bzr-pqm
[13:48] <benji> jelmer: how does one go about rectifying that?
[13:48] <jelmer> benji: install a newer version of bzr (are you on precise yet?)
[13:49] <benji> jelmer: lets see... the VM I'm using at the moment is oneiric
[14:01] <deryck> Morning, all.
[14:01] <rick_h_> morning
[14:02] <rick_h_> deryck: on the new hardware this morning?
[14:02] <deryck> rick_h_, indeed
[14:02] <deryck> rick_h_, feels nice :)
[14:02] <rick_h_> as shiny as hoped?
[14:02] <rick_h_> hehe
[14:02] <deryck> yeah, definitely.  very nice laptop/
[14:15] <flacoste> deryck: convoy has no release?
[14:15] <flacoste> deryck: Daviey is packaging it for precise for the maas project
[14:16] <czajkowski> deryck: how has your team managed all the questions/issues re private bugs in the last few weeks ?
[14:16] <czajkowski> deryck: can you see private bugs or do you like me see oops ?
[14:17] <deryck> flacoste, I don't think it has a release.  rick_h_ do you know for sure?
[14:17] <deryck> czajkowski, no, I can't see them either. Usually, you just have to ask follow up questions to the person to figure things out.
[14:18] <rick_h_> flacoste: no release? it's in a daily build setup by StevenK and we use that
[14:18] <czajkowski> deryck: am fairly stuck on https://answers.launchpad.net/launchpad/+question/188450
[14:18] <rick_h_> flacoste: it's not on pypi, but I need to bug the guys about that one
[14:19] <flacoste> rick_h_: it's not on lp either (i mean there are no releases on lp either)
[14:19] <flacoste> rick_h_: how's pycon?
[14:19] <deryck> pasting for bot link:  OOPS-dd4660fd4f3a19b43f9d6649dc99eda
[14:19] <rick_h_> flacoste: there's a recipe to build everyone uses (landscape has one, etc) but yea, no releases done
[14:19] <rick_h_> flacoste: leaving for pycon this afternoon, so hopefully awesome! :)
[14:20] <deryck> oh the bot doesn't giving me a link here.  hmmm
[14:20] <deryck> what's the oop site URL?  new lappie and all. ;)
[14:20] <czajkowski> deryck: https://lp-oops.canonical.com/openid/+login
[14:24] <deryck> czajkowski, so I would have thought it would have redirected to the correct URL then said unauthorized to you and I.
[14:24] <deryck> czajkowski, maybe this is different now with purple squad's new work.
[14:25] <deryck> sinzui, can you see bug 924475?
[14:27] <salgado> sinzui, I guess you didn't see my question earlier?  did you get a failure email from that ec2-land you did for me yesterday?
[14:31] <sinzui> I do indeed have a failure
[14:38] <sinzui> salgado, did you get the email. I read it 10 minutes before you pinged me, not I do not see and it is not in my trash?
[14:39] <salgado> sinzui, no, I didn't get it
[14:39] <sinzui> :(
[14:39]  * sinzui keeps looking
[14:53] <rick_h_> jcsackett: ping, can you peek at this when you get a sec please? https://code.launchpad.net/~rharding/launchpad/fix_cal2/+merge/96584
[14:58] <jcsackett> rick_h_: r=me.
[14:58] <rick_h_> jcsackett: ty
[14:58] <jcsackett> aren't you supposed to be pyconning? :-P
[14:59] <rick_h_> I leave this afternoon
[15:06] <mhall119> I have an API question
[15:06] <mhall119> if I have a Branch object from launchpadlib, is there a way to get a list of all the branches that have been previously merged into it?
[15:09] <sinzui> salgado, I found the email, well in a manner of speaking. I can see the email and will forward it to you. I do not know where thunder(shite)bird moved it too)
[15:09] <sinzui> salgado, one failure. Looks easy to fix
[15:09] <salgado> sinzui, heh, that's fine.  thanks a lot!
[15:10] <czajkowski> salgado: mails now being sent and post done
[15:11] <salgado> czajkowski, thanks!  the blog post will be held until everything is live, right?
[15:15] <czajkowski> salgado: the blog post is just a copy of the mail annoucment you sent me
[15:15] <czajkowski> is thre another more detailed post ?
[15:16] <salgado> czajkowski, mrevell said in the email that he'd be writing the blog post as well.  but maybe the idea is to have two posts: one with the warning and another one when the changes are live?
[15:17] <czajkowski> salgado: thats how I read it
[15:47] <mhall119> lifeless: ping
[15:49] <mhall119> wgrant: ping
[15:53] <czajkowski> mhall119: wrong times for both of them
[15:53] <mhall119> hmmm, who's awake at this time of day?
[15:54]  * mhall119 will try the on-call reviewer
[15:54] <mhall119> jcsackett: ping
[15:57] <mhall119> oh sweet, LP support for work items!
[15:57] <mhall119> czajkowski: \o/
[15:58] <mhall119> has that been deployed yet?
[15:58] <czajkowski> nope not yet
[15:59] <jcsackett> mhall119: pong.
[16:01] <mhall119> jcsackett: if I have a Branch object from launchpadlib, is there a way to get a  list of all the branches that have been previously merged into it?
[16:01] <jcsackett> mhall119: not sure. one sec.
[16:01]  * jcsackett takes a look at API docs
[16:02] <mhall119> the API will get me branches currently in MPs, but I don't know about past-merged MPs
[16:02] <mhall119> and I guess it wouldn't be able to give me branches merged manually, without an MP
[16:03] <rick_h_> mhall119: I'd expect that to be the job of bzr history more than LP api
[16:03] <mhall119> rick_h_: yeah, me too, it's just that I'm already using launchpadlib to generate stats about MPs
[16:04] <mhall119> and trudging through bzr branch history is likely to be orders of magnitide sloper
[16:04] <mhall119> slower
[16:04] <jcsackett> mhall119: you can get merged MPs from the API. so you could construct a script that gets all the MPs for the branch with a date_merged, and get the branches from that.
[16:04] <rick_h_> mhall119: yea, I guess need to split bzr merge vs MP records in LP.
[16:04] <jcsackett> mhall119: but it's likely to be convoluted.
[16:05] <mhall119> ok, thanks, that's all I needed to know
[16:05] <jcsackett> and yes, it'll only get you branches that were merged with an MP. if someone just merged in a branch on their own that's not going to show up.
[16:09] <jcsackett> sinzui: i see there is a pending request for ui review from you on a loggerhead change. https://code.launchpad.net/~cruzjbishop/loggerhead/ui-changes/+merge/95090
[16:09] <jcsackett> did you actually want to weigh in on that, or shall i just move it along? it's a switch of browser-specific rounded corners to the generalized version.
[16:11] <sinzui> I don't see why I need to review, but...
[16:12] <jcsackett> sinzui: you don't.
[16:12] <jcsackett> i'm asking if you want to.
[16:12] <sinzui> I think we can drop -webkit-border-radius -moz-border-radius because firefox and webkit switched to the official property about 3 years ago
[16:12] <jcsackett> i don't think it's necessary, and was prepping to just move it along.
[16:13] <jcsackett> sinzui: dig. i'll move this into approved and get it merged into loggerhead.
[16:14] <mabac> jcsackett, could you bear having another look at https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-widget/+merge/94790 for me? We found just another little bit we needed to add.
[16:15] <sinzui> jcsackett, FTW.., why do we have border-radius at 4px, 5px, and this example of px. There can be only one
[16:15] <jcsackett> sinzui: FTW? or WTF?
[16:15] <sinzui> I think 5px is the standard
[16:16] <sinzui> Consider -2 WTF, consider -1 FTW
[16:17] <sinzui> I think the CSS in the review should use 5px for the radius. I think Lp's own CSS also need fixing and we might be able to delete a few rules
[16:18] <rick_h_> jcsackett: sorry, added sinzui because I wasn't sure on how only some corners were rounded and if that was something that should be ui reviewed/standardized
[16:19] <rick_h_> jcsackett: and sinzui was listed in the wiki for ui reviews :)
[16:19] <sinzui> rick_h_, that is ancient history...but you were right to get me to look at the oddness
[16:19] <jcsackett> sinzui: ok, i'll leave a comment to the effect of plz change to 5px.
[16:19] <jcsackett> or you can, if you like.
[16:20]  * sinzui could land an rs branch to just fix all the references tomorrow
[16:20] <jcsackett> sinzui: it'd be two branches, right? one for LP and one for loggerhead.
[16:21] <sinzui> jcsackett, yes. The logger head fix can be made in the branch that is being reviewed
[16:22] <jcsackett> sinzui: dig. just wanted to make sure i was on the same page as you.
[16:24] <sinzui> I feel like I am flipping though a book at the moment. I hate editing moin
[16:24] <abentley> adeuring: chat?
[16:25] <sinzui> When I am lord god-emperor of the Earth, the Universe, and Canada, Moin syntax will be 100 papre-cut offense.
[16:25] <jcsackett> sinzui: if you are creating new pages, allenap created a method to use rst.
[16:25] <jcsackett> or you could update the entire page you're editing and use his method. :-P
[16:25] <sinzui> second offenders will get lemon juice on the cuts
[16:26] <allenap> sinzui: +1
[16:26] <sinzui> jcsackett, i am editing information is a large table
[16:26] <abentley> jcsackett: I just wish rst table headers had consistent meaning.
[16:26] <jcsackett> mabac: this branch is getting sort of unwieldy. are you merging in branches approved in other MPs as well?
[16:28] <jcsackett> abentley: +1
[16:28] <mabac> jcsackett, sorry about that. yes we thought that the help-popup belonged in this branch for landing
[16:28] <mabac> jcsackett, and we really believed this branch was done.
[16:28] <mabac> jcsackett, which is not a (good) excuse for messing it up
[16:28] <jcsackett> mabac: i'll take a look at these later revisions. but an ongoing branch for weeks is a recipe for problems. :-)
[16:29] <mabac> jcsackett, I promise that I've learned a lot in the process? :D
[16:29] <jcsackett> mabac: :-P
[16:29] <mabac> jcsackett, but yes, I'll keep it neater next time
[16:31] <jcsackett> mabac: i'm seeing changes to the Makefile in those revisions? it looks like you've got a weird diff going on with rick_h_'s recent js_watch work ...
[16:32] <jcsackett> rick_h_: did your js_watch stuff ever land? i don't see it in devel, but i think i'm seeing it in mabac's diff.
[16:32] <mabac> jcsackett, I can see that we merged devel just recently. perhaps something more changed since then. I'll take a look
[16:35] <jcsackett> mabac: i've sorted it. i was looking at changes in the recent revisions, which includes when rick_h_'s stuff was introduced; there's an update from devel in those revisions i missed.
[16:35] <mabac> jcsackett, ok good
[16:36] <jcsackett> mabac: b/c of that, though, i can't get a diff of just the things you've added that need to be looked at. can you generate a diff of just the new stuff and throw it up on pastebin or something?
[16:37] <jcsackett> otherwise i'm going to have to look at the whole diff again, which i can do today but not anytime soon.
[16:37] <rick_h_> jcsackett: yes, the js watch stuff landed
[16:37] <mabac> jcsackett, is it better if I merge from devel and push again?
[16:38] <jcsackett> mabac: no, that won't sort it. :-)
[16:38] <mabac> jcsackett, ok diff coming right up
[16:38] <jcsackett> mabac: if you don't have time to do that, it's ok. i can review this today, just not now.
[16:43] <mabac> jcsackett, http://paste.ubuntu.com/874794/
[16:43] <mabac> jcsackett, thanks
[16:46] <popey> hullo.
[16:46] <czajkowski> popey: boo
[16:47] <popey> I saw czajkowski's announce about blueprints and wondered if it would adversely affect http://status.ubuntu.com/ (given that site directly plucks work-item text in specially formatted ways from blueprints) or whether you've all thought about that and I should stop worrying ☺
[16:47] <czajkowski> salgado: ^^^
[16:51] <jcsackett> mabac: perfect, exactly what i needed.
[16:51] <jcsackett> reviewing now.
[16:55] <salgado> popey, we planned it so that for users there are no visible changes (i.e. they will continue to enter the work items in a text field using the exact same format as before) and the tools will keep working (there was a trivial change to launchpad-work-items-tracker which I did to make it work against the new API and it was accepted yesterday)
[16:56] <jcsackett> mabac: new revisions look fine. thanks.
[16:58] <popey> salgado: groovy
[16:58] <mabac> jcsackett, great thanks for reviewing it again :)
[16:59] <mabac> jcsackett, will you make another go at landing it too?
[17:08] <adeuring> abensure. mumble (sorry for the delay...)
[17:13] <jcsackett> mabac: sure.
[17:14] <salgado> jcsackett, actually, let's wait a bit.  see discussion on #launchpad-ops :)
[17:20] <jcsackett> salgado: got it. :-P
[18:01] <lifeless> morning
[18:13] <czajkowski> lifeless: good day
[18:18] <lifeless> hi czajkowski
[20:26] <sinzui> jcsackett, do you have time to review this long branch: https://code.launchpad.net/~sinzui/launchpad/remove-register-branch/+merge/96649
[20:34] <jcsackett> sinzui: sure, i can review it. it's mostly big b/c you're ripping stuff out, right?
[20:34] <sinzui> Yes -800+ lines of unused views and tests
[20:36] <jcsackett> sinzui: cool. i'll be happy to review it. these things needed killing for awhile.
[21:09] <jcsackett> sinzui: r=me.
[21:09] <jcsackett> and now i need more coffee. :-P
[21:09] <sinzui> thank you
[21:43] <sinzui> lifeless, or deryck can I have your +1 to try this script on staging, then production: http://pastebin.ubuntu.com/873679/
[21:44] <lifeless> sinzui: the statement timeout is too high; needs to be 2000 to be sure we won't cause timeouts
[21:44] <sinzui> okay
[21:45] <czajkowski> if someone had some spare time could they answer https://answers.launchpad.net/launchpad/+question/190103  so I can book mark it as well for me to learn.
[21:45] <czajkowski> thank you
[21:46] <lifeless> sinzui: other than that +1 - or perhaps we should drop the rows?
[21:48] <sinzui> lifeless,  we do not as yet (merge doesn't and the merged team continues to exist as a historical record if the team leaves before being merged). I am pondering deletion though; only someone with db access can see the data
[22:10] <StevenK> lifeless: 2000? Er, what? I thought the policy was 2500.
[22:11] <lifeless> pretty sure it was a round 2 seconds
[22:11] <StevenK> For manual SQL? Look it up, it's 2500.
[22:12] <lifeless> whats the wiki pge
[22:13] <StevenK> No fair if you edit the wiki page to claim you're right.
[22:14] <StevenK> "The write lock holding portion of the script must complete in 2.5 seconds to avoid causing timeouts in appserver requests."
[22:14] <StevenK> https://wiki.canonical.com/InformationInfrastructure/OSA/RequestLogging/LP/SQL
[22:21] <lifeless> StevenK: I considered it, but it wouldn't be fair.
[22:21] <lifeless> however, I probably should drop it down to 1s
[22:22] <StevenK> In either case, I'm right. :-)
[22:22] <lifeless> twitch
[22:26] <StevenK> wgrant: http://pastebin.ubuntu.com/875283/
[22:45] <StevenK> wgrant: http://pastebin.ubuntu.com/875299/
[23:24] <jelmer> sinzui: YOU ROCK
[23:24] <jelmer> sinzui: thanks for lp:~sinzui/launchpad/remove-register-branch
[23:25] <wgrant> I said you'd be interested :)
[23:27] <jelmer> :)
[23:45] <bigjools> jelmer: does any of these errors look familiar for recipe builds? https://bugs.launchpad.net/launchpad-buildd/+bug/940157
[23:45] <_mup_> Bug #940157: PPA builders have corrupted filesystem <ppa> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/940157 >
[23:46] <jelmer> bigjools: I don't recall having seen those for any recipe builds
[23:48] <bigjools> jelmer: ok. Very weird then.
[23:49] <wgrant> bigjools: Given that no other package has ever seen it, it seems unlikely that it's not a package bug.
[23:49] <bigjools> wgrant: quite possibly yes
[23:49] <bigjools> but I want some opinions from more people first
[23:50] <wgrant> Everyone agrees that there's no reason to believe it's not a package bug.
[23:50] <bigjools> who is everyone?
[23:50] <wgrant> infinity, me
[23:50] <wgrant> ie. most of the relevant people who weren't away when this came up originally.
[23:51] <bigjools> I agree too, but I still want to ask around
[23:52] <elmo> poolie: ping
[23:52] <elmo> how rude
[23:52] <elmo> bigjools: I agree too btw
[23:53] <elmo> someone even check the first accused build; there's nothing wrong with the FS
[23:53] <elmo> I'm not quite sure why gustavo doesn't add more output, -v to rsync or cp, strace or whatever
[23:53] <wgrant> And palmer, vernadsky and rothera aren't exactly untested machines.
[23:53] <elmo> wgrant: I've been meaning to ask - can receipe builds install from PPAs?
[23:54] <wgrant> Perhaps Go is really so amazing that it exposes bugs that no other piece of software in the world does.
[23:54] <wgrant> elmo: Yes.
[23:54] <elmo> wgrant: so, umm
[23:54] <elmo> wgrant: why are they running non-virtualized?
[23:54] <elmo> isn't that a gaping security hole?
[23:54] <wgrant> elmo: It's a non-virt PPA, I assume.
[23:54] <elmo> ah, hmm
[23:55] <wgrant> Possibly because ARM, but I'm not quite sure.
[23:55] <elmo> ok, so normal receipe builds will only happen on a PPA?
[23:55] <wgrant> Yes.
[23:55] <elmo> cool, I'll stop freaking out quite so much
[23:55] <wgrant> We're not entirely stupid.
[23:55] <wgrant> I hope.
[23:56] <bigjools> speak for yourself. wheeeeeeee
[23:56] <bigjools> elmo: furry muff, ta