After many years of effort, I am happy to announce that Debian riscv64 is now an official architecture!

This milestone is not the end of the journey but rather the beginning of a new one: the port will need to be rebootstrapped in the official archive, build daemons will have to be reinstalled and handed over to DSA, many bugs will need to be fixed. If everything goes well, the architecture will eventually be released with Trixie. Please note that this process will be long and will span several months.

I would like to take this opportunity to thanks everyone who contributed to this significant milestone, including individuals and Debian teams, as well as the organizations and companies that provided us with resources (by rough chronological order): MIT CSAIL, Sifive, Mullvad, tetaneutral.net, OSU Open Source Lab, Microchip, BeagleBoard.org Foundation, RISC-V international, PLCT Lab (ISCAS), StarFive, and Metropolitan Area Network Darmstadt.

Over the years, the Debian GNU/kFreeBSD port has gone through various phases. After many years of development, it was released as technology preview with the release of Squeeze and eventually became an official architecture with the release of Wheezy. However it ceased being an official architecture a couple of years later with the release of Jessie, although a jessie-kfreebsd suite was available in the official archive. Some years later, it was moved to the debian-ports archive, where it slowly regressed over the years. The development totally has now been stopped for over a year, and the port has been removed from the debian-ports archive. It's time to say it goodbye!

I feel a touch of nostalgia as I was deeply involved in the Debian GNU/kFreeBSD port for nearly a decade, starting in 2006. There are many different reasons to like GNU/kFreeBSD ranging from political to technical considerations. Personally, I liked the technical aspect, as the FreeBSD kernel, at that time, was ahead of the Linux kernel in term of features: jails, ZFS, IPv6 stateful firewalling, and at a later point superpages. That said it was way behind for hardware support and to the best of my knowledge this remains unchanged. Meanwhile, the Linux kernel development accelerated in the latter stages of the 2.6.x series, and eventually closed the feature gap. At some point, I began to lose interest, and also to lack time, and slowly stepped away from its development.

A few months ago, I switched my backup server to an ODROID-M1 SBC. It uses a RK3568 SoC with a quad-core Cortex-A55 and AES extensions (useful for disk encryption), and I added a 2 TB NVME SSD to the M2 slot. It also has a SATA connector, but the default enclosure does not have space for 2.5" drives. It's not the fastest SBC, but it runs stable and quite well as a backup server, and it's fanless, and low-power (less than 2 W idle). The support for the SoC has been added recently to the Linux kernel (it's used by various SBC), however the device tree for the ODROID-M1 was missing, so I contributed it based on the vendor one, and also submitted a few small fixes.

All the changes ended in the Bookworm kernel, and with the Bookworm release approaching, I decided it was the good moment to upgrade it. It went quite well, and now I can enjoy running dist-upgrade like on other stable servers without having to care about the kernel. I am currently using Borg as a backup software, but the upgrade also gave access to a newer Restic version supporting compression (a must have for me), so I may give it a try.

For over 15 years, I've hardly made any updates to my website, and it remains low on my priority list. So I made a radical decision to replace it entirely with my blog. The content of the website has been reduced to just two additional pages.

But nothing has been lost: nowadays, Wikipedia is a much better platform for sharing knowledge than random websites. And it happens that they already cover all that was on my website about subaquatic diving in French. They also offer a multitude of resources in electronics, including the topics that were on my website: LCD displays, I²C bus, barcodes, parallel ports, serial ports, and DCF77 reception.

Finally if you're in need of Debian QEMU images for various architectures, I recommend the Debian Quick Image Baker pre-baked images page instead.

For quite some time, many people asked for a riscv64 porterbox. Now we've got one called debian-riscv64-porterbox-01.debian.net.

A big thanks to SiFive for providing the HiFive Unmatched board and OSUOSL for assembling the hardware and hosting it.

The GNU libc version 2.34 has just been accepted into unstable. Getting it ready has been more challenging than other versions, as this version integrates a few libraries (libpthread, libdl, libutil, libanl) into libc. While this is handled transparently at runtime, there are a few corner cases at build time:

