xf86-video-geode 2.11.14

A few days ago, I pushed out version 2.11.14 of the Geode X.org driver. This is the driver used by the OLPC XO-1 and by a plethora of low-power desktops, micro notebooks and thin clients.

This release mostly features long-overdue fixes to rendering issues under GTK3+ and xulrunner, plus yet more ongoing changes to make this driver compile under recent X servers.

Sadly, the release took place much too late to be included into the upcoming stable Debian version, Wheezy, which is already deeply into freeze, pending publication.


HTML5: Firefox without Flash

Over the past few days, I decided to purge Gnash and LightSpark from my laptop to see whether my Internet experience would be affected in any dramatic way. Amazingly, a number of sites seem to offer video content encoded in Theora (VP3) or WebM (VP8). Sadly, a handful of popular sites such as Vimeo insist upon using the H.264 (MPEG-4) CODEC, which cannot be safely supported on Free Software because of unclear licensing issues that might impose an ulterior usage fee onto the end-users.

The good news is that the Mozilla Foundation has decided to avoid the issue together: starting with the most recent release of the mobile version of Firefox, content decoding is offloaded to the platform's native media CODEC library. On most Free Software platforms, this means that Gstreamer will handle the content and, in turn, use gstreamer-plugins-bad to perform the decoding. However, Gstreamer support is still rather sketchy, as attested by this Debian bug report and thus disabled by default. This leaves me wondering how little is missing for this to properly work. Would either Canonical or Red Hat perhaps be interested in funding this?


Bounty: PulseAudio: implement compression into the RTP modules

I'm looking for someone – preferably based within the IBAN zone – to implement compression support into PulseAudio's RTP modules. Please contact me via my Ubuntu address for details.


PulseAudio: system mode broken

Ever since version 1.1 of PulseAudio was released, remote audio stopped working for me. Basically, the tunnel created by enabling "Detect native remote PulseAudio sinks" in paprefs on the client side immediately crashes the PulseAudio server on the remote host. I reported the issue at Free Desktop bug #49681. The issue still exists in version 2.0, which is what Debian's next stable release is supposed to ship (and in 2.1, available via the experimental repository). This essentially means that I cannot upgrade my hosts to Wheezy without losing my remote speakers. Would anybody knowledgable enough with PulseAudio internals be able to help me track down the cause of this bug?

OpenWRT: SLAAC and DHCPv6 on White Russian

As I recently reported, I have been trying to configure my Linksys WRT54GL running the OpenWRT firmware (version 0.9 a.k.a. White Russian) to support SLAAC and DHCPv6 out of the box.

Most of the feedback I got involved upgrading the OpenWRT firmware to a more recent release that might not fit the available storage capacity of the device, which felt like too risky of an operation to attempt.

The solution I found instead involved adding ipkg sources to OpenWRT's backports repository, which offers a minimalistic DHCPv6 client. Although I haven't been able to find any proper documentation for this client, the content of its configuration file is mostly intelligible. What remains now is to actually configure it to cooperate with the kernel's native SLAAC implementation and, whenever an IPv6 network is found on the ISP side, to propagate the address space, DNS and routing information to my LAN using radvd.

Would anyone located within the Helsinki metropolitan area happen to have an IPv6 testing environment that would at least allow me to configure and test my router?


OpenWRT: accepting Router Adverts from the ISP in White Russian?

As we are getting closer to the World IPv6 Day, I thought that I'd see if I can upgrade my WRT54GL's OpenWRT (White Russian) installation to accept Router Adverts from the ISP to acquire an IPv6 address (rather than via a 4-to-6 tunnel broker, which seems to be the most documented case), and to propagate its IPv6 address space to my local network via my WRT45GL's radvd. Unfortunately, most of the instructions out there concern newer OpenWRT releases to which I cannot upgrade to because their software base takes up significantly more space than White Russian does. Still, I figure that someone in the community must have already succeeded at configuring their WRT54GL for this and might be able to help. Anyone? :)


Ubuntu: LTS to LTS+1 upgrade leaves cruft

Over the past few weeks, I upgraded my Ubuntu hosts to the Precise release due to be published next month. While the upgrade on my desktops from Oneiric to Precise went mostly well, the upgrade of my terminal server from Lucid to Precise was more daunting. In short: too many packages leave an undue amount of cruft behind, namely tons of obsolete configuration files that are not correctly handled by maintainer scripts, to either delete obsolete files or to rename them to the currently valid filename. At Debian, these oversights are periodically monitored using piuparts and reported to the package maintainer, but Ubuntu doesn't seem to offer this sort of automated Quality Assurance process yet. Perhaps this would be something worth developing?

