Tag - debian

Entries feed - Comments feed

Last entries

Thu 16 Apr 2009

Pourquoi le Libre est préférable au gratuit

Il n'est pas toujours facile de voir la différence entre gratuit et libre (au sens de Logiciel Libre, les quatre libertés) et les avantages que le Libre peut avoir sur le gratuit, surtout pour les œuvres. Voici quelques exemples qui, j'espère, illustrent les différences.

Gratuit mais pas réutilisable

Imaginons que je veuille faire un ouvrage sur les systèmes téléphoniques de quatrième génération, systèmes 4G. Comme je suis un gars sérieux, je vais directement à la source, sur le site du 3GPP où je peux accéder gratuitement à toutes les spécifications. C'est parfait ! Je peux enfin expliquer comment marche ces systèmes, en me basant sur les schémas de référence. Par exemple, je peux reprendre le schéma de la figure 4.2.1-1 du chapitre 4.2.1 du document TS 23.401 (qui décrit l'architecture générale du système[1]) et le mettre dans mon ouvrage. Sauf que je n'ai pas le droit ! En effet en page 2 du document on lit :

No part may be reproduced except as authorized by written permission.

Ce qui en bon français pourrait se traduire en :

Aucune partie ne peut être reproduite sauf si une telle reproduction est autorisée par écrit.

Donc, bien que les documents soient gratuits et téléchargeables par tous, je n'ai pas le droit de les recopier, même partiellement, même à but d'illustration pour un ouvrage pédagogique. Et comment expliquer le fonctionnement d'un système si on ne peut pas recopier ses schémas de référence ?

Copiable mais pas Libre

Bon, qu'à cela ne tienne. D'autres organismes de standardisation sont beaucoup plus progressistes. Par exemple l'IETF ! Donc je décide de changer de sujet et je m'attaque maintenant à SIP qui me permet de faire de la téléphonie sur Internet. Je vais télécharger la norme de ce protocole, la RFC 3261, et je peux librement en recopier les schémas, par exemple le magnifique diagramme de la page 132 :

                               |Request from TU
                               |send request
           Timer E             V
           send request  +-----------+
               +---------|           |-------------------+
               |         |  Trying   |  Timer F          |
               +-------->|           |  or Transport Err.|
                         +-----------+  inform TU        |
            200-699         |  |                         |
            resp. to TU     |  |1xx                      |
            +---------------+  |resp. to TU              |
            |                  |                         |
            |   Timer E        V       Timer F           |
            |   send req +-----------+ or Transport Err. |
            |  +---------|           | inform TU         |
            |  |         |Proceeding |------------------>|
            |  +-------->|           |-----+             |
            |            +-----------+     |1xx          |
            |              |      ^        |resp to TU   |
            | 200-699      |      +--------+             |
            | resp. to TU  |                             |
            |              |                             |
            |              V                             |
            |            +-----------+                   |
            |            |           |                   |
            |            | Completed |                   |
            |            |           |                   |
            |            +-----------+                   |
            |              ^   |                         |
            |              |   | Timer K                 |
            +--------------+   | -                       |
                               |                         |
                               V                         |
         NOTE:           +-----------+                   |
                         |           |                   |
     transitions         | Terminated|<------------------+
     labeled with        |           |
     the event           +-----------+
     over the action
     to take

             Figure 6: non-INVITE client transaction

Donc là, pas de soucis, je peux les utiliser comme je veux (ou du moins à but pédagogique), notamment les copier/coller dans mon ouvrage.

Mais imaginons que ce protocole ne me satisfait pas, que je veuille modifier sa structure pour l'améliorer. Par exemple remplacer l'encodage texte par un encodage en binaire normalisé comme ASN.1. Et comme je suis un bon gars, je documente mon travaille et je met à jour la norme avec mon extension, pour que d'autres puissent reprendre ce travail à leur tour. Et bien ce n'est pas possible ! Je n'ai pas le droit de modifier une norme IETF, sauf pour en faire une autre norme IETF. En effet, les petites lignes de la licence en fin de document (Full Copyright Statement page 268) indiquent :

However, this document itself may not be modified in any way, [...] except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, [...]

En français :

Ce document ne peut en aucune manière être modifié, [...] sauf si le but est de développer un standard Internet, auquel cas les procédures de gestion du copyright définies dans les Standards Internet doivent être suivies, [...]

