[00:26] <StevenK> cody-somerville: Are you able to QA r14876, which is on qas now?
[00:38] <StevenK> wgrant: The notfound template already says: "This page does not exist, or you may not have permission to see it."
[00:38] <wgrant> StevenK: IN about 10 tonnes of other text.
[00:39] <StevenK> It's the first text after the heading
[00:51] <cody-somerville> StevenK, How do I QA it?
[00:52] <StevenK> cody-somerville: You added an attribute to the webservice. Can you get it and set it in the way you expect?
[00:53] <cody-somerville> StevenK, Cool. Okay. I can do that. Do I tag the bug or something if successful?
[00:54] <StevenK> cody-somerville: Yes. There is currently a 'qa-needstesting' tag on the bug. If it works fine, remove that tag and add 'qa-ok'
[01:15]  * StevenK smacks wallyworld 
[01:15] <wallyworld> ?
[01:15] <StevenK> wallyworld: 116+from lp.app.interfaces.services import IService right at the top of lib/lp/registry/browser/tests/test_product.py ?
[01:16] <wallyworld> auto import fail
[01:16] <wallyworld> will fix in current branch
[01:17] <StevenK> wallyworld: I spent hours fixing imports yesterday and the next feature branch gets it wrong. :-(
[01:17] <wallyworld> it's only one of many i added, easily fixed :-)
[01:28] <StevenK> wgrant: Tempted to do distribution via SQL. There are less than 50.
[01:30] <wgrant> StevenK: Possibly.
[01:30] <wgrant> lifeless: staging should have my first patch in about 30 minutes.
[01:30] <wgrant> http://people.canonical.com/~wgrant/launchpad/flatbugtask.sql is the second one which I described yesterday.
[01:31] <wgrant> It's missing triggers on the access policy bits, and there's no handling of toggling of Product.active, but it should otherwise be reasonably consistent.
[01:32] <lifeless> wgrant: drop that in a file on devpad
[01:33] <wgrant> lifeless: carob:~wgrant/flatbugtask.sql
[01:35] <lifeless> is it dependent on the first patch ?
[01:35] <wgrant> It'll apply and partly work without it, but none of the access stuff will be there.
[01:37] <wgrant> Once the first patch is applied we need to build its data (SELECT bug_mirror_legacy_access(id) FROM bug), then build the second lot of data (SELECT bugtask_flatten(id) FROM bugtask).
[01:38] <lifeless> ok, ping me
[01:38] <wgrant> Yup, just prewarning you.
[01:41] <wgrant> lifeless: I also need a way to do mass async updates when Product.active changes. Jobrunner job? Dirty flag with garbo job? The latter is a bit evil but somewhat lighter than the current jobrunner situation.
[01:42] <lifeless> jobrunner
[01:42] <wgrant> :(]
[01:42] <lifeless> should be light enough
[01:42] <wgrant> 2KLOC later...
[01:42] <lifeless> I'm sure you'll make it lighter as you go
[01:42] <wgrant> Heh
[01:47] <wgrant> I guess we need a pattern for this sort of thing anyway.
[01:52] <wgrant> StevenK: Bah, I said I had created a card already :)
[01:52] <wgrant> 2012-02-29 01:42:39 INFO    2209-11-3 applied just now in 0.4 seconds
[01:54] <wgrant> lifeless: https://pastebin.canonical.com/61200/ are the incantations.
[02:18] <lifeless> wgrant: do you want them run now ?
[02:18] <wgrant> lifeless: Please. \timing would be handy too.
[02:19] <wgrant> lifeless: Will be interested to see how long the two mass function calls take in a single batch.
[02:20] <lifeless> one transaction?
[02:20] <wgrant> Might as well run it in three, just in case one fails.
[02:21] <lifeless> heh, started it a begin
[02:21] <lifeless> will do over if it fails
[02:21] <wgrant> lifeless: You applied flatbugtask.sql, right? :)
[02:21] <wgrant> It defines the last function.
[02:21] <lifeless> no, not yet
[02:27] <lifeless> wgrant:
[02:27] <lifeless> INSERT INTO accesspolicy (product, type) SELECT id, 3 FROM product;
[02:27] <lifeless> INSERT 0 34729
[02:27] <lifeless> Time: 3833.312 ms
[02:27] <lifeless> INSERT INTO accesspolicy (product, type) SELECT id, 4 FROM product;
[02:27] <lifeless> INSERT 0 34729
[02:27] <lifeless> Time: 4182.285 ms
[02:27] <lifeless> INSERT INTO accesspolicy (distribution, type) SELECT id, 3 FROM distribution;
[02:28] <lifeless> INSERT 0 36
[02:28] <lifeless> Time: 9.049 ms
[02:28] <lifeless> INSERT INTO accesspolicy (distribution, type) SELECT id, 4 FROM distribution;
[02:28] <lifeless> INSERT 0 36
[02:28] <lifeless> Time: 9.061 ms
[02:31] <wgrant> lifeless: Looks reasonable.
[02:32] <lifeless> SELECT bug_mirror_legacy_access(id) FROM bug;
[02:32] <lifeless> Time: 228686.012 ms
[02:33] <lifeless> SELECT bugtask_flatten(id) FROM bugtask;
[02:33] <wgrant> Not too bad, considering a lot of it was probably cold.
[02:49] <lifeless> (1097473 rows)
[02:49] <lifeless> Time: 994126.901 ms
[02:49] <lifeless> bugtask_flatten(id) returns a pile of null :P
[02:52] <wgrant> Hmmm, slower than it should have been.
[02:52] <wgrant> But thanks.
[02:52] <wgrant> So.
[02:52] <wgrant> You should now have a marvellous bugtaskflat with 20 or so indices
[02:54] <lifeless> select count(*) from bugtaskflat;
[02:54] <lifeless>   count
[02:54] <lifeless> ---------
[02:54] <lifeless>  1097473
[02:54] <wgrant> Excellent.
[02:55] <wgrant> Try https://pastebin.canonical.com/61202/
[02:57] <lifeless> 102984, 1238ms
[02:57] <wgrant> :(
[02:58] <lifeless> explain analyze 625ms
[02:58] <wgrant> So 500ms planning?
[02:58] <wgrant> Or 1238 cold?
[02:58] <lifeless> 9ms
[02:58] <wgrant> coldish, that is
[02:58] <lifeless> 1238 coldish
[02:58] <wgrant> Ah
[02:58] <wgrant> So it's now 600ms?
[02:58] <wgrant> ish?
[02:58] <lifeless> 420, 500, etc
[02:59] <wgrant> That's more like it.
[02:59] <wgrant> Care to throw in a bit of FTI?
[02:59] <wgrant> Like BugTaskFlat.fti @@ ftq('kernel hang') or so?
[03:02] <wgrant> (yes, the privacy constraint is hideously structured, but it works it out -- I need to rework the Python to spell it better)
[03:03] <wgrant> The SQL I provided uses gist for fti, but it might be interesting to compare it to gin on sourcherry.
[03:03] <lifeless> pastebin what you want :)
[03:09] <wgrant> lifeless: https://pastebin.canonical.com/61204/
[03:10] <lifeless>  Aggregate  (cost=82175.45..82175.46 rows=1 width=0) (actual time=637.165..637.166 rows=1 loops=1)
[03:10] <wgrant> Well that sucks.
[03:11] <wgrant> Can I have the whole thing?
[03:11] <lifeless>  Limit  (cost=82182.00..82182.19 rows=75 width=8) (actual time=527.338..527.366 rows=75 loops=1)
[03:12] <lifeless> https://pastebin.canonical.com/61205/
[03:12] <wgrant> Thanks.
[03:13] <wgrant> A
[03:13] <wgrant> Ah
[03:13]  * wgrant blames gist.
[03:13] <wgrant> A bit of planner stupidity too, but mostly gist.
[03:15] <wgrant> lifeless: DROP INDEX bugtaskflat__fti__idx; CREATE INDEX bugtaskflat__fti__idx ON bugtaskflat USING gin (fti); and retry?
[03:15] <wgrant> Will probably take a while
[03:15] <wgrant> GIN generation is slooooow.
[04:13] <StevenK> wgrant, lifeless: O hai, can we have a mumble about ArchiveAudit?
[04:14] <lifeless> sure
[04:14] <lifeless> skype?
[04:14] <lifeless> or fanout ?
[04:14] <StevenK> You can't do mumble?
[04:14] <lifeless> it hates me
[04:15] <wgrant> Hangouts still don't work for me, and are even less tasteful than Skype.
[04:15] <lifeless> it needs http://www.rowetel.com/blog/?page_id=454
[04:15] <StevenK> It worked last time :-P
[04:15] <wgrant> So I suggest we Skype :)
[04:15] <lifeless> StevenK: it was traumatic
[04:15] <lifeless> StevenK: and I've got Cynthia beside me at this time of day
[04:15] <StevenK> I can make it more trauatic and turn on the webcam
[04:16] <StevenK> *traumatic
[04:16] <lifeless> I know what you look like already
[04:18] <lifeless> I can hear you
[04:19] <lifeless> lies
[04:19] <lifeless> precise
[04:19] <lifeless> diaf
[04:19] <lifeless> sound panel sees my input
[04:20] <lifeless> what command ?
[04:20] <wgrant> pavucontrol
[04:23] <StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/db-add-archiveaudit/+merge/94726 is the WIP MP
[05:15] <wgrant> lifeless: Any chance you could recreate the FTI index as GIN as I described above?
[05:18]  * StevenK peers at his garbo test
[05:20] <lifeless> CREATE INDEX
[05:20] <lifeless> Time: 159917.895 ms
[05:21] <lifeless>  Limit  (cost=82270.96..82271.14 rows=75 width=8) (actual time=1031.584..1031.633 rows=75 loops=1)
[05:21] <lifeless>  Limit  (cost=82270.96..82271.14 rows=75 width=8) (actual time=183.615..183.666 rows=75 loops=1)
[05:21] <wgrant> lifeless: blink
[05:21] <wgrant> So it's 3x faster?
[05:21] <lifeless> looks like it
[05:22] <wgrant> Might try with GIN straight away, then
[05:22] <lifeless> what about table scans
[05:22] <wgrant> Given that we're going to be restrictedly testing this for a while anyway.
[05:22] <lifeless> ok
[05:22] <wgrant> They're unlikely to happen given the other indices.
[05:22] <wgrant> But yes, it is a concern.
[05:23] <stub> We can drop in GIN already if we don't care about occasional searches breaking, but in the past we have :-)
[05:24] <wgrant> stub: The new table has strategic indices.
[05:24] <StevenK> Haha
[05:24] <wgrant> Rather than random ones that are mostly useless, like bug and bugtask.
[05:25] <stub> The 'all stopwords' query is the usual one that breaks things.
[05:40] <lifeless> we could take a calculated risk
[05:41] <lifeless> easy enough to change index style
[05:41] <lifeless> and hell, 1 second is still >> 8 seconds
[05:44] <lifeless> StevenK: I had a quick look for a audit service, couldn't see one
[05:44] <lifeless> wgrant: let webops know if/when you want that stuff dropped from staging
[05:45] <wgrant> lifeless: Easy enough to change index style, and easy enough to turn the feature flag off :)
[06:24] <stub> lifeless, wgrant: If we are rebuilding the search, I think we should a) use GIN indexes wherever possible and b) catch the exception we see when it attempts a full scan and return a 'too many results' type page.
[06:24] <lifeless> wfm
[06:25] <wgrant> Probably, yeah.
[06:25] <stub> Might as well stick a LIMIT in the query too, generating the 'too many results' thing even if the index hit did work. Nobody wants page 1 of 600.
[06:26] <wgrant> Well
[06:26] <wgrant> Hopefully we'll be using StormRangeFactory soon
[06:26] <wgrant> Which will remove the COUNT(*) entirely.
[07:28] <stub> bug_fti is off the 'most bloating indexes' list, yay!
[07:50] <wgrant> stub: yup :)
[08:44] <wgrant> buildbot failure is mine, I'm on it.
[08:52] <adeuring> good morning
[09:05] <czajkowski> aloha
[09:39] <[reed]> wgrant: throw in IE's X-XSS-Protection as well
[09:39] <[reed]> Chrome supports it, too
[09:40] <[reed]> wgrant: depending on how that gets presented, you may wish to add "; includeSubDomains" to the HSTS header, too
[09:41] <wgrant> [reed]: Can't use includeSubDomains, due to some questionable historical decisions.
[09:41] <wgrant> Will look into X-XSS-Protection, though -- didn't realise Chrome did it too. Thanks.
[09:43] <nigelb> oh wow. totally did not expect [reed] in here ;)
[09:43] <[reed]> I'm everywhere.
[09:44] <nigelb> Yes, TIL.
[09:44] <[reed]> also, I've been complaining about some of these things for a while, at least in LDS
[09:44] <nigelb> Wait, you come to UDSes and LDSes?
[09:44] <[reed]> LDS == Landscape Dedicated Server
[09:44] <nigelb> Ahhhhhh.
[09:44] <[reed]> I have come to two UDSes, though
[09:45] <wgrant> X-XSS-Protection looks like a bit of a misfeature.
[09:45] <[reed]> I'll probably stop by the Oakland one
[09:45] <wgrant> Potential for security issues, even.
[09:45] <[reed]> wgrant: I think most of those issues have been worked out... it's been around for a while now
[09:46] <[reed]> "Registration for the next UDS opens on 24th February 2012."
[09:46] <[reed]> it's a bit past that
[09:46] <[reed]> lol
[09:55] <[reed]> wgrant: if you want to be super-awesome, send an appropriate CSP header ;)
[09:58] <wgrant> [reed]: Isn't that thoroughly unstandard and still in flux?
[09:58] <wgrant> Ahhh
[09:59] <wgrant> I see X-XSS-Protection has evolved a bit since I dismissed it as completely insane a couple of years ago
[09:59] <wgrant> Notably with the addition of mode=block
[10:00] <[reed]> indeed
[10:00] <wgrant> Anyway, yeah, was looking at doing CSP, but it's going to be a bit less trivial to ensure everything still works, and it seems like there's work on making it more sensible and standard.
[10:00] <[reed]> sure
[10:00] <wgrant> But since you're suggesting it, I might have to look again :)
[10:00] <[reed]> hah
[10:01] <[reed]> I know a bunch of Mozilla sites implement it
[10:01] <wgrant> Because you added it? :)
[10:01] <[reed]> but I also know it took them quite a while to do the right thing
[10:01] <nigelb> haha
[10:01] <[reed]> hah, not for CSP, but I did add other headers ;)
[10:01] <wgrant> Heh
[10:01] <[reed]> pretty much every security "feature" Bugzilla has gained in the past several years was because I wrote a patch for it :p
[10:02] <wgrant> I've wanted to do this to LP for 18 months, but there were various bits of stupidity that needed to be fixed first.
[10:02] <wgrant> Like certain URLs which were forced to HTTP for no good reason.
[10:02] <[reed]> wanna fix Landscape as well? :P
[10:02] <wgrant> And crufty bits of Zope that needed upgrading.
[10:02] <wgrant> sigh
[10:02] <wgrant> Heh
[10:02] <[reed]> don't get me started on how terrible Landscape is from a security perspective ;)
[10:06] <wgrant> Yeeeeeah
[10:07] <wgrant> It's the one major Canonical webapp that I haven't tried to poke holes in.
[10:07] <wgrant> I'm not entirely sure I want to try :)
[10:08] <[reed]> I'd appreciate it if you would! ;)
[10:08] <[reed]> I've poked a bunch of holes in it already
[10:08] <[reed]> but I know there are plenty more
[10:08] <[reed]> it's never had a formal security review, as far as I can tell
[10:09] <wgrant> juju is the next target of my wrath.
[10:49] <czajkowski> wgrant: you still up ?
[10:50] <wgrant> czajkowski: Vaguely.
[10:50] <czajkowski> can you help me in launchpad with a question:/ re  merge proposals
[10:50] <czajkowski> please
[10:55] <wgrant> czajkowski: mgz is one of us :)
[10:55] <wgrant> Well, bzr.
[10:55] <wgrant> But close enough.
[10:58] <czajkowski> wgrant: aye thats what I thought too
[11:57] <rick_h_> morning
[11:58] <czajkowski> rick_h_: morning
[12:18] <mabac> rick_h_, good morning. :) since there's no ocr can I pester you with another review? or perhaps could you point me to someone I could bug? ;) https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-widget/+merge/94790
[12:57] <rick_h_> mabac: sure thing, will peek at it
[13:02] <mabac> rick_h_, cool, thank you very much!
[13:29] <salgado>   File "/home/salgado/launchpad/lp-branches/workitems-migration-script/lib/lp/services/database/bulk.py", line 244, in create
[13:29] <salgado>     IStore(cls).execute(Insert(db_cols, expr=db_values))
[13:29] <salgado> TypeError: __init__() got an unexpected keyword argument 'expr'
[13:30] <salgado> has anybody seen this before?
[13:33] <salgado> hmm, looks like I'm using an old version of storm (storm-0.19.0.99_lpwithnodatetime_r404-py2.6-linux-i686.egg)
[13:33] <salgado> that's the version I should be using, in fact, but my branch is using storm-0.19.0.99_lpwithnodatetime_r402-py2.6-linux-i686.egg
[13:35] <salgado> I thought rocketfuel-get would update the generated scripts (bin/test, etc) to use the latest source but I guess that wouldn't make sense -- I should probably do that manually when I merge devel
[13:35] <salgado> is make clean; make the correct way to deal with that?
[13:37] <rick_h_> salgado: yea, think you'd need rocketfuel get, but then to merge with devel to lget the latest versions.cfg or what not. Not sure if storm is a packaged thing or a source dep
[13:39] <salgado> rick_h_, yeah it's in lp-sourcedeps, not deb-packaged.  I guess there's nothing faster than to "make clean" and rebuild from scratch?
[13:40] <rick_h_> salgado: might get away with a bin/buildout
[13:40] <rick_h_> but not tried it so not sure
[13:40] <salgado> oh, right, I'll try that next time
[13:41] <rick_h_> reading and working on makefiles a lot lately, but still some voodoo on what fits where to me :)
[14:12] <rick_h_> mabac: ok, notes posted, I ping'd jcsackett for a follow up
[14:14] <mabac> rick_h_, great thanks! will have a look asap!
[14:16] <rick_h_> mabac: most of my feedback just surrounds how I like to test things that parse like this: https://pastebin.canonical.com/61235/
[14:16] <rick_h_> mabac: so that as bugs/issues are found it's very trivial to add a new test case and see at once what works/doesn't kind of thing
[14:16] <rick_h_> if that makes sense
[14:16] <rick_h_> but it's a preference thing on my end
[14:17] <mabac> rick_h_, thanks. I don't have access to the canonical pastebin though
[14:17] <rick_h_> ah, sorry sec
[14:17] <rick_h_> http://paste.mitechie.com/show/552/ mabac
[14:18] <rick_h_> but anyway, for that to work our parsing/raising exceptions need to be a bit split/etc
[14:19] <mabac> I didn't really know if I should always raise LaunchpadValidationErrors or perhaps let parse errors pass through as well
[14:19] <rick_h_> yea, not sure on the standard since I've not done much with it
[14:23] <mabac> I'll see if I can use a regexp for the assignee as well. and move the work items header re to a module level constant
[14:25] <rick_h_> mabac: awesome
[14:29] <rick_h_> rvba: ping, just wanted to toss out a heads up that on the js builder stuff. Not sure if you guys can use that over in maas land.
[14:29] <rvba> rick_h_: pong
[14:29] <rick_h_> rvba: I've got to update the wiki with some notes, but give it a shot with what you guys are doing and let me nkow how I can make it more 'general' for other projecs
[14:30] <rick_h_> I want to find out what's too LP specific so I can hit up the other JS people out there and figure I can bug your team first :)
[14:33] <deryck> adeuring, https://plus.google.com/hangouts/extras/talk.google.com/orange-standup
[14:36] <salgado> how do I tell the test runner to drop into pdb on the first failure?
[14:37] <benji> salgado: -D
[14:37] <rvba> rick_h_: I'm in the middle of something right now, can you please paste the link to the page you want me to have a look at and I'll get back to you shortly.
[14:38] <salgado> benji, and that's an argument to bin/test I guess?
[14:38] <benji> salgado: yep
[14:38] <rick_h_> rvba: https://lists.launchpad.net/launchpad-dev/msg09077.html no hurry, just more fyi
[14:38] <salgado> benji, great, thanks!
[14:39] <salgado> benji, it doesn't seem to work if I use it with testr (raises BdbQuit immediately), but I guess that's known/expected?
[14:40] <adeuring1> deryck, abentley, rick_h_sorry, again a crash...
[14:40] <deryck> adeuring, np, we'll wait on you.
[14:40] <rvba> rick_h_: I see.  The problem with maas is that it's a distributed package.  To add a dependency: either it's packaged in precise or we have to include the source code in our tree.
[14:40] <rick_h_> rvba: ok, gotcha
[14:41] <benji> salgado: it's not known by me, and expectations lie at the root of suffering.
[14:41] <rvba> rick_h_: But I keep track on what you guys do on lp :).
[14:41] <rvba> rick_h_: We have the same dilemma about using/not using convoy.
[14:42] <adeuring> deryck: can you send me the link to the hangout again?
[14:42] <rick_h_> adeuring: https://plus.google.com/hangouts/extras/talk.google.com/orange-standup
[14:45] <adeuring1> deryck abentley rick_h_ seems that i should this machine for the hangout; haven't installed the plugin yet...
[14:47] <rick_h_> rvba: sorry, standup. Ok cool, I wasn't sure how you guys were doing the JS stuff but know you asked about the combo loader bits at the epic
[14:48] <rick_h_> rvba: so yea, the convoy stuff in the jsautobuild probably doesn't help you guys at all then if you're not going combo loader/convoy
[14:49] <rvba> rick_h_: I really would like to use the combo loader/convoy but I'm not sure it's going to happen for 12.04 for the reasons mentioned above.
[14:49] <rick_h_> rvba: right
[14:50] <adeuring1> abentley: let's use mumble...
[14:50] <abentley> adeuring1: sure
[14:50] <rvba> rick_h_: I'll benchmark what it costs us (in terms of page load time) to not use it.
[14:51] <rvba> rick_h_: if this is really significant, I'll try to get someone to package it or we will include the code in our tree.
[14:51] <rick_h_> yea, you guys are on disk/local right so I doubt it's horrible.
[14:51] <rvba> We will see.
[14:51] <rick_h_> but the pyinotify stuff is cool if you guys do hav a make jsbuild type step that you don't want to have to run on ever save
[14:52] <rick_h_> but ok cool. thanks for thinking/taking a peek if it fits into your stuff at all.
[14:52] <rvba> Looks very useful indeed.
[14:52] <mpt> Hi, I'd like to test a bug that occurs when reporting bugs, but staging.launchpad.net times out when doing something as simple as showing a package page
[14:53] <mpt> Is it likely that staging will work again soon?
[14:53] <rvba> rick_h_: I'll keep you in the loop when I'll do the benchmark.
[14:58] <czajkowski> mpt: I'll ask and find out
[14:59] <mpt> czajkowski, actually, I found a package that has hardly any bug reports (which I guess was causing the timeouts), so it's not urgent for me now. But staging seems rather underpowered for meaningful testing.
[14:59] <czajkowski> mpt: no harm in asking and finding out for sure
[15:07] <mpt> (The bug I was testing I have now reported as bug 943321)
[15:07] <_mup_> Bug #943321: Private bug report wrongly says "Subscribed by <reporter>" for automatic subscribers <Launchpad itself:New> < https://launchpad.net/bugs/943321 >
[15:08] <cr3> hi folks, launchpad uses a special syntax in brackets to identify the person approving in commit messages for example. where might this be documented?
[15:12] <rick_h_> cr3: somewhat here: https://dev.launchpad.net/PQMCommitMessages
[15:12] <rick_h_> cr3: basically it's [r={lpuser}]
[15:14] <cr3> rick_h_: thanks!
[15:57] <abentley> cr3: There are tools that will generate this for you: "bzr lp-land" from the bzr-pqm plugin, and ec2 land in the LP tree.
[15:59] <cr3> abentley: why use things like [bug=90791] when you can use bzr commit --fixes lp:90791 instead?
[16:00] <abentley> cr3: I don't believe that PQM respects that revision property.  It goes strictly on the basis of the message.
[16:01] <cr3> abentley: ok, so in practice, nobody really types any of those bracketed messages, right?
[16:01] <abentley> cr3: right.
[16:01] <cr3> abentley: that makes sense then, thanks!
[16:02] <abentley> cr3: And if you use commit --fixes, then ec2 land or lp-land will include [bug=] for you.
[16:04] <cr3> abentley: sweet, so the developers are encouraged to use bzr properly and get lots of benefits for free
[16:46] <danilos> mrevell, flacoste: so, we're having some problems with answers.launchpad.net: 1. there are packages linked to some of our projects, so we get weird pages like https://answers.launchpad.net/linaro — I don't seem to have permissions to remove those Packaging records anymore; 2. there are requests to either make "external" setting for answers app do something useful, or get rid of the tab — I know that Launchpad is not designed as a p
[16:46] <danilos> roject hosting service directly, but we want to be able to clearly point people at support resources
[16:46] <danilos> hi, btw :)
[16:49] <danilos> mrevell, flacoste: fwiw, for 1, I'm asking czajkowski in #launchpad if she can help remove them, but I am mentioning that as a more general problem for things we don't have control of
[16:52] <mrevell> thanks danilos, I'm otp, so slow to respond
[16:52] <danilos> mrevell, sure thing, just raising this as it's becoming an issue for us and I'd like your general opinion on it when you find the time
[17:38]  * deryck goes offline for lunch, back soon
[17:43] <stokachu> Hi im messing around with Oauth and launchpad and was curious if we could add ability to return some user data when grabbing the access_token?
[17:43] <stokachu> Right now there is no way to dynamically pull an id/display_name from an initial access token request
[17:44] <stokachu> so people will need to know their display name ahead of time
[17:47] <stokachu> hmm i guess i could do a /people/+me
[17:52] <lifeless_> stokachu: so once you have an OAuth token you can request details from /~ exactly.
[17:55] <stokachu> lifeless_: ok so when calling api.staging.launchpad.net/people/+me it'll response with json from /~username automatically?
[17:55] <stokachu> i think thats how im reading it in docs
[17:56] <lifeless> stokachu: yes, likewise /people/+me
[17:56] <stokachu> ok sweet
[17:56] <stokachu> let me hack it some more -- ive almost got a drupal plugin going
[17:57] <stokachu> ahhh i think im adding a json format by accident 'data' => 'Object: <lp.registry.model.person.PersonSet object at 0xa2310d0>, name: u\'+me.json\'',
[17:57] <stokachu> it already does json without me telling it
[17:59] <sinzui> stokachu, correct
[18:00] <sinzui> stokachu, out oauth/launchpad lib code is  think of most things as simple string and numbers. dates have to be written as strings I think
[18:01] <stokachu> ah gotcha
[18:02] <stokachu> if i authorize against launchpad.net and attempt to call api.staging.launchpad.net that will fail b/c of auth correct?
[18:02] <sinzui> correct
[18:03] <sinzui> Lplib scripts will prompt you to authorise for the new host
[18:03] <stokachu> ok
[18:04] <stokachu> crap still getting unauthorized
[18:05] <stokachu> so here is my header information http://pastebin.com/uB4axged
[18:05] <sinzui> stokachu, pastebin the script or the part that does the login/auth
[18:05] <stokachu> ok
[18:07] <stokachu> http://pastebin.com/8RdQruEi - so this is my library
[18:08] <stokachu> line 137-149 is where im having the issue
[18:08] <stokachu> im wondering if im not providing enough header information
[18:10] <sinzui> Ah I see you are implementing a PHP lib that duplicates part of LaunchapdLib. You will need to manage the JSON serialisation yourself
[18:11] <sinzui> stokachu, I think you should look at http://bazaar.launchpad.net/~lazr-developers/launchpadlib/trunk/files/head:/src/launchpadlib/ which shows how credentials and serialisation is done
[18:11] <stokachu> ok ill check that
[18:15] <stokachu> i dont think im getting to the point of parsing the response yet
[18:16] <stokachu> when i do 'request' => 'GET /1.0/people/+me HTTP/1.0 it gives me unauthorized
[18:16] <stokachu> even though +request-token and +access-token succeeds
[18:17] <sinzui> stokachu, I think the request is missing the Lp cookie that contains who you are. +me looks for the user in the interaction of the request, and that will come from a cookie
[18:19] <stokachu> ok, i may be using the wrong scheme here.. i see launchpad uses http authorization scheme
[18:19] <stokachu> and i may be pushing it through just post
[18:21] <lifeless> our oauth module is homebrewed; its possible we only implemented the Authenticate header approach for OAuth
[18:32] <stokachu> ok i see, lifeless, i think youre right i dont see anything related to the authorization in the headers
[18:32] <stokachu> hmmmmm
[18:33] <sinzui> lifeless, stokachu. I think partial implementation is the case here. I recall something came up a a few years ago where where made a change to stay compatible, but did not elect to do a full implementation
[18:35] <sinzui> abentley, rick_h_, jcsackett, wallyworld (Ian) has three important in the review queue. I am mentally challenged at the moment. I can review the disclosure rules that are in the branches, but most of the implementation is better reviewed by a rocket scientists
[18:35] <stokachu> :P
[18:35] <abentley> sinzui: I'll have a look.
[18:36]  * sinzui has taken a second dose of cough medicine and now has that disconcerting feeling of contentment.
[18:36] <stokachu> haha
[18:36]  * sinzui fears that when he yawns, a hole will open up behind him and will fall out of the universe
[18:36] <abentley> sinzui: rofl.
[18:36] <stokachu> what are the request bugs? i'd like to see all 3 consumer requests methods
[18:37] <stokachu> or at least the one where you send as HTTP POST
[18:38] <sinzui> abentley, I am not kidding. me + cough syrup = mescaline induced hallucinations. I never want that to happen again
[18:38] <abentley> sinzui: I'm sorry.  "disconcerting feeling of contentment" was too much for me.
[18:39]  * sinzui does want to re-enact the Odyssey again
[18:39] <sinzui> abentley, it is okay to laugh. my wife does
[18:39] <sinzui> I am serious that I am mentally challenged
[18:41] <stokachu> ok im going write a helper routine to implode my parameters into an Authorization request
[18:41] <stokachu> see if i can get authed then
[22:36] <StevenK> james_w: O hai
[22:37] <james_w> hi StevenK
[22:38] <StevenK> james_w: lifeless said you guys have a standard way of bringing Django apps, is that right?
[22:41] <james_w> StevenK, ish
[22:41] <james_w> we have what we currently think to be the best way
[22:41] <james_w> but none of our apps probably comply fully with that :-)
[22:42] <StevenK> james_w: Are you able to point me at some details?
[22:43] <james_w> StevenK, lp:pkgme-service is the newest one which you may want to use as an example
[22:43] <james_w> https://wiki.canonical.com/JamesWestby/DjangoDeploymentBestPractices has some notes
[22:44] <StevenK> james_w: Thanks, I'll look over both