Debian QEMU images updated

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:

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

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 onmost architectures, while GCC is correctly detects the issue on some others.

This has been reported as bug#728249.

How multiarch adds new RC bugs...

# 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:

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...

Date: Mon, 18 Mar 2002 18:22:10 +0000
From: James Troup <>
To: Aurelien Jarno <>
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:>. Please take a minute now to
familiarize yourself with the Debian Machine Usage Policy, available
at <URL:>

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

We strongly suggest that you use your 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
with `gpg --keyserver --send-keys "YOUR USER ID"'.

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

We suggest that you subscribe to
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  Take a look at the support
section on in order to find out more information.

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

  o The Debian Social Contract

  o The Debian Policy Manual

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

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 is our main archive server.  Every 
uploaded package finds it's way there (except for Packages covered by US 
crypto laws which go to eventually. is 
the home of our bug tracking system. Project web pages and CVS archives are 
hosted on (aka cvs/, klecker is also our
general shell server. Web pages should be placed in public_html on klecker 
and refered to by

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:> 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:>. 
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

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)

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 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

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

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

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

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.