With all the discussion about SHA-1 weaknesses and generation of new OpenPGP keys going on there's some concern about how the web of trust will be affected. I'm particularly interested in the impact on Debian; while it's possible to add new keys and keep the old ones around that hasn't worked so well for us with the migration away from PGPv3 keys. We still have 125 v3 keys left, many of them for users who also have a v4 key but haven't asked for the v3 key to be removed or responded to my email prodding them about it. I don't want to repeat that.

So if we're looking at key replacement we need to have some idea about where our Web of Trust currently stands, and what effect various changes might have on it. I managed to find the keyrings Debian shipped all the way back to slink and ran the keyanalyze and cwot stats against them. I then took the current keyring, pull in all the updates for the keys in it (so that any signatures from newly generated keys would be included) and ran the stats again. Finally I took details of 12 key migrations (mostly from Debian Planet but also a couple of others I knew about) and calculated what the effect of removing each key would be. These stats are cumulative and I replaced the most well connected (by centrality) keys first.

The results are below.

• Total is the total number of keys in the keyring
• SCS is the largest Strongly Connected Subset
• Reachable is the largest reachable subset
• MSD is the Mean Shortest Distance
• Centrality is the average centrality for the reachable subset
• update-foo indicates that foo's key was replaced with a newer one

	Total	SCS		Reachable		MSD	Centrality
1999-02-06 (slink)	228	36	(15.78%)	50	(21.92%)	2.9022
2000-01-03 (potato)	375	104	(27.73%)	180	(48.00%)	4.3382
2001-09-22 (woody)	948	538	(56.75%)	704	(74.26%)	4.7320	2008.6249
2005-05-28 (sarge/etch)	1106	883	(79.83%)	969	(87.61%)	3.3485	2074.6604
2007-12-04	1191	1001	(84.04%)	1062	(89.16%)	3.1103	2113.3747
2009-01-18 (lenny)	1126	947	(84.10%)	1010	(89.69%)	3.0489	1941.2594
2009-04-04 (squeeze/sid)	1121	946	(84.38%)	1008	(89.91%)	3.0466	1936.9761
2009-05-06 (current)	1067	894	(83.78%)	958	(89.78%)	2.9670	1759.4363
	Total	SCS		Reachable		MSD	Centrality
base	1067	904	(84.72%)	959	(89.87%)	2.9640	1776.4389
update-93sam	1067	902	(84.53%)	958	(89.78%)	2.9734	1780.9874
update-joerg	1067	900	(84.34%)	958	(89.78%)	2.9776	1780.7578
update-aurel32	1067	898	(84.16%)	957	(89.69%)	2.9803	1779.2497
update-noodles	1067	896	(83.97%)	956	(89.59%)	2.9831	1777.8326
update-jaldhar	1067	896	(83.97%)	955	(89.50%)	2.9855	1779.9193
update-srivasta	1067	896	(83.97%)	955	(89.50%)	2.9904	1784.3382
update-ana	1067	895	(83.88%)	954	(89.40%)	2.9926	1784.3102
update-nobse	1067	893	(83.69%)	953	(89.31%)	2.9947	1782.2392
update-neilm	1067	892	(83.59%)	951	(89.12%)	2.9974	1782.6098
update-reg	1067	891	(83.50%)	950	(89.03%)	2.9977	1780.8515
update-rmayorga	1067	890	(83.41%)	949	(88.94%)	2.9984	1779.4910
update-evgeni	1067	889	(83.31%)	948	(88.84%)	2.9974	1776.6445

This is actually more hopeful than I thought. There's an obvious weakening as a result of the migrations, but the MSD stays under 3 and the centrality stays fairly constant too. The reachable/SCS counts do decrease, but at this point it looks fairly linear rather than an instant partition. Of course the more keys that are removed the more likely this is to drop off suddenly. Counteracting that DebConf9 is coming up which will provide a good opportunity for normally geographically disperse groups to cross sign, reinforcing the WoT for these new keys.

Either way I at least have a better handle on the current state of play, which gives me something to work with when thinking about how to proceed. For now, bed.

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:

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

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.

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.

