For etch, we will have apt security in place, so we can be sure that the stuff comes from the correct archive. But it is not possible to disable that checks only for one source, just for anything.
Buildds uses at least one mirror: incoming.debian.org aka ftp-master.debian.org. There are two queues, the accepted autobuild queue and the main archive. The accepted autobuild queue is not signed at all, it does not provide a Release file. The archive needs some time to generate the Packages files each dinstall run and have broken sigs during this time.
This means: buildds can't use APT security at all. And no, there is no other mechanism to ensure data integrity.
The buildd admin job is a rather dumb one. You get between 20 and 60 mails per day; most of them build logs. This logs, which are mostly sent unsecured through the public internet, have to be signed and the only available key is the personal key of the admin. So on one hand you have to make sure that the key is secure, on the other hand you have to find a way to sign a rather large amount of stuff.
For the debian-kernel archive, which I operate, and the pkg-voip/pkg-gnome/pkg-kde-extras archive, which is operated by Kilian, we decided to sign the uploads automaticaly. Each buildd get its own key and the used DAK includes a patch which restricts this keys to do uploads of only binaries of the correct arches.
This drasticaly reduces the time until a new package is uploaded; this means much less failed builds because a build dep is not yet built. Also it reduces the places where it is possible to do harm; you have to attack the buildd machine itself instead of the complete mail setup between buildd and admin.
Why is there no automatic or at least semi automatic infrastructure for LSB tests? The last published result is from the beginning of the last year and only for sarge.
The upcomming linux-2.6 release will introduce some changes in the Xen support.
i386 gets PAE only
The i386 images gets PAE only. The main cause is a bug in this versions which makes non-PAE images crash on core dumps. The patch is from Fedora, which only ships PAE images; so it is unlikely that they will fix it.
Network breaks with older guests
There is a bug in it, which makes older kernels on the guests break on a host which uses the new version. The reason is for know unknown. The kernel logs many of the following errors:
kernel: xen_net: Memory squeeze in netback driver.
I just take a look into the opcodes list of binutils for s390 and found the following entries:
b9b1 cu24 RRF_M0RR "convert utf-16 to utf-32" z9-109 zarch b2a6 cu21 RRF_M0RR "convert utf-16 to utf-8" z9-109 zarch b2a6 cuutf RRF_M0RR "convert unicode to utf-8" z9-109 zarch b9b3 cu42 RRF_M0RR "convert utf-32 to utf-16" z9-109 zarch b9b2 cu41 RRF_M0RR "convert utf-32 to utf-8" z9-109 zarch b2a7 cu12 RRF_M0RR "convert utf-8 to utf-16" z9-109 zarch b2a7 cutfu RRF_M0RR "convert utf-8 to unicode" z9-109 zarch b9b0 cu14 RRF_M0RR "convert utf-8 to utf-32" z9-109 zarch
Since z9-109, it have own opcodes to convert between the different types of unicode.
It is done. The new Xen infrastructure is finished, although it is not yet completely in unstable.
The main difference to the old one, the hypervisor and utils packages includes the complete version and an abi spec, just like our linux kernels. Also it is now possible to install more than one version of the utils at the same time. The userspace tries to find the correct tools for the running hypervisor.
The following packages are provided now:
and from the kernel
The only missing thing is a selection of the correct hypervisor in update-grub.
The T2000 have many slow CPUs but rather fast IO.
I did some performance tests with the T2000. The CPU is too slow to beat any current one from IBM (Power), AMD or Intel.
My first test was building kernels. With -j32, a complete build needs about 9 minutes. For comparison, a 4-way UltraSparc 2 with 450MHz needs 30 minutes. So each core compares to an UltraSparc 2 with 700MHz.
This numbers are not that phenomenal, so I added another test with ccache, to realy use the io system. With empty cache, it needs 10 minutes, with filled cache it needs 2.5 minutes.
As application server, it is not that usable; they are cpu bound. Especially zope, which is known to not scale well on more cpus because of the python global interpreter lock, is not able to use this. A comparision with an Opteron 242 with 1.6GHz shows a factor of 5 in the computing power on virtual cpu.
Some people already know it, I got a new machine to play with.
It is a Sparc running Debian etch:
# uname -a Linux zee 2.6.17-2-vserver-sparc64 #1 SMP Sat Aug 26 12:28:58 UTC 2006 sparc64 GNU/Linux
The kernel is not yet available in Debian, it is handbuilt. But I hope that this will change soon.
It is a small machine with some CPUs:
# grep ncpus /proc/cpuinfo ncpus probed : 32 ncpus active : 32
It only have a little bit of RAM:
# grep MemTotal /proc/meminfo MemTotal: 33257432 kB
And really too less disk space:
SCSI device sda: 143374738 512-byte hdwr sectors (73408 MB) SCSI device sdb: 143374738 512-byte hdwr sectors (73408 MB)
Yes, it is a T2000 from Sun with 8 real CPU cores:
cpu : UltraSparc T1 (Niagara) fpu : UltraSparc T1 integrated FPU prom : OBP 4.19.0 2005/10/27 17:24 type : sun4v
Each of the 8 cores can run 4 threads at the same time, Sun calls this CoolThreads, and Linux sees this as virtual CPUs.
Yes, the xen images from linux 2.6.16-18 in unstable does not work with the currect xen 3.0 in unstable and testing. The interface for the priviledged domain changed in an incompatible way. I'm working on that problem and 2.6.17-7 will contain a complete new infrastructure.
I think the current situation is rather clear. Our current kernel contains firmware blobs for some hardware. They are relicts from the time where the firmware loading infrastructure did not exists. It may be possible to move them outside, but such patches was rejected to keep compatibility.
Some people clearly stats, that they think, this violates paragraph 2 of the DFSG. I must say, I'm not sure. This paragraph say: The program must include source code. Now source is not defined and opaque data have no defined form of source. The data is opaque as it is not possible to say, what it includes. (Some people wanted to differentiate between executable code and configuration settings, but there is no way to see what it is.)
If we remove them from the kernel image, we make many users unhappy. Many of the widely used hardware like TG3 and some storage adapters will just stop working after a kernel upgrade. There is also no clean upgrade path. Even the installer infrastructure is missing and I don't think they will be finished for the release of etch. Therefor is think, such a removal will even violation paragraph 4 of our Social Contract which say: Our priorities are our users.