Outstanding issue in Debian: unroutable public v6 IP

Given how Debian and Ubuntu nowadays enable IPv6 support by default, the routing table includes some IPv6 entries by standard. However, this has the unpleasant side-effect that lib C tries to connect to public IPv6 addresses, even in a case when the only IPv6 entries are for loopback and local link. Apparently, libc incorrectly assumes that the mere presence of any IPv6 means that there is a usable default IPv6 route. This results in, among other things, APT failing at fetching packages from the Debian repository if the DNS rotation returned the IPv6 address for the server first. I was thus wondering whether libc6 could be made to reject public IPv6 addresses, in cases when the host has no IPv6 gateway in its routing table? Or would there be a smarter way to prevent applications from failing at contacting IPv6 addresses whenever there is no IPv6 connection to the outside world?


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.