Aurelien, your claim is wrong. About a year ago (IIRC; might've been longer), the Debian/m68k team decided that it wanted to do emulated buildd hosts, since that would allow us to more easily keep up with unstable. We discussed it in the team, we discussed it with ftp-masters, and we all decided to go for it. We've had emulated m68k builds go to the archive for quite a long time, with full knowledge and agreement of ftp-masters. We realized that emulated builds could be problematic, but we evaluated the issues and decided to take that risk, as a team. The reason your key was rejected for uploads of arm binaries was because you started doing those emulated builds without discussing it with the arm buildd maintainers, and without discussing it with the arm porters. You just decided it might help, so it must be good, right? Finding the difference is left as an exercise to the reader.

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

The Debian Python Modules Team is discussing which DVCS to switch to from SVN. Ondrej Certik asked how to generate a list of commiters to the team s repository, so I looked at it and got this:
emilio@saturno:~/deb/python-modules$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
865 piotr
609 morph
598 kov
532 bzed
388 pox
302 arnau
253 certik
216 shlomme
212 malex
175 hertzog
140 nslater
130 kobold
123 nijel
121 kitterma
106 bernat
99 kibi
87 varun
83 stratus
81 nobse
81 netzwurm
78 azatoth
76 mca
73 dottedmag
70 jluebbe
68 zack
68 cgalisteo
61 speijnik
61 odd_bloke
60 rganesan
55 kumanna
52 werner
50 haas
48 mejo
45 ucko
43 pabs
42 stew
42 luciano
41 mithrandi
40 wardi
36 gudjon
35 jandd
34 smcv
34 brettp
32 jenner
31 davidvilla
31 aurel32
30 rousseau
30 mtaylor
28 thomasbl
26 lool
25 gaspa
25 ffm
24 adn
22 jmalonzo
21 santiago
21 appaji
18 goedson
17 toadstool
17 sto
17 awen
16 mlizaur
16 akumar
15 nacho
14 smr
14 hanska
13 tviehmann
13 norsetto
13 mbaldessari
12 stone
12 sharky
11 rainct
11 fabrizio
10 lash
9 rodrigogc
9 pcc
9 miriam
9 madduck
9 ftlerror
8 pere
8 crschmidt
7 ncommander
7 myon
7 abuss
6 jwilk
6 bdrung
6 atehwa
5 kcoyner
5 catlee
5 andyp
4 vt
4 ross
4 osrevolution
4 lamby
4 baby
3 sez
3 joss
3 geole
2 rustybear
2 edmonds
2 astraw
2 ana
1 twerner
1 tincho
1 pochu
1 danderson
As it s likely that the Python Applications Packaging Team will switch too to the same DVCS at the same time, here are the numbers for its repo:

emilio@saturno:~/deb/python-apps$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
401 nijel
288 piotr
235 gothicx
159 pochu
76 nslater
69 kumanna
68 rainct
66 gilir
63 certik
52 vdanjean
52 bzed
46 dottedmag
41 stani
39 varun
37 kitterma
36 morph
35 odd_bloke
29 pcc
29 gudjon
28 appaji
25 thomasbl
24 arnau
20 sc
20 andyp
18 jalet
15 gerardo
14 eike
14 ana
13 dfiloni
11 tklauser
10 ryanakca
10 nxvl
10 akumar
8 sez
8 baby
6 catlee
4 osrevolution
4 cody-somerville
2 mithrandi
2 cjsmo
1 nenolod
1 ffm
Here I m the 4th most committer And while I was on it, I thought I could do the same for the GNOME and GStreamer teams:
emilio@saturno:~/deb/pkg-gnome$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
5357 lool
2701 joss
1633 slomo
1164 kov
825 seb128
622 jordi
621 jdassen
574 manphiz
335 sjoerd
298 mlang
296 netsnipe
291 grm
255 ross
236 ari
203 pochu
198 ondrej
190 he
180 kilian
176 alanbach
170 ftlerror
148 nobse
112 marco
87 jak
84 samm
78 rfrancoise
75 oysteigi
73 jsogo
65 svena
65 otavio
55 duck
54 jcurbo
53 zorglub
53 rtp
49 wasabi
49 giskard
42 tagoh
42 kartikm
40 gpastore
34 brad
32 robtaylor
31 xaiki
30 stratus
30 daf
26 johannes
24 sander-m
21 kk
19 bubulle
16 arnau
15 dodji
12 mbanck
11 ruoso
11 fpeters
11 dedu
11 christine
10 cpm
7 ember
7 drew
7 debotux
6 tico
6 emil
6 bradsmith
5 robster
5 carlosliu
4 rotty
4 diegoe
3 biebl
2 thibaut
2 ejad
1 naoliv
1 huats
1 gilir

emilio@saturno:~/deb/pkg-gstreamer$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
891 lool
840 slomo
99 pnormand
69 sjoerd
27 seb128
21 manphiz
8 he
7 aquette
4 elmarco
1 fabian
Conclusions:
- Why do I have the full python-modules and pkg-gstreamer trees, if I have just one commit to DPMT, and don t even have commit access to the GStreamer team?
- If you don t want to seem like you have done less commits than you have actually done, don t change your alioth name when you become a DD (hint: pox-guest and piotr in python-modules are the same person)
- If the switch to a new VCS was based on a vote where you have one vote per commit, the top 3 commiters in pkg-gnome could win the vote if they chosed the same! For python-apps it s the 4 top commiters, and the 7 ones for python-modules. pkg-gstreamer is a bit special

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.

Aur lien JARNO defended his PhD this morning, and I’m just back from attending his defense. He did an incredible work designing and implementing a simulator for the MUSE instrument that will equip the VLT in 2012 (”first light”) and is being built now. People working in the field are very impressed by the work he achieved, and I must add that it’s even more impressive when you know all he did in Debian and various other projects at the same time. Wow. Congratulations Dr. JARNO!

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?

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.

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…

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.


ldmeqib r9!, r1, r8, ip ^
ldclsl 3, cr14, [r4, #-364]!
stmleda r1, r0, r2, r6, r7, r9, sl, ip, lr ^
cmppl r6, #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.

Aur lien, I definitely can do better. All my recent blog entries (except one or two political ones) are focused on this activity, which lasts for 1.5 month now. As usual, when I began it, I ommitted to record the status of l10n to just have a proof that it gave great results, so you will just have to believe me. It is giving great results..:-) Making a lot of noise is sometimes a good way to make one's point. That is specifically my goal here. I think that at least one goal is achieved: I now expect many package maintainers to think twice before changing the debconf templates in their packages and, more generally, any internationalised material. Not that I don't want them to be fixed (indeed, that will be my next jihad: take packages one by one, ranked by popcon score, proofread the English templates, change them if needed and accompany maintainers in the interaction with translators), but I want them to be fixed cleanly.

Christian, this is the percentage of your blog entries concerning translation ratios in the last two weeks. I am sure you can do better