PS: For those who wonder how I spotted those obsolete configuration files, I simply enabled the FLAUSCH environment variable before running upgrade-system.


Adopted: ispell-et, myspell-lv, rus-ispell.

Over recent months, I have been pondering the relevance of my Free Software involvement a lot:

More than anything, it constantly feels more and more like several important distributions and projects are moving in directions that break with the old ways far too radically, by breaking software usability rules such as "least surprise", "works out of the box", and "if it ain't broken, don't fix it" either to try new approaches to addressing existing needs or simply for change's sake.

Another aspect lies in my usual motivation for packaging or adopting software: because I need it and nobody else bothered doing it. Further reflection made me ponder what, correspondingly, are my usual reasons for dropping software: because what exists already works and because everybody and their grand-mother already invented a million of ways to handle the same issue.

Which brings us to today's news.

What prompted me to hand the dictionary packages I maintained over to someone else was a combination of "no longer need it" and "it already works fine as it is."

For instance, the Estonian dictionaries haven't seen any upstream release since the initial one in 2003. While I still use Estonian daily in my online communications, the last 9 years have mostly been spent making minor changes to the dependencies and maintainer scripts, just to keep the package compliant with current Debian packaging policies and with ongoing improvements to the dictionary-common maintainer tools. This is not the sort of work that requires any knowledge of the Estonian language, so I felt that having dictionary-common developers handle those technical transitions in a clean and across-the-board way for as many dictionary packages as possible would be more productive than me trying to keep track of those changes by myself.

A similar case applies to the Latvian dictionaries. While there have been occasional upstream releases, some of which required patching the source code, maintaining the package has mostly been about tracking Debian policy changes and dictionary-common functional changes. Additionally, my interest for learning Latvian has dramatically dropped over the years, so I no longer saw any point in remaining involved in maintaining the package.

Ditto for the Russian dictionaries: occasional upstream releases, occasional patches, regular packaging upgrades to keep up with the Debian policy and with dictionary-common functionality, but no longer much of anything than a passive interest in practicing my Russian.

One of the developers behind dictionary-common, Agustin Martin Domingo, frequently helped me make sense of the changes I needed to track in the past, so he gladly accepted taking over the technical maintenance of all 3 packages. The Estonian dictionaries, while extremely skim in the breadth of vocabulary they cover, remain useful, but are essentially deprecated, as the upstream author is working on a spell checking engine similar to what Voikko does for Finnish, which is why maintaining them will be a rather easy task for Agustin. Meanwhile, Aigars Mahinovs passively remains on board for the Latvian dictionaries, while the Russian dictionaries have been adopted by Mikhail Gusarov, in both cases with Agustin assisting on technical matters.

Basically, I feel that passing the maintenance over to people whose motivation remains high is a better way to guarantee those packages' future than leaving them in my unmotivated hands and I'm glad that I found someone to keep on packaging them.

PS: happy Valentine's day to everyone!


xf86-video-geode 2.11.13

A few days ago, I pushed out version 2.11.13 of the Geode X driver. This is the driver used by the OLPC XO-1, by a plethora of thin clients such as the ThinCan, by low-power desktops such as the Linutop and by a few notebooks such as the eCafé EC800.

While this release indeed features a few bugfixes (mainly to keep this driver compilable on the latest X server), the lion's share of the changes involve a complete overhaul of the build scripts, courtesy of Gaetan Nadon. The key motivation for this overhaul was to acknowledge the efforts made by third-party contributors to make the driver compile on BSD variants. Sure enough, this release finally compiles on FreeBSD and, low and behold, on Hurd.

However, the hybrid nature of Debian's FreeBSD kernel-based GNU operating system variant posed an additional challenge, because it provides usable support for Video for Linux version 2 (V4L2), but without the full complement of Linux definitions. This resulted in one post-release commit (included in Debian and Ubuntu package 2.11.13-2), following which my assertion that we could now safely define this package as Architecture: any-i386 finally proved to be a safe one for Debian-based operating systems.

At this point, I'm curious as to how many more operating systems, especialy BSD variants, can finally use this driver. Patches to further improve support of non-Linux systems are welcome.