Aurélien Jarno

Running upstream OpenSBI on SpacemiT K1

aurel32 — Sun, 26 Apr 2026 14:13:00 +0200

The SpacemiT K1 is a rather interesting RISC-V SoC, found for instance on boards like the Banana Pi BPI-F3 board. It's one of those platforms that looked promising on paper, but took a bit of time before things really started to move upstream. Things have clearly accelerated over the last few months.

Linux 7.0 brings, among other things PCIe support, making the board quite capable as a development board. SD card, CPU thermal sensor and cpufreq support are already in the pipe.

Unfortunately the situation is less advanced on the firmware side. There is only very basic support for the SpacemiT K1 in U-Boot for the second stage, and initial SPL support has been posted on the mailing list, but has not yet been merged. In practice, this means you still have to rely on the vendor U-Boot, which is based on the rather old 2022.10 release.

On the other hand, OpenSBI does have upstream support for the SpacemiT K1, however it is not compatible with the vendor U-Boot, mostly due to device tree differences.

This can be addressed by applying a few patches to the vendor U-Boot, which I have published in a git tree in the k1-bl-v2.2.y-opensbi branch (technically this can also be handled on the OpenSBI side, but I prefer using a vanilla upstream OpenSBI version). The first two patches update the configuration to get closer to the upstream U-Boot defaults, and to enable some configuration options for the Milk-V Jupiter board, which stores its firmware in SPI NOR flash, instead of eMMC for the Banana Pi BPI-F3. The following patches update the device tree by adding extra compatible entries to several devices, as expected by the upstream kernel and OpenSBI (thanks to Troy Mitchell for the hint about the UART change) and update the CPU riscv,isa properties. Finally an additional patch adds the SpacemiT P1 PMIC to the device tree, which is required for the OpenSBI reboot patchset I recently posted (this is currently done only for the Banana Pi BPI-F3 and Milk-V Jupiter boards, but extending it to other boards should be straightforward).

Building this U-Boot version is as simple as running this command in the source directory:

make k1_defconfig && make

On a Banana Pi BPI-F3 board, the resulting U-Boot can be flashed with:

echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=FSBL.bin of=/dev/mmcblk0boot0 bs=512 seek=1
dd if=u-boot.itb of=/dev/mmcblk0p1

Building upstream OpenSBI is also fairly simple, and can be done by running this command in the source directory:

make PLATFORM=generic

On a Banana Pi BPI-F3 board, the resulting OpenSBI can be flashed with:

dd if=fw_dynamic.itb of=/dev/mmcblk0p2

Note that the vendor U-Boot version is patched to install OpenSBI in a separate partition instead of embedding, as the upstream U-Boot does. While this works well on the Banana Pi BPI-F3, the corresponding partition in the Milk-V Jupiter SPI NOR flash is too small for the upstream OpenSBI version, and can't be easily resized without breaking compatibility. To address this, the branch k1-bl-v2.2.y-opensbi-embedded contains an additional patch (a bit hackish I admit) to somehow restore the upstream approach. The build process remains simple, first build OpenSBI with the following command:

make PLATFORM=generic

Then build U-Boot, specifying the patch to the just built OpenSBI firmware:

make k1_defconfig && make OPENSBI=/path/to/opensbi/build/platform/generic/firmware/fw_dynamic.bin

On a Milk-V Jupiter board, the resulting combined U-Boot/OpenSBI can be flashed with:

modprobe mdtblock
dd bs=4k if=FSBL.bin of=/dev/mtdblock2
dd bs=4k if=u-boot.itb of=/dev/mtdblock5

