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.
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!
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.
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 firstname.lastname@example.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
And more important, I have learned the basic about IA-64 assembly!
pub 4096R/1DDD8C9B 2009-05-09 Key fingerprint = 7746 2642 A9EF 94FD 0F77 196D BA9C 7806 1DDD 8C9B uid Aurelien Jarno <email@example.com> uid Aurelien Jarno <firstname.lastname@example.org> uid Aurelien Jarno <email@example.com> sub 4096R/C3FCA1A8 2009-05-09
I’ll get it signed by other Debian Developers tomorrow, during the Debian France meeting.
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.
- 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.
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…
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.
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 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.
- 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).
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.
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
Sempron 2600+, 1GB RAM
Hosted by Aurelien Jarno (ADSL)
PIII 800 MHz, 512MB RAM
Hosted by ETH Zürich
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.