[12:51] <aquarius> CardinalFang, ping?
[13:13] <aquarius> thisfred, ping
[13:13] <thisfred> aquarius: pang
[13:15] <thisfred> ?
[13:16] <aquarius> currently, CouchDatabase.get_records() explicitly excludes deleted records, which is good
[13:16] <aquarius> I don't have a way of getting records that *include* deleted ones, though
[13:17] <aquarius> can you think of a good way of doing this?
[13:17] <aquarius> i.e., should I add a return_deleted_items=False to that function and have it create *two* views?
[13:21] <thisfred> aquarius: I'd prefer a new method with that explicitly in the name. Yes it's just syntax, but most people using the API won't care about deleted records, and prefer to think of them as deleted, so not having this extra kw arg makes the API cleaner IMO
[13:22] <thisfred> we will have to create both views yes, unless we can think of a clever way to collate the two without suffering performance
[13:22] <aquarius> yeah, but I'm loath to create a whole new method, because that dignifies it. Deleted records are a hack. If we bake a method into the api then we have to support it until the end of time :(
[13:23] <aquarius> the alternative is that I have some other way of detecting that there used to be a paired server record for a given cloud service, but it's since been removed, which i think CardinalFang was doing, but he's not here so I can't ask him :)
[13:25] <tchernobog> hallo, i'm a subscriber of the ubuntuone 10GB plan
[13:25] <tchernobog> is there a way to delete entire directories via web interface?
[13:25] <aquarius> oo, CardinalFang returns :)
[13:25] <aquarius> tchernobog, at the moment there isn't, I don't think
[13:26] <tchernobog> whoops
[13:26] <tchernobog> and then, how can i do that?
[13:26] <aquarius> tchernobog, you can do it on your desktop
[13:26] <tchernobog> right, but the client seems to have some problems here on karmic
[13:26] <tchernobog> it doesn't always connect etc.
[13:27] <aquarius> I believe there's a new version coming out in the next few days which resolves the connection problems
[13:27] <tchernobog> i've removed the directory, the client says it's connected
[13:27] <aquarius> dobey will know :)
[13:27] <tchernobog> but it doesn't delete the dir remotely
[13:27] <tchernobog> should i open up a bug report for allowing to delete directories via web interface?
[13:28] <aquarius> yes please, if there isn't one already
[13:28] <tchernobog> also renaming doesn't work, so i believe it's a missing functionality
[13:29] <CardinalFang> aquarius, I didn't have a use for records for service pairings after we're finished with them.  Only for peer hosts, we need to keep the record around so we know to update the far end not to point back to us.
[13:29] <aquarius> ah, ok
[13:30] <aquarius> the thing I'm trying to resolve is: when you start up ubuntuone-client-applet, it should add the u1 couch pairing
[13:30] <aquarius> but if they've explicitly gone in and unpaired that because they don't want it, it should not be re-added!
[13:30] <aquarius> hence me wanting to see if there is a record that's been deleted
[13:30] <tchernobog> yes there are many bugs about deleting from web
[13:30] <aquarius> couchdatabase.get_records() helpfully doesn't show deleted records, though :)
[13:30] <tchernobog> for anyone interested, the bug about deleting from web is 428801
[13:31] <aquarius> tchernobog, there's a "this also affects me" there you can click
[13:31] <tchernobog> i've done it, just reporting for the record or anyone else affected
[13:31] <aquarius> tchernobog, thanks!
[13:31] <tchernobog> aquarius: thanks to you!
[13:32] <aquarius> CardinalFang, another question: yesterday you said that I could call put_static_paired_service and not bother supplying any oauth data, because the replication daemon looks up the oauth data when it first starts up. But...I do need to supply that data. Can I supply it with lies?
[13:34] <thisfred> aquarius: if I unpair with u1, and change my mind, how do I pair again, if you hide the option?
[13:35] <thisfred> I would just always offer it if it's not paired...
[13:35] <thisfred> as inoffensively as possible, UI wise
[13:35] <aquarius> thisfred, ah, two different things. The pairing tool lets you explicitly say "pair with U1" or "unpair with U1 (if you're already paired)"
[13:35] <aquarius> what I'm doing is: when you start up client-applet, also pair desktopcouch with U1 without giving you the option
[13:36] <CardinalFang> aquarius, I saw put real data in there, and we should figure out what the replicator should do.
[13:36] <thisfred> aquarius: aha
[13:36] <aquarius> CardinalFang, ok
[13:36] <thisfred> sry
[13:37] <aquarius> thisfred, what I don't want to happen is: you start up client-applet, it pairs DC with U1, you think "I don't want that" and unpair DC with U1 using the pairing tool, then you start client-applet again and it re-pairs you :)
[13:37] <thisfred> aquarius: and how about going around the API there? Just doing an on the fly view for that one deleted record? (the db is likely to be minute)
[13:37] <aquarius> can't do on-the-fly views, though
[13:37] <aquarius> _temp_view is going away
[13:37] <thisfred> ah ok, well, then adding a view _design/management/get_deleted_u1_pairing
[13:37] <aquarius> yeah, that's what I thought I'd need to do :)
[13:38] <thisfred> right
[13:38] <thisfred> I would object to putting any of the deleted stuff in the actual API, since version history is going to shake all that up
[13:38] <thisfred> and we don't want clients relying on stuff that's not gonna work the same anymore
[13:49] <aquarius> CardinalFang, if the replication daemon looks up the data anyway, is there any need for me to pass real data in? (getting hold of the real data is a bit of a pain, so I'd like to just pass in nulls if I can)
[13:50] <CardinalFang> aquarius, Well, let's decide.
[13:51] <aquarius> ok
[13:51] <CardinalFang> aquarius, Where should it go?  We have only one service module.  Perhaps we're over-planning.
[13:51] <CardinalFang> Is it both likely that we will have other modules included and that one will have a weird auth idea?
[13:52] <CardinalFang> (Like 3-legged, perhaps)
[13:53] <aquarius> I don't think that's massively likely
[13:54] <aquarius> there's also a separate, slightly unkind issue here, which is that if there's another service module written, it will almost by definition not be written by us. :)
[14:00] <aquarius> hang on, I've confused myself here. The replication daemon can't look up the oauth data when it starts up, because...how does it get it?
[14:00] <aquarius> it has to authenticate to get that information
[14:01] <aquarius> so I must have to create the record with correct oauth keys in, no?
[14:03] <CardinalFang> aquarius, Yes.  It's the "desktopcouch-service".  That's where replication runs.  It does indeed try to get at the keyring.
[14:04] <aquarius> so desktopcouch-service reads the keyring to get the oauth keys for ubuntu one? it doesn't care what's actually written in the paired server record?
[14:05] <CardinalFang> aquarius, I think so.
[14:05] <aquarius> then I shall pass in an oauth_data dictionary with { "consumer_key": "stored in keyring", ... } I think
[14:06] <CardinalFang> aquarius, Er, that's evil.
[14:06] <aquarius> what's your preferred non-evil solution? :)
[14:06] <CardinalFang> Is  None  legal?
[14:06] <aquarius> you'd rather have null stored in the record than "stored in keyring"?
[14:07] <CardinalFang> than a string with a description for some human to read?  Yes.
[14:07] <aquarius> then we disagree :-)
[14:07] <aquarius> storing a string makes the record sorta self-documenting
[14:08] <aquarius> storing null makes people who see the record think: what's the point of storing nulls here? and then they have to rtfs to find out that we look in the keyring for that data
[14:08] <CardinalFang> aquarius, Just update the API for the function so it doesn't store anything.
[14:08] <aquarius> ah. the reason I'd rather not do that is that it makes U1 paired-server records different from other paired-server records.
[14:09] <CardinalFang> I fail to see how you can be okay with passing in a nonsensical value, then.
[14:10] <aquarius> I'm not really OK with it; really, I think that the oauth data should actually be stored in the record. But this is complicated by how dc-replication is not the only user of that data, hence it being in the keyring
[14:11] <CardinalFang> aquarius, Okay, let's do the sensible thing, then.  I'll rip out the extra look-up of data from the keyring, which is terrible already, and you pass in valid oauth data.
[14:12] <aquarius> hm, hang on, now I've thought that up, it's wrong
[14:12] <aquarius> because you *have* to hit the keyring, in case the oauth credentials have changed :(
[14:12] <aquarius> damn
[14:13] <aquarius> so much for my argument
[14:13] <aquarius> so, you need to hit the keyring for it.
[14:13] <CardinalFang> Then we have to change what the record structure.
[14:13] <aquarius> so you want u1 paired-server records to not contain oauth_data at all, yes?
[14:14] <CardinalFang> Yes.  I want oauth items to be optional.
[14:14] <aquarius> OK.
[14:19] <aquarius> right, done that, pushing branch now
[14:20] <aquarius> and submitted for revierw
[14:21] <urbanape> good lord, how hard can this be?
[14:22]  * urbanape rages (but just a little)
[14:22] <aquarius> urbanape, finding out which profile is currently running?
[14:25] <CardinalFang> urbanape, You know you're going to find out it's a simple whoami() or something, right?
[14:26] <aquarius> CardinalFang, am I right in thinking that desktopcouch-tools will be installed by default?
[14:28] <CardinalFang> aquarius, no.  It's likely it will not.  That's why you're making u1 replication default.  No additional install for user to make all of Ubuntu One work.
[14:28] <aquarius> oh
[14:28] <aquarius> so, then, I can't call couchdb_io.py
[14:28] <aquarius> because they won't have it
[14:28] <aquarius> I have to duplicate the functionality of it/
[14:28] <aquarius> ?
[14:28] <aquarius> that's a bit rubbish.
[14:29] <CardinalFang> Er, I think it should be in there.  That shouldn't be desktopcouch-tools .
[14:30] <aquarius> so what is in desktopcouch-tools then?
[14:30] <aquarius> bin/desktopcouch-pair is, afaik -- but all the pairing tools' *libraries* are in desktopcouch?
[14:31] <aquarius> i don't know how to work out an answer to this question, because all the packaging stuff doesn't live in the source tree, it lives elsewhere
[14:31] <CardinalFang> I will have to find out.  This is worrying.
[14:31] <CardinalFang> It's in a different project.
[14:47] <urbanape> aquarius, CardinalFang, yes.
[14:47] <urbanape> I added a comment here: https://code.launchpad.net/~urbanape/bindwood/handle-all-profiles/+merge/11891
[14:47] <urbanape> the only reliable way to make this work (as it's currently coded) is to use the profile manager exclusively.
[14:56] <jblount> urbanape: Have you seen any of those weird interface pauses since reverting your laptop?
[14:57] <joshuahoover> dobey: are there different emblems for files in different sync states? (completely synced, actively synced, etc.) i've only seen the one with the clouds and the up arrow and it appears to stay on the file permanently once it's synced
[14:57] <CardinalFang> Karmic just ate my machine.  Some kind of interface problem.
[14:58] <dobey> joshuahoover: there's upload and download currently
[14:58] <joshuahoover> dobey: have you seen it where the upload stays there after syncing?
[14:59] <dobey> joshuahoover: not personally, but i think the branch i did yesterday fixes the problem
[14:59] <dobey> joshuahoover: i found a typo in the code that might cause that
[14:59] <joshuahoover> dobey: ah, got ya
[15:02] <urbanape> jblount: nope
[15:04] <jblount> urbanape: What happens next week when both our machines blow up? ;)
[15:05] <jblount> MEETING BEGINS
[15:05] <jblount> me
[15:05] <rodrigo_> me
[15:05] <vds> me
[15:05] <aquarius> me
[15:05] <CardinalFang> me
[15:06] <dobey> me
[15:06] <jblount> DONE: Fixing dev envrionment
[15:06] <jblount> TODO: Finish fixing, review, packing for London next week
[15:06] <jblount> BLOCKED: Nope
[15:06]  * jblount high-fives rodrigo_ 
[15:06] <rodrigo_> • DONE: Submitted new tomboy fixes branch. Submitted package with patch to create an U1 addressbook in evo-couchdb by default. Submitted branch for IM addresses manipulation in couchdb-glib
[15:06] <rodrigo_> • TODO: Start upstream discussion for adding social services accounts config to about-me. Talk to Ara about writing mago tests for evo-couchdb. Propose couchdb-glib/evo-couchdb for GNOME 2.29. Store UUIDs for postal addresses. Conflict resolver tool in pair tool. Look at becoming a MOTU (https://wiki.ubuntu.com/UbuntuDevelopers). openSUSE/Fedora packaging with aquarius. Notes web UI.
[15:06] <rodrigo_> • BLOCKED: no
[15:06] <rodrigo_> vai vds
[15:07] <vds> DONE:still investigating quota and replication on couchdb, fixed development machine in troubles after last karmic update
[15:07] <vds> TODO: continue to investigate, on call review
[15:07] <vds> BLOCKED:
[15:07] <vds> aquarius: all yours
[15:07] <aquarius> ⚀ DONE:  tiny branch to fix problem in desktopcouch-pair; allow cloud paired-server records to not contain oauth data
[15:07] <aquarius> ⚁ TODO:  fix UnknownLoginError and make it be known (bug #376087); make starting up filesharing also add desktopcouch pairing (bug #430782)
[15:07] <aquarius> ⚂ BLOCKED:
[15:07] <aquarius> ⚃ BUG COUNT:https://bugs.edge.launchpad.net/~sil/+assignedbugs?field.tag=ubuntuone-karmic - 2
[15:07] <aquarius> CardinalFang: you are hereby charged with committing heresy against the Holy Church
[15:07] <dobey> (ze bots are why i don't put 'bug' in front of the numbers)
[15:07] <CardinalFang> DONE: packaging work.  some work on compacting and replication
[15:07] <CardinalFang> TODO: fix same-file error in couchdb{,-bin}.  Dependency problem, maybe?
[15:07] <CardinalFang> BLOCKED: Broken machine.
[15:08] <aquarius> dobey, clever.
[15:08] <CardinalFang> dobey, too clever!  Your turn.
[15:08] <dobey> ☺ DONE: Bug triage, #429482, Started #381012
[15:08] <dobey> ☹ TODO: Reviews, Finish #381012, #374890
[15:08] <dobey> ☹ BLCK: None.
[15:08] <urbanape> me
[15:09] <urbanape> woops
[15:09] <aquarius> dobey, flaw with your way is: I have no idea what you're working on ;)
[15:09] <CardinalFang> Woo!  Maybe my machine works now.
[15:10] <dobey> aquarius: you have to open the bugs either way
[15:10] <urbanape> DONE: Tried to wrangle some info out of Firefox devs about profiles
[15:10] <urbanape> TODO: One last Bindwood branch that will use timestamps to further reduce the amount of network traffic and work when pulling bookmarks.
[15:10] <urbanape> BLOCK: None
[15:10] <dobey> aquarius: a lot of times the summary isn't particularly useful anyway :)
[15:10] <aquarius> urbanape, are you putting ?since on the URLs?
[15:10] <aquarius> dobey, good point. :)
[15:10] <urbanape> aquarius, not that I know of
[15:10] <aquarius> urbanape, ah, I thought that's what you meant by timestamps :)
[15:11] <urbanape> I was thinking along the lines of "get boomarks that are newer than <last time I polled>"
[15:11] <urbanape> until we actually have the changes feed working
[15:11] <aquarius> _changes does work, doesn't it?
[15:11] <urbanape> as it stands, we still iterate over all bookmarks.
[15:11] <urbanape> *shrug*?
[15:12] <aquarius> it had better do ;)
[15:12] <urbanape> documentation somewhere?
[15:14] <aquarius> http://jchrisa.net/drl/_design/sofa/_show/post/Simple-Wins
[15:14] <aquarius> has some stuff about it
[15:16]  * aquarius is still unskypeable :(
[15:16] <aquarius> oops
[15:37] <dobey> CardinalFang, kenvandine: where exactly /is/ the src pkg branch for desktopcouch?
[15:38] <kenvandine> i don't know for sure... it is the new fangled source package branch stuff
[15:38] <kenvandine> lp:ubuntu/desktopcouch
[15:38] <kenvandine> or something
[15:38] <kenvandine> as well use under the control tower as desktopcouch/spb
[15:38] <kenvandine> something like that
[15:39] <dobey> ah ok
[15:39] <dobey> kenvandine: i guess you need to propose your branch for merging into lp:~ubuntuone-control-tower/ubuntu/karmic/desktopcouch/spb then, rather than lp:desktopcouch
[15:40] <dobey> though i've no idea why it is stacked on lp:desktopcouch in the first place
[15:40] <kenvandine> i guess... i don't really know :)
[15:40] <kenvandine> well
[15:40] <kenvandine> i pulled from lp:~ubuntuone-control-tower/ubuntu/karmic/desktopcouch/spb th
[15:40] <dobey> weird
[15:40] <kenvandine> and it got me lp:desktopcouch
[15:41] <kenvandine> and when i proposed it... i put in lp:~ubuntuone-control-tower/ubuntu/karmic/desktopcouch/spb
[15:41] <dobey> lp:desktopcouch doesn't have a debian/ dir... or any of the revisions in your branch :)
[15:41] <kenvandine> and LP converted it
[15:41] <kenvandine> so freaking weird
[15:41] <dobey> kenvandine: you just typed it, or you also clicked the radio button?
[15:41] <kenvandine> anyway... statik already handled it
[15:41] <kenvandine> typed it
[15:41] <kenvandine> copy/paste
[15:41] <kenvandine> and hit search
[15:41] <dobey> ah you probaably had the default radio button selected still
[15:41] <kenvandine> you can just obsolete that merge proposal
[15:41] <kenvandine> nope
[15:41] <dobey> well i rejected it
[15:42] <kenvandine> i did it twice... cause it confused me
[15:42] <dobey> weird
[15:42] <kenvandine> and it kept converting it
[15:42] <kenvandine> so i assume LP was smarter than me :)
[15:42] <dobey> that sounds like a pretty serious lp bug
[15:49] <urbanape> finally tracked down the right guy to get the right answer
[15:50] <aquarius> nice! and the answer is...?
[15:50] <dobey> 42
[15:51] <aquarius> call the undocumented function whichSoddingProfileAmI()
[15:57] <urbanape> *sigh*, no.
[15:57] <urbanape> best they can offer me is the profile directory.
[15:57] <urbanape> which is pretty much guaranteed to be different across different machines, even with the same "name"
[15:58] <urbanape> iX945de.default
[15:58] <urbanape> f'rex.
[15:58] <urbanape> the reasoning is thus: Profile Manager is likely to go away in the future, don't put too much stock in it, and besides, there's always the degenerate case of users who just use a random directory as a profile.
[15:58] <urbanape> without a name.
[16:00] <CardinalFang> dobey,  lp:ubuntu/desktopcouch
[16:02] <dobey> i'm guessing you mean lp:ubuntu/karmic/desktopcouch/trunk (which is what i think it actually is for 'official' ubuntu source package branches, no?)
[16:02] <dobey> but it looks like we have one separate from that which we maintain
[16:03] <dobey> otherwise i don't think kenvandine would have bothered with the merge proposal
[16:37] <aquarius> OK, off to pick up my daughter. Back in a few hours
[16:58] <joshuahoover> dobey: on the blurry icon, i was thinking of the notification icon...my bad
[16:59]  * CardinalFang thrashes grub.
[17:17] <dobey> joshuahoover: no worries. i already fixed the notification icon issue
[17:20] <urbanape> dobey or CardinalFang or Chipaca: can I get one of you to merge lp:~urbanape/bindwood/complete-sync to lp:bindwood via tarmac?
[17:21] <dobey> does bindwood have some neat testing thing i need to run?
[17:21] <urbanape> nopers.
[17:22] <dobey> urbanape: you need to set the commit message
[17:22] <urbanape> oh, right
[17:24] <dobey> crikey
[17:24] <urbanape> done
[17:25] <dobey> that's a commit novel
[17:26] <dobey> not into the whole brevity thing?
[17:26] <CardinalFang> "el duderino"
[17:36] <urbanape> I changed it
[17:38] <urbanape> resubmitting deleted-view
[17:46] <urbanape> and I'm going to yank the other two until this one lands.
[17:47] <urbanape> no sense in propagating these big dumb diffs.
[18:39] <CardinalFang> Wow, booting a degraded MD raid could use some work.
[18:44] <urbanape> woohoo
[18:59] <urbanape> Okay, I'm done mucking with this branch now. Anyone who wants to test some new Bindwood behavior, please lemme know.
[19:20] <benoitc> mmm I'm curious about the failover system used by ubuntuone for couchdb
[19:20] <benoitc> do uyou use nly relication ?
[19:24] <Chipaca__> ooohh, we have a failover system?
[19:26] <benoitc> dunno :)
[19:26] <benoitc> I supposed ubunone had one
[20:29] <urbanape> @reviewers
[21:01]  * BlackFate away
[22:19] <malapetsasc> hi I need a help to ad my computer in ubuntu one cliend the applet dont work and the client cant conect
[22:20] <_marx_> malapetsasc: jaunty?
[22:21] <malapetsasc> I have run all the upgrade for carmic
[22:22] <_marx_> hum well adding machines has worked for me w/jaunty and karmic but there are sync probs
[22:22] <malapetsasc> the problemme is that cant ab my computer
[22:23] <malapetsasc> jast run the client and nothing els
[22:25] <_marx_> can you find the client version? or i should say do you know how to find the client version
[22:26] <malapetsasc> no i dont know how
[22:26] <_marx_> ok, "apt-cache show ubuntuone-client" is one way
[22:27] <malapetsasc> Package: ubuntuone-client
[22:27] <malapetsasc> Source: ubuntuone-client
[22:27] <malapetsasc> Priority: optional
[22:27] <malapetsasc> Section: net
[22:27] <malapetsasc> Installed-Size: 460
[22:27] <malapetsasc> Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[22:27] <malapetsasc> Architecture: all
[22:27] <malapetsasc> Version: 0.95.0+r213-0ubuntu1~ppa2~jaunty
[22:27] <malapetsasc> Replaces: nautilus-ubuntuone, ubuntuone-oauth-login, ubuntuone-storagefs
[22:27] <malapetsasc> Depends: python-ubuntuone-client (= 0.95.0+r213-0ubuntu1~ppa2~jaunty), python-configglue, python-apport
[22:27] <malapetsasc> Conflicts: nautilus-ubuntuone, ubuntuone-oauth-login, ubuntuone-storagefs
[22:28] <malapetsasc> Filename: pool/main/u/ubuntuone-client/ubuntuone-client_0.95.0+r213-0ubuntu1~ppa2~jaunty_all.deb
[22:28] <malapetsasc> Size: 35944
[22:28] <malapetsasc> MD5sum: d4001baf9e12801aa07b21d24ae20a5f
[22:28] <malapetsasc> SHA1: e8f3577dd5c9059ef6bc17526ef6b1339a669270
[22:28] <malapetsasc> Description: Ubuntu One client
[22:28] <malapetsasc>  Ubuntu One is a suite of on-line services. This package contains the
[22:28] <malapetsasc>  synchronization daemon for the Ubuntu One file sharing service.
[22:29] <_marx_> well too much information, only the version line was needed, you are out of date...
[22:29] <_marx_> so do an update and dist-upgrade
[22:29] <_marx_> need the commands?
[22:30] <malapetsasc> yes if you can
[22:30] <_marx_> sudo apt-get update && sudo apt-get dist-upgrade
[22:32]  * _marx_ version is now 0.95.1
[22:32] <_marx_> upgraded moments ago
[22:32] <malapetsasc> thanks i will try with this
[22:34] <malapetsasc> sudo apt-get -d
[22:34] <malapetsasc> dont make  upgrage
[22:35] <malapetsasc> i try to foung the new version in .deb
[22:36] <malapetsasc> thanks anyway for your time
[22:37] <dobey> malapetsasc: do you have an ~/.cache/ubuntuone/log/oauth-login.log?
[22:42] <malapetsasc> gedit ~/.cache/ubuntuone/log/oauth-login.log?is empty
[22:43] <dobey> malapetsasc: get rid of the question mark on the end :)
[22:45] <_marx_> well apt-get -d doesn't do anything
[22:47] <_marx_> Version: 0.95.0+r213-0ubuntu1~ppa2~jaunty and that's a jaunty version
[22:47] <malapetsasc> I have reinstall the pakage ubuntuone-client-gnome_0.95.1-0ubuntu1_i386.deb
[22:47] <malapetsasc> but the same probleme
[22:48] <dobey> malapetsasc: i need to know what's in your ~/.cache/ubuntuone/log/oauth-login.log to be able to tell you anything useful :)
[22:50] <malapetsasc> 2009-09-18 23:38:19,250:250.381946564 UbuntuOne.OAuthDesktop.main Creating a LoginProcessor
[22:50] <malapetsasc> 2009-09-18 23:38:19,252:252.716064453 UbuntuOne.OAuthDesktop.main Hooking libnotify
[22:50] <malapetsasc> 2009-09-18 23:38:19,255:255.583047867 UbuntuOne.OAuthDesktop.main Getting configuration
[22:50] <malapetsasc> 2009-09-18 23:38:19,269:269.762992859 UbuntuOne.OAuthDesktop.main Login D-Bus service starting up
[22:50] <malapetsasc> 2009-09-18 23:38:19,270:270.42889595 UbuntuOne.Client.Applet Starting Ubuntu One client version 0.95.1
[22:50] <malapetsasc> 2009-09-18 23:38:20,144:144.663095474 UbuntuOne.OAuthDesktop.main maybe_login() D-Bus message received with realm='https://ubuntuone.com', consumer_key='ubuntuone'
[22:50] <malapetsasc> 2009-09-18 23:38:20,144:144.906044006 UbuntuOne.OAuthDesktop.main Initiating OAuth login in LoginProcessor
[22:50] <malapetsasc> 2009-09-18 23:38:20,145:145.028114319 UbuntuOne.OAuthDesktop.main Obtaining OAuth urls
[22:50] <malapetsasc> 2009-09-18 23:38:20,145:145.140886307 UbuntuOne.OAuthDesktop.main Fetching config URLs for realm='https://ubuntuone.com'
[22:50] <malapetsasc> 2009-09-18 23:38:20,145:145.335912704 UbuntuOne.OAuthDesktop.main Realm 'https://ubuntuone.com' is not in config
[22:50] <malapetsasc> 2009-09-18 23:38:20,145:145.623922348 UbuntuOne.OAuthDesktop.main OAuth URLs are: request='https://ubuntuone.com/oauth/request/', userauth='https://ubuntuone.com/oauth/authorize/', access='https://ubuntuone.com/oauth/access/', secret='hammertime'
[22:50] <malapetsasc> 2009-09-18 23:38:20,496:496.006965637 UbuntuOne.OAuthDesktop.auth auth.AuthorisationClient created with parameters realm='https://ubuntuone.com', request_token_url='https://ubuntuone.com/oauth/request/', user_authorisation_url='https://ubuntuone.com/oauth/authorize/',access_token_url='https://ubuntuone.com/oauth/access/', consumer_key='ubuntuone', callback_parent='<bound method LoginProcessor.got_token of <ubuntuone.oauthdesktop.main.LoginProcess
[22:50] <malapetsasc> or instance at 0xa5e354c>>'
[22:50] <malapetsasc> 2009-09-18 23:38:20,496:496.146917343 UbuntuOne.OAuthDesktop.main Calling auth.client.ensure_access_token in thread
[22:50] <malapetsasc> 2009-09-18 23:38:20,504:504.049062729 UbuntuOne.OAuthDesktop.auth Trying to fetch the token from the keyring
[22:50] <malapetsasc> 2009-09-18 23:38:20,537:537.916898727 Ubu
[22:51] <dobey> eep
[22:51] <dobey> pastebin.ubuntu.com is your friend :)
[22:52] <dobey> malapetsasc: please pastebin it
[22:52] <malapetsasc> I have jast a month with ubuntu and linux
[22:53] <malapetsasc> then I dont know much from all this
[22:53] <dobey> malapetsasc: go to http://pastebin.ubuntu.com/ and paste the contents of the file in the text area there, and click "Paste!"
[22:54] <dobey> malapetsasc: then it should give you a new URL, and you can copy/paste just that url in the channel
[22:54] <dobey> so you won't flood the channel with the log file info :)
[22:55] <malapetsasc> ok sorry i dont know that
[22:57] <malapetsasc> http://pastebin.ubuntu.com/273803/
[22:58] <malapetsasc> is it rightnow??
[23:01] <dobey> thanks
[23:02] <dobey> it looks like your browser configuration is wrong
[23:02] <dobey> i don't know greek though
[23:02] <dobey> Σφάλμα εμφάνισης  url: Αποτυχία εκτέλεσης θυγατρικής διεργασίας "/home/christos/Επιφάνεια" (No such file or directory)
[23:02] <dobey> that is your problem :)
[23:02] <dobey> malapetsasc: you didn't get an error dialog with that?
[23:03] <joshuahoover> dobey: that's one of the few languages you don't read/speak, right? ;)
[23:03] <dobey> currently, yes :)
[23:04]  * _marx_ has long ago forgotten his new testement greek
[23:04] <malapetsasc> the write  that can found  mh desktop
[23:04] <dobey> malapetsasc: right
[23:05] <dobey> malapetsasc: if you run gnome-default-applications-properties what does it say for your "Web Browser" being set to?
[23:06] <_marx_> dobey: his client version isn't current
[23:06] <dobey> _marx_: eh?
[23:07] <dobey> _marx_: looks new enough to me
[23:07] <dobey> _marx_: the problem is that his browser is defined to be something in his home directory, which doesn't exist
[23:09] <malapetsasc> ok I have fix it and work
[23:09] <_marx_> well maybe i'm behind
[23:10] <malapetsasc> in gnome aplication properties I have put firefox by default browsser
[23:11] <malapetsasc> now its open the page and workig as well
[23:12] <_marx_> oofta, no his version is the same I have on jaunty
[23:12] <_marx_> but not karmic
[23:12] <malapetsasc> thanks gays
[23:13]  * _marx_ rolls on the floor
[23:16] <dobey> sure malapetsasc
[23:16] <dobey> glad it's working for you :)
[23:18] <malapetsasc>  dobey you know greek??
[23:23] <malapetsasc> nice to meet you... have a nice day buy :-))