C'est pour cette raison que les RFC de l'IETF ne sont pas incluses dans la section main de Debian et qu'on les retire même des paquets qui les contiennent.

Enfin Libre !

Adjustements OpenBTS Mais si maintenant, pour réaliser mon ouvrage technique, j'utilise quelques pages de Wikipédia ou la documentation d'OpenBTS, une implémentation libre d'une station de base de la norme GSM de téléphonie mobile (téléphonie 2G), là je suis libre de faire ce que je veux. Car la licence GNU GPL du code me permet de réutiliser, modifier, rediffuser des schémas et explications sans avoir à demander l'autorisation à qui que ce soit. La voilà la véritable liberté, le libre partage du savoir et la diffusion de la connaissance !

Donc la prochaine fois que vous utiliserez une documentation ou une norme, jetez un coup d'œil sur sa licence ! ;-)

Notes

[1] Et oui c'est du .doc ! On va juste dire que ce sont des documents de travail qui doivent être éditables. ;-) Pour un standard, utiliser un format standardisé comme l'ODF aurait été judicieux.

Thu 02 Apr 2009

Lors des mises à jour, redémarrez les programmes concernés !

La plupart des gens qui utilisent une Debian ou une Ubuntu ont entièrement confiance dans les mises à jour de sécurité. Ils ont bien raison, c'est pour cela qu'on utilise une distribution.[1]

Cependant, après le traditionnel aptitude update && aptitude safe-upgrade ou un clic sur Installer les mises à jour du Gestionnaire de mises à jour, il faut bien penser à redémarrer les logiciels concernés par les mises à jour, notamment dans le cas de bibliothèques partagées ou de mise à jour du noyau !

En effet, quasiment tous les programmes installés sur une distribution Linux utilisent des bibliothèques partagées. Ce sont des morceaux de code, regroupés dans un fichier .so et chargés en mémoire à l'exécution du programme. Par exemple, si je prends l'exemple du logiciel Apache2 tournant actuellement sur mon Linux :

$ sudo ps ax |grep apache2
5245 ?        Ss     0:00 /usr/sbin/apache2 -k start
5379 ?        S      0:00 /usr/sbin/apache2 -k start
5382 ?        S      0:00 /usr/sbin/apache2 -k start
5384 ?        S      0:00 /usr/sbin/apache2 -k start
5385 ?        S      0:00 /usr/sbin/apache2 -k start
5388 ?        S      0:00 /usr/sbin/apache2 -k start
6612 ?        S      0:00 /usr/sbin/apache2 -k start
7225 pts/0    R+     0:00 grep apache2

Le processus apache2 a pour PID (Process IDentifier) 5245. Je regarde les bibliothèques partagées utilisées par ce processus :

$ sudo cat /proc/5245/maps
7f65ad09a000-7f65ad0b0000 r-xp 00000000 08:03 3599252                    /usr/lib/php5/20060613/pdo.so
7f65ad0b0000-7f65ad2b0000 ---p 00016000 08:03 3599252                    /usr/lib/php5/20060613/pdo.so
7f65ad2b0000-7f65ad2b1000 r--p 00016000 08:03 3599252                    /usr/lib/php5/20060613/pdo.so
7f65ad2b1000-7f65ad2b4000 rw-p 00017000 08:03 3599252                    /usr/lib/php5/20060613/pdo.so
7f65ad2b4000-7f65ad2bf000 r-xp 00000000 08:03 4540164                    /lib/libnss_files-2.8.90.so
7f65ad2bf000-7f65ad4be000 ---p 0000b000 08:03 4540164                    /lib/libnss_files-2.8.90.so
7f65ad4be000-7f65ad4bf000 r--p 0000a000 08:03 4540164                    /lib/libnss_files-2.8.90.so
7f65ad4bf000-7f65ad4c0000 rw-p 0000b000 08:03 4540164                    /lib/libnss_files-2.8.90.so
7f65ad4c0000-7f65ad4ca000 r-xp 00000000 08:03 4540166                    /lib/libnss_nis-2.8.90.so
[...]

Au total, il y a environ 63 bibliothèques différentes utilisées par Apache2.

Lors d'une mise à jour de sécurité d'une bibliothèque partagée, le système de mise à jour va remplacer sur le disque le contenu de /usr/lib/toto.so par un nouveau /usr/lib/toto.so corrigeant la faille de sécurité. Mais si mon programme Apache2 utilise cette bibliothèque toto.so, les versions en mémoire utilisées par les processus apache2 ne seront pas mises à jour ! C'est une propriété des systèmes Unix : si on efface un fichier en cours d'utilisation, l'ancienne version actuellement utilisée par des programmes leurs est toujours accessible, et ce jusqu'à la fermeture par les programmes concernés de ce fichier.[2]

