Present Perfect

I usually tend to think of Python as the discerning gentleman's programming language: well-behaved, well-documented, people take care of the code written. I like the batteries-included approach and assume that the battery code in the standard library is well-written. "import this" is a vision statement directly included in the language - it's hard to get more stylish than that.

I got an eye-opener this weekend however. I was still on my quest to get desktopcouch and ubuntuone working on Fedora. While wresting with this bug and doing things that I usually consider a hanging offense (changing /usr-installed code by adding prints to figure out where the craziness was coming from) I finally drilled down to the exception-raising reason. It all boiled down to a single line of code in httplib.py:

def __init__(self, host, port=None, key_file=None, cert_file=None,
strict=None, timeout=socket._GLOBAL_DEFAULT_TIMEOUT):

where socket.py contains

_GLOBAL_DEFAULT_TIMEOUT = object()


So, in a nutshell, httplib2.py tracebacks because of this new object, which isn't a valid argument to sock.settimeout()

Now, I'm pretty sure I'm running into this problem because I'm doing "bad" things to some of the stdlib, pulling in bits I need to make ubuntuone (coded on a 2.6.3 python where my Fedora 11 comes with 2.6) work.

But pulling the cover off like this did point out this one object that:

• seems to be intended to be private, but it gets referenced from other stdlib modules
• comes with no documentation at all
• comes with not a single comment explaining *why* it's there, or *why* it's ok to just create a completely empty and useless "object" that you can't even trace the origin of (I had to override __setattr__ on some class to figure out what the anonymous object was, and where it was being set from, to find it)

Maybe I'm oldfashioned, but this leaves me disappointed. This one line breaks beauty, explicitness, and readability that is included in the Zen of Python.

The only attempt at explaining I found is this.

Any Python guru want to set me straight on why this isn't the incredibly ugly wart on stdlib that I consider it to be ?

Meanwhile I'll go digging in svn to see when it was added to 2.6 and why.

I usually tend to think of Python as the discerning gentleman's programming language: well-behaved, well-documented, people take care of the code written. I like the batteries-included approach and assume that...

I hacked some more this evening on getting UbuntuOne running on my Fedora 11 desktop.

Now, obviously, trying to get something with 'Ubuntu' in the name on Fedora was going to be an exercise in masochism, so I pretty much knew what I was in for.

The good thing though is that the desktopcouch and ubuntuone hackers are obviously enthusiastic at someone getting this to run on Fedora, and as I often find the right motivation is 75% of the work. If these guys are going to be receptive to my feedback, then it is worth spending my time getting this to run.

I needed to first figure out order of packages and software. ubuntuone-storage-protocol goes underneath everything. For now I settled on creating a bdist_rpm out of the setup.py, which I should repackage properly later.

On top of that goes the ubuntuone-client stuff.

Here's a bread crumb trail of bugs I ran into with possible patches I made:

• ubuntuone-storage-protocol 1.0 release does not have pem file in MANIFEST
• ubuntuone poking into httplib.HTTPSConnection private variables which weren't there before 2.6.3 (Fedora 11 has 2.6, which I assume is the release right before 2.6.1 :))
• a bug where ssl authentication fails, because the ca-certs.crt of Ubuntu is a completely different path on Fedora - but that took a while to figure out because of the obtuse error message

Now I got it to the point where the client applet actually starts up without errors, and loads a UbuntuOne page into my Firefox window:

And there are no further tracebacks on my console.

Sadly, I get this puzzling notification message straight after:

I'm not sure yet how my client can be newer - I'm sure the ubuntuone guys will tell me what this means. Enough hacking for one day, time to catch some sleep for tomorrow.

UPDATE: apparently I ran into this bug, where apparently due to some bug the ubuntuone guys decided to add a capability to make sure no one would be using the old client. I understand the logic but I think that should be handled better - the message is not obvious, and I don't think it's easy to figure out what's wrong.

In any case, the patch worked for me, and I just synced my first test file to the cloud ! Whee ! Not sure why syncing a 22 byte text file took roughly half a minute to sync, but it's a start.

I hacked some more this evening on getting UbuntuOne running on my Fedora 11 desktop. Now, obviously, trying to get something with 'Ubuntu' in the name on Fedora was going...

Time to unravel some tufts of the yak hair lying around from this weekend.

I wanted to work on making my GTD application (using CouchDB) a little more friendly.

I started out by learning GreaseMonkey so I could modify Trac pages to include a link converting the ticket into a thing in my application.

