Nokia kindly sponsored my trip to Maemo Summit in Berlin.

Unexpectedly was asked to give my LinuxTag presentation during the lightning talks. It did not go very well. Note to self: advance preparation helps, at least if you know you're going to present something.

Met PyPy folks (Maciej and Holger). Had a mutual "what on Earth are you doing here?" reaction. Learned a new quirk in the Python language (try: ... finally: does not set sys.exc_info()).

Impressed by one guy (sorry, but I'm really bad with names) giving a presentation from the N810, with OpenOffice.org Impress in a Debian chroot, over a SIS USB2VGA dongle. Apparently he created the whole setup in half an hour before the actual talk.

No free wireless at the hotel. Paid wifi options include 25 EUR for 24 hours or 30 EUR for 30 days. Can I have just the 29 days for the 5 EUR? No.

The WiFi at c-base was fast and almost flawless. Missed half of the talks while checking my email and blogs. I'm addicted to the Internet. :(

Still able to get up before 6 AM. The US trip has done wonders with my daily schedule.

Netspeed is a GNOME panel applet that shows your current upload/download speed in bytes (or bits) per second. I love it. Except... you have to manually say which network device to monitor. If you're switching between wireless and wired, this gets old really quickly. There's an option, Always monitor a connected device, but it is buggy and usually gets stuck monitoring some stupid network interface like wmaster0 or vmnet8.

Today I spent a couple of hours fiddling with netspeed's source code and fixed the bug! Patches attached to the bug report and tested with netspeed-0.14 on Ubuntu Hardy.

While doing this I created a local Bazaar branch for playing with the source code. Sadly, Bazaar decided to hurt me again: bzr viz, instead of letting me look at my commits in a nice GUI window, barfs AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph' and stops. Apparently the latest version of bzr-gtk (trunk from launchpad) is not compatible with the latest version of bzr (1.6rc2 from the Hardy PPA).

It's becoming a pattern: every couple of months I give Bazaar a try, and I hit a new bug that prevents me from doing whatever I wanted to do. Why do I even keep trying?

The subprocess module in Python 2.4 has a race condition. If you're doing process.communicate() on more than one pipe, on a Unix-like system you may end up getting an exception (4, 'Interrupted system call') when the child process terminates, if the SIGCHLD signal arrives at an inopportune moment.

This bug appears to be fixed in Python 2.5.2, where all calls to select, read and write are wrapped in a while looks and ignore EINTR errors.

Maybe this blog post will save someone else the hour needed to study strace logs trying to figure this out.

Update: It's not fixed in upstream Python. Ubuntu patched it a year ago for python2.5, but not for python2.4. Upstream knows about the patch, but so far only a partial fix (EINTR guard around select, but not around read/write) has made it into svn trunk (but not the 2.5 maintenance branch, yet, and I'm not even thinking about 2.4).

Today was a release day for me.

I released eazysvn 1.8.0, the helpful syntactic sugar wrapper that makes using Subversion branches almost not painful. This is the first release with full on-line documentation (at last).

I also bumped the version number of restview, my ReStructuredText viewer, to a solid 1.0.0. I've been using it for years now without problems, which was not immediately apparent from the old version number (a modest 0.0.5).

Before that I made my first ever bugfix releases of a couple of Zope 3 packages (zope.component 3.5.1 and zope.app.testing 3.4.3). Blame me if anything is wrong with them. Kudos to Philipp von Weitershausen for his release process documentation.

So, you hear that your media player supports remote control over D-Bus. That's great, isn't it?

So, you're lying on a couch, listening to music and reading a book on your N810. Suddenly a song you don't like starts playing. Do you

A. Stand up, walk to the PC, click the "Next song" button with your mouse,

or

B. Open Terminal on your N810, ssh into your desktop and run banshee-1 --next?

If you chose option B, you lose:

mg@mg-desktop:~$ banshee-1 --next
[Warn  00:43:59.080] DBus support could not be started. Disabling for this session.
[Info  00:43:59.101] Running Banshee 1.0.0

(Nereid:9174): Gtk-WARNING **: Locale not supported by C library.
	Using the fallback 'C' locale.

(Nereid:9174): Gtk-WARNING **: cannot open display: 

You can't access your D-Bus session from a different login session. This means, among other things, that I cannot ask gnome-power-manager to suspend my laptop that I left at work if I'm trying to run gnome-power-cmd.sh suspend over an SSH session.

Dear lazyweb, what's the fix?

P.S. I apologise for the impertinence of asking dear lazyweb a question on a blog that has no comments facility, but I somehow cannot bring myself to trust Pyblosxom's comment plugins in today's spam-filled world without an in-depth evaluation for which I don't have the time and energy. At least there's a mailto link clearly labeled "send feedback" below each blog entry.

Update: Steve Holden suggested using screen, which works, but only if I have the foresight to start a screen session on the desktop before I walk away. I can then reattach to the running screen session with screen -x and run banshee-1 --next inside.

Ross Burton says that setting DISPLAY=:0 ought to help D-Bus find the existing session, but only if I have the very latest and greatest D-Bus (1.2.1), which I don't have. With D-Bus 1.1.20 in Hardy, all I get by setting $DISPLAY is Banshee opening a second player instance.

Update #2: Lee Harr suggests fishing out the DBUS_SESSION_BUS_ADDRESS environment variable from ~/.dbus/session-bus/*.

Update #3: Kees Cook also has a solution.