[01:54] <Hendrik1> Hi
[01:54] <Hendrik1> Where would be the right place to post a feature request/suggestion
[02:11] <jderose> Chipaca: where should Hendrik1 file a feature request? ^^^
[03:12] <beuno> Hendrik1, filing a bug is fine
[03:13] <Hendrik1> ? really? most times people do that they get told this is not a bug its an idea ...
[03:13] <beuno> Hendrik1, it would be a wishlist bug
[03:13] <beuno> otherwise
[03:13] <beuno> you can post to the mailing list
[03:14] <Hendrik1> ok i'll file a bug
[03:14] <Hendrik1> maybe some one here has some thoughts on it
[03:14] <Hendrik1> I think the mobile streaming service should be extended for example it would be nice to have it as an app for the boxee box
[03:16] <beuno> Hendrik1, absolutely
[03:17] <beuno> we are totally looking into extending it to more devices
[03:20] <Hendrik1> so should i file this in ubuntuone or some subproject for streaming
[03:20] <beuno> Hendrik1, ubuntuone-servers is fine
[03:22] <Hendrik1> ok
[03:29] <Hendrik1> filed bug #686314
[03:29] <ubot4> Launchpad bug 686314 in ubuntuone-servers "Ubuntu One Music Streaming should support more Devices e.g. Boxee Box (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/686314
[09:33] <duanedesign> morning all
[13:16] <rye> api servers are going down for update
[13:16] <rye> and hello everybody
[13:16] <CardinalFang> hi hi
[13:17] <rye> CardinalFang: have you ever had any experience poking couchdb-glib?
[13:17] <CardinalFang> rye, no, none.  What does it do?
[13:19] <rye> CardinalFang: provides glib wrapper for desktopcouch/couchdb interaction... And the test is crashing, and couchdb is unhappy with what couchdb-glib sends from evolution...
[13:21] <rye> hm, bazaar.launchpad.net is not cooperating
[13:26]  * beuno waves at karni 
[13:34] <duanedesign> hello rye
[13:51] <CardinalFang> karni, hi.  How stable is the ubuntuone-android-files source?  I will want to start adding features in a few days, I think.
[13:51] <CardinalFang> I want a starting place that isn't likely to move a lot.
[13:54] <nessita> stand up in 5!
[13:55]  * dobey prefers to sit
[14:00] <nessita> me
[14:01] <nessita> alecu, dobey, thisfred, ralsina, Chipaca, mandel, stand up?
[14:01] <thisfred> me
[14:01] <Chipaca> me
[14:01] <mandel> me
[14:02] <nessita> alecu, dobey, ralsina?
[14:02] <alecu> sorry, was chatting with the new boss.
[14:02] <alecu> me
[14:03] <dobey> me
[14:03]  * Chipaca jiggles ralsina's power cord
[14:03] <ralsina> aca estoy
[14:03] <ralsina> me
[14:03] <dobey> Chipaca: are you going to dfw for the rally?
[14:03] <nessita> let's go!
[14:03] <nessita> DONE: Boss chasing re the control panel spec. Code reviews for mandel. More for bug #673670. Had power outage so I went to a bar without my ongoing work, so I updated my laptop to natty (really smooth so far), and fixed bug #673054.
[14:03] <nessita> TODO: Finish bug #673670.
[14:03] <nessita> BLOCKED: nopes
[14:03] <nessita> NEXT: thisfred
[14:03] <thisfred> DONE: found a way to test XUL extensions (thanks JamesTait!) added first test to bindwood. TODO: create tests for bindwood | start refactoring it BLOCKED: not blocked
[14:03] <ubot4> Launchpad bug 673670 in ubuntuone-control-panel "Contact syncdaemon dbus service from backend (affects: 1) (dups: 1) (heat: 12)" [High,In progress] https://launchpad.net/bugs/673670
[14:03] <ubot4> Launchpad bug 673054 in ubuntu-sso-client "Update wiki page with Dbus service documentation (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/673054
[14:03] <thisfred> Chipaca: you!
[14:04] <Chipaca> I just wanted to say I'm handing off my standoff duties to ralsina, as he is now manager of the team :)
[14:04] <Chipaca> so I'll no longer need to say "not me"! :-D
[14:04] <nessita> ue!
[14:04] <Chipaca> mandel: go
[14:04] <mandel> DONE: Arrive to spain. Looked at bug 682744. The issues is that the use od the port in not admin users is blocked.
[14:04] <mandel> TODO: Find how to load com visible object form python
[14:04] <mandel> BLCOKED: no, but doing things for the first time
[14:04] <ubot4> Launchpad bug 682744 in ubuntuone-windows-installer "Files not syncing (affects: 7) (dups: 1) (heat: 36)" [High,Confirmed] https://launchpad.net/bugs/682744
[14:04] <mandel> alecuo go!
[14:04] <mandel> alecu hehe
[14:05] <alecu> DONE: found a mistake in handling Offered Shares events, worked on it (still bug #674252)
[14:05] <alecu> TODO: more zg
[14:05] <alecu> BLOCKED: no
[14:05] <ubot4> Launchpad bug 674252 in ubuntuone-client (Ubuntu) (and 1 other project) "Syncdaemon needs to store events into zeitgeist (affects: 1) (heat: 173)" [High,In progress] https://launchpad.net/bugs/674252
[14:05] <nessita> NEXT: dobey
[14:05] <dobey> λ DONE: rally flight booking, lots of arguing about project splits and autotools, filed #686224, 686036
[14:05] <dobey> λ TODO: workaround 686224, finish 686036, fix 674876, 683351, backports
[14:05] <dobey> λ BLCK: None.
[14:06] <dobey> ralsina: go
[14:06]  * alecu throws an usb keyboard ralsina's way
[14:06] <Chipaca> dobey: I'm not going to dfw, no
[14:06] <ralsina> DONE: administrivia (I hope)
[14:06] <Chipaca> dobey: neither is ralsina unless he can express his visa
[14:06] <ralsina> TODO: interviews with all if you (stand in line, please)
[14:06] <ralsina> BLOCKED: not yet
[14:06] <dobey> ]ah ok
[14:06] <nessita> any closing comments?
[14:07] <dobey> it's too damn cold.
[14:07] <ralsina> dobey: lucky you
[14:07] <nessita> any closing comments regarding the stand up? :-)
[14:07] <mandel> how has/is going to the desktop thing?
[14:07] <ralsina> I will try to express the visa, but it's very unlikely that I will attend
[14:08] <nessita> mandel: not sure what you've asked
[14:08] <nessita> can you please rephrase?
[14:08] <thisfred> nessita: I think he means "who is going to the platform sprint"
[14:08] <mandel> nessita, that one :P
[14:08] <mandel> platform - desktop, kind of the same for me :P
[14:09] <nessita> mandel: I'm going, dobey, and not sure who else
[14:09] <nessita> Chipaca: who else is going? :-)
[14:09] <thisfred> Not me, I was deemed too much of a distraction ;)
[14:10] <nessita> ok, I think this is eom!
[14:10] <mandel> thisfred, hehe then that makes me sure I do not go :)
[14:11] <alecu> mandel, how was your trip back home? when did you arrive?
[14:11] <mandel> alecu, I arrived yesterday at 11:00 pm, so about 3 days to go home...
[14:11] <thisfred> mandel: I can't believe you're even considering travelling again ;)
[14:12] <mandel> alecu, it was a pain in the ass, but well, I do not mind it, I've done worse (Mac'n-Madrid by train)
[14:12] <mandel> thisfred, I would, just to see if I get anywhere hehe
[14:12] <Chipaca> nessita: ralsina, you and dobey. Fingers crossed on the ralsina front.
[14:13] <alecu> mandel, what's Mac'n ?
[14:14] <dobey> hmm
[14:14] <alecu> is that a Klingon city?
[14:14] <mandel> alecu, Manchester :P
[14:14] <dobey> Mac'n'Cheese
[14:14] <alecu> oh, and it took more than 3 days?
[14:15] <alecu> dobey, I know about the food! I've never travelled from a food to a city tho.
[14:15] <dobey> alecu: you just need to put more psychotropics in the recipe
[14:15] <alecu> jajajaj
[14:16] <mandel> alecu, yes, by train, on xmas day and sleeping in a brothel in paris :P
[14:16] <alecu> mandel, you can spare the details on *that*
[14:16] <mandel> in my defense, I though it was a hotel until I turned on the tv and it was all porn
[14:16] <mandel> alecu, no putas involved, I promise
[14:18] <mandel> nessita, so, 'm save to assume that I'm not goint to the platform sprint, right :)
[14:18]  * mandel books holidays...
[14:19] <nessita> mandel: I think so :-)
[14:19] <nessita> mandel: I reviewed the keyring branch yesterday
[14:19] <nessita> mandel: do you have more branches for me to review?
[14:20] <dobey> i just hope mandel never meets anyone who lives in Punta Gorda
[14:20] <mandel> nessita, yes, but I'm first dealing with some crazy code on windows
[14:20] <nessita> mandel:  no problem!
[14:20] <mandel> dobey, Punta Gorda or Puta Gorda?
[14:20] <nessita> mandel: this is a public channel ;-)
[14:20] <dobey> Punta
[14:21] <mandel> nessita, sorry I missed typed ;)
[14:21] <mandel> dobey, why?
[14:22] <dobey> mandel: the jokes, mostly
[14:22] <mandel> dobey, hehe true :)
[14:22] <mandel> nessita, regarding the keyring, I really do not know why that occurs, I might need to ask alecu about that
[14:22] <mandel> alecu, can you tell me why this happens: https://code.launchpad.net/~mandel/ubuntu-sso-client/windows_keyring/+merge/42709
[14:23] <mandel> alecu, nessitas comment
[14:23] <nessita> mandel: you can ask me :-)
[14:24] <alecu> mandel, looking
[14:24] <nessita> alecu: I can help, no worries (if you're busy)
[14:24] <alecu> nessita, great, thanks.
[14:25] <nessita> mandel: the problem is the monkey patching, let me find out the solution
[14:25] <mandel> nessita, I though so, but I really do not know where that is happening
[14:25] <dobey> in setUp
[14:26] <alecu> mandel, what are you using win32crypt for?
[14:27] <mandel> alecu, to crypt the data in the keyring
[14:27] <mandel> alecu, if not, the data will be stored plain in the registry
[14:27] <mandel> alecu, which is not good
[14:27] <alecu> mandel, cool. And what password are you using to encrypt?
[14:28] <mandel> alecu, the crypto lib takes the users password, if the password changes the lib remembers and next time uses the new one
[14:31] <nessita> mandel:  modify test_linux.py, line 121, and change
[14:31] <nessita> self.service = self.patch(keyring, "SecretService",
[14:31] <nessita> for
[14:31] <nessita> self.service = self.patch(keyring.linux, "SecretService",
[14:31] <mandel> nessita, uh, cool, thx! :)
[14:32] <alecu> mandel, so, the token is encrypted with the user's password and stored in the registry. sounds nice.
[14:32] <nessita> mandel: there are more errors when fixing that
[14:32] <alecu> mandel, but what if the user changes the login password?
[14:32] <nessita> mandel: but I'll think you can resolve those e3asily
[14:32] <nessita> easily (mostly import errors)
[14:32] <alecu> mandel, would a prompt need to be shown when unencrypting the token?
[14:32] <mandel> alecu, win32 keeps track of that, and will ensure it can decrypt it
[14:32] <alecu> mandel, and would that block?
[14:32] <alecu> mandel, nice win32.
[14:33] <mandel> alecu, no ui is shown, so there is not block for a user input
[14:33] <mandel> nessita, thx, I'll take a look at those, there is also another branch that adds a script to run the tests on windows, you might want to take a look at that one too
[14:33] <nessita> mandel: link please?
[14:34]  * mandel looks
[14:34] <mandel> nessita, https://code.launchpad.net/~mandel/ubuntu-sso-client/windows_run_tests/+merge/42716
[14:35] <nessita> mandel: reviewing it...
[14:35] <mandel> nessita, I changed the runner to allow to pass modules to ignore, that way we can run tests on windows ignoring those that depend on dbus etc.. all the tests I write for windows, will run on linux
[14:36] <dobey> changed what runner?
[14:36] <dobey> sigh
[14:38] <dobey> i thought sso was already using u1trial?
[14:40] <nessita> dobey: it is not, we should file a bug a make the transition
[14:41] <nessita> dobey: do you think mandel's changes can be added to devtools?
[14:41] <dobey> probably
[14:41] <dobey> i don't see why they couldn't be
[14:45] <facundobatista> alecu, pign
[14:45] <facundobatista> *ping
[14:45] <alecu> facundobatista, gnip!
[14:45] <facundobatista> alecu, :)
[14:46] <facundobatista> alecu, che, regarding your work with Z, are you planning to know when a share invitation was sent'
[14:46] <facundobatista> ?
[14:46] <alecu> facundobatista, yes. I added an eq event for that.
[14:46] <alecu> facundobatista, let me find a link...
[14:47] <facundobatista> alecu, is that in trunk?
[14:47] <alecu> facundobatista, not yet
[14:47] <facundobatista> alecu, awesome
[14:47] <facundobatista> nessita, ^
[14:48] <nessita> facundobatista: yiipiiii
[14:48] <alecu> facundobatista, it will be called "AQ_SHARE_INVITATION_SENT"
[14:49] <alecu> facundobatista, and it's both sent after an invitation is sent with http or a share sent thru the server
[14:49] <facundobatista> alecu, and on error?
[14:49] <facundobatista> alecu, what do you mean with "share sent thru server"?
[14:49] <alecu> facundobatista, it's not sent.
[14:50] <alecu> facundobatista, the invitation is sent with http if the username matches an email address
[14:50] <facundobatista> yes
[14:50] <alecu> facundobatista, no share is created in that case till the user accepts the invitation.
[14:50] <facundobatista> exacto
[14:50] <alecu> facundobatista, on the other hand...
[14:50] <alecu> when the username is a u1 username, a share is created and sent thru the api server.
[14:51] <alecu> sooooo
[14:51] <alecu> that event is sent in both cases.
[14:51] <facundobatista> alecu, well
[14:51] <facundobatista> alecu, a share is created in that case
[14:51] <facundobatista> nothing is "sent"
[14:51] <facundobatista> do you have a diff for the ActionQueueCommand?
[14:52] <alecu> facundobatista, yes. But from the point of view of the local user, it's the same.
[14:52] <alecu> facundobatista, the local user does not care about shares being created.
[14:53] <rigved> hello everyone
[14:53] <facundobatista> alecu, well, that's arguable, but I care more about AQ being nice regarding what it sends
[14:53] <facundobatista> Hola rigved
[14:53] <alecu> facundobatista, for what value of nice?
[14:53] <rigved> my tomboy notes don't syncronise with the ubuntuone servers anymore. is there a fix to this? using ubuntu 10.04
[14:53] <facundobatista> alecu, and I also need an event there for magicicada
[14:53] <rigved> facundobatista: hi
[14:54] <facundobatista> alecu, so, do you have a diff with your proposal?
[14:54] <dobey> nessita, mandel: actually, with u1trial, the changes are smaller, since i abstracted the dbus runner out; so it can already be avoided on windows anyway
[14:54] <alecu> https://code.launchpad.net/~alecu/ubuntuone-client/ziggy-for-syncdaemon
[14:54] <mandel> dobey, sweet, that is great!
[14:54] <mandel> dobey, is a matter of ignoring th module load then
[14:55] <nessita> mandel: can you propose a branch for devtools instead and I'll make use that ussoc uses devtools?
[14:55] <dobey> yeah, u1trial would only need the --ignore bits added
[14:55] <mandel> nessita, dobey I can add that to u1trial then, makes more sense
[14:56] <nessita> mandel, dobey: awesome, I'll propose a branch so ussoc uses devtools
[14:56] <facundobatista> alecu, so, on success, if you created the share, you send *both* events AQ_CREATE_SHARE_OK and AQ_SHARE_INVITATION_SENT ?
[14:56] <facundobatista> alecu, no ActionQueueCommand sends two events on success, can we revisit this decission?
[14:56] <mandel> nessita, we will need to add the batch script, but that is nearly a copy paste of the one proposed
[14:56] <alecu> facundobatista, we sure can.
[14:57] <facundobatista> alecu, I'd naturally think about two new events:
[14:57] <facundobatista> - AQ_SHARE_INVITATION_SENT (only) when an invitation is sent successfully
[14:57] <rigved> my tomboy notes don't syncronise with the ubuntuone servers anymore. is there a fix to this? using ubuntu 10.04. any help would be welcome.
[14:58] <facundobatista> - AQ_SHARE_INVITATION_SENT_ERROR when an invitation is not sent because an error
[14:58] <facundobatista> (we could make AQ_SHARE_INVITATION_SENT_OK the first one, to be more coherent)
[14:59] <alecu> facundobatista, it makes sense
[14:59] <nessita> rye: how can we debug a tomboy sync failure? (see rigved question)
[14:59] <facundobatista> alecu, also, if you're sending an event when the command finished ok and self.use_http == True, you can remove the warning log
[14:59] <alecu> facundobatista, I'll send AQ_SHARE_INVITATION_SENT_OK for now, since the other event will not be used yet.
[14:59] <facundobatista> alecu, but it will be unbalanced
[15:00] <alecu> facundobatista, then we'll need to wait for Anakin to arrive.
[15:00] <facundobatista> AQ_CREATE_SHARE_OK / AQ_SHARE_INVITATION_SENT_OK on success, AQ_CREATE_SHARE_ERROR on error
[15:01] <alecu> facundobatista, I don't like to add code that will be unused. We can always add it when it's needed.
[15:01] <alecu> facundobatista, but I really think it's nice to only send one event on successes.
[15:03] <facundobatista> alecu, this impacts directly in the dbus_interface, are you fixing that?
[15:03] <rodrigo_> rye, what problem are you having with couchdb-glib?
[15:04] <nessita> dobey: can you please file a bug for me to add devtools to ussoc?
[15:04] <alecu> facundobatista, how? the dbus interface only reports on AQ_CREATE_SHARE_OK
[15:04] <dobey> ok
[15:05] <facundobatista> alecu, today, through the dbus interface you can do create_share() for both username and mail
[15:05] <facundobatista> alecu, and then you can listen to ShareCreated and ShareCreateError
[15:05] <alecu> facundobatista, right
[15:06] <facundobatista> alecu, tomorrow, you should be able to listen ShareInvitationSentOK and ShareInvitationSentError (or something)
[15:06] <alecu> facundobatista, ok, right.
[15:06] <alecu> facundobatista, I don't plan to add those DBus signals now.
[15:07] <facundobatista> alecu, that's why you need the event on error :)
[15:07] <facundobatista> alecu, oh
[15:07] <facundobatista> alecu, mmm... so your fix is a half fix
[15:07] <facundobatista> nessita, ^
[15:07] <dobey> nessita: #686606
[15:08] <nessita> facundobatista: well, zg don't need that...
[15:08] <nessita> facundobatista: if we (magicicada) need it, we can fill a bug? we can propose a patch?
[15:08] <alecu> nessita, that makes sense.
[15:09] <facundobatista> nessita, yes, wee need to add code on that
[15:09] <AJenbo> hmm seams i always have to start the ubuntu one client, and posibly the u1sdtool before sync happens.
[15:09] <nessita> AJenbo: what system are you running?
[15:09] <nessita> facundobatista: yes
[15:10] <AJenbo> My laptop has been one for 25 hours after i made a sync at work, and still wasn't updated, infact the content on it is much older then before that sync
[15:10] <AJenbo> nessita, maverick
[15:10] <AJenbo> the keys ring is unlocked (started my mail client on boot)
[15:11] <nessita> AJenbo: we have a known bug regarding that. We have proposed the fix, but I'm not sure it hit maverick-updates yet
[15:11] <nessita> AJenbo: what does u1sdtool -s says?
[15:11] <nessita> rmcbride: ping
[15:11] <AJenbo> it's doing a local rescan
[15:11] <dobey> it's in -proposed still afaik
[15:11] <rmcbride> nessita: hi
[15:11] <nessita> rmcbride: hi there! quick question. Are the SRU on -updates now? or still -proposed?
[15:12] <AJenbo> also u1sdtool dosn't seams to work over ssh (complains about gtk dialog), but i remember it working back on lucid
[15:12] <rmcbride> nessita: we still have verification of #647483 pending. if you could respond to my question on that I think we may be good to go
[15:12] <nessita> AJenbo: so, syncdaemon just started. To make it synch, u1sdtool -c
[15:12] <nessita> rmcbride: right! I have that on my todo, I'll try now
[15:12] <nessita> AJenbo:  the gtk thing means you don't have valid credentials on that machine
[15:13] <nessita> AJenbo: I mean, you're ssh'ing to a machine that doesn't have valid credentials for Ubuntu One and the sign opn dialog is being raised
[15:13] <dobey> nessita, rmcbride: fwiw, -proposed stuff typically isn't pushed to -updates for at least 7 days after all the bugs are verification-done
[15:13] <AJenbo> i'm locked in as my self and went in to the other rom ran the u1sdtool, went back in to the other computer and still got the samme error over ssh
[15:13] <nessita> dobey: really? in my experience for ussoc has been 1 or 2 days after
[15:13] <AJenbo> infact on the local machine ssh'ing to it self i still get the error
[15:14] <dobey> nessita: for uploads to devel ubuntu, or for SRU?
[15:14] <nessita> AJenbo: that's because u1sdtool is connecting to different dbus sessions. YOu should use screen when ssh'ing
[15:14] <nessita> dobey: for SRUs
[15:15] <AJenbo> nessita, try this "ssh localhost", then "u1sdtool -s" and you will get a screen load of python whining
[15:16] <AJenbo> this did not happen on lucid, and i think it is related to the sso client
[15:16] <dobey> AJenbo: it did happen. or at least, there might have been less of it. But dbus does not work over ssh.
[15:16] <AJenbo> the solution is to use "ssh -X localhost"
[15:17] <dobey> dbus does not forward over the X connection
[15:17] <nessita> AJenbo: you're mixing things :-). Let me explain
[15:17] <dobey> and even if it did, it wouldn't do what you expected
[15:17] <AJenbo> dobey, then wy does it work
[15:17] <AJenbo> shoudn't the dbus be confined to the local machine?
[15:18] <nessita> AJenbo: can you please wait a few minutes and read what I'm about to say?
[15:18] <AJenbo> sure...
[15:18] <dobey> AJenbo: i'm not sure what your definition of 'work' is here, but it doesn't, without lots of extra environment configuring, which ssh doesn't do for you, and which is hard to do automatically
[15:19] <nessita> AJenbo: thanks! u1sdtool connects to the session bus. When doing ssh to a machine, u1sdtool is connecting to a different session bus that the one you have connected on a terminal without ssh
[15:19] <AJenbo> dobey, i just want to see the status of sync deamon on my other machine
[15:19] <nessita> AJenbo: you can't do it over ssh
[15:19] <dobey> nessita: no ti isn't
[15:19] <nessita> AJenbo: the result you'll get will be confusing
[15:19] <dobey> nessita: when doing ssh, there is no dbus; unless you configure the environment vars to point to the proper things on the machine you're sshed in to
[15:20] <nessita> AJenbo: if you want to do that, you need to use some helper such as "screen"
[15:20] <nessita> dobey: I'm not sure what you're talking about but you can try it yourself... u1sdtool locally, and then over ssh
[15:21] <nessita> AJenbo: so, let's solve one problem at a time.
[15:21] <AJenbo> "u1sdtool -s"  gives me the same results   "ssh -X localhost", "u1sdtool -s"
[15:21] <AJenbo> i don't find it confusing...
[15:22] <dobey> nessita: ssh localhost 'echo "$DBUS_SESSION_BUS_ADDRESS"'
[15:22] <dobey> nessita: notice how it is empty.
[15:22] <nessita> AJenbo: you're starting 2 daemons I think, let me confirm. verterok, you arond?
[15:23] <verterok> nessita: wasup?
[15:23] <AJenbo> ok, ill wait til it start uploading/downloading stuff, then we should be able to see if it is the same deamon it is talking to
[15:23] <dobey> AJenbo: the results aren't the same, even if you think they are. u1sdtool does not work over ssh.
[15:23] <nessita> verterok: what was the issue with using u1sdtool via ssh?
[15:23] <verterok> nessita: there is no dbus session
[15:24] <AJenbo> but yes i see you point about the deamon being bound to the session
[15:24] <nessita> verterok: AJenbo doesn't believe it doesn't work as expected, could you please explain with a little more detail?
[15:24] <dobey> sigh
[15:24] <AJenbo> could it be made to work
[15:24] <dobey> pay no attention to the gnome developer of 10+ years
[15:24] <dobey> not easily
[15:24] <AJenbo> (don't have to explain that it doesn't)
[15:24] <AJenbo> ill belive you for now
[15:24] <verterok> if you start 2 syncdaemon *bad* things will happen
[15:24] <nessita> AJenbo: nopes as far as I know
[15:24] <AJenbo> :(
[15:25] <nessita> verterok: so u1sdtool over ssh starts another daemon, right?
[15:25] <dobey> nessita: no
[15:25] <dobey> nessita: it simply fails.
[15:25] <AJenbo> not even in the near future natty +1/+2
[15:25] <rye> rodrigo_: bug #564669, older paste was not meant to go there, not yet that familier with irrsi
[15:25] <ubot4> Launchpad bug 564669 in couchdb-glib "Deleting an document just after creation generates an internal server error (affects: 1)" [Undecided,New] https://launchpad.net/bugs/564669
[15:25] <nessita> dobey: that didn't happen on my case. I've tried it by mistake.
[15:25] <rye> nessita: looking
[15:25] <verterok> AJenbo: the issue is that syncdaemon use dbus as a lock, so if you start another dbus session there is nothing to prevent from a dbus call to automatically start a new daemon
[15:26] <nessita> AJenbo: you can check your syncdaemon status over ssh using the program "screen", like I mentioned before
[15:26] <dobey> oh well, it fails for me anyway because nightlies are broken
[15:26] <rodrigo_> rye, hmm, ok, looking
[15:26] <AJenbo> nessita, good ping, i was planning to look in to screen any way
[15:27] <nessita> AJenbo: if you want to learn, I can help you with that. DO u1sdtool -q on every machine/session/ssh
[15:27] <verterok> nessita, AJenbo: if you execute plain: u1sdtool --start via ssh, it will fail with something like this:
[15:27] <verterok> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: /bin/dbus-launch terminated abnormally with the following error: Autolaunch error: X11 initialization failed.
[15:27] <dobey> screen will only work if you start the screen session by local means, and not over ssh
[15:27] <AJenbo> yeah
[15:27] <rye> nessita: re tomboy notes - it is possible that server-side sends invalid xml
[15:27] <verterok> *but* if you execute it using dbus-launch, it wil fire a new dbus session and thing will "work" (for some value of work)
[15:27] <verterok> nessita: ^
[15:27] <dobey> and by local means i mean inside a logged in gnome sessijon
[15:28] <rye> verterok: i second that, it works :), I used to use that method
[15:28] <dobey> if you start screen and then log out, the dbus session will be forfeit
[15:28] <verterok> nessita, AJenbo: dbus-launch u1sdtool --start
[15:28] <verterok> rye: :)
[15:28] <nessita> rye: can we help rigved diagnose if this is the case?
[15:28] <dobey> if you export the dbus environment vars to be the same as the ones where the logged in session is running, then you can talk to the remote service
[15:29] <dobey> verterok: that will start a second syncdaemon
[15:29] <verterok> dobey: yes, exactly my point :)
[15:29] <rye> nessita: only by recompiling tomboy adding debug statements, unfortunately
[15:29] <verterok> which is *bad*
[15:29] <AJenbo> shoudn't there be put something in place to prevent multiple syncdeaemons?
[15:30] <nessita> AJenbo: we have, but it works under the same dbus session
[15:30] <rye> AJenbo: yes, that's dbus, but there should be only one dbus session for the user
[15:31]  * rye recalls some issue he faced when dbus got.. ah
[15:31] <AJenbo> hmm i'm still having a hard time seeing that this dons't work, the status just changed and i can see it on both the local and the ssh
[15:31] <rye> AJenbo: are you on headless installation, i.e. accessing only via ssh?
[15:31] <AJenbo> rye, no, laptop
[15:32] <AJenbo> rye, if it was headless i would have a hard time executing the command locally ;)
[15:32] <nessita> AJenbo: what does the folowing output: ps aux | grep ubuntuone
[15:33] <verterok> AJenbo: it "works", but you might end up losing data.
[15:33] <rye> AJenbo: ok, in case you arrange for dbus session to persist for local installation and store info about it somewhere so it gets restored for all other logins 9e.g. GUI) then you will get 2 dbus sessions running since gdm launches gnome-session with dbus-launch unconditionally. That's what I got. After that talking to some processes was really hard since they were on "different" session
[15:34] <dobey> i don't see what point trying to do 'ssh localhost' serves anyway, unless you're trying to test what happens when you ssh into a different machine without needing two IPs
[15:34] <verterok> AJenbo: basically, the on-disk metadata used by syncdaemon isn't suited for being modified by multiple processes
[15:35] <verterok> if you start two syncdaemons, you might (and probably will) lose data
[15:35] <AJenbo> nessita, http://pastebin.com/p4u76EQF
[15:35] <rye> is it only me or bzr branch lp:~adiroiban/couchdb-glib/couchdb-session-tests cannot be done?
[15:36] <rodrigo_> rye, right, can't do it neither
[15:36] <AJenbo> dobey, ssh localhost is for testing
[15:37] <rye> rodrigo_: btw, in bug #564669 i wrote how to find out what invalid json went to couchdb - https://bugs.launchpad.net/couchdb-glib/+bug/564669/comments/1
[15:37] <ubot4> rye: Bug 564669 on http://launchpad.net/bugs/564669 is private
[15:38] <rodrigo_> yeah, saw it
[15:38] <AJenbo> verterok, then shoudn't there be placed a hardlock on the data prevening this? Or is it ok that some one who dosn't know the inner workings of U1 and want to see the status over ssh, might loos his data?
[15:39] <verterok> AJenbo: there is no support for using syncdaemon over ssh
[15:40] <verterok> AJenbo: sadly, using a file lock brings a lot of other problems to the table :(
[15:40] <verterok> like no way to support nfs
[15:41] <AJenbo> k :/
[15:42] <AJenbo> Call me crasy but didn't the ps aux show that both the ssh and local u1sdtool is talking to the same daemon?
[15:43] <verterok> then something really weird is going on
[15:44] <AJenbo> verterok, is the thing about ssh not being supported in any wiki or faq?
[15:44] <nessita> AJenbo: seems like it, but you should not use sdtool (nor syncdaemon) over ssh
[15:44] <AJenbo> if it continues to "work" i probably will
[15:45] <AJenbo> but don't worry i won't come crying if i loos some thing as a result :)
[15:45] <nessita> AJenbo: you understand you can safely manage syncdaemon over ssh using screen, don't you? do you need help setting that up?
[15:46] <nessita> AJenbo: why would you prefer to risk your data instead?
[15:46] <AJenbo> nessita, yeah but i don't think i have time to learn that right now, i'm getting to be late for work
[15:47] <nessita> AJenbo: is your call
[15:47] <AJenbo> nessita, i'm not doing ssh u1sdtool right now, and can wait untill i learn screen, but i can't learn screen right now
[15:47] <AJenbo> i don't see any thing wrong with that
[15:48] <AJenbo> unless you think learn screen > have a job
[15:49] <AJenbo> one last thing.
[15:49] <AJenbo> Could i solve the issue with data not being synced by adding u1sdtool -c as a start up program in gnome?
[15:50] <nessita> AJenbo: there is a fix for that issue (syncdaemon not connecting automatically) that is already on maverick-proposed. You can enable that repository or wait a few days until is relesed under maverick-updates
[15:51] <AJenbo> nessita, thanks ill do "that"
[15:51] <nessita> AJenbo: you're welcome, instructions how to enable the repository are at (looking link)
[15:52] <nessita> https://wiki.ubuntu.com/Testing/EnableProposed
[15:52] <AJenbo> i know
[15:52] <AJenbo> ok, thanks :)
[15:52] <nessita> :-)
[15:53] <nessita> rmcbride: I don't have the test translated for the SSO dialog when ubuntu one opens it...
[15:54] <rmcbride> nessita: so that bug is not then fixed?
[15:54] <nessita> seems like not, thou I may be testing it wrong
[15:54] <nessita> rmcbride: how did you test it? I installed turkish locale and started a X session with that language set
[15:54] <nessita> then, I removed U1 credentials and issues u1sdtool -c
[15:54] <rmcbride> nessita: I didn't really know HOW to test, which is why I asked for your opinion
[15:56] <nessita> rmcbride: you can install a new language pack and boot your session in that language
[15:56] <rmcbride> nessita: but it certainly sounds as iff there is an issue. Can you put your results in the bug report? we may need rodrigo to revisit...
[15:56] <nessita> rmcbride: maybe the string is not translated yet? do you where I can check that?
[15:56] <AJenbo> nessita, just tried ssh -X ip u1sdtool -s from a remote machine, and it seams to have spawned a seperate sync-deamon
[15:57] <rmcbride> nessita: it's certainly possible that translations are not done
[15:57] <AJenbo> by
[15:57] <rmcbride> nessita: but I don' t know anything about how that process works
[15:57] <nessita> dobey: do you know where translations are stored in disk, to check if a string is translated or not?
[15:58] <rmcbride> nessita: I think perhaps a language more likely to already be translated might be a decent choice. I'll try it in German shortly. I need to set this up on a seperate machine.
[15:58] <nessita> rmcbride: my result on a screenshot: http://imagebin.ca/view/eFc-Eef.html
[15:59] <rmcbride> nessita: that certainly looks like it's not translated, but I don't know if it's because the bug isn't fixed, or turkish translations haven't been updated
[15:59] <nessita> right
[16:01] <rmcbride> nessita: OK I think when I asked my question I was focussed more on the "arrive by dbus" section and less on the resulting translated display.
[16:02] <rmcbride> nessita: I need to go get food for lunch, I'll set up a test on German when I return
[16:02] <nessita> rmcbride: ok then
[16:02] <rmcbride> nessita: I don't suppose you are already perhaps running Spanish anywhere?
[16:02] <nessita> rmcbride: nopes :-/
[16:03] <nessita> rmcbride: I run turkish because the Decimal module from python crashes with that land
[16:03] <rmcbride> nessita: OK. Worth asking anyhow :)
[16:03] <nessita> lang*
[16:03] <nessita> so I like to test using that lang
[16:03] <rmcbride> Ah I see
[16:07] <dobey> rmcbride, nessita: that string was translated on Oct 20, so probably not shipped yet
[16:08] <rmcbride> doh
[16:08] <nessita> dobey: how can you tell, so I can learn how to diagnose?
[16:08] <nessita> dobey: also, I can add a dummy translation myself, if I'd knew where the translation files are :-D
[16:09] <dobey> https://translations.edge.launchpad.net/ubuntu/natty/+source/ubuntuone-client
[16:09] <dobey> nessita: you can't edit the translation files in place as they are binary data
[16:09] <dobey> nessita: you'd need to edit in the source, build the translation, and install it
[16:09] <nessita> dobey: they are? oh
[16:10] <dobey> hrmm
[16:10] <dobey> oh
[16:10] <dobey> of course
[16:13] <dobey> i know what the problem is
[16:15] <nessita> dobey: what problem where?
[16:15] <dobey> in syncdaemon
[16:15] <nessita> dobey: regarding translation? :-/
[16:15]  * nessita is not following
[16:17] <dobey> yes
[16:17] <dobey> is there a bug # for the broken translation?
[16:17] <nessita> dobey: bug #647483
[16:17] <ubot4> Launchpad bug 647483 in ubuntuone-client (Ubuntu Maverick) (and 8 other projects) "Ubuntu One help text contains non-translatable text (affects: 2) (dups: 1) (heat: 64)" [Undecided,Fix released] https://launchpad.net/bugs/647483
[16:17] <dobey> i already have a branch to fix it :)
[16:20] <dobey> oh, well mostly done perhaps. let me check libsyncdaemon
[16:21] <dobey> ok, so there are two bugs
[16:23] <dobey> https://bugs.launchpad.net/ubuntu-sso-client/+bug/647483/comments/5
[16:23] <ubot4> Launchpad bug 647483 in ubuntuone-client (Ubuntu Maverick) (and 8 other projects) "Ubuntu One help text contains non-translatable text (affects: 2) (dups: 1) (heat: 18)" [Undecided,Triaged]
[16:28] <dobey> nessita: and filed bug #686647 for the other issue
[16:28] <ubot4> Launchpad bug 686647 in ubuntuone-client (Ubuntu Natty) (and 5 other projects) "SSO help text does not appear translated in UI (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/686647
[16:29] <dobey> going to get some lunch, and then i will fix it; and finish the other things i'm working on at the moment
[16:30] <nessita> dobey: ok, thanks
[16:37] <nessita> thisfred: comments on bug #686289?
[16:37] <ubot4> Launchpad bug 686289 in ubuntuone-client (Ubuntu) "Ubuntu One Preferences not loading (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/686289
[16:38] <thisfred> nessita, hmm, no that's a weird one.
[16:38] <thisfred> mandel: vds, CardinalFang, any idea what could cause a gnomekeyring.IOError ^^? (Why does it even have its own IOError?)
[16:39] <nessita> thisfred: seems like the keyring is locked? I thought that we agreed on using txsecrets? but maybe that fell off of milestone 1.0?
[16:39] <thisfred> nessita: that is not yet 1.0
[16:39] <nessita> right
[16:39] <thisfred> nessita: no, I mean the bug report is not running 1.0
[16:39] <thisfred> nessita: I have not worked on the keyring parts, so I don't know if 1.0 will fix this
[16:40] <nessita> ah! you're right, is natty
[16:40] <mandel> nessita, thisfred ASAIK we are not using tx secret, are we?
[16:41] <vds> thisfred: sorry no :(
[16:42] <CardinalFang> thisfred, natty, I don't know the cause of that.  I'm looking around the web.
[16:45] <CardinalFang> thisfred, nessita, my guess is that it's a problem talking to DBus somehow.
[16:45] <thisfred> oh joy
[16:47] <thisfred> It's not a miracle of sound design that u1prefs fails to start if the replication service has a problem either
[16:47] <CardinalFang> I added a question to the bug.   python -c "import gnomekeyring; gnomekeyring.get_default_keyring_sync()"    # error?
[16:47] <thisfred> CardinalFang: thx, I'll assign it to myself, and keep an eye on it. May come back to you with questions. In fact it's pretty much guaranteed.
[16:48] <CardinalFang> Roger.  Okay, thisfred.
[16:52] <CardinalFang> thisfred, vds, I think I can reduce the complexity around keyring usage.  I will look soon.
[16:52] <CardinalFang> soon = in the next week or so.
[16:54] <CardinalFang> lunch
[16:54]  * nessita -> lunch
[17:09] <rye> we are looking into the issue that is causing the following to be displayed for new signups in 10.04 -  http://ubuntuone.com/p/Sb4/
[17:12] <alecu> CardinalFang, thisfred: I had some similar gnomekeyring issues when the user set gdm to autologin
[17:12] <alecu> when using autologging, the default keyring is not unlocked.
[17:21]  * nessita is back
[17:21] <nessita> CardinalFang, thisfred: thanks for your attention to this. Now I remember what alecu is pointing out...
[17:21] <nessita> alecu: how did you solve it?
[17:23] <alecu> nessita, I started digging and found gnomekeyring to be unreliable: some gk functions tried to unlock the keyring (and blocked) while other gk functions just returned that error.
[17:24] <nessita> alecu: ok, so one more argument to switch to txsecrets. Thanks!
[17:24] <alecu> and there's no good documentation on python-gnomekeyring, so it was a bit of reading the C api, and a bit of manual testing... so yes, txsecrets ftw!
[17:25] <nessita> alecu: it works great, by the way, you did a terrific work there. Thanks!
[17:25] <alecu> :-)
[17:30] <dobey> hmm
[17:32] <rmcbride> nessita: dobey: I've marked bug #647483 as "verification done" based on the digging y'all have done. We'll likely need to do another SRU in maverick going forward, but I'd like to get the version in -proposed moved along ASAP to address the startup/connect issues
[17:32] <ubot4> Launchpad bug 647483 in ubuntuone-client (Ubuntu Maverick) (and 8 other projects) "Ubuntu One help text contains non-translatable text (affects: 2) (dups: 1) (heat: 18)" [Undecided,Triaged] https://launchpad.net/bugs/647483
[17:33] <nessita> rmcbride: +100
[17:35] <dobey> rmcbride: fine by me
[17:40] <karni> beuno: CardinalFang: hi guys. what can I say.. after uber successful code session during weekend just before 30 Nov, I had little time to get back on track *slams head against the wall*. canonical should soo hire me heh, I would have no other issues to focus on. anyhow, software for my aunt that I mentioned to beuno is done, and apart from 2 and counting assignments at college, I'm currently relatively able to get back to work *looks
[17:41] <karni> CardinalFang: I'll be probably still shuffling some code, however if you would be fine with us agreeing on approach to introduce publishing (content provider part is ready), you could definitely start with that
[17:41] <beuno> karni, heya!
[17:41] <beuno> karni, have you been committing all these changes to trunk?
[17:41] <karni> beuno: CardinalFang: upon connection, one has access to all meta data (Ubuntu One/UDFs/Shares) as previously mentioned, I also added
[17:41] <karni> hi beuno !
[17:42] <karni> beuno: no, I was waiting with that to ask for your opinion/permission on what to do
[17:42] <karni> as I need 3-4 free days (read: 3-4 weekend days) to make it at least as usable as AndroidU1
[17:42] <karni> finishing: I also added 'sync button' next to each file/folder, so that once selected
[17:43] <karni> it's saved into the content provider, and will be sync'ed upon change on the server side.
[17:43] <karni> beuno: if you have a moment, we can discuss that now.
[17:43] <beuno> CardinalFang, I think I feel that if this is where we're going, it should go into trunk. What do you think?
[17:44] <karni> beuno, when I push the code, you can put in your oauth tokens and see were we at
[17:44] <beuno> great
[17:44] <karni> but, like I said, I really roll with the project when I have a free day or two
[18:43] <rye> http://launchpad.net/bugs/686697
[18:43] <ubot4> Launchpad bug 686697 in ubuntuone-servers "/oauth/request/ fails with CSRF verification failed. Request aborted. (affects: 1) (heat: 8)" [High,Confirmed]
[18:44] <rye> fyi
[19:12] <dobey> nessita, rmcbride: https://code.launchpad.net/~dobey/ubuntuone-client/fix-translations/+merge/42990
[19:13] <dobey> nessita, rmcbride: don't know if the latest translation packages have been released on maverick, but there is a turkish translation for that string on narwhal for sure
[19:13] <rmcbride> dobey: cool, thanks. Reviewing now
[19:14] <nessita> dobey: ack
[19:14] <dobey> no en espanol, though
[19:15] <karni> CardinalFang: please call my nick too, when you answer beuno's question about pushing my source into trunk.
[19:15] <alecu> nessita, do you know how we add python-zeitgeist as a dependency on the ubuntuone-client package?
[19:15] <rmcbride> yea I don't have my  dev box on narwhal yet
[19:15] <dobey> err, actually maybe in spanish. not in albanian though
[19:15] <dobey> alecu: to which package?
[19:15] <nessita> alecu: talk to dobey, he builds the package
[19:15] <rmcbride> but I'll find out about maverick I guess :)
[19:15] <nessita> dobey: ubuntuone-client
[19:15] <alecu> dobey, ralsina found this: http://launchpadlibrarian.net/60282604/buildlog_ubuntu-maverick-i386.ubuntuone-client_1.5.0%2Br764~maverick1_FAILEDTOBUILD.txt.gz
[19:15] <nessita> or ubuntuone-syncdaemon
[19:15]  * nessita runs
[19:16] <dobey> ah nightlies
[19:16] <dobey> oh well at least it's a different error
[19:16] <dobey> alecu: i'll update
[19:16] <dobey> uhm
[19:16] <dobey> wait
[19:17]  * alecu waits
[19:17] <dobey> how the heck did that even land
[19:18] <ralsina> At least it doesn't look like a terribly hard problem
[19:19] <dobey> ah nevermind
[19:19] <dobey> there is no python-zeitgeist
[19:19] <nessita> dobey: zeitgeist-core
[19:20] <dobey> yeah i see that now, after a little __file__ checking
[19:20] <alecu> nessita, right, thanks.
[19:21] <rmcbride> grr. Ok translations clearly not updated yet in maverick (dated 10 09)
[19:21] <rmcbride> MAYBE my old laptop works in that context, it is upgraded, don't recall if I have the dev environment on it still...
[19:24] <dobey> alecu, nessita: fixed, along with missing platform/ from the packages
[19:24] <dobey> alecu: of course, the tests will still probably fail for the other reasons :-/
[19:26] <alecu> dobey, sorry, didn't got that part. what other reasons?
[19:26] <dobey> alecu: there is some weird issue with the tests failing in all kinds of weird ways, in the package
[19:27] <alecu> dobey, oh, ok. I thought it was zeitgeist related. Thanks!
[19:27] <dobey> nah. no ghosts until your branch landed :)
[19:30]  * alecu will get some food
[19:45] <rye> public files also suffer from the same CSRF protection issue
[20:40] <AJenbo> Hi again, back from work with more questions :)
[20:41] <AJenbo> my lap top has been hanging on LOCAL_RESCAN for the past 4 hours, i think somthing might be haning...
[20:42] <AJenbo> also how about to avoid multiple syncdaemons running at the same time, just check if a syncdaemon process is allready is running, or would that pring issues with multi users?
[20:55] <AJenbo> also i don't really see any hdd activity
[21:04] <AJenbo> hmm might be some thing bad that happned when i was messing with ssh and u1sdtool, and i did promise not to come wining about it so guess ill try to fix this one my selv :)
[21:04] <AJenbo> keep up the good work.
[21:11] <nessita> AJenbo: to debug, you can:
[21:11] <nessita> quit all the syncdaemon instances
[21:11] <nessita> (either killing the process or u1sdtool -q)
[21:12] <nessita> be sure there is no ubuntuone-syncdaemon process running
[21:12] <nessita> and in that scenario, start syncdaemon from a local terminal (no ssh involved) using u1sdtool -c
[21:13] <nessita> AJenbo: you may have corrupt metadata due to potential multiple syncdaemon's modifying it...
[21:14] <nessita> AJenbo: please let me know if after a full restart of the service (what I've just described) you keep having a stuck syncdaemon on LOCAL_RESCAN
[21:22] <alecu> nessita, if you have some time tomorrow, please review: https://code.launchpad.net/~alecu/ubuntuone-client/ziggy-for-syncdaemon/+merge/42980
[21:22] <alecu> verterok, idem
[21:23] <alecu> verterok, oh, you don't work tomorrow :-)
[21:23] <verterok> alecu: I'll try to review it today
[21:23] <verterok> :)
[21:23] <alecu> thanks!
[21:23] <nessita> alecu: do you work tomorrow?
[21:23] <alecu> no, I don't
[21:23] <nessita> (I will review it)
[21:23] <nessita> alecu: okis
[21:36] <dobey> rmcbride, rye: have either of you reproduced https://bugs.launchpad.net/bugs/674876 at all?
[21:36] <ubot4> Launchpad bug 674876 in ubuntuone-client (Ubuntu) (and 1 other project) "Nautilus keeps opening when ubuntu one plugin is installed (affects: 2) (dups: 2) (heat: 20)" [High,Incomplete]
[21:57] <rmcbride> dobey: I was not able to reproduce that at all no
[22:01] <dobey> :-/
[22:03] <dobey> rmcbride: did you get anywhere with the translation?
[22:04] <rmcbride> dobey: oh right. I was setting up on the other laptop. Give me a few
[22:04] <dobey> sure
[22:07] <duanedesign> u1sdtool --refresh shares  refreshes the UDFs? I get shares and shared confused
[22:15] <dobey> no
[22:15] <dobey> --{whatever}-folders are arguments to deal with UDFs
[22:15] <dobey> shares are shared to you, shared are things you share to others, i think
[22:19] <rmcbride> dobey: I am not seeing translated strings on natty with your branch and the provided tests. I've tried in Turkish and in German. From the dates on teh version string of the language packs though, I'm not certain that the translations are in yet
[22:20] <rmcbride> dobey: hold on a sec
[22:20] <dobey> rmcbride: the turkish one should be 201012something
[22:20] <rmcbride> dobey: it is. I think I was in the wrong terminal, one sec
[22:20] <duanedesign> thanks dobey
[22:21] <dobey> 1:11.04+20101202
[22:21] <dobey> ah
[22:21] <rmcbride> dobey: nope, I was in the right window. re-ran that command and still getting english.
[22:21] <dobey> weird
[22:21] <dobey> ran it in my branch?
[22:21] <rmcbride> yea... I don't get it
[22:21] <rmcbride> yea run in your branch copy-pasted verbatim into the terminal as well
[22:22] <dobey> [dobey@lunatari:fix-translations]: PYTHONPATH=. LANG=tr_TK.UTF-8 python -c "from ubuntuone.clientdefs import DESCRIPTION; print DESCRIPTION"
[22:22] <dobey> Ubuntu One, bir Ubuntu Single Sign On (SSO) hesabına ihtiyaç duyuyor. Bu işlem, eğer yoksa yeni bir hesap oluşturmanızı sağlayacak.
[22:22] <dobey> ^^ that's what i get
[22:22] <dobey> weird
[22:22] <rmcbride> rmcbride@strangiato:~/canonical/ubuntuone-client/review.ft$ PYTHONPATH=. LANG=tr_TK.UTF-8 python -c "from ubuntuone.clientdefs import DESCRIPTION; print DESCRIPTION"
[22:22] <rmcbride> Ubuntu One requires an Ubuntu Single Sign On (SSO) account. This process will allow you to create a new account, if you do not yet have one.
[22:23] <dobey> rmcbride: PYTHONPATH=. python -c "from ubuntuone import clientdefs as cd; print cd.__file__"
[22:23] <rmcbride> dobey: /usr/lib/pymodules/python2.6/ubuntuone/clientdefs.pyc
[22:23] <rmcbride> hmm
[22:24] <dobey> rmcbride: you do need to do "./autogen.sh && make ubuntuone/clientdefs.py" first
[22:24] <rmcbride> dobey: doh. right
[22:24] <rmcbride> I miss regular review days
[22:24]  * dobey updates the description to be a bit clearer
[22:25] <dobey> yeah
[22:25] <duanedesign> I think --refresh-volumes is what I was looking for. Have a couple users on the forums, and bbug reports with issues greating UDF's and then they do not show up.
[22:25] <rmcbride> PYTHONPATH=. LANG=tr_TR.UTF-8 python -c "from ubuntuone.clientdefs import DESCRIPTION; print DESCRIPTION"
[22:25] <rmcbride> Ubuntu One requires an Ubuntu Single Sign On (SSO) account. This process will allow you to create a new account, if you do not yet have one.
[22:26] <rmcbride> hmm
[22:26] <dobey> and clientdefs.py built?
[22:27] <dobey> duanedesign: ah right, volumes. forgot about that name
[22:27] <rmcbride> it sure seems to have, however it's still getting the one out of /usr/lib/blah
[22:29] <rmcbride> OK
[22:29] <rmcbride> got it
[22:29] <rmcbride> had a very old set of everything on that laptop
[22:32] <dobey> hmm
[22:32] <dobey> ok
[22:33] <dobey> alright, i'm out for the evening; later
[22:40] <rmcbride> yea me too
[22:52] <duanedesign> has anyone seen this before http://ubuntuforums.org/showthread.php?t=1640088
[22:52] <duanedesign> "CSRF verification failed. Request aborted."?
[22:57] <beuno> duanedesign, yeah, working on it
[23:03] <duanedesign> beuno: ahh, ok thank you :)