[00:01] all day ubuntu one does not sync files just makes empty copies this between Karmic and Jaunty [00:02] even after disconnects and connects [00:02] and says updating 1 of 2 files and there it hangs [00:04] leonel: did you update the client lately on the jaunty machine? [00:05] yes 0.94 [00:05] 0.94.0+r198-0ubuntu1~ppa1~jaunty [00:06] leonel: how about the karmic machine? which alpha are you using there? [00:07] 2 hours since last update [00:08] leonel: alpha 5 then? [00:08] leonel: that was released today [00:08] joshuahoover: yes [00:08] k [00:09] hmmm...if you look in ~/.cache/ubuntuone/log do you see any files with syncdaemon exception in the name? [00:11] ubuntuone.SyncDaemon.State - ERROR - READY_WITH_NETWORK --[SYS_SERVER_RESCAN_DONE]--> ERROR!!! [00:12] BadTransition: State READY_WITH_NETWORK can't handle the SYS_SERVER_RESCAN_DONE event [00:12] leonel: ok, i think you're going to need to file a bug report [00:12] that from the latest log [00:12] going to bugs.launchpad.net [00:12] thanks [00:12] leonel: if you right-click on the ubuntu one applet, select "report a bug" [00:13] leonel: and if you don't mind, can you attach the exception log to your bug report? this will help us figure out what's going on a bit better...thanks! [00:16] joshuahoover: how do I attach the log the right-click does not have where to attach it .. or attach it on launchpad? [00:16] leonel: sorry about that...attach in launchpad :) [00:16] ok [00:18] leonel: hi [00:18] leonel: what's the date on that log in exceptions? [00:19] syncdaemon-exceptions.log.2009-09-03_16-59-07 [00:19] date [00:19] Thu Sep 3 17:19:08 MDT 2009 [00:19] leonel: and this is with r198? [00:20] yes [00:20] leonel: could you quit or kill the applet and the syncdaemon, and run «/usr/lib/ubuntuone-client/ubuntuone-syncdaemon --debug» from a terminal? [00:24] leonel: ? [00:27] check the version # oauth-login.log [00:31] leonel: did you report a bug as i asked you to earlier? [01:00] dobey: got busy, now I'm taking this again to report the bug [01:02] dobey: --debug running [01:02] FS_FILE_OPEN and CLOSE on the 2 new files [01:03] leonel: grep "0.94.0" ~/.cache/ubuntuone/log/oauth-login.log [01:04] 2009-09-03 16:59:28,382:382.539987564 UbuntuOne.Client.Applet Starting Ubuntu One client version 0.94.0 [01:05] launched the applet and connected [01:05] the syncdaemon said : [01:06] http://paste.ubuntu.com/264709/ [01:06] leonel: grep "BadTransition" ~/.cache/ubuntuone/log/syncdaemon-exceptions.log [01:07] this on jauntygrep "BadTransition" ~/.cache/ubuntuone/log/syncdaemon-exceptions.* [01:07] /home/leonel/.cache/ubuntuone/log/syncdaemon-exceptions.log.2009-09-03_16-59-07:BadTransition: State READY_WITH_NETWORK can't handle the SYS_SERVER_RESCAN_DONE [01:08] both of those greps were on jaunty? [01:08] yes [01:08] ok [01:08] :D [01:08] He really do not like that collar [01:08] whoops [01:08] looks like the BadTransition was from an old version of the client [01:14] dobey: want the logs from karmic ? [01:14] this is what I have on jaunty [01:14] ii python-ubuntuone-client 0.94.0+r198-0ubuntu1~ppa1~jaunty Ubuntu One client Python libraries [01:14] ii python-ubuntuone-storageprotocol 0.93.0+r69-0ubuntu1~ppa1~jaunty Python library for Ubuntu One file storage a [01:14] ii ubuntuone-client 0.94.0+r198-0ubuntu1~ppa1~jaunty Ubuntu One client [01:14] ii ubuntuone-client-gnome 0.94.0+r198-0ubuntu1~ppa1~jaunty Ubuntu One client GNOME integration [01:14] ii ubuntuone-ppa-beta 2009.05.14-0ubuntu1 GPG keys and sources for the Ubuntu One pack [01:15] no [01:16] but an older version of syncdaemon was running when the BadTransition occurred, from what i can tell [01:17] that was with the current version [01:23] so should I still do the bug report ? [01:25] you can file a report but i'm like ~100% sure it's a duplicate of #420354 [01:25] as the logs say old code was still running at the time [01:28] based on the information i have seen anyway [01:28] leonel: you've not had any issues since that crash, right? [01:31] dobey: yes, that started yesterday [01:33] leonel: can you quit the applet on both machines, and then start it again on both, and if there are any more issues please file bugs :) [01:35] dobey: did that a few times today , also tried disconnect / connect to restart [01:35] and same result [01:35] files with 0 length on ubuntuone.com/files and on nautilus [01:41] now on ubuntuone/files selected the 3 files to delete and does not get deteted [01:41] got to go I'll check latter on and to the bug report. [01:42] Gracias / Thank You [01:43] ok [01:51] hiya, I'm having trouble using ubuntuone. When I look at the web interface I see files but when I look at nautilus there are no files there. [13:19] aquarius, Hi. Are you working on removing databases? [13:19] CardinalFang, no, I'm working on unpairing servers [13:19] although I have to go to the dentist so it peobably won't be finished today [13:19] Er, removing from replication is what I meant. [13:20] yes, that's what I'm working on :) [13:20] deleting the paired server record [13:20] that actually works fine, it's just all the GUI bits (take it out of this list, put it in this other list, hide the other list if its empty, blah blah blah) [13:21] aquarius, I was thinking, if you write a "this should go away now" record somewhere, then in the normal replicaton process, I can remove this-server's replication entry from the remote end, the next time we see each other. [13:22] CardinalFang, aha, already done, sorta. Paired-server ecords don't actually get deleted.they get application_annotations.Ubuntu One.private_application_annotations.deleted = true [13:22] so you can look for that [13:25] Hrm, but those will persist, even after I reconcile everything. I don't want to be unnecessarily chatty just because we were paired in the past. A positive record that I can delete when I reconcile it would be netter. [13:27] correct, but if they're actually deleted then they can't be undeleted [13:27] also, remember that the .deleted=true hack is just a hack until we have proper history, at which point they can be actually deleted [13:27] I don't mean actually deleted, of course. [13:28] you don't have to be chatty, though; don't start replication for servers listed in deleted records, no? [13:28] brb hopefully [13:28] aquarius, when do I remove the entry from the far end? [13:29] CardinalFang, ah, your point being that you can't tell the difference between "this record has been deleted and needs reconciling" and "this record has been deleted and I've already reconciled it" [13:29] a good and wise argument. [13:29] Exactly. [13:30] is it worth having a whole other record for that? rather than just "reconciled=false" in the record itself? [13:30] In the record that we are also marking as deleted? [13:31] yep. So when I delete a record, I mark it as deleted and unreconciled. When you reconcile it, remove the "unreconciled" but leave it deleted [13:31] That sounds fair. [13:32] Also, new topic: I was thinking of adding a "do-not-replicate" pane in the pairing tool, to mark databases we don't want copied. This is probably near your work. [13:33] Spatially, in code and GUI. [13:33] I can wait a while if you think you'll commit soon. [13:33] soon = "before Tuesday. [13:34] * CardinalFang afk 5 min. [13:37] I should have this done before tuesday. [13:37] I don't know about the do-not-replicate pane, though. I'm not sure I want it to be easy to say "don't replicate this database" [13:54] Hrm, okay. [13:55] The functionality exists in the replicator, for 'management' hard-coded and others in records. I'm okay with leaving no way to get things in and out of that list. [13:59] *nod* yep. We certainly need a way of doing it, which we have. I just don't think we need convenient UI for it [14:00] Roger. Now, is "gnomekeyring" module very Gnome-centric? That is, will the Foobuntu people balk at it? [14:04] I...think so. But we're supporting Ubuntu [14:04] there is no cross-desktop keyring [14:06] one was just released last week [14:06] dunno if it's any good, but we can probably start using it for karmic+1 [14:07] http://pypi.python.org/pypi/keyring [14:07] statik, Thanks [14:07] *nod* I saw that it exists, but haven't had a chance to look at it in any detail [14:13] aquarius: so, I added admin users galore to my system couchdb yesterday. Now all of the tests fail because of unauthorized [14:14] which was a bit of a surprise [14:14] Rawk! [14:14] erm [14:14] Oh, wait... [14:14] thisfred, the oauth user should be an admin [14:14] aquarius: there are no oauth tests? [14:14] aquarius: I mean the tests on my branch [14:14] which worked fine until then [14:15] so: 1. they aren't talking to the right db after all [14:15] 2. the admin users are being written to the ini and we inherit them. [14:15] 2. I just thought of [14:15] they're talking to your *system* couchdb? on 5984? that's wildly ungood. [14:15] aquarius: that would be one option, but I don't see how [14:15] does your system couchdb have all the test-created databses in them? [14:15] in it? [14:17] aquarius: my system couch isn't running. Since I don't think I have the right to shut it down if it is, I think we can assume 2. [14:17] which is bad, but less surprising: [14:18] the admin users aren't being written to the ini that couch is reading, though; we specifically start it up with an ini parameter [14:18] user accounts should not be part of an .ini file, especially when they are chainable for different databases. But maybe we are just using the chaining weirdly [14:18] pointing at XDG/desktop-couch/desktop-couch.ini [14:18] ah, man, it doesn't chain to the ones in /etc, does it? [14:18] aquarius: yeah I would think so. [14:18] aquarius: I'd hope not, but I'm not sure [14:18] it's the only explanation I can think of [14:19] I'm starting a master couch [14:20] aquarius: and verily, I cannot create a database there either [14:20] unchain my couch, Joe Cocker! [14:20] puzzled [14:22] aquarius, dobey: is this still a real bug? i know dobey is swamped, is this one we could dump on aquarius? https://bugs.edge.launchpad.net/ubuntuone-client/+bug/376087 [14:22] Launchpad bug 376087 in ubuntuone-client "UnknownLoginError during request for OAuth token" [Undecided,Triaged] [14:23] aquarius: the way we run couchdb, with the chaining command, a user in the system couch, becomes a user everywhere, at least for admins [14:23] thisfred, ok, that's bad. How do we make it not chain? I didn't realise it always chained to /etc ini files [14:23] we need to not do that [14:24] I did not either, and never considered in combination with the fact that non configuration stuff is dumped in the ini. That's not such great practice... [14:24] aquarius: will start asking on #couchdb, where they love me with great love ;) [14:25] statik, if it's still a real bug (it is a most confusing bug report!) then I'm happy to take it. dobey, is it still a real bug? [14:27] * CardinalFang gets breakfast [14:30] is what a what? [14:30] oh UnknownLoginError [14:30] yes [14:31] particularly when the cert verification or host lookup/connection fails [14:32] morning u1ers [14:33] dobey, what's the suggested solution? [14:33] aquarius: I am 100% sure my analysis of the behavior is correct: deleting the admin users from /etc/couchdb/local.ini (note the *local*) fixes everything [14:34] thisfred, so, we need to make DC startup pass --dont-chain-ini-files-unless-i-tell-you-to to the couchdb executable. Except I don't know if there is such an option [14:34] aquarius: I think we should take out chaining, while we let the couch devs think of how they want to solve this [14:34] aquarius: we explicitly chain, we don't have to [14:34] aquarius: we can just generate the whole ini file ourselves [14:34] there is no reason, none, why chaining is a good idea, although we might need to boost our ini file writer to include some of the stuff in default.ini [14:34] aquarius: not sure. for the cert validation, it would be nice if the certs we use for the storage protocol were used for that as well [14:35] aquarius: right. I'll file a bug then. And start on it, since this seems like it would be a good idea to solve [14:35] aquarius: and for failures, it would be nice to not bunch everything together as "UnknownLoginError" but propagate the errors up somehow [14:36] although i'd also like to not use pycurl, and instead use urllib2 or something, so we can reduce the number of http libraries we need/use [14:36] dobey, hang on, there's two sorts of fixes possible -- the first is to make the unknownloginerror not occur (by checking certs, etc), and the second is to handle login problems in some better user-visible way. Which were you planning on doing? both? [14:36] it uses pycurl because nothing else does cert checking, if I remember correctly [14:36] aquarius: i think we need to do both. i don't know how to do the cert checking though [14:37] well, pycurl does it automatically, but doesn't use our certs to check against [14:37] anyway, I have assigned the bug to me [14:37] hooray [14:37] haven't hacked on u1fs for a while... [14:37] i think you can do it with urllib2 now, but you have to write your own class thingy to do it [14:37] ah, ok. I might ask you about that when I get to this bug :) [14:37] which we'll need to do for supporting proxies as well [14:38] why is it so hard to say "get this URL"? grr [14:38] unless there's some way to make pycurl do proxies and cert validation easily [14:38] don't know. I'll look at that when I look at the bug -- certainly I'd like to remove the pycurl dependency if I can [14:39] yeah. i don't know enough about it currently to just go fix it, and i've been sacked with other critical/major issues, which i can fix :) [14:40] *nod* :) [14:42] dobey, are you still waiting on icons/emblems from someone? [14:44] statik: afaik, design team is supposed to be drawing some [14:45] dobey, thats what i thought. can you file a bug for me in ubuntuone-client with the brief list of exactly what the deliverables are, and I will add the icon for the desktopcouch pairing tool and go hunting for our images? === teknico is now known as teknico_away [14:46] since we have like one day left to integrate them before UI freeze [14:46] https://wiki.ubuntu.com/UbuntuOne/KarmicClient#Icons Needed [14:51] perfect, i'll take it from there [14:52] aquarius, can this bug be closed or punted to after karmic or something? https://bugs.edge.launchpad.net/ubunet/+bug/399687 [14:52] Error: This bug is private [14:52] stupid privacy [14:52] * statik makes the bug public [14:52] statik, it's going to have to be punted until after karmic [14:52] thats a deal sir [14:52] we're not going to get a dbus api in before karmic [14:52] so it slips. Sorry. [14:54] we got the python api [14:54] i'm more worried about getting replication working with the cloud than about the dbus api, so no fuss there [14:54] and C, and ideally JS. D-Bus was there so people could call it from any language they wanted [14:55] but writing bindings isn't that hard [14:55] uhm [14:55] welllll [14:55] technically speaking, we do have a dbus API :) [14:55] ? [14:56] yeah, getPort() and quit() :D [14:56] we've got some dbus, but i didn't think it exposed the contacts methods [14:56] evolution-data-server has an API that lots of things are already using [14:56] heh [14:56] so install evolution-couchdb, set it as your default store in evolution, and et voila! [14:56] well, right, and it's moving to dbus for 2.29 [14:57] oh, i thought e-d-s was already dbus [14:57] it's still orbit? [14:57] no, the patch was merged in trunk, but 2.28 was already branched [14:57] yeah, good old orbit :) === teknico_away is now known as teknico [15:02] oh gosh! [15:02] oh well [15:02] MEETING BEGINS [15:02] You know the drill! Do it! [15:02] me [15:03] me [15:03] me [15:03] me [15:03] me [15:03] me [15:03] me [15:04] i have a quick announcement before jblount starts us off, is that ok jblount? [15:04] statik: :) [15:04] ANNOUNCEMENT: As we are hurtling toward karmic release, we need to start saying 'not until after karmic' to more work. Please, refuse to work on anything that does not have a bug tagged with ubuntuone-karmic. If you are doing work that is not on a bug on that list, either stop doing the work or talk to me to get the tag added. Every day that goes by I will be more aggressively removing work from the ubuntuone-karmic list, because we *will* [15:04] be shipping on time even if it means ripping out features. https://bugs.edge.launchpad.net/ubuntuone/+bugs?field.tag=ubuntuone-karmic Next Karmic release deadline is User Interface freeze on September 10th, which means new icons/UI tweaks MUST be uploaded by september 9th. [15:05] at the daily standup I want to start reporting progress in terms of driving that bug list to zero [15:05] we'll see how it goes :) [15:05] * statik hands the baton back to jblount [15:05] DONE: Lost in a sea of mockups, trying to sort out tabs stuff [15:05] TODO: punt on some ui stuff so I can push the tabs in the next 60 minutes, reviews, reviews, reviews [15:05] BLOCKED: Indecision on artistic direction [15:05] * jblount tags teknico [15:06] DONE: implemented the details view for the new contacts web ui, made even more improvements to the creation of contacts for testing, did some reviews [15:06] TODO: talking with jblount about the new contacts web ui, implementing adding and editing contacts [15:06] BLOCK: none [15:06] next: statik [15:06] DONE: Worked on the GreatDomainMove. Planning for Karmic+1 UDS, lots of bug herding. [15:06] TODO: Work with Chipaca on packaging next couchdb snapshot. Work on domain move. [15:06] BLCK: not-blocked-just-yet but anxiously awaiting versions of desktopcouch, bindwood and couchdb-glib which use oauth by default. Need icons, will chase today. [15:06] rodrigo_, et tu [15:06] • DONE: Added OAuth support to evo-couchdb, and lots of testing [15:06] • TODO: Start upstream discussion for adding social services accounts config to about-me. Talk to Ara about writing mago tests for evo-couchdb. Propose couchdb-glib/evo-couchdb for GNOME 2.29. Store UUIDs for postal addresses. Conflict resolver tool in pair tool. Look at becoming a MOTU (https://wiki.ubuntu.com/UbuntuDevelopers). openSUSE/Fedora packaging with aquarius. More tomboy syncing fixes. More OAuth testing [15:06] • BLOCKED: none [15:06] next: urbanape [15:06] DONE: More wrangling with OAuth. Sigh. [15:06] TODO: Ibid, most likely. [15:06] BLOCK: I keep thinking I'm not blocked, but evidently, I'm having a hard time degbugging these issues. Wouldn't mind a pair. [15:06] dobey: Your turn [15:06] ⚜ DONE: Fixed server to use python-oauth, got python-oauth built on hardy [15:06] ⚜ TODO: Reviews, Fix client/protocol to use python-oauth [15:06] ⚜ BLCK: None. [15:06] aquarius: avast me hearty! [15:06] ⚀ DONE: nothing got finished yesterday. nothing. I suck. [15:06] ⚁ TODO: allow unpairing of servers (bug #419975), although that's not tagged for karmic so I shall stop, or do desktopcouch bugs not get the tag? [15:06] ⚂ BLOCKED: none [15:06] ⚂ BUG COUNT: https://bugs.edge.launchpad.net/~sil/+bugs?field.tag=ubuntuone-karmic - 3 [15:07] Launchpad bug 419975 in desktopcouch "for pairing, do not display hosts or servers that are already paired" [Medium,In progress] https://launchpad.net/bugs/419975 [15:07] aquarius, we need to add the tag for that [15:07] ah, OK, I'll carry on working on it then :) [15:08] I only have 3 bugs at the moment, which is nice, although I suspect there will be more [15:08] MEETING ENDS (I think) [15:08] crap! [15:08] statik: I've got some bugs I think should have the tag also (tomboy notes stuff, and oauth for couchdb-glib), giving you the #s in 1 minute for you to double check [15:08] tag added [15:08] * jblount re opens the meeting and hugs CardinalFang [15:09] oh, and I'm going to the dentist in 20 minutes, because my life is just that great [15:09] thanks everyone! rodrigo_, can you mark the bugs for your tomboy sync work and couchdb-glib work as 'also affects project' and tag them with ubuntuone-karmic? [15:09] statik: ok [15:10] also affects project 'ubunet' is fine I think [15:11] urbanape, i'm already booked for today or i would pair with you on the js stuff. maybe teknico could peek at some of it with you? [15:11] statik, also affects project? [15:11] i thought ubunet was going awya [15:12] appreciate it, statik [15:12] DONE: D-c replication to U1, committed, needs review. (Code assumes name change, couchdb exists there, db-name-account-mapping is implemented). [15:12] i wish someone would split up all the server components into separate projects [15:12] ode to the day! [15:12] urbanape, statik, sure [15:12] TODO: Clean up replication and pairing code. [15:12] aquarius: well, it'll be renamed maybe one day after karmic. but it still holds our server code. if a bug needs an upload to karmic, then the bug task needs to be in ubuntu (sourcepackage). If we make a bug task also show up in one of the ubuntuone projects, then we can easily see it in that big list [15:12] BLOCKED: None. [15:12] but i am NOT doing it [15:13] dobey, no worries, i think you've done enough renames to get out of them forever :) [15:13] teknico, if you'd like, you can pull my code from lp:~urbanape/bindwood/using-oauth [15:13] statik, ah, ok, rodrigo needs to do that because the bugs are not on a project which is already part of ubuntu one. got it [15:13] urbanape, ok [15:13] I'd be happy to chat through my current issues with you. [15:13] here, privmsg, or skype [15:14] TODO also: Implement second half of un-pairing code in replication daemon. (There's a good rationale for this.) [15:14] Is there an easy way to tell if a bzr branch is a shared repo? lp:ubunet branches are taking ages to pull down. [15:15] aquarius, we have to do the same with desktopcouch; if we need an upload then we need to do 'also affects distribution', select ubuntu and the sourcepackage 'desktopcouch', then nominate the bug for karmic. then the platform team decides whether the nomination is accepted. if the bug is medium importance and accepted for ubuntu, it means that it 'may' be uploaded. if it is critical or high importance and accepted for ubuntu and targeted to [15:15] a milestone, it means that the bug will prevent the release from happening until it is fixed [15:16] jblount, i'm really happy to hear tabs are showing up soon [15:16] jblount, have you spoken on the phone with john lea yet? [15:17] statik: Nope, should I? [15:17] aquarius, speaking of this, do you mind not marking the un-paired records as deleted? The d-c view code these days should omit records marked as deleted. [15:17] CardinalFang, huh? [15:17] jblount: yes, give him a call this morning if you can. he works in london on the design team and is assigned 100% to our team. he will be happy to discuss artistic directiony stuff with you [15:17] CardinalFang, what shoudl I do instead? [15:17] urbanape, done, wanna try skype? [15:18] aquarius, Add some attribute that says it's dead or something. I'll delete it when it's truly unused for anything. [15:18] my skype id is teknico.net [15:19] CardinalFang, have to go to the dentist now. drop me a mail with what you want me to do? [15:19] aquarius, Roger. [15:19] * jblount scowls at the dentist. All of them. [15:19] scowling is overrated [15:20] * CardinalFang tries not to make a dentistry & England joke. [15:21] heh [15:21] It is a pretty brutal profession, though. Boy! I can't wait until we discover Medicine. [15:22] It's probably another 10 years off, though. [15:22] teknico, sure. I'm 'urbanape' [15:23] CardinalFang: like working technology [15:30] dobey, No, we're always doomed for that. We stop calling things "technology" when they are mature. [15:30] There will always be a bleeding edge somewhere. When it was the wheel, we complained about that. [15:32] computers are a hundred years old and still don't work! [15:36] Your computers in your calculator, microwave, thermostat, car -- all work. Computers on Pioneer 10 are probably still working. The bleeding edge sucks, as always. [15:45] CardinalFang: This is a very interesting way to look at things. I'm glad you mentione dit. [15:45] or it. [15:45] jan____: when you have a second, me and jdo have a question or two about authentication plugins :) [15:46] * jdo immediately thinks 'dit' is something cool he is missing out on === thisfred is now known as ditfred [15:47] jdo: dit == this in dutch [15:48] :) [15:48] what's fred in dutch? [15:48] dobey: Eric [15:48] majesteit ;) [15:48] lies [15:48] indeed [15:48] hehe [15:48] caught === ditfred is now known as thisfred [15:49] * jdo wishes he would have gone to the nice coffe house on the beach this morning [15:49] actually it would be dezefred, as dit is neuter [15:49] jdo: no hurricane this week? [15:49] * thisfred just received "Welcome to the United States: A Guide for New Immigrants" [15:50] yay! [15:50] :) [15:50] thisfred: does it say "You really have to try the fish." ? [15:50] Ha! [15:50] don't drink the water ;) [15:51] nothing on where to pick up my gun [15:52] maybe that's only when you become a citizen [15:52] Huh! You should have received one with the pamphlet. [15:52] you'd think [15:53] mail fraud is such a huge problem in this country [15:53] Reminds me of a bar in college. We joked that they searched you for knives when you entered, and if you didn't have one, they issued you one. [16:28] * aquarius returns [16:28] my teeth hurt. [16:28] alright, I have two desktopcouch merge proposals. [16:28] stupid dentist [16:29] anyone know if couch recently got picky about the body of json request? [16:29] we're sending this: [16:29] Bindwood: Query body: {"language":"javascript","map":"(function (doc) {if (doc.application_annotations && doc.application_annotations.Firefox && doc.application_annotations.Firefox.uuid) {emit(doc.application_annotations.Firefox.uuid, doc);}})"} [16:30] do those ampersands need to be escaped? [16:30] no. ampersands don't need escaping inside a string [16:30] that's what's kicking back invalid_json [16:30] I didn't think so [16:32] that json isn't invalid. Odd. [16:33] and helpful errors: [16:33] Bindwood: Error querying couch: message: 'undefined', reason: '', description: 'undefined', error: 'invalid_json' [16:34] weird. Can you replicate the problem with, say, curl on the command line? [16:34] (although it's oauthed, of course) [16:35] (also, you can create design docs on teh filesystem rather than doing it from code, but don't worry about that for now) [16:36] CardinalFang, do you think the unpairing bug (bug #424386) that you filed is a karmic blocker? [16:36] Launchpad bug 424386 in desktopcouch "unpairing couchdb replication" [Medium,Confirmed] https://launchpad.net/bugs/424386 [16:37] aquarius, hrm. It's embarassing, but not severe. [16:38] I don't understand what the second part of "For finding pairings, the pairing tool must ignore records that have {'unpaired'=True} set, and for new pairings, must remove any records that have {'unpaired'=True} ." means [16:39] aquarius, you show things that can be unpaired, yes? If you find one of those records, do no show its entry as unpairable again. [16:40] CardinalFang, ah...that's problematic. [16:40] CardinalFang, because what if you change your mind [16:41] Then you may pair it again, I suppose. [16:41] there are three states: I am paired (record exists), I am not paired (record does not exist), I want to be not paired but it hasn't happened yet (record exists with unpaired:True) [16:42] ah, so I can show it as pairable again, that's fair. So when you choose a server to pair with, I need to check whether it has an unpaired:true record already [16:42] I need to draw myself a flowchart or something for this :) [16:43] Good point. Yes. Create or update existing to remove "unpaired" attribute. [16:43] gotcha. I'm going to restructure the code I've got. [16:44] (because there's also "is this a cloud server", since cloud servers don't get unpaired:true, they just get the record deleted straight away) [16:51] Right. [16:52] aquarius, is there a bug to describe the u1 couchdb replication stuff? [16:52] which replication stuff? [16:52] Like, local db names are mapped __ thusly. [16:52] I have it written, just trying to link work to bugs. [16:53] I don't want statik yelling at me. [16:53] ah. No, I don't think so [17:00] utter frustration [17:00] computing the correct headers and passing in the same request from curl gets me the info. [17:00] argle and/or bargle [17:01] urbanape, can you capture what's going out via wireshark, and compare/retry via curl? [17:09] I'll give that a try. I tried to recreate from as much of what I'm logging as possible, but it's likely there's something else twiddling it along the way. [17:15] hmm, doesn't find my interfaces. Probably a VMware issue. [17:19] ah, just needed to sudo it === thunderstruck is now known as gnomefreak [17:23] thisfred, Oh, with your "Welcome to the US" pamphlet, you did get a coupon for a jar of peanut-butter, right? [17:27] weird. capturing on any interface, I don't see my Bindwood traffic. Nor do I see the CLI curl request. [17:30] urbanape, through Wifi, perhaps? [17:31] well, wireshark is set to capture on any network interface [17:31] I'll bet it's a VMware thing. [17:33] Ah, yeah. That is it. What's your host OS? It should see it. [17:34] CardinalFang: no coupons. :( [17:35] CardinalFang, Mac OS X [17:36] even if all the traffic is local to the guest? localhost requests. [17:36] What the hell?! How are we supposed to acclimate new people without introducing them to peanut butter? This is a dire social issue. [17:37] Actually, I don't know that .nl doesn't have peanut butter. Does it. thisfred? [17:42] CardinalFang: yes. Thicker and less sweet, on the whole. [17:43] it's called pindakaas, (peanut cheese) [17:43]