This combined U-Boot/OpenSBI can also be used on a Banana Pi BPI-F3, using the same flashing procedure as above, while skipping the OpenSBI part (although running it won't cause any issue, it will simply be unused).

All of this is admittedly a bit hackish, but enabling the use of upstream OpenSBI is already one step forward. Hopefully, in a few months, we will be able to rely entirely on upstream U-Boot.

UEFI Unified Kernel Image for Debian Installer on riscv64

aurel32 — Sat, 30 Nov 2024 10:41:00 +0100

On the riscv64 port, the default boot method is UEFI, with U-Boot typically used as the firmware. This approach aligns more closely with other architectures, which avoid developping riscv64 specific code. For advanced users, booting using U-Boot and extlinux is possible, thanks to the kernel being built with CONFIG_EFI_STUB=y.

The same applies to the Debian Installer, which is provided as ISO images in various sizes and formats like on other architectures. These images can be put on a USB drive or an SD-card and booted directly from U-Boot in UEFI mode. Some users prefer to use the netboot "image", which in practice consists of a Linux kernel, an initrd, plus a set of Device Tree Blob (DTB) files.

However, booting this in UEFI mode is not straightforward, unless you use a TFTP server, which is also not trivial. Less known to users, there is also a corresponding mini.iso image, which contains all the above plus a bootloader. This offers a simpler alternative for installation, but depending on your (vendor) U-Boot version this still requires to go through a media.

Systemd version 257-rc2 comes with a great new feature, the ability to include multiple DTB files in a single UKI (Unified Kernel Image) file, with systemd-stub automatically loading the appropriate one for the current hardware. A UKI file combines a UEFI boot stub program, a Linux kernel image, an optional initrd, and further resources in a single UEFI PE file. This finally solves the DTB problem in the UEFI world for distributions, as a single image can work on multiple boards.

Building upon this, debian-installer on riscv64 now also creates a UEFI UKI mini.efi image, which contains systemd-stub, a Linux kernel, an initrd, plus a set of Device Tree Blob (DTB) files. Using this image also ensures that the system is booted in UEFI mode. Booting it with debian-installer is as simple as:

load mmc 0:1 $kernel_addr_r mini.efi # (can also be done using tftpboot, wget, etc.)
bootefi $kernel_addr_r

Additional parameters can be passed to the image using the U-Boot bootargs environment variable. For instance, to boot in rescue mode:

setenv bootargs "rescue/enable=true"

AI crawlers should be smarter

aurel32 — Tue, 19 Nov 2024 23:31:00 +0100

It would be fantastic if all those AI companies dedicated some time to make their web crawlers smarter (what about using AI?). Noawadays most of them still stupidly follow every link on a Git frontend.

Hint: Changing the display options does not provide more training data!

Welcome Debian riscv64

aurel32 — Sun, 23 Jul 2023 21:28:00 +0200

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.

Goodbye Debian GNU/kFreeBSD

aurel32 — Fri, 14 Jul 2023 18:14:00 +0200

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.

Backup server upgraded to Bookworm

aurel32 — Wed, 12 Apr 2023 11:07:00 +0200

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.

New website, or kind of...

aurel32 — Tue, 11 Apr 2023 10:29:00 +0200

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.

riscv64 porterbox

aurel32 — Tue, 08 Nov 2022 23:52:00 +0100

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.

GNU libc 2.34 in unstable

aurel32 — Sun, 07 Aug 2022 23:25:00 +0200

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.

James Webb Space Telescope launched!

aurel32 — Sat, 25 Dec 2021 16:10:00 +0100

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.

10 years ago...

aurel32 — Tue, 23 Feb 2016 21:43:00 +0100

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.

MIPS Creator CI20

aurel32 — Wed, 20 Aug 2014 22:52:00 +0200

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.

Intel about to disable TSX instructions?

aurel32 — Fri, 15 Aug 2014 18:02:00 +0200

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.

Debian is switching (back) to GLIBC

aurel32 — Wed, 18 Jun 2014 22:04:00 +0200

Five years ago Debian and most derivatives switched from the standard GNU C Library (GLIBC) to the Embedded GLIBC (EGLIBC). Debian is now about to take the reverse way switching back to GLIBC, as EGLIBC is now a dead project, the last release being the 2.19 one. At the time of writing the glibc package has been uploaded to experimental and sits in the NEW queue.

EGLIBC is dead for a good reason: the GLIBC development has changed a lot in the recent years, due to two major events: Ulrich Drepper leaving Red Hat and the GLIBC development, and the GLIBC steering committe self-dissolving. This has resulted in a much more friendly development based on team work with good cooperation. The development is now based on peer review, which results in less buggy code (humans do make mistakes). It has also resulted in things that were clearly impossible before, like using the same repository for all architectures, and even getting rid of the ports/ directory. Before we used to have two sets of architectures, the main ones in the glibc repository with architectures like x86, SuperH or SPARC, and the secondary ones in the glibc-ports repository with architectures like ARM or MIPS. As you can see the separation was quite arbitrary, and often leaded to missing changes on the secondary architectures. We also got real stable branches, with regular fixes.

The most important EGLIBC features have been merged to GLIBC, including for example the use of non-bash but POSIX shell, or the renaming of reserved keywords. The notable exception is the support for configurable components, which we originally planned to use for Debian-Installer, by building a smaller flavor using -Os and without NIS and RPC support. At the end we never worked on that, and it seems that the hardware targeted by Debian has grown faster than the GLIBC size, so that is not really a big loss. At the end, we ended up with only 5 missing patches from the EGLIBC tree:

The package names are unchanged (except the source package and the binary package containing the sources) so the transition is fully transparent for the users.

I would like to thank all the CodeSourcery employees who worked on EGLIBC, with a special thank to Joseph Myers who spent countless hours to merge the most important EGLIBC changes back to GLIBC, and sent regular emails about the merge status. I would also like to thanks all the people on the GLIBC side that made the change to happen, and all persons participating in the GLIBC development.

On configure systems

aurel32 — Sun, 16 Feb 2014 15:52:00 +0100

I will never understand the point of using autotools, cmake or whatever configure system, when later the code uses an hardcoded list of architectures to determine the size of a pointer... Unfortunately for porters this pattern is quite common.

Update: As people keep asking, the way to check for the size of a given type is explained in the autoconf manual. To check for the size of the pointer, the following entry has to be added to configure.ac:

AC_CHECK_SIZEOF(void *)

On a 64-bit system, this will lead to the following entry in config.h:

/* The size of `void *', as computed by sizeof. */ #define SIZEOF_VOID_P 8

Debian QEMU images updated

aurel32 — Mon, 06 Jan 2014 20:46:00 +0100

Following the release of Debian Wheezy, I have (finally) updated my set of Debian QEMU images for both Squeeze (6.0.8) and Wheezy (7.3). The following images are now available:

amd64 (Squeeze and Wheezy)
armel (Squeeze and Wheezy)
armhf (Wheezy)
i386 (Squeeze and Wheezy)
mips (Squeeze and Wheezy)
mipsel (Squeeze and Wheezy)
powerpc (Squeeze and Wheezy)

Each of these directories contains a GPG signed README.txt file with the md5sums all files, detailed instructions how to run these images and especially the minimum QEMU version to use.

The requirements to run the default desktop environment have increased a lot between Squeeze and Wheezy. An accelerated graphics card is now needed to be able to use Gnome (unless you use the fallback mode), which is not something provided by QEMU (actually there is now a QXL para-virtualized video card, but the driver is only in unstable). In addition GDM now needs more than 128MiB to start, while this is the default amount of memory provided for virtual machines. I have therefore decided to switch the default desktop environment on the Wheezy images to Xfce and the display manager to LightDM. Both Gnome and GDM are still installed on the images, and the original default can easily be restored using the following commands:

update-alternatives --auto x-session-manager
echo /usr/sbin/gdm3 > /etc/X11/default-display-manager

Beside this the new images only contain minor changes. The filesystems have been tweaked to not run fsck after a certain amount of days, and locales-all and openssh-server are now installed in all images. For MIPS and MIPSEL, 64-bit kernels are now also installed and provided, so that it is possible to choose between a 32-bit or a 64-bit kernel (see the README.txt for more details).

There is no Debian Wheezy SPARC image available, as QEMU does not fully support SPARC64 yet (it is actually possible to run it, but then the VM crashes often), and Debian Wheezy now only supports 64-bit kernels. I will also invest time to build an S390X image, but so far I haven't been successful on that.

The following images are still available at the same location, though they haven't been updated:

sparc (Etch)
SH4 (Sid from a few years ago)

Detecting code issues using multiple architectures

aurel32 — Wed, 30 Oct 2013 00:37:00 +0100

Sometimes building the same code on multiple architectures is useful to detect horrors like:

ExEnv::err0() << sprintf("AtomInfo: invalid name: %s\n",name.c_str());

This code builds using -Werror=format-security with only a few warnings on most architectures, while GCC is correctly detects the issue on some others.

This has been reported as bug#728249.

How multiarch adds new RC bugs...

aurel32 — Sun, 03 Jun 2012 13:13:00 +0200

# dpkg --add-architecture kfreebsd-amd64
# dpkg -i libc0.1-dev_2.13-32_kfreebsd-amd64.deb
Selecting previously unselected package libc0.1-dev.
(Reading database ... 446113 files and directories currently installed.)
Unpacking libc0.1-dev (from libc0.1-dev_2.13-32_kfreebsd-amd64.deb) ...
dpkg: error processing libc0.1-dev_2.13-32_kfreebsd-amd64.deb (--install):
  trying to overwrite '/usr/include/_G_config.h', which is also in package libc6-dev 2.13-32
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
  libc0.1-dev_2.13-32_kfreebsd-amd64.deb

Before multiarch the bug was not existing, and of course none of libc6-dev and libc0.1-dev are marked as Multi-Arch: something. People wanting to delay the release of Wheezy, I am sure you can find much more RC bugs like that.

10 years ago...

aurel32 — Sun, 18 Mar 2012 21:52:00 +0100

Date: Mon, 18 Mar 2002 18:22:10 +0000
From: James Troup <troup@samosa.debian.org>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: da-manager@debian.org
Subject: New Debian maintainer Aurelien Jarno

[ This is a long (automatically-generated) mail, but it contains
   important information, please read it all carefully. ]

Dear Aurelien Jarno!

An account has been created for you on developer-accessible machines
with username 'aurel32'.  The password for this account can be found 
encrypted with your PGP or GPG key and appended to this message. A list 
of machines available to Debian developers can be found at
<URL:http://db.debian.org/machines.cgi>. Please take a minute now to
familiarize yourself with the Debian Machine Usage Policy, available
at <URL:http://www.debian.org/devel/dmup>

You have been subscribed to the debian-private mailing list as
<aurel32@debian.org>.  Please respect the privacy of that list and don't forward
mail from it elsewhere.  E-mail to <aurel32@debian.org> will be
forwarded to <aurelien@aurel32.net>.  To change this, please see
<URL:http://db.debian.org/forward.html> Also, please subscribe to 
debian-devel-announce, if you haven't done so already.

We strongly suggest that you use your aurel32@debian.org address for
the maintainer field in your packages, because that one will be valid
as long as you are a Debian developer, even if you change jobs, leave
university or change Internet Service providers.  If you do so, please
add that address to your PGP/GPG key(s) (using `gpg --edit-key "YOUR
USER ID"') and send it to the keyring server at keyring.debian.org
with `gpg --keyserver keyring.debian.org --send-keys "YOUR USER ID"'.

You can find more information useful to developers at
<URL:http://www.debian.org/devel/> (in particular, see the subsection
titled "Debian Developer's reference").

We suggest that you subscribe to debian-mentors@lists.debian.org.
This list is for new maintainers who seek help with initial packaging
and other developer-related issues.  Those who prefer one-on-one help
can also post to the list, and an experienced developer may volunteer
to help you.  You can get online help on IRC, too, if you join the
channel #debian-devel on irc.debian.org.  Take a look at the support
section on www.debian.org in order to find out more information.

You should have read these documents before working on your packages.

  o The Debian Social Contract
    <URL:http://www.debian.org/social_contract.html>

  o The Debian Policy Manual
    <URL:http://www.debian.org/doc/debian-policy/>

If you have some spare time and want to contribute it to Debian you
may wish to take a look at the "Work-Needing and Prospective Packages
for Debian GNU/Linux" also known as WNPP that can be found at
<URL:http://www.debian.org/devel/wnpp/>

If you plan to make a Debian package from a not yet packaged piece of
software you *must* announce your intention on the debian-devel mailing
list to make sure nobody else is working on them.

The machine ftp-master.debian.org is our main archive server.  Every 
uploaded package finds it's way there (except for Packages covered by US 
crypto laws which go to non-us.debian.org) eventually. master.debian.org is 
the home of our bug tracking system. Project web pages and CVS archives are 
hosted on klecker.debian.org (aka cvs/www.debian.org), klecker is also our
general shell server. Web pages should be placed in public_html on klecker 
and refered to by http://people.debian.org/~aurel32

