=== solka` is now known as solka === Tehfoe is now known as Darkfoe [11:59] dobey, ping [13:12] any way to trigger replication between two local desktopcouch ? [13:12] both of them are running, I paired, I see the pairing records, but no replication is happening [13:19] hi all [13:34] Must I use Nautilus to use U1? Can I do it from the command line? [14:05] <]pablo[> is it possible to use Ubuntu One on Debian? [14:06] <]pablo[> i.e. is there a .deb for debian with the ubuntuone-client? [15:40] what triggers a desktopcouch to switch to listen on its public ip instead of localhost ? [18:41] CardinalFang: Hello, hope holidays were ok, did you guys looked at adding attachments to the API? [18:43] mandel, Hi! [18:43] I have a branch with half of it implemented. [18:44] I wanted to understand it better before I make an API that can not change. [18:45] CardinalFang: great, well, I don't want to to work during the weekend I'll bother you with it during the week :P [18:45] mandel, I can have something for you to review in ~27 hours. I'll work on it Monday morning. [18:45] how long are u going to stay around, do you mind giving a go to my app in about 30 min (fighting with quickly package right now) [18:48] mandel, I expect to go offline soon. If you email me a link, then I'll look later. [18:49] CardinalFang: ok, thanks again [18:50] mandel, de nada. [18:53] homeasvs, is the question about IP address still actual? [18:53] * rtgz looks at irc logs and can't find them for today, 2009-11-29 [18:54] ubuntulog, any ideas? [19:32] Hi! I have a problem upgrading Ubuntu One. The payment fails, even though I tried two different cards. [19:57] Your Payment Failed [19:57] Payment Information [19:57] * Payment: ERROR [19:57] # [19:57] # Order Id: xxxxxxxxxxxxxxxxxx [19:59] OH .. now I managed to pay! [20:11] GnuBee, I belive that you might not be able to get any info regarding your issue at the moment, since all developers seem to be away. You may have better luck on Monday. However, I advise you to create a bug report ( https://bugs.launchpad.net/ubuntuone-servers/+filebug ) describing the problem in all details including any info you may get from your bank (in case transaction was declined by the bank itself). [20:12] * rtgz thanks his ISP for breaking the PPP connection right when the final parenthesis was printed... [20:22] HTTP Error 503 Service Temporarily Unavailable for files.one.ubuntu.com. Is it maintenance downtime or capacity problems? === rtgz_ is now known as rtg === rtg is now known as rtgz [21:50] hello, is the server experiencing some problems? I've got some important documents stored in Ubuntu One, but they don't get synced locally [21:50] additionally, i'm getting a 503 error if I try to retrieve them via web interface [21:55] please help, this may turn into a disaster :-) [21:55] i've to edit my thesis work before submitting it [22:07] CardinalFang, ping [22:09] hm, I think I'm seeing the same as tchernobog [22:10] homeasvs, the file sync seems to work fine atm, just updated a file via the client, but the web interface is working until one tries to download the files [22:19] rtgz, I'm having 503's when replicating couchdb stuff [22:30] homeasvs, just tested the server-client replication - works fine here. [22:46] still getting a 503 error, and sync not working... anyone knows what's happening to Ubuntu servers? [22:49] tchernobog, are you using ubuntuone sync client or web interface only? [22:50] tchernobog, it looks like there are no developers in this channel at the moment, though. [22:53] rtgz: i'm trying both [22:53] none works [22:56] tchernobog, sorry, got disconnected, did not receive any reply here, so what are you using to connect to u1, is it a client or web interface only ? [22:59] both [23:00] none of them works [23:01] tchernobog, strange, 'cause the client works here as far as I can tell. However this needs some investigation. Could you perform some diagnostic steps? [23:01] yes, please tell [23:01] tchernobog, first, quit the client via cloud/right click/quit [23:02] tchernobog, then remove the logs from previous runs, this will give us the clear state. the logs are in ~/.cache/ubuntuone/logs [23:02] tchernobog, ~/.cache/ubuntuone/log [23:02] done [23:03] tchernobog, now try to start ubuntuone-client-applet from the terminal [23:03] yes [23:03] ouch [23:04] tchernobog, if it says something, please copy-paste here [23:04] i will use a pastebin [23:04] so i don't spam here [23:04] tchernobog, okay [23:05] http://pastebin.com/d60ae709 [23:06] tchernobog, o_O... okay, need to test some assumptions here, stay tuned [23:06] i'd be happy for it to work via web, too [23:06] i just need to download an .odt file :-| [23:10] tchernobog, okay, the good news is that auth server is working fine so this does not seem to be _that_ server-side issue. [23:11] yep, i last used the client to upload files on friday on this particular machine [23:11] it went fine [23:11] tchernobog, wait, this is something wrong with client-side couchdb [23:12] yes, i was just guessing that [23:12] i'd like to know what's bad with it [23:12] s/bad/wrong/g [23:12] tchernobog, the thing is that couchdb is not related to file sync at all, but it is now blocking it as well. let's debug this [23:13] tchernobog, open seahorse and navigate to the 'login' keyring [23:14] yes [23:14] tchernobog, do you see the entries "Desktop Couch user authentication" ? [23:14] yes, there are two [23:14] tchernobog, there may be several of them [23:16] one is 'oauth' and one is 'basic' [23:16] for desktopcouch [23:17] tchernobog, okay, since we need a quick solution, try to remove the Desktop Couch user auth keys. They will be recreated when needed and desktopcouch will reinitialize your local installation. [23:17] rtgz_, the data will not be affected since desktopcouch will rewrite the configuration for the database only. [23:18] i deleted them [23:18] however trying to exit the applet and re-opening it shows the same error [23:19] tchernobog, then try to start the applet again. 401 means that local couch db is rejection your access as unauthorized, but this does not make sense to me at the moment since the only way to alter auth credentials is to remove them and create the invalid ones. [23:19] doesn't get to that [23:20] i've got ACCEPT all 127.0.0.1 in my fw rules, before anyone asks [23:20] tchernobog, okay, the firewall does not seem to be an issue, since this is HTTP auth error [23:21] tchernobog, okay, trying to restart the desktopcouch - /usr/lib/desktopcouch/desktopcouch-stop [23:21] tchernobog, then try to start it with /usr/lib/desktopcouch/desktopcouch-service in the terminal. [23:22] ouch. [23:22] it crashes [23:22] tchernobog, who where when how? [23:22] couchdb.client.PreconditionFailed: ('file_exists', 'The database could not be created, the file already exists.') [23:22] sorry, i mean: [23:22] the service goes up [23:23] but it gives me a traceback [23:23] and that error [23:23] tchernobog, is it a proper exception, can you pastebin it completely? [23:23] tchernobog, it looks waaay too wrong to me [23:23] i believe it is: http://pastebin.com/d5f604b9c [23:24] tchernobog: Sorry to interrupt, but the web interface does not 503 for me anymore (it did some minutes ago) [23:24] thanks kjoller, that could be my last hope :-D [23:25] You should still get the local couch fixed at some point. [23:25] kjoller: of course [23:25] but for now my priority falls towards getting my BhD [23:26] kjoller, yes, thank you, 'cause I am too couchdb-fix-it-right-now at the moment :) [23:26] yay! got the file from the web [23:27] rtgz_, i can still debug a little if you want [23:27] hurrah! [23:28] rtgz_: i'm trying having a look at http://localhost:59623/_utils/index.html [23:28] looks pretty empty to me [23:28] tchernobog, does the futon work for you, do you see the management database? [23:28] there's just a document under users [23:29] _design/_auth [23:29] i'm running the test suite, who knows [23:29] maybe it's useful [23:30] tchernobog, do you see the 'management' database, this should be seen in the Overview page? [23:30] yes, but it's empty [23:31] tchernobog, okaaay, it is completely empty, right?.. [23:31] tchernobog, then... remove it :) [23:31] just a moment, it's still running the tests [23:31] tchernobog, check the number of documents, it MUST be 0 [23:31] some fail [23:31] it is 0 [23:31] tchernobog, okay, then we don't lose much data [23:32] the config test fails with: # Assertion failed: config.httpd.port == port [23:32] other tests failing are oauth and replication [23:33] i've deleted the management database [23:33] tchernobog, yes, this is ok, since the config lists port as 0, and couchdb is running on a random port, however I guess we would expect it to pass the built-in tests, though... oauth and replication - yes. no data for them so they cannot work [23:33] ok [23:33] tchernobog, okay, now try to stop the database [23:33] and start it again [23:34] done [23:34] * rtgz_ thinks that it reminds him of windows-like troubleshooting... [23:34] i got the same error on the console; the management database was re-created and is empty [23:34] tchernobog, it should not spit any errors now, since it should be able to create that 'management' database [23:34] tchernobog, grrr [23:35] don't growl at me, i ain't couchdb :-) [23:35] tchernobog, couchdb is not in this channel, unfortunately... [23:36] tchernobog, can you do "ps aux | grep couch" ? [23:36] just a moment [23:36] i've restarted the applet [23:36] and it's syncing [23:36] tchernobog, O_O [23:36] perhaps, errors notwithstanding [23:37] it *was* a server-side issue [23:37] tchernobog, yep, but the server was the 'local' one which was giving the errors... hmmmmmmm [23:37] i'm not saying that my couchdb instance is in any way healthy... [23:38] tchernobog, can you check the management database? [23:38] but maybe it works with some magical fallback [23:38] yes [23:38] it has now three documents [23:38] tchernobog, heh [23:38] after the sync [23:38] tchernobog, this explains such behavior [23:38] is it? [23:38] i'm not getting it :-| [23:39] tchernobog, the management database was filled with data because the applet was able to write to it because we removed the couchdb user secret from keyring. [23:40] tchernobog, and you removed the management database and the service startup created new credentials [23:40] ah [23:40] tchernobog, however this is a mess [23:40] this may relate to a problem i got some time ago... [23:40] i was a paying subscriber of the beta [23:40] tchernobog, so now your couchdb is happily replicating [23:41] but then i went back being a normal subscriber [23:41] don't know what happened [23:42] the month after it, i wasn't billed on my CC, so i believe it was ok [23:42] tchernobog, I am still a 2Gb free user, periodically testing the client side just for experience with python :) [23:43] i'm willing to pass to the paying subscription, because it's cheap and i love founding further development [23:43] but i'm waiting to see it run without all these problems [23:44] tchernobog, will switch to the paid subscription once I find > 2Gb of files worth such kind of backup. [23:44] it's a couple of weeks i last nuked the ubuntuone directories in my home [23:44] to have it start working [23:44] i'd love to have the evo contacts thing working, too... [23:45] but it says couchdb plays the ass, here [23:45] tchernobog, I've written a diagnostic script that contains check for the known problems so that it is not that frustrating. Will see what the developers will say about this tomorrow/later today. [23:45] ass -> the animal, not the body part [23:45] whoah, you're nice :-) [23:45] my kudos [23:46] tchernobog, huh? How does it play that? Cause I got mine first working without much problem [23:46] * rtgz_ tries to forget how he tried to break this afterwards, broke that and spent some evening fixing that... [23:46] says cannot authenticate to the desktop couchdb instance [23:46] never worked, in these months [23:47] tchernobog, hm, this is embarassing (as firefox 3.5 says), do you want to fix it? (I promise, will not ask to delete your contacts database) [23:48] that would be quite painful, indeed :-) [23:48] let's try [23:48] i'm trying to see if evolution says something on the console [23:49] evolution pops up an error message saying that the addressbook doesn't exist [23:49] nothing on the console [23:49] tchernobog, it may not say much, since the daemon is sending everything to... possibly nowhere. Try this: https://wiki.ubuntu.com/UbuntuOne/Bugs#Getting%20debug%20info [23:50] tchernobog, okay, this is familiar (about addressbook doesn't exists). Let's see what I can get with a connected data server... [23:51] huh? now that i got evolution-data-server killed and restarted, it's not giving me the error [23:51] nevertheless, it's not giving me any contact too [23:51] i've manually inserted a couple on the web [23:52] tchernobog, evolution data server should print something to the terminal or to the log file if you redirected it [23:53] mostly a bunch of (process:14079): Json-CRITICAL **: json_object_get_object_member: assertion `node != NULL' failed [23:53] let me see the error log [23:54] http://pastebin.com/d5dc602a8 [23:54] tchernobog, do you see something starting from liboauth .. [23:54] here it shows also the records retrieved from online [23:55] i mean, the three-four contacts I inputted via web interface [23:55] sign that it's trying to sync correctly [23:55] tchernobog, the contacts are already in your database, this is good [23:55] can you open the addressbook view in Evolution? [23:56] i'm already there [23:56] they don't show up [23:56] i've also tried to copy a contact from evolution -> couchdb [23:56] 'cause I don't see any assertions. You mean that you have CouchDB addressbook and it is empty [23:57] try to quit evolution and start it again, switch to Addressbook view again and note any error messages you might get [23:58] wtf? now they're here [23:58] this doesn't make much sense [23:58] tchernobog, the copy might not work because the database is not 'connected'.. [23:58] tchernobog, thanks for flying UbuntuOne airlines... [23:59] this will have me scratching my head for a bit [23:59] if it's a syncing service [23:59] I shouldn't be required to kill e-d-s to see new data, right?