Looking back, I cannot think of a single moment when Joey wouldn't have shown the utmost patience and courtesy towards anyone involved in Debian, even towards mere users filing sometimes senseless bug reports against his packages. From this perspective, I cannot help but venture that whatever chain of events lead to Joey's decisions essentially means one thing: Debian must have seriously gotten off-course for someone who has been involved for so long to call it quits. As for the current situation at hands, while I admittedly haven't followed too closely who or what caused Joey's decision, I nonetheless cannot help but feel that whoever pushed Joey's buttons so hard as to make him decide to leave Debian ought to be the one(s) kicked out of Debian instead.
sudo apt-get update && \ sudo apt-get install apt dpkg locales && \ sudo apt-get --purge dist-upgrade && \ sudo apt-get --fix-policy install && \ sudo apt-get --purge autoremove $(deborphan --guess-all)
I guess I'll be busy filing bug reports for the next few hours. Wish me (and each faulty package's maintainer) luck!
PS: Apparently, so many aspects of Debian have become dependent upon GPG features that merely upgrading APT, DPKG and libc6+locales is no longer enough. One must also upgrade gnupg and gnupg2. Thus, the second element of the above recipe has become:
sudo apt-get install apt dpkg gnupg gnupg2 locales && \
Hopefully, APT's dist-upgrade command already knows that these must be upgraded first...
PPS: Hosts running Network-Manager cannot be upgraded remotely, because Network-Manager insists upon killing the network connection and the SSH daemon with it, when its turn comes to get upgraded.
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?
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.
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?
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.
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?
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?