[00:00] tchernobog, the only way I can explain this is that couchdb was not very cooperative to evolution. When couchdb got restarted, existing e-d-s did not spot the change of the credentials, environment or the phase of the moon. Killing e-d-s made it reconnect to couchdb server. [00:00] BUT [00:01] the question is why it did not work earlier [00:01] nice question [00:01] probably because the credentials went wrong for both the sync daemon and evo [00:02] tchernobog, yes, but you say that sync stopped this friday or so. [00:03] tchernobog, okay, the only thing required is to reproduce it somehow with some dummy data to make sure this will not get 'WTF?' questions in the future [00:05] oh, for heaven sake. i don't know if i should shiver or cheer [00:06] it has also sent online the contact I copied from my evolution addressbook [00:06] to the couchdb one [00:06] it took ages, but it did that [00:07] tchernobog, the contacts are first created in local couchdb and then replicated to u1 service every $some minute. [00:07] yes, so we know now it works [00:07] but i'm still wondering why it didn't before [00:09] tchernobog, unfortunately I've seen at least 2 such cases here in the last 2 weeks, when it "magically" started to work. [00:09] so, the fastest route seems to remove the auth keys from seahorse and, if you're not familiar with the terminal, log out and in again [00:10] tchernobog, okay, that was a nice chat but it's 2AM over here and it looks like this is time to sleep :) So good luck with your BhD! And stay tuned to #ubuntuone, not only if something bad happens but when something good happens as well :) [00:10] it's 1 AM here, so I agree [00:10] tchernobog, in your case it was necessary to kill the management [00:10] :) [00:10] * the management database :) [00:10] sleep tight, thanks for everything [00:10] oh, i do that at work everyday [00:10] damn, you beat me on time [00:11] goodbye, and thanks [00:11] tchernobog, yep, you too. good night :) [00:11] * rtgz_ copies the log 'cause ubuntulog does not seem to log this weekend's conversations [04:23] hello is anybody here [04:24] i have a question that when i synchronize notes use tomboy with one.ubuntu there is a error that "Could not synchronize notes" [04:25] my tomboy is new install but i have some notes in the ubuntuone before some notes write using tomboy under ubuntu and some under xp [04:27] ??????????? [09:19] thomasbe, hey [09:20] aquarius: is launchpad down? [09:21] looks like it [09:22] aquarius: question, have you notice that when working with desktopcouch trunk if you try to access the db through the bookmark it asks for username and password? [09:22] I've been dealing with it most of the weekend and I do not know it is is 'cause I broke it or 'cause it happens in every machine [09:22] mandel, it shouldn't do; if it does, that means the couchdb.html file is out of date. that's what we tried to fix in dallas, no? [09:23] aquarius, dallas was another issue, there the bookmark was not updated with the right port and password, in this case the port is correct but it ask for auth [09:24] ah, you mean that it says "you are about to log into localhost port 23423 with username KLHFOIUHEFPHP are you sure you want to allow this?" [09:25] no, it actually asks for the user name and password, that message I know [09:25] so the port is right but the username/password are wrong? [09:25] that's broken [09:25] delete the ini file and restart DC [09:26] I actually have instructions for how to do that in http://www.freedesktop.org/wiki/Specifications/desktopcouch/Documentation/Troubleshooting now :) [09:28] that is what I have been doing all day :P [09:28] mandel, LP back up anyway [09:28] well, and fight with bloody quickly to make a package... [09:28] mandel, confused :( [09:29] aquarius, funny, anyways, I just wanted to check if my ppa was there with the new version [09:30] aquarius, hi [09:30] I'll hang around here all day anyway, I'm working from home, the business is deciding if the cancel yet another project I'm working on at the office, so nothing to do there today :D [09:30] aquarius, so, currently struggling with figuring out why couchdb internally fails to replicate with ubuntuone [09:30] aquarius, works on my ubuntu macbook, fails on my two f11 machines [09:31] homeasvs_, and the replication log isn't showing anything massively obvious? [09:31] aquarius, currently suspecting certificate stuff, but don't know how erlang/ssl/couchdb/desktopcouch works [09:31] aquarius, nope, nothing obvious [09:31] aquarius, and pretty sure it's in ssl_esock [09:31] which is what I've been stracing for a while now [09:31] it would help if someone could look at the u1's couchdb log :) [09:31] ah, man, you think it's actuallly failing in the SSL stuff? [09:31] yeah [09:31] I can look at that log, sort of [09:31] that's my best guess atm [09:31] we only get it refreshed once an hour [09:32] (debugging this stuff was really hard for us, too) [09:32] oh well, should be fine, it's been failing all weekend :) [09:32] but first of all, know anything about how the certificate part works ? [09:32] * aquarius grins. I'll have a look [09:32] maybe erlang is just internally failing because it doesn't know the certificate [09:32] could be -- have you said your couch debugging level to debug? [09:33] also, what's the 'weird' part from this url: https://couchdb.one.ubuntu.com/u%2F0a4%2F330%2F97870%2Fgtd/ [09:33] is that some hash tied to my user ? [09:33] yes [09:33] aquarius, yes, I did, also on the working one, to see where it compares [09:33] aquarius, ok, do you have a way to see if it's actually there on the server ? [09:33] we need that because you might have a gtd database and so might i [09:33] understood [09:34] how long is an oauth token valid for ? I tried to do manual curl requests to see if I could debug it, but couldn't get a working token [09:34] I don't have such a way, but I think I can find an admin who does :) [09:34] oauth token should be valid forever [09:34] BUT [09:34] can only be used once ? :) [09:34] we've had a couple of server problems with oauth tokens [09:34] the token for filesync occasionally doesn't end up correctly in couchdb [09:34] meaning that you can't authenticate [09:35] hm, well filesync has worked from the beginning [09:35] yep [09:35] my problem is pretty much only with the couchdb sync part [09:35] so, anyone who knows about the certificates part and how I can debug it ? [09:35] yeah, the issue is that for some people, their oauth token never gets copied to couchdb, so they can't sync to couch. [09:35] the weird thing is, on the macbook, I see it looking for a .pem file, but it fails to find it [09:35] it only seems to happen occasionally, and we're not sure why [09:35] and it goes on without it [09:36] on my machine, it does find it, reads through it, and then goes on [09:36] hm [09:36] maybe I should try *moving* my ssl certs temporarily just to see what would happen [09:36] I don't get that, though [09:37] give me a quick primer on SSL -- do you suspect that the problem is that our SSL server is signed with a root cert that's not in Fedora but is in Ubuntu? or do you suspect something stranger? [09:37] I assume u1's couch is only available over https ? [09:37] correct, https only. [09:38] aquarius, at the moment I'm suspecting the reverse - ubuntu's ssl_esock is not finding any certificates, so just happily accepts [09:38] otherwise all your data is sniffable :) [09:38] * aquarius laughs [09:38] fedora's does find certificates, and then hangs up because it doesn't match [09:38] it's a wild intuition based on the logs however [09:38] if that's actually the case, then I do believe we have a bug to fix, since SSL is flat not meant to work like that :) [09:38] my previous guess was 'fedora doesn't know about u1's cert, so it hangs up' haven't ruled that out yet [09:39] yeah :) [09:39] well, it's harder with the exponential backoff :) right now it's waiting for 256 secs before giving up finally [09:39] definitely, desktopcouch-service doesn't handle this error case nicely - a bunch of threads are left hanging [09:39] (when you run -stop) [09:40] (why are you even spawning threads at all if you're using twisted ?) [09:41] on threads, I'm not sure -- chad knows more about that piece of the code. [09:43] On error handling -- from my perspective that's a slightly philosophical issue. It should work. We shouldn't deal with auth not working, because there's no reason why it shouldn't work, in the same way that apps shouldn't have to deal well with "I wrote the letter A to a file and when I read it back it was B", because that should just work [09:44] what do you mean, 'auth should just work' ? the internet is a hostile place, code should handle failures gracefully [09:44] hm, any idea what cert auth your cert is signed by ? the go daddy one ? [09:45] there isn't any graceful handling, though. If replication doesn't work then the whole replication daemon is screwed, basically [09:45] what should it do at that point? [09:46] not sure which use case specifically we're talking about here [09:47] for the filesync I'd expect the notification applet to tell me there is a problem [09:47] (but right now it's still using 100% CPU when it's running, that's after this ssl bug on my list of things to fix) [09:47] hm [09:47] so, might it be possible that you need one of the two u1-storage-protocol .pem files installed for this to work at all ? [09:47] asking our admin people about the cert [09:48] if that's the case, *and* I am lucky, then it's just a matter of installing those .pems in the different locatino for fedora [09:49] admins say: godaddy [09:50] fingers crossed that you are lucky :-) [09:51] * aquarius gives bug 489963 a baffled look [09:51] Launchpad bug 489963 in desktopcouch "desktop pairing only works when starting desktopcouch-service manually" [Undecided,New] https://launchpad.net/bugs/489963 [09:52] why would d-bus starting desktopcouch-service make a difference? don't understand that. [09:52] yeah, me neither [09:52] I will do a bunch of repeat tests, maybe it's entirely random [09:53] hm, so those two pem's you ship with u1-storage.... are they CA certs ? or something else ? [09:53] * homeasvs_ always gets those things confused [09:57] I don't know about the pems either -- I *think* they are certs [09:57] ok, so let's start simple here. [09:57] How can I issue a curl request to my local desktopcouch to make it try and replicate to u1 ? [09:57] that would make this debug process a lot faster [09:59] right, let me construct that for you, hang on [10:04] I'm not convinced I have a cert problem. When I browse manually with firefox or links to https://couchdb.one.ubuntu.com/(hash)/contacts/, it pops up a dialog saying 'administrator' asking for user/pass [10:05] that would indicate there is no cert issue, I'd think [10:12] homeasvs_, curl -X POST http://basicauthusername:pw@localhost:LOCALPORT/_replicate -d '{"source":"database", "target": { "url": "", "auth": { "oauth": {"token":"", "token_secret": "", "consumer_key": "", "consumer_secret": "" } } } }' [10:12] homeasvs_, I agree on the cert thing [10:13] see your local management database for the oauth details, specifically the record about Ubuntu One [10:14] could somebody with sufficient permissions please poke ubuntulog so that it starts logging to irclogs.ubuntu.com? [10:15] aquarius, I tried that this weekend, let's see if I can try that again [10:16] aquarius, did you know that jsut changing the http:// part of that to be correct makes the request hang ? [10:16] aquarius, ie, with all empty vars [10:16] aquarius, can you reproduce that problem ? [10:18] so, with correct basicauthusername/password, a correct source dbname, and a correct target url? [10:20] yes [10:20] wait [10:20] that's not what I meant [10:20] with correct basicauthusername/pw, and everything else as you typed [10:20] doesn't hang for me; I get {"error":"db_not_found","reason":"could not open https://couchdb.one.ubuntu.com/u%2F3c5%2F9dc%2F21%2Ftest/"} [10:20] ie, empty variable values [10:20] which I'd expect [10:21] with an empty target url, I get an erlang traceback error,no_scheme [10:21] which I'd also expect [10:21] really ? I get no result [10:21] just hangs [10:21] I'd expect it to error out [10:21] because it's trying to connect to a target URL that isn't there [10:21] maybe I should try this against my 'normal' one [10:22] so it should tell me it's not there instead of hanging! [10:22] curl -X POST http://UUU:PPP@localhost:39834/_replicate -d '{"source":"test", "target": { "url": "", "auth": { "oauth": {"token":"", "token_secret": "", "consumer_key": "", "consumer_secret": "" } } } }' [10:22] that gives me an erlang traceback [10:22] it does so too on my macbook [10:22] not on my fedora machines [10:22] are you using the same version of couch? [10:22] we carry a couple of couch patches [10:23] yeah, I pulled in those patches this weekend [10:23] so afaik yes, but not sure how to be sure :) [10:23] * aquarius grins [10:23] I just noticed though you guys carry erlang 13b while fedora has r12b [10:23] I'm not sure either [10:23] aha [10:24] that might have something to do with it [10:24] you think there might be important bugs fixed there ? [10:24] sheesh, I would *not* look forward to rebuilding erlang :/ [10:24] yes. the couch people bumped their required erlang version up a few notches [10:24] I don't know exactly which minimum version is required, but I am pretty sure that you need r13 [10:25] we rely on #couchdb to tell us that... [10:25] I'll ask them [10:30] ok, so interesting! [10:30] I can get curl to do replication now [10:30] on my fedora machine [10:31] when source is local, and target is ubuntuone, it seems to 'work' in the sense that it finishes properly [10:31] when I reverse source and target, to pull from u1, then I get all the worker dead errors in my couchdb log [10:31] rodrigo_ ping [10:31] trying the same now on the macbook [10:31] so on the macbook, it works both ways [10:31] interesting! [10:31] now what could cause the push to work and the pull to fail ? [10:32] aquarius, I think we could really use those server logs right about now :) === homeasvs_ is now known as homeasvs [10:33] looking for them :) [10:35] can you name a specific database that you've been trying to replicate that other people may not have? [10:36] well, right now I'm doing it with contacts [10:36] I know it's there, since it works on the macbook with ubuntu [10:37] and u1's web shows me the contacts I created [10:37] one is me, one is one i created through the web, and one from evo [10:37] this particular db I cannot 'pull' from u1 on my f11 machine [10:37] to me it seems like it's failing internally somewhere [10:37] I'll show you what debug messages I get from that [10:39] ok, looking at logs [10:39] mandel: pong [10:39] aquarius, http://pastebin.com/m251b3508 [10:40] aquarius, so, as soon as I ask to replicate, I get these couch_rep_httpc errors [10:40] rodrigo_: I was wondering what are we going to be doing about the groups, are we using the categories field? [10:40] ooooo. [10:41] mandel: not on the stable version, but we should be adding it soon [10:41] rodrigo_: and how are the groups represented, string, lists of strings... [10:41] they're not good. Like you say, that's an internal-to-couchdb error [10:41] mandel: comma-separated strings [10:41] rodrigo_: which field? [10:42] mandel: categories [10:43] rodrigo_: ok, I'll work on my side with that assumption to try and get my stuff working, gracias :P [10:43] mandel: for simulating groups, we could use '/', so friends/madrid, work, work/design_team, etc [10:44] rodrigo_: I was thinking of that as well, it should be easy to implement without much problems [10:47] once again, don't do that [10:47] make a group a list [10:48] [ ["friends", "madrid"], ["work"], ["work", "design team"] ] [10:48] otherwise fans/AC/DC is a problem [10:48] :) [10:48] aquarius: bloody AC/DC [10:49] hey, they have a number of fans, what with being the most popular rock band in the world and all :-) [10:49] aquarius: the worst thing is that you used the same example in dallas [10:49] I know :) [10:56] aquarius, f12 has a 13B erlang, will try and rebuild that one and see what happens [10:56] aha, that sounds useful [10:56] I wish erlang tracebacks were more readable [10:56] I don't know how easy it is to backpor [10:56] *backport [10:56] come to think of it, I wish erlang were more readable :) [10:56] we'll see soon enough [10:56] homeasvs, hahaha. You are not the first person to complain about this, my man :) [10:57] do you guys carry specific erlang patches ? [10:57] we hate it just as much as you do :) [10:57] I don't know yet if it's hate or ignorance :) [10:57] erlang...not sure, hang on [10:57] I need to context-switch into work [10:58] bah [10:58] work's not important. :) [10:58] I concede that I have the advantage that this *is* work for me :) [11:02] aquarius: that is not fair... wanna swap jobs? :P [11:02] nah, i like my job :) [11:03] aquarius: sigh, had to try ;) [11:18] homeasvs, I don't *think* we're carrying any relevant erlang patches to 13b1. There *is* an ssl patch, but it says that it's to add ipv6 support for ssl [11:19] I suppose it's possible that that alters the way ssl works in some way. But I'd try the stock r13b from f12 first, I think === rtgz_ is now known as rtgz [12:11] hi all,. QUESTION: is birthday & anniversary contact sync working ? what is the proper format for birthday so that i can test it from the webUI ? 01/15/2001 is correct ? [12:11] aquarius, ok, it looks like exactly the same request with 13b erlang works [12:12] homeasvs, aha. so, I conclude that r13b is required :) [12:13] will file a couchdb bug and see what they say [12:13] and verify some more [12:13] gourgi, that's a rodrigo_ question, that is :) [12:13] this might be close to the end of the tunnel [12:13] homeasvs, heh, enjoy interacting with the glory that is Jira :) [12:13] :) [12:13] rodrigo_, ^^ [12:13] gourgi: yyyy-mm-dd [12:14] gourgi: but there is a bug in the version in karmic, so please use the updates in our beta ppa [12:14] ty rodrigo_ , so it should work , right? [12:14] rodrigo_, if date format matters, should we be enforcing it? [12:14] ah ok , i will thanks rodrigo_ [12:14] keep up the good work guys ;) U1 is great so far [12:14] aquarius: we enforce it in the web UI [12:14] aquarius: and evolution knows how to deal with the current locale [12:14] ah, OK [12:15] gourgi, where were you entering a date? [12:15] at evolution firstrly, now i;ll try the PPA and the webUI [12:15] evolution first didn't work, only for birthday data [12:16] gourgi: https://edge.launchpad.net/~ubuntuone/+archive/beta [12:16] rodrigo_ ty :) [12:16] gourgi: yeah, it was broken, so was not saving any date at all [12:18] aquarius: https://issues.apache.org/jira/browse/COUCHDB-585 [12:18] alright, let's see if I can get full sync working now [12:18] rodrigo_ another question : in the webUI contacts sort by first name. wouldn't be better to be sorted by last name? [12:19] at least that is the default sorting in my country (Greece) [12:19] homeasvs, good work. We make progress! [12:19] homeasvs, s/We/You/, obviously :P [12:19] aquarius, heh. where progress is me suffering all weekend and you coming in on a monday :) [12:20] homeasvs, I'd have been here over the weekend if I had the net [12:20] as it is I am still using my mobile phone [12:20] stupid cable provider :( [12:20] aquarius, no worries, I'm a free man, it's my choice to waste my weekend on exciting new and fragile tech :) [12:20] * aquarius grins [12:20] gourgi, I guess the better option is to be able to specify the sorting method, 'cause it is common to sort by last name here, in post-USSR countries, but the 'new generation' uses first name sorting [12:21] gourgi: yeah, maybe, file a bug if you think so please [12:21] aquarius, btw I submitted a patch to make desktop-pair a little cleaner code-wise - not sure if I need to sign anything if you want to accept those ? [12:21] most mobile phones etc seem to default to first-name sorting, because people think of their friends as "George", not "Mr Kite" [12:21] rtgz agree, rodrigo_ what is the proper package.place to fill a bug ? [12:22] homeasvs, I saw the patch (and good work!); we need the contributor agreement signed, yeah (http://www.canonical.com/contributors), if you would [12:22] gourgi, file a bug with "ubuntu-bug evolution-couchdb" from a terminal [12:23] gourgi, I guess it will be the https://bugs.launchpad.net/ubuntuone-servers/+filebug. aquarius isn't it the Web UI setting, re: sorting method? [12:23] aquarius ok thanks, i've asked because it is a suggestion against the webUI [12:23] rtgz, hm, yes, true -- gourgi, please use the URL that rtgz gives :) sorry :) [12:24] okk :) [12:24] sweet jesus [12:24] here are all my contacts and bookmarks, sitting pretty in my desktopcouch [12:24] homeasvs, w00! rawk. [12:24] ok, now I can get into the more interesting questions [12:24] still left: 100% CPU in the applet to fix [12:24] so, first question [12:24] why are the replications not continuous ? :) [12:25] ah, now, we thought about continuous replication, and there were some issues with it [12:25] I find it weird to go through all this trouble, then notice a delay between editing on one machine and seeing them on another [12:25] but, annoyingly, I can't remember precisely what led us to do every-10-minutes rather than continuous [12:25] one more, there were some disruptions of the service yesterday, i.e. no files were accessible via the web interface. Is there any way for u1 to set up some 'status' service, i.e. "the storage service is inaccessible because it broke. ETA: 12 hours, workarounds:", "couchdb service: ok", "sync service": ok [12:25] it's like running the race, then falling over right before arriving at the finish line, dropping your pants, and sticking your bottom out [12:25] when cardinalfang shows up we'll ask him, since I bet he remembers. :) [12:26] homeasvs, colourful analogy ;-) [12:26] aquarius, all I'm saying is, we should be going the last mile :) [12:26] because the users are made to think about u1 as a 'magical world' where everything happens by itself :) [12:26] aquarius, if there's a reason, I'd like to know, because all your eager testers are going to wonder exactly the same thing. 'why does this thing not sync automatically?' [12:27] homeasvs, agreed [12:27] ok, I'll clean up my packaging so I can put stuff online. I've patched everything that didn'twork on stock python 2.6.0, without needing to touch python [12:27] it's a fragile balance but it seems to work, except for the applet. [12:27] bug submitted # 490311 [12:27] I should try desktop pairing again to see if sync now works fine there [12:28] thanks for doing that. It's a touch difficult for us to check whether a thing we're relying on actually appeared in python 2.6.1 or whatever :( [12:28] aquarius, buildbots ? [12:28] shouldn't be too hard [12:28] the horror that is httplib being a case in point [12:29] come to think of it - do you have a testsuite that would have shown me these bugs ? [12:29] there's a test suite, yes, but it doesn't test replication at the moment [12:29] "trial desktopcouch" will run the test suite [12:30] homeasvs, on buildbots, yeah, but we rely on a load of stuff that appeared in 9.10, so we don't test against 9.04, which had a lower version of Python [12:34] aquarius, second question, is my data encrypted on u1 ? [12:34] aquarius, if not, any plans for that ? [12:34] aquarius, not yet sure I *want* my personal data readable by your admins [12:35] homeasvs, it's not encrypted on the back end, because we want to integrate with encryption on the desktop; obviously data that's encrypted ont he desktop will be encrypted on the server too [12:35] testing replication is hard, btw, because the test suite would need to set up two couchdbs and an ssl proxy to do it properly :( [12:36] aquarius, so you're basically saying, the client should encrypt docs somehow before sending to ubuntuone ? [12:36] Ubuntu has the concept of an "encrypted Private directory" (it uses ecryptfs), so we'd like to integrate with that [12:36] homeasvs try cryptkeeper, it uses EncFS for encryption , i use it and it works. you only need to remember the passprhase and keep .encfs6.xml for restore purposes. [12:37] aquarius, gourgi: not sure how either would work for my data in couchdb ? [12:37] homeasvs, oh, couchdb data? that's not encrypted, but it is secured with your oauth token, which I do not have [12:38] aquarius, but anyone who's root on that machine can get my data no ? [12:38] aquarius, or am I missing something ? [12:38] homeasvs, correct, because they can read your oauth token out of your keyring [12:39] ok [12:39] so encryption might still be a desired feature [12:39] maybe that should be a couchdb feature [12:39] ok, third question [12:39] it looks like replication doesn't replicate any of my views/templates/... [12:39] interesting idea. I'm not sure how it'd work, but it needs talking about [12:39] is that possible ? [12:40] it'd be nice if it was possible to get something futon-like accessible for the u1 couchdb [12:40] it makes it hard to debug certain things without seeing what's going on there [12:40] it would be nice. We're still talking about that. [12:40] part of the problem is that browsers don't do oauth :( [12:40] is there a way to force a contact sync from evolution ? [12:41] homeasvs, there are certain issues with you being able to create views that actually run on one.ubuntu.com, like we need to stop you writing a view which eats all the CPU for example. This is why it's not currently possible :) [12:42] homeasvs, but I really like the idea of being able to write CouchApps on top of couchdb and deploy them on our infrastructure [12:42] aquarius, yeah, the views was what I was suspecting would be the major blocker, but it ought to be doable to limit that [12:43] aquarius, I don't necessarily need to run my couchapp on your infrastructure, I just want that couchapp replicated to all my clients [12:43] agreed it ought to be doable, we just haven't yet had a chance to figure out how :) [12:43] aquarius, right now it seems it doesn't do that [12:43] aquarius, am I missing something maybe ? Or has it not been tried ? [12:43] I'm not 100% sure how these things work, I think they are attachments to a database [12:44] yeah. A temporary get-halfway-there approach would be to allow replicating the views but not allow them to run on the infrastructure [12:44] I believe the issue is this: views are defined in design documents. To create a design document you have to be an admin. you're not an admin on couchdb.one.ubuntu.com, so the views don't replicate [12:44] oh, ok [12:44] thisfred knows Much about this area, though, so we'll ping him when he arrives [12:45] ok [12:45] so I guess for now I need to use couchapp to push it to my desktopcouch instance [12:45] yeah, although couchapp won't push it there by default because it doesn't know about oauth [12:45] on my list of Cool Stuff I Would Like To Do is teach it :) [12:46] (you could just use the basic auth username adn password, which you are Not Supposed To Do, but I didn't just suggest that :)) [12:46] contact sync with birthday works with the ppa version. cool! :) [12:47] gourgi, excellent! [12:47] aquarius, don't worry, I was already planning to do just that [12:47] aquarius, let's ping thisfred now that he's arrived [12:49] homeasvs: actually I just dropped in on IRC to say that I'm sick, sorry. You can mail me at eric.casteleijn@canonical.com, and I promise I'll have a look at it when I get better, if no ome else here can help you [12:49] thisfred, get better soon [13:14] homeasvs, have submitted your patch for code review at https://code.edge.launchpad.net/~sil/desktopcouch/pick-or-listen-non-global-489925/+merge/15419 [13:15] homeasvs, I don't know if you're using bzr, but if you are then you are welcome to submit branches yourself?) [13:35] aquarius: question, is when creating a record passing a dict, the dict contains and "_id", should't the record_id be set up? [13:35] mandel, yes. [13:35] I think [13:35] * aquarius checks :) [13:36] aquarius, do you mind if i send a patch then :D [13:38] mandel, it works for me [13:38] python -c "from desktopcouch.records.server import CouchDatabase; from desktopcouch.records.record import Record; db=CouchDatabase('test', create=True); r=Record({'_id':'someid','name':'sil'}, record_type='http://example.org'); db.put_record(r)" [13:39] aquarius, 'cause the couchdatabase class does the check, but not if you do: record = Record({"_id":"2323"}, record_type="url") [13:39] server_base does record_id = record.record_id or record._data.get('_id', '') [13:39] while record does not [13:40] mandel, ah, so you want Record by itself to set up record_id? gotcha. Yep, patch patch patch away :) [13:40] aquarius: ok, thanks :D [13:43] aquarius: what should happen if the data passed to record have an _id and we pass the record_id parameter? [13:43] aquarius, I'd say exception [13:44] issue a warning with warnings.warn and use the one in _id [13:44] I suppose we could throw an exception, but it seems a bit harsh [13:44] aquarius, ok [14:20] aquarius, patch done and summited :) [14:21] mandel, nice :) did you link your newly created bug to the branch? [14:21] aquarius, yes [14:21] winner [14:21] aquarius, I'm getting better at this ;) [14:37] * rtgz has been browsing google wave for 6 hours and still can't get the point... [14:40] http://www.linux-magazine.com/Online/News/Ubuntu-One-Clients-for-KDE-and-Fedora: Independent of the Kubuntu project, Fedora developer Thomas Vander Stichele is working on an Ubuntu One client for Fedora. Because Ubuntu One is at least partially a closed code project, it creates somewhat of a challenge. (Marcel Hilzinger) [14:43] you, close source bastards! hehe [14:44] yep, we demand the access to the closed-source billing system including credit cards data [14:50] it's amazing how many pingbacks I get on the fact that I'm doing this === vds1 is now known as vds === rtgz is now known as rtgz|very_away === joshuahoover changed the topic of #ubuntuone to: Have a question? Ask for joshuahoover | Updated client software is now available to everyone running Ubuntu 9.10. Please run Update Manager to install it, and then restart the client. Enjoy 9.10! | https://one.ubuntu.com | https://launchpad.net/ubuntuone | Current Testing Client Revno is 278, Protocol Revno is 73 [15:24] mandel, I reviewed "record_id" branch. [15:26] CardinalFang: replying right now, I agree with most of it, including removing record_id and use a property that just looks into _data [15:26] in the branch I already removed all the uses of _id outside record that I know [15:26] You rock. [15:28] CardinalFang: I'll update the code and will let u know through lp :P [15:36]