[00:11] <BUGabundo> kklimonda: reboot?
[00:11] <kklimonda> nah, just lost connection..
[10:14] <markgsaye> jcastro: I'd like add my name as help contact into the channel topic, but do not have op rights - can you help?
[10:19] <markgsaye> jussi01: can you help? ^^
[11:18] <jussi01> markgsaye: who are you?
[11:18] <markgsaye> Hi jussi01: I am a Senior Software Developer for Canonical
[11:19] <jussi01> markgsaye: can you somehow give me some sort of verification for that?
[11:19] <rodrigo_> jussi01: I can certify he is what he says, if that serves :)
[11:20] <markgsaye> jussi01: my LP profile is at https://launchpad.net/~markgsaye - does that help?
[11:20] <jussi01> markgsaye: 1 moment please
[11:28] <SteveA> sladen: hi
[11:28] <SteveA> sladen: we were just talking about oauth
[11:28] <SteveA> sladen: and I pointed you at http://oauth.net
[11:28] <SteveA> sladen: aquarius here is very familiar with how the ubuntu one systems use oauth, and how the dbus service works
[11:28] <aquarius> hey
[11:28] <sladen> SteveA: okay
[11:28] <aquarius> hey sladen
[11:29] <SteveA> and I happen to know he's got 15 mins spare to give a quick overview ;-)
[11:29] <sladen> aquarius: is that Aq under a more verbose name?
[11:29] <sladen> SteveA: fantastic, ta
[11:29] <aquarius> sladen: it is indeed :)
[11:30] <sladen> aquarius: can you sum up in two-three lines what actually happens.  Something is running, that exposes com.ubuntuone.Authenication, which is it?
[11:31] <aquarius> sladen: /usr/bin/ubuntuone-client-applet  exposes the com.ubuntuone.Authentication D-Bus interface
[11:31] <sladen> can (bearing in mind that I have not accepted the T&C, so can't run this), what component(s) pops up the password box
[11:32] <sladen> aquarius: so, that means that the gnome-applet is _required_.  It's not possible to use just syncdaemon and it's u1sdsdsdtool
[11:33] <aquarius> ubuntuone-client-applet pops up the password box. that component handles the OAuth exchange for you, fetching an access token (which you authorise in the web browser). ubuntuone-client-applet then stores that access token in the gnome-keyring, and that storage action is what requires the password.
[11:34] <aquarius> sladen: If you want to, you can fetch an authorised access token and store it in the gnome-keyring yourself; if that happens, then the d-bus interface is never called
[11:34] <aquarius> (because the syncdaemon looks for an access token and successfully finds it)
[11:35] <sladen> aquarius: okay, I'd like to document the manual method, as that is likely to (very accurate) show  the procedure
[11:35] <aquarius> sladen: but I confess I've not actually *tried* that; I'm just reasoning from how it should work.
[11:36] <sladen> aquarius: but the basic premise is that the remote authenication (to get the token) is all done via the browser and a standard login to launchpad?
[11:36] <aquarius> sladen: yes
[11:38] <aquarius> sladen: that's the stock OAuth procedure; the way OAuth works is 1. program makes a request to get a request-token; 2. program pops up the user's browser to authenticate that request-token; 3. tell the program you've done it; 4. program uses the (now authenticated) request-token to get an access-token; 5. program stores the access-token and can from then on use it to access resources without having to ask the user
[11:38] <aquarius> sladen: (possibly you already know this!)
[11:39] <sladen> aquarius: no, oauth is so recent that I haven't had to use it in anger for any projects yet
[11:40] <jamesh> aquarius: the bits that the OAuth spec doesn't define is the actual URLs and supported signing methods.  I suppose we should publish them somewhere.
[11:40] <sladen> aquarius: how does -applet get the actual return code (token) from the browser?
[11:41] <jamesh> sladen: it makes a call to the OAuth "access token URL"
[11:41] <jamesh> passing in the request token
[11:42] <aquarius> sladen: it doesn't. The browser just authorises the request token. The applet then calls the access-token url and says "you authorised this request-token; give me a corresponding access-token, please"
[11:42] <aquarius> jamesh: they should be published, indeed; it looks like the docs that sladen's putting together may do that quite nicely though :-)
[11:43] <jamesh> sladen: think of the request token as a "session identifier" for the authentication process.  While it has a similar name to the access token, it has quite a different purpose
[11:43] <sladen> so there's a new session token (access token) each time the user logs in
[11:43] <sladen> it's not setup once when the Share is shared and kept
[11:44] <sladen> so the username and password get saved only in the Firefox keyring (normal launchpad login)
[11:44] <jamesh> sladen: the access token is stored in the keyring long term
[11:44] <sladen> and the token, that get stashed in the gnome-keyring is saved long-term, but is only useable for this session
[11:44] <jamesh> (at least for our client)
[11:45] <sladen> or should that this s/this session/this share/
[11:45] <jamesh> sladen: the request token is a session identifier for the user authentication/authorisation process
[11:45] <jamesh> the access token that results from that process can be used long term
[11:46] <aquarius> sladen: the access token that gets stashed in the keyring -- think of it like a login cookie for a website, so you don't have to log in every time you go back there.
[11:46] <sladen> who exchanges the session identifier for the long-term access token?  Is that syncdaemon, or -applet/
[11:47] <jamesh> sladen: the applet -- it stuffs the access token in the keyring and then notifies anyone interested that it is available
[11:47] <sladen> so the -applet is effectively doing write-through cacheing.  The first time (it's empty) it fires up the browser and saves the result, and returns it
[11:48] <sladen> and thereafter, -applet returns it straight away (to syncdaemon)
[11:49] <sladen> syncdaemon then includes this identifier as part as every single u1storage-based connection setup to the ubuntuonestoragefsapiserver
[11:51] <aquarius> I'm not sure whether syncdaemon calls the d-bus api to get the token. or whether syncdaemon actually looks in the keyring itself. jamesh?
[11:53] <jamesh> sladen: syncdaemon checks the keyring for the access token first.  If no token is found, it asks the applet to acquire a token via DBus
[11:53] <jamesh> sladen: there is a fairly loose coupling between the two components
[11:54] <jamesh> that's how I remember it working ...
[12:08] <facundobatista> Hi all
[12:11] <CardinalFang> hiya, facundo.
[12:18] <jdobrien> hi facundo
[12:20] <facundobatista> Hi CardinalFang, jdobrien
[16:39] <jblount> Hiya people! Anyone have access to a Windows Xp vm or similar that can test logging in with Opera 9.64 for me?
[16:44] <facundobatista> jblount, I am
[16:44] <facundobatista> jblount, I need to install Opera, though
[16:47] <jblount> facundobatista: Thanks! If you could install the current build (not the 10.x beta recently announced) and try to log in, I just need to confirm if someone can get through our LP SSO :)
[16:47] <facundobatista> god, how many steps to install something in Windows!
[16:47] <jblount> heh, 1241251
[16:58] <facundobatista> jblount, it just work
[16:59] <facundobatista> jblount, I tried it not being logged in Launchpad, *and* already being logged in
[17:39] <facundobatista> jblount, I also commmented the bug about what you asked
[17:56] <toros> hi
[18:02] <jblount> facundobatista: gracias
[18:03] <facundobatista> jblount, de nada, :)
[19:46] <days_of_ruin_> I dragged a tarball into my Ubunto One/My Files directory
[19:46] <days_of_ruin_> but it doesn't upload it.
[19:49] <days_of_ruin_> icon is rotating
[19:50] <days_of_ruin_> but system monitor is showing that its not uploading.
[19:53] <facundobatista> days_of_ruin_, what the log says?
[19:54] <days_of_ruin_> where is the log?
[19:54] <facundobatista> days_of_ruin_, ~/.cache/ubuntuone/syncdaemon.log
[19:55] <days_of_ruin_> 2009-06-09 13:50:37,395 - ubuntuone.SyncDaemon - WARNING - Another instance     is running
[19:55] <days_of_ruin_> thats there because I tried to start another.
[19:59] <facundobatista> days_of_ruin_, try to remove all instances from memory and try again
[20:11] <days_of_ruin_> still not working
[20:16] <toros> I have problems with the Ubuntu One client to
[20:17] <toros> and a guy on IRC had the same problem this afternoon too
[20:18] <facundobatista> days_of_ruin_, log?
[20:19] <Chipaca> days_of_ruin_: something is wrong with the service right now
[20:19] <days_of_ruin_> its not just me?
[20:19] <days_of_ruin_> its happening to everyone?
[20:20] <Chipaca> days_of_ruin_: correct
[20:20] <Chipaca> days_of_ruin_: or it might be; still diagnosing the problem
[20:20] <toros> ohh, an upgrade for the ubuntu one client
[20:40] <Chipaca> days_of_ruin_: any change?
[20:41] <days_of_ruin_> I removed my computer from my ubuntu one account...
[20:41] <days_of_ruin_> to see if that would help. How do I get it back?
[20:42] <days_of_ruin_> The page isn't poppin up in my browser:|
[20:42] <facundobatista> days_of_ruin_, through the web page, I guess
[20:43] <dobey> days_of_ruin_: you'll need to delete the token from your local computer in Accessories->Passwords and Encryption Keys, under the Passwords tab
[20:44] <jblount> days_of_ruin_: ^^ and quit / reopen the applet. When it sees the token gone, it will help you setup a new one :)
[21:04] <days_of_ruin_> When I try to reopen it it never shows up.
[21:05] <facundobatista> days_of_ruin_, reopen what?
[21:06] <days_of_ruin_> when I click on Applications>Internet>Ubuntu One
[21:06] <days_of_ruin_> or run it from a terminal
[21:06] <days_of_ruin_> nothing happens
[21:07] <facundobatista> days_of_ruin_, did you follow the dobey and jblount instructions to get there?
[21:10] <toros> re
[21:10] <toros> it seems ubuntu one is working again \o/
[21:10] <toros> do we know what was the problem?
[21:12] <facundobatista> toros, a frozen database connection that never timed out
[21:12] <facundobatista> toros, we're trying to see why that happened, but now it should work ok
[21:12] <toros> thanks for the info
[21:13] <toros> did somebody test the unshare feature? does it work?
[21:17] <toros> I rejected a directory shared with me - now I don't see it in the web interface, but according to u1sdtool it's still shared
[21:26] <days_of_ruin_> yes I followed the instructions. But it worked just now :)
[21:30] <days_of_ruin_> everything is working now
[21:32] <facundobatista> days_of_ruin_, great!
[21:32] <days_of_ruin_> thanks for the help.
[22:41] <days_of_ruin_> hrm. it seems to be happening again.
[22:43] <Chipaca> days_of_ruin_: let me see...
[22:43] <Chipaca> days_of_ruin_: nope, it's working here
[22:47] <days_of_ruin_> I disconnected and reconnected and now its just "idle" and doesn't notice any new files.
[22:47] <medeshago> how can I change the ubuntuone folder?
[22:53] <Chipaca> days_of_ruin_: hmmm
[22:53] <Chipaca> days_of_ruin_: and there are new files?
[22:53] <Chipaca> medeshago: not yet, sorry
[22:53] <medeshago> Chipaca: thanks
[22:56] <Chipaca> days_of_ruin_: if you open a terminal and do "killall ubuntuone-syncdaemon; ubuntuone-syncdaemon --debug" you should get to "see" it working
[22:58] <days_of_ruin_> Chipaca: I ran that, what am i supposed to see.
[22:58] <Chipaca> days_of_ruin_: copious output :)
[22:59] <Chipaca> days_of_ruin_: you should see it "noticing" new files, for one
[23:01] <days_of_ruin_> I right-clicked the icon now and connected it. Now its working again.
[23:02] <Chipaca> ah :)
[23:57] <Ng> woo, working client in karmic \o/
[23:58] <Ng> the spinny applet thing is spinning reeeeally fast :o