[02:03] <duanedesign> evening U1inites :)
[02:08] <ajmitch> afternoon
[02:08] <duanedesign> ajmitch: did your music get downloaded?
[02:08] <ajmitch> sure
[02:09] <ajmitch> all it really took was u1sdtool -q
[02:09] <ajmitch> telling it to disconnect & reconnect wasn't enough for it
[02:09] <duanedesign> ajmitch: good you got it
[02:09] <ajmitch> rhythmbox restarted the syncdaemon, the music finished downloading
[02:09] <duanedesign> ahhh
[02:09] <ajmitch> I'll see if I can fetch the relavant log if it's useful
[02:10] <duanedesign> was this the disconnect/reconnect in the Ubuntu One Preferences Panel, under Devices tab
[02:10] <ajmitch> no, with u1sdtool
[02:10] <ajmitch> as I was watching syncdaemon.log :)
[02:11] <duanedesign> ajmitch: weird. So it had to be auto-started by Rhythmbox
[02:12] <ajmitch> what's weird is that it downloaded 9 of the 10 songs of the album & stalled at 0.8MB on the last one
[03:58]  * huntz0r is away: I'm busy
[04:01] <hallyn> chatting elsewhere about Ubuntu One, it occurred to me that I'd be more likely to store music there if I coudl specify priorities - "download this (smaller, but important) stuff first when I sync a new machine".  Then music can d/l later.  Is that being considered?
[04:23] <Chipaca> hallyn: you can do that now
[04:23] <Chipaca> hallyn: not super user friendly-ly
[04:24] <duanedesign> you can? /me wonders how :)
[04:24] <Chipaca> hallyn: but, with u1sdtool, you can temporarily unsubscribe a user-designated folder, so if all your music is in a user-designated folder (such as the one the music store creates, or any other one), you can unsubscribe it while the important stuff syncs, and then resubscribe
[04:25] <Chipaca> subscription is a local action, so it doesn't affect your other computers synced. This is different from udf creation/deletion, which does. So take care.
[04:26] <Chipaca> duanedesign: what do you think of the submenu and the location bar now, btw?
[04:29] <hallyn> Chipaca: cool - i'll give that a shot, thanks
[04:30] <ajmitch> Chipaca: UDFs like the music folder are synced to each computer, right?
[04:31] <Chipaca> ajmitch: to each computer subscribed to the UDF, yes
[04:32] <ajmitch> is subscription to the music folder automatic?
[04:32] <ajmitch> hm, 'invalid openid transaction', that's a new one
[04:33] <ajmitch> Chipaca: why I ask is that I don't really need 500MB of music synced to each VM that I have :)
[04:33] <Chipaca> ajmitch: not sure what you mean by 'automatic'. yes or no, depending on that :)
[04:34] <duanedesign> Chipaca: i havent booted into Maverick recently, I will check that out
[04:34] <Chipaca> ajmitch: ah, yeah, default is to sync
[04:34] <Chipaca> duanedesign: thanks
[04:34] <ajmitch> I should clarify, I mean with a default desktop install with ubuntuone-client-gnome installed
[04:35] <Chipaca> duanedesign: I ask because I only hear about it when it's really bad, and want to hear it also when it's merely bad :)
[04:35] <ajmitch> hah
[04:35] <duanedesign> Chipaca: been neading to boot up my Maverick install, got some packages to test..
[04:35] <ajmitch> you've been improving the nautilus widget?
[04:35] <Chipaca> there are more improvements scheduled, but yes
[04:35] <Chipaca> we won't get to do everything we would've hoped, but it should be less painful
[04:36]  * ajmitch can't really see visible improvements at the moment
[04:36] <Chipaca> ajmitch: if you sign up with an account that has a music folder, it'll download that by default, yes
[04:36] <duanedesign> Chipaca: /5
[04:36] <Chipaca> ajmitch: you should set up an account just for testing, and use that :)
[04:36] <duanedesign> oops
[04:36]  * Chipaca hopes that wasn't a password
[04:36] <ajmitch> Chipaca: right, but how should I setup multiple U1 accounts with the single ubuntu SSO login? :)
[04:37] <ajmitch> from what I know that's not allowed/supported?
[04:37] <Chipaca> ajmitch: inside the vm, use a different sso login
[04:37] <Chipaca> ajmitch: not sure I understood you correctly
[04:38] <ajmitch> that's more or less what I mean
[04:38] <ajmitch> with PPAs, you can have multiple 2GB PPAs on the one launchpad account
[04:38] <Chipaca> ah
[04:38] <ajmitch> but from what I know of U1, the U1 account is just the ubuntu single-signon account
[04:39] <Chipaca> right, no, ubuntu one subscriptions are 1:1 ubuntu one accounts, and you can only have one of these for a sso account
[04:39] <ajmitch> it's just due to me wanting to keep different kinds of files in the one place
[04:39] <Chipaca> so, yes to what you just said (more or less)
[04:40] <Chipaca> clearly i'm tired, or i would've stopped using non-contextual references in my reply
[04:40] <ajmitch> heh
[04:40] <ajmitch> or it's mid-afternoon & I'm making no sense whatsoever :)
[04:41] <Chipaca> duanedesign: no problem and no hurry. Just please ping me re that when you can, please; I want to know.
[04:42] <duanedesign> ok
[04:42] <duanedesign> brb...
[04:42] <ajmitch> ok, now I need to figure out why I can't connect in my maverick VM
[04:42]  * ajmitch hunts
[04:43] <ajmitch> Invalid request token in u1-prefs.log after going through the 'add my computer' step
[04:44] <ajmitch> ah, there's a traceback in ~/.cache/sso/oauth-login.log
[04:48] <Chipaca> the oauth-login log sucks
[04:48] <Chipaca> it has no dates :(
[04:48] <ajmitch> I suspect my problem is that I'm a release behind on ubuntu-sso-client
[04:49]  * ajmitch is patiently waiting to install updated packaged
[04:49] <ajmitch> s/packaged/packages/
[04:53] <Chipaca> ajmitch: ubuntu-sso-client isn't talking with syncdaemon just yet
[04:54] <Chipaca> ajmitch: so it shouldn't be that
[04:55] <ajmitch> so the AUTH_FAILED I'm now getting in syncdaemon.log is due to something else?
[04:56] <Chipaca> ajmitch: I hope so :)
[04:57] <ajmitch> then I'm not sure what's going wrong, since the u1 token in gnome-keyring is just new  :)
[04:57] <Chipaca> ajmitch: how did that token get into the keyring?
[04:58] <Chipaca> ajmitch: through a browser, right?
[04:58] <Chipaca> ajmitch: and not through ussoc, i mean
[04:58] <ajmitch> by trying to connect through the preferences app, which took me to the page in firefox
[04:58] <Chipaca> ah, ok
[04:59] <Chipaca> ajmitch: you're in maverick, not the nightlies, right?
[04:59] <ajmitch> yes, maverick
[05:00] <ajmitch> not all packages are up to date, but the ubuntuone-client* packages are
[05:00] <Chipaca> ajmitch: can you killall ubuntuone-syncdaemon; /usr/lib/ubuntuone-client/ubuntuone-syncdaemon --debug ?
[05:01] <Chipaca> ajmitch: then in a different terminal u1sdtool -c
[05:01] <ajmitch> sure
[05:01] <Chipaca> ajmitch: then, pastebin the bit of the log around the auth failed
[05:03] <ajmitch> http://paste.ubuntu.com/479742/
[05:04] <Chipaca> yep, you're getting auth failed
[05:04]  * Chipaca cap'n obvious
[05:04] <ajmitch> not very helpful, is it?
[05:04] <ajmitch> no more than what I saw in syncdaemon.log , anyway :)
[05:05] <ajmitch> is it worth removing the ubuntuone token from the keyring again & retrying from the preferences app?
[05:05] <Chipaca> 1 sec
[05:06] <Chipaca> ajmitch: what is the token in the keyring called?
[05:06] <ajmitch> UbuntuOne token for https://ubuntuone.com
[05:06] <ajmitch> old url?
[05:07] <Chipaca> ^C syncdaemon, remove from keyring, relaunch syncdaemon --debug, u1sdtool -c
[05:07] <ajmitch> OK
[05:08] <ajmitch> done, and giving tracebacks now
[05:08] <ajmitch> one sec, it's complaining about expired timestamp & the threshold
[05:08] <ajmitch> it *appears* that the VM clock has skewed a bit
[05:09] <ajmitch> Failure: ubuntuone.syncdaemon.main.NoAccessToken: OAuthError: Expired timestamp: given 1282103412 and now 1282104473 has a greater difference than threshold 900
[05:10] <ajmitch> is there some way this can be made more robust than looking for errors such as this?
[05:10] <ajmitch> the VM clock is out by just over 15 minutes
[05:11] <Chipaca> ajmitch: that's one weird oauth error you're hitting. Nice one.
[05:11] <ajmitch> sorry to waste so much of your time with it, I should have looked at the time there :)
[05:11] <Chipaca> no prob
[05:12] <Chipaca> but it wasn't showing that error (in the pastebin at least)
[05:12] <ajmitch> yeah, I'm surprised at that, because I'm sure that I didn't miss that much of the log
[05:12] <ajmitch> this reminds me of kerberos tickets & the fun with clock skew there
[05:14]  * ajmitch wonders what to write in a bug report for this
[05:16] <Chipaca> ajmitch: "syncdaemon not working because chipaca too sleepy"
[05:16] <Chipaca> or something
[05:16]  * Chipaca looks longingly towards the bed
[05:16] <ajmitch> your sleepiness isn't what's caused things like a clock skew error to be hidden from the user :)
[05:17] <ajmitch> I'll keep the clock as-is & take a further look at it if I get time this evening
[05:18] <ajmitch> & then I'll get around to updating the debian packages :)
[05:18] <ajmitch> thanks for your help with it
[05:22] <Chipaca>  thank you
[05:23] <Chipaca> and g'night :)
[05:23] <ajmitch> night, sleep well :)
[08:42] <mandel> good morning!! :D
[08:55] <duanedesign> mandel: good morning
[08:56] <mandel> duanedesign, morning :D
[08:57] <duanedesign> mandel: had not booted into Maverick in awhile. Booted it up just now to do some testing. The work that has been done on the nautilus extension look good.
[08:58] <mandel> duanedesign, oh, dont talk me about that... I'm working on the windows port and I have not been able tow ork on linux for far too long :(
[08:58] <mandel> duanedesign, I need to get some time to see the improvements
[09:00] <duanedesign> mandel: how is the windows port coming along?
[09:02] <mandel> duanedesign, nice, we are goign to work with the python code we have but we are writing the UI and other stuff with c#so it is as native as posible to the OS, we have done the IPC betwenn python and c# and now moving to remove the dependency on dbus and pynotify
[09:03] <duanedesign> mandel: nice.
[10:34] <mkarnicki> hi all :)
[10:36] <duanedesign> hello mkarnicki
[10:38] <mkarnicki> hi duanedesign :)
[13:28] <Chipaca> mandel: vds: ping
[13:33] <vds> Chipaca: pong
[13:35] <mandel> Chipaca, pong
[13:36] <Chipaca> vds: mandel: I've got to talk with __lucio__ about the branch some, but it looks complicated. What are you guys doing meanwhile?
[13:38] <mandel> Chipaca, I'm finishing the issue with the firewalls and it is vds who can give you more info, last I know we where between suing verteroks branch and try to merge with trunk or use __lucio__ branchs and start from scratch
[13:38] <mandel> Chipaca, from what I know verterok says is better to use what __lucio__ did
[13:39] <Chipaca> right, my question was more: are you guys blocked on this?
[13:39] <Chipaca> no matter what we do it'll take a few days, so I want to find a way for you to move forward without this, if it is blocking you that is
[13:40] <mandel> Chipaca, oh, that, well I'm not for the next days since I'm goign to use tdd to remove pynotify, I'll try to make our change pass all the same tests, but I think vds will soon be blocked by this
[13:40] <mandel> if he is not already
[13:44] <vds> Chipaca: I'm working on the ipc side with protobuf
[13:45] <vds> Chipaca: I'm not blocked in the short term
[13:46] <Chipaca> ok
[13:47] <kklimonda> what documentation on couchdb do you recommend?
[13:47] <kklimonda> i.e. books, web pages etc.
[13:48] <kklimonda> honk can someone take a look at bug 601932?
[13:48] <kklimonda> hmm.
[13:48] <kklimonda> oh, ubottu isn't here
[13:49] <vds> kklimonda: the o'reilly book?
[13:49] <kklimonda> the definitive guide?
[13:50] <Chipaca> kklimonda: the bug is re funambol, not couch, right?
[13:50] <Chipaca> https://bugs.edge.launchpad.net/ubuntuone-servers/+bug/601932
[13:50] <mandel> I though ubottu was here right? bug 608333
[13:51] <kklimonda> Chipaca: yes, the bug isn't related to my question - I've just remembered to poke someone about it again :)
[13:51] <Chipaca> kklimonda: ah. thisfred maybe?
[13:51] <mandel> meh, is not :(
[13:51] <Chipaca> kklimonda: looking at rye's comment on that bug, it might actually be couchdb and not funambol
[13:52]  * thisfred looks
[13:52] <Chipaca> ok, this connection sucks, I'm going to go back to the other one
[13:52] <Chipaca> hopefully it'll be working again
[13:52] <Chipaca> bbiab
[13:53] <thisfred> rye: do you have the full traceback of the oops? What you posted stops short of the actual error.
[13:54] <rye> thisfred, /srv/ubunet-logs/app-logs-prod/lardizabala/2010-07-07/36271-1649appserverZADGBdIHcDAFEECGFIefHCdIJHaAIeECe244990.oops.bz2
[13:54] <rye> thisfred, on buffaloberry
[13:54] <thisfred> thx
[13:58] <thisfred> rye Chipaca: the error is thrown in django wsgi translogging. It might well be that the underlying cause is corruption of a contacts record, but it's hard to tell. I think this is one for the web & mobile team
[13:59] <thisfred> Until they can trace it back to what went wrong, or show us an error in the cloud_server code
[14:00] <rye> thisfred, i believe some application_annotations subtree is not in an expected format, probably a string instead of hash object
[14:01] <thisfred> rye, that could well be it
[14:45] <kklimonda> are there some examples of how to use views viwth couchdb-glib ?
[14:48] <rodrigo_> kklimonda, no, sorry, but the API is straightforward
[14:49] <rodrigo_> kklimonda, you get the docs containing views as CouchdbDesignDocuments
[14:49] <rodrigo_> GSList          *couchdb_database_get_design_documents (CouchdbDatabase *database, GError **error);
[14:49] <rodrigo_> GSList          *couchdb_database_execute_view (CouchdbDatabase *database,
[14:49] <rodrigo_>                                                 const char *design_doc,
[14:49] <rodrigo_>                                                 const char *view_name,
[14:49] <rodrigo_>                                                 GError **error);
[14:50] <rodrigo_> CouchdbDesignDocument *couchdb_database_get_design_document (CouchdbDatabase *database,
[14:50] <rodrigo_>                                                              const char *docid,
[14:50] <rodrigo_>                                                              GError **error);
[14:50] <rodrigo_> that's the whole API for views
[14:50] <rodrigo_> kklimonda, you will also get the DesignDocuments when you call list_documents or get_all_documents
[14:52] <kklimonda> rodrigo_: mhm, thanks
[14:59] <kklimonda> bah, gedit in maverick has some huge memory leaks..
[15:00] <kklimonda> it's using over 2GB of ram..
[15:00] <mkarnicki> kklimonda: :O wow
[15:01] <mkarnicki> a bit too much as for a text editor ;D
[15:18] <kklimonda> any idea how much memory does couchdb for android use?
[15:19] <kklimonda> 8MB in idle according do couch.io.. hmm..
[15:19] <kklimonda> or is it 8MB less than in previous release?
[15:50] <jan____> kklimonda: 8MB idle
[15:50] <jan____> kklimonda: hop on #couchdb for couchdb questions :)
[16:22] <mandel> ping vds
[16:47] <kklimonda> rodrigo_: do you have a moment? I get weird errors somewhere inside couchdb-glib and I can't decide whether I do something wrong or are vala binding to blame or maybe there is an actual bug.. I have this piece of code in vala: http://pastebin.com/JsQc9KKY which translates into this sweet little thing: http://pastebin.com/xbuNEqma and I get this output in the terminal http://pastebin.com/M7tCe1a4
[16:59] <rodrigo_> kklimonda, looking
[17:02] <kklimonda> it may be that I'm misusing weak in vala again and the list of documents returned is freed too fast..
[17:02] <rodrigo_> kklimonda, hmm, value: null on the response from http://127.0.0.1:5984/kangaroo/_design/channel/_view/channels_by_guid , that seems wrong from couchdb
[17:03] <rodrigo_> kklimonda, let me have a look at the doc
[17:03] <kklimonda> ah yes, it may obviously be a bug in my couchdb view :)
[17:04] <rodrigo_> kklimonda, http://wiki.apache.org/couchdb/HTTP_view_API#Access.2BAC8-Query
[17:04] <rodrigo_> kklimonda, well, do you have the source code of your view?
[17:05] <rodrigo_> kklimonda, it can be also a bug on couchdb-glib, I didn't do a lot of testing, just with a simple views I had
[17:07] <rodrigo_> kklimonda, also, see what does couchdb return if you just enter the URL on the browser
[17:07] <rodrigo_> http://127.0.0.1:5984/kangaroo/_design/channel/_view/channels_by_guid
[17:08] <kklimonda> well, the map function is just "function (doc) { emit (doc.guid, null) }"
[17:09] <kklimonda> and there are no errors when I run it in browser (or visit this the url you pasted directly)
[17:13] <rodrigo_> kklimonda, and what does it have in value: ?
[17:13] <rodrigo_> I guess the null in your emit causes that
[17:13] <rodrigo_> although I think value should also include the doc.guid
[17:13] <rodrigo_> thisfred, ^^ ?
[17:14] <thisfred> sry really busy atm
[17:15] <rodrigo_> kklimonda, try replacing that emit (...null) with some field and see what happens in both the browser and couchdb-glib
[17:16] <rodrigo_> kklimonda, couchdb-glib creates the CouchdbDocument from the value: field, so if it's null, you'll get nothing
[17:16] <rodrigo_> couchdb-glib should probably deal better with that, and just return an empty document with the id
[17:16] <rodrigo_> kklimonda, file a bug for that, and I'll fix it
[17:17] <rodrigo_> I need to go now, bbl
[17:17] <kklimonda> rodrigo_: how to title it? "ugh, something broke but still, couchdb-glib, you coud do better than that"? ;)
[17:20] <kklimonda> ok, filled
[19:29] <kklimonda> great, now I can't access my contacts from browser..
[19:29] <kklimonda> and I've wiped my phone and computer :D
[19:31] <kklimonda> ah, I have one more backup fortunately
[19:32] <mkarnicki> kklimonda: I didn't give it much thought while stress testing ubuntuone-android-contacts recent days :D It's good to have a backup!
[19:34] <kklimonda> well, it doesn't work for me ;)
[19:35] <kklimonda> it hasn't worked for over a month
[19:35] <kklimonda> oh wait, it's not funambol
[19:35] <kklimonda> but the error is serverside anyway
[19:36] <mkarnicki> kklimonda: we've been working on it
[19:36] <kklimonda> ah, it's still funambol.. i see, i see..
[19:36] <mkarnicki> yes
[19:36] <mkarnicki> actually sil has been working on it, I've been only helping
[22:11] <mwhudson> hi
[22:11] <mwhudson> i'm still trying to use u1 to save my notmuch mail store
[22:12] <mwhudson> (70k messages + a xapian db)
[22:12] <mwhudson> it's not working very well :(
[22:13] <duanedesign> hello mwhudson
[22:13] <mwhudson> hi
[22:32] <ajmitch> mwhudson: has it still not finished syncing them? :)
[22:34] <mwhudson> ajmitch: no :(
[22:34] <mwhudson> though i have been stopping the daemon occasionally because it's doing so much io it's interfering with my using the machine
[22:35] <ajmitch> that's kind of depressing
[22:37] <lifeless> mwhudson: bzr it
[22:44] <mkarnicki> urbanape: Hi Zachery :) I'm author of AndroidU1 and helping out with ubuntuone-android-contacts -- I applied for ubuntuone-android-client-team, is it ok for me to join :) ?