Au final, pour faire une mise à jour complète, il faut identifier les programmes à redémarrer pour que tous utilisent les nouvelles versions corrigées des bibliothèques :

  • faire l'habituel aptitude safe-upgrade ;
  • si un paquet du style libtoto3 est mis à jour, repérer tous les programmes utilisant cette bibliothèque avec lsof (merci Saint Gilles et François !) et les redémarrer :
$ sudo lsof | grep toto
[ des processus s'affichent comme zedémon ]
$ sudo invoke-rc.d zedémon restart
  • si les paquets mis à jour sont le noyau Linux ou des bibliothèques utilisées par tous les programmes, redémarrer la machine.[3]

Idéalement, le système de mise à jour des paquets devrait redémarrer les programmes qui le nécessitent. Vous pouvez utiliser le programme checkrestart du paquet Debian debian-goodies pour vous indiquer les services à redémarrer.[4]

Si votre Debian ou Ubuntu est une machine que vous éteignez tous les soirs, ne vous donnez pas la peine de chercher et redémarrer les programmes le nécessitant, la bonne version sera utilisée au prochain démarrage.

Mise à jour. 2009-04-11 : ajout information sur checkrestart.

Notes

[1] Sinon on suit les annonces de sécurité des logiciels installés et ont fait les patches et autres mises à jour soit-même.

[2] C'est justement cette propriété qui permet de mettre à jour dynamiquement un système sans perturber le fonctionnement des programmes en cours. Windows n'en est pas capable.

[3] Une tradition Unix veut qu'on ne redémarre jamais une machine. Mais ce folklore a été établi à une époque où il n'y avait pas autant d'alertes de sécurité. Si on n'utilise pas les noyaux à jour, on se fait attaquer, comme les serveurs Debian en novembre 2003.

[4] Merci à Fred pour avoir creusé le problème et donné le pointeur sur checkrestart sur gulliver@.

Mon 16 Mar 2009

Compilez vos programmes...

...enfin, au moins quelques uns ! ;-)

La première liberté du Logiciel Libre, c'est de pouvoir utiliser les programmes. Bien souvent, on utilise des programmes pré-emballés, empaquetés, parce que c'est plus simple et plus rapide. Mais qui dit que le programme est réellement libre ? Qu'une de ses dépendances ne pose pas un problème ? Que le programme est complet ? Qu'il est de qualité ?

Si vous utilisez un paquet d'une distribution bien connue, comme Debian ou Ubuntu, vous pouvez être sûr qu'il n'y a pas de soucis (en particulier pour Debian). Mais si vous utilisez un logiciel libre trouvé sur le web, rien ne dit que le logiciel proposé en téléchargement est complet, qu'il n'a pas de dépendances non libres ou simplement qu'il est bien compilable à partir des sources. C'est pourquoi je vous encourage vivement à compiler, au moins une fois de temps en temps, un logiciel libre que vous utilisez ou testez. Et tant que vous y êtes, à jeter un coup d'œil aux sources, histoire de regarder comment il est codé et la licence. Et une fois que vous avez fini, vous pouvez mettre une petite doc en ligne ou faire un petit billet de blog, histoire d'aider les autres.

Installer un programme à partir des sources, ce n'est pas si compliqué que ça en a l'air. Cela dépend bien évidemment du langage utilisé, de vos connaissances et de votre environnement. Mais la connaissance d'un minimum d'anglais technique permet de lire les fichiers README et INSTALL qui indiquent pas à pas les actions à faire. Et si vous avez un soucis, vous pouvez toujours demander sur la liste de diffusion gulliver@.

Et plus fondamentalement, compiler un programme, c'est un peu suivre l'esprit scientifique. En science, refaire une expérience soit-même permet de vérifier les dires d'un chercheur et confirmer ou infirmer ses propos. Installer un programme à partir des sources, c'est vérifier que le programme est complet et réellement utilisable, qu'il est bien libre, sans laisser à d'autres le soin de le faire pour vous. En faisant ça et en le faisant connaitre, vous faites progresser le logiciel libre.

...et remerciez les programmeurs

