[00:07] <micahg> in the email interface if I want to affect multiple packages and set the status for each, is that possible?
[00:40] <wgrant> micahg: Use multiple affects commands, following each with a status command.
[01:04] <micahg> wgrant: ok, that's what I figured, but the docs seem to imply that all the affects commands need to be first
[11:41] <d1b> hi um i logged into launchpad to edit a wiki page and i hit this
[11:43] <wgrant> d1b: What's the issue?
[11:44] <d1b> 1 s
[11:44] <d1b> http://pastebin.com/axSZiZyt
[11:44] <d1b> the redirect failed - it might because i had js disabled but ..
[11:45] <wgrant> d1b: It looks like the wiki doesn't like usernames with + signs in them.
[11:45] <d1b> wgrant: now im getting an error 500
[11:45] <wgrant> You could rename your Launchpad account, I guess :/
[11:45] <d1b> wgrant: no
[11:46] <d1b> :P
[11:47] <wgrant> Otherwise you'll have to track down whoever maintains the Ubuntu wiki auth plugin these days.
[11:47] <d1b> or just sign up with a wiki account / new account
[11:47] <wgrant> True.
[11:59] <d1b> wgrant: wany reason why the max password is 20 chars?
[11:59] <d1b> lenth*
[12:00] <wgrant> d1b: Is it? That sounds like a bug.
[12:00] <wgrant> In fact, my password is far longer than that...
[12:00] <wgrant> Where are you seeing that?
[12:00] <d1b> wgrant: on the sign up page
[12:00] <wgrant> Which URL, exactly?
[12:00] <d1b> 1 min
[12:01] <d1b> https://login.launchpad.net/+new_account
[12:01] <d1b> --> password field size=20
[12:03] <wgrant> d1b: Your browser limits it to that size?
[12:03] <wgrant> That's normally just a suggestion for how wide the textbox should be, not the value inside.
[12:15] <d1b> yes /me is tired. yeah i think that is the case
[12:15] <d1b> sorry
[12:21] <d1b> weird, my username is now daveb, my 'fullname' is daveb - so it must not like the + in my email now
[12:21] <d1b> erh... but im now logged in
[12:21] <d1b> ./sleep &
[12:21] <wgrant> Heh.
[12:22] <wgrant> I should as well, once this deployment is done.
[12:24] <d1b> the wiki page just throws up 500s to a lot ...
[12:55] <Adri2000> hi
[12:55] <Adri2000> is it possible to subscribe to a merge proposal? (without subscribing to the whole branch and receiving all commits)
[12:56] <wgrant> Adri2000: You can't subscribe directly to a merge proposal, but you can subscribe to just merge proposals on the proposed branch, without subscribing to revisions.
[13:10] <Adri2000> wgrant: ok, thanks
[14:20] <hazmat> does launchpad karma calculation skew to whoever owns the trunk of a repository..ie they get points for merges to trunk, even if they where not involved in any of the branch commits or merge.
[15:07] <niemeyer> Yo!
[15:07] <niemeyer> I need a hand in a fight with PPA
[15:08] <bigjools> niemeyer: wassup
[15:08] <niemeyer> Anyone willing to spend some time for the cause?
[15:08] <niemeyer> bigjools: hey!
[15:08] <niemeyer> bigjools: Trying to build golang there
[15:08] <niemeyer> bigjools: The package has lots of tests, among them something for the syslog module which communicates with the local syslog over unix sockets
[15:09] <niemeyer> bigjools: Works fine locally, but apparently I'm unable to convince the PPA to bring up the syslog dameon
[15:09] <niemeyer> daemon
[15:09] <bigjools> I vaguely remember problems like this before
[15:09] <bigjools> the chroot may not start a syslog
[15:10] <barry> leonardr: did you try my ppas?
[15:10] <niemeyer> Hmmm, chroot
[15:10] <niemeyer> bigjools: So is it a lost cause, or is there a workaround?
[15:10] <bigjools> lamont: what do you know about our buildd chroots and syslog?
[15:10] <leonardr> barry: i forgot about them before the maverick build completed. let's try again
[15:10] <bigjools> niemeyer: lamont may know more, he's the buildd admin
[15:11] <niemeyer> bigjools: Ah, superb, thanks
[15:11] <barry> leonardr: thx
[15:11] <niemeyer> lamont: What's the magic sauce?
[15:11] <bigjools> Salt Lick BBQ sauce, Driftwood, Texas.  But I digress :)
[15:12] <niemeyer> bigjools: Hmmm, sounds good :)
[15:26] <leonardr> barry: could you do me a huge favor and repackage the natty version of lazr.restfulclient for maverick?
[15:26] <leonardr> otherwise i can't test
[15:26] <leonardr> alt. i can upgrade one of my machines to natty, but that'll take a while
[15:56] <lamont> bigjools: daemons do not start in build chroots.
[15:56] <bigjools> lamont: yeah I figured as much
[15:56] <lamont> niemeyer: the solution is to stop wanting that
[16:15] <barry> leonardr: will do after my meeting
[16:30] <Guest25832>  /join #dondetuhermana
[16:30] <ScottK> It would have been nice to see speed at least mentioned in https://lists.launchpad.net/launchpad-dev/msg06389.html
[16:33] <maxb> leonardr, barry: dputted to ppa:maxb/launchpad, thought I might as well since it's just a no-change upload :-)
[16:34] <leonardr> maxb, thanks
[16:34] <barry> maxb: thanks.  yeah, i'm building it in my ppa too, but either way should work for leonardr
[16:59] <gary_poster> ScottK, speed is one of the TA's two projects, and an active effort that the product team (of which I am not a member, to be clear) is fully behind.  I believe that email was about upcoming changes.  The performance work is active and current.
[16:59] <gary_poster> hazmat: I know you asked that a while ago, but no one replied.  I have no idea.  Is it important to you?  If so, I can try to investigate.
[17:00] <barry> leonardr: i'm getting some lunch now.  b/w maxb's and my ppa, you should have what you need to test.  please update the bugs with status.  i want to get the new versions into debian and then sync them to ubuntu.
[17:01] <hazmat> gary_poster, i'm a bit curious, as i'm working on a project, where i've got committed most of the lines of code (~80-90%), and done a ton of bug management and some review, and someone who is only doing code reviews is significantly ahead (x2), we both started on the project at the same time, the only difference i can see is that he's owner of the trunk. its baffled both of us.
[17:03] <gary_poster> hazmat, ack.  sinzui, would you happen to know off-hand?  The original question was this:
[17:03] <gary_poster> does launchpad karma calculation skew to whoever owns the trunk of a repository..ie they get points for merges to trunk, even if they where not involved in any of the branch commits or merge.
[17:03] <leonardr> barry: will do as soon as i get this branch into review
[17:03] <gary_poster> that's probably more of a code question, but sinzui knows all...
[17:05] <sinzui> gary_poster: karma is 100% arbitrary and untrustable. I believe karma balancing skews aways from project maintainer and branch contributors. I think karma favours blueprints, answers, and bugs
[17:07] <gary_poster> thanks sinzui.  hazmat, I'm afraid that's what I expected.  I think filing a bug would be a reasonable next step though, if you are willing.  If karma is causing project maintainers/contributors to be unhappy, perhaps we should consider either deciding to spend some more time on it or removing it.  It's supposed to encourage participation, and arbitrariness does not.
[17:07] <sinzui> gary_poster: hazmat those bugs are already filed
[17:08] <sinzui> gary_poster: hazmat: the specific bug is to stop rebalancing karma. We are not working on karma, We are discussing removing it
[17:08] <hazmat> okay.. its good to know its arbitrary and not capricious ;-).. and that relevant bugs are filed.. thanks sinzui, gary_poster
[17:08] <gary_poster> thank you sinzui.  hazmat, heh. :-)  welcome
[17:09] <sinzui> hazmat: indeed that is the core issue. Karma is helpful to identify recent activity, but it is easilly misunderstood and users that it very seriously.
[17:09] <hazmat> sinzui, i'd be in favor of removing it, if the activity stream for a user had enough contextual information to be useful..  https://launchpad.net/~hazmat/+karma ie.. actually linked to the project and artifact in question
[17:10] <hazmat> i hate to say it but something more akin to the github activity for a user.. which has enough contextual info and links to be useful as an rss feed for example
[17:11] <hazmat> as it is rather hard to decipher what karma means, outside of 'goodness'
[17:12] <hazmat> and understanding the relative karma on a project as to a user's contributions to it seems opaque to me
[17:12] <hazmat> i digress, thanks folks
[17:15] <pvo> fwiw ++ on removing karma
[17:16] <gary_poster> hazmat, agree with your analysis, and I think the product team (in charge of direction/features) does as well.
[17:16] <gary_poster> you might or might not be interested in this brainstormy email, psted above in a different context:
[17:16] <gary_poster> https://lists.launchpad.net/launchpad-dev/msg06389.html
[17:16] <gary_poster> "Activity walls"
[17:17] <leonardr> maxb: argh, barry's keyring package is built against a natty version of python. could you maybe put python 2.7.1-0ubuntu2 into that repository?
[17:18] <leonardr> although at this point i should probably just put my desktop on natty
[17:18] <maxb> Putting python 2.7 onto maverick sounds rather like a can of worms
[17:19] <maxb> Rebuilding a more maverick-like python-keyring sounds easier
[17:19] <sinzui> leonardr: natty is fine, though you might want to avoid unity. It has been very unstable for the last 3 weeks
[17:20] <leonardr> maxb: another possibility is that i could tell you some python code to run and you could tell me what happens
[17:20] <leonardr> test it that way
[17:20] <maxb> Run some python code on maverick, or on natty?
[17:24] <leonardr> maxb: on natty, with barry's launchpadlib
[17:24] <maxb> sec, booting natty netbook
[17:27] <maxb> booted. updating. what ppa do I need?
[17:28] <leonardr> maxb: checking...
[17:29] <leonardr> maxb: ppa:barry/python
[17:29] <leonardr> install python-launchpadlib and python-keyring
[17:39] <computerx> lkp.werld.access@x.net
[17:39] <computerx> phreak phreaker
[17:39]  * computerx mixcve@werld.name
[17:39]  * computerx adm|n acc0unt
[17:39] <computerx> u$er{uki.net.com}err0r
[17:40] <computerx> computer{x}
[17:40]  * computerx 192.168.0.1
[17:40]  * computerx linux account access
[17:40] <computerx> $phreak;terminal|*
[17:40] <computerx> ukg$;~|*
[17:41]  * computerx elos$;
[17:41] <maxb> leonardr: now installing those.
[17:41] <computerx> execute: send_submit("form2");
[17:42]  * computerx ;character-map*com|oli$;|
[17:42]  * computerx !n$ta|| dr!v3r
[17:43]  * computerx goode
[17:44]  * computerx Citrix_XenApp5.0_ExpansionServer_W2K8_32bit_v102
[17:45]  * computerx help user admin
[17:45] <maxb> nhandler: Can you kill this bot? ^
[17:45]  * computerx account
[17:45] <computerx> ukil$;.net.com computerx;~
[17:45] <computerx> computer*x|ill;{dlsos$}
[17:47] <nhandler> Looks like it quit
[17:56] <leonardr> maxb: this should test the new launchpadlib pretty well: http://pastebin.ubuntu.com/562102/
[17:57] <maxb> yikes, from launchpadlib.launchpad import Launchpad took something like 3 seconds
[18:00] <maxb> leonardr: During step one, the text on the "Confirm Computer Access" page saying "See all applications authorized to access Launchpad on your behalf." needs updating ("applications")
[18:00] <leonardr> maxb: fair enough
[18:00] <leonardr> "applications and computers"
[18:01] <maxb> leonardr: The "Within a few seconds you should be able to start using its Launchpad integration features." should advise the user that they should now go back and look at the application, not wait for the webpage to say something more
[18:01] <leonardr> ok, file a bug for this stuff if you don't mind
[18:02] <maxb> On the console, the text "Running global cleanup code from study base classes." appeared after authorizing. This is weird.
[18:02] <leonardr> the application is also free to grab the focus, btw--it knows when it's been authorized
[18:02] <leonardr> never seen that before
[18:02] <maxb> I don't have time to file bugs right now, so I'll just say stuff, and search my irc logs later
[18:02] <leonardr> ok
[18:03] <leonardr> maxb: "global cleanup code" is a firefox message
[18:03] <maxb> *blink*
[18:03] <maxb> what's firefox doing accessing stdout in my terminal?!
[18:05] <leonardr> maxb: was firefox running before, or did python start it up when it did the browser open?
[18:05] <maxb> *ah*
[18:05] <maxb> explained, good.
[18:05] <maxb> leonardr: Does lp.people.me ever work? Because lp.people doesn't seem to have such an attribute
[18:05] <leonardr> maxb: argh, typo. should be lp.me
[18:06] <maxb> uhoh, get_token_and_login is behaving wrongly
[18:06] <maxb> first, no deprecation warning
[18:07] <maxb> also, somehow launchpad has given me a "Sorry, you don't have permission to access this page" for accessing /+authorize-token
[18:08] <leonardr> dammit, now i have to remember what get_token_and_login does
[18:08] <leonardr> i already purged that knowledge
[18:09] <maxb> this is repeatable
[18:09] <maxb> my guess is that you're sending +authorize-token the wrong token id
[18:11] <maxb> leonardr: Step 4 [login_with(credentials_file="....")] works as described, but I'm not sure it ought to be requesting a desktop integration token in that case
[18:12] <leonardr> maxb: those arguments are for a desktop integration token. you can get a per-application token by specifying a consumer name instead of an application name
[18:14] <maxb> leonardr: I feel your API change of changing the purpose of positional argument 0 is not appropriate
[18:15] <maxb> I (speaking as an application author programming against the launchpadlibs currently available in released Ubuntu distributions) _am_ specifying a consumer name in this case
[18:15] <maxb> The newer launchpadlib has chosen to reinterpret my api call in a different manner
[18:16] <leonardr> maxb: can you explain why you want to specify a consumer name?
[18:17] <maxb> It's unfriendly for an upgrade of launchpadlib to change the behaviour of existing APIs in this manner
[18:17] <leonardr> maxb: the goal is to transparently migrate you from per-application credentials to desktop-wide credentials. do you have a reason for opting out of that?
[18:18] <maxb> I feel uncomfortable about applications having behaviour "transparently" changed underneath them
[18:19] <maxb> I most particularly do not want several different applications on my system to all request separate desktop integration tokens because they are all written to use per-app credentials_file paths
[18:19] <maxb> Also, why can't I integrate my entire system to change non-private data only?
[18:20] <maxb> (sorry, I'm sure you've heard this one before, I'm just trying to hit on all the things occurring to me from this walkthrough of the proposed new system)
[18:20] <leonardr> maxb: "per-app credentials_file paths" -- i agree, which is why i originally ignored per-app credentials file paths. unfortunately, there's a legitimate use for them, so i had to add them back
[18:21] <mok0> Why would subversion import to LP suddenly stop retrieving new revisions?
[18:21] <leonardr> "why can't I integrate my entire system to change non-private data only" -- we considered that and rejected it as causing way too much confusion. you would create one "desktop-wide" token, and the first time an app needed to change private data you would get another browser open and have to upgrade that credential
[18:21] <mok0> https://code.edge.launchpad.net/~mok0/coot/trunk
[18:22] <leonardr> after this gets into ubuntu we will be going through the ubuntu applications that use launchpadlib and making sure they use the new system well
[18:22] <maxb> leonardr: the kind of people who care about such things will *want* that re-auth to happen
[18:22] <maxb> leonardr: And if you're planning to go through ubuntu apps anyway, that's even more rationale NOT to reorder the login_with parameters
[18:22] <leonardr> maxb: the rationale for reordering the login_with parameters is for _new_ apps
[18:23] <maxb> By doing so you change the behaviour of existing code. Personally I reckon that's not kind to people using your library *at all*, and barely acceptable
[18:23] <leonardr> i want it to be _extremely difficult_ to do a non-system-wide integration except in the case where a system-wide integration is impossible (integrating another web site)
[18:24] <maxb> Let me go over the api changes (will probably not be until the weekend), and write an email
[18:25] <leonardr> maxb: i think you should talk to flacoste or lifeless. i have been going back and forth with developers on this for over a year
[18:25] <Garo_> hello. I'm trying to find out where I can download the sources of the last revision in the trunk for this project? http://bazaar.launchpad.net/~duplicity-team/duplicity/0.6-series/files
[18:26] <Garo_> I'm propably just stupid, but I can't find anywhere the repository url nor any download links for the repository
[18:26] <leonardr> the per-application credential system was broken and useless, and i don't feel a strong need to preserve backwards compatibility for it
[18:28] <maxb> I think it works quite well.
[18:28] <maxb> Moreover, I feel that for a library to change the behaviour of an API call in such a significant way is really quite evil.
[18:29] <leonardr> maxb: just to be clear, we're talking about a system that shuttles the user through a complex process N times, for no more security benefit than doing the same thing 1 time
[18:30] <leonardr> a process so complex that developers will go through almost any amount of work to hack around it
[18:45] <maxb> mok0: That import looks fine to me.
[18:45] <mok0> maxb, it's missing the last two
[18:45] <maxb> Not according to "svn log -v http://coot.googlecode.com/svn/trunk/ --limit 2" executed by me locally
[18:46] <maxb> The returned revisions match the last two shown on the launchpad branch webpage
[18:46] <mok0> maxb: what does "--limit 2" do?
[18:46] <maxb> Just avoids retrieving the entire project history
[18:47] <mok0> maxb, I checked out the repo and I get up to r3357
[18:48] <mok0> maxb: but LP only has upto r3355
[18:49] <maxb> mok0: svn revnums are global to the repository. For this project, r3356 and r3357 did not touch /trunk
[18:51] <mok0> maxb, I am confused. So you are saying that the last 2 revs are not part of trunk?
[18:51] <maxb> yes, exactly
[18:52] <mok0> But if I check out trunk, I get r3357, that's weird
[18:52] <maxb> mok0: Now run "svn info" in the checkout
[18:53] <maxb> Take particular note of "Revision:" vs. "Last Changed Rev:"
[18:53] <mok0> maxb: I hate svn
[18:53] <maxb> hah :-)
[18:53] <mok0> :-I
[18:54] <maxb> It would be more friendly if svn printed the last changed rev of the root, not the revision, after a checkout/update/switch etc.
[18:55] <mok0> maxb: indeed
[18:56] <mok0> maxb: thanks for your help
[18:56] <maxb> np
[18:57] <mok0> Now, if bzr would only know about the svn revno
[18:57] <maxb> it does
[18:57] <mok0> maxb: ah! How so?
[18:57] <maxb> bzr log should show it to you
[18:58] <maxb> (if you have the bzr-svn plugin installed)
[18:58] <maxb> If you don't, you can use bzr log --show-ids and note that the svn revno is the last part of the revision id, for a bzr-svn imported revision
[18:58] <mok0> maxb: I don't,, I think
[19:00] <mok0> Ah, yes, I see
[19:03] <mok0> maxb, that is so cool, now I can extract the svn revision and get a correct name for my package
[19:38] <d34df00d> Hi!
[19:38] <d34df00d> I've heard some rumors that launchpad is going to support .ts files (Qt's translation format) directly, without 3d-party tools for converting them to .po.
[19:38] <d34df00d> Is that really planned?
[19:46] <lifeless> d34df00d: I'm not aware of direct work going on to do that, but we do have pluggable input/output layers, so we probably can do it, or someone could submit a patch.
[20:51] <Meths> lifeless: It's just dawned on me that the line spacing is huge on the revision pages, should they be using the same CSS as the code browsing?
[20:57] <lifeless> Meths: url?
[21:06] <leonardr> barry, mixed results from the launchpadlib test. i gave some code to maxb to run. he reported a problem with one of the deprecated methods.
[21:06] <leonardr> i hosed my netbook upgrading it to natty, so i still can't test on my own
[21:10] <barry> leonardr: ok.  please let me know if there's anything i can help with
[21:11] <leonardr> barry: let me go back to the code and ask you to try some stuff out
[21:11] <barry> k
[21:14] <leonardr> barry: what happens when you run this code?
[21:14] <leonardr> from launchpadlib.launchpad import Launchpad
[21:14] <leonardr> Launchpad.get_token_and_login("foo", "staging")
[21:14] <barry> leonardr: in natty, with the ppas, right?  i need to get my vm updated, sec...
[21:15] <leonardr> barry: right
[21:25] <Meths> lifeless: e.g. difference between http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/12321 and http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/bootstrap.py
[21:31] <leonardr> maxb, when you write up your comments on the change to launchpadlib, please keep in mind these two earlier emails from me, esp. if you haven't read them before
[21:32] <leonardr> http://www.mail-archive.com/launchpad-dev@lists.launchpad.net/msg04664.html and http://www.mail-archive.com/launchpad-dev@lists.launchpad.net/msg04858.html
[21:33] <leonardr> when we make these changes our policy is to talk them over with identified stakeholders (this was an unofficial policy before and it's official as of a couple weeks ago). right now the stakeholders are doctormo, james_w, thekorn, and poolie. if you want to self-identify as a stakeholder we'll include you as well
[21:37] <lifeless> Meths: which is the one that is double spacing ?
[21:38] <Meths> The revision view (first URL).
[21:39] <lifeless> Meths: which bit is double spacing for you? [perhaps a screen shot with a circle where to look?]
[21:40] <Meths> Any expanded file, i.e. any bit of code.
[21:40] <Meths> Screenshot will just look like the other bug for code browsing except be on a different page.
[21:41] <lifeless> Meths: well, the css is accessible
[21:41] <lifeless> so I think we need a bug filed
[21:42] <Meths> Okay
[21:49] <flacoste> http://codeconf.com/
[21:50] <james_w> hey, when looking at a ppa +packages, if a source was built from a recipe wouldn't it link to said recipe?
[21:51] <james_w> ah, it does if you go to the binary build
[21:51] <poolie> hello leonardr
[21:51] <lifeless> james_w: if the source doesn't, perhaps file a bug?
[21:51] <poolie> leonardr, i'm curious if you think i'm smoking toenails in https://bugs.launchpad.net/bugs/711718
[21:51] <james_w> one step ahead of you
[21:54] <james_w> bug 712773
[21:56] <poolie> maxb, what were you going to propose?
[21:56] <james_w> and 712776 from filing that one
[22:00] <lifeless> thats a dup
[22:00] <lifeless> jml: should 712773 be in the 'must do' for the feature?
[22:00]  * james_w files a bug on the dupe finder
[22:01] <lifeless> james_w: that will be a dupe too
[22:01] <leonardr> poolie, checking
[22:01] <lifeless> james_w: the dupe finder works nearly like a regular search, all terms need to be present.
[22:01] <lifeless> james_w: won't be addressed till the major search overhaul
[22:02] <lifeless> james_w: when filing, only use the key elements, not an english description
[22:03] <leonardr> poolie: yeah, that's fine. you're seeing status quo bias. some things are published as scoped collections because they're that way in the model, and some things aren't because we didn't put them in the model
[22:06] <poolie> ok, and i'm correct in saying generally speaking, collections linked from the object are preferable?
[22:08] <barry> leonardr, maxb: are ppas still off-line or something?
[22:08] <leonardr> barry: no idea
[22:08] <barry> apt-get update fails after add-apt-repository
[22:09] <poolie> barry, how?
[22:09] <poolie> and hi
[22:09] <barry> poolie: hi
[22:10] <barry> Err http://ppa.launchpad.net natty/main Sources
[22:10] <barry>   404  Not Found
[22:10] <barry> Err http://ppa.launchpad.net natty/main amd64 Packages
[22:10] <barry>   404  Not Found
[22:10] <barry>  
[22:10] <poolie> barry, often this means that ppa has no builds for natty
[22:10] <poolie> i 'd check that first
[22:10]  * barry checks
[22:11] <barry> indeed, maxb's ppa doesn't have natty packages
[22:13] <poolie> arguably this is a bug in ...something
[22:13] <poolie> that it doesn't give you a more obvious message
[22:13] <poolie> i also find it a bit unobvious that apt-add-repository doesn't apt-get update
[22:14] <barry> agreed
[22:21] <barry> leonardr: results of running the code:
[22:21] <barry> >>> from launchpadlib.launchpad import Launchpad
[22:21] <barry> >>> Launchpad.get_token_and_login('foo', 'staging')
[22:21] <barry> The authorization page:
[22:21] <barry>  (https://staging.launchpad.net/+authorize-token?oauth_token=vWVgVFQhmTvltPmmsXmb&allow_permission=DESKTOP_INTEGRATION)
[22:21] <barry> should be opening in your browser. Use your browser to authorize
[22:21] <barry> this program to access Launchpad on your behalf.
[22:21] <barry>  
[22:21] <barry> Waiting to hear from Launchpad about your decision...
[22:21] <barry>  
[22:21] <leonardr> barry: you get a browser open?
[22:21] <barry> at that point though i killed it because i'm running on a command line interface
[22:21] <barry> leonardr: no, because i was ssh'd in.   let me try again in a graphical login
[22:22] <leonardr> barry: you could also have copied the url into some other browser
[22:22] <lifeless> barry: not even w3m ?
[22:22] <barry> lifeless: nope, just hangs
[22:23] <barry> leonardr: in a graphical login, firefox opens up to login.staging.launchpad.net
[22:23] <leonardr> barry: ok, authorize the token and see if it works
[22:23] <barry> says: Sign in to Launchpad's staging environment
[22:24] <leonardr> actually, i guess you should run 'print Launchpad.get_token_and_login(...).me.name'
[22:24] <leonardr> so that yo'll actually do something with the resultig launchpad object
[22:25] <barry> i land on a page that says "Not allowed here" but i am apparently logged into staging
[22:25] <barry> and the python prompt is still hanging
[22:26] <leonardr> barry: it's not hanging per se, it's periodically polling launchpad
[22:26] <leonardr> barry: give me the url?
[22:27] <barry> leonardr: it's a bit tricky as this is in a vm, but look at pastebin.ubuntu.com/562243
[22:29] <leonardr> barry: you get the error "didn't say what kind of desktop it is..."?
[22:30] <barry> leonardr: nope.  now, this is on natty with just my ppa, so hopefully it's testing what you want me to test
[22:31] <leonardr> barry: ok, i'm confused about the page that says "not allowed here"
[22:31] <leonardr> when you go to the url you pasted to me, where do you end up?
[22:32] <barry> that's the url for the "not allowed here" page
[22:32] <barry> which is where i end up after authenticating with the lp staging login service
[22:33] <leonardr> barry: i see an exception with a traceback. do you?
[22:33] <leonardr> and at the bottom of the traceback i see Consumer "foo" asked for desktop integration...
[22:34] <barry> i don't see an exception, tho i see some warnings from NSPlugin Viewer (from ff i'm guessing).  and then "Running global cleanup code from study base classes."  Also from FF?
[22:34] <barry> i can try C-c'ing python and doing it again
[22:34] <leonardr> barry: i'm talking about an exception *in the web browser*
[22:34] <leonardr> on the very page that also says "not allowed here"
[22:35] <leonardr> a *launchpad* exception
[22:35] <barry> leonardr: nope i don't see that
[22:35] <barry> leonardr: the page just says:
[22:35] <barry> Not allowed here (in bold)
[22:35] <barry> Sorry, you don't have permission to access this page.
[22:36] <barry> You are logged in as Barry Warsaw.
[22:36] <leonardr> not sure why you don't get a traceback, but i'm pretty sure we're seeing the same page
[22:36] <barry> leonardr: should i ctrl-C and try again?
[22:36] <wgrant> leonardr: Only ~launchpad sees tracebacks.
[22:37] <barry> and i think flacoste booted me from that a few weeks ago :)
[22:37] <leonardr> that would explain it
[22:37] <wgrant> Yup.
[22:38] <leonardr> ok, we have a regression in at least one deprecated method
[22:38] <leonardr> barry, how long do we have to fix this problem?
[22:39] <barry> leonardr: natty alpha 2 just came out, and feature freeze is something like feb 24, so you have some time
[22:39] <leonardr> ok. i will file a bug about this and work on it on monday
[22:40] <barry> sounds good.  ping me for another test
[22:40] <leonardr> flacoste, since i have to do another release anyway, i would also like to remove the keyring code. i feel bad about this because it was a lot of work, but nobody wants it, and everyone who is paranoid enough to benefit from it has an encrypted home directory
[22:40] <poolie> flacoste, why do you want to remove it?
[22:41] <flacoste> poolie: i don't, leonardr wants
[22:41] <poolie> s///
[22:41] <leonardr> poolie:
[22:42] <leonardr> poolie: i don't think its benefits outweigh the additional complexity
[22:43] <poolie> istm gui clients will almost certainly want to use this,
[22:43] <poolie> and it's better to have it in the base library than to have N slightly different implementations of it
[22:43] <poolie> as is tending to happen at the moment with similar features
[22:44] <leonardr> gui clients will want to use login_with()
[22:44] <poolie> but, perhaps we should be more precise about which feature we're discussing
[22:44] <leonardr> poolie: good idea
[22:45] <poolie> i think lplib ought to have a way for a client to say "log me in, getting/putting the credentials in the keyring"
[22:45] <leonardr> currently the desktop-wide credential is stored in the keyring/kde wallet
[22:45] <leonardr> i propose storing the desktop-wide credential in a file on disk, instead
[22:46] <poolie> what's the api to get the desktop-wide credential now?
[22:46] <leonardr> i think lplib ought to allow a client to say "log me in, reusing credentials if possible, getting new ones if necessary"
[22:46] <poolie> btw can i suggest you post about this to the list and the stakeholders before doing anything drastic?
[22:46] <leonardr> sure
[22:46] <leonardr> there is no api to "get the desktop-wide credential"
[22:46] <leonardr> there is an api to "log in"
[22:47] <leonardr> the caller should not have to know *anything* about credentials, desktop-wide or otherwise
[22:48] <leonardr> i don't consider this a change that affects the third-party developer or the typical end-user at all
[22:49] <poolie> well, it does affect people
[22:49] <poolie> s//developers and users
[22:50] <poolie> because it changes the behaviour of the app, and that's likely to generate user support requests and change the way they need to be answered
[22:50] <leonardr> ok, let's talk about that
[22:50] <poolie> so, i think telling people when you change behaviour is a pretty good idea
[22:51] <leonardr> in my experience "file on disk" is a lot more reliable than the gnome keyring
[22:51] <leonardr> eg. i had to find a workaround to make the keyring work over x forwarding
[22:51] <poolie> mm
[22:51] <poolie> that's probably true
[22:51] <poolie> that it's more reliable, i mean
[22:51] <leonardr> we went with the keyring because it was a desktop standard
[22:52] <leonardr> and that's the leading argument for it imo
[22:52] <leonardr> but on an absolute scale, it's not that great
[22:52] <poolie> i do also agree with you that generally we should be assuming that people have encrypted home directories
[22:52] <poolie> if they care at all
[22:54] <leonardr> barry: btw, judging from my experience today, i'm +1 on putting the python-keyring update into natty
[22:54] <poolie> leonardr, i wonder if it would be good to have a wiki page or something stating what the recommended approach is and what the options are
[22:54] <poolie> for app authors or users
[22:54] <poolie> like just saying:
[22:55] <poolie> - for desktop apps, we will normally give just one token per user and computer
[22:55] <poolie> and this will be stored mode 0600 but unencrypted in blah blah
[22:55] <poolie> - and if you want a per-app token, do X
[22:55] <barry> leonardr: okay. i'll work with debian to get the update there and then request a sync to natty.  in the meantime it's in my ppa
[22:55] <poolie> - and if you want to use the keyring, do Y
[22:56] <poolie> maybe this already exists, for all i know
[22:56] <poolie> what do you think?
[22:57] <leonardr> poolie: what you describe is close to an existing document
[22:57] <leonardr> https://help.launchpad.net/API/ThirdPartyIntegration
[22:58] <leonardr> but, i think it's a mistake to think thoughts like "if you want to use the keyring"
[22:58] <leonardr> there are three use cases:
[22:58] <leonardr> 1. desktop use case
[22:58] <leonardr> 2. headless server use case
[22:58] <leonardr> 3. website integration use case
[22:59] <poolie> you're right, thinking in terms of cases like that is better
[22:59] <leonardr> for #1, we have decided to use the keyring. we may decide to switch to an unencrypted file. either way, the developer goes with what we chose without seeing a difference
[22:59] <leonardr> the api is the same
[22:59] <poolie> i suppose i wonder whether users are really happy having just one token per home directory
[22:59] <poolie> so, i should ask, why would they not be?
[22:59] <leonardr> yeah, they're certainly not happy with more than one token
[23:00] <poolie> as we discussed previously, there is not a great deal of process isolation such that they would want to be running untrusted apps
[23:00] <poolie> but...
[23:00] <leonardr> but there is no way to partition the tokens. it's simply not possible
[23:00] <poolie> 1- perhaps they're *accustomed* to seeing apps ask before doing stuff to launchpad and it will be weird, until they reacclimatize, to see it just work
[23:01] <poolie> 2- i guess the initial token needs to get full access?
[23:01] <poolie> so you can partition the tokens by having several named by app, but it you can't _securely_ partition them
[23:01] <leonardr> yeah
[23:01] <poolie> gnome-keyring probably comes closest to that
[23:01] <leonardr> it's security theater
[23:01] <poolie> hey, it works for uncle sam, it can work for you too :)
[23:03] <leonardr> thumper: i need to work on https://bugs.launchpad.net/launchpadlib/+bug/712808, that's my project for monday
[23:03] <poolie> leonardr, does the server still get the app name for logging/statistical purposes?
[23:03] <leonardr> poolie: yes, the app name is still sent in the User-Agent string
[23:03] <poolie> and that's still passed to the login function?
[23:03] <leonardr> yes
[23:03] <poolie> so we could, potentially, split up the tokens further down the road
[23:04] <leonardr> yeah, but that looks like it will require magic computers
[23:04] <poolie> if someone thinks it's worthwhile
[23:04] <poolie> :)
[23:04] <poolie> cool
[23:04] <wgrant> Magic computers?
[23:04] <poolie> what about apps that want to do security-sensitive stuff with short-lived tokens?
[23:04] <poolie> they'll still open a web browser to confirm it?
[23:05] <poolie> wgrant, magic computers that protect you against hostile code running in your own uid
[23:05] <poolie> hostile local apps
[23:05] <wgrant> poolie: Just needs non-sucky OSes.
[23:05] <poolie> yep
[23:05] <poolie> it's not impossible
[23:06] <leonardr> poolie: we have a plan for short-lived/single-use tokens that have powers above and beyond what a normal token can do
[23:06] <leonardr> for quickly
[23:07] <leonardr> these tokens will probably not be cached at all, and you'll get them using some method other than login_with. i don't remember the details, if there even are any details
[23:07] <poolie> ok
[23:07] <poolie> so what's the story for (2), servers?
[23:08] <leonardr> the credentials_file argument
[23:08] <leonardr> you pass in a path and it uses that instead of the keyring (or, instead of the standard path, should we get rid of keyring)
[23:10] <poolie> so the application controls the location, and you get a per-application token
[23:10] <poolie> cool, thanks for taking the time to explain it
[23:10] <leonardr> sure
[23:10] <poolie> that sounds good to me
[23:10] <poolie> perhaps we can leave the keyring glue in but turn it off by default if it causes trouble?
[23:11] <leonardr> poolie: i suggested that and barry said it wold cause bitrot
[23:11] <leonardr> which is true enough
[23:11] <poolie> it may
[23:12] <leonardr> and we don't really have any way for an end-user to signal that they would rather their credential be stored in the keyring
[23:12] <leonardr> i was really frustrated with the keyring earlier which is why i had this thought, but i think we've resolved the major problems
[23:13] <leonardr> and as keyring improves we'll reap the benefits rather than going off and doing our own thing
[23:13] <leonardr> so, i think i'm ok with leaving it... but ask me again on monday
[23:13] <poolie> :)
[23:13] <poolie> i do think a brief note just about where you're heading would be good
[23:14] <poolie> it's a good plan
[23:14] <leonardr> ok, another thing for monday