[05:38] <tritium> duanedesign: thanks for the info!
[06:08] <duanedesign> tritium: absoloutely
[09:11] <rtgz> duanedesign, re bug #516935 - apt-get update will not update the jaunty package to karmic
[09:15] <rtgz> duanedesign, http://irclogs.ubuntu.com/2009/11/06/%23ubuntuone.html#t20:14
[09:18] <windmill> I filed an ubuntuone bug in launch pad and it has disappeared, it no longer shows on my account. Is it possible someone deleted it??
[09:21] <rtgz> windmill, do you have the bug number (i.e. from confirmation e-mail etc.)? I can't find the possibility to delete a bug report...
[09:33] <rodrigo_> hey rtgz, thanks again for your help last night :-)
[09:34] <rtgz> rodrigo_, hey, that was interesting, i like such things :)
[09:34] <rodrigo_> cool
[09:34]  * rodrigo_ now knows who to "use" for testing old versions :)
[09:35] <rtgz> rodrigo_, yup, jaunty vm is ready for crash tests.
[09:36] <rtgz> Ok, so these ppa versions will not appear during upgrade prompts, since they are physically no longer available from the server
[09:38] <rodrigo_> no, removed them last night
[09:38] <rodrigo_> so users who haven't upgraded yet won't see them at all
[09:38] <rodrigo_> hmm, any answer on the bug/mailing list?
[09:38]  * rodrigo_ looks
[09:43] <rtgz> rodrigo_, no, aptitude/apt does not list ubuntuone libs as the candidates for upgrade anymore
[09:43] <rodrigo_> great
[09:44] <duanedesign> rtgz:  morning
[09:45] <rtgz> duanedesign, day
[09:46] <duanedesign> rtgz: So in jaunty '1.1.1+r321-0ubuntu1~ppa1~jaunty' is in the main repos. I assumed, which is terrible to do, that if they had that version they had the Beta PPA in their sources
[09:47] <rtgz> duanedesign, nope, there was a story with versioning
[09:49] <rtgz> duanedesign, right before karmic was released, a version bump was performed from 1.0 to 1.1 for ppa; Those who installed jaunty ppa packages, got 1.1 version. After update to Karmic, the upgrade system ignored ubuntuone packages, since base system contained 1.0-something and the ppa version was 1.1
[09:49] <rtgz> in order to fix this all the packages need to be purged and ubuntuone client needs to be reinstalled
[09:49] <duanedesign> i see, and the upgrade from jauntry to karmic removes the ppa's
[09:49] <rtgz> duanedesign, nope
[09:50] <rtgz> duanedesign, i mean... the packages are left intact, the ppa entries might be removed, yes
[09:50] <duanedesign> ok
[09:50] <duanedesign> :)
[09:50] <duanedesign> thank you for that.
[09:51] <rtgz> duanedesign, so to reproduce this... Install jaunty, install ubuntuone beta ppa. Upgrade jaunty to karmic, observe that jaunty ppa is still installed and it does not want to go anywhere until it is purged manually
[10:28] <windmill> rtgz, thanks for the offer of help, it turns out someone had marked my bug as a duplicate. I didn't realise that removed it from my bug list in launchpad.
[10:28] <rtgz> windmill, yes, it removes from the default view, you can use 'advanced' bug search so that duplicates are not skipped
[11:03] <rtgz> re: bug 491278 - it looks like ubuntuone client does not care about the nickname, i had mine changed 4 times and it works still :)
[15:00] <jblount> Desktop+ MEETING BEGINS
[15:01] <jblount> me
[15:01] <rodrigo_> me
[15:01] <teknico> oh, already?
[15:01] <teknico> right, london time
[15:01] <teknico> me
[15:05] <jblount> DONE: Got all sprite crazy, started working on translation build system template thing for start pages
[15:06] <jblount> TODO: Finish build system stuff, determine next action on possibly sick hard drive, worry about broken hardware
[15:06] <jblount> BLOCKED: Nope
[15:06] <jblount> rodrigo_: You're next :)
[15:06] <rodrigo_> • DONE: Recently used contacts in contacts picker, Made oauthdesktop code more generic. Looked at nautilus crashes in jaunty with newer glib. On-call review
[15:06] <rodrigo_> • TODO: Conflict resolver tool in pair tool. 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? Add jslint tests to check. Remove autosave code in notes web editor. U1 client interrogates library page to update download progress. geoip detection on server to forward to appropriate store
[15:06] <rodrigo_> • BLOCKED: no
[15:06] <rodrigo_> teknico, go
[15:10] <teknico> ops
[15:10] <teknico> DONE: funambol project review; trip to Millbank
[15:10] <teknico> TODO: pseudosprint in Millbank; review the branch to fix the phone setup web interface code
[15:10] <teknico> BLOCK: none
[15:10] <teknico> next: noone
[15:10] <teknico> sorry
[15:59] <rtgz> hi all, i am interested in bug #501020
[15:59] <rtgz> and the last comment to be precise
[16:02] <rtgz> The person claims to be having 404 response during sync and it is true, the server says that /notes/api/1.0/user/ does not exist while responding with such url previously
[17:33] <statik> rtgz, i wonder if the 404 is auth-related. we sometimes serve 404 reponses when auth fails and we don't want to say whether or not the resource exists
[17:33] <rtgz> statik, no, it does not look like that
[17:34] <rtgz> that person has one URL served to him via first request, I have a different one. His returns 404 both for him and for me and my one replies with a proper HTTP response with 'Subscription required' text
[17:36] <statik> huh
[17:38] <rtgz> statik, huh?
[17:41] <statik> I am surprised and out of useful suggestions :)
[17:41] <rtgz> joshuahoover, reproduced that ABE popup - bug 440408.
[17:43] <rtgz> statik, is there any code in ubuntuone that could give the following -  {"oauth_access_token_url": "https://one.ubuntu.com/oauth/access/", "user-ref": {"href": "https://one.ubuntu.com/notes/", "api-ref": "https://one.ubuntu.com/notes/api/1.0/>>>>user<<<</"}, "oauth_authorize_url": "https://one.ubuntu.com/oauth/authorize/", "oauth_request_token_url": "https://one.ubuntu.com/oauth/request/", "api-version": "1.0"}
[17:48] <rtgz> joshuahoover, noscript policy for Application Boundaries Enforcer prevents internet sites from accessing LAN resources
[17:50] <rtgz> joshuahoover, here's what is printed in the popup: http://paste.ubuntu.com/368997/
[17:59] <nettrot> I seem to have a table in my desktop-couchdb that isn't syncing to U1
[18:00] <nettrot> I've been doing some tests with the U1 integration for GTG, and the gtg_tasks database is never syncing from my desktop to my netbook.
[18:03] <nettrot> Any ideas as to what would cause a sync issue? I haven't excluded any databases.
[18:05] <nettrot> Odd, the Replicate log on my netbook doesn't seem to have any records newer than mid-January
[18:06] <rtgz> joshuahoover, http://www.youtube.com/watch?v=ciOVBbI6IkQ
[18:07] <rtgz> nettrot, do you have avahi running?
[18:07] <nettrot> rtgz: Yes.
[18:07] <rtgz> nettrot, additionally, could you please try shutting down desktopcouch instance and then start it from the terminal. In case replication does not start then this should be reflected in some way via an error message of some sort
[18:08] <nettrot> What's the best way to shut down desktop-couch? Just kill the pid in the pidfile in cache?
[18:08] <rtgz> /usr/lib/desktopcouch/desktopcouch-stop
[18:09] <rtgz> and then /usr/lib/desktopcouch/desktopcouch-service
[18:09] <nettrot> Started. No log messages about replication failure yet.
[18:10] <rtgz> started and you see the URL of the page for futon access, right?
[18:11] <rtgz> is there anything useful in replication log (it will take 10 minutes for it to start replicating)?
[18:11] <rtgz> nettrot, I mean whether there are any messages about success or failure of replication, etc...
[18:12] <nettrot> There is a replication entry for today, and it doesn't appear to have failed.
[18:12] <nettrot> And...I've got records in the gtg_task database according to futon.
[18:13] <nettrot> Not sure they're the same ones from the desktop, which suggests that I'm having replication problems there, but I can't check that until later.
[18:14] <nettrot> Doesn't look quite right.
[18:15] <nettrot> I'm going to stop the desktop-couch service that's in the terminal and have it restart in the background.
[18:18] <rtgz> i wonder whether that's desktop<->cloud or cloud<->netbook replication failing
[18:20] <nettrot> Not sure. I'll check the desktop this evening, but that's at least 7 hours away.
[18:21] <rtgz> nettrot, so there were no entries in the replication log on the netbook say, from Feb 3 (yesterday, at least for me :) ). And it was operating yesterday so it should have replicated something or at least try to, right?
[18:24] <nettrot> rtgz, actually, there were no entry logs since January 10.
[18:24] <nettrot> Until I shut it down and restarted it following your instructions.
[18:24] <nettrot> And I've been using this machine 5 days a week.
[18:25] <nettrot> Desktopcouch *has* been starting, since I would access it via futon from time to time.
[18:25] <rtgz> nettrot, hm...
[18:27] <nettrot> The netbook is on the latest Ubuntu Alpha, the desktop, still on 9.10, though I'm not sure that would matter.
[18:44] <rtgz> nettrot, it should not, but there's something I want to ask desktopcouch team...
[18:50] <statik> pfibiger, rmcbride, rtgz, joshuahoover: dobey just let me know that we need some testing of the ubuntuone-client and ubuntuone-storage-protocol packages that have been sitting in karmic-proposed for about 6 weeks, I guess the formal testing/confirmation of those packages is necessary before they can be promoted to karmic-updates
[18:51] <statik> more info about the process is here: https://wiki.ubuntu.com/StableReleaseUpdates
[18:51] <joshuahoover> statik: looking at that now...
[18:51] <rmcbride> looking
[18:56] <statik> Chipaca ^ FYI. this amazing team should be able to make short work of getting those SRUs verified
[19:01] <rtgz> statik, does the fact that I've been using karmic-proposed versions of all ubuntuone components for 2 weeks or so count?
[19:01] <rmcbride> rtgz: I'd definitely say that it did.
[19:02] <rtgz> rmcbride, but... as it is 6 weeks old it lacks my beloved emblems fix :'-(
[19:02] <statik> rtgz, i figured you might have been doing something like that :) yes, it should count. I think the main thing that is needed here is some organized testing and reporting/documenting of results so that the archive admins know whether or not those packages are safe
[19:03] <joshuahoover> rtgz, rmcbride: i think we need to make sure that each of the bugs in the sru have the right info in the bug description...specifically looking at the procedure section, #2
[19:03] <statik> rtgz: also, i am not officially asking you to do work but just letting you know whats going on as I figure you care a lot about this stuff
[19:03]  * rtgz wants emblems :)
[19:03] <rmcbride> joshuahoover: yea that is important.
[19:05] <pfibiger> joshuahoover, well, step 4 is 'upload to release proposed' and we're already there :)
[19:06] <pfibiger> i think we just need updates on the bug report saying 'yes, these fixed the problems, no regressions encountered'
[19:06] <joshuahoover> pfibiger: heh...yeah, but i think if we don't have steps to reproduce then it's going to be hard to prove that we tested these fixes sufficiently
[19:08] <joshuahoover> rtgz, rmcbride: i'm more than happy to provide steps to reproduce on these but it would likely be faster if we split them up between us (if you guys are available to do that today or tomorrow)
[19:08] <pfibiger> joshuahoover: fair enough
[19:09] <rmcbride> joshuahoover: I'm in process of looking at them now to get an idea of the required work
[19:10] <rmcbride> I have a karmic vm that I'm going to get the proposed packages on.
[19:15] <rtgz> joshuahoover, i have a real karmic machine with proposed packages, so ready to reproduce bugs and capture them on video :)
[19:16] <joshuahoover> i have to setup a new vm for this...won't take long
[19:20]  * rtgz 's Acer Aspire One's Wifi dies during update to lucid. Sad. Need wired connection :(
[19:43] <joshuahoover> rmcbride, rtgz: what is the best way to see sru's in proposal on lp?
[19:43] <joshuahoover> rmcbride, rtgz: i did a search on our projects based on tags but i'm not sure that's the best way
[19:43] <dobey> joshuahoover: you want to see the bugs you mean?
[19:44] <joshuahoover> dobey: yep
[19:44] <dobey> joshuahoover: https://edge.launchpad.net/ubuntu/+source/ubuntuone-client/1.0.3-0ubuntu1
[19:45] <dobey> joshuahoover: there's a similar page for the ubuntuone-storage-protocol source package also
[19:45] <joshuahoover> dobey: ahhh...cool, thanks!
[19:45] <joshuahoover> dobey: you recovered from that bad day of travel?
[19:46] <dobey> i think so
[20:04] <rtgz> what should happen when the read limit for ubuntuone is set to 0
[20:04] <rtgz> ?
[20:04] <joshuahoover> rtgz: ah yes, one of my favorites!
[20:04] <rtgz> exceptions.ZeroDivisionError: float division happens
[20:05] <joshuahoover> rtgz: yes, i have a bug for us not to allow 0 to be set
[20:05] <rtgz> joshuahoover, it is no longer protocol error, though :)
[20:05] <rtgz> but it does not work nevertheless
[20:05] <joshuahoover> rtgz: right :)
[20:05] <rtgz> with 0 :)
[20:06] <joshuahoover> rtgz: right, this is one of those where we fixed the initial problem but i think presented another one
[20:14] <dobey> the problem is that the limit needs to be fixed to only affect the actual file upload/download operatins, and not regular operations of say "authenticate" :)
[20:16] <rtgz> you know...
[20:16] <rtgz> it does not create protocol errors, right
[20:17] <rtgz> but the default values in the applet are set to 0 by default
[20:18] <rtgz> so if a person like me turns on bandwidth throttling and leave the default values then it will raise ZeroDivisionError. I.e. it will not work
[20:18] <joshuahoover> dobey: right
[20:19] <joshuahoover> rtgz: do you get that error in the exceptions log? i don't get the error...the client just won't connect when set to the default (0)
[20:20] <joshuahoover> rtgz: so we can't accept this as a fix because the original problem wasn't so much the error as it was turning on bandwidth throttling and the client not connecting (regardless of the exact error)
[20:20] <rtgz> joshuahoover, syncdaemon.log gets ZeroDivisionError: float division and Failure: twisted.internet.error.ConnectionLost: Connection to the other side was lost in a non-clean fashion: Connection lost.
[20:22] <joshuahoover> rtgz: k, thought we were seeing that in the exceptions log before
[20:24]  * rtgz is pasting it to pastebin
[20:25] <rtgz> joshuahoover, http://paste.ubuntu.com/369087/
[20:25] <rtgz> line 1513
[20:25] <joshuahoover> rtgz: ok, i see it in my logs as well now
[20:26] <joshuahoover> rtgz: so we can't pass this one
[20:26] <rtgz> joshuahoover, technially it is different bug, since it was accompanied by protocol error message. But syncdaemon still does not work with default values
[20:27] <rtgz> i mean still does not work with bandwidth turned on and read/write limits are left as is
[20:27] <joshuahoover> rtgz: right, i think the specific error isn't as important as the end result...the end result of this fix or the earlier code is that the software doesn't connect/work
[20:27] <dobey> rtgz: the default values in the preferences are not 0
[20:27] <rmcbride> doesn't connect/work with throttling turned on and the settings left at default
[20:28] <rtgz> (i thought that 0 means unlimited, at least it does not make sense to set speed to 0, so usually it is assumed to be unlimited)
[20:28] <joshuahoover> rmcbride: right
[20:28] <dobey> rtgz: if it's becoming 0, something is seriously messed up somewhere :)
[20:28] <dobey> rtgz: 0 in fact, does make sense
[20:28] <rmcbride> dobey: it's definitely 0
[20:29] <rmcbride> and I can turn the throttling checkbox on while sync is occurring and watch twisted freak out.
[20:29] <dobey> rtgz: if i want to only upload files, and not download stuff, i can set download to 0... (aside from the fact that it's broken atm)
[20:29] <rtgz> /home/rtg/.config/ubuntuone/syncdaemon.conf [__main__] log_level = TRACE
[20:29] <rtgz> lol
[20:30] <rtgz> it is 2048 before turning on the checkmark but it resets to 0 once it is enabled
[20:31] <joshuahoover> can we all agree that this bug is not really fixed?
[20:32] <rmcbride> joshuahoover: yea, it definitely shouldn't do that when enabling throttling
[20:33] <dobey> which bug? so far i've seen 2 described :)
[20:33] <rtgz> dobey, the read/write fields are 2048 by default but they are not active. Once 'Enable bandwidth throttling' is clicked, the fields become active and their content is reset to 0, so yes, 0 is the default when no previous values are stored
[20:33] <joshuahoover> dobey: we're specifically talking about bug #455544
[20:34] <dobey> sigh
[20:37] <dobey> so basically, the fix for the other bug exposed another one, which was being hidden by the fact that the "settings aren't saved"
[20:41] <joshuahoover> dobey: right
[20:42] <dobey> but this explains why people were getting conf files with throttling enabled and the values set to 0
[20:45] <joshuahoover> dobey: on a fresh karmic install with all updates and then the proposed ubuntuone-client and storage-protocol updates installed, the default is always 0 for me...both in the GUI and the syncdaemon.conf file
[20:46] <rmcbride> That is what I just got on the karmic VM I was using as well
[20:46] <dobey> joshuahoover: the default was always 0 then
[20:46] <dobey> joshuahoover: my point is that is not a new problem
[20:46] <dobey> joshuahoover: it's just more visible now because other bugs are fixed
[20:46] <joshuahoover> dobey: got ya
[21:00] <joshuahoover> dobey: is the best thing to do to file a new bug then or something else?
[21:01] <dobey> yes i think so
[21:01] <dobey> or
[21:01] <dobey> best thing for me to do right now is go get lunch
[21:01] <dobey> :)
[21:02] <joshuahoover> dobey: definitely get lunch...i can log the test results in the original bug and file a new one for the problem that gets discovered as a result
[21:05] <joshuahoover> rtgz: you mentioned that the values are set to 2048 originally...is this in the code prior to the proposed updates?
[21:05] <rtgz> joshuahoover, video is on its way :)
[21:06] <joshuahoover> rtgz: ah, very good...i installed recordmydesktop, so i should do the same...or at least test it out ;)
[21:12] <rtgz> joshuahoover, once I started recordmydesktop it stopped being 2048 :-(
[21:13] <joshuahoover> rtgz: was it showing 2048 on proposed updates?
[21:13] <rtgz> joshuahoover, yes, for 2 or three times so that I felt that I can reproduce that
[21:14] <rtgz> it was showing 2048 prior to enabling the checkbox
[21:14] <joshuahoover> rtgz: because i did a fresh install of karmic with all updates and then installed proposed updates for u1 client and protocol storage and the default was 0
[21:16] <rtgz> joshuahoover, wow, that is really strange
[21:16] <rtgz> uploading...
[21:19] <rtgz> joshuahoover, http://www.youtube.com/watch?v=DR8Z_HTFyik
[21:20] <rtgz> joshuahoover, the default is 2048 but it looks like it reads the info from syncdaemon or some other location...
[21:23] <rtgz> i know why I could not reproduce that, with video enabled i was not quick enough to invoke ubuntuone-client-preferences. Still, it gets reset to 0 no matter whether I enable bandwidth throttling or not
[21:25] <rtgz> but bug 465030 is definitely fixed :)
[21:27] <joshuahoover> rtgz: does recordmydesktop work with compiz?
[21:27] <rtgz> joshuahoover, yes, but it needs some tweaks
[21:28] <rtgz> joshuahoover, Advanced/Performance/Full shots at every frame
[21:28] <joshuahoover> rtgz: i run compiz and tried starting up recordmydesktop and my machine became all but unresponsive
[21:28] <rtgz> joshuahoover, o_O
[21:29] <rtgz> joshuahoover, so just starting gtk-recordMyDesktop breaks X/Compiz?..
[21:29] <joshuahoover> rtgz: not sure, i'll have to try again...i was running two vms at the time so maybe it was just a bit too much ;)
[21:30] <rtgz> joshuahoover, it should not be that resource intensive...
[21:30] <rtgz> joshuahoover, btw, yes, when syncdaemon starts the preference window resets 2048 which looks like hardcoded somewhere to 0
[21:31] <joshuahoover> rtgz: strange
[21:38] <joshuahoover> rtgz, rmcbride: i'll test bug #357395
[21:38] <rmcbride> joshuahoover: cool :)
[21:38] <rtgz> joshuahoover, bug 459175 - fixed
[21:39] <rtgz> bug 457564 - fixed
[21:39] <joshuahoover> rtgz: do you want to leave comments on bug #455544 in regards to results you've found?
[21:39] <rtgz> joshuahoover, i do :)
[21:40] <joshuahoover> rtgz: cool, thanks!
[21:40] <rtgz> joshuahoover, rmcbride /me is testing 462003
[21:41] <rmcbride> joshuahoover: rtgz: #488413 is fixed
[21:41] <rtgz> joshuahoover, rmcbride /me is testing bug 462003 (bad ubottu, you should do what I mean, not what I actually write)
[21:42] <rmcbride> joshuahoover: rtgz: I'm hitting #455527, #495175, #491573 and #451670
[21:43] <joshuahoover> rtgz, rmcbride: we need to put reproduce steps in the description along with results and expected results...then i think leave a comment about our testing results for each of these bugs...that way others can verify as well...many of our bugs don't have this unfortunately
[21:43] <rmcbride> joshuahoover: right.
[21:50] <rtgz> oops...
[21:55] <dobey> hmm
[21:56] <rtgz> DATA LOSS ALARM!
[21:57] <rtgz> joshuahoover, rmcbride  bug 462003
[21:57] <rtgz> ALARM!
[21:58] <joshuahoover> rtgz: results?
[22:00] <rtgz> joshuahoover, commented to the bug report
[22:00] <joshuahoover> rtgz: checking...
[22:00] <rtgz> joshuahoover, the conflict folder is NOT created, the local file is removed along with the directory that was holding it
[22:01] <rtgz> joshuahoover, reproduced twice, the first attempt is linked as pastebin log.
[22:01] <rmcbride> rtgz: good test. that's definitely not the right resolution to that conflict
[22:03] <joshuahoover> rtgz, rmcbride right, not good, we should put those steps, and expected results in the description
[22:08] <rtgz> joshuahoover, the file that was killed in action is "Ubuntu One/testing/promo/elfy.asc",  "promo" dir was removed from the server
[22:12] <rtgz> ah
[22:12] <rtgz> it is still protocol version error with bug 455544
[22:15] <joshuahoover> rtgz: with the proposed update installed?
[22:15] <rtgz> joshuahoover, yes, http://paste.ubuntu.com/369087/ line 1520
[22:16] <joshuahoover> rtgz: ah, good catch!
[22:16] <dobey> i dont get it
[22:16] <joshuahoover> rtgz: seems strange that is not in syncdaemon-exceptions like we do with the current version
[22:17] <dobey> how is deleting a file locally if it is deleted on the server, a data loss bug?
[22:18] <joshuahoover> dobey: are you talking about #462003 or something else?
[22:18] <dobey> i guess so, i'm talking about the supposed data loss that rtgz mentioned
[22:20] <joshuahoover> dobey: it deletes a local file, doesn't mark it as .u1conflict
[22:21] <dobey> if it's deleted on the server, yes?
[22:21] <rtgz> dobey, the file is added locally and it is not present on the server. But if the tree is removed on the server (that file is not even there yet), then the file is removed locally along with the directory
[22:21] <joshuahoover> dobey: w/ the proposed fix...at least that was my understanding
[22:21] <joshuahoover> dobey: no, if the folder is deleted
[22:21] <dobey> why would it mark it as a conflict if the local file hasn't changed?
[22:21] <dobey> joshuahoover: yes, that's what i would expect it to do
[22:21] <dobey> deleting a folder deletes all its contents
[22:21] <joshuahoover> dobey: but that local file isn't on the server yet
[22:22] <joshuahoover> dobey: so there is a conflict between the server and the client
[22:22] <rmcbride> the local flie has been changed. It's been added  since the last update
[22:22] <dobey> oh, ok
[22:23] <joshuahoover> rtgz, rmcbride: bug #357395 has steps to reproduce, results, expected results and a comment noting it passed my tests
[22:25] <rtgz> P.S. i have some thoughts on NetworkManager support, if somebody is interested, https://bugs.launchpad.net/ubuntuone-client/+bug/505402/comments/3
[22:25] <rtgz> but that is offtopic at the moment
[22:26] <rtgz> I believe i will need to go, since it is night here (again, I hate 24 hours clock :).
[22:27] <dobey> find a slower spinning planet, or a larger one :)
[22:27] <joshuahoover> rtgz: heh, have a good evening!
[22:28] <rtgz> dobey, i'd love to, but i believe it is not yet covered by any Earth ISPs
[23:00] <CardinalFang> aquarius, https://code.edge.launchpad.net/~cmiller/desktopcouch/couchdb-polutes-its-ini/+merge/18645