Tiens, à propos de logiciel libre et de compilation, le Framablog a sorti un billet sur une idée sympa :

Un obscur blogueur du nom de Solarius vient tout seul de décréter le dernier vendredi du mois de mars, le « Thank a dev day », que l’on pourrait traduire par la « Journée de remerciement aux développeurs de votre logiciel libre préféré » (oui, c’est un peu plus long en français).

La procédure est simple (et itérative) :

1. Choisir votre logiciel libre, de préférence parmi ceux que vous utilisez au quotidien et qui vous a déjà rendu mille services.

2. Trouver le mail de son auteur, ou plus sûrement de ses auteurs. Ce n’est pas forcément facile mais à défaut prendre l’adresse de contact du site officiel du logiciel en question.

3. Lui écrire pour le remercier chaleureusement en précédant le sujet de votre message du tag « TADD ». Ne pas hésiter à lui donner quelques détails de l’usage que vous faites de son logiciel.

4. Et c’est fini, vous avez échangé un petit sourire entre développeur et utilisateur. Si vous le souhaitez vous pouvez revenir au point 1. pour recommencer avec un autre logiciel ;-)

Je trouve que c'est une très bonne idée. Ça ne coute pas grand chose et ça peut faire énormément plaisir. Cette initiative est dans la droite ligne de dons aux logiciels libres que voulais faire un « Thomas » sur la liste gulliver@ en janvier dernier.

Le 27 mars prochain, envoyez un petit mot à vos développeurs préférés. Pour ma part, j'hésite encore : Emacs ? Gnus ? OCaml ? Firefox ? Dotclear ? Dokuwiki ? Lighttpd ? make ? gcc ? ssh ? bash ? BackupPC ? Mercurial ? La liste est trop longue. :-) Je crois que je vais privilégier les logiciels peu connus ou de petite taille. Les gros projets on déjà des financement et de la reconnaissance. À vous de jouer !

Thu 12 Mar 2009

Politique de mise à jour des paquets dans Ubuntu

Colin Watson, développeur Ubuntu et membre de Canonical, a récemment fait une clarification sur la politique de mise à jour des paquets dans une version stable d'Ubuntu sur ubuntu-devel-announce@. Cette clarification faite suite à un besoin de mettre à jour le paquet landscape-common consécutif à un changement de protocole entre le client et le serveur. Landscape est la solution de gestion centralisée d'un parc informatique de Canonical, maison mère (et source de financement) d'Ubuntu.

J'ai trouvé sa lecture intéressante, notamment en regard de la politique Debian de ne faire aucune mise à jour dans une version stable de la distribution (hormis bien évidemment les failles de sécurité).

Pour résumer, la politique par défaut est, tout comme Debian, de ne mettre aucun paquet à jour. Mais si une exception doit être faite, la grille de lecture suivante sera utilisée :

  • La mise à jour doit faire suite à des changements dans l'environnement extérieur, non prévisibles au moment de la sortie de la version stable ;
  • Une nouvelle version d'upstream (c.-à-d. le développeur du programme) est la meilleure façon de corriger un problème. Mais si cela est possible, il est préférable de backporter les changements nécessaires ;
  • upstream doit avoir la volonté de travailler avec Ubuntu ;
  • le code upstream doit être bien testé ;
  • le paquet concerné doit avoir le minimum d'interactions avec les autres paquets.

Bien évidemment, on peut se demander si ces critères n'ont pas été taillés sur mesure pour que le paquet de Landscape puisse être mis à jour. :-) Cela a probablement influencé leurs choix.

Mais la règle de base est quand même de ne faire aucune mise à jour. Avec une nouvelle version stable tout les six mois, ce n'est pas vraiment un problème (par exemple Ubuntu stable (Karmic Koala) aura la dernière version d'OCaml avant Debian stable (Squeeze) ;-).

Par contre pour la version LTS (Long Term Support) les mêmes problèmes que pour Debian se posent : au bout d'un certain temps, la non adaptation à l'environnement transforme l'avantage de la stabilité en réel problème :

  • impossibilité d'installer sur du matériel récent ;
  • bibliothèques trop vieilles pour compiler la dernière version d'un programme ;
  • nécessité de compiler un programme et ses dépendances à la main car le paquet officiel est obsolète.

Ubuntu et Debian s'en rendent compte et s'y adaptent, mais de façon différente. Ubuntu fait des mises à jour de paquets, au cas par cas (processus SRU, ''Stable Release Update'' [1]), alors que Debian privilégie la mise à jour du noyau et du serveur X (et uniquement de ceux-ci) quand la situation devient trop critique.

