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.
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:
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.
Following the release of Debian Lenny, I have updated my set of Debian QEMU images. The following images are now available:
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 ...
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.
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.
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.
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.
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?