[00:09] <diogo> Hello people, I'm using ubuntuone and I'm getting a lot of this message '2009-08-13 20:04:08,341 - ubuntuone.SyncDaemon.Main - INFO - ---- MARK (state: UNKNOWN_ERROR; queues: metadata: 129; content: 4943; hash: 0, fsm-cache: hit=382326 miss=120231) ----'
[00:28] <CardinalFang> diogo, Hrm.  First sanity check.  $ ps x |grep ubuntu[o]    # How many processes?
[00:33] <CardinalFang> diogo, FWIW, it should be something close to "/usr/bin/python /usr/bin/ubuntuone-client-applet" and "/usr/bin/python /usr/lib/ubuntuone-client/ubuntuone-syncdaemon"
[00:35] <diogo> CardinalFang I did that, that are 2 processes running and i restarted that. After a restart that keep checking files and then I receive tha messages 2 minutes
[00:43] <CardinalFang> diogo, Hrm, okay.  Is there anything in syncdaemon-exceptions.log ?
[00:53] <verterok> diogo, CardinalFang: the MARK log is just that, a mark or syncdaemon telling it's alive :)
[00:54] <verterok> diogo: is the content count going down?
[00:54]  * popey hugs statik 
[00:55] <dobey> verterok: it should probably not do that :)
[00:55] <verterok> dobey: do what?
[00:55] <dobey> the MARK logging and whatever timeout todes it
[00:55] <dobey> err
[00:55] <dobey> whatever timeout does it
[00:56] <verterok> dobey: there isn't a timeout
[00:56] <verterok> dobey: why not logging the mark?
[00:56] <dobey> verterok: because it wastes power causing cpu wakeup and disk io
[00:57] <verterok> dobey: it's logged every 2 minutes
[00:57] <verterok> 1 wakeup every 2 minutes
[00:58] <dobey> yeah, and it doesn't need to wakeup at all most of the time :)
[00:58] <verterok> dobey: yes, it's beta, we need all the info we can get :)
[00:59] <verterok> dobey: once it's out of beta we can turn off the debug logs too
[01:00] <dobey> ok
[01:56] <diogo> verterok About that log, No, I have about 400 mb to sync and in the ubuntu one i only have 292.86 mb synched
[02:14] <diogo> verterok dobey I'm still receiving a lot of "2009-08-13 21:12:08,341 - ubuntuone.SyncDaemon.Main - INFO - ---- MARK (state: UNKNOWN_ERROR; queues: metadata: 129; content: 4943; hash: 0, fsm-cache: hit=382326 miss=120231) ----" and my count is not going down
[02:15] <diogo> My folder size is "416M	Ubuntu One/" and in Ubuntu One site is "292.6 MB of 10.0 GB Used (2.9%)"
[02:16] <verterok> diogo: there is fix for that bug in the latest build, in the meantime, I think reconnecting the client is a workaround
[02:16]  * verterok search the bug
[02:18] <diogo> verterok I tried to reconnect and didn't work, I will search for that bug too
[02:19] <verterok> diogo: there isn't a bug for it, bu the merge proposal of the fix is: https://code.edge.launchpad.net/~chipaca/ubuntuone-client/fixes-for-aq-states/+merge/10070
[02:21] <verterok> diogo: revno in trunk is 145, so it's in the new client build
[02:22] <diogo> verterok Ok, thank you
[02:22] <verterok> diogo: np
[02:23] <verterok> diogo: isn't the new client available to intall, try with: sudo apt-get update
[02:28] <diogo> verterok yes, there is a new update, thank you
[02:36] <diogo> verterok With the new version I'm still getting that errors
[02:36] <verterok> diogo: what errors? content count isn't going down?
[02:37] <diogo> first i received "2009-08-13 22:34:01,581 - ubuntuone.SyncDaemon.State - DEBUG - UNKNOWN_ERROR --[SYS_CONNECTION_LOST]--> UNKNOWN_ERROR"
[02:37] <diogo> then "2009-08-13 22:34:01,581 - ubuntuone.SyncDaemon.EQ - DEBUG - push_event: SYS_STATE_CHANGED, args:(), kw:{'state': <AQErrorState UNKNOWN_ERROR>}
[02:37] <diogo> "
[02:37] <diogo> and again "2009-08-13 22:35:50,849 - ubuntuone.SyncDaemon.Main - NOTE - ---- MARK (state: UNKNOWN_ERROR; queues: metadata: 129; content: 4943; hash: 0, fsm-cache: hit=382225 miss=120332) ----
[02:37] <diogo> "
[02:37] <verterok> diogo: ok, that's an error, but the MARK log isn't
[02:38] <verterok> diogo: it's the syncdaemon connected?
[02:38] <diogo> verterok I restarted the service and the applet, however with this new update applet don't show in my tray bar
[02:38] <verterok> diogo: the applet behaviour changed a "bit"
[02:38] <verterok> diogo: I think the applet hides itself when the syncdaemon it's "idle"
[02:40] <verterok> diogo: could you run this command?: dbus-send --session --dest=com.ubuntuone.SyncDaemon --type=method_call --print-reply  /status com.ubuntuone.SyncDaemon.Status.current_status
[02:41] <verterok> diogo: also this one: u1sdtool --current-transfers
[02:41] <diogo> http://paste.ubuntu.com/252864/
[02:42] <diogo> Current uploads: 0 \n Current downloads: 0 \n
[02:42] <verterok> diogo: ok, it's stuck in error, could you paste the log lines above "2009-08-13 22:34:01,581 - ubuntuone.SyncDaemon.State - DEBUG - UNKNOWN_ERROR --[SYS_CONNECTION_LOST]--> UNKNOWN_ERROR"
[02:43] <verterok> diogo: I think you hitted a bug, but let's be sure first :)
[02:45] <diogo> verterok http://paste.ubuntu.com/252867/
[02:46] <verterok> diogo: err, sorry. the lines before 2009-08-13 22:34:01,581 - ubuntuone.SyncDaemon.State - DEBUG - UNKNOWN_ERROR --[SYS_CONNECTION_LOST]--> UNKNOWN_ERROR
[02:54] <diogo> verterok still uploading
[02:54] <verterok> diogo: ok, thanks.
[02:54] <verterok> diogo: I need the previous lines because the error occured before the 'SYS_CONNECTION_LOST'
[02:55] <verterok> diogo: if it's to big, just paste the 20-30 lines before the UNKOWN_ERROR
[02:55] <verterok> s/to big/too big/
[02:57] <diogo> verterok I cancelled that and pasted 125 lines before that http://paste.ubuntu.com/252871/
[02:57] <verterok> diogo: excellent, thanks! :)
[02:58] <verterok> diogo: ok, congrats, you just found a bug!
[02:58] <verterok> diogo: would youo mind to file it in launchpad? and attach the contents of http://paste.ubuntu.com/252871/
[02:59] <verterok> *you
[03:00] <verterok> or I can file it, let me know
[03:00] <diogo> verterok I will do that, thank you
[03:01] <verterok> diogo: so, the issue here is that the connection was dropped in the middle of the server rescan, and syncdaemon didn't handled that very well :/
[03:01] <verterok> diogo: restarting the daemon should be enough to get it working again
[03:01] <verterok> diogo: btw, thanks a lot for the help! :)
[03:03] <diogo> verterok bug filled https://bugs.launchpad.net/ubuntuone-client/+bug/413369
[03:03] <diogo> verterok thank you
[03:04] <lbsjack> Hi,I installed the ubuntuone-client-gnome that use some account,and now I want to change the account,how can I do?
[03:06] <verterok> lbsjack: Hi
[03:06] <lbsjack> Verterok
[03:06] <lbsjack> verterok:hi
[03:06] <verterok> lbsjack: the client uses a token stored in the gnome keyring to connect to the server, removing the token from the keyring and restarting the client should be enough
[03:07] <verterok> lbsjack: do you know how to remove a token/password from teh keyring?
[03:07] <verterok> *the
[03:08] <lbsjack> verterok:ok,thank you very much.
[03:08] <verterok> lbsjack: np
[03:16] <verterok> later!
[13:05] <diverse_izzue> hey all. i have ubuntuone "working" (read: tray icon spinning) forever after resuming from suspend. is that a known bug?
[13:08] <Chipaca> nope, sounds like an unknown one
[13:08] <Chipaca> diverse_izzue: did you update the client yesterday?
[13:09] <diverse_izzue> Chipaca, I have 0.92.0-0ubuntu1
[13:09] <diverse_izzue> from the karmic repos
[13:12] <Chipaca> I think that's slightly older than yesterday's beta
[13:12] <Chipaca> I'm not positive, though :)
[13:13] <Chipaca> diverse_izzue: if you want, you can add ppa:ubuntuone/beta and try that
[13:14] <diverse_izzue> Chipaca, will do, but it's not a new behavior of 0.92.0, i was just too lazy to report it before (enough trouble in other areas with karmic :-)
[13:14] <Chipaca> diverse_izzue: (that would be what you add via system -> administration -> software sources -> third party software -> add)
[13:14] <Chipaca> yeah
[13:14] <Chipaca> yesterday's beta fixed it in three different ways ;)
[13:15] <Chipaca> first, when it gets stuck during the initial handshake, the client now timesout (imagine that!), and retries (wow!) until it finally gives up in a huff
[13:15] <Chipaca> second, when the client gets an unknown error, it restarts
[13:15] <diverse_izzue> i'll try right away
[13:15] <Chipaca> third, when nothing is happening, the applet goes for a walk
[13:16] <diverse_izzue> besides, it's pretty awesome how easy it's become to add PPA's in karmic!
[13:16] <Chipaca> yes :)
[13:17] <diverse_izzue> correction: wasn't it supposed to import the relevant key as well?
[13:18] <Chipaca> yes, it was
[13:18] <Chipaca> didn't it?
[13:20] <diverse_izzue> no, it didn't
[13:21] <diverse_izzue> had to do it manuall, but at least you can paste from clipboard now
[13:23] <diverse_izzue> Chipaca, is quitting the tray applet and restarting from the menu enough?
[13:23] <diverse_izzue> or do i have to log out and back in again?
[13:23] <Chipaca> diverse_izzue: yes
[13:24] <Chipaca> no, quitting is enough
[13:24] <diverse_izzue> also, is it planned to add notification if the user changes something in the webfrontend?
[13:24] <diverse_izzue> so far, one has to reload ubuntuone to make it pick up changes made on the web
[13:25] <Chipaca> yes, the pieces for that are finally falling into place
[13:25] <diverse_izzue> great
[13:25] <Chipaca> >clunk< >thunk< >crunch< oh damn
[13:25] <Chipaca> :)
[13:26] <diverse_izzue> is the applet in the new beta supposed to hide itself from tray?
[13:26] <diverse_izzue> or did it simply crash? *g
[13:26] <Chipaca> it's supposed to hide
[13:26] <Chipaca> notifications are coming shortly, I believe
[13:26] <diverse_izzue> brilliant
[13:26] <Chipaca> so it doesn't just go away
[13:26] <Chipaca> but says bye-bye or sthing
[13:26] <diverse_izzue> oh, cool :-)
[13:27] <diverse_izzue> also, what's all the couchdb stuff about?
[13:27] <diverse_izzue> what's it supposed to do?
[13:29] <Chipaca> magic
[13:30] <Chipaca> that's my take on it, anyway
[13:30] <Chipaca> (I'm on the syncdaemon side of things; couch is done by other people)
[13:30] <diverse_izzue> i don't believe in magic :-)
[13:31] <diverse_izzue> can i read about it somewhere? anyway is there a blog/news channel about ubuntuone?
[13:32] <Chipaca> not with recent, juicy stuff on it, no
[13:32] <Chipaca> there should be
[13:32] <diverse_izzue> exactly
[13:33] <diverse_izzue> just to keep the testers updated what's going on
[13:33] <diverse_izzue> so they can test newly implemented stuff
[13:33] <diverse_izzue> karmic is only 2 months away...
[13:33] <Chipaca> ssh!
[13:33] <Chipaca> I'd managed to forget
[13:34] <Chipaca> got a sprint all next week to bash things into shape :)
[13:34] <diverse_izzue> cool - i'll help on the testing site as much as i can :-)
[13:34] <diverse_izzue> is it planned to be able to sync any folder - not just ~/ubuntuone?
[13:35] <Chipaca> not for karmic
[13:35] <Chipaca> but, yes
[13:35] <Chipaca> that is "multiroot"
[13:36] <till> rodrigo_: ping
[13:36] <rodrigo_> till: hi
[13:37] <dobey> oh not for karmic?
[13:38] <Chipaca> dobey: I doubt it
[13:38] <Chipaca> dobey: we have next week
[13:38] <dobey> yeah
[13:38] <till> rodrigo_: heya, do you happen to know if the trigger stuff is in a release version of couch meanwhile, or does one still need trunk?
[13:38] <dobey> just noting that any client features we don't get into karmic, are going to be a total pain to do
[13:39] <Chipaca> dobey: I don't think it's what we'll be doing, but I'd be happy to be wrong :)
[13:39] <till> rodrigo_: also, is the contact schema actually used somewhere yet, in other words, is there data out there that end users could actually get to?
[13:39] <rodrigo_> till: the trigger stuff?
[13:39] <till> rodrigo_: notification triggers
[13:39] <till> rodrigo_: of changes in the db
[13:39] <till> rodrigo_: _changes URL
[13:39] <dobey> Chipaca: well, i certainly won't be doing it
[13:39] <Chipaca> diverse_izzue: maybe you can ask rodrigo_ about living-room furniture
[13:39] <rodrigo_> till: ah, not sure about the details, thisfred should know
[13:39] <thisfred> hi
[13:40] <till> thisfred: Good morning.
[13:40] <rodrigo_> till: and it's used in evo and our web site for phone syncing
[13:40] <till> We're wondering whether it makes sense to package the akonadi couchdb resource at this point.
[13:40] <rodrigo_> Chipaca: am I an expert in living room furniture? :)
[13:40] <thisfred> till: _changes is in trunk, soon to be released as 0.10
[13:40] <till> rodrigo_: ah, so you can actually use it
[13:40] <rodrigo_> till: yes
[13:40] <till> rodrigo_: great, no notifications, though, I guess?
[13:41] <thisfred> or at least there will be a stable feature frozen 0.10 branch, looks like this weekend
[13:41] <till> rodrigo_: can you make me an account, btw, so I can test against taht?
[13:41] <rodrigo_> till: I haven't implemented them yet on evo-couchdb
[13:41] <rodrigo_> till: for u1? you don't have one already?
[13:41] <till> Nope, been testing with local dbs.
[13:42] <rodrigo_> till: ok, will send you an invitation, what's your email?
[13:42] <till> till@kdab.net
[13:42] <rodrigo_> ok
[13:42] <till> I'll make sure the resource works with latest stable couch, your server, etc Without notifications, then we can release it with KDE 4.3.
[13:42] <till> For kubuntu.
[13:43] <Chipaca> rodrigo_: I don't know; you seem to know more about it than I :-D
[13:43] <rodrigo_> till: well, the akonadi backend should probably be talking rather with the desktop couch (desktopcouch project in LP)
[13:44] <rodrigo_> till: you'll need to get the port via dbus, so I'd suggest you test with that
[13:44] <till> rodrigo_: yeah, sure
[13:44] <till> Is that available to end users yet?
[13:44] <rodrigo_> till: we don't have invitations any more, just go to u1.com and subscribe
[13:45] <rodrigo_> till: yes, desktopcouch package in karmic
[13:45] <thisfred> rodrigo_: till : I don't think ubuntuone itself has anything couch related yet (in fact that's what I'm working on)
[13:45] <till> Ok, I'm trying to get an idea of the practical usefulness of the akonadi resource to end users, at this point.
[13:45] <rodrigo_> thisfred: right, that's why I suggest till to use the desktopcouch
[13:45] <thisfred> desktopcouch is public, and I believe there was a new release yesterday, but I'm not 100% sure
[13:45] <till> So provided they install desktopcouch, they can access whatever data is n there.
[13:45] <till> And evo could be using that too, if set up for that.
[13:46] <rodrigo_> till: in the local couchdb per-user instance, yes
[13:46] <rodrigo_> till: that will be synced to u1.com server, but that's not 100% ready yet
[13:46] <till> Ok.
[13:46] <dobey> s/will/can if you tell it to enable the ubuntuone.com connectivity/
[13:46] <till> Anyhow, I'll make sure it works with the desktopcouch in karmic.
[13:47] <rodrigo_> till: yes, that's the plan, akonadi and evo will use desktopcouch
[13:47] <till> right, trying to judge how much of that is useful for end users yet.
[13:47] <rodrigo_> till: are there packages of your akonadi backend?
[13:48] <till> That's why I'm asking these questions. :)
[13:48] <till> Trying to decide whether to make them.
[13:48] <rodrigo_> till: I can help you testing the interaction between evo and akonadi
[13:48] <till> ok, I'll set up an "official" desktopcouch.
[13:49] <statik> hola
[13:49] <rodrigo_> hola statik :)
[13:50] <rodrigo_> till: if you make them, poke me and I'll keep testing them while I keep working on evo-couchdb
[13:50] <statik> rodrigo_, i have many questions for you. in the evolution-couchdb that was uploaded yesterday, do you have dependencies on python-desktopcouch and recommends for desktopcouch-tools? also, is there an MIR written for evolution-couchdb already? After the MIR, is someone working on getting evolution-couchdb into the ubuntu-desktop seed to be installed by default?
[13:50] <till> rodrigo_: deal
[13:51] <rodrigo_> till: a bit old version of evo-couchdb is in the u1 beta ppa, if you want to test also. Will submit a new release soon
[13:51] <statik> hey till, awesome to see you in here
[13:51] <statik> i dunno if someone packaged the akonadi backend. we should get that done
[13:51] <till> Talking to Riddel about just that.
[13:51] <rodrigo_> statik: no python-desktopcouch dependencies, although I guess it should depend or suggest at least desktopcouch*
[13:52] <rodrigo_> statik: about MIR, I really don't know, who should I poke for that?
[13:52] <till> I need to make sure it also works fine with older couches, as I've developing against trunk, to get the notifications feature.
[13:52] <statik> rodrigo_, i think it needs a hard dependency, desktopcouch is where you get the DBUS interface to get the running desktop couch instance
[13:52] <rodrigo_> statik: yeah, right
[13:52] <statik> rodrigo_, kenvandine can help probably, but will need your input
[13:53] <rodrigo_> ok, he's out this week though, but will poke him on Monday
[13:53] <rodrigo_> statik: well, he told me something about that in Dublin, so I guess he's keeping track of it
[13:53] <statik> rodrigo_, i think you should look at the MIR for ubuntuone-client and write the evolution-couchdb one yourself today then, i'm afraid to wait for monday
[13:53] <rodrigo_> ok
[13:54] <rodrigo_> where is the u1-client one?
[13:54] <statik> also, pitti approved the MIR for couchdb, so it will be good to ping him about evolution-couchdb as well
[13:54] <statik> they are on the ubuntu wiki somewhere
[13:55] <rodrigo_> ok
[13:55] <statik> rodrigo_, the end goal is that alpha5 has evolution-couchdb installed by default, along with couchdb and the necessary bits to make it run
[13:56] <statik> rodrigo_, but it doesn't need to be the default backend for evolution, just available by default
[13:56] <rodrigo_> ok
[13:56] <rodrigo_> ok, found it -> https://wiki.ubuntu.com/MainInclusionReport/UbuntuOneClient?highlight=%28MIR%29|%28ubuntuone\-client%29
[13:57] <statik> great
[13:57] <statik> there is a page explaining the process on the ubuntu wiki somewhere, but basically you write the MIR and file an MIR report and then need someone like pitti to approve and make the seed modifications
[13:57] <statik> this won't be a surprise to anyone, we've discussed it all along
[13:58]  * dobey really doesn't want to do reviews today
[13:58] <dobey> too many features to code...
[13:58] <rodrigo_> ah, kenvandine already added them it seems -> https://wiki.ubuntu.com/MainInclusionReport/CouchDBGlib?highlight=%28couchdb%29|%28MIR%29 and https://wiki.ubuntu.com/MainInclusionReport/EvolutionCouchDB?highlight=%28couchdb%29|%28MIR%29
[13:58] <statik> dobey, you are officially relieved from reviews today
[13:59] <statik> i'll cover if the other reviewers get overwhelmed
[13:59] <statik> rodrigo_, great! i bet it needs review and the MIR bug to be filed
[14:00] <rodrigo_> statik: couchdb-glib is already fix released -> https://bugs.launchpad.net/ubuntu/+source/couchdb-glib/+bug/408848
[14:00]  * rodrigo_ does the evo-couchdb one
[14:01] <dobey> hooray
[14:04]  * rodrigo_ -> lunch
[14:05] <rodrigo_> statik: done -> https://bugs.launchpad.net/ubuntu/+source/evolution-couchdb/+bug/413589
[14:05] <rodrigo_> brb
[14:08] <statik> rodrigo_, a million thanks
[14:20] <statik> wow, joyent sold bingodisk to expandrive, but is still going to pay for my lifetime account
[14:27] <pfibiger> statik: the paid service / paid client route could be a little weird. can you buy it for a month and get the full-featured sftp client? do you buy the client separately? if so, do you have to keep buying new clients as they add new features?
[14:28] <statik> pfibiger, i have no idea. i was a minor investor in textdrive, so i have free lifetime accounts that transferred to joyent
[14:28] <dobey> pfibiger: WoW is paid service/client too
[14:28] <statik> s/minor/micro/
[14:29] <pfibiger> dobey: yeah but the client doesn't provide significant value outside the game
[14:29] <pfibiger> whereas expandrive w/o bingodisk/strongspace is still full featured sftp-mounting software
[14:29] <dobey> i guess
[14:30] <pfibiger> dobey: it'll just be interesting to see what path they choose.
[14:39] <dobey> damn it feels good to be a gangsta
[14:55] <jblount> dobey: +1
[15:00] <statik> MEETING BEGINS
[15:00] <statik> hello hackers, say me if you are here to change the world
[15:01] <jblount> ME
[15:01] <statik> me
[15:01] <statik> dobey, teknico, urbanape, CardinalFang?
[15:01] <statik> rodrigo_,
[15:01] <rodrigo_> me
[15:01] <dobey> moi
[15:01] <urbanape> me
[15:01] <statik> jblount, start us off will ya?
[15:02] <jblount> DONE: Landed css fixes for webui, started work on overlays
[15:02] <jblount> TODO: Finish overlays, get some reviews done
[15:02] <jblount> BLOCKED: Nope
[15:02] <jblount> statik: DOIT
[15:02] <statik> DONE: a bunch of code review and phone calls. fixed a tricky bug in the couchdb snapshot package. handed off spawning packaging to rick, reviewed indicators proposal from david
[15:02] <statik> TODO: help with reviews, design team call, some evolution-couchdb and tomboy sync testing
[15:02] <statik> BLCK: None.
[15:02] <statik> rodrigo_, all you
[15:02] <rodrigo_> • DONE: Many evo-couchdb fixes in dont-lose-uuids submitted branch. Submitted patch for tomboy to Ubuntu. Submitted branch to fix 500 error on HTTP redirecting. Filed evo-couchdb MIR bug
[15:02] <rodrigo_> • TODO: Add more tests in couchdb-glib test suite. More openSUSE packaging. Change tomboy syncing prefs interface to show many servers. Add social services accounts config to about-me. Talk to Ara about writing mago tests for evo-couchdb. File bugs for missing evo-couchdb fields and summary of the fields it uses. Make evo-couchdb package depend on desktopcouch
[15:02] <rodrigo_> dobey: go!
[15:02] <dobey> ☭ DONE: Started on #330769
[15:02] <dobey> ☭ TODO: #406897, Finish #330769, Finish OAuth 1.0a work
[15:02] <dobey> ☭ BLCK: None.
[15:02] <dobey> urbanape: hit it
[15:02] <urbanape> DONE: New files ui, helping a FF dev try to test Bindwood
[15:02] <urbanape> TODO: Fix new files ui bugs
[15:02] <urbanape> BLOCK: None
[15:02] <urbanape> Next: None?
[15:03] <statik> i guess thats it
[15:03] <statik> MEETING ENDS
[15:03] <rodrigo_> wow, less than 3 minutes :)
[15:04] <statik> rodrigo_, thisfred: have you guys compared the evolution-couchdb record format with what markgsaye has for the record format on the server side after syncing from a mobile phone?
[15:04] <rodrigo_> statik: not really compared it, I'm just basing the evo-couchdb work on the field mappings they have
[15:05] <teknico> me, sorry, on a call
[15:05] <statik> cool. i'm mostly wondering how evolution-couchdb is going to deal with it when those records show up in the local DB via replication
[15:05] <teknico> DONE: landeed the branch to remove relative imports (after many tries), talked with jdo and markgsaye about disabling free phone sync after 30 days
[15:05] <teknico> TODO: more work on disabling free phone sync after 30 days
[15:05] <teknico> BLOCKED: none
[15:05] <statik> teknico, thanks!
[15:05] <rodrigo_> statik: I'll ask mark for some record samples
[15:05] <thisfred> statik I have not taken the time to look at evo-couch, rodrigo_: feel free to ask questions, or just for feedback on specifics
[15:06] <thisfred> rodrigo_: or ask mark, that works too :)
[15:06] <rodrigo_> thisfred: yeah, just looking at the mappings
[15:06] <urbanape> poop. my slicehost slice got compromised. was a spam relay. sad panda. oh well, I wanted to upgrade to 9.04 anyway.
[15:06] <statik> teknico, i wonder whether there is anything that could be done to get mobile phone syncing actually working and a contact record showing up in the evolution that originated on a phone?
[15:06] <dobey> grr
[15:07] <teknico> statik, first the phone needs to sync with the funambol ds server, then the evolution syncml plugin should do the same
[15:07] <statik> teknico, as a higher priority than disabling phone sync? i'm just suggesting this because we have a really important karmic deadline coming up, and i want to see the roundtrip contact from mobile->evolution next week if it's going to make karmic
[15:08] <statik> teknico, evolution syncml? what about couchdb replication?
[15:08] <rodrigo_> for the record to show up in evo, we need the replication
[15:08] <statik> i sure hope our plans aren't based on the evolution syncml thing
[15:08] <rodrigo_> since evo talks to the desktopcouch instance
[15:08] <statik> we've been writing an evolution-couchdb backend
[15:08] <rodrigo_> no syncml that I know of, yeah :D
[15:09] <teknico> statik, better ask rodrigo_ about evolution, and thisfred about couchdb :-)
[15:09] <teknico> oh, thunderbird has one, I thought evolution had one too, sorry
[15:10] <statik> teknico, i'd like you to postpone the work on disabling mobile sync and work with rodrigo and thisfred on getting records synced from a phone all the way through to evolution, displaying through evolution-couchdb
[15:10] <thisfred> teknico: evo is *not* gonna talk to funex. Everything should go through couch
[15:11] <statik> this is the single highest priority functionality story we have for this week and the alpha5 deadline in karmic
[15:12] <rodrigo_> statik: who is working on the desktop->server couchdb replication?
[15:12] <thisfred> rodrigo_: me
[15:12] <rodrigo_> ah cool
[15:12] <thisfred> but would welcome teknico's help
[15:12] <rodrigo_> thisfred: anything I can do to help you?
[15:12] <rodrigo_> right, teknico's help would be better than mien :D
[15:12] <teknico> thisfred, you got it :-)
[15:13] <statik> you guys rock
[15:13] <thisfred> rodrigo_: or yours :) teknico has done more work on the backend though
[15:13] <dobey> hooray me
[15:13]  * thisfred hoorays dobey 
[15:13]  * dobey makes a note to thwap aquarius on his return
[15:13] <rodrigo_> thisfred: yes, teknico's better, just let me know if you need anything from me
[15:13] <statik> dobey, did you get a chance to see the notification mockups from david?
[15:13] <thisfred> rodrigo_: will do!
[15:13] <thisfred> teknico: we'll coordinate on the call
[15:14] <CardinalFang> Eek!
[15:14] <CardinalFang> DONE: gwibber accounts tested; should be ready to merge.  Finally finished desktopcouch work; released.
[15:14] <CardinalFang> TODO: figure out what needs to be done with gwibber icon caching.  Travel to vacation spot, so offline but working today.
[15:14] <CardinalFang> BLOCKED: gwibber source management isn't very good.  bugs out of control, no obvious 2.0-dev branch.
[15:14] <teknico> thisfred, which is in 30 seconds :-)
[15:14] <thisfred> I know
[15:16] <dobey> statik: yeah
[15:17] <jblount> I'm so stoked on syncing tomboy notes
[15:17] <jblount> It is ridiculous.
[15:18] <CardinalFang> jblount, when is that due?
[15:19]  * dobey is getting tired of refactoring code
[15:19] <dobey> CardinalFang: aren't you on holiday?
[15:19] <CardinalFang> dobey, not yet.
[15:19] <jblount> rodrigo_: When will I be able to sync my tomboy notes?
[15:20] <dobey> CardinalFang: the calendar is a lie?
[15:20] <CardinalFang> dobey, Yes.
[15:20] <rodrigo_> jblount: you already are, if you use trunk and the tomboy package in our beta PPA
[15:20]  * dobey goes to get some cake then
[15:20] <CardinalFang> dobey, (There is no cake.)
[15:20] <rodrigo_> jblount: there might be some errors, so make sure to test with 'testing' data, not real notes for now
[15:21] <jdo> teknico, markgsaye: is the couchdb that the contacts API talks to the same couchdb that a users tomboy notes are stored?
[15:21] <jblount> CardinalFang: did you see rodrigo_ 's response? NOW!
[15:21] <rodrigo_> jdo: it's another database
[15:21] <jblount> rodrigo_: Neat! I'll try playing with it this weekend.
[15:21] <CardinalFang> Aiee!
[15:21] <jdo> rodrigo_, cool
[15:21] <dobey> CardinalFang: http://www.youtube.com/watch?v=0Lo6uXwi4M0
[15:22] <jdo> rodrigo_, when is their couchdb created? the first time they try to sync?
[15:22] <jdo> rodrigo_, re: tomboy notes couchdb
[15:22] <rodrigo_> jdo: yes, or when you use the web ui
[15:23] <rodrigo_> jdo: all the code in notes/views check for the existence of the db, and create it if it's not there yet
[15:23] <statik> rodrigo_, jdo: actually there is a very odd problem that creating notes from the web UI is not working in production, although it is working in dev.
[15:23] <rodrigo_> statik: yeah, filed a bug for it the other day
[15:23] <statik> i'm worried about that
[15:23] <rodrigo_> yeah
[15:23] <statik> jdo, i don't know if you have any spare cycles, but that would be a very great place to get some help if you have any extra time
[15:23] <dobey> o/~ we're out of beta, we're releasing on time o/~
[15:24] <markgsaye> jdo: it's the same couchdb, but a different database
[15:24] <jdo> markgsaye, ok
[15:24] <jdo> statik, help where the dev/prod issue?
[15:25] <statik> jdo, yes - i fear it is masking some broader production couchdb configuration matter
[15:25] <statik> er, revealing not masking
[15:26] <rodrigo_> jdo: https://bugs.launchpad.net/ubunet/+bug/412402
[15:28] <jblount> urbanape: I pledge to remember to use "Zac" instead of "Zach" or "Zack". pfibiger can tell you of a similar pledge reguarding pronouncing his name.
[15:28] <urbanape> heh
[15:29] <urbanape> no worries
[15:31] <urbanape> statik: Did I ask if we'd considered using Miller columns for the web ui?
[15:47] <dobey> were there like 3 hurricanes in Florida this week or something? sheesh
[15:49] <pfibiger> dobey: really? we've had zero named anythings until now
[15:49] <dobey> pfibiger: i don't know. it's just been raining hard here all week, so i presumed it was hurricane fallout
[15:50] <pfibiger> dobey: nothing..just some tropical waves, one may turn into a tropical depression
[15:50] <dobey> weird
[15:52] <dobey> i hope atlanta isn't all screwy this weekend
[15:52] <jblount> dobey: Make sure to drink some mate
[15:53] <dobey> heh
[15:53] <dobey> argentina/chile are one giant cloud right now :-/
[15:56] <jdo> markgsaye, tell me about the firefox plugin for phone sync
[15:57] <dobey> i really need to get in the habit of eating breakfast
[15:59] <markgsaye> jdo: thunderbird plugin? see: https://mozilla-plugin.forge.funambol.org/
[16:02] <markgsaye> jdo: let me know if you have questions about that
[16:03] <jblount> Apparently Karmic preferes putting sound out in the secondary audio jack, which is better than no sound.
[16:09] <teknico> jblount, yeah, there have been some strange audio mixer changes
[16:57] <nystire> sorry to bother the channel, but where should i look for information about registering for "ubuntu one"
[17:02] <statik> hi nystire
[17:02] <statik> you left too soon, i was going to tell you ubuntuone.com
[19:35] <keen101> hello, just installed ubuntuone for the first time today.
[19:36] <jblount> keen101: Fun!
[19:36] <keen101> heh, thanks, but i have no idea how to use it :D
[19:36] <jblount> keen101: Do you have a folder in ~/Ubuntu One/ ?
[19:37] <keen101> yep
[19:37] <keen101> well, under my home folder
[19:37] <jblount> keen101: If you put stuff in that folder, it will sync up to your account and be available at http://ubuntuone.com
[19:38] <dobey> "that folder" == ~/Ubuntu One/My Files/
[19:38] <keen101> ok, cool. is there supposed to be an icon in the notification area?
[19:39] <dobey> an icon should appear during various important activities, and errors
[19:40]  * jblount scowls at firefox
[19:41]  * dobey doesn't know what to do with firefox at this point
[19:41] <dobey> i wonder if midori is usable
[19:42]  * dobey tries to call what the ugly flash page was that thisfred pointed him at the other day
[19:42] <jblount> I was quite happy with chromium, not sure why I went back to firefox, but that needs to stop.
[19:42] <thisfred> dobey: something belgian, a brewery
[19:43] <dobey> oh right
[19:43] <dobey> the delerium tremens beer
[19:43] <thisfred> http://en.wikipedia.org/wiki/Delirium_Tremens_%28beer%29
[19:43] <thisfred> that has the links (I've learned my lesson well)
[19:44] <thisfred> learnt?
[19:44] <dobey> ooh
[19:44] <dobey> midori didn't crash!
[19:44]  * dobey ponders using midori
[19:45] <thisfred> Midori is a melon liqueur with a sweet, fruity taste.
[19:45] <dobey> it goes well with tequila and vodka
[19:47] <thisfred>  it is extremely versatile, and can be found in many fruity cocktails, as well as mixed up simply with another mixer as a long drink
[19:48] <thisfred> MIDORI has gained an outstanding reputation among leading bartenders and cocktail designers worldwide for its outstanding quality and superb versatility
[19:48] <dobey> thank you wikipedia
[19:49] <dobey> ok, not using midori
[19:49] <dobey> it has other faults which make it unusable
[19:49] <dobey> like C-l not selecting the text in the location entry, and C-k in the location entry doing search
[19:49] <dobey> too bad, it could have been nice :(
[19:50] <dobey> oh well
[19:52] <dobey> Chipaca: ping
[19:52] <Chipaca> dobey: pong
[19:53] <dobey> Chipaca: can you explain to me the differences between WORKING_ON_CONTENT and WORKING_ON_METADATA, and what's actually going on?
[19:54] <Chipaca> dobey: the syncdaemon has two queues relevant to your question: one for metadata commands such as file creation, deletion, moving and renaming, shareing, et cetera
[19:54] <Chipaca> dobey: and another queue that is for content operations: upload and download
[19:54] <Chipaca> dobey: do I continue?
[19:55] <Chipaca> dobey: what do I need to do to get ./autogen.sh to work?
[19:55]  * thisfred wants to become a leading cocktail designer
[19:55] <Chipaca> dobey: never mind re autogen.sh, I symlinked storageprotocol in by hand :)
[19:56] <dobey> Chipaca: so does WORKING_ON_METADATA hit the network? and what does START_WORKING_ON_ mean?
[19:57] <dobey> Chipaca: i'm trying to determine when i should get the list of pending transfers, and do all the calculations for uploads/downloads/etc...
[19:57] <Chipaca> dobey: START_ states are the same as the START_-less states, except that they fire the action that gives the state its name
[19:57] <dobey> thisfred: all you need is some cough syrip and a lighter
[19:58] <dobey> Chipaca: so i guess START_foo is probably what i want to check for to do it?
[19:58] <Chipaca> dobey: does dbus guarantee delivery? if not, you probably want to catch both
[19:59] <dobey> i don't think dbus guarantees anything
[19:59] <dobey> which is why we seem to be getting so many DBusExceptions :(
[19:59] <dobey> and i don't know if we can do anything about those
[20:00] <Chipaca> what are you wanting to do?
[20:00] <Chipaca> there are a lot of events, and we can add more if you need something more specific
[20:00] <Chipaca> adding events is cheap :)_
[20:07] <Chipaca> __lucio__, dobey: I'm about to ask for a review of lp:~chipaca/ubuntuone-client/holy-reactionary-reactors-batman
[20:07] <Chipaca> __lucio__: dobey: you get early warnings, because I'm trying to be a nice guy
[20:09] <dobey> Chipaca: i'm not reviewing anything today
[20:09] <Chipaca> dobey: I'm not asking for a review, but I'm swapping out the reactor in the applet
[20:10] <Chipaca> dobey: so if you want to stop me from doing such an evil thing, now is when you holler
[20:10] <dobey> uhm
[20:10] <dobey> "why?"
[20:11] <dobey> i guess it is unneccessary there...
[20:12] <dobey> hrmm
[20:12] <dobey> actually
[20:12] <Chipaca> dobey: because the current reactor chews batteries
[20:13] <Chipaca> dobey: uses a hrtimer
[20:13] <Chipaca> dobey: when browsing the interwebs on a battery, you'll have three hogs: firefox, and sd, and the applet
[20:14] <dobey> Chipaca: so we're using a reactor because oauthdesktop starts up a twisted web server during oauth
[20:15] <dobey> i wonder if BaseHTTPServer is better at that
[20:16] <Chipaca> dobey: maybe. We'd still need this for syncdaemon, however, so you're getting it gratis :)
[20:17] <dobey> getting what?
[20:21] <dobey> Chipaca: you're fixing oauthdesktop to not use twisted?
[20:21] <Chipaca> dobey: no, getting the cheaper reactor
[20:22] <dobey> oh
[20:22] <dobey> i thought you were removing it
[20:24] <dobey> oh well
[20:24] <dobey> anyway, i was asking about the WORKING states, so i know how to know when the syncdaemon is doing stuff, and when i should check the waiting list
[20:25] <dobey> Chipaca: does it keep going from SORKING_ON to START_WORKING_ON for subsequent uploads/downloads?
[20:25] <dobey> or is START_ only called the first time?
[20:26] <Chipaca> the upload/download only starts after entering START_WORKING_ON_CONTENT
[20:27] <Chipaca> dobey: at least, today
[20:27] <Chipaca> dobey: there is another event which is probably more relevant
[20:27] <Chipaca> dobey: but you don't tell me what you're wanting to do :)
[20:27] <Chipaca> dobey: AQ_DOWNLOAD_STARTED
[20:27] <dobey> i told you waht i want to do
[20:27] <Chipaca> dobey: and its friends
[20:28] <Chipaca> dobey: sorry, I must've disconnected; I see no reply to my question
[20:28] <dobey> download/upload started/finished are only fired when each individual file transfer actually starts
[20:29] <dobey> Chipaca: i need to call waiting_content() before any transfers happen at all, and i am trying to figure out the best way to know when to call it
[20:29] <dobey> because having a timeout sucks
[20:29] <Chipaca> dobey: why do you need to call waiting_content() before any transfers happen at all?
[20:30] <dobey> Chipaca: so i can present appropriate UI to the user
[20:30] <Chipaca> dobey: sorry, I don't follow
[20:31] <Chipaca> dobey: the "before any transfers happen at all" is what I don't follow
[20:31] <dobey> Chipaca: avoid showing 500 notifications rapidly in a row, as on example
[20:31] <Chipaca> dobey: that's like wanting to guess the future, ro sth
[20:31] <Chipaca> or something
[20:31] <dobey> sigh
[20:31] <dobey> we talked about this yesterday or something even
[20:31] <dobey> or maybe i just talked with verterok, but you pointed me at waiting_content
[20:31] <Chipaca> yes
[20:32] <dobey> it's not guessing the future, unless waiting_content is actually entirely pointless and doesn't tell me that information
[20:32] <Chipaca> you have two methods to query: one for the current transfer, and another for the ones that are queued up
[20:32] <dobey> which appears to be the case right now
[20:32] <Chipaca> *what* information?
[20:32] <dobey> yes and i need to know the queue first
[20:33] <Chipaca> why do you need to know the queue first? before the transfer starts?
[20:33] <dobey> what is queued!
[20:33] <dobey> sheesh
[20:34] <Chipaca> dobey: I'm really trying to understand what you need, but you're not telling me. I'm probably exceptionally thick, or something, but could you please patiently explain?
[20:35] <Chipaca> dobey: I mean: sure, you need to present the information to the user
[20:35] <Chipaca> so you might have things uploading or downloading, and you have things queued up
[20:35] <Chipaca> you query those things
[20:35] <Chipaca> and present them
[20:35] <Chipaca> you don't even have to wait for an event
[20:35] <Chipaca> now, waiting for some events makes sense, so that you don't have to poll
[20:36] <Chipaca> so you look at the CONTENT_QUEUE_(WAITING|DONE) events, and check things then
[20:37] <dobey> i am telling you, but you're ignoring those parts or just fucking with me, afaict :(
[20:37] <Chipaca> I am not fucking with you, I swear
[20:38] <dobey> there are not CONTENT_QUEUE states
[20:38] <Chipaca> no, those are events
[20:39] <Chipaca> dobey: is this because of the "only show the applet for things that take more than 30 seconds"?
[20:39] <dobey> no
[20:40] <dobey> it's so the ui doesn't change every N seconds when something starts/finishes
[20:40] <dobey> but displays all the transfers in the same place
[20:40] <dobey> and so i can say "Uploading file N of M"
[20:40] <dobey> etc...
[20:40] <Chipaca> but you can't say "uploading file N of M"
[20:40] <dobey> but i don't want to poll, and i really only want to do it when stuff is going to transfer
[20:41] <Chipaca> because M is without bounds
[20:41] <dobey> then syncdaemon needs fixed so i can say that
[20:41] <Chipaca> I mean, the user can add files at any time
[20:41] <dobey> yes
[20:41] <dobey> and then M should increase
[20:41] <dobey> but we don't have a ContentQueued signal on dbus
[20:41] <Chipaca> so you're going to count files from the moment sd is turned on? that sounds silly
[20:42] <dobey> and i am trying to implement this with what's there, so i don't end up refactoring all of syncdaemon so i can have a ContentQueued signal on dbus
[20:42] <dobey> no
[20:42] <dobey> i'm going to do len(waiting_content())
[20:42] <dobey> and ideally increment that if it changes during the transfer period
[20:42] <Chipaca> dobey: but then it would always be "uploading file 1 of M"
[20:43] <dobey> Chipaca: no, both N and M would icrement, and i'm pretty sure users aren't going to be in an infinite state of adding files
[20:44] <dobey> especially since there is this whole "quota" concept
[20:45] <Chipaca> dobey: you can see those events under /Event if you start the sd with --send_events_over_dbus
[20:45] <Chipaca> also, note that should be "transferring", not "uploading", right?
[20:46] <Chipaca> dobey: (because the content queue is for both uploads and downloads)
[20:46] <dobey> Chipaca: no, it'll split uploads/downloads into different sets when i get that far
[20:46] <dobey> i'm tyring to actually understand how to get it done, before i try to do it though
[20:47] <Chipaca> dobey: that might be suboptimal from the user's perspective, but it's a design decision
[20:47] <Chipaca> dobey: ui design, I mean
[20:48] <Chipaca> dobey: anyway: see if those events do what you want; we can add something more specific to sd so they get out by default
[20:48] <dobey> not really, but it also doesn't really matter technically at the moment, becuase we only ever transfer 1 file at a time
[20:49] <Chipaca> dobey: I mean, if a user sees "downloading file 3 of 20", the expectation is probably for it to go on to 4/20, 5/20, and so on until it's finished
[20:49] <dobey> Chipaca: as far as i'm concerned, there are too many states already, adding all the events on top of that and getting flooded by event changes over dbus, is not ideal
[20:49] <Chipaca> dobey: and not to switch to uploading file 7/13
[20:49] <Chipaca> dobey: that's why I say, use this to see if it's what you need, and then we prune it down for you
[20:49] <dobey> Chipaca: if it alternatees, we should probably fix the syncdaemon to prioritize uploads
[20:50] <Chipaca> dobey: why?
[20:50] <dobey> because me uploading my 30 4k documents is probably more imporant than downloading the 300MB video of a panda sneezing that someone shared to me?
[20:50] <Chipaca> dobey: right now the user, over dbus, can prioritize things
[20:51] <dobey> how?
[20:51] <Chipaca> dobey: using reschedule_waiting
[20:53] <dobey> at this point i am just resolved that this branch isn't going to get done today anyway
[20:53] <dobey> so we can argue about it on monday over beer or something
[20:53] <Chipaca> beers are on beuno :)
[20:54] <dobey> srsly
[20:54] <dobey> it's all his fault anyway
[20:54] <Chipaca> dobey: you could just poll, to get the other parts done
[20:54] <dobey> i have a feeling polling would totally be screwy
[20:54] <Chipaca> dobey: totally
[20:54] <dobey> and that M would randomly increment or decrement
[20:54] <Chipaca> dobey: but it'll get you the info, and let you get the rest of the code in place
[20:55] <dobey> so an upload might finish and it would go down, and then the user added another file, and it would go back up the next time it was called
[20:55] <Chipaca> dobey: that M *will* randomly increment or decrement, if the M is the length of waiting
[20:55] <dobey> Chipaca: only if we keep calling waiting
[20:55] <dobey> Chipaca: if we call waiting once and then store the length, it's not going to change unless we specifically tell it to
[20:56] <Chipaca> dobey: that kinda assumes dbus delivers everything
[20:56] <Chipaca> damn, rain in pilar for sunday
[20:56] <dobey> heh
[20:57] <dobey> it's rained here every day for the past week almost
[21:00] <Chipaca> dobey: I think we should sit down with beuno and rework some of this to make the information we provide match what the syncdaemon has
[21:00] <dobey> afaik syncdaemon has the info, it's just not exposing it in the best ways
[21:00] <Chipaca> dobey: otherwise we'll be making stuff up, and at some point, in some scenario, lie to and confuse the user
[21:00] <dobey> we already do that
[21:01] <Chipaca> dobey: let's do less of it :)
[21:01] <Chipaca> adding stuff to sd to make it expose it properly is also part of what I tried to say we should do
[21:03] <dobey> i think i'll just finish fork^H^Hfixing oauth today