Blog of Sylvain Le Gall

The return from Debconf 7 with Lunar was at least as interesting as the whole conference. I really enjoy this week. The only problem was that my luggage get lost in Edinburgh or Paris airport... Take two days to get it back.

The things i remember the most clearly from the end of the last week is several talks/bof about Debian debtags and general archive testing. There is really great QA idea. I decided to give a try to sbuild setup to try some automated testing of OCaml packages.

Another point is that i realized how many differents people are involved in Debian. The idea about "friends of debian" (or debian-community.org) can really be a great things to give some official status to all this people involved in Debian.

Trying spamplemousse, a plugin for dotclear... Hope this work

A lot of talks for now:

• Welcome talk
• Bits from the DPL
• SE Linux for dummies
• Data mining popcon
• Debian installer an update
• Dependency based boot sequence
• Rewriting the Policy to be machine interpretable
• Debian Release Management
• Debian Live
• Resurrecting "cruft"
• OpenStreetMap
• Popcon BOF

I really appreciate the ones about popcon. I think that today searching packages inside debian is a pain. I think that one of the way to make Debian more sexy is to show what is the best in Debian: a huge number of packages (more or less) well maintained ... This is a real advantage over any other distributions (thinking to Red Hat or Mandriva) which has a lot of disseminated source of packages which are not bound together and most of the time are uninstallable.

The idea behind using popcon data to propose more accurate result is great. I think that this idea combinated with debtags, should enable our users to have really good results when searching for a particular package. Another idea should also be interesting: adding hardware information to popcon. This should enable to do even more precise query (e.g. what TV viewer should i use, considering that my card is XXX). This could save a lot of time to many people that do not exactly know what program to use with their hardware. But the couple of package and hardware data in popcon could led to a problem of privacy...

Anyway, i think that searching a 15000 packages database is not enough efficiant debian (but i must agree that using debtags/ara is already a good way to search).

Today i attend two talks : HP relationship with Debian, DAK future direction.

The talk about DAK led me to meet some known people in a technical background. Many ideas were exchanged and in particular one about the possibility to create staging area into experimental! I think this should be really great and would enable debian to do things in a more team synchronized manner.

Going back to my own experiment, with ocaml packaging, i think this should really help ocaml people to do more soft transition. The big problem of team work is that their playground is unstable. There should be no problem concerning that -- expect when you need to do big transition that will break most of the team maintained packages. For example, uploading new OCaml package will break almost all OCaml library packages. You must at least binNMU all packages and most of the time you have to patches/upload new upstream. This transition make all the ocaml packages uninstallable/unusable for a time. This can be quite long when there is big problem with particular package (thinking of coq and mldonkey).

People should also consider the fact that this kind of staging area must:

• be easy to setup (just give a name and a list of GPG key of people that are allowed to upload)
• configure a list of arch to build (for team maintained package, chances are that you have at least i386, amd64, ppc)
• define a shorter delay for rebuilding packages/updating ftp area
• simulate an upload to unstable by building on all arches in sequence
• upload packages to unstable waiting for them to be build on every arches before uploading the next one.

As usual this kind of thing should be great but the main problem, is the lack of manpower to create it...

After my disappointing xen experiments, i try to use vserver. The way it handles virtualization is just a lot more simple than xen. The problem with this is that you only get linux installation. All is running upon the same kernel, every guest is separated using security context. It has advantage over chrooted env (i have also try this, but it is not worth to write a blog entry for it): it can use natively several IP/hostname.

It is a lot less fun than Xen: you cannot run windows concurrently with linux at native speed. But it is a lot more stable. I did some test and it show me that it has more or less the same stability as the Linux kernel. For now, i am able run my server for 9 days. I think this is stable.

Concerning my other need:

• i reuse the same X/XDMCP scheme as with Xen
• i set up a framebuffer (no problem)
• i can share my sound card (just have to copy dev entry of the sound card to the "/dev/" of the vserver)
• network is stable -- but there is some problem.

Just to give a quick summary of my network problem :

• some firewall rules are strange to write, because you have no originating NIC device for it
• you have to limit every duplicated daemon (host/guests) to listen to only IP address of host
• eth2 and my USB printer seems to conflict, eth0 and my sound card seems to conflict

I have concerns about the last item! I think it is related to possible not enough good driver of the NIC. I need to investigate on this point (i.e. move to linux 2.6.21).