Blog of Sylvain Le Gall

One month later... the OCaml transition is in good shape.

In fact, the transition was almost finished after 15 days of work for the OCaml task force (i.e. September 20th or so). OCaml task force is now waiting to enter testing. The transition is blocked, because there is also an ongoing GTK transition that cross our path.

In order to enter testing, some packages will be removed: ocamldbi, regexp-pp... Zack has done a small poll to see if there was any reasons to keep them, since they don't compile with 3.10.0. After a week, we decided to go on and remove these packages.

With the transition there will be some small changes:

• cameleon has been upgraded to 1.9.18 (+ some svn correction)
• camomile is now in version 0.6.0
• for ocaml developpers, we are now trying to ship as much as possible an ocamldoc generated documentation with every XXX-dev package (referenced as XXX-ocamldoc-apiref in doc-base)
• arm and ia64 are buggy and prevent some packages to build (felix, camomile), these architectures won't be native anymore (OCaml will be shipped without ocamlopt on this arch)

After this long summer without posting (holiday time)... I come back to work.

The Debian OCaml Task Force has decided to migrate to OCaml 3.10.0. We have done a full round of test in experimental repository before deciding to submit a request to debian release management. After more than one week to let release manager give us permission to initiate the transition, we take the decision to do it!

Now, people can follow our progress using this web page or this one. On the status page, only package in unstable should be taken into account (package in experimental was the first round of test).

During this transition, Zack has also decided to create a common scheme for OCamldoc generated API documentation. For now, every library package that I upload contains this html/api location. This will allow to create a API bookshelf for OCaml library (more information on policy page).

Since this morning, OCaml 3.10.0 has been built for every arches and is installed... More packages to come

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

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

I spent the last three weeks to do test concerning stability and features of Xen. Well, i must say that i am not convinced, as some people thinks, that xen virtualization is ready for stable server.

Just for reminding, my previous post: there is no easy way to activate real framebuffer with xen. I try vesafb and intelfb. The first one doesn't work at all, the second one made a kernel oops (not at the beginning, you must wait a little before it). So i stick to standard console. I need to remove fbgetty because it uses framebuffer, and crashes (oops) with Xen (not at the beginning...).

I continue using my X configuration, expect that i move it to a xdmcp-chooser init script. This help me to "stop" it when my domU was not started. I still have some problems with the fact that after a time, if XDMCP fails, it restarts, switching to vt7 in the same time.

Now my real problem: stability of xen when playing around with PCI peripherals.

I try to hide my soundcard in dom0 and unhide it in a domU. This sound pretty well... But the computer seems to keep segfaulting after 24hours. So, i switch back to standard, non xen, configuration. It works for a week (at least). I also try to upgrade my BIOS, don't use ACPI, APIC et al -- but it doesn't work. Conclusion: my soundcard was a problem. In fact, the real problem comes from the fact that the sound card shared his IRQ with NIC and IDE controller. When running in a non-xen, the kernel see the conflict and rearranged IRQ. With Xen + sound card hide, there is no conflict and it finishes by a "oops".

Another, not so real, problem: performance.

I run a courier based imap server, including sqwebmail a webmail CGI. Running under xen configuration, it was almost like my previous computer (VIA C3 1GHz / 512MB / USB 2.0 HD and my current computer is Core 2 Duo T7600 / 2GB / SATA drive). When i test it with non-xen configuration, it was twice as fast. The main reason: courier use Maildir which contains a lot of small files. This implies a lot of IO, where xen is not very efficient.

Conclusion: Xen is not ready for my "production" environment. I think it is a good product to test things and to consolidate server which are not bound to hardware components (sound card, NIC). I don't think Xen is a good solution to build a "hardware" isolation.

As usual, i will use my favorite development scheme KISS (Keep It Simple and Stupid): build chrooted environment.

I am amazed, this blog was spammed. I heard that it was possible, but i don't understand why they have done that with my blog. Anyway, for now comments are closed. Mail-me if you are not a spammer !

I spend my whole sunday playing with GNU arch (tla). While i was looking at distributed SCM, i had a look at it... At this time, i find it was a bunch of very funny commands. I was right ;-)

OK, i am not fair with tla. I think it has some very powerful features. The main problem is the "learning curve" -- to reword with DARCS terminology. The problem has to do with the complex set of command which are available. I think you need a big training in order to begin to understand how tla works...

Another problem: tla remember what i have registered... I need to remove files in ~/.arch-params everytime i need to do crappy things. Not easy for testing purpose ;-) But anyway, after one day, i get a copy of wiclear tla repository and create my own branch for development.

I submitted a patch against wiclear to include some of my changes. After this, i will maybe begin to create an OpenID authentification mechanism.

Reading OCaml mailing list is really great source of good ideas.

I was thinking for some times to have a binding to DBUS in OCaml. This can give an easy access to HAL which is a good tool to detect most of the interesting hardware on a computer. I think this is a good way to write efficient script (as i am experimenting with Perl to detect my DVD writer). I think this deserve a debian package ;-)

While browsing for ocaml-dbus, i see that the upstream author also release a binding to inotify... This is also something i am interested in. I was thinking of building a inotify daemon to launch commands when files appear in a directory. Inotify can detect this kind of events.

And yesterday, while reading ocaml-beginners, someone talk about ocamlp3l. I have already seen this software, but at the time, i have no interest in it. But as of today, i think this can be a great way to unravel the power of a dual core computer! OCamlp3l helps people building parallel application. I also want to give this a try one day (when i will have finished to package everything).

For now, there is an RFS for ocamlp3l, but all these packages need to be authorized by upstream author.

My next package :

• ocaml-dbus
• ocaml-inotify
• ocamlp3l

Last week i was at Solution Linux 2007. I meet some other debian developper and it is good to meet some member of the community. I am a little bit disappointed concerning the people who attends this event. It was not as crowded as it used to be. I think Linux is no more the top "hype" thing of the year (but i heard at least twice "web 2.0" during the show... the "hype" was here).

During a discussion after this, i realize that some people think that the town of associations ("village des assoces" in french) was not enough opened to non-technical users. This guy thinks that open-source guy doesn't know how to sell OSS.

I am wondering if the spirit of the OSS is to "sell" anything to the public. Most of the people that are working on this are technical guy, there is no real "marketing" staff of the open source among them. I think that the core is essentially non-marketing guy (i really do think no one will never perform selling "cron" or "at" to any windows users -- and they are essential components of a GNU/Linux distribution).

After all, what does the OSS has to win doing "maketing" things. More users ? To my mind it is non sense, users coming to GNU/Linux, for example, must have personnal motivation. It is not like selling a box with a "Windows Vista" compatible sticker on it. They will loose a lot of applications, habits and eye-candiness. They should have a stronger reason to do that. This must be a real "motivation". I won't try to convince a guy that there is no problem using OSS -- because nothings is perfect.

As conclusion, i think that the town of associations was what it should be : a place where OSS developper can meet.