You should use ssh to log into the machines instead of regular telnet
or rlogin. Our LDAP directory is able to share ssh RSA keys among machines,
please see <URL:http://db.debian.org/doc-mail.html> Otherwise when you
first login a ~/.ssh directory will be created with the appropriate
permissions. Please be aware of the security implications of using RSA
authentication and ssh agents.

Finally, please take a minute to visit <URL:http://db.debian.org/>. 
Login using the password information appended to this email, and 
update your personal information. The information is used to maintain 
your accounts on various Debian machines, and also to allow other 
developers and general users to find out more about you. Many of 
the fields are only visible to other registered Debian developers. This
is also the only way to change your password. The passwd program does not 
yet work.

Welcome to the project!

-- 
The Debian New Maintainer Team

Performances of open-source Radeon driver

aurel32 — Fri, 06 Jan 2012 01:27:00 +0100

I am the happy owner of a new netbook with an AMD Fusion E-450 APU, which includes a Radeon graphics card. I am using the open-source driver on it, that is a 3.2-rc7 kernel for KMS, and xserver-xorg-video-radeon package from sid. I have to say I am not really happy about the performances.

No I don't speak about the graphical performances that are pretty good (especially compared to my Intel Atom N450 based previous netbook) but about the power consumption. With this setup and with the original battery I get 2h30 of autonomy. Switching to UMS and adding some power management options in xorg.conf improves it to 2h40, but breaks suspend to ram/disk (a pity for a netbook) and switch between VT. I then tried the non-free fglrx driver, it also suffers from the suspend to ram/disk issue, in addition to crashing xorg when playing videos... On the other hand I get an impressive 3h30 of autonomy, and additionally a silent netbook (contrary to the open-source driver, the fan doesn't spin at idle).

I have tried plenty of options, ranging from adding some power management options to xorg.conf, to passing dynclks=1 to the radeon module, including setting /sys/class/drm/card0/device/power\_method to dynpm. Right now I have worked around the issue by buying a bigger battery which brings me 5h30 of autonomy, but I would really appreciate any software way to improve it with the open-source driver.

Debian s390x port (aka 31 bits is not enough)

aurel32 — Tue, 09 Aug 2011 23:45:00 +0200

During Debconf 11, I got access to a fast s390 machine, and I have started to work on a Debian s390x port, the 64-bit version of the s390 port. One of my goal was to help the SPARC64 port, as some of the issues are the same: both are 64-bit big-endian, don't support unaligned access and behave differently between -fpic and -fPIC.

Why such a port?

When talking about 64-bit ports, we usually hear: "4GB is enough, handling 64-bit takes more memory". This really sounds like "640K ought to be enough for anybody". The s390 port is actually 31-bit from the address point of view (one bit is reserved for address space extension from 24 to 31 bits), so each process is limited to 2GB only. Nowadays applications which need more than 2GB are not that uncommon, especially on mainframes. Actually the 2GB limit already causes some problem in Debian: in some cases it's not possible to build haskell applications or even C applications using GCC. On the other hand, we already require a 64-bit kernel on the s390 port (only the userland is 32-bit), and applications are handling more and more 64-bit or greater values (files offset, time counters, uid, etc.).

What is the status?

Bootstrapping the architecture was not really easy (as for any other new architectures), due to a huge amount of dependencies and build-dependencies loops, as explained by Wookey during Debconf11. Now that this part is mostly done, an autobuilder has been started and currently more than 65% of the packages are built. The s390x port is hosted on debian-ports.org. Unfortunately it is not yet deboostrapable, though that should happen in the next few days (only a few packages are missing).

The main issues are currently packages which fail to build from source due to linker, gcc-4.6 and curl changes, or due to the libjpeg and multiarch transitions, and thus are not directly related to s390x. If your package is in this case, it would be a good idea to fix it. Otherwise if it has a lot of reverse dependencies and the bug is opened for a while, just expect an NMU (as allowed by the 0-day NMU policy). Of course for a few packages s390x specific fixes are needed, some of them are already in the BTS.

How can you help?

The list of bugs blocking the s390x port is available through the s390x usertag, fixing these bugs (a lot of them are general FTBFS) would help a lot. Alternatively if you have access to an s390x machine you can take a look at the packages failing to build.

Update: Fixed the explanation about the 32th bit, thanks to Bastian Blank for the comment.

Debian and the ARM hype

aurel32 — Mon, 28 Jun 2010 21:04:00 +0200

Thanks to the versatility of the Linux kernel, Debian has always been known for supporting a large number of architectures. It has also often been criticized for that as it is said to slow down the development of Debian.

Among these architectures, the ARM one was considered dead a few years ago, and some people wanted to get rid of it. Today all major distributions now have an ARM port, one of those distributions being even based on Debian. It seems Debian was right.

Now that Android has been ported to MIPS, we may see more and more MIPS based devices. Will the same scenario happen again?

bindv6only=1 and GNU/kFreeBSD

aurel32 — Sun, 13 Jun 2010 01:01:00 +0200

A few months ago the netbase package started to install the /etc/sysctl.d/bindv6only.conf file to switch the default bindv6only value from 0 to 1.

A lot of people are not happy with this change, but it is not my goal to give my opinion here. On the other hand, people have propagated the rumour that it has been done as the FreeBSD kernel, used in the kfreebsd-amd64 and kfreebsd-i386 ports of Debian, only supports the mode corresponding to 1.

Let's give the truth:

GNU/kFreeBSD people haven't been contacted about this decision;
The FreeBSD kernel can support both modes through the net.inet6.ip6.v6only sysctl. However contrary to the Linux kernel it defaults to 1;
This option is available in the FreeBSD kernel since 2001, and in the Linux kernel since 2003.