• For backwards compatibility, empty static archives (e.g. libpthread.a) are provided, so that the linker options keep working. However a few cmake files shipped in some packages still reference the path to the shared library symlink (e.g. libpthread.so) which is now removed.

• A few symbols have also been moved from libresolv to libc and their __ prefix removed. While compatibily symbols are provided in the shared library for runtime compatiblity, this does not work at link time for static libraries referencing this symbol.

The next challenge is to get it migrating into testing!

For the adventurous persons, GNU libc 2.35 is now available in experimental. And as people keep asking, the goal is to get the just released GNU libc 2.36 into Bookworm.

The long awaited James Webb Space Telescope has finally been successfully launched today. It is a Xmas gift for many people who have been waiting for it for many years.

On a more personal side, I am happy and proud to have contributed to a tiny part of a tiny piece of software of this huge project over the last 15 years: the Instrument Performance Simulator of the NIRSpec instrument.

I joined the Debian GNU libc team and did my first glibc upload. At that time source-only upload were far from existing, and I was using a HP 9000 model 715/80 HPPA workstation for my Debian builds.

Still it seems to me like yesterday.

I have received two MIPS Creator CI20 boards, thanks to Imagination Technologies. It's a small MIPS32 development board:

As you can see it comes in a nice packaging with a world-compatible power adapter. It uses a Ingenic JZ4780 SoC with a dual core MIPS32 CPU running at 1.2GHz with a PowerVR SGX540 GPU. The board is fitted with 1GB of RAM, 8GB of NOR flash, HDMI output, USB 2.0 ports, Ethernet + Wi-Fi + BlueTooth, SD card slot, IR receiver, expansion headers and more. The schematics are available. The Linux kernel and the U-Boot bootloader sources are also available.

Powering this board with a USB keyboard, a USB mouse and a HDMI display, it boots off the internal flash on a Debian Wheezy up to the XFCE environment. Besides the kernel, the Wi-Fi + Bluetooth firmware, and very few configuration changes, it runs a vanilla Debian. Unfortunately I haven't found time to play more with it yet, but it looks already quite promising.

The board has not been formally announced yet, so I do not know when it will become available, nor the price, but if you are interested I'll bring it to DebConf14. Don't hesitate to ask me if you want to look at it or play with it.

Last time I changed my desktop computer I bought a CPU from the Intel Haswell family, the one available on the market at that time. I carefully selected the CPU to make sure it supports as many instructions extensions as possible in this family (Intel likes segmentation, even high-end CPUs like the Core i7-4770k do not support all possible instructions). I ended-up choosing the Core i7-4771 as it supports the "Transactional Synchronization Extensions" (Intel TSX) instructions, which provide transactional memory support. Support for it has been recently added in the GNU libc, and has been activated in Debian. By choosing this CPU, I wanted to be sure that I can debug this support in case of bug report, like for example in bug#751147.

Recently some computing websites started to mention that the TSX instructions have bugs on Xeon E3 v3 family (and likely on Core i7-4771 as they share the same silicon and stepping), quoting this Intel document. Indeed one can read on page 49:

HSW136. Software Using Intel TSX May Result in Unpredictable System Behavior

Problem: Under a complex set of internal timing conditions and system events, software using the Intel TSX (Transactional Synchronization Extensions) instructions may result in unpredictable system behavior.
Implication: This erratum may result in unpredictable system behavior.
Workaround: It is possible for the BIOS to contain a workaround for this erratum.

And later on page 51:

Due to Erratum HSw136, TSX instructions are disabled and are only supported for software development. See your Intel representative for details.

The same websites tell that Intel is going to disable the TSX instructions via a microcode update. I hope it won't be the case and that they are going to be able to find a microcode fix. Otherwise it would mean I will have to upgrade my desktop computer earlier than expected. It's a bit expensive to upgrade it every year and that's a the reason why I skipped the Ivy Bridge generation which didn't bring a lot from the instructions point of view. Alternatively I can also skip microcode and BIOS updates, in the hope I won't need another fix from them at some point.