[00:00] <StevenK> I'm looking at it.
[00:00] <StevenK> I'm vaguely disgusted by lines 70-84 of the diff
[00:00] <StevenK> Oh, you're just moving code.
[00:01] <wgrant> Yeah, moving body elements into the body :)
[00:02] <StevenK> &lt;/script&gt;
[00:02] <StevenK> Excuse me while I review my breakfast.
[00:02] <wgrant> Thankyou Internet Explorer :)
[00:06] <StevenK> wgrant: r=me
[00:06] <wgrant> StevenK: Thanks.
[00:24] <StevenK> wallyworld__: I've handled PUBLICSECURITY -> UNEMBARGOEDSECURITY in my branch.
[00:24] <wallyworld__> StevenK: aewsome, thank you :-)
[00:25] <wallyworld__> StevenK: there's a card for that i think
[00:26] <StevenK> 510 line branch
[00:33] <StevenK> wallyworld__, wgrant: Either of you want to review https://code.launchpad.net/~stevenk/launchpad/move-to-informationtype/+merge/96271 ?
[00:33] <wallyworld__> i can
[00:34] <wgrant> StevenK: Why did you use sponge?
[00:34] <wgrant> sed -i...
[00:34] <wallyworld__> StevenK: btw, a branch of mine should be out of ec2 rsn and wil need to be merged into yours
[00:34] <StevenK> Arse
[00:52] <StevenK> wallyworld__: When is your branch due out of ec2?
[00:53] <wallyworld__> StevenK: i ec2 landed it around 7am
[00:53] <StevenK> My time or yours?
[00:53] <wallyworld__> not should be done very soon i hope
[00:53] <wallyworld__> s/not/so
[00:53] <wallyworld__> my time of course :-)
[00:53] <StevenK> wallyworld__: Run 'bin/ec2 ls' ?
[00:54] <wallyworld__> up for 3:54
[00:54] <StevenK> Right, it should land in the next 15 or so
[00:54] <StevenK> wallyworld__: I'll hold off on the branch you approved, then.
[00:54] <wallyworld__> StevenK: thanks, otherwise there will be conflicts
[00:54] <StevenK> Wait for yours, merge, fix conflicts and re-check.
[00:55] <wallyworld__> yes, plus rename new uses of AccessPolicyType
[00:55] <wallyworld__> in tests etc
[00:55] <StevenK> Right
[00:55] <wallyworld__> there will only be a few, if any, can't remember
[00:55] <StevenK> I was going to grep for it again
[00:56] <wallyworld__> ok
[00:56] <StevenK> I can share the one-liner I used, if you wish
[00:56] <wallyworld__> ok
[00:56] <wallyworld__> i don't use sed that much
[00:56] <StevenK> wallyworld__: for f in $(bzr grep -l AccessPolicyType) ; do sed -e 's/AccessPolicy\(Type\)/Information\1/g' < $f | sponge $f ; done
[00:56] <wallyworld__> i love a got bit of regex
[00:56] <wgrant> bzr grep -l AccessPolicyType | xargs sed -i -e ''s/AccessPolicyType/InformationType/g'
[00:56] <wallyworld__> good
[00:57] <StevenK> Bah, xargs
[00:57] <wallyworld__> i like xargs better too
[00:57] <wallyworld__> what does sponge do?
[00:59] <StevenK> wallyworld__: sponge soaks up all standard input and then writes it to a file
[01:00] <StevenK> wallyworld__: If you do 'sed < file > file' what happens is the shell opens file for writing with truncate, so when sed gets a hold of it, it's empty
[01:00] <wallyworld__> oh, interesting
[01:01] <StevenK> wallyworld__: http://pastebin.ubuntu.com/872355/
[01:02] <wallyworld__> right
[01:16] <wallyworld__> StevenK: merge done
[01:16]  * StevenK updates his devel with fear and trepidation
[01:17] <wallyworld__> StevenK: if you get yours into ec2 within say 30 minutes or a bit longer, you'll make the next bb run
[02:09] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-869631/+merge/96280
[02:10] <StevenK> wgrant: Excellent work, r=me
[02:10] <wgrant> Thanks.
[02:44] <StevenK> wallyworld__, wgrant: Either of you want to review https://code.launchpad.net/~stevenk/launchpad/drop-garbo-accesspolicy/+merge/96285 ?
[02:45] <wgrant> StevenK: Weren't there additional product and distribution grants to remove security.cfg?
[02:45] <wgrant> This should probably just be a straight antimerge of the rev.
[02:45] <StevenK> It was
[02:51] <StevenK> wgrant: bzr di -r 14900..14901 doesn't show the distribution/product addition
[02:52] <wgrant> StevenK: Hm, I thought it was in the original MP. Maybe it isn't any more.
[02:52] <wgrant> Or it was added with the workitem migrator
[02:52] <wgrant> That's more likely.
[02:52] <StevenK> I remember adding it
[02:57] <StevenK> wgrant: Removed them manually
[02:57] <wgrant> StevenK: You'll probably break the workitem migrator.
[02:57] <StevenK> "Good" ?
[02:57] <wgrant> Heh
[02:58] <wgrant> Yes, r14893 (the workitem migrator) added those two
[02:58] <wgrant> Which is why they're not in your diff.
[02:58] <StevenK> Ah
[02:59]  * StevenK wonders if bzr uncommit and push --overwrite will cause issues
[02:59] <wgrant> Will work fine.
[03:03] <StevenK> wgrant: Since we've just spent 15 minutes talking about it, do you want to rubber stamp it?
[03:03] <wgrant> If X stops crashing.
[03:03] <StevenK> Unlikely.
[03:03] <wgrant> At least with -radeon it doesn't hang the kernel.
[03:03] <StevenK> I suggest NVidia.
[03:03] <wgrant> Is approved.
[03:04] <StevenK> wgrant: Thank you.
[03:04] <wgrant> Nah, these crashes are unrelated to the drive.
[03:04] <wgrant> r
[03:04] <StevenK> I can see it conflicting horribly with my branch that is in ec2 now, but meh
[03:29] <StevenK> wgrant: Can you explain the trigger stuff you mentioned on the call this morning?
[03:34] <wgrant> StevenK: You may not need a trigger, but it's possibly easiest.
[03:34] <wgrant> StevenK: We need to migrate from the two flags to the enum.
[03:35] <wgrant> There are multiple triggers and bits of application code that use the flags.
[03:35] <wgrant> The easiest way to migrate may be to map flag changes to enum changes in the DB.
[03:38] <StevenK> So I add a bit to bug_mirror_legacy_access ?
[03:40] <nigelb> Where is bigjools? Apartment hunting?
[03:40] <bigjools> sat here!
[03:40] <StevenK> He's teasing me in another channel, at the moment.
[03:41] <wgrant> StevenK: You could potentially work it into that.
[03:41] <bigjools> I was straight-batting your troll back
[03:41] <wgrant> StevenK: It's not clear how it fits into bugtaskflat.
[03:41] <wgrant> StevenK: (which isn't landed yet, partly for this reason)
[03:41] <StevenK> Mmmm
[03:42] <StevenK> So we can ignore the trigger thing, and do it in code+garbo
[03:42] <StevenK> Which allows bugtaskflat in
[03:43] <wgrant> Our data access layer is sufficiently chaotic that that is normally impractical.
[03:43] <wgrant> But for this limited case you may be able to do it.
[03:43] <wgrant> Since the two flags already have custom behaviour.
[03:43] <StevenK> Right.
[03:45] <wgrant> bugtaskflat may continue to have the private flag, I suspect.
[03:46] <wgrant> Calculated from whether the type is private or not.
[03:46] <wgrant> But it may also want to have a copy of the type.
[03:46] <StevenK> I suspect it would do better with just a copy of the type
[03:47] <StevenK> Then Bug.private and Bug.security_related can just *die*
[03:47] <StevenK> And good riddance
[03:48] <wgrant> Right, those two certainly die.
[03:49] <wgrant> But for performance and sense it may be best for BugTaskFlat.private to still exist.
[03:49] <nigelb> bigjools: HA. I did not se that reply until now :)
[03:50] <bigjools> nigelb: :)
[03:50] <StevenK> wgrant: I will ignore triggers for now and deal with updating information_type in my model branch
[03:50] <wgrant> StevenK: Sounds reasonable.
[03:50] <wgrant> I guess it's only the appservers that really matter here.
[03:51] <StevenK> ENOSTUB though
[03:53] <StevenK> lifeless: Are you happy to review this DB patch, or do I get to wait until tomorrow afternoon?
[03:53] <wgrant> lifeless: Also, want to request a deploy of your DB patch?
[03:55] <lifeless> StevenK: stub should be around soon, I may have a look if you toss me a url
[03:55] <lifeless> wgrant: good idea! want to toss it up?
[03:55] <StevenK> lifeless: stub will not be around. It's a public holidays in .th today.
[03:56] <wgrant> lifeless: Sure
[03:57] <lifeless> wgrant: thanks
[03:57] <lifeless> StevenK: ah, so what is the url?
[03:57] <StevenK> lifeless: Still sorting out the MP, give me a few.
[03:59] <StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/db-add-information_type/+merge/96290
[04:05] <lifeless> we should probably deprecate comments
[04:05] <lifeless> do them in the patches
[04:07] <StevenK> lifeless: I think that's probably orthogonal :-)
[04:07] <lifeless> anyhow, you tried to use a default, which you can't.
[04:08] <wgrant> Well
[04:08] <wgrant> You can add a default afterwards
[04:08] <wgrant> But you can't set a default on create
[04:08] <wgrant> Should be able to do it in the same patch, no?
[04:08] <lifeless> alter table add column foo integer default 1 -> rewrites the heap.
[04:09] <lifeless> alter table add column foo integer; alter table alter column foo set default 1; -> ok.
[04:09] <lifeless> (not-quite-sql)
[04:09] <wgrant> Right.
[04:09] <wgrant> That's what I Meant.
[04:09] <lifeless> StevenK had the former
[04:09] <wgrant> Also, comments don't take locks, so we can keep comments.sql if we want
[04:09] <lifeless> wgrant: meh.
[04:10] <lifeless> wgrant: one system to rule them all
[04:11] <StevenK> Just thinking about it, the default is dangerous, so I'll remove it
[04:11] <wgrant> Hmmm, I think xx-builder-page.txt might get into an infinite redirect loop with the broken <noscript>...
[04:11] <wgrant> StevenK: We already default private to false.
[04:11] <wgrant> IIRC
[04:12] <wgrant>  private                | boolean                     | not null default false
[04:12] <StevenK> wgrant: Right, but DB patch gets deployed with information_type default to 1, and someone files a private bug. It's now private = true and information_type = 1
[04:13] <wgrant> Sure, we need to run garbo and then verify.
[04:13] <lifeless> I prefer no default
[04:13] <lifeless> for that exact reason
[04:13] <StevenK> I agree
[04:13] <wgrant> This is going to be a common thing with migrations, but sure.
[04:14] <StevenK> I'm happy to add a default when there is code to deal with the above case.
[04:18] <StevenK> lifeless: Diff updated
[04:23] <lifeless> wgrant: it is, I think the defaults should be added late or never
[04:23] <lifeless> wgrant: -> because the code to sync them with other things can only be added after the columns
[04:24] <lifeless> wgrant: -> and the way to do a write-through-check e.g. garbo migrator, is to look for unset values
[04:24] <wgrant> lifeless: In some cases.
[04:24] <wgrant> Sometimes that's not possible.
[04:25] <lifeless> do you think there is a better sane-default-position ?
[04:26] <wgrant> I guess looking for unset values works for this case, so we can do that.
[04:26] <lifeless> so, if you think we should recommend something else, lets do that
[04:26] <StevenK> Was my plan
[04:26] <lifeless> I totally ack that there may be different cases out there
[04:27] <lifeless> and am v. happy for folk to do whatever is needed; I'd like the common case to be what we encourage
[04:27] <lifeless> which, AFAICT, is add without default and use null to detect unset [excluding new FK's]
[04:34] <StevenK> lifeless: Can haz another look?
[04:49] <StevenK> wgrant: Have you seen http://pastebin.ubuntu.com/872533/ before?
[04:50] <wgrant> StevenK: It happens one in a couple of hundred runs.
[04:50] <wgrant> Maybe less
[04:50] <wgrant> But it's not unheardof.
[04:51] <StevenK> I'll ignore it then
[04:51] <StevenK> My move-to-informationtype branch has tripped over it.
[04:58] <wgrant> Debugging hanging doctests makes me sad.
[06:34] <wallyworld__> StevenK: how far away is your enum branch?
[06:35] <wallyworld__> ah, bb. are you going to land it manually?
[06:35] <StevenK> It just failed ec2.
[06:36] <wallyworld__> ok. i have a new branch that will conflict with it. i'll wait till yours in merged before landing mine
[06:37] <StevenK> And we're in testfix
[06:37] <StevenK> For the love of ...
[06:37]  * StevenK marks it testfix because buildbot is so crap
[06:38] <wallyworld__> tsk tsk
[06:38] <StevenK> If I would be allowed to actually move us to Jenkins, we wouldn't have to do this crap
[06:39] <wallyworld__> yep :-(
[06:39] <wgrant> StevenK: You must never mark a non-testfix branch as testfix
[06:39] <wgrant> Force the buildbot build.
[06:40] <StevenK> And then wait twelve hours instead of six
[06:40] <StevenK> wallyworld__: r14911, and I'm a bad man.
[06:40] <wgrant> In either case you'll be asleep.
[06:40] <wallyworld__> StevenK: thanks. and yes, you are very naughty and must be punished
[06:41] <StevenK> I should look at writing a fixture for convoy for use in buildbot and ec2. That sounds fairly punishing.
[06:42] <wgrant> Well
[06:42] <wgrant> It probably wants to be a layer.
[06:42] <wgrant> Using a fixture.
[06:50] <bigjools> there's a thing for that
[08:54] <adeuring> good morning
[11:09] <rick_h_> morning
[11:11] <czajkowski> rick_h_: good day to you sir
[11:16] <rick_h_> gah, let the email catch up begin!
[14:32] <deryck> adeuring, ping for standup.
[14:33] <adeuring> deryck: whoops, coming..
[15:11] <abentley> deryck: I think my --dry-run output looks right, but could you check? https://pastebin.canonical.com/61826/
[15:17] <deryck> abentley, looking....
[15:17] <deryck> abentley, yeah, looks fine to me.
[15:17] <abentley> deryck: cool, thanks.
[15:18] <salgado> mrevell, hey there. did you get a chance to work on that announcement?
[15:25] <abentley> deryck: My mail issue appears to be because ec2 doesn't copy my smtp credentials to the instance.  But Canonical smtp requires credentials, so I don't understand how this works for anyone.
[15:25] <deryck> abentley, hmmm, yeah, I'm not sure either.
[15:26] <deryck> abentley, maybe gary_poster has an idea about how the mailing works?
[15:26] <abentley> gary_poster: ping :-)
[15:27] <gary_poster> abentley, :-) I'm reading backlog
[15:27] <gary_poster> um
[15:27] <gary_poster> that's a long time ago...
[15:27] <gary_poster> thinking
[15:29] <rick_h_> abentley: the only thing I recall is getting my smtp creds into my bazaar.conf on default
[15:29] <rick_h_> my only other issues were gpg related, not email side
[15:30] <abentley> rick_h_: Are they in bazaar.conf or authentication.conf?
[15:30] <rick_h_> bazaar.conf
[15:30] <rick_h_> abentley: I don't have any email settings in authentication.conf
[15:31] <abentley> rick_h_: mine is in authentication.conf, so maybe that's why ec2 doesn't see it.
[15:31] <rick_h_> yea, I've got smtp_username/server/password in bazaar.conf and I've never had email issues with ec2
[15:33] <sinzui> rick_h_, I too had to add smtp_* which also requires me to set my address to the one provide by canonical. I then had to visit location.conf to put my email address back for non-canonical projects
[15:37] <abentley> sinzui: Well, you don't technically *have* to use a smtp.canonical.com to send mail from a canonical.com address :-)
[15:37] <gary_poster> abentley, confirmed that my mail configuration is in bazaar.conf.
[15:37] <sinzui> abentley, are you running your own smtp?
[15:38] <gary_poster> I think some docs (used to?) advise this
[15:38] <sinzui> gary_poster, yes, the new launchpader setup and rocketfuel setup pages both recommended it
[15:38] <gary_poster> yeah
[15:39] <czajkowski> ok hands up who understand private bugs as I'm a bit confused (yes I know it happens a lot)
[15:39] <abentley> gary_poster: I believe authentication.conf is the preferred method within the Bazaar community, so that's what I've used.  It would be nice to support everything Bazaar does.
[15:40] <abentley> gary_poster: I'm a bit lost trying to figure out how the credentials are transmitted to the test instance.
[15:40] <czajkowski> trying to work out if a person should see a private bug if they are part of a project or not
[15:41] <abentley> sinzui: yes, I am running my own smtp.
[15:45] <gary_poster> abentley, this code has changed far, far from what I wrote.  I would look for what is copying over bazaar.conf and have it also copy over authentication.conf, perhaps
[15:46] <gary_poster> czajkowski, I don't but people on sinzui's squad will, and deryck and gmb probably will, among others (whee, ping fest, hi everybody!)
[15:46] <gmb> Wat?
[15:46]  * gmb backscrolls
[15:46] <czajkowski> gary_poster: good day :)
[15:46] <gary_poster> :-)
[15:47]  * deryck looks up ???
[15:47] <sinzui> czajkowski, no, not today
[15:47] <gmb> czajkowski: sinzui and squad are your folks for that .
[15:47] <gary_poster> gmb, are you willing to admit knowledge of private bugs?
[15:47] <sinzui> Only subscribed users/teams/bots can access a private bug.
[15:47] <czajkowski> gmb: wondering does a get to see private bugs if they are in a project that the private bug has been reported on
[15:47] <abentley> gary_poster: cool.  I found it.
[15:47] <gmb> gary_poster, Not any more, unless sinzui hasn't been a-changing all the rules, in which case those were some very strong drugs I took.
[15:47] <gary_poster> deryck and gmb, sorry, was just thinking bug thoughts
[15:48] <gary_poster> heh
[15:48] <czajkowski> https://answers.launchpad.net/launchpad/+question/188450
[15:48] <czajkowski> is why I am asking
[15:48] <czajkowski> sinzui: *hugs*
[15:48]  * gary_poster runs away
[15:48] <gmb> Why I can't open a private bug that affect PlayOnLinux project?
[15:48] <gmb> Thanks in advance,
[15:48] <gmb> Aymeric.
[15:48] <deryck> heh.  I shall ignore you all.
[15:48] <gmb> WTF?
[15:48] <gmb> OIC.
[15:48] <gmb> Sorry. C+P spam
[15:48] <sinzui> czajkowski, For 5 months, we allows the project maintainer to access all private bugs, but we are now transitioning to sharing. In two weeks, we might restore project-level access to private bugs
[15:49] <gmb> czajkowski: Ah, I filed a bug about private things returning an OOPS with their 404, which I think is wrong. There may have been some discussion about this.
[15:49]  * czajkowski hands gmb a very large coffee
[15:49] <gmb> You saw what the nespresso machine did to me, let's not go down that road again.
[15:50] <sinzui> gmb: lifeless dupe that bug after we investigated and found that the bug was targeted to a deactivated project
[15:50] <gmb> Ah.
[15:50] <czajkowski> sinzui: gotcha so right now, unless they are the project maintainer they cannot see the private bugs
[15:50] <gmb> That's a merry can of worms.
[15:50] <sinzui> czajkowski, no
[15:50] <sinzui> The user must be subscribed to the bug
[15:50] <sinzui> no exceptions this week
[15:51]  * gmb goes back to futzing around with packaging, which is marginally less fun than poking a knitting needle into one's eye to see what happens.
[15:51] <sinzui> czajkowski, commercial projects *had* an exception for 5 months
[15:54] <czajkowski> sinzui: gotcha but it's not a commerical project.
[15:54] <sinzui> okay. then subscription was the only way to get access to a private bug or branch for that matter
[15:59] <stokachu> does the oauth_tokens expire on staging?
[16:00] <sinzui> stokachu, they are no different from production...but staging's database it replaced almost every Saturday
[16:01] <stokachu> sinzui: ok
[16:01] <mrevell> salgado, flacoste: I'm in the Product channel on Mumble.
[16:02] <mrevell> salgado, flacoste: https://dev.launchpad.net/Projects/WorkItems/
[16:12] <flacoste> salgado: http://bazaar.launchpad.net/~canonical-launchpad-branches/lp-dev-utils/trunk/view/head:/spam.py
[16:34] <stokachu> what api call(s) should i be using to grab a list of bugs (public/private) that are assigned to me?
[16:34] <stokachu> is al lthat done through collections link?
[16:42] <stokachu> do i just query a collection of bugs and find their owner link?
[16:42] <sinzui> stokachu, this is an example in Python: http://pastebin.ubuntu.com/873230/
[16:42] <sinzui> The documentation is https://launchpad.net/+apidoc/devel.html#has_bugs
[16:43] <stokachu> ok thanks ill look at that
[16:44] <stokachu> ah makes sense, sinzui thanks :)
[16:54] <abentley> sinzui: Now that ec2test is standalone, it requires the python-tz package to be installed as a deb.  Can we add it to launchpad-developer-dependencies?
[16:56] <sinzui> abentley, we can. I thought it was indirectly in the deps though. I have always had the package without the need to install it
[16:56] <stokachu> sinzui: im doing this in php and has_bugs mentioned underlying entry, where does this entry get called from?
[16:57] <abentley> sinzui: I did have to install it.
[16:59] <abentley> sinzui: But I don't have launchpad-developer-dependencies installed right now, because it says rabbitmq-management is broken.
[17:00] <sinzui> stokachu, Launchpadlib maps the entity data from Lp to the WADL definition. It essentially instantiates a generic object and adds the properties and methods.
[17:00] <sinzui> abentley, that is true...I have pinned my rabbit libs so that I can keep the meta packages installed
[17:01] <sinzui> wgrant, has some experience packaging rabbitmq for Lp. I do not know why we cannot use what Ubuntu provides
[17:05] <stokachu> sinzui: ok but i can't pull objects through api interface over php
[17:07] <sinzui> stokachu, LPAPI does not provide objects. It send a json data about the object. One of the json properties maps to type defined in the WADL.
[17:07] <stokachu> ok
[17:23] <stokachu> sinzui: so that brings me back to calling the api for all bugs and breaking it down through there?
[17:23] <stokachu> i see the resource_type_link in the properties
[17:27] <stokachu> So my entry point looks like it would be api/bugs, grab the bug_tasks_collection_link, and there i can capture the assignee link
[17:27] <sinzui> stokachu, resource_type_link points to the WADL that states what you can do with the resource. The resource has a self link. posting data to that self link will return another entity or maybe return a collection of entities.
[17:28] <sinzui> stokachu, you might be able to search all bugs, but I do not think you should. There will be a million bugs in a few months. Your requests will timeout out or if your script DOSes Lp, it will be blocked
[17:29] <stokachu> yea i wasn't planning on searching all bugs
[17:33] <stokachu> but im still a little confused on what entry point to use.. if i pull a person collection there are no resources there that describe what bugs i may be assigned to
[17:34] <stokachu> pulling a bug collection pulls all bugs and thats not what we want
[17:34] <stokachu> and in order to get a bug tasks collection you need to know the bug id
[17:36] <stokachu> looks like launchpad lib gives you the ability to searchTasks which meets a certain criteria
[17:37] <stokachu> the top level bugs collection doesn't give me the ability to define criteria
[17:42] <stokachu> sinzui: in your example you do a lp.people['registry']
[17:42] <stokachu> what is registry?
[17:43] <sinzui> ~registry is a team I am a member of.
[17:43] <sinzui> Teams and users hare about 75% of the same methods and properties
[17:44] <stokachu> ahh.. maybe i should think in terms of teams rather than a single person
[17:45] <stokachu> so when you return lp.people['registry'] what is providing you with searchTasks
[17:46] <stokachu> ah team..
[17:47] <stokachu> sinzui: now i see...
[17:47] <stokachu> team->searchTasks
[17:48] <stokachu> ok ok.. sinzui think i understand now, ill leave you alone :)
[17:49] <sinzui> stokachu, Lp uses person to mean team or user. They are often interchangable. We use "user" or "team" only when we are doing something specifically to the type. Teams have members, users have ssh keys for example. the API webdoc also confuses users and teams. Both are Person and you can do most things operations without needing to check which type you got back from Lp
[17:50] <stokachu> sinzui: yea the whole 'user' 'team' thing was giving me a runaround
[17:50] <stokachu> like in the sub_teams_collection_link for person collection it says lists 'subteams of this team'
[17:50] <stokachu> so that is veryyyy confusing
[18:40] <stokachu> for clarity once i retrieve my person collection i can do api.launchpad.net/~adam-stokes?ws.op=searchTasks?
[18:47] <sinzui> stokachu, I think you need to post to an API version. Maybe api.launchpad.net/devel/~adam-stokes?ws.op=searchTasks
[18:48] <stokachu> sinzui: this is my url https://api.staging.launchpad.net/1.0/~adam-stokes?oauth_consumer_key=drupallp&oauth_nonce=517b21443bea00d082c9961b40c79bb6&oauth_signature=%26mZQnG1jG85KLcn1j1p6Q4SZf5c4CcpWzJbcrvW2GX2xS2gqnmZCm6lSw7Q10gfc5m1zG9zr8QZMTp6rp&oauth_signature_method=PLAINTEXT&oauth_timestamp=1331145573&oauth_token=6Srv0p37zxM4k1fMqBrr&oauth_version=1.0&ws.op=searchTasks
[18:48] <stokachu> it looks like its a GET request from the documentation
[18:48] <stokachu> crap
[18:49] <stokachu> i thought i scrubbed the tokens
[18:49] <stokachu> lmao
[18:49] <stokachu> ill revoke it in a few
[18:50] <stokachu> sinzui: so with the above url it just returns false
[18:52] <stokachu> i didnt see any other requirements for this call either
[18:52] <sinzui> stokachu, I think the oauth cannot be in the URL. The method you are testing can be used anonymously (only public data is returned): eg, you can see me at https://api.launchpad.net/devel/~sinzui?ws.op=searchTasks
[18:53] <sinzui> I have a lot of bugs
[18:53] <stokachu> ok, what about accessing private bugs?
[18:53] <sinzui> Your request must have a cookie issued by oauth
[18:54] <sinzui> You can see my assigned bugs with this query direct request https://api.launchpad.net/devel/~sinzui?ws.op=searchTasks&assignee=https://api.launchpad.net/devel/~sinzui
[18:54]  * sinzui has no private bugs assigned
[18:54] <stokachu> sinzui: so in my headers i have the authorization set
[18:56] <stokachu> ok so.. i think i see, my get requests shouldnt be putting in my oauth data because its in the authorization header
[18:56] <stokachu> lemme try something
[18:58] <sinzui> stokachu, I think the process LPLib process is start engine, call login, check credentials+host to get session cookie info, do oauth to get session cookie info, make request with cookie info and go post/get to url
[18:59] <stokachu> yea i think thats what im doing wrong..only keep the authorization in the header and just make the requests
[19:49] <salgado> jcsackett, around?  would you mind ec2-landing https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-widget/+merge/94790?  the announcement is in the works so we can expect it to be ready by the time this reaches staging and is QAed
[20:02] <salgado> sinzui, maybe you can do that for me? (^)
[20:03] <sinzui> salgado, I will do that now
[20:03] <salgado> sinzui, yay, thank you!
[22:09] <StevenK> lifeless: Can *please* haz another look at my DB patch?
[22:09] <sinzui> StevenK, wgrant: can either of you review this and +1  it http://pastebin.ubuntu.com/873679/
[22:55] <sinzui> wallyworld__, http://bazaar.launchpad.net/~sinzui/essence-contact/trunk/view/head:/essence/test_contact.py
[23:33]  * wgrant is still shocked by seeing bigjools commenting on bugs at odd hours