EGLIBC and PowerPCSPE port

aurel32 — Tue, 25 May 2010 17:57:00 +0200

This has been roughly one year since Debian switched from GLIBC to EGLIBC, so it's probably the time to make a small report about this change.

First of all, on the GLIBC upstream side, things has improved a bit since we now have regular stable release, thanks to Petr Baudis aka Pasky. The good point is that the stable releases are imported into the EGLIBC stable repositories.

On the EGLIBC side the switch has helped to reduce the number of patches in the Debian package (for example, resolv.conf is automatically reloaded if needed), and has brought some bug fixes and improvements, especially for the arm, mips and powerpc targets.

It should be noted that the newly created PowerPCSPE port for PowerPC e500 series CPU also benefits from EGLIBC, as it is not natively supported by GLIBC.

Debian SH4 QEMU image available

aurel32 — Fri, 09 Apr 2010 13:58:00 +0200

Thanks to the great work of Nobuhiro Iwamatsu and others, Debian has an unofficial SH4 port which is close to complete (> 90% of the packages built).

In order to help developers to fix bugs on this architecture, I have produced an SH4 QEMU image which is available at the same location as my other QEMU images.

You will need a recent GIT HEAD QEMU to use it. Previous versions suffer from bugs in the MMU, causing segfaults and gratuitous TLB flushing. The MMU emulation is now hopefully correct, but still a bit slow. Also the emulated board is limited to 64 MB of memory, and this value can't be changed as memory extension would overlap the addresses used for peripherals.

Update: I have backported the necessary SH4 patches into the QEMU Debian package version 0.12.3+dfsg-4.

Squeeze will be released with eglibc 2.11

aurel32 — Sun, 07 Mar 2010 16:32:00 +0100

Contrary to what lucas announced (I don't know where he got this info), we plan to release Squeeze with eglibc 2.11. It is already packaged in experimental and is ready on all architectures except hppa where there are a few major regressions in the testsuite to fix. This is what prevent us to upload it to unstable.

Working on the eglibc package

aurel32 — Thu, 28 Jan 2010 00:00:00 +0100

In the last weeks, I stopped being motivated to work on the eglibc package, it's not fun as it was before. Maintaining this package is taking a lot of my (free) time, and I am not anymore able to follow the bug rate, especially for RC bugs or bugs that I consider high priority. In turn it does not give me time to integrate eglibc 2.11 or other wishlist features I would have liked to see (rework of the locales* packages, using multiarch paths, etc.).

I hope it's only a bad moment and that things will change soon, so I can find time to work on GNU/kFreeBSD, QEMU or to do electronics. In any case you can help by handling bug reports or writing patches. Everything is in the BTS!

Thought of the day

aurel32 — Thu, 12 Nov 2009 22:13:00 +0100

New features usually come with new versions. Before reporting a bug for a new feature, it may be a good idea to make sure you are using the latest version. apt-get can be really useful for that.

Learning IA-64 assembly

aurel32 — Sun, 02 Aug 2009 21:23:00 +0200

While testing EGLIBC 2.10.1 on all Debian architectures, I have discovered that the testsuite on IA-64 fails for the new POSIX 2008 math tests. I have reported the problem both upstream and on debian-ia64@lists.debian.org, but without success.

IA-64 being one of the last architecture (with HPPA) on which EGLIBC 2.10.1 fails to build from sources, I have decided to spend my day fixing the problem and digging into the corresponding IA-64 assembly code. The mathematical functions on this architecture are based on the Highly Optimized Mathematical Functions for the Intel® Itanium™ Architecture. Using the Intel® Itanium™ Architecture Software Developer's Manual and after a lot of tries, I have been able to add the missing code paths needed for POSIX 2008 compliance, and also fixed a few bugs on the stack frame allocation (arguments of the alloc instruction).

The resulting patch is now in the pkg-glibc SVN and in the upstream bugzilla.

And more important, I have learned the basic about IA-64 assembly!

Countries from where I have done a (E)GLIBC upload

aurel32 — Mon, 13 Jul 2009 01:22:00 +0200

If you want to see your country coloured on the map, you can invite me for my next holidays ;-).

New GPG key

aurel32 — Sun, 10 May 2009 23:24:00 +0200

pub   4096R/1DDD8C9B 2009-05-09
      Key fingerprint = 7746 2642 A9EF 94FD 0F77  196D BA9C 7806 1DDD 8C9B 
uid                  Aurelien Jarno <aurel32@debian.org>
uid                  Aurelien Jarno <aurelien@aurel32.net>
uid                  Aurelien Jarno <aurelien@jarno.fr>
sub   4096R/C3FCA1A8 2009-05-09

I'll get it signed by other Debian Developers tomorrow, during the Debian France meeting.

Debian is switching to EGLIBC

aurel32 — Tue, 05 May 2009 21:00:00 +0200

I have just uploaded Embedded GLIBC (EGLIBC) into the archive (it is currently waiting in the NEW queue), which will soon replace the GNU C Library (GLIBC).

The EGLIBC is a variant of the GLIBC which stays source and binary compatible with the original GLIBC. While primarily targeted for embedded architectures, it has some really nice points:

More friendly upstream (especially with regard to embedded architectures): "Encourage cooperation, communication, civility, and respect among developers" (as opposed to this).
Stable branch with fixes for important bugs (a real one, not like the GLIBC one which is left unchanged).
Better support for embedded architectures.
Support for different shells(GLIBC only supports bash).
Support for building with -Os.
Configurable components (do we really need NIS or RPC support in debian-installer?).
Better testsuite for optimized or biarch packages.

We do not use some of these features yet, but this upload is a first step. From the user point of view, the package names are unchanged (except the source package and the binary package containing the sources) so no transition is needed.

Debian QEMU images updated

aurel32 — Wed, 15 Apr 2009 12:37:00 +0200

Following the release of Debian Lenny, I have updated my set of Debian QEMU images. The following images are now available:

AMD64 (Etch and Lenny)
ARM (Etch and Lenny)
ARMEL (Lenny)
i386 (Etch and Lenny)
MIPS (Etch and Lenny)
MIPSEL (Etch and Lenny)
PowerPC (Etch and Lenny)
SPARC (Etch)

There is no Debian Lenny SPARC image available, as QEMU does not fully support SPARC64 yet, and Debian Lenny now only supports 64-bit kernels.

Note also that the README.txt files (which among other things contain the md5sums of the images) is now GPG signed. Read carefully these files as they contain details on how to use the images, and especially the minimum QEMU version to use.

Faster wireless access

aurel32 — Sat, 07 Feb 2009 18:06:00 +0100

The hotel we are staying in for FOSDEM is providing an expensive wireless access limited to 15kB/s.

For a faster access the solution is to use IP-over-DNS for a rate up to 48kB/s. Moreover it's free...

Re: emulated buildds

aurel32 — Mon, 19 Jan 2009 23:14:00 +0100

Wouter, I really doubt that the decision of having a Xen build daemon has been taken in a team, and the fact is that it's causing problems.

The only goal of my post is to show we have double standards.

Emulated versus paravirtualized build daemons

aurel32 — Mon, 19 Jan 2009 20:41:00 +0100

There has been a few flam\^Wdiscussions about emulated build daemons, each time coming to the conclusion that we should not upload packages built on an emulated machine to the archive.

