[09:13] <oly> hi, i am having problems syncing ubuntu one on one machine i have 09.10 and 10.04 on the other do the clients differ in these versions ?
[09:14] <oly> could this be the cause and if this is the case is there a ppa i can use to update 09.10 ?
[09:22] <popey> oly: does u1sdtool -s show that both machines are connected?
[09:23] <oly> i know the 10.04 machines are connected, but the 9.10 machine is not
[09:24] <oly> that command does not work by the way no -s parameter
[09:24] <oly> but intresting to know was not aware of that command
[09:25] <aquarius> u1sdtool is significantly nicer in 10.04
[09:25] <oly> in nautilus you hit connect and it does not even attempt to connect looking at it
[09:25] <oly> i am on the 9.10 machine curently
[09:25] <aquarius> in 9.10, you need to look at the log file, ~/.local/share/ubuntuone/log/syncdaemon.log, and see if it contains things that look like errors
[09:25] <oly> the 10.04 machine at home are connected and syncing nicely
[09:27] <oly> close file is actually located in ~/.cache/ubuntuone/log/syncdaemon.log on my machine
[09:27] <oly> state: STANDOFF_WAITING_WITH_NETWORK_WITH_BOTHQ
[09:27] <oly> has lots of those states from this morning
[09:29] <aquarius> er, yeah, .cache, sorry :)
[09:29] <aquarius> hm, if you're at standoff then (1) restarting the syncdaemon may help (2) you want to be talking to someone more knowledgeable about syncdaemon states than me :)
[09:30] <aquarius> https://wiki.ubuntu.com/UbuntuOne/Bugs may be useful, if you've not already read it
[09:30] <aquarius> and rye knows about this stuff more than I do, so he may be able to help when he wakes up
[09:33] <duanedesign> oly: is there anything in ~/.cache/ubuntuone/log/syncdaemon-exceptions.log
[09:34] <aquarius> aha, or duanedesign :)
[09:34] <oly> nope seems to be empty
[09:34] <duanedesign> his ears must of been burning :)
[09:34] <duanedesign> hello rye
[09:34] <rye> duanedesign, hello, i am about to upload "The art of unsuspending" :)
[09:35] <duanedesign> oly: could you pastebin the syncdaemon.log
[09:35] <oly> i just killed the sync deamon now the icon correctly shows not connected :p
[09:35] <oly> yeah
[09:35] <duanedesign> http://ubuntu.pastebin.com/
[09:35] <rye> duanedesign, http://picasaweb.google.com/lh/photo/E9ukoCzOnTd8x0O5OJHqMw?feat=directlink
[09:36] <duanedesign> rye: I like the wallpaper :P
[09:36] <rye> duanedesign, desktopcouch did not start eating my CPU after unsuspend but I got an awesome wallpaper, right.
[09:37] <oly> http://paste.ubuntu.com/383571/
[09:37] <oly> thats part of it but its the same messages repeated
[09:38] <rye> bug 487257 ?
[09:39] <rye> duanedesign, oly - I believe there is disconnect info somewhere
[09:40] <oly> it looks like it may be fixing itself
[09:40] <oly> i killed the sync daemon and have reconnected
[09:40] <oly> now says syncing
[09:40] <oly> although the applet seems to get confused between if its connected or not
[09:44] <duanedesign> oly: can you run: dpkg -l ubuntuone-client
[09:44] <oly> http://paste.ubuntu.com/383575/
[09:44] <duanedesign> check whick version you have?
[09:44] <oly> that may be a more usfull error log as it has a division by zero error :)
[09:44] <duanedesign> aha
[09:44] <oly> 1.0.3-0ubuntu1
[09:45] <duanedesign> oly: check your preferences
[09:45] <oly> already disabled the throttling
[09:45] <oly> because of that error
[09:45] <duanedesign> ok
[09:47] <duanedesign> oly: you might also want to delete ~/.config/ubuntuone/syncdaemon.conf
[09:47] <oly> done
[09:48] <duanedesign> bug 509740
[09:49] <duanedesign> oly: you might of already saw that. But thats the bug related to the error
[09:53] <oly> yeah, now i recons i am connected and my files are in sync which they most certainly are not :/
[09:53] <oly> i shall have a look a bit later though
[09:55] <duanedesign> oly: you can run : u1sdtool --current-transfers
[09:55] <duanedesign> to check current transfers
[09:56] <oly> says 0 and 0
[09:57] <oly> i am attempting the nirvana option
[09:58] <rye> duanedesign, oly - could you please give me some info on what is happening?
[09:58] <rye> please :)
[09:58] <duanedesign> rye: he had 509740
[09:58] <duanedesign> http://paste.ubuntu.com/383575/
[09:59] <duanedesign> turned off 'limit bandwidth'
[09:59] <rye> aha, float division due to 0 in one of the fields
[09:59] <duanedesign> and deleted syncdaemon.cnf
[09:59] <duanedesign> thats about where we are
[09:59] <oly> i also have 2 machines at home which are 10.04 and one here which is 09.10 that the newer ones are syncing fine
[10:00] <oly> was not sure if it was version differences
[10:00] <popey> is u1 known to be flaky behind a proxy?
[10:00] <oly> u1sdtool -w recons my network connection is broken
[10:01] <duanedesign> oly: you might try quiting the client by r-clicking the applet. Running u1sdtool -q to quit the syncdaemon
[10:01] <popey> oops, sorry, I'll wait until oly is finished
[10:01] <oly> Failure: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[10:01] <oly> that was with the wait command
[10:02] <oly> i have quit using -q and tried again with -w and its given same error
[10:03] <duanedesign> ok
[10:04] <duanedesign> oly: ps uaxxc | grep ubu
[10:04] <duanedesign> anythingcome back?
[10:05] <rye> oly, the syncdaemon has a bit long startup before it can service dbus requests. Therefore dbus requests time out, then syncdaemon goes up completely, says "huh?" and continues working properly
[10:05] <oly> ubuntuone-clien and ubuntuone-syncd
[10:05] <oly> i wonder if it could be todo with my msn problems as well
[10:06] <oly> sometimes here msn will refuse to connect, i get arround it by sshing to a remote machine and forwarding pidgin from my machine at home
[10:07] <oly> never figured out what stops msn from connecting as everything else seems to work with out a hitch
[10:08] <oly> but i guess what ever stops msn connecting could be causing the same problem for ubuntu one
[10:09] <duanedesign> oly: are you getting the same: STANDOFF_WAITING_WITH_NETWORK_WITH_BOTHQ
[10:09] <duanedesign> in your syncdaemon.log ?
[10:10] <oly> state: READY_WITH_NETWORK_WITH_BOTHQ; queues: metadata: 54; content: 53; hash: 0, fsm-cache: hit=71823 miss=137608
[10:10] <oly> curenttly got that no sign of the other error
[10:13] <rye> oly, this means that you needs to connect via applet
[10:16] <duanedesign> popey: bug 387308
[10:17] <popey> aw shame
[10:17] <popey> i cant even open ubuntuone-preferences
[10:17] <popey> it barfs
[10:27] <popey> i have filed bug 527658 if you believe it's a dupe of 387308, so be it
[11:45]  * rye reboots, suspend broke video :(
[15:11] <vds1> Desktop+ MEETING BEGINS aquarius beuno CardinalFang Chipaca dobey jblount teknico urbanape ?
[15:11] <Chipaca> me
[15:12] <teknico> me
[15:12] <beuno> me
[15:12] <dobey> meh
[15:13] <vds1> me
[15:15] <CardinalFang> me
[15:16] <urbanape> memememe
[15:16] <teknico> the meme of me
[15:21] <dobey> yawn
[15:21] <Chipaca> DONE: looking at oauthdesktop and hmm'ing a lot. Also: removing note edition from web until we fix it. TODO: push note edition removal branch. Crack down on oauthdesktop. BLOCKED: no. NEXT: teknico.
[15:21] <teknico> DONE: did more reviews; found a workaround for the funambol DNS/haproxy/exchange problem in production with the L0SAs, and phone sync finally worked! (#511316)
[15:21] <teknico> TODO: fixing more deployment and web ui bugs; showing the web desktop+ guys around our phone sync code
[15:21] <teknico> BLOCK: none
[15:21] <teknico> next: beuno
[15:22] <beuno> DONE: Half-did a lot of things. Debugged with funambol support the duplicate checking, started a branch to show more information about your phone in the index
[15:22] <beuno> TODO: Continue pursuing dupe prevention, finish and land the phone details branch
[15:22] <beuno> BLOCKED: Yes, on funambol
[15:22] <beuno> next: dobey
[15:23] <dobey> ☺ DONE: Removed connect button from Nautilus, Started adding Connect to CP
[15:23] <dobey> ☹ TODO: Finish branch to add Connect to CP, Finish the rest of the CP work
[15:23] <dobey> ☹ BLCK: None.
[15:23] <dobey> vds1: roll
[15:23] <vds1> DONE: landed one_pwd_generation branch, rolled back patch_13, investigated on contact dups but stopped as local sync is broken, investigated on broken local sync and filed a bug, investigated on broken production sync, reviewed some bugs, started #498324
[15:23] <vds1> TODO: finish #498324 re-land patch_13, re-start invetigating on dups as soons as the problem can be reproduced
[15:23] <vds1> BLOCKED: no really
[15:23] <vds1> CardinalFang please
[15:24] <CardinalFang> aw, crap, not ready.  urbanape take my spot.
[15:25] <urbanape> DONE: nailed most of the ajaxy goodness for funambol phone choice
[15:25] <urbanape> TODO: little smoothy bits (spinners, &c) and CSS lovin'
[15:25] <urbanape> BLOCK: None
[15:25] <urbanape> CardinalFang, whenever you're ready
[15:28] <CardinalFang> DONE: worked on desktopcouch-service noticing when couchdb is listening on a different port, and change its zeroconf advertisements and replication.  tested get-port branch more.  fixed bug with dbus attempting communication before we are ready, with help from james_w.
[15:28] <CardinalFang> TODO: get reviews on get_port branch.  release to kenvandine.
[15:28] <CardinalFang> BLOCKED: None
[15:29] <CardinalFang> maybe-TODO: help thisfred and mthaddon diagnose couchdb on server
[15:29] <CardinalFang> that's all from me.
[15:30] <popey> is it possible to start syncdaemon on the command line? I want to run it in foreground
[15:31] <verterok> popey: /usr/lib/ubuntuone-client/ubuntuone-syncdaemon -h
[15:31] <popey> i have looked at that
[15:31] <verterok> popey: if you want debug logs to stdout: /usr/lib/ubuntuone-client/ubuntuone-syncdaemon --debug
[15:31] <popey> ok, thats non-obvious
[15:32] <popey> i would have expected a --no-daemon or something
[15:32] <popey> thanks
[15:33] <verterok> popey: the daemon itself doesn't fork, it's usually executed in background becasue it's started via dbus activation
[15:34] <popey> I'm trying to run it behind a horrid proxy, and have made a magick network, but can't get syncdaemon to use it
[15:34] <kklimonda> hmm.. how can I check sync progress in lucid?
[15:35] <popey> ooo, made it work
[15:35] <popey> yay
[15:37] <duanedesign> kklimonda: u1sdtool --current-transfers
[15:38] <kklimonda> duanedesign: thanks
[17:40] <bollullera> hello everybody!
[17:43] <duanedesign> hello bollullera
[17:51] <rye> re: proxy. It is possible to run syncdaemon behind the proxy, but it requires some configuration changes that are not supported
[17:52] <rye> but it is not possible to run desktopcouch with proxy for now, I haven't yet figured out how to make that work properly. It will definitely require source code changes
[17:52] <rye> ok
[17:52] <rye> me is back and full of energy to do things
[17:54]  * rye is going to vm fullscreen (I have only one display :( ) to test note sync XML/HTML issue again
[18:05]  * CardinalFang tries landing a bunch of desktopcouch branches.
[18:06] <CardinalFang> mandel is a mad-man!
[18:22] <CardinalFang> mandel!  Hi.  I was landing code and I have a complaint about one of your patches.  I want to make sure I'm sane.
[18:22] <mandel> CardinalFang, hehe I've noticed
[18:23] <mandel> CardinalFang, let me take a look
[18:23] <CardinalFang> mandel, thisfred, aquarius, re-review  https://code.edge.launchpad.net/~mandel/desktopcouch/fix_bug_517676/+merge/18708 ?  Previously approved.
[18:23] <thisfred> CardinalFang: ouch, I totally got sidetracked on your other review too
[18:26] <thisfred> CardinalFang: I think it may contain the _rev, actually. Admittedly that's because python-couchdb does something VERY unexpected, which exploded my brain elsewhere
[18:26] <thisfred> basically:         self.db[record.record_id] = record._data
[18:27] <thisfred> will modify record._data to contain the new _rev
[18:29] <mandel> thisfred, CardinalFang, indeed python couchdb will do that and that is why I filled the bug, it would be stupid to retrieve the code gain
[18:29] <CardinalFang> I am going to verify that.  If it does, put_record has been wrong forever and at least two other parts of d-c can be cleaned up.
[18:30] <thisfred> CardinalFang: that may well be, as I only learned of this behavior when it broke something on the server
[18:30] <mandel> CardinalFang, I'll take a look too, just o make sure I did not understood python-couch wrong
[18:30] <thisfred> meanwhile reviewing that other branch
[18:30]  * CardinalFang prepares to eat his hat.
[18:30]  * thisfred hands CardinalFang salt and pepper shakers
[18:31] <CardinalFang> I suspect it's salty enough.
[18:31] <mandel> :D
[18:31] <mandel> look at line 323 at client.py
[18:32] <mandel> thisfred, CardinalFang, that is updating the _id and the _rev, right?
[18:33] <CardinalFang> Indeed.
[18:34] <CardinalFang> Side-effects on __setitem__.  I'd puke if it weren't so useful.
[18:34] <CardinalFang> Okay, I withdraw my second complaint.
[18:34] <mandel> CardinalFang, hehe I just discovered by chance
[18:35] <mandel> CardinalFang, give thisfred and mandel a complement in the comment ;)
[18:35] <CardinalFang> First complaint is that we've documented this behavior for a while.
[18:35] <mandel> Indeed but asking people to perform extra requests when they do not need to is very ugly
[18:35] <thisfred> CardinalFang: yes, but I can't think of a backward compatible way to fix it.
[18:36] <thisfred> and I think we do want to fix it asap
[18:36] <thisfred> rather than lucid + x
[18:36] <thisfred> I don't know if it merits a freeze exception
[18:37] <CardinalFang> I think we need another method.  put_record_and_update()  ?
[18:38] <mandel> CardinalFang, doing the same but returning the record??
[18:39] <mandel> CardinalFang, from a coding point of view I'd complain, on the other hand for backward compatibility... which apps will be affected? gwibber?
[18:40] <thisfred> CardinalFang: note that if someone passes a record into this one and keeps reference to it, it *already* updates it
[18:40] <CardinalFang> Literally nothing that uses put_record() currently will continue to work.  We have to get the new record_id to do anything currently.  Everyone is using that.
[18:40] <CardinalFang> thisfred, Yeah, I was just noticing that.
[18:41] <thisfred> and always has done so
[18:41] <thisfred> So, ok, I can live with moving this into a new method, I think that's a compromise that will keep everyone mildly unhappy
[18:41] <thisfred> mandel: ?
[18:42] <thisfred> (I have to go walk the dog now, bbiab)
[18:42] <mandel> thisfred, agreed, move it to a new method to keep backwards comp but put a warning in the old one
[18:42] <mandel> at least people will know there is a "better" way to do it
[18:42] <mandel> CardinalFang: ?
[18:44] <CardinalFang> A note in the comments, and changing the docs, but no programmatic warning yet.  Maybe next version.
[18:45] <mandel> CardinalFang, ok, but I'll keep an eye on that bug since is a pain in the ass in some cases
[18:46] <aquarius> *nod* No breaking backwards compatibility. Good decision, CardinalFang/thisfred
[18:47] <aquarius> (sorry I've not been available to be part of that discussion)
[18:48] <mandel> blah, I've been outnumbered :P
[19:05] <mandel> CardinalFang, aquarius, thisfred, what do you think about the following: http://pastebin.ca/1810531
[19:06] <mandel> I've got something similar in my code and other people might find it useful
[19:06] <aquarius> that's an implementation of schemas. I don't like schemas :(
[19:06] <aquarius> I certainly can see how it's useful, I just don't like the idea of baking support for it into desktopcouch, because it's against the philosophy. But I'm happy to be talked out of it :)
[19:06] <mandel> aquaris, I knew your were going to do that...
[19:06] <aquarius> mandel, well, yeah :)
[19:06] <aquarius> we're at opposite ends of the spectrum on this ;)
[19:07] <mandel> aquarius, if you bring up AC/DC I'll go off line ;)
[19:08] <mandel> aquarius, anyway, I'm using it because is a pain in the ass to be accessing application annotations all the time with by code... ofcourse it has a problem, you need to provide the app name
[19:09] <aquarius> *nod*
[19:10] <aquarius> that's the same thing as, say, calling D-Bus, though; you need to do it there, too.
[19:10] <aquarius> If you wanted to be particularly magic, you could default appname to the actual name of the executable
[19:11] <mandel> indeed, but providing the app_name is certainly better
[19:11] <rye> reproduces note misbehavior, now with complete STR
[19:13] <mandel> aquarius, I'll put the code in a post out there in case people want to use it
[19:13] <aquarius> mandel, yeah, definitely -- I've certainly got no problem with someone (you?) building a wrapper library on top of DC which offers things like StrictRecord. People are likely to find that useful
[19:14] <aquarius> and that's a good way to show that I'm wrong and it should be in DC core, too -- if loads of people find the library useful, then it's clearly something we should think about including. that's what happened with python and urllib2
[19:15] <mandel> aquarius, ok, you just convinced me, I'll put it somewhere as an add-on or something
[19:15] <aquarius> mandel, you ge tthe satisfaction of laughing at me when I'm wrong, which is not to be underestimated :)
[19:16] <aquarius> mandel, feel free to edit the desktopcouch documentation to point at docs for your wrapper library, too
[19:18] <mandel> aquirius, I'll think about it, but I doubt I'll point to my code from here without your agreement, I hate self-promotion :P
[19:19] <aquarius> mandel, you have my agreement :)
[19:19] <aquarius> __lucio__, *nice* work on the windows port
[19:20] <__lucio__> aquarius, thanks. its still missing some stuff: filesystem monitoring, dbus replacement and proper testing
[19:20] <__lucio__> but at least it downloads stuff
[19:20] <__lucio__> ill try to propose this as soon as i clean up the tests
[19:20] <aquarius> __lucio__, that's amazing. I almost wish I ran windows just so I could try it :)
[19:21] <__lucio__> aquarius, no, you dont :)
[19:21] <aquarius> well, OK, that was a white lie, I admit it. I like Ubuntu :-)
[19:22] <till> __lucio__: not sure if you know, but dbus master works fine on Windows
[19:22] <__lucio__> till, but thats not very "windows", is it?
[19:22] <till> Well, depends what your goal is.
[19:23] <__lucio__> till, im afraid that trying to use dbus from a file explorer extension may be a mess
[19:24] <till> Possibly, yes, you can probaby judge that better than me, just thought I'd point out that it does, in fact, work fine :)
[19:25] <thisfred> mandel: re: schema's I'm with aquarius mostly. I'd use the mappings to transform from and to application data, and add more mappings where needed
[19:25] <thisfred> mandel: you know that the fieldmappings already put unrecognized fields in the correct application annonations namespace, right?
[19:26] <mandel> thisfred, nope, I did not know about those, where are they?
[19:26] <thisfred> mandel: look at the doctest in desktopcouch/doc/
[19:29] <mandel> thisfred, I remember now, you show them to me before, I completely forgot about them
[19:40] <thisfred> mandel: they're basic, but they're in use on the server, and I'm happy to help expand them with whatever client developers need
[19:41] <CardinalFang> mandel, thisfred, aquarius, I think this is sufficient.  https://code.edge.launchpad.net/~cmiller/desktopcouch/put_record_documented_more/+merge/20166
[19:41] <thisfred> and they impose nothing on the client application, nor any new restrictions on the record format
[19:41] <mandel> thisfred, I'm actually thinking of using them in a special thing I'm writing right now, let me a couple of days and I'll bother you about them
[19:42] <thisfred> mandel: ok, great! :)
[19:47] <rye> ok. notes are definitely not converted during sync. Me is extremely sure and has performed a lot of time-consuming tests.
[19:47] <rye> aquarius, is the method planned for dc to have replication done on dbus request, in order not to wait for 10 minutes for the miracle to happen?
[19:49] <rye> joshuahoover, just verified note conversion during sync in tomboy - it is not happening. HTML nodes are not converted to XML if they are stored in HTML on server side
[19:49] <aquarius> rye, not sure -- CardinalFang will know
[19:50] <joshuahoover> rye: and you were able to do this following your steps for bug #527335 ?
[19:50] <rye> joshuahoover, i have added a document and a link to pastebin that was used for testing
[19:51] <CardinalFang> rye, it will spawn replication after changes only, using the _changes interface.  Not very soon.
[19:51] <CardinalFang> In Murderous Marmot or whaterver
[19:52] <joshuahoover> rye: cool...if these are the steps to reproduce, can you update the description so that it's clear these are the best steps to use to try to reproduce the bug?
[19:52] <rye> joshuahoover, updating...
[19:52] <joshuahoover> rye: thanks!
[19:58] <rye> joshuahoover, update finished
[19:59] <joshuahoover> rye: perfect! thank you!
[20:00] <rye> Did you know that you can use Bug:12345 format to specify a link to LP bug at wiki.ubuntu.com? No need to remember http://bugs.launchpad.net/bugs/12345 !
[20:00]  * rye needs to pick a better random number next time
[20:00] <CardinalFang> 1 is good
[20:01] <CardinalFang> Bug:1
[20:01] <rye> CardinalFang, 1 is not that random.
[20:01] <CardinalFang> No specific number is random.
[20:02]  * rye will use random bug number generator
[20:29] <mandel> CardinalFang, I'll take a look at the merge problems
[20:33] <rye> hm
[20:46] <mandel> CardinalFang, when a merge is not longer needed is it better to delete or to reject?
[20:46] <CardinalFang> Superceded, I think.
[20:46] <CardinalFang> I don't know if that's an option.
[20:47] <mandel> CardinalFang, I don have the right, can you do that for: https://code.launchpad.net/~mandel/desktopcouch/fix_bug_519922/+merge/19029
[20:49] <sanderqd> just to check: ubuntuone doesn't store the ~/Ubuntu One files in a couchdb database, right?
[20:49] <CardinalFang> No, sanderqd.
[20:49] <sanderqd> ok, thanks
[20:49] <CardinalFang> couchdb synch and file synch are separate.
[21:17] <mandel> CardinalFang, fixed https://code.edge.launchpad.net/~mandel/desktopcouch/batch_update/+merge/17482 it should work ok now
[21:18] <CardinalFang> mandel, thanks!
[21:18] <mandel> CardinalFang, as soon as that is merged all fix fix_bug_519873/+merge/19018
[22:37] <espen77> i am not able to connect to ubuntuone for some reason, have a fresh lucid a3 and neither files or tomboy can sync, but i can register the computer and it shows how much space on u1 used, any ideas?
[22:40] <mandel> CardinalFang, before I go, I revised https://code.edge.launchpad.net/~mandel/desktopcouch/fix_bug_519873/+merge/19018 as shoul dbe ok now, but since I use lucid I get the fails reported by John, good night