The basics of that were easy, but I need to learn a bunch more Javascript before it will actually work well. So, I switched to finally figuring out if desktopcouch might be a good solution for the general problem for users to set up a couchdb database.

desktopcouch's tagline describes it nicely 'A CouchDB for every desktop.' From what I can tell, it has:

• a way to automatically start a per-user couchdb instance
• oauth enabled by default for it, so only you can get to it
• some gnomekeyring integration
• a pairing tool that makes it easy to pair with other desktopcouch instances on your network
• a python module on top of python-couchdb that layers a 'record' concept over CouchDB documents using record_type and record_revision keys
• some pre-defined record types for notes, contacts, and bookmarks
• possible integration with the UbuntuOne service

At this point I don't know how intertwined this record concept is with the rest of desktopcouch. As at the moment I want to use desktopcouch simply as a reliable way to get a secure, per-user, replicated couchdb database, I'd prefer to not deal with records at all at this point.

In the process of getting acquainted with desktopcouch and packaging it for Fedora, I ran into a few little niggles:

• First off, bdist_rpm didn't work for desktopcouch because of the man pages being compressed.
• My first run failed. Furthermore, the unhandled exception left my $HOME/.local/share/desktopcouch in a half-done state; I ran it again, and it worked, but it didn't generate a couchdb.html as it should have because of this.
• Some rpmlint warnings

As for the package, if you're on Fedora 11, just install tao-release for F-11 i386 then type 'yum -y install desktopcouch'

After that, you can start it by asking it for what port is running:


dbus-send --session --dest=org.desktopcouch.CouchDB --print-reply --type=method_call / org.desktopcouch.CouchDB.getPort


If all goes well that should come back with a number.

You can now access your desktopcouch through Futon with:

firefox $HOME/.local/share/desktop-couch/couchdb.html


Let me know if this worked for you or not !

I have a separate post about packaging ubuntuone stuff, which was much more complicated - and I'm still not sure if I will be able to use it as an online server for my couchdb app.

Now, for some questions to you desktopcouch-savvy people out there:

• Looking at the generated couchdb.html, I see that I can now access the user-specific couchdb with a generated username and password. If I want to push my GTD app to this couchdb, I can do so using this username and password. So, obvious questions: a) should I push with couchapp this way to get my app in desktopcouch ? b) is there a better way to get this username/password ? I assume desktopcouch does this in the python modules using gnome-keyring c) is it an intended mode of operation to be able to push my app into the user couchdb ? I am working on the web interface part served by couchdb and I want it to be one of the ways in which to access the data.

Is it possible to pair with a different user on the same machine ? I was on a laptop with no other linux computer around, so I was not able to test the pairing. I did set it up for a different user, but neither account seemed to see the other's couchdb running.

• Will I be able to sync non-record databases to ubuntuone ? If not, what else could I do to have an online couchdb to sync between my various work machines ?

Time to unravel some tufts of the yak hair lying around from this weekend. I wanted to work on making my GTD application (using CouchDB) a little more friendly. I...

Today while using bdist_rpm to build a quick package to test desktopcouch, the build failed on man pages. It took a while to figure out what to google for, but it turns out it's this bug which will turn 7 years old come Friday.

That is a little embarassing. I don't know if it's because bdist_rpm hardly ever gets used or because it's hard to figure out what the bug is or how to report it.

In any case, I attached a patch that worked for me today against python 2.6. I punted on actually rebuilding Python for Fedora for my repo since it's a little bit overkill (the plan is to build a proper .spec file anyway for the package), but if you need the patch it's in the bug report.

Today while using bdist_rpm to build a quick package to test desktopcouch, the build failed on man pages. It took a while to figure out what to google for, but...

After a visit from the unicode police I'm gearing up for a first morituri release.

If you're on F-11, you can just install my repository and then install the latest snapshot with
yum -y install morituri

After that, pop in a relatively well-known CD, then type:

rip offset find

Hopefully, it will be able to tell you the read offset of your CD drive.

Then do

rip cd rip --offset (the number from above)

and it should proceed to look up the CD on MusicBrainz, rip and verify the tracks to flac, and then do an AccurateRip verification.

Let me know if that works out for you. And if you're not on Fedora 11, you can always check out the source code directly, it's not much harder to get running.

After a visit from the unicode police I'm gearing up for a first morituri release. If you're on F-11, you can just install my repository and then install the latest...