Même si j'adhère fondamentalement à l'aspect communautaire de Debian et sa volonté de stabilité, je ne suis pas passé à Ubuntu sur mon poste de travail par hasard : vive les versions stables régulières ! ;-)

Notes

[1] en particulier une application peut être mise à jour si elle n'appartient pas à l'infrastructure de base.

Mon 09 Mar 2009

OCaml revisions for each Ubuntu release

OCaml revision in Ubuntu for a given release depends more or less of the OCaml revision in Debian unstable at the time the Ubuntu release is started. Here is a short reminder of OCaml revisions for recent Ubuntu releases:

  • Hardy Heron (8.04): OCaml 3.10.0
  • Intrepid Ibex (8.10): OCaml 3.10.2
  • Jaunty Jackalope (9.04): OCaml 3.10.2
  • Karmic Koala (9.10): (probably) OCaml 3.11.0

As a reminder, the current official OCaml release is 3.11.0 and Debian unstable is currently also migrating to 3.11.0 (you can see its progress on Debian OCaml transition monitor). The probability is high that this transition will be finished or at least in good shape before the Debian Import Freeze of Karmic on June the 25th.

Mon 02 Mar 2009

Mise à jour Debian Etch en Lenny sur un kimsufi d'OVH

J'ai mis à jour mon serveur kimsufi d'OVH de Debian Etch 4.0 en Lenny 5.0. Pas de soucis particuliers. Je donne ici les étapes que j'ai suivi, si ça peut servir à d'autres...

Mon serveur est un serveur d'installation Etch standard d'OVH, avec le noyau 2.6.24.5-grsec-xxxx-grs-ipv4-32 d'OVH qui n'est pas le noyau standard de Debian[1]. J'ai quelques services installés : postfix, PostgreSQL, lighttpd, PHP5, etc.

Avant toute mise à jour, lire le chapitre 4 (Upgrade) des Release Notes de la mise à jour de Lenny.

J'ai fait cette mise à jour en trois phases :

  • installation de GRUB ;
  • mise à jour du système ;
  • dernières corrections.

Dans les indications suivantes, # marque le prompt du shell de root sous lequel il faut exécuter les commandes.

Installation de GRUB

J'ai installé GRUB parce qu'il supporte mieux les noyaux récents (cf. remarque sur initramfs pour LILO dans les Release Notes), parce qu'il ne nécessite pas d'exécuter LILO après chaque installation d'un nouveau noyau, parce que c'est le bootloader par défaut de Debian (même si je n'utilise pas le noyau standard) et pour augmenter le FPF[2].

# aptitude install grub
# grub-install "(hd0)"
# update-grub

Indiquer qu'on veut générer un /boot/grub/menu.lst.

Faire ensuite les modifications suivantes[3] sur /boot/grub/menu.lst. Ma partition root est /dev/sda1 ce qui correspond à (hd0,0) de GRUB, adaptez les modifications à votre propre partitionnement (voir la doc du nommage dans GRUB) :

--- /boot/grub/menu.lst.orig	2009-03-01 17:52:12.000000000 +0100
+++ /boot/grub/menu.lst	2009-03-01 18:14:12.000000000 +0100
@@ -16,7 +16,7 @@
 ## timeout sec
 # Set a timeout, in SEC seconds, before automatically booting the default entry
 # (normally the first entry defined).
-timeout		5
+timeout		0
 
 # Pretty colours
 color cyan/blue white/blue
@@ -36,11 +36,11 @@
 # root		(hd0,0)
 # makeactive
 # chainloader	+1
-#
-# title		Linux
-# root		(hd0,1)
-# kernel	/vmlinuz root=/dev/hda2 ro
-#
+
+title		Linux
+root		(hd0,0)
+kernel	/boot/bzImage-2.6.24.5-xxxx-grs-ipv4-32 root=/dev/sda1 ro
+
 
 #
 # Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST

Enfin rebooter... et croiser les doigts. :-)

# reboot

Normalement la machine reboot correctement. En cas de soucis, utiliser le mode rescue d'OVH pour essayer de récupérer la situation.

Mise à jour du système en Debian Lenny

Note : vous pouvez garder un script de la mise à jour avec la commande :

# script -t 2>~/upgrade-lenny.time -a ~/upgrade-lenny.script

