[00:02] <hackel> I copied 750 files of about 11M total into my Ubuntu One directory, and syncd appears to be caught in some kind of loop, using 100% cpu and calling calculate_hash over the same two directories over and over again.  Any ideas?
[00:12] <__lucio__> hackel, put ubuntuone in debug, restart and contact facundobatista (tomorrow)
[01:42] <facundobatista> hackel, don't, we already have a bug about that
[01:42] <facundobatista> hackel, it's a known issue... stop the client and restart it
[01:43] <facundobatista> hackel, and avoid renaming a directory from .u1conflict to a non-conflict name
[01:43] <facundobatista> hackel, if you're interested, I can point you to the relevant bugs, for you to mark them as "it happens to me too"
[01:43] <facundobatista> __lucio__, ^
[13:38] <rtgz> https://wiki.ubuntu.com/UbuntuOne: This protocol is built on top of Google Protocol Buffers (a sort of fast binary XMLish schema language). This abstraction is to allow extension of the u1storage protocol with breaking compatibility.
[13:38] <rtgz> wow
[14:21] <JGJones> Hello
[14:21] <JGJones> I'm having a bit of an issue logging into Ubuntu One via the website on Windows
[14:21] <JGJones> Headed to http://one.ubuntu.com and then clicked on Sign in.
[14:22] <JGJones> I log in successfully and I am taken back to the Ubuntu One homepage and it is still showing the same original page (Sign in) - how do I access my files?
[14:27] <verterok> JGJones: hi, what browser are you using?
[14:27] <rtgz> JGJones, could you please provide the version of you rbrowser?
[14:27] <rtgz> verterok, ops, me is too slow today :)
[14:27] <JGJones> sorry forgot to add that - latest version of Firefox
[14:27] <verterok> rtgz: :)
[14:27] <JGJones> And I'm on Windows Vista
[14:27] <JGJones> I'm primarily after my Tomboy notes here.
[14:28] <rtgz> JGJones, are you able to browse https://one.ubuntu.com/notes/ directly?
[14:29] <JGJones> Ah yes I am thanks
[14:29] <JGJones> that solve my problem - although the log in process is a tad broken?
[14:29] <verterok> JGJones: I just login and it worked, FF3.5 @ Ubuntu
[14:30] <rtgz> probably the log in process got some redirect loop, i.e. openid login targeted the sign in page...
[14:30]  * rtgz checks on win 7 (emulated, so don't worry :) )
[14:30] <verterok> JGJones: you can try removing the cookies
[14:30] <JGJones> verterok, I'm on Windows Vista - however I did not have any problem on Ubuntu last time I did it.
[14:31] <JGJones> Will try deleting cookies later on.
[14:31] <rtgz> verterok, no, it is not cookies
[14:31] <verterok> rtgz: you can reproduce it?
[14:31] <rtgz> verterok, otherwise it would not be possible to access notes directly.
[14:33] <JGJones> rtgz, did you get the same issue in Windows 7?
[14:33] <rtgz> verterok, JGJones hey, i am still starting it... And it is already asking things about my virtual network and whether I like to allow firefox update to update my system...
[14:34]  * JGJones goes to fire up Ubuntu - my notes aren't sync'ed...the one I wanted isn't there. Oh well.
[14:35]  * rtgz is all for 'Synchronize Now!'-free notes syncing, simply to local CouchDB
[14:38] <dobey> JGJones: clearing cache might help too
[14:38] <rodrigo_> rtgz: that's coming soon, hopefully
[14:39] <JGJones> rtgz - windows 7 can't still be starting up?
[14:39] <rtgz> JGJones, nope, not reproducible and I don't think it is windows-specific, to be honest
[14:39] <JGJones> Hmm ok
[14:40] <JGJones> I'll clear out my cache and see if I can do it again
[14:40] <rtgz> rodrigo_, yep, it is possible to set up a service that will read the .notes and put them to couchdb and fetch the updates from couchdb into notes but the applications might not be that happy about the files being changed while they are running...
[14:41] <JGJones> OK panic's over folks
[14:41] <rodrigo_> rtgz: well, the idea is to make tomboy write to couchdb directly
[14:41] <rtgz> JGJones, were you redirected to the launchpad OpenID login page or the original ubuntuone page telling you to back up your life with the big SIGN IN button?
[14:41] <JGJones> Just cleared out cache and things was fine once more.
[14:41] <rtgz> rodrigo_, please please pick GNote :)
[14:42] <rodrigo_> rtgz: I won't, but you can if you want :D
[14:42] <JGJones> rtgz, When I went to Ubuntu One home page - clicked on the Big Red Sign In button - and was taken to the launchpad login page. I then logged in successfully and I was taken back to the ubuntu one home page...with the Big Red Sign In button.
[14:43] <JGJones> After clearing out the cache - it works as expected - logging in takes me to the files page.
[14:43] <rtgz> JGJones, okay... trying to reproduce...
[14:43] <JGJones> so flushing out cache worked - although what caused it to not work in first place before clearing cache I have no idea.
[14:44] <dobey> i think perhaps firefox incorrectly caches the login page, and the redirect after successful log-in causes it to load the wrong page from cache
[14:48] <rtgz> dobey, the return_to should go to https://one.ubuntu.com/auth/complete/?janrain_nonce and afterwards the redirect is to https://one.ubuntu.com and yes, it is possible that the subsequent /files redirect failed. Just got it in lynx
[14:48] <rtgz> dobey, no idea whether lynx is supported or not :)
[14:48] <dobey> rtgz: i know what it *should* do
[14:49] <rtgz> dobey, I believe you are in Foundations+, right ?
[14:49] <dobey> no
[14:50] <JGJones> well hope mine's just one of those random rare case
[14:50]  * rtgz knows three new words, Desktop+, Foundations+ and Ops+ and tries to apply them whenever possible...
[15:00] <jblount> Desktop+ MEETING BEGINS
[15:00] <jblount> Hello: dopey CardinalFang Chipaca jblount rodrigo_ teknico thisfred, time for a meeting! Please respond with "me". We'll go in that order repeating statuses in the format: DONE / TODO / BLOCKED
[15:00] <thisfred> dopey? :)
[15:00] <jblount> Heh
[15:00] <aquarius> thisfred does not belong to us ;)
[15:00] <rodrigo_> :)
[15:00] <jblount> Or his smarter and more aware cousin dobey
[15:00] <rodrigo_> me
[15:00] <teknico> me
[15:00]  * jblount is going to cut his fingers off later and try out some speech to txt software
[15:00] <jblount> me
[15:01] <aquarius> me
[15:01] <vds1> me
[15:01] <teknico> jblount, maybe only the second part, pretty please?
[15:01] <dobey> me
[15:02] <jblount> teknico: :)
[15:03] <jblount> rodrigo_: At your leisure!
[15:04] <rodrigo_> • DONE: Contacts picker. More music store discussions
[15:04] <rodrigo_> • TODO: Conflict resolver tool in pair tool. Look at becoming a MOTU (https://wiki.ubuntu.com/UbuntuDevelopers). Make sandy's snowy test suite work with our server (http://git.gnome.org/cgit/snowy/tree/api/tests.py). Discuss with jdo and aquarius about oauth token per app, not per machine?
[15:04] <rodrigo_> • BLOCKED: no
[15:04] <rodrigo_> teknico: go!
[15:04] <teknico> DONE: started exposing SMS methods in Funambol Server API (#381398), discussed various Funambol issues with Funambol people, done some reviews
[15:04] <teknico> TODO: do more reviews, finish exposing SMS methods in Funambol Server API (#381398), triage my 20 bugs
[15:04] <teknico> BLOCK: none
[15:04] <teknico> next: jblount
[15:04] <jblount> DONE: Got a branch sorted to fix a bunch of bugs that kept dropping off my radar
[15:04] <jblount> TODO: Land that branch, get started on some polish for the /files/ ui that has been on my todo list for a while
[15:04] <jblount> BLOCKED: Seriously considering doing my normal run with a gorilla mask on. I can't make my mind up abut whether or not I would survive the whole run, or if I would have to take off the mask because of heat exhaustion.
[15:04] <jblount> aquarius: ACK!
[15:04] <aquarius> ⚀ DONE: music store planning; music store user flows mockup
[15:04] <aquarius> ⚁ TODO: look at oauth-enabling twisted; make tomboy first-sync experience nicer; continue work on desktopcouch developer docs; write up things learned at UDS/sprint; work with rodrigo on Music Store, much more music store architecture planning; talk to thisfred and vds about sequence numbers etc
[15:04] <aquarius> ⚂ BLOCKED:
[15:04] <aquarius> vds1: go
[15:04] <vds1> DONE:updated bugs about migration to funambol v8 working on a branch to close #381398 mail to funambol support, skype with funambol, support ticketing with funambol support...ok you got it....
[15:04] <vds1> TODO: finish the branch, talk with Chipaca and mattgriffin about clients,
[15:04] <vds1> BLOCKED: nope
[15:04] <vds1> dobey: go go go
[15:04] <dobey> ☺ DONE: Triage, Arguing with Aquarius (it builds empires), Review of U1 Application Spec
[15:04] <dobey> ☹ TODO: Finish Backporting, Triage, Prepare releases/SRUs
[15:04] <dobey> ☹ BLCK: None.
[15:05] <dobey> urbanape: wake up, before you go go
[15:05]  * aquarius laughs
[15:05] <dobey> jblount: you forgot him btw :)
[15:05] <CardinalFang> DONE: attachments API work.
[15:05] <CardinalFang> TODO: more attachments work.  Get it right the first time.
[15:05] <CardinalFang> BLOCKED: None
[15:07] <dobey> jblount: re: gorilla suit, be wary of other gorillas searching for a mate
[15:07] <jblount> dobey: I also called you dopey, I'm a bucket of broken today.
[15:08] <jblount> dobey: Good point about gorillas-in-heat. Maybe I should skip the mask until I can confirm the amount of local apes.
[15:08] <aquarius> CardinalFang, hey, nice, attachments stuff :)
[15:09] <dobey> jblount: i don't know if you have any banana trees in mt. dora either, so you might starve
[15:12]  * dobey discovers a new genre of music via spam
[15:13] <rmcbride> dobey: actually bananas grow pretty well here
[15:13] <dobey> rmcbride: i know. cypress gardens had plenty.
[15:13] <rmcbride> hmm. I totally need to get some banana plants
[15:14] <urbanape> DONE: Sick kid. Before that, keeping the dream of our new lazr-jsified ubuntuone-servers branch alive, still need to do a better job with lazr-js as a sourcedep (or full-on .deb)
[15:14] <urbanape> soz, all
[15:14] <urbanape> TODO: Go over my bug list. It's growing.
[15:14] <urbanape> BLOCK: None
[15:14] <dobey> rmcbride: i don't know if many people have them planted in suburban areas though :)
[15:14] <rmcbride> dobey: my neighbors across the street have a plant I'm looking at now. It's about 20 feet tall
[15:14] <rmcbride> or maybe more
[15:15] <dobey> nice
[15:15] <dobey> i wonder if i could grow one here
[15:17] <aquarius> blimey, I'm meant to hack on lazr.js, aren't I?
[15:17] <aquarius> had better do that. urbanape, if there's anything you'd like me to pick up there, let me know
[15:18] <urbanape> aquarius: I wouldn't mind pairing with you on it
[15:18] <aquarius> urbanape, happy to do so, when you're free
[16:23]  * rtgz came with peace, from Empathy...
[16:24] <rtgz> nope, my logger does not pick up IRC conversation, sad :(
[16:30] <rtgz> re: bug #412716
[16:32] <aquarius> ?
[16:32] <aquarius> is that the right number? :)
[16:33] <rtgz> aquarius: yes, is there any image-like pastebin around here? :)
[16:33] <rtgz> okay, will put to my local web server
[16:33] <aquarius> imageshack.us?
[16:33] <rtgz> http://buzz.rtg.in.ua/~rtg/truncating.png
[16:34] <aquarius> rtgz, ah, I know that that bug number is right about the problem
[16:34] <aquarius> I just don't understand what that's got to do with your logger not picking up IRC conversation :)
[16:35] <aquarius> (also, add that image to the bug?)
[16:35] <rtgz> so, re: the bug above - this looks pretty strange, to have filenames shortened in such a manner. This is a full-screen window on 1280x800 in firefox with pretty much default fonts
[16:35] <rtgz> the logger is a completely separate thing, just needed some channel other than xmpp to test. Since this is my favorite.... :)
[16:36] <aquarius> heh, gotcha
[16:36] <aquarius> yeah, it's obviously a bug
[16:36] <aquarius> jblount may be your chap for that, or urbanape
[16:37] <rtgz> aquarius: it is just reminds me about 8.3 filenames
[16:37] <jblount> rtgz: Yeah, the file names are too short. I've worked out what I'm going to do, just haven't landed the changes yet.
[16:38] <aquarius> I thought jblount would already be on the case :P
[16:38] <jblount> I'm planning on using a format similar to what gmail does, letting the filename trail off when it hits the edge of the row there.
[16:38] <rtgz> jblount: ah, it's just it was marked as Fix Released, so I thought that it is too late :)
[16:38] <jblount> At present I think we're being too clever and ending up making it yucky for most people.
[16:39] <rtgz> jblount: 01-massi…ng).mp3
[16:39] <rtgz> jblount: radiohea…ice.ogg
[16:40] <rtgz> pretty much strange filenames for the audio files :)
[16:40] <jblount> rtgz: You're seeing a "?" in the file name? That should be an ellipsis ("...")
[16:40] <aquarius> it is an ellipsis
[16:40] <rtgz> the process of finding the right file starts to be much more interesting...
[16:40] <aquarius> jblount unicode fail :)
[16:41] <jblount> lame
[16:41] <aquarius> jblount, xchat-gnome shows it as an ellipsis
[16:41] <rtgz> the first is massive attack by teardrop (theme song) and the second is Radiohead, Karma Police :)
[16:41] <aquarius> rtgz, is that first one Daydreaming by Massive Attack?
[16:41] <aquarius> ha!
[16:41] <aquarius> wrong MA song.
[16:42] <rtgz> aquarius: almost there, teardrop by massive attack :)
[16:42] <jblount> aquarius: Stupid terminal window in propietary operating system that runs photoshop shows a "?" :p
[16:42] <rtgz> jblount: it does not add readability too :)
[16:42] <aquarius> jblount, there is a lesson, there ;-)
[16:42] <jblount> aquarius: Noted!
[16:43]  * aquarius grins
[16:43] <aquarius> I get ellipses, you get Photoshop
[16:43] <rtgz> so, should I attach my screenshot of the scary filenames?
[16:43] <aquarius> sounds like a fair division, to me
[16:44] <rtgz> and I bet I can make a full folder of files with filenames that look like duplicates on the web ui... ;-)
[16:45] <urbanape> rtgz: there's a second bug about making the truncation longer
[16:45] <urbanape> but that bug is definitely done
[16:46] <rtgz> urbanape: ah, so it started showing ellipses, but filenames became too short so that new bug says they should be longer, right?
[16:46] <urbanape> rtgz: bug #451997
[16:46] <jblount> That's what i get for not checking in to see what bug we're talking about!
[16:46] <urbanape> d'oh
[16:46] <urbanape> private
[16:47] <urbanape> why can't I make it public?
[16:47] <rtgz> urbanape: Re bug #443121 - the tests here on a local pc also show the firefox is running instead of hanging :)
[16:47] <urbanape> are you running my PPA package?
[16:48] <jblount> urbanape: webkit
[16:48] <jblount> https://bugs.edge.launchpad.net/ubuntuone-servers/+bug/451997/+index
[16:48] <urbanape> jblount: aha
[16:48] <urbanape> yeah, in Chromium
[16:48] <jblount> urbanape: To be more clear, in webkit browsers the little edit icon doesn't show up.
[16:48] <urbanape> that seems suboptimal
[16:50] <rtgz> urbanape: yes, i am using the ppa version, however I don't understand how the bookmarks get organized, what are being synced, but that is completely another question.
[16:51] <jblount> urbanape: Yeah, it's a known issue with a bug though.
[16:51] <urbanape> well, we had an intentional goal of having no UI. Currently, we just sync all bookmarks to the desktop couchdb.
[16:52] <urbanape> rtgz: we don't (yet) preserve the hierarchical ordering of bookmarks between machines using the same profile, but that's coming soon.
[16:52] <urbanape> the unresponsiveness issues sorta trumped all development in that direction.
[16:52] <urbanape> and I'm still a little unhappy with the current state of it. It cuts down the amount of work Bindwood does, but still causes a PITA lag on the first sync.
[16:53] <urbanape> (for anyone with lots of bookmarks)
[16:59]  * rtgz *whispers* favicons :)
[17:00] <rtgz> and one more, urbanape, does deleting a bookmark in firefox trigger some action in Bindwood?
[17:08] <urbanape> rtgz: yes, deleting in firefox marks the couchdb record as deleted, but doesn't actually delete. This is to allow secondary clients to delete local copies
[17:09] <urbanape> (otherwise, secondary machines might re-propagate the same bookmark back up to couch, where it'd show up again on the first, leading to frustration, torches, and pitchforks)
[17:09] <urbanape> favicons have been requested before.
[17:10] <urbanape> we provide a view in futon for the deleted bookmarks, so if you know it's been deleted on all the appropriate client machines, you can delete the records from couch. Clumsy...
[17:12] <CardinalFang> urbanape, what do you need for favicons?  Storage?
[17:17] <urbanape> nah, it's just the way Firefox adds them to bookmark records.
[17:17] <aquarius> favicons are tiny -- we could either make them attachments (ha! CardinalFang looks interested), or just base64-encode them
[17:17] <urbanape> They're annotations, and happen out of band
[17:18] <urbanape> I believe they're actually stored as URLs on the annotation
[17:18] <urbanape> not hard, just needs tracking.
[17:18] <urbanape> and Firefox usually does its own job of fetching them as the bookmark is accessed
[17:18] <urbanape> (if it's not already set)
[17:19] <aquarius> so they don't need storing at all, then?
[17:19] <urbanape> probably not
[17:19] <rtgz> urbanape: is deleting uses the desktopcouch approach, i.e. application_annotations["Ubuntu One"].["deleted"] ?
[17:20] <urbanape> rtgz: it's a top-level field, not under application_annotations
[17:20] <urbanape> it marks the record itself as deleted
[17:20] <rtgz> urbanape: hm, when I tried to delete bookmarks via dc they all got new Ubuntu One/deleted annotation :-/
[17:21]  * urbanape pokes someone in charge of dc. Like aquarius.
[17:21] <urbanape> This doesn't feel like an application annotation. It's not application specific.
[17:22] <urbanape> it's semantic to the record itself.
[17:22] <aquarius> No, it isn't. But we can't just slam a top-level "deleted" field into any arbitrary record
[17:22] <aquarius> it's in a_a.UbuntuOne because that's a sort of "semantic to the record but not at the top level" location
[17:22] <rtgz> urbanape: yep, it does not, but "db.delete_record(document["id"])" insists on application_annotation...
[17:23] <aquarius> and a_a.U1.deleted is a workaround for couch not yet supporting history.
[17:23] <urbanape> aquarius: we can slam a top-level delete field if we account for it in the schema
[17:24] <aquarius> yeah, but then everyone has to account for it in the schema :)
[17:24] <urbanape> and?
[17:24]  * rtgz starts the vm to give a screenshot of how the world looks like w/o favicons...
[17:25] <aquarius> and then everyone has to rev their schema to not include it the day couch supports history
[17:25] <aquarius> this is a wart, no two ways about it
[17:27] <urbanape> right, but now I have to rev Bindwood, and provide for understanding both deletion markers.
[17:27] <aquarius> urbanape, yeah, I know :(
[17:28] <aquarius> I wish I had a better solution. i hate tagging stuff as deleted rather than actually deleting it :(
[17:28] <rtgz> urbanape: or provide some conversion script that will "fix" the records
[17:29] <urbanape> so, in the future, will couch propagate some sort of deletion event via _changes?
[17:29] <urbanape> how will secondary machines know to delete a record?
[17:29] <CardinalFang> I've been thinking about this.
[17:29] <urbanape> rtgz: bleah.
[17:29] <rtgz> aquarius: yes, btw, it takes real space on your server, e.g. my bookmarks now weight 6 Mb of not-accountable-on-the-web space, notes take 8Mb and it is grooowing...
[17:29] <urbanape> I'd rather keep the code around as a sign of shame. Like a big read "A"
[17:29] <urbanape> red, even
[17:30] <aquarius> rtgz, have you compressed your DBs?
[17:30] <aquarius> urbanape, I *think*, and I'm not sure about this, that if you see a space where you want to put a record, you should check whether there *used* to be a record there by looking in the history. I think
[17:30] <urbanape> wha?
[17:31] <rtgz> aquarius: okay, bookmarks now weight 6Mb and notes take 3 :)
[17:31] <aquarius> heh
[17:32] <aquarius> rtgz, so you actually have 6MB of bookmarks?
[17:32] <urbanape> actually, that will require clients to try and push every bookmark on every start
[17:32] <urbanape> which gets back to a huge pile of PITA.
[17:32] <aquarius> urbanape, this is why I'm not sure about exactly how it should work
[17:32] <rtgz> aquarius: actually this is why i wanted to delete all duplicating records and instead received 1000 records "marked" as deleted...
[17:32] <urbanape> CardinalFang: you want to elaborate on your thoughts for delete propagation?
[17:32] <CardinalFang> aquarius, we may not get undo support in couchdb soon.  Perhaps we should plan a true expunging method.  Along with deleted-p, add a deleted date.  The desktopcouch service could sweep out all records that are more than N months old.  With vigilance and timing, deleted records would disappear.
[17:33] <urbanape> I'm genuinely curious
[17:33] <aquarius> urbanape, I think there's a distinction between *actually deleted* (which is indicated by a_a.U1.deleted at the moment, and will eventually be indicated by the record not being there but being in the history), and Bindwood's notion of deletion-for-propagation (indicated by "deleted" at the top level)
[17:33] <aquarius> I'm having difficulty articulating the precise difference, but I think they indicate different things
[17:33] <urbanape> CardinalFang: I suggested to SteveA before he left that we might try a heuristic where each client that is involved in the process tags the record in Couch saying, "ACKD"
[17:34] <urbanape> then, when all machines in the account have hit it, we can safely be sure it's been deleted from all instances in play.
[17:34] <aquarius> you can't know how many machines there are, though
[17:34] <urbanape> sure you can
[17:34] <aquarius> or, at least, any one given machine can't know that "all the other machines have hit this record, so I can delete it"
[17:34] <urbanape> they're the ones associated with the account.
[17:35] <rtgz> aquarius: and if one of the machines died or deassociated then this record will stay forever
[17:35] <urbanape> it wouldn't be any one of the machines/
[17:35] <aquarius> that only works in an Ubuntu One world, not a world with LAN pairing in it too...
[17:35] <CardinalFang> urbanape, desktopcouch is bigger than Ubuntu One.
[17:35] <urbanape> maybe we handle it centrally.
[17:35] <urbanape> CardinalFang: yeah, but we can handle the cleanup for our users, and let other desktopcouch networks come up with their own policy.
[17:36] <urbanape> what's wrong with differentiation along service lines?
[17:36] <aquarius> because if I have all but one of my machines paired with U1 and one machine LAN-paired, that LAN-paired machine won't get to see the deleted record
[17:36] <aquarius> so it'll put it back into couch, and then it'll appear everywhere else again
[17:37] <urbanape> aquarius: I fail to see the distinction you mentioned previously between "really deleted" and "deleted for the purpose of propagation". Secondary machines still need to recognize a record that should be deleted locally.
[17:38] <urbanape> aquarius: that case seems more than a little degenerate
[17:38] <CardinalFang> Is that the same question?  I thought aq had some idea about browser behavior only.
[17:38] <urbanape> (as an aside: after a long holiday with no real adult conversation, I find this utterly fascinating)
[17:39] <aquarius> the difference between really-deleted and deleted-for-propagation is that we're working around a deficiency in CouchDB's replication engine
[17:39] <aquarius> because it doesn't propagate deletes.
[17:39] <urbanape> CardinalFang: not sure. There are two things here: proper ways to mark records as deleted, considering that Couch DB record is canonical, so all clients have a go at deleting locally, and knowing when we can safely delete couch records "for real"
[17:39] <aquarius> syncdaemon does, for example
[17:40] <urbanape> well, we're making it propagate deletions.
[17:40] <rtgz> aquarius: are you sure it does not? I remember killing the entries from the database and they did not return from the server afterwards...
[17:40] <aquarius> o rly?
[17:40] <aquarius> hm
[17:40] <CardinalFang> urbanape, we're making it propagage an additional revision that has an element that says "ignore me please."
[17:40] <aquarius> rtgz, urbanape, your two cases are diametrically opposite one another. They can't both be true :-)
[17:41] <rtgz> delete_all_records.py.. need to locate this in the IRC logs
[17:41] <urbanape> CardinalFang: yes, we're exploiting a new revision, but the upside is, we're propagating deletions.
[17:42] <urbanape> a "deletion event" in _changes, for instance, would still be a document with a revision
[17:42] <urbanape> it would just be a lot smaller.
[17:42] <urbanape> s/would/could/
[17:42] <CardinalFang> urbanape, yes, as we have designed it for current usage.  This is a hack.
[17:42] <rtgz> thisfred	rtagger:  joshuahoover  #474170 has a script to *permanently* delete all documents from a database. Use with appropriate caution.
[17:42] <rtgz> ubottu: bug #474170
[17:43] <urbanape> CardinalFang: well, I'm gonna place it just on the side of "elegant"
[17:44] <urbanape> including it in _changes feels right to me. Whether it's an annotation that makes the record grow, or it were better about "wipe out everything but its uuid and a note to the effect that clients should delete" isn't too important to me.
[17:44]  * rtgz starts liking trackerd once he has all IRC logs from #ubuntuone locally
[17:44] <CardinalFang> It's a hack because if we remove the record from the database, then when we next ask a peer "I have set(a,b,d), what do you have?" and they say "Oh, I have c too!", we will still say "Send us C!" even though we removed C 10 minutes ago.
[17:46] <aquarius> rtgz, log into couch! :)
[17:46] <rtgz> I guess i'll need to check what happens to my bookmarks if i delete them in such way. The second couchdb is running in the VM so the effect should be seen shortly
[17:47] <CardinalFang> It would be nicer if couchdb said instead, "Aw, I know of C and Idon't want it.  KTHXBYE."
[17:50] <rtgz> rtg@buzz:~/Downloads$ python delete_all_docs.py bookmarks => 1142 records permanently deleted, wow
[17:51] <rtgz> Ubuntu One finished updating 0 files
[17:52] <rtgz> awesome notification popped up :)
[17:56] <rtgz> aquarius: it took me 10 minutes to realize what you told me :). Trackerd does not search couchdb, sorry ;(
[17:57] <aquarius> rtgz, ah, not what I meant -- I meant, save irc logs into couch too, and then you can search it all there
[17:58] <rtgz> aquarius: yep, xmpp conversations are ok, but IRC seem to require more attention and a test channel :)
[17:59] <rtgz> aquarius: i mean xmpp MUC
[17:59] <urbanape> CardinalFang: It's not just that, though! Couch not wanting it is not the same thing. In fact, it's not about what Couch wants. It's about what the user wants. Couch is acting as a proxy for the user. "The user wants this record deleted. So, delete it."
[18:00] <rtgz> The vm just notified me that my files are up to date, then updated some more files and notified me again, repeated 3 times :-/
[18:00] <urbanape> we *need* to propagate the semantics of that intent, not just the record (heh) of its deletion once upon a time.
[18:01] <CardinalFang> urbanape, I don't think we're talking on the same level.  All I am saying is we have 1) ignore this forever and 2) expunge this information but get it back if someone else has it.
[18:02] <rtgz> Is it only me or desktopcouch puts couchdb.html that contains an invalid port, on every system startup...
[18:02] <aquarius> rtgz, CardinalFang may have already fixed that in trunk
[18:03] <CardinalFang> I think I have, rtgz.
[18:03]  * rtgz is waiting for the bookmarks either to appear or to disappear...
[18:04] <urbanape> rtgz: if you're using my PPA packaged bindwood, it won't push them again.
[18:05] <rtgz> CardinalFang: are you talking about the notifications or couchdb.html?
[18:05] <urbanape> it only pushes newer bookmarks than the last known last_modified bookmark on subsequent starts of Firefox.
[18:05] <rtgz> urbanape: i am just waiting for the bookmarks to disappear from the second couchdb instance...
[18:05] <rtgz> urbanape: or to appear again in the first one
[18:06] <CardinalFang> rtgz, I think desktopcouch starting up is fixed in trunk.  It fails to start the first time on some small fraction of machines.
[18:06] <CardinalFang> It's a timing bug caused by a wrong assumption about pid file and socket availability.
[18:07] <rtgz> CardinalFang: is it possible to teach couchdb to provide the required info itself and not to search through file handles?
[18:08] <urbanape> rtgz: ah, between couches, gotcha.
[18:08] <CardinalFang> rtgz, yes, in that it's open source and mutable and they might accept patches.
[18:09] <urbanape> CardinalFang: 2 is only a concern in aquarius' degenerate use of the system. I think U1 can offer the ability to act as reliable steward for the registered machines.
[18:09] <urbanape> If the user wants to entrust the replication to another machine outside that circle, they need to take additional steps to ensure that records are properly deleted when they should be.
[18:09] <aquarius> there's a difference between "Ubuntu One is more reliable" and "if you don't use Ubuntu One you are *guaranteed* to be fucked by Bindwood"
[18:09] <aquarius> the latter seems a bit unfair, since we're making Ubuntu One be a Bindwood dependency
[18:10] <urbanape> how is that unfair? Use U1 in the manner intended, and you'll be fine. Get clever and you have to stay clever.
[18:10] <aquarius> and I don't think we should do that
[18:10] <aquarius> there is no way of being clever, though
[18:11] <aquarius> if your definition of clever is "configure Bindwood correctly" then that's sorta OK. If your definition of clever is "never delete any bookmarks, or patch Bindwood" then that's unreasonable, I think
[18:11] <CardinalFang> Let's pause a moment and decide if there's another way than assume a canonical listing of hosts. (har.)
[18:12] <urbanape> no, when I'm talking clever, I'm talking about the guy who not only uses U1's desktop couch replication, but adds his own running on a slice into the mix.
[18:12] <urbanape> CardinalFang: timestamping and acting after X months is just as surprising when the user starts up his long synced netbook six months later and now all these old bookmarks he doesn't care about get thrown back into the mix.
[18:12] <aquarius> urbanape, yeah, but that's my point -- what you're suggesting is that LAN paired desktopcouches and Bindwood are fundamentally incompatible.
[18:13] <aquarius> urbanape, that is: Bindwood depends on you having an Ubuntu One account
[18:13] <urbanape> pause
[18:13] <urbanape> not at all.
[18:13] <urbanape> what I'm suggesting:
[18:13] <urbanape> we use delete flags to propagate deletions to clients.
[18:13] <urbanape> U1 offers a service whereby:
[18:14] <urbanape> clients who's acked a deletion make note of themselves on the record somehow (hand wavy)
[18:14] <urbanape> when all clients in an account have acked, delete the actual record in Couch.
[18:14] <CardinalFang> urbanape, Using U1 as a list of hosts fails if any of 1) user discards computer and doesn't remove U1 token, 2) if user has any paired peers, 3) user has more than one service, 4) user has no service, 5) that Fedora guy ports to Fedora and it doesn't support the same host listing.
[18:14] <urbanape> that can be done even in a LAN environment, just takes coordination.
[18:14] <aquarius> urbanape, when you delete the record in couch, a LAN-paired server will just put it back, no?
[18:15] <aquarius> at least, any LAN-paired server that hasn't seen it will just put it back
[18:15] <urbanape> that's a degenerate case where a user has both: u1 and a LAN-paired server. That's clever, and they need to stay clever.
[18:15] <urbanape> if a user is purely lan based, they'll have to roll their own solution.
[18:15] <aquarius> yeah, but what I'm saying is: there is no way of them *being* clever. There's no way for them to avoid the situation where a LAN server puts their bookmarks back
[18:15] <rtgz> hm, latest info from vm replication dates back to 2009-11-30...
[18:15] <aquarius> which means that anyone who has a LAN-paired desktopcouch can't delete bookmarks
[18:16] <CardinalFang> They don't have to be pure.  They only need a single computer that U1 doesn't know about.
[18:16] <aquarius> which means that Bindwood doesn't work properly if you have any LAN-paired servers
[18:16] <urbanape> "doctor, it hurts when I do this."
[18:16] <urbanape> it works if you only use LAN-paired servers
[18:16] <aquarius> ahem. LAN pairing is a proper documented designed-in-from-the-beginning use of desktopcouch. It is not an extra bag hung on the side at the last minute.
[18:17] <aquarius> How does it work if you only use LAN-paired servers? The deletion never happens, then. If you're OK with the deletion never happening, then why do we need it in an Ubuntu One world?
[18:17] <urbanape> then keep the bloody records around and let the user delete them manually through futon when they're sure all their clients have dealt with them properly.
[18:18] <aquarius> personally...that's what I think we should do, which is basically what we're doing at the moment, no?
[18:18] <urbanape> then it works in whatever orgyistic haze the user has set up.
[18:18] <CardinalFang> urbanape, Back to this -- "timestamping and acting after X months is just as surprising when the user starts up his long synced netbook six months later and now all these old bookmarks he doesn't care about get thrown back into the mix"
[18:19] <CardinalFang> "Back into the mix" is still marked "ignore this -- it's called 'deleted'".
[18:19] <urbanape> aquarius: yes, I was trying to address, for U1 users (see the channel we're in?) a means to automatically clean up.
[18:19]  * aquarius laughs
[18:19] <urbanape> CardinalFang: not if the recently awoken client has that bookmark in play.
[18:19] <urbanape> it'll go back into Couch as a new bookmark.
[18:19] <CardinalFang> "In play"?
[18:19] <urbanape> if it never got wind of the delted record, and that record has since been expunged.
[18:20] <aquarius> I think clean-up isn't that important, esecially since at some point we'll have history, and then nothing ever gets cleaned up
[18:20] <CardinalFang> urbanape, Oh, well it would get the new revision which clobbers it whenever it replicates to anywhere.
[18:20] <urbanape> right, but client A, which six months ago deleted this bookmark would suddenly have it appear again.
[18:21] <rtgz> Test completed: the real couchdb received 42 new bookmarks, the vm one remained with 1000+ bookmarks. Is it really making the same content available on all machines?
[18:22] <urbanape> aquarius: I think you're right. It just feels needlessly cluttered and sending people to futon to clean up after themselves is kinda lackluster.
[18:23] <CardinalFang> urbanape, Yes, certainly.  That's the time out.  What is reasonable delay between mark-as-deleted-so-it's-propagated and assume-everything-is-finished-and-expunge-old-records.
[18:23] <CardinalFang> ?
[18:23] <urbanape> inf - 1
[18:24] <aquarius> urbanape, I agree with you. This is why I think the real way to solve this is to actually delete the record (but keep it in history) and have the delete propagate, and have every bindwood check history before writing. That entirely solves the problem, but gives us the extra one of bindwood hammering the crap out of desktopcouch on startup
[18:24] <CardinalFang> Dang.  I was hoping for inf - 3.
[18:24] <CardinalFang> That's sooner.
[18:24] <urbanape> I'd still like to know how the presence of history is going to help. Presumably, this will require a full-on try-to-push-everything-on-every-start to check, "Should I still care about this one? This one? Have you got this one?"
[18:25] <urbanape> aquarius: woops, was typing all that when you just said it.
[18:25] <urbanape> that seems poo.
[18:25] <aquarius> yep, that's exactly what I think should happen. If that's inefficient, we should think of a way of making it less so.
[18:25] <aquarius> I can think of a few
[18:25] <urbanape> what's our real concern here?
[18:25] <urbanape> db bloat?
[18:26] <aquarius> that's not *my* concern, but then I've got an 80GB hard drive. :)
[18:26] <urbanape> I've got 500GB, here's a nickel.
[18:26] <CardinalFang> :)
[18:26] <aquarius> like, for example, have bindwood add a validator document that prevents pushing a bookmark if the identical one exists in history
[18:26] <urbanape> so, one thing we could do.
[18:26] <urbanape> does history only capture deletions?
[18:27] <aquarius> urbanape, mine's SSD. If you've got a half-terabyte SSD it didn't cost no damned five cents :P
[18:27] <urbanape> no, not SSD.
[18:27] <aquarius> history is entirely theoretical at this point
[18:27] <rtgz> aquarius: true, i got 1000 bookmarks and only 50 of them were not duplicates
[18:27] <aquarius> the assumption is that it will capture every change
[18:28] <urbanape> CardinalFang: is it possible to infer even non-U1 participants by finding out who all is in a replication network?
[18:28] <aquarius> nope
[18:28] <urbanape> well, that's dumb.
[18:28] <aquarius> not without complicated collaboration between all the participants
[18:28] <CardinalFang> It's complicated.  Theoretically, yes.
[18:28] <aquarius> pairing is not everyone-to-everyone
[18:28] <CardinalFang> The coordination will have to be asynchronous.
[18:29] <CardinalFang> And there is no obvious ringleader.
[18:29] <aquarius> I mean, record deletion would be doable: a give server says "I will only mark this record as seen by me if it's already been seen by all my pairs"
[18:29] <CardinalFang> We could elect one, but that might be a bad choice (e.g. offline often computer)
[18:29] <aquarius> and then when you see a record which is already seen by you, you can delete it
[18:29] <aquarius> but that requires some testing to be sure it works :P
[18:30] <urbanape> so, what about a big red button that does our Jeeves act.
[18:30] <urbanape> bah.
[18:31] <urbanape> the whole notion of purging is anathema to our target audience. Hell, I use mutt and I hate to have to purge.
[18:31] <aquarius> actually...that coordination method would work, wouldn't it?
[18:31]  * CardinalFang is thinking.
[18:34] <CardinalFang> aquarius, I don't think it works.  We're not trying to be conservative with marking as deleted?  Overuse of the I-have-seen flag/set/list is not the problem.  Knowing whether there is something else that has it is the problem.
[18:34] <CardinalFang> (That's not a question, sentence two.)
[18:34] <aquarius> CardinalFang, yeah, but if a machine has  marked a record as "I have seen this" then it can be assumed to have dealt with it, i.e., to have deleted the bookmark
[18:35] <aquarius> so you need to establish whether all machines have seen it
[18:35] <CardinalFang> There's no place that can start the process.  It's deadlocked at the start, right?
[18:35] <aquarius> if you refuse to mark a record as seen until all your pairs have seen it (other than the pair you got it from), then any machine which gets a record which it has already seen can know that it's OK
[18:35] <thisfred> bbiab
[18:36] <aquarius> nope, that's what the (other than the pair you got it from) is for
[18:36] <aquarius> imagine A-B-C-D-E, paired in a line like that. A marks deleted. It replicates to B, C, D, E, E says "I got this from D, I have no other pairs, mark it as seen by E and delete the record"
[18:37] <aquarius> er, delete the bookmark
[18:37] <aquarius> it then goes all the way back down the lne to A
[18:37] <aquarius> which says "I got this from B, I have no other pairs, mark it as seen by me, and delete the bookmark"
[18:38] <aquarius> goes back down the line through C to D, which marks it as seen (got it from C, already seen by E) and then goes back down the line to A and E, both of which delete it
[18:38] <aquarius> I think
[18:38] <aquarius> need to write something that tests this :)
[18:39] <thisfred> aquarius: CardinalFang I'm not sure that we're not actually reinventing replication here. What is the problem we're solving again?
[18:40] <CardinalFang> aquarius, we don't know the source of the record.  Imagine two hosts.  Both have a record.  If each is waiting for the other to say "everyone I know has updated this record" then neither will be first.
[18:40] <aquarius> CardinalFang, nope, because when host2 gets it, it says "all my pairs except the sender (host1) have seen this" (because it *has* no pairs)
[18:40] <CardinalFang> thisfred, we're trying to invent expunging of records.
[18:41] <joshuahoover> rtgz: ah, thanks for the script
[18:41] <CardinalFang> We don't know "sender"
[18:41] <aquarius> ah, pants, we don't, do we
[18:41] <thisfred> CardinalFang: and the problem is hard because of *when* to do this?
[18:42] <rtgz> joshuahoover: o_O what script?
[18:42] <CardinalFang> thisfred, it's hard because we don't want to keep a record of what we have locally  expunged and we don't know all hosts in the replication network.
[18:42] <joshuahoover> rtgz: (11:42:30 AM) rtgz: thisfred	rtagger:  joshuahoover  #474170 has a script to *permanently* delete all documents from a database. Use with appropriate caution.
[18:43] <thisfred> CardinalFang: but expunging means *actually* deleting the record, rather than marking it deleted, correct? When we do that, it will just replicate everywhere. What am I missing?
[18:43] <CardinalFang> "it?"
[18:43] <CardinalFang> what will replicate everywhere?
[18:43] <aquarius> thisfred, the problem is that if a record just vanishes, Bindwood will say "I have a bookmark that's not in couch!" and just recreate the record
[18:43] <thisfred> the deletion
[18:44] <thisfred> aquarius: then there's something wrong with bindwood
[18:44] <rtgz> joshuahoover: ah, i got the whole line copied from IRC log :), this was said by thisfred and the script is also by thisfred :)
[18:44] <CardinalFang> thisfred, that's what we're assuming (!?) is false.
[18:44] <aquarius> thisfred, because bindwood doesn't get told about deletions, it just sees the result (the record is not there) and it can't tell if it's not there because it was deleted, or because it was never there
[18:44] <thisfred> aquarius: yeah, so bindwood will need to keep track of that then
[18:44] <aquarius> thisfred, how do you propose it works? bindwood can't watch _changes -- bindwood might not be running when the replication happened
[18:44] <CardinalFang> Not just bindwood.  All apps.
[18:44] <thisfred> aquarius: does not need to, it can call changes with a since param
[18:44] <aquarius> thisfred, bindwood can't keep track of it. There's no way of asking couch "did there used to be a record with ID xxxxx"?
[18:45] <thisfred> aquarius: not all apps will want to know:
[18:45] <aquarius> thisfred, that only works if the database ha not been compacted in the meantime, as i understand it
[18:45] <thisfred> it only breaks if the data is stored in two place
[18:45] <thisfred> s
[18:46] <thisfred> if couch is really the backend, then gone is gone right? doesn't matter if it was ever there
[18:46] <thisfred> if an app stores things internally *and* in couch
[18:46] <CardinalFang> Okay, aquarius, urbanape, thisfred, I'm satisfied in saying "records can not be expunged yet".  When they can, it will be couchdb implementing it, not us, anyway.
[18:46] <thisfred> then it needs to keep track of deletions etc.
[18:47] <thisfred> CardinalFang: I still don't understand: couchdb can delete documents, and if they are deleted on node 1, all other nodes that replicate from it, will also delete the record
[18:47] <CardinalFang> thisfred, really?  This surprises me.
[18:47] <thisfred> that's how replication works
[18:48] <CardinalFang> If so, that solves the problem.
[18:48] <urbanape> I need to pause and beg off for a bit to help with bug wrangling.
[18:48] <thisfred> I would think so,
[18:48] <aquarius> that means that bindwood will *have* to watch _changes and call it with _since
[18:48] <thisfred> aquarius: why?
[18:48] <thisfred> aquarius: because it does store the bookmarks internally as well?
[18:48] <aquarius> thisfred, because it needs to know the difference between "this was deleted" and "this was never here"
[18:48] <thisfred> then yes
[18:49] <urbanape> aquarius: that's what Bindwood does now, anyway.
[18:49] <aquarius> thisfred, yes, Firefox stores the bookmarks internally, and bindwood syncs between the Firefox store and Couch. It doesn't *replace* the firefox store with couch.
[18:49] <thisfred> aquarius: right
[18:49] <urbanape> correct
[18:49] <thisfred> and other apps will have the same problem, though not all apps
[18:49] <thisfred> so we might build some infrastructure for that
[18:49] <aquarius> urbanape, so...it's _changes, I think
[18:49] <urbanape> what is?
[18:50] <thisfred> but couchdb itsel;f does not have thius problem
[18:50] <aquarius> urbanape, the solution; then you can tell the difference between "this was deleted" and "this was never there"
[18:50] <thisfred> ok now I really have to walk the dog
[18:51] <urbanape> I'm still not following, and I have to run and handle Lex. aquarius, let's talk about this in a bit, if you're up for it. Incidentally, I'm okay with not auto-expunging now.
[18:51] <urbanape> (for the time being)
[18:51] <aquarius> urbanape, yeah, I have to go out in about an hour
[18:51] <aquarius> so  tomorrow
[19:09] <thisfred> back, dog didn't like the rain
[19:20] <felipe1> I'm having problems with my ubuntu one...
[19:20] <felipe1> by mistake I erase all the authorized computers from the web page, and now I can't add a new one there. I start the client and doesn't prompt me for an authorization, it just tries to connect and it can't
[19:22] <felipe1> is somebody here that can help?
[19:23] <rtgz> felipe1: yup
[19:23] <felipe1> so, what do i do? did you read my problem?
[19:24] <rtgz> felipe1: first of all, the default check for most known issues:
[19:24] <rtgz> wget http://ubuntuone-client-diagnose.googlecode.com/svn/trunk/ubuntuone-client-diagnose.py
[19:24] <rtgz> python ubuntuone-client-diagnose.py
[19:24] <rtgz> download the ubuntuone-client-diagnose file and run the script in the terminal
[19:25] <felipe1> it says that no issues were detected
[19:25] <rtgz> felipe1: okay, then quit the client completely and start it from the terminal - ubuntuone-client-applet :)
[19:25] <verterok> felipe1: do you have any u1 token in your keyring?
[19:26] <felipe1> no that I know of
[19:26]  * rtgz notes that he needs to check for keyring first....
[19:26] <felipe1> oh, sorry, i misread... i don't know what a u1 token is... how do i check that
[19:27] <rtgz> verterok: may I?
[19:27] <verterok> rtgz: sure
[19:28] <verterok> felipe1: go to: Applications -> Accesories --> Encryption and Passwords (or a similar name)
[19:28]  * verterok is using kde ATM
[19:28] <rtgz> felipe1: Open Applications/Accessories/Passwords and Encryption Keys, navigate to login keyring, unlock it (if it is locked) and check that you have UbuntuOne token for https://ubuntuone.com
[19:28] <verterok> rtgz: thanks
[19:28] <felipe1> is Gnome... I'm there
[19:29] <verterok> rtgz: we can check this in your diagnose script ;)
[19:29] <felipe1> I don't have that token
[19:29] <rtgz> verterok: yup, pretty easily and will provide far better diagnostic...
[19:30] <felipe1> so now what?
[19:30] <rtgz> felipe1: okay, so you don't have the token. What browser are you using? Are you able to open the page with "xdg-open http://www.ubuntu.com" in the terminal?
[19:31] <felipe1> I'm using firefox, and chrome... and I can open both
[19:31] <felipe1> with the xdg-open command changing my preferences to any of the two browsers
[19:32] <rtgz> felipe1: no, i mean is the browser actually opening on xdg-open http://www.ubuntu.com ?
[19:32] <felipe1> yes it is
[19:33] <felipe1> I meant that it opens that webpage in any of the two, my default was chrome, but I just changed it to firefox just in case
[19:33] <felipe1> and it open in both
[19:33] <rtgz> felipe1: then we'll need the logs from you, can you paste ~/.cache/ubuntuone/log/oauth-login.log to http://paste.ubuntu.com ?
[19:33] <dobey> felipe1: you aren't getting an error dialog or anything either?
[19:33] <felipe1> nope
[19:34] <felipe1> the thing that happen was that I accidentally erase all my authorized computers from the website... and now I can't connect to ubuntu one, and the applet is not giving me an option to authorize this computer again
[19:34] <rtgz> felipe1: and follow-up to the former question about starting up ubuntuone-client-applet in the terminal, could you please do that for the time being?
[19:35] <felipe1> I just pasted it there
[19:35] <rtgz> felipe1: could you provide the URL?
[19:35] <felipe1> I already did, it's running from the terminal already
[19:35] <felipe1> sorry, I forgot, here you go: http://paste.ubuntu.com/333340/
[19:36] <rtgz> felipe1: i assume that applet did not print anything weird on startup, right?
[19:37] <felipe1> yes, it didn't
[19:37] <felipe1> it's running like nothing is wrong, but I just can't connect
[19:39] <rtgz> felipe1: okay, try to change the debug level for the applet/oauth log, I'll give you a command in a sec
[19:39] <dobey> hrmmmm
[19:40] <felipe1> ok
[19:40]  * rtgz is probably missing something obvious
[19:41] <felipe1> do you think that if I erase the "Desktop couch user authentication" from my passwords, UbuntuOne will ask me to authorized my computer again?
[19:42] <dobey> maybe but i doubt it
[19:42] <felipe1> I'm going to give it a try...
[19:43] <felipe1> I think that the computer thinks it's still authorized to log in, but the service isn't letting it, but there must be a log or some debug command where we can see that...
[19:43] <rtgz> felipe1: just in case, here's the sed statement:
[19:43] <rtgz> sudo sed -i s/logging.INFO/logging.DEBUG/ /usr/share/pyshared/ubuntuone/oauthdesktop/logger.py
[19:44] <felipe1> thanks... I was waiting for it, before I erase those keys
[19:44] <dobey> i did just find a bug though, which i will fix real quick. but it shouldn't be causing any issues, just an efficiency problem
[19:45] <rtgz> felipe1: afterwards, quit the applet and start it again. oauth-login.log shoudl contain much more info after you start the applet, so please pastebin it again
[19:45] <felipe1> ok
[19:45] <felipe1> now it worked!
[19:46] <felipe1> I didn't get any messages on the terminal, but my browser opened and asked me to authorized my laptop
[19:46] <felipe1> after doing the sed command
[19:46] <rtgz> felipe1: so you removed the keys and restarted the applet, right?
[19:46] <felipe1> yes
[19:46] <dobey> weird
[19:47] <rtgz> felipe1: then it was not the sed command that fixed that
[19:47] <felipe1> of course not... but I just said that after this procedure (the sed command) it worked
[19:47] <rtgz> felipe1: you can undo the change by:
[19:47] <rtgz> sudo sed -i s/logging.DEBUG/logging.INFO/ /usr/share/pyshared/ubuntuone/oauthdesktop/logger.py
[19:47] <felipe1> do i have to quit the UbuntuOne before I run that comment?
[19:48] <felipe1> command*
[19:48] <rtgz> felipe1: no, that simply changes the sources that is already read, so it will be applied only the next time you run the applet
[19:48] <felipe1> oh i see
[19:48] <rtgz> dobey: desktopcouch pairing prevents the OAuth?..
[19:49] <felipe1> thanks guys a lot
[19:50] <felipe1> bye
[19:50] <rtgz> there is something I do not get
[19:52] <dobey> rtgz: no...
[19:53] <dobey> rtgz: the code that pairs desktopcouch doesn't get hit until after the "allow this computer" stuff happens, and was successful
[20:04] <rtgz> the bad thing about diagnose script is that it rules out too many of the easily-detected things leaving the ones that are not that trivial...
[20:32] <Goliath> Hi all, I'm using karmic, I'm logged in one.ubuntu.com and my computer is registered BUT I can't sync from applet, any ideas?
[20:36] <jblount> Goliath: Hi! What does "can't sync from the applet" mean? What happens when you put files into ~/Ubuntu One/ ?
[20:36] <Goliath> I have created a new file in ~/Ubuntu One
[20:37] <Goliath> but the applet cannot connect to ubuntu.com
[20:37] <jblount> Goliath: Eureeka! So when you click on "connect" it's not connecting?
[20:37] <Goliath> yep
[20:40] <Goliath> jblount: yes when i click on "connect" anything happens.
[20:41] <rtgz> Goliath: could you please run the diagnostic script:
[20:41] <rtgz> wget http://ubuntuone-client-diagnose.googlecode.com/svn/trunk/ubuntuone-client-diagnose.py
[20:42] <rtgz> python ubuntuone-client-diagnose.py
[20:42] <rtgz> Goliath: execute this in terminal to make sure you are not hitting a well-known bug
[20:42] <Goliath> Checking your Ubuntu One client...
[20:42] <Goliath> No issues were detected.
[20:42] <Goliath> Done.
[20:43] <jblount> Goliath: Could you paste the results of this: tail ~/.cache/ubuntuone/log/oauth-login.log
[20:43] <Goliath> Unable to contact NetworkManager
[20:43] <Goliath> Avvio client Ubuntu One versione 1.0.2
[20:43] <Goliath> Unable to contact NetworkManager
[20:43] <Goliath> Avvio client Ubuntu One versione 1.0.2
[20:43] <Goliath> Unable to contact NetworkManager
[20:43] <Goliath> Avvio client Ubuntu One versione 1.0.2
[20:43] <Goliath> Avvio client Ubuntu One versione 1.0.2
[20:43] <Goliath> Avvio client Ubuntu One versione 1.0.2
[20:43] <Goliath> Avvio client Ubuntu One versione 1.0.2
[20:43] <Goliath> Avvio client Ubuntu One versione 1.0.2
[20:43] <Goliath> Avvio = Starting
[20:44] <dobey> jblount: s/paste/pastebin/ when you ask for that info :)
[20:44] <jblount> dobey: Right on.
[20:44] <jblount> Goliath: Do you currently use NetworkManager? The current stable client requires it.
[20:44]  * rtgz broke NM detection? O_O
[20:44] <jblount> Goliath: I think ppa has a version that dobey has fixed this though.
[20:44] <dobey> no i think he installed NM yesterday to fix that
[20:45] <Goliath> jblount: could you tell me y nm is needed?
[20:45] <dobey> otherwise it would repeat with the later Starting messages
[20:45] <Goliath> yes i did
[20:45] <rtgz> dobey: yes, true,
[20:45] <jblount> Goliath: No, it is a mystery to me. I am a lowly writer of html.
[20:45] <dobey> Goliath: it's not, but there is a bug in the stable version in Karmic currently. there is a fix for it and I am working on getting it into an update for karmic :)
[20:46] <Goliath> oh
[20:46] <Goliath> and just another thing
[20:46] <Goliath> cancel
[20:46] <Goliath> the last
[20:47] <Goliath> I need to make more proof before ask for
[20:47] <Goliath> nm is running
[20:47] <Goliath> anyway
[20:48] <dobey> actually
[20:48] <dobey> you're using manually configured network, right?
[20:48] <Goliath> yn
[20:48] <Goliath> i have configured /etc/network/interface
[20:48] <Goliath> but
[20:48] <dobey> right
[20:49] <Goliath> there's an instance of nm running
[20:49] <dobey> yes
[20:49] <Goliath> device not handled
[20:49] <Goliath> is what nm says to me
[20:49] <dobey> i think the problem you're seeing now is maybe that nm is reporting it's disconnected
[20:49] <rtgz> dobey: the script checks that NM returns CONNECTED state,
[20:50] <dobey> nm-tool|grep "^State"
[20:50] <rtgz> Goliath: could you pastebin the output of nm-tool, just to make sure
[20:50] <dobey> Goliath: what does that say^
[20:50] <dobey> oh, it might not be State in italian
[20:50] <dobey> i don't know if that is translated or not
[20:50] <Goliath> NetworkManager Tool
[20:50] <Goliath> State: connected
[20:50] <Goliath> - Device: eth0 -----------------------------------------------------------------
[20:50] <Goliath>   Type:              Wired
[20:50] <Goliath>   Driver:            forcedeth
[20:50] <Goliath>   State:             unmanaged
[20:51] <Goliath>   Default:           no
[20:51] <dobey> ok
[20:51] <Goliath>   HW Address:        00:11:....
[20:51] <Goliath>   Capabilities:
[20:51] <Goliath>     Carrier Detect:  yes
[20:51] <Goliath>     Speed:           100 Mb/s
[20:51] <Goliath>   Wired Properties
[20:51] <Goliath>     Carrier:         on
[20:51] <dobey> so it says it is connected, so that's not the issue
[20:52] <Goliath> yes but it also says: unmanaged
[20:52] <Goliath> so
[20:52] <Goliath> the connection is up but not with nm
[20:52] <Goliath> is that correct?
[20:53] <dobey> yes, that is fine
[20:53] <dobey> we just check for the global state
[20:53] <dobey> which is "connected" for you
[20:53] <Goliath> ok
[20:53] <rtgz> Goliath: Can you check that you have an "Ubuntu One" token in your keyring (Applications/Accessories/Passwords and Encryption Keys / login keyring) - will be different in Italian, i guess?
[20:54]  * rtgz sounds like a broken record
[20:54] <Goliath> yes
[20:54] <Goliath> I have the token
[20:55] <Goliath> by the way
[20:55] <Goliath> if the connection of ubuntuone is handled by nm if nm can't manage it
[20:55] <Goliath> how can it check UID and PWD?
[20:55] <dobey> it's not handled by nm
[20:56] <dobey> Goliath: UID and PWD are not relevant really
[20:57] <Goliath> I don't understand why nm is needed
[20:57] <Goliath> and i really think that's the problem
[20:57] <dobey> it's not, and it's not the problem
[20:57] <dobey> well it's needed because there is a bug with the handling of NM status in 1.0.2
[20:58] <Goliath> Hmmm
[20:58] <dobey> but as I said, I am working on getting the fix into an update for karmic
[20:58] <rtgz> Goliath: can you start the applet from the command line, just to make sure it is not printing anything unusual, ubuntuone-client-applet?
[20:58] <dobey> your issue is definitely not related to NM
[20:58] <dobey> that much i can tell :)
[20:58] <Goliath> ok :-)
[20:59] <Goliath> rgtz: -v?
[20:59] <Goliath> The applet says nothing
[21:00] <rtgz> Goliath: ok, one more, totally unrelated, but still something:
[21:00] <Goliath> and the flag -v is useless
[21:00] <rtgz>  /usr/lib/desktopcouch/desktopcouch-stop
[21:00] <rtgz> and then
[21:00] <rtgz>  /usr/lib/desktopcouch/desktopcouch-service
[21:01] <Goliath> what are those files?
[21:01] <rtgz> this should restart the service, then restart the applet
[21:01] <rtgz> Goliath: these are the files that control the CouchDB instance running on your machine. CouchDB stores some information about your setup so it may be related
[21:02] <Goliath> ls
[21:02] <Goliath> sorry i was chatting with bash ;-)
[21:02] <rtgz>  /usr/lib/desktopcouch/desktopcouch-service will keep the terminal, so please don't kill it :)
[21:03] <Goliath> the applet says is updating
[21:04] <Goliath> but it's not true
[21:04] <rtgz> Could you execute u1sdtool --current-transfers ?
[21:04] <rtgz> Goliath: ^ *please
[21:04] <Goliath> sure
[21:05] <Goliath> Current uploads: 0
[21:05] <Goliath> Current downloads: 0
[21:05] <Goliath> i don't know
[21:05] <Goliath> but seems to be bad
[21:05] <dobey> me either :)
[21:05] <rtgz> Goliath: do you use any proxies ?
[21:06] <Goliath> privoxy
[21:06] <Goliath> oops
[21:06] <Goliath> no
[21:06] <rtgz> Goliath: and now could you paste the contents of ~/.cache/ubuntuone/log/syncdaemon.log to http://paste.ubuntu.com and tell us the url ?
[21:06] <Goliath> it is not the reason
[21:07] <rtgz> Goliath: i guess the privoxy is just used by your browser, you have a direct connection otherwise, right?
[21:07] <Goliath> yes but you know computer have a dark soul isn't it?
[21:07] <Goliath> yes but you know computers have a dark soul isn't it?
[21:07] <Goliath> sorry
[21:08]  * rtgz recalls.. privoxy... is it still replacing all occurrences of open() to privoxyOpen() throughout the page even outside the <script/> tags? It was funny to read the perl code with such substitutions...
[21:09] <Goliath> http://paste.ubuntu.com/333391/
[21:10] <rtgz> Goliath: and clicking connect does not work now, right?
[21:10] <Goliath> exactly
[21:10] <Goliath> yes
[21:11] <Goliath> and i'm logged in
[21:11] <Goliath> with a trusted computer
[21:11] <Goliath> this connection worked only one time
[21:12] <rtgz> Goliath: would you be so kind as to remove the Ubuntu One token from the key ring and try to reauthorize. Something is really strange here
[21:12] <Goliath> done
[21:13] <dobey> i think it's a planetary alignment thing
[21:13] <Goliath> ahahah
[21:13] <rtgz> dobey: nope, this is reproducible, somehow, but I can't find the way
[21:14] <rtgz> The curse of the developer is that everything works perfectly on his own computer...
[21:14] <Goliath> ok
[21:14] <Goliath> I deleted the token
[21:14] <Goliath> logged out from the site
[21:14] <Goliath> relogged in in the site
[21:14] <Goliath> and try to "connect"
[21:14] <Goliath> and....
[21:14] <Goliath> ...
[21:14] <rtgz> Goliath: and click connect...
[21:14] <rtgz> ...
[21:14] <Goliath> it doesn't work
[21:14] <Goliath> :-(
[21:15] <rtgz> Goliath: okay, now the last thing, could you please try to remove the DesktopCouch tokens also found in the keyring?
[21:15] <rtgz> then restart the applet and try to connect
[21:16] <rtgz> if that fails, try to restart the couchdb as described earlier, restart the applet and try to connect
[21:17] <Goliath> but
[21:18] <Goliath> the token isn't the way the service authenticate himself to the system
[21:18] <Goliath> ?
[21:18] <Goliath> I mean
[21:18] <nessita1> Goliath: quick question... do you have throttling enabled on your syncdaemon.config?
[21:18] <nessita1> syncdaemon.conf*
[21:18] <Goliath> where is syncdaemon?
[21:19] <rtgz> nessita1: already ruled out by the diagnostic script :(
[21:19] <nessita1> rtgz: oh... wasn't aware of that :-/
[21:19] <dobey> hrmm
[21:19] <dobey> yeah, i just connected just fine :(
[21:19] <nessita1> Goliath: $HOME/.config/ubuntuone/syncdaemon.conf but seems like that's not the issue
[21:20] <dobey> Goliath: check ~/.config/ubuntuone/syncdaemon.conf
[21:20] <rtgz> Goliath: the data is not affected, the desktopcouch service will recreate the tokens as needed
[21:20] <Goliath> anyway
[21:20] <Goliath> [bandwidth_throttling]
[21:20] <Goliath> on = True
[21:20] <Goliath> read_limit = -1
[21:20] <Goliath> write_limit = -1
[21:20] <nessita1> that's the problem!
[21:21] <dobey> indeed
[21:21] <nessita1> Goliath: set on = False
[21:21] <nessita1> Goliath: prior to that, close the applet, modify the config, reopen the applet
[21:21] <dobey> thanks nessita1
[21:21] <nessita1> Goliath: modify the config using a text editor, not the applet
[21:22]  * rtgz goes to rewrite the detection... HOW...
[21:22] <nessita1> dobey: :-) this issue stole hours of my life a while ago
[21:22] <Goliath> ok
[21:22] <Goliath> just a second
[21:22] <Goliath> I have deleted tokens
[21:22] <Goliath> restarted service
[21:22] <Goliath> but the problem still remains
[21:23] <nessita> Goliath: did you disabled throttling?
[21:23] <dobey> Goliath: you need to do as nessita suggested
[21:23] <Goliath> I'm glad you're helping me
[21:23] <Goliath> but 3 at once requires time
[21:23] <dobey> Goliath: quit the applet, change on = True to False in ~/.config/ubuntuone/syncdaemon.conf , and then start the applet again
[21:23] <nessita> heh
[21:23] <dobey> Goliath: sorry :)
[21:24] <Goliath> that's ok
[21:24] <rtgz> aha, sdlog should contain Protocol version error first
[21:24] <nessita> Goliath: pick me! pick me! :-P
[21:24] <dobey> Goliath: us developers type pretty fast too ;)
[21:24] <Goliath> ahahah
[21:25] <Goliath> nooo the thing is that you are think and not making stuffs! ;-)
[21:25] <Goliath> whooo
[21:25] <Goliath> hoo
[21:25] <Goliath> that's not working
[21:25]  * rtgz *phew*
[21:25] <nessita> Goliath: let's go from the top, shall we?
[21:25] <rtgz> there was no protocol version error in the logs, so the client did not even attempt to connect...
[21:26]  * rtgz shuts up
[21:26] <nessita> Goliath: close the applet by right-clicking on the cloud and then "Quit"
[21:26] <nessita> Goliath: let me know when you finished that
[21:26] <Goliath> I'm really sorry
[21:26] <Goliath> but now i need to go
[21:26] <Goliath> sorry
[21:26] <nessita> Goliath: ok, no problem
[21:27] <Goliath> really thank you
[21:27] <Goliath> bye
[21:27] <rtgz> Goliath: right before you go, could you please..
[21:27] <Goliath> yes?
[21:27] <Goliath> really quick
[21:27] <rtgz> copy-paste the ~/.cache/ubuntuone/log/syncdaemon.log again ?
[21:28] <rtgz> to http://paste.ubuntu.com
[21:29] <Goliath> http://paste.ubuntu.com/333418/
[21:30] <Goliath> ok?
[21:30] <Goliath> all right, bye and thank you again
[21:30] <rtgz> Goliath: ok
[21:31] <rtgz> Okay, now it does not have the access token
[21:36] <facundobatista> verterok, ping
[21:36] <verterok> facundobatista: pong
[21:43] <joshuahoover> rtgz: ping
[21:44] <rtgz> joshuahoover: pong
[21:44] <joshuahoover> rtgz: is bug 486912 about running out of ubuntu one space (example: 2 GB free plan, user has over that limit)
[21:46] <rtgz> joshuahoover: no, it is about the fact that syncdaemon becomes crazy when there is no free disk space on the client
[21:46] <rtgz> joshuahoover: though I would test your variant too, looks tempting :)
[21:47] <joshuahoover> rtgz: ok, that's what i thought but i wanted to make sure
[21:47] <rtgz> joshuahoover: That's where I have seen that client cannot handle OK response or something like that...
[21:59] <rtgz> no, client cannot handle BYTES was in that ticket
[22:34] <rtgz> no, the emblems definitely don't work, just got to the nautilus code, it looks like it executes ubuntuone_nautilus_update_file_info only once which sets /* Add the synchronized emblem anyway, and update later */ and the ubuntuone-synchronized emblem just don't go away. Need to rebuild the extension...
[22:50] <rtgz> ** (nautilus:20685): WARNING **: No marshaller for signature of signal 'UploadFinished'
[22:50] <rtgz> ** (nautilus:20685): WARNING **: No marshaller for signature of signal 'DownloadFinished'
[22:50] <rtgz> ** (nautilus:20685): WARNING **: No marshaller for signature of signal 'ShareCreateError'
[22:50] <rtgz> Initializing nautilus-open-terminal extension
[22:50] <rtgz> UbuntuOne-Nautilus-Message: rtg: Add the synchronized emblem anyway
[22:50] <rtgz> (nautilus:20685): GLib-GObject-CRITICAL **: g_type_instance_get_private: assertion `instance != NULL && instance->g_class != NULL' failed
[22:50] <rtgz> ** (nautilus:20685): CRITICAL **: dbus_g_proxy_begin_call: assertion `DBUS_IS_G_PROXY (proxy)' failed
[22:50] <rtgz> UbuntuOne-Nautilus-Message: rtg: Add the synchronized emblem anyway
[22:50] <rtgz> he he
[23:09] <rtgz> bug #479475
[23:12] <rtgz> FOUND!
[23:14] <rtgz> I wonder if i am the only crazy enough here to chat with the empty channel...
[23:46] <rtgz> PATH!