=== mthaddon` is now known as mthaddon [11:01] hello peoples :D [11:09] hi miha [11:09] hey, instace of NWO. no new age for you. [11:09] hehe [11:10] :) [11:10] (last time "in this New World Order" was mentioned on CNN.. i guess it's official now) === miha is now known as wolfeysi [13:32] rodrigo_, ping [13:32] homeasvs_: pong [13:32] rodrigo_, so, I have packages for n900 [13:32] rodrigo_, but [13:32] I have a cryptic erlang error on couchdb startup [13:32] http://pastebin.com/d287f37b9 [13:32] hmm, what error is it? [13:32] any idea what that's about ? [13:33] no, we'd better ask on the #couchdb channel [13:33] can you do it please? I'm out for a lunch, bbiab [13:33] sure [13:33] hm, some googling suggests I did not compile erlang with ssl [13:33] oh, yopu already did :) [13:33] that would, uhm, 'suck' to figure out now [13:34] yeah [13:34] ok, bbiab [13:37] homeasvs_, "init terminating in do_boot" is a generic "it didn't start up properly for some reason" error :( [13:37] homeasvs_, quite often it means "I tried to use a library and it wasn't there", which lends weight to your SSL theory [13:37] homeasvs_, although I've had it do the same thing when spidermonkey wasn't available too [13:38] aquarius, it looks like ssl, not sure though why it was not built, investigating now [13:39] aquarius, --enable-dynamic-ssl-lib \ [13:39] --without-ssl-zlib [13:39] that's in the deb build [13:39] aquarius, any idea what exactly that then does ? [13:40] homeasvs_, I haven't, sorry. I don't know about the build stuff; you want cardinalfang for that, I think [13:40] #couchdb may be more helpful [13:40] heh, in fact they are already being more helpful :) [13:58] aquarius, rodrigo_ ok, one crash further [13:58] it's so close I can smell it [13:58] aquarius, will you be getting an n900 if this works ? :) [13:58] progress by crashing! :) [13:58] homeasvs_, I don't like physical keyboards, otherwise I'd already be agitating for one, I think :) [13:59] aquarius, you don't have to use the physical one :) [13:59] homeasvs_, yeah, but then I've got a phone which is half an inch thicker than it needs to be.... [13:59] aquarius, if half of that is couchdb, why does it matter ? :) [14:00] but I feel you, this phone is big in comparison to my e51 from before [14:00] * aquarius grins. I do rather like the idea of couch on the phone, I admit it [14:20] morning, all [14:33] mornin.gz [14:39] homeasvs_: cool :) [14:42] sweet baby jesus [14:42] I just browsed to futon running from my phone [14:42] this calls for some food [14:44] woohoo! === jcastro_ is now known as jcastro [14:58] hmm [15:01] Desktop+ MEETING BEGINS. Say 'me' to claim a slice of the stand-up meeting, then take your turn by saying DONE/TODO/BLOCKED. [15:04] me [15:05] me [15:05] me [15:05] rodrigo_: should i comment on your blog or your facebook? I don't know any more what the cool thing to do is :) [15:05] me [15:05] dobey: up to you, I'll get notifications on both :) [15:06] dobey: the cool thing though is to do it via your Palm Pre :D [15:07] dobey: and it would be super cool if you could re-review my libubutuone branch you commented on last Friday :) [15:07] yes i will [15:07] where is everyone else? [15:07] jblount is off ill [15:07] ChipAway, urbanape: ping [15:09] vds: ping [15:09] jblount is sick and teknico is on holiday [15:10] rodrigo_: eh, let's get this over with :) [15:10] ok [15:10] • DONE: Started adding search to contacts picker. Conboy unstable testing. XML<->HTML fixes [15:10] • 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:10] • BLOCKED: no [15:10] CardinalFang: go! [15:10] me [15:11] DONE: Attachments. Finally figure it out. Played with GTG started writing desktopcouch backend storage. [15:11] TODO: Still testing weird edge cases. May have to harass python-couchdb upstream. [15:11] BLOCKED: None [15:11] aquarius. [15:11] ⚀ DONE: talk to thisfred and vds about sequence numbers etc; talk to #couchdb about sequence numbers; review duty; decide on lxml, not BeautifulSoup, for html parsing with rodrigo [15:11] ⚁ TODO: 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; step-by-step guide to what happens during contact sync [15:11] ⚂ BLOCKED: [15:11] dobey: go [15:11] ☺ DONE: Reviews, SSO call, Triage [15:11] ☹ TODO: Homework, Review/Fix #479375, Finish Backporting, Triage, Prepare releases/SRUs [15:11] ☹ BLCK: None. [15:11] urbanape: rock on [15:11] DONE: Got ubuntuone-servers branch back from the dead, handed off to jblount for some CSS lovin [15:11] TODO: Get it landed. Move on to other bugs and Bindwood. [15:11] EOM? [15:11] BLOCK: None [15:17] sandy|lurk, aquarius: around here? [15:17] ya [15:17] yup [15:18] ok, so about storing HTML vs XML on our database, sandy|lurk, could you please share your concerns with aquarius? [15:18] sure [15:18] so currently there's this bug in the XML<->HTML parser [15:18] which messes up bulleted lists a bit [15:18] yes [15:18] at first I thought, okay, no big deal, should only affect users who edit notes in U1 [15:19] but then I realized that actually, you store HTML, and the conversion happens on each sync [15:19] well, this means anyone syncing experiences the bug [15:19] so even though I'm sure this will be fixed soon [15:19] this sort of thing could easily come up again [15:19] yes. [15:19] Your proposed alternative is, I imagine, store tomboy's XML in the DB, yes? [15:19] so I'd advocate storing the native XML format of the REST API instead [15:19] yup [15:20] my problem with doing that is that we have to have a working html-to-xml converter for the web UI anyway. [15:20] aquarius: well, it makes sense, since it's the format used by tomboy, conboy, tomdroid, etc [15:20] as I explained to rodrigo, I woudl guess that most users using Tomboy+U1 are using it for syncing, then a subset uses it for viewing too, and then a smaller subset uses it for editing [15:20] aquarius: or an editor that knows about the XML format, would that be too hard? [15:20] rodrigo_, check my facebook :) [15:20] aquarius: yeah, I sympathize with that issue [15:20] rodrigo_, yep, it's too hard. I tried that. Without writing a widget completely, completely from scratch, whcih is horrific pain [15:21] yes, the rich editors all use HTML [15:21] that makes sense [15:21] aquarius: you could have a cache, of course [15:21] sandy|lurk, I'm trying to avoid the web UI falling behind if there's a problem. This way, if there's a problem we see it immediately and can fix it immediately [15:21] generate the HTML only when the user actually views the note...slowish the first time [15:21] cache? [15:21] yeah, store both [15:21] yeah, but we have to back-translate [15:21] from arbitrary random HTML to tomboy XML [15:22] aquarius: only if they edit [15:22] aquarius: I understand that this way you see bugs faster [15:22] but users see bugs immediately that they woudl not expect [15:22] yeah. I'm not completely averse to the idea of storing tomboy XML in the DB, I admit [15:22] I would not expect simply syncing my notes to modify them in any way [15:22] (as a user) [15:23] storing both formats might be ok, I guess [15:23] oh, I agree [15:23] yeah, I don't know what your space constraints are [15:23] homeasvs_: in a minute... [15:23] text is small but doubling the storage could hurt, I dunno [15:24] space isn't a problem; my issue is that storing the same data twice is a flat-out invitation for them to get out of sync :) [15:24] but ideally, storing both would be my favorite soution [15:24] if they're translatable, then you don't need to store them twice. If they're not translatable, then the web UI is irretrievably broken anyway [15:24] yeah, and whenever you sync a note from tomboy, we need to convert, and the same when editing on the web [15:24] which gives us the same problem, if there are new tags in the tomboy xml not understood by the converter [15:25] well you already convert every note during a sync [15:25] my original intention was, as above, to make it so if it broke then it'd break for everyone and we'd notice and fix it fast [15:25] yeah [15:25] even though most users will nver usethe HTML [15:25] but if the converter is buggy, we have the same problem [15:25] aquarius: yeah, I understand that [15:25] but that seems pretty risky to me [15:25] but I am starting to think that the better approach is to have it so when it breaks, it doesn't necessarily break everything [15:25] so at least a subset of users won't experience the problem. [15:26] I think users using different editors on the same file may expect some weirdness [15:26] if I use Word and OO.o I expect formatting issues [15:26] ditto Tomboy and U1's note editor [15:26] sandy|lurk: you mentioned some time ago that plugins would use their own XML markup if needed, right? [15:26] rodrigo_: yeah, many plugins add new XML tags [15:27] if your converter doesn't know about them today, I don't know what you guys do [15:27] homeasvs_: yay! [15:27] if I write a custom add-in [15:27] that only I know about [15:27] and I don't share it [15:27] and it adds a new XML tag [15:27] and then I sync to U1 and it gets lost even though I don't use the editor [15:27] I'd be sad [15:27] it should, in theory, handle it ( gets converted to and then gets converted back) [15:27] aquarius: ah, cool :-_) [15:27] rodrigo_, I'll see about getting my packages done properly, cleaning up, and putting them somewhere [15:27] I did try to not have it throw away information ;) [15:27] rodrigo_, then next step would be desktopcouch stuff [15:28] aquarius: thanks [15:28] so then the only real concern is converter bugs [15:28] the current parser doesn't eat indented notes because it throws away information, it eats indented notes because it's appending children to the wrong place in the tree [15:29] if the bug was limited to the editor it would just be annoying [15:29] since it's not, it's critical [15:29] sandy|lurk: yay, I marked it as such [15:29] so a bug in the converter becomes a much bigger deal all of the sudden [15:29] yeah, so it comes down to a straight-up choice between 1. converter bugs get noticed quickly because they break everyone, and 2. converter bugs only affect a subset of users but are less likely to get fixed when they do happen [15:30] well maybe I can help with 2) by providing good complex test notes [15:30] I was leaning towards 1 (that's why we store HTML), but I am now leaning towards 2, with the caveat that we have to convert everyone's existing notes :) [15:30] I assume you guys have unit tests [15:30] homeasvs_: desktopcouch should be easier, I think, since python modules should be easy, right? [15:30] so better note data to test could help with 2 [15:30] good complex test notes would be good -- we do have unit tests for the converter, but they're not totally comprehensive (that's how we missed the nested-lists bug :)) [15:30] cool, I'll try to get to that before next week then [15:31] sandy|lurk: we have unit tests, but they don't test everything, so we're adding them [15:31] do you have a set of complex notes for tomboy's own unit tests? [15:31] so Tomboy sucks wrt unit testing [15:31] but I do have complex notes in my own collection for ad-hoc testing [15:31] * aquarius grins [15:32] us having them would help quite a lot :) [15:32] rodrigo_, yeah [15:32] when we were rewriting printing we came up with some fun gnarly notes to test with [15:32] rodrigo_, I guess it will depend on whether we need ubuntuone-storage-protocol [15:32] we need to have a working converter first, though, so we can convert the stored format for current notes [15:32] okay, I've got to run...employee meeting starting [15:32] sandy|lurk, cheers! [15:32] homeasvs_: that's for file sharing, so I guess not [15:32] but even then, should still be doable. Just want to clean up the current mess first before moving on, since I will probably need to pull in some couchdb patches as well for oauth [15:32] I also want to talk to you guys about note attachments at some point [15:33] rodrigo_, right, but I want to easily pair with u1 on the phone [15:33] homeasvs_, you don't need any ubuntu one stuff at all for desktopcouch. [15:33] homeasvs_: ah, ok [15:33] go homeasvs_ go! :D [15:33] homeasvs_, you need a little bit of it in order to replicate couch to u1, but not much (just enough to get the oauth tokens) [15:33] sandy|lurk: are attachments supported already in tomboy? [15:33] ie, how should we modify the REST API to support notes having files attached to them (images for example) [15:33] sandy|lurk: ah ok [15:33] sandy|lurk, that sounds like it'll be a fun conversation :) [15:34] rodrigo_: no, but I was working on it the other day [15:34] sandy|lurk, ah! ok, good, I thought it was going to be a kicking for us about not supporting them ;) [15:34] sandy|lurk: for images, I guess we need them [15:34] sandy|lurk, happy to think about that, definitely :) [15:34] cool, thanks for the chat guys [15:34] from our POV it should be easy, since we can store attachments with the couchdb documents [15:34] yeah, as long as no-one attaches an iso image to a note or something ;) [15:34] sandy|lurk: thanks to you :D [15:35] aquarius: :) [15:35] homeasvs_: oh, you mentioned the sdk repo in some facebook message, where is that? [15:35] homeasvs_: I haven't seen anything about it when looking for repos [15:36] rodrigo_, it's the one that is in your scratchbox [15:36] deb http://repository.maemo.org/ fremantle/sdk free non-free [15:36] homeasvs_: ah [15:37] rodrigo_, so I think that we should 1. get the converter working 2. change the back-end storage format to tomboy XML 3. convert all the currently-stored notes [15:37] aquarius: step by step, I'll work on 1 first :) [15:39] CardinalFang: ping [15:39] mandel, hi [15:40] CardinalFang: hello, did u see my message regarding the record_id branch? [15:41] CardinalFang, all that conversation about the if statement and at the end I used to wrong logic [15:41] mandel, I haven't seen that message yet, no. [15:41] https://code.edge.launchpad.net/~mandel/desktopcouch/record_id/+merge/15424 [15:41] CardinalFang, last message [15:42] CardinalFang, guillermo just changed to approved, but the code will not work [15:42] mandel, CardinalFang sorry :/ [15:42] it has 2 approves... [15:43] mandel: CardinalFang: should I cange it back to Needs review/reject? [15:43] rodrigo_: here's a test note that was great for printing, though it only goes two-levels deep for bulleted lists: http://bugzilla-attachments.gnome.org/attachment.cgi?id=127654 [15:43] verterok, CardinalFang, I would, you can blame me, it was my fault :P [15:43] mandel: should I change it to needs review? [15:44] verterok, I would [15:44] ok, done [15:44] mandel: thanks for pinting this out :) [15:44] verterok, no problem, the new version in the branch has the correct logic plus a test to avoid any other problems like this [15:45] verterok, totalmente mi culpa ;) [15:45] mandel: ooh, I see. you should "resubmit" the branch ;-) [15:45] verterok, will do [15:46] verterok, I just have to do a second merge proposal? [15:47] mandel: no, from the merge proposal pag you can resubmit it, and launchpad creates a new merge proposal that superseeds the current [15:47] verterok, mandel, usually it is best to push a new branch, but there's no reason to bother now. Everyone who cares is here listening and knows what's going on. [15:47] mandel, there's no red tape here. Let's worry about the bug instead. [15:48] CardinalFang, so I just do a superseed merge, ok [15:48] verterok, (I don't think one can resubmit a merged branch. I may be wrong.) [15:49] CardinalFang: it's merged? [15:49] Yes. [15:49] ooh, that's a different story [15:49] mandel: ^ [15:49] mandel, just push it as you intended to. It's all good. [15:50] CardinalFang, verterok, so I do not do anything, right? [15:50] CardinalFang, verterok, I feel kind of stupid for that error... [15:51] mandel: what CardinalFang said [15:51] ok [15:51] mandel: no worries, I reviewed the branch and didn't see it :/ [15:55] CardinalFang, I have pushed a new version of the branch with the changes + test [15:55] CardinalFang, although I can always push to a diff branch to make it explicit [16:06] mandel, there's a problem with your test. I'm adding a comment. [16:15] mandel, comment added. Needs fixing. [16:15] https://code.edge.launchpad.net/~mandel/desktopcouch/record_id/+merge/15753 [16:17] CardinalFang, cool I sort it out right away, I di dnot know that :D [16:31] CardinalFang, changed made, sorry for the pain in the ass [17:47] aquarius: you aboot? [17:47] otp [17:47] k [17:48] also for CardinalFang and thisfred: was thinking more about the way we'll handle delete in the future. If clients push content that has been seen before, presumably we'll need to provide a recognizable response so the client knows it can deal with the record properly. [17:49] "Hi, here's this bookmark." [17:49] "Bah, our user deleted that weeks ago. Begone!" [17:49] what HTTP response code would you use? Bad Request? [17:50] 406 Not Acceptable? [17:50] 410 Gone [17:51] I think 410 matches that story. [17:51] 411 "highly embarrassing"? [17:51] * rmcbride makes up HTTP response codes at randome [17:51] urbanape, I think upstream couchdb will be a better place to handle that, and I bet they will have something already planned. Maybe jan____ knows. [17:52] do you know off-hand what the conditions will be for determining identity? presumably the couch _id, right? [17:53] software is hard. let's go shopping. [17:56] jan____, without consulting #couchdb at all, we've been tossing around ideas for understanding and dealing with documents that are expunged from a database, so that replication doesn't reintroduce them. [17:57] jan____: particularly when Couch isn't the primary storage, but is the replication medium. [17:58] again: replication does not reintroduce deleted documents... [17:58] Ah. [17:58] thisfred: it's not about the replication [17:59] right [17:59] So it is a positive event. Sorry. [17:59] in Bindwood [17:59] so that other clients don't reintroduce them [17:59] (not replication, correct) [18:00] I think the way to solve this is to monitor _changes, and act accordingly [18:00] yes, but the question is what to monitor in changes? There has to be a there there to monitor [18:00] if deletions show up as a document in the _changes feed, we're fine [18:00] urbanape: ah, do delete events not show up? [18:00] that would be an unfortunate omission [18:00] I don't know, we don't delete documents [18:01] lessee [18:01] right, so we don't have the problem yet, or do we? [18:02] yes, they show up in changes [18:02] with a deleted flag [18:02] yay, we're done. [18:02] champagne and caviar, for everyone! [18:02] Can I have double champagne if I pass on the caviar? :) [18:03] no. Eat your fish eggs and like 'em. [18:03] * thisfred mopes [18:03] CardinalFang: we (at least Bindwood) have no problems in this regard any longer. [18:03] forget I ever ranted and/or raved. [18:04] we'll actually just do delete documents and pull those changes from _changes when we normally poll. [18:05] urbanape, yo [18:05] aquarius: never mind, we solved it. [18:06] urbanape, oh, good. I shall read the scrollback :P [18:08] summary: deleted docs show up in _changes with a deleted: True field in the record. [18:09] so we don't need to tag records with deleted, now that we're polling _changes. We can just tell Couch to delete the doc, and it'll show up for other clients in _changes. [18:09] We don't need to wait for history. [18:13] as long as bindwood polls _changes, yeah. Excellent. That's just excellent, is what that is [18:14] now all we need is chromium support for shelling out and then I can have my bookmarks back again :P [18:25] yes, I need to hang out in #chromium some more. [18:26] I just think it might be beyond their scope. [18:26] Expeciallly in light of Chrome OS. [18:27] "What would you shell out to? There is only the browser. What would you gain from an environment (in an env sense) that is only the browser?" [18:28] and I don't think they want to entertain the notion of extensions that only run on "desktop OSes" [18:30] NOT A DESKTOP [18:31] kthx [18:32] :) [18:32] your pedantry is quaint, but I don't think you're going to convince the world. [18:34] I'm gonna start just calling everything jeejahs. [18:34] desktop jihad [18:34] convert or die :) [18:35] can we not get bookmarks and passwords out of chrome? [18:36] if not, it sounds like an antitrust suit waiting to happen :) [18:37] we can get bookmarks. Not sure about passwords. [18:37] the problem is we can't shell out to get our dbus couch port or get at our oauth tokens. [18:38] oh we can't run python? [18:38] we can't shell out period. [18:38] we can't run an external process [18:39] yes, that's what i was saying [18:39] do they provide some way to access local disk data from internals? [18:39] (please don't say "HTML5 storage") [18:40] I believe you can get to file:/// resources, but I don't think there's a way to get to $USER from javascript, so per-user files would be hard to do. [18:40] still learning some of this stuff, so it might be possible. [18:41] and you probably can't do things like read/write from/to unix sockets [18:41] hmm, you can use NPAPI for "legacy" stuff. [18:41] what the heck is "legacy"? [18:41] certainly not a 2TB hard disk [18:42] http://code.google.com/chrome/extensions/npapi.html [18:42] "legacy": "anything that we don't explicitly provide as an extension API" [18:45] "anything that isn't google docs" [19:00] aquarius, thisfred, mandel, https://code.edge.launchpad.net/~cmiller/desktopcouch/attachments/+merge/15765 [19:00] Review? Complain? [19:00] * CardinalFang acquires comestibles. [19:04] CardinalFang, why block overwriting of an existing attachment? to stop people doing it by accident? [19:14] aquarius, Yes. I want anything that destructive to be explicit. [19:14] but record["foo"] = "bar" is destructive too, no? even if record["foo"] == "quux" [19:14] and changes aren't *saved* [19:15] Just a thing I wanted to ask some days ago. Where does the diff containing debian/ directory come from for ubuntuone-client lp trunk? [19:17] aquarius, They may understand index or key assignments, but the verb "attach" doesn't convey "be sure not to have the same name already, or you lose". [19:17] replace() ? [19:17] I see your point. [19:18] don;t want replace() since most of the time you're not replacing anything [19:18] yeah, maybe you're right. :) [19:39] CardinalFang, looking at it right now [19:44] CardinalFang: what about using an update rather than detach, attach??? [19:46] CardinalFang: looks good to me. Just one questions: Why do we not want CouchDB to provide ids for documents? [19:46] thisfred, they say it's a bad idea. [19:47] really? [19:48] thisfred, yes, it should be done in the client side, I had to do the same in my code [19:48] Is the algorithm broken, or are there collission issues? [19:48] From python-couchdb cleint.py : """Note that it is generally better to avoid the `create()` method and instead generate document IDs on the client side. This is due to the fact that the underlying HTTP ``POST`` method is not idempotent, and an automatic retry due to a problem somewhere on the networking stack may cause multiple documents being created in the database.""" [19:49] anyway, that's just curiosity. If it's a better idea not to, I'll change the server side code not to do it either [19:49] CardinalFang: ah yes, that makes sense [19:50] Not having transactions is the price we pay [19:50] thisfred, I changed the server class, "put record". [19:51] thisfred, adding to what CardinalFang said: http://www.atypical.net/archive/2009/05/12/couchdb-090-bulk-document-post-performance [19:51] CardinalFang: right, should be enough, just checking that I'm not putting anything else bypassing the API [19:51] like users [19:51] hmm, I was just about to noodle on how bindwood could drop the FF-generated UUIDs in favor of getting the next id from Couch and use that as the unifying foreign key. [19:52] or am I misunderstanding that? Are they suggesting that clients generate ids for documents? [19:53] urbanape, yes, from my understanding, the client should generate the id [19:54] even on id-less PUTs? [19:55] CardinalFang, got a question, why do you have a try block in list_attachments?? [19:55] urbanape, Yes. HTTP isn't smart enough. If you're going to be stateless, you have to be able to handle when you're redirected several times. A (e.g.) proxy between you could PUT more than once, and that would cause problems. [19:56] CardinalFang: fair enough, I suppose [19:57] mandel, good find. No reason, now. I was creating _attachments somewhere else. Now I make it at __init__(), and so I can be sure it exists. I'll remove it. [20:00] CardinalFang: in the detach, you will have a keyword error when poping, do you want to give the default message or put your own? Maybe "not existent attachment or empty" or something of the kind [20:01] CardinalFang, of course when working with an empty dict or none existing keyword, but I'm sure you knew what I meant ;) [20:11] mandel, Okay, I added more descriptive KeyErrors. Thank you. [20:17] CardinalFang, One last thing, if you are going to generate the id in the client side, why not moving that to the record constructor when the record_id or data["_id"] is none. [20:18] CardinalFang, I know it is less lazy, but from my point of view it looks nicer [20:18] CardinalFang, one stored the other one takes care of the id, but this is just my opinion [20:19] mandel, I want to keep as much as possible like the old behavior. [20:20] CardinalFang, ok, I understand. Then everything looks great! [20:21] CardinalFang, I'l use it as soon as it is merged, thanks! [21:03] Hello [21:04] Phở? Yum. === verterok is now known as verterok|brb === verterok|brb is now known as verterok [21:35] I have just gotten a (well, two) share-e-mails, but when I press the link, I get a "Something has gone wrong (500)". Nothing is available through the Ubuntu One folder either. [21:39] kjoller: hi, yes it's a known issue, it will be fixed real soon [21:39] verterok: ok, great, thanks [21:54] verterok, pfibiger: do we need a rollout before sharing is fixed? [21:55] i am so woefully behind on things [21:56] statik: "A plan is just a list of things that don't get done." [21:56] statik: yes, the fix already landed [21:57] cool, thanks [22:16] how do i relocate my files on ubuntuone to a different folder or rename a folder? [22:31]