Préparer la mise à jour en modifiant les fichiers de configuration d'apt :

  • supprimer le contenu d'/etc/apt/preferences si vous l'utilisiez (comme moi pour les backports) :
# mv /etc/apt/preferences /etc/apt/preferences.2009-03-01
  • mettre à jour /etc/apt/sources.list :
deb ftp://mir1.ovh.net/debian/ lenny main
deb-src ftp://mir1.ovh.net/debian/ lenny main

deb http://security.debian.org/ lenny/updates main
deb-src http://security.debian.org/ lenny/updates main

Mettre à jour la liste des paquets :

# aptitude update

Vous verrez probablement le warning suivant, ne pas en tenir compte (apt ne connaît pas encore la signature de l'archive des paquets de Lenny) :

W: There is no public key available for the following key IDs:
4D270D06F42584E6
W: You may want to run apt-get update to correct these problems

Installer la nouvelle version d'aptitude (et de la libc, ...) :

# aptitude install aptitude

J'ai eu quelques conflits à résoudre et j'ai accepté la solution proposée par aptitude.

Première mise à jour sans tout bousiller :

# aptitude safe-upgrade

Attention : surtout ne pas exécuter /sbin/lilo !! Vous effaceriez l'installation actuelle de GRUB.

J'ai eu quelques erreurs sur des services qui n'ont pas pu être relancés. Je les ai ignorées.

Deuxième mise à jour, en autorisant à supprimer des paquets :

# aptitude full-upgrade

Encore une mise à jour, pour mettre à jour les derniers paquets :

# aptitude full-upgrade

Un coup de grub-install pour être sûr qu'il est bien installé (inutile, mais je préfère être sûr) :

# grub-install "(hd0)"

Et un reboot en croisant les doigts :

# reboot

Normalement, votre machine devrait correctement re-démarrer. :-)

À noter que je n'ai pas eu de soucis avec /etc/udev/rules.d/70-persistent-net.rules qui influence le nommage des interfaces, eth0 est bien resté eth0. Mais comme le soulignent Alarc'h et AnatomicJC dans les commentaires, se problème peut se produire. Comme Alarc'h le dit, il faut alors rebooter en mode rescue le serveur puis monter la partition et éditer le fichier /etc/udev/rules.d/70-persistent-net.rules pour intervertir eth0 et eth1. Je ne sais pas s'il y a une solution propre à ce problème, c.-à-d. corriger le problème avant le reboot.

Dernières mise à jour

Je supprime LILO :

# aptitude remove lilo
# grub-install "(hd0)"
# reboot

Encore une fois, le grub-install est inutile mais je préfère être prudent. Normalement, votre machine doit rebooter correctement.

Vérifier que tout marche, en accédant à votre site web, blog et en vous envoyant des emails pour s'assurer que tous les services (email, serveur web, serveur de bases de données, PHP, ...) fonctionnent correctement.

Profitez maintenant de votre toute nouvelle Debian Lenny ! ;-)

Notes

[1] J'ai préféré garder le noyau d'OVH pour des raisons de sécurité. Il est compilé avec des extensions de sécurité et ne supporte pas les modules, réduisant les risques d'attaques.

[2] FPF : Fred Pleasing Factor

[3] un « - » en début de ligne indique une ligne supprimée, un « + » indique une ligne ajoutée.

Thu 26 Feb 2009

List of Ubuntu patches applied to Debian OCaml packages

I have updated my set of pages around OCaml packages in Debian and Ubuntu with a page that lists the Ubuntu patches applied to Debian OCaml packages. The page is updated daily.

I also published the source code of those hacks^Wscripts. The compute script is called in a cron job.

Thu 19 Feb 2009

Up-to-date status of OCaml packages on Ubuntu

I have set-up a set of scripts that give the status of OCaml packages on Ubuntu. As there is no OCaml packagers on Ubuntu, nearly all OCaml packages of Ubuntu are directly imported from Debian during the synchronization periods between Debian sid and Ubuntu. Those pages are made to help the job of Debian developers. They are doing a wonderful jobs regarding packaging of OCaml software on Debian and they are interested in helping the OCaml support on Ubuntu.

So, on those very basic pages, you'll find:

In all the above files, the format is:

 debian-source-package  distro-release  ocaml-compiler  package-version

Those lists of packages are made with quickly hacked scripts from Debian's OCaml developers:

page 3 / 3