sudo apt-get update && sudo apt-get dist-upgrade

Debian 11 (codename Bullseye) was recently released. This was the smoothest upgrade I've experienced in some 20 years as a Debian user. In my haste, I completely forgot to first upgrade dpkg and apt, doing a straight dist-upgrade. Nonetheless, everything worked out of the box. No unresolved dependency cycles. Via my last-mile Gigabit connection, it took about 5 minutes to upgrade and reboot. Congratulations to everyone who made this possible!

Since the upgrade, only a handful of bugs were found. I filed bug reports. Over these past few days, maintainers have started responding. In once particular case, my report exposed a CVE caused by copy-pasted code between two similar packages. The source package fixed their code to something more secure a few years ago, while the destination package missed it. The situation has been brought to Debian's security team's attention and should be fixed over the next few days.

Afterthoughts

Having recently experienced hard-disk problems on my main desktop, upgrading to Bullseye made me revisit a few issues. One of these was the possibility of transiting to BTRFS. Last time I investigated the possibility was back when Ubuntu briefly switched their default filesystem to BRTFS. Back then, my feeling was that BRTFS wasn't ready for mainstream. For instance, the utility to convert an EXT2/3/4 partition to BTRFS corrupted the end of the partition. No thanks. However, in recent years, many large-scale online services have migrated to BRTFS and seem to be extremely happy with the result. Additionally, Linux kernel 5 added useful features such as background defragmentation. This got me pondering whether now would be a good time to migrate to BRTFS. Sadly it seems that the stock kernel shipping with Bullseye doesn't have any of these advanced features enabled in its configuration. Oh well.

Geode

The only point that has become problematic is my Geode hosts. For one things, upstream Rust maintainers have decided to ignore the fact that i686 is a specification and arbitrarily added compiler flags for more recent x86-32 CPUs to their i686 target. While Debian Rust maintainers have purposely downgraded the target, RustC still produces binaries that the Geode LX (essentially an i686 without PAE) cannot process. This affects fairly basic packages such as librsvg, which breaks SVG image support for a number of dependencies. Additionally, there's been persistent problems with systemd crashing on my Geode hosts whenever daemon-reload is issued. Then, a few days ago, problems started occurring with C++ binaries, because GCC-11 upstream enabled flags for more recent CPUs in their default i686 target. While I realize that SSE and similar recent CPU features produce better binaries, I cannot help but feel that treating CPU targets as anything else than a specification is a mistake. i686 is a specification. It is not a generic equivalent to x86-32.

WebRTC fails tests on Firefox 78.10.0esr (64-bit)

Having to participate in many online events since the COVID crisis started, I've come to notice that few of the online clients work properly on the current Firefox ESR found in Debian. A quick visit at WebRTC Test confirmed that none of the tests in the Network and Connectivity section pass. Meanwhile, a Windows 10 laptop running Edge via the same network works just fine, so I have to assume that either a Firefox or Debian packaging issue is to blame, but I wouldn't know where to start. Any help? Thanks!

Shipping Debian with GNOME X.XX.0 is an extremely bad idea

Since the freeze has slowly crept in, now is the time to revisit my pet peeve with Debian's release process: to publish a new Debian release as soon as GNOME published a new X.XX.0 version. This is an extremely bad idea: X.XX.0 releases tend to lack polish, their translations are not up-to-date and several silly bugs that hamper the user experience (what the Ubuntu guys call "paper cuts") exist. Those issues tend to be fixed later when GNOME X.XX.1, X.XX.2, etc. bugfix releases are published. However, Debian has a policy of not pushing non-security releases onto a stable distribution. In this particular case, there are only two valid alternatives: either release Bullseye with GNOME 3.38.X or change the Debian policy to allow pushing 3.40.X bugfix releases via bullseye-updates.

OpenWRT: WRT54GL: Backfire: IPv6 issues

While having a Debian boxen as a router feels nice, I kept on longing for something smaller and quieter. I then remembered that I still had my old WRT54GL somewhere. After upgrading the OpenWRT firmware to the latest supported version for that hardware (Backfire 10.03.1, r29592), I installed radvd and wide-dhcpv6-client. Configuring radvd to deliver consistent results was easy enough.

The issue I keep on experiencing is the external interface (wan) dropping the IPv6 address it received from the ISP via router advertisement, which in turn kills the default IPv6 route to the outside world. Logging in via SSH and manually running "rdisc6 eth0.1" restores the IPv6 gateway. I just honestly wished I didn't have to do this every time I need to reboot the router.

Does this issue sound familiar to anyone? What was the solution?

PS: No, I won't just go and ditch this WRT54GL just because new toys exist on the market. This is obviously a software issue, so I need a software solution.

PPS: IPv6 pretty much works out of the box on the Debian boxen I had been using as my router. I previously wrote about this on my blog. Basically, it's unlikely to be an ISP issue.

Help needed: clean up and submit KMS driver for Geode LX to LKML

Ever since X.org switched to rootless operation, the days of the Geode X.org driver have been numbered. The old codebase dates back from Geode's early days at Cyrix, was then updated by NSC to add support for their new GX2 architecture, from which AMD dropped GX1 support and added support for their new LX architecture. To put it mildly, that codebase is a serious mess.

However, at least the LX code comes with plenty of niceties, such as being able to detect when it runs on an OLPC XO-1 and to probe DCC pins to determine the optimal display resolution on other hardware. This still doesn't make the codebase cruft-free.

Anyhow, most Linux distributions have dropped support for anything older than i686 with PAE, which essentially means that the GX2 code is just for show. Debian is one of very few distributions whose x86-32 port still ships with i686 without PAE. In fact, the lowest common denominator kernel on i386 is configured for Geode (LX).

A while back, someone had started working on a KMS driver for the Geode LX. Through word of mouth, I got my hands on a copy of their Git tree. The driver worked reasonably well, but the codebase needs some polishing before it could be included in the Linux kernel tree.

Hence this call for help:

Is there anyone with good experience of the LKML coding standards who would be willing to clean up the driver's code and submit the patch to the LKML?