However Debian has started to use at least one paravirtualized (Xen) build daemon, the i386 experimental one. The result is that one of the tests of the GNU libc testsuite is failing. On the other hand, the GNU libc and the GCC testsuites are giving the same results on a QEMU emulated machine and a real machine, for amd64, arm, armel, i386, mips, mipsel and powerpc. Same for KVM on amd64 and i386.

I wonder if we made the right choice ...

QEMU PowerPC

aurel32 — Thu, 15 Jan 2009 00:04:00 +0100

For a few weeks Laurent Vivier, Blue Swirl and myself have been working on getting QEMU PowerPC working correctly with recent distributions.

QEMU used to rely on OpenHackWare for the OpenFirmware implementation on PowerPC. It is a very limited implementation (for example it as no Forth support), which is unable to boot most 2.6.x kernels with the OldWorld emulation. It is able to boot recent kernels with the PReP emulation, but things like the PCI bus emulation are not working correctly. Moreover the PReP kernels are gone with the removal of the arch/ppc tree.

OpenBIOS was already used for the OpenFirmware implementation of Sparc 32 and Sparc 64 targets. It now supports PowerPC for the OldWorld emulation. As a result it is now possible to use Debian PowerPC under QEMU emulating an OldWorld machine.

What works?

Display (partly), keyboard, hard disk, network;
Booting from CD-ROM or from disk using Quik;
Installation of Debian Etch or Lenny (but due to a bug in debian-installer quik.conf has to be fixed manually);
Standard Debian kernels;
G3 CPU emulation: the testsuite results of the GNU libc 2.7 and of GCC 4.3 (Debian packages) are the same than on a real machine.
virtio devices

What doesn't work / has to be done?

A few devices part of the MacIO chipset are not emulated and/or are replaced by other devices: IDE, SCSI, Ethernet and sound;
The red and green colors are reversed, in some modes only (in debian-installer for example);
X only outputs some strange images;
PCI devices using I/O ports don't work (like the RTL8029 card, or the RTL8139 card with the 8139too driver).

For those who want to test, an Etch image is available. You will need to compile QEMU by manually given that the version in Debian is too old and that openbios-ppc is still in the NEW queue.

Dr Jarno

aurel32 — Fri, 11 Jul 2008 22:40:00 +0200

As already announced by Julien Blache, I successfully passed my PhD defense today, and I am now a doctor.

During my PhD, I designed and implemented an optical simulator for the MUSE instrument, an integral field spectrograph which will be installed on one of the large European telescopes of the VLT.

Flight booked (aka crazy prices)

aurel32 — Thu, 12 Jun 2008 23:18:00 +0200

As I am one of those who have read "able" instead of "unable", I had to find a really cheap flight. This may sound crazy, but an Iberia flight to Buenos Aires from Berlin costs far less than from Lyon (where I live) or even from Madrid: 781.12 EUR from Berlin instead over 1,200.00 EUR from Madrid and over 1,300.00 EUR from Lyon (in both cases with a change in Madrid Barajas).

I wonder if Iberia pays you 420,00 EUR if you flight from Berlin to Madrid...

Now I have to find a cheap way to go to Berlin from Lyon (probably an EasyJet flight). I plan to spend a few days of holiday in Berlin before flying to Argentina.

IPsec, MTU & NAT

aurel32 — Mon, 09 Jun 2008 16:26:00 +0200

Dear lazyweb, I encounter MTU problems with an IPsec setup and NAT.

Here is a simplified version of my setup:

remote host < --- internet ---> (eth0) gateway (eth1) < --- LAN

As you may have guess, the gateway has only one public IP address and thus the hosts on the LAN are connected to the internet through NAT.

The connection between the remote host and the gateway is secured using IPsec (kame tools), and this works as expected as long, as the connection is done between the remote host and the gateway. The problems arise when I try to make a connection between the remote host and one host from the LAN. Due to the use of IPsec, the MTU is reduced by 44 bytes, however "ICMP need to frag" packets are not emitted by the gateway, so the connection just hangs.

I have tried various solution from the web (setting MTU on the various interfaces, clamping MSS with iptables, defining advmss with ip route, etc.), and the only one which actually works is reducing the MTU on the LAN hosts. Not very useable given that they are a lot of hosts on the LAN.

Note that when IPsec is disabled, if I lower the MTU of eth0, the "ICMP need to frag" packets are correctly emitted, and the connection just works.

Suggestions?

PhD report submitted

aurel32 — Wed, 21 May 2008 13:45:00 +0200

Some of you may have noticed that I was mostly unavailable those last weeks. I was finishing writing my PhD report. It is now submitted, so I have more free time again.

I am currently processing the backlog. If you are waiting for an action from my side, you should get some news in the next few days.

MAC address strangeness

aurel32 — Mon, 17 Mar 2008 20:58:00 +0100

Today I upgraded my BIOS in the hope to solve various issues. When I rebooted the machine, it didn't get an IP address through DHCP: the Ethernet MAC address has been changed by the BIOS upgrade.

Now compare the old and the new Ethernet MAC addresses:

old address: 0:1a:4d:60:72:e0
new address: e0:72:60:4d:1a:0

Time to laugh...

New GNU/kFreeBSD build daemon

aurel32 — Tue, 31 Jul 2007 17:28:00 +0200

We now have a second GNU/kFreeBSD build daemon building the kfreebsd-amd64 architecture. It has been kindly offered and is hosted in UK by The Positive Internet Company Ltd.

It adds redundancy to our buildd network, which is important given that the other kfreebsd-amd64 build daemon machine is on a simple ADSL line, and so less reliable than a machine in a datacenter.

For those who want to know more, here is the current status of the GNU/kFreeBSD buildd network:

callisto.debian.net (kfreebsd-amd64)
2 x Opteron 1.4GHZ, 1GB RAM
Hosted by The Positive Internet Company
shockley.aurel32.net (kfreebsd-amd64)
Sempron 2600+, 1GB RAM
Hosted by Aurelien Jarno (ADSL)
hagrid.debian.net (kfreebsd-i386)
PIII 800 MHz, 512MB RAM
Hosted by ETH Zürich
maxwell.aurel32.net (kfreebsd-i386)
Sempron 2600+, 1GB RAM
Hosted by Aurelien Jarno (ADSL)

My goal is to eventually get rid of all build daemons that I am hosting at home on my ADSL line, though that is less critical now.

ARM code of the day

aurel32 — Thu, 03 May 2007 14:45:00 +0200

ldmeqib r9!, {r1, r8, ip}^
ldclsl 3, cr14, [r4, #-364]!
stmleda r1, {r0, r2, r6, r7, r9, sl, ip, lr}^
cmpp lr6, #12582912

This program does not work, but it still has a meaning.

Hint: Each instruction is 32-bit long, the total length is 128 bits.

94.4%

aurel32 — Sun, 25 Feb 2007 19:20:00 +0100

Christian, this is the percentage of your blog entries concerning translation ratios in the last two weeks.

I am sure you can do better ;-)

New ARM autobuilders

aurel32 — Sun, 17 Dec 2006 19:50:00 +0100

I am really upset by the way the ARM build daemons are managed. The packages are not uploaded regularly, with sometimes three days between two uploads. Well it should not be a problem, if packages that have failed to build due to some packages not uploaded fast enough (see for example python-gnome, or rkward) were requeued, but that's actually not the case. Also last week, the build daemon named "cats" stopped to upload packages, despite it continued to build them. 11 days later, nothing has changed even after a mail to arm@buildd.debian.org. And I do not speak about build daemons building nothing.

All of that resulted in ARM being the slowest architecture to build packages. It looks like the ARM build daemon maintainer does not know the excellent page made by Jeroen.

As arm@buildd.debian.org is everything but responsive (well if you can assign a level of responsiveness to /dev/null), I have decided to act. I have installed QEMU on an 8-way Opteron machine, and created 8 emulated ARM machines, which 256MB of RAM and 10GB of disk for each, all running buildd + sbuild. Altogether those 8 emulated ARM machines should be faster than all the Debian ARM build daemons. I have setup a wanna-build database on my server. During the day it has built around 100 packages.

Yes I agree that real machines would be better, but I don't have a stack of fast ARM machines at home. Anyway when you see random segfaults on the build daemons, or strange failures (that happen for weeks) on the build daemon named "netwinder", you may think to that again.

Unfortunately the machine I use for that is only available for a few months, and I will have to stop the emulated machine then. I just hope that the situation with respect to the build daemons will improve, so that I can stop them even before.

NEW queue almost empty

aurel32 — Sun, 19 Nov 2006 21:04:00 +0100

The NEW queue is almost empty with 7 packages only. Thanks a lot Joerg.

Cheap MIPS/MIPSEL development machine

aurel32 — Mon, 13 Nov 2006 18:27:00 +0100

In addition to the ARM platform, it is now possible to emulate a MIPS (big endian) or MIPSEL (little endian) machine running Debian under QEMU. It could be used as a cheap MIPS/MIPSEL development machine to test your packages, provided that you have a not to slow i386, AMD64 or PowerPC computer.

Running on an Athlon 64 X2 3800+ the emulated system is around 10% faster than my SGI Indy R4400SC 200MHz and possibly with much more RAM (my emulated system has 512 MB of RAM). Also for the ones who know about the Indy SCSI controller, the transfer rate is around 13 MB/s on the emulated system.

I have written a small howto explaining how to install Debian Etch on such an emulated MIPS or MIPSEL machine, using Debian-Installer RC1, which has just been released.

Thanks to Daniel Jacobowitz who has recently improved QEMU/MIPS a lot, and to Thiemo Seufer who has started the integration of the MIPS QEMU platform in Debian-Installer and in the Debian kernel.

Note 1: I have written this howto very quickly, so there are probably some mistakes. Comments are welcome.
Note 2: I have updated the ARM howto to take in account improvements from Debian-Installer RC1

Experimental is not autobuilt (at least for glibc)

aurel32 — Sat, 11 Nov 2006 23:57:00 +0100

Martin, I can't let you say that experimental is autobuilt. I have uploaded a few versions of the glibc to experimental in the last few months and only arm, hppa and alpha have tried to build them. Before the summer mips and mipsel also have tried to build the experimental glibc. And the last version has not been tried on alpha, despite the fact it includes a fix and should now build correctly on this architecture.

Hopefully I have most Debian architectures at home, but alpha, m68k and ia64, so I can build the glibc on my own machines. For m68k and ia64, I can use debian.org machines. Concerning alpha, the debian porting machine, ie escher.debian.org, is locked down since the compromise about 4 months ago. And no answer to my mail to debian-admin... Hopefully a user kindly gave me an access on his machine, thanks. The glibc 2.5 is now building correctly on this machine, but I can't upload the package because I can't trust the machine. That really sucks.

What about removing alpha from the release architectures? After all, it fails to comply with the etch candidate release architecture criteria for months.

Update: Some build daemons had glibc in "weak-no-autobuild". Thanks Martin for fixing that.

Cheap ARM development machine

aurel32 — Mon, 25 Sep 2006 22:46:00 +0200

You want a cheap ARM development machine to test your packages? You can actually have one for free (both as in beer and as in speach :)) provided that you have a not to slow i386, AMD64 or PowerPC computer. The solution is called QEMU, a generic and open source processor emulator which can emulate i386, x86_64, ARM, MIPS, PowerPC and Sparc systems.

Running an Athlon 64 3800+ the emulated system is around 20% faster than the popular NSLU2 and possibly with much more RAM (my emulated system has 256 MB of RAM).

I have written a small howto explaining how to install Debian Etch on such an emulated ARM machine.

Note: I have written this howto very quickly, so there are probably some mistakes. Comments are welcome.

How Ubuntu is slowing down Debian

aurel32 — Wed, 19 Jul 2006 19:17:00 +0200

Today in bug report #369411:

"I do oppose an NMU as you haven't actually explained why this patch is
necessary. Ubuntu doesn't have this patch and yet has been building
32-bit alsa for several releases without problems."

While Ubuntu has this patch included for 3 weeks now. I have written this patch to fix an RC bug in Debian...

FOSDEM slides up

aurel32 — Mon, 20 Mar 2006 11:31:00 +0100

I gave a talk about Debian GNU/kFreeBSD at FOSDEM 2006. It tooks me time, but I finally have made the slides available.

kfreebsd-amd64 build daemon

aurel32 — Sun, 05 Mar 2006 03:52:00 +0100

Yesterday I have setup a kfreebsd-amd64 (ie GNU/kFreeBSD on an amd64 CPU) build daemon. Its name is shockley.aurel32.net (all my machines are named related to electronics), and it has Sempron 2600+ CPU.

As you can see on the photo, it is still missing a decent case. There are actually two machines on the the photo, the motherboard in the case is maxwell's one (one of the kfreebsd-i386 build daemon), while the one on the top front is shockley's one. That's a bit strange, but the amd64 motherboard needs a power supply with a P4 connector, while the other one only needs a small power supply.

Thanks to Ingo Juergensmann, the kfreebsd-amd64 architecture is now listed on http://buildd.net. As you can see on the graph, this machine is very fast (it only runs for 24 hours!).

GNU/kFreeBSD on http://buildd.net

aurel32 — Sat, 17 Sep 2005 23:21:00 +0200

Thanks to Ingo Juergensmann, the kfreebsd-i386 architecture is now listed on http://buildd.net. That means that Debian developers can now easily check the state of their packages, and if they fail to build, to find why.

The requirement to appear on http://buildd.net was to use wanna-build and make its output available somewhere on the web. As I was still using a set of (very) ugly shells scripts to handle the build-daemon, I spent a part of the last days to setup wanna-build, and to understand how it works. With wanna-build a lot of thing is automatic, and almost everything could be controled via the mail interface. That would save me some time that I could invest in porting packages to GNU/kFreeBSD.

Debian GNU/kFreeBSD developer accessible machine

aurel32 — Sat, 06 Aug 2005 07:46:00 +0200

The machine on the photo below is currently somewhere between France and Switzerland. It runs Debian GNU/kFreeBSD, and will be accessible to all Debian developers. Thanks to Gürkan Sengün, the ETH Zürich will host it.

Debian GNU/kFreeBSD build daemon upgraded

aurel32 — Sun, 24 Jul 2005 01:37:00 +0200

I am running a build daemon for the Debian GNU/kFreeBSD port. It was a bit overloaded by the high number of packages to build since the CXX ABI transition has begun. I decided to use the old mainboard of my main computer to upgrade it from an AMD K6-2 500 to an Athlon XP 1800+. I also had to buy a new box since the old mainboard was an AT one, whereas this mainboard is an ATX one. The hard disks (an old 8.4 GB IDE disk for the system and an old 4.3 GB SCSI disk for the build daemon stuff) are still a bit slow, that is probably the next thing I'll upgrade.

It runs for a few hours now and has already reduced the backlog. Currently 83% of the Debian packages are built for the kfreebsd-i386 architecture.

New mainboard and new CPU

aurel32 — Sun, 24 Jul 2005 00:51:00 +0200

I have just upgraded my main computer with a new motherboard and a new CPU. It now has and Athlon 64 3000+ CPU, it is a lot faster than my old Athlon XP 1800+.

I have four SATA disks in a software RAID 5 array, and with my old mainboard the SATA controllers were on two PCI cards. The PCI bus was limiting the maximum transfer rate to about 60 MB/s. My new mainboard has an NForce 3 chipset, which has two SATA controllers connected directly to the HyperTransport bus, so that I can reach 158 MB/s. That's a great improvement!

I have a total of 5 hard-disks, 1 DVD-ROM drive and 1 DVD-RW drive resulting in a lot of cables and a big mess in the mini-tower box, as it could be seen on the photo below. Hopefully I now have less PCI cards as the soundcard, the SATA controllers and the ethernets controllers are now integrated on the mainboard.

Now that the hardware is setup, I'll have to look at the software, as my computer is still running in 32-bit mode.

Strange keyboard

aurel32 — Thu, 14 Jul 2005 16:43:00 +0200

Sam has got a laptop with a very strange keyboard. Have a look:

No, it's not a DVORAK one.

Actually he explained me he tried to convert the QWERTY keyboard into a DVORAK one, but some of the keys can not be swapped because of the trackpoint. And he is using it as a QWERTY keyboard.

Hardware problems

aurel32 — Sat, 09 Jul 2005 19:44:00 +0200

I have got two hardware problems today.

First my UPS died, leaving my servers at home as well as my ADSL modem without any power. The bad thing is that I am not at home, but in Helsinki for Debconf 5, so I had to managed to get it replaced by simple wires, by phone. That was not that easy, because the person that did the changes (thanks a lot Dominique) hasn't my keys, and thus have to get it first.

The second problem I got today concerns my laptop. It seems the memory has not supported the flight to Helsinki, and I had to remove half of it :-(

Is Debian still the universal OS?

aurel32 — Tue, 15 Mar 2005 00:54:00 +0100

As others I am very unhappy with the outcome of the release meeting. This "proposal" has been made by people that have key responsabilities in Debian, and without asking other people, except the DPL candidates. By the way, I feel silly that such persons sign this "proposal" as DPL candidates, whatever is their opinion.

In short the proposal says: "We've got problems to release with 11 architectures, let's drop 8 of them." A lot of users who choose Debian because it was the only distribution out of there to provide serious support for the architectures they care for, for various reasons. That's the end of the Universal OS, and that's sad.

It's seems that the actual teams found they are overloaded, so as they don't want to share their powers and call for help (even worse, they refuse help), they prefer to drop architectures.

The criteria given to keep architectures seems to have been choosen after the list of architectures itself. And actually none of the architectures in Debian fulfill them (all the four proposed architectures, i.e. i386, ppc, amd64 and ia64, only have one build daemon). And when you ask the technical point behind each criterion, nobody answers...

I don't say there isn't any problems, but there is a difference between a reasonable answer to these problems, and dropping most of architectures we support. If they are problems with build daemons, the solution is to solve them (hint: more build daemons and more admins would be a good start).

But actually I doubt the number of architectures is the real problem for Sarge. One of the main problems since August (at least that is what is announced in every "Bits from the release manager"), is the testing build daemons. Why it lasts so long? Why offers for help have been refused?

And don't forget the social contract: "Our priorities are our users and free software"

simulpic: new upstream version for more than 8 years!

aurel32 — Fri, 28 Jan 2005 15:44:00 +0100

I have just uploaded a new version of simulpic. This software is a simulator for Microchip PIC16F84 microcontrollers. The initial version was a student project of the University of Pisa, and the development has stopped 8 years ago. Well, not really stopped as they were some patches in the Debian package.

Recently, a new upstream has decided to continue this project and to add some functionalities. He has just released a new version, the first one for more than 8 years! That demonstrates the power of Free Software.

High server load

aurel32 — Mon, 24 Jan 2005 19:41:00 +0100

During the last few days, I experienced a high load on my server (sometimes up to 15). Each time it happens, I observed that apache was unable to serve pages. Restarting it regularly seemed to fix the problem.

Yesterday, I started to investigate the problem. Actually it was "referer spam". The stats of my blog are generated with webdruid and are available on http://blog.aurel32.net/stats/ . Some spammers tried to increase their website's page rank by submitting spoofed referers. It seems that they use zombie hosts, as the requests come from many IPs. The bad thing is that the hosts don't close the TCP connections, causing a lot of apache processes to be unable to serve pages. It's like a DoS, though this was not the aim.

A search on Google gave me a way to stop that. I added the following lines to /etc/wordpress/htaccess:

RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://www.spammersite1.com [OR]
RewriteCond %{HTTP_REFERER} ^http://www.spammersite2.com
RewriteRule .* - [F,L]

The load started to go down. Good! I also added a robots.txt, so that the stats pages are not indexed anymore by the search engines (note to the wordpress maintainer: it would be nice to have a /etc/wordpress/robots.txt).

After a day, I grepped the apache logs to find all the zombies IPs, and I blacklisted all of them on my firewall with iptables, ie. 217 IPs!

This event reminds me that my server doesn't have enough RAM and that I should add some more.

Do some kind of greylisting on Debian bugs?

aurel32 — Tue, 11 Jan 2005 19:45:00 +0100

Over the last few months, it seems that the number of silly bugs is increasing. Of course, in most of the cases, the severity of such silly bugs is set to critical. I won't list all that silly bugs (it would take too long :) ), but I'll take two examples, that are very recent as they occured today yesterday.

The first one is the bug #289666 titled "sane only work as root on 2.6.10 (2.6.*)". The bug reporter explains that the module scanner.o has been removed from the kernel and thus he, and all other users, should use the root account to scan a document. He think it is a critical security bug. I don't know why Julien Blache wrote a README to explain how to be able to scan as user! The command is very simple: adduser user scanner.

The second annoying bug was filled today on OpenOffice.org. It is bug #289800 and is titled "openoffice.org: please enable autosave per default". Basically, the user was writting a text on OpenOffice.org, and its machine crashed. As he hasn't saved the document, and as autosave was not enabled, he lost it. Surely not a critical bug. Maybe the user should learn all to click on the save icon instead of sending bug reports!

Maybe we should do something to avoid these annoying bugs. A kind of greylisting, which first sends back an email to the bug reporters (asking them if they have read the documentation, if they have verified that the bug has not been already reported, if they are using the latest version) and then that waits for a key contained in the email to be returned to validate the bug. This could also avoid people using invalid email addresses.

Yes, such a system looks like a bit silly... just as some of the bug reporters.

Back on the Internet

aurel32 — Tue, 30 Nov 2004 18:07:00 +0100

My ADSL line was opened yesterday, so I am back on the Internet! Actually during the last two months, I still had an Internet connection, but only though a 56k modem, not really useable for maintaining Debian packages or for doing an "apt-get upgrade" on my machines (and a bit costly).

I am in my apartment for a month, and it tooks two weeks to get the invoice of my telephone line, one more week to get the ADSL line and one more week to get my modem from the post.

The connection is an ADSL2+ connection, so there is enough upload rate to be able to host websites. I moved all my websites to my home server, and I am just waiting the activation of the reverse DNS to be able to host an SMTP server.

US presidential elections

aurel32 — Wed, 03 Nov 2004 19:10:00 +0100

John Kerry has just called George Bush to congratulated him. As most European people I am disappointed by the result of the elections.

But maybe the question is why US elections is so important for European people. Maybe Europe is not enough united to be an alternative to the US power...

My new apartment

aurel32 — Wed, 03 Nov 2004 19:06:00 +0100

Yesterday I moved to my new apartement. Moving was not really easy as it was running cats and dogs. The apartement now looks a bit empty, as I currently only have a camping mattress, a sleeping bad, a few clothing, without forgetting my computers... I need to buy a mattress, a fridge, solid plates, etc.

In the next few days, I'll have to open a telephone line, with an ADSL connection. I hope it wouldn't take too much time, as it's not very easy to only have an Internet access at work. That's why I am not so active into Debian by now, though I am still reading my mails and uploading packages.

Switching to kernel 2.6 (part 2)

aurel32 — Tue, 28 Sep 2004 22:33:00 +0200

Yesterday I switched all of my machines but one to kernel 2.6. The last one to migrate is a SparcStation 4. It is a little bit complicated as the BIOS refuse to recognize my hard-drive since I changed it from a 2.1GB one to a 9.1GB. After an afternoon of tests, I decided to boot this workstation via the network, as the Linux kernel recognizes it.

Using a 2.4 kernel was very easy, you just have to convert the Debian kernel in aout format using zcat and elftoaout. For a 2.6 kernel, it is a little more complicated as Debian ships them with an initrd image. After a few minutes searching google, I found the solution:

zcat /boot/vmlinuz > vmlinux
elftoaout -o netboot.img vmlinux piggyback netboot.img /boot/System.map /boot/initrd.img

It seems to work well, however the image is 271,654,944 bytes long. I still don't understand why.

My firewall

aurel32 — Tue, 28 Sep 2004 22:03:00 +0200

In my latest post (Switching to kernel 2.6), I spoke quickly about my firewall. In the comments, I was asked for information about it. So I decided to write a new post.

My firewall is based on a micro-ATX PIII mainboard with an Intel Celeron 600. I know that it is too much for my use (the load is almost always 0), however I already had the mainboard. This processor is one of the slowest processor that the mainboard accepts (the lowest speed is 500 MHz). Anyway that kind of processor is a good choice for such a computer, as it is one of the first processor using a 0.18µm technology, thus it doesn't need a lot of power (for an x86). Using an Aqua 690 heatsink it can run without a fan.

This mainboard has an integrated Ethernet adapter, and 3 PCI ports. I chose to use them to plug three Ethernet adapters, that is to say a total of four. Currently three of them are setup in bridge, but I can later un-bridge one or more ports if I need. It could be useful to plug a WiFi access point, or to create a DMZ for my servers (just for the fun as I am the only user of my LAN).

Instead of using an hard-drive, that makes noise and heat, I chose to use a 256MB Compact Flash instead. I made a CF/IDE adapter using the article published in Elektor (April 2002 for the French edition). It is now possible to find such an adapter in some webshops.

I packed all that stuff in a metal box, with a 120W Shuttle Power Supply. The longest part was to machine the metal, with a drilling machine and a file in my case.

On the software side, this firewall is running Debian, with two scripts of my own using iptables: one for IPv4 and one for IPv6. 256 MB is enough for that and some useful packages (ADSL modem drivers, radvd, ping, traceroute, tcpdump, ethstatus, lm-sensors, snmpd, ntp, logcheck, etc.).

Below is a photo of the inside (sorry for the poor quality, I took it with my webcam as I still don't have a digital still camera):

You can see a fan grille on the front, however there is no fan behind it. I removed it as it was making noise, and was not really necessary. Concerning the processor's fan, I control it using lm-sensors, and it is almost always off, resulting in a very silent firewall.

I used the same box for my servers, however they are using an hard-drive. It is possible to put up to two hard-drives (useful for RAID1) in a such box, if you are using low profile RAM.

Switching to kernel 2.6

aurel32 — Tue, 28 Sep 2004 00:14:00 +0200

I decided to switch all my machines to kernel 2.6. I now consider the kernel 2.6 stable enough, at least for the use of my machines. Except for my workstation on which I like to add some patches, I am using Debian kernels for my other machines. Moreover some of them are very slow (a parisc@60 MHz and a sparc@110 MHz), and building a kernel on such machines takes very long time.

I started with my a backup server, it was very easy, apt-get install and voilà!

Then I switched my firewall. It was not so easy as for my backup server, as I only have a 256 MB disk (actually a compact flash card). Because of its size, it was not possible to have two kernels at the same time on the disk. I decided to remove the old 2.4 kernel (/boot and /lib/modules), to install the new 2.6 kernel. Then I typed reboot, and started to pray. As I don't have neither a display nor a keyboard on that machine, I started to look both at the hard disk's LED and at a console on my workstation on which I started ping fourier. After a some time (I don't know exactly how much, in such situations seconds are like minutes), there was some echo reply. Wonderful!

After such successes, I decided to continue and to switch my hppa machine. Again apt-get, then a quick look at the palo's documentation to know how to specify an initrd image, and then reboot. After a lot of time, it was still not possible to ping the machine. Shit! PALO has the possibilty to specify an alternate kernel in case of a problem, however in that case it seems it has failed... or the boot was mabe successfull. Half an hour later, after I plugged a screen, a keyboard and a null-modem serial cable, I understood the problem: the module for the network card was not loaded (whereas it was directly binded into the 2.4 kernel). And hotplug doesn't load it as it is not on a PCI bus. I tooked my keyboard and started to write my login. Nothing. The keyboard's module was also not loaded. I switched back to the 2.4 kernel, I put a lot of modules into /etc/modules (network card, keyboard, mouse, sound card, parallel port, serial port, etc.). And it worked!

Moral: Don't change your kernel when you only have very few time to do that. It always take a lot longer than expected.

Finding a flat

aurel32 — Thu, 16 Sep 2004 00:20:00 +0200

On monday, I received a phone call to tell me that I am accepted at the Centre de Recherche Astronomique de Lyon to do a PhD. I will begin it the 1st of October.

I am currently living at my parents' house, which is located in Toulouse, so I have to find a flat very quickly. I'll take the train to Lyon tomorrow, and I hope my search will be successfull.

Fixing gcc-m68h1cx

aurel32 — Sun, 12 Sep 2004 00:46:00 +0200

Today, I spent all the day fixing gcc-m68hc1x. It is gcc built for cross-compiling to 68HC11 and 68HC12 microcontrollers. There was a strange bug: an ICE on 64-bit hosts. Actually the bug was there for a long time, but I had decided that the version currently in testing will be enough. However, yesterday a bug was filled as a package need to build it was not available anymore in testing.

So I started to try to debug it. It was the first time I was looking at gcc's sources. Whow! I didn't know were to start to find the bug. I asked on IRC on #gcc, but people were no encouraging me: "aurel32, that bug is not easy to tackle for newbies". I first reduced the file causing the ICE to a single line in a function, I added a lot of printf in gcc's sources, and then tried to compile the same testcase both on a 32-bit host and a 64-bit host. At the end of the day I found some differences, and with that, the bug!

As the ICE was triggered by the build of libgcc2, gcc-m68hc1x was unbuildable on 64-bit hosts. Now that this bug is fixed, it means one RC bug less.

And in short for any people writing code: please don't assume that a 64-bit number needs two int to be represented!

First post

aurel32 — Sun, 12 Sep 2004 00:28:00 +0200

With this first post, I hereby declare this weblog open!