Tag - ubuntu

Entries feed - Comments feed

Last entries

Thu 18 Jun 2009

Ubuntu 9.10 will ship with OCaml 3.11.0... for now

As I recently announced on caml-list@, all OCaml packages coming from Debian were correctly compiled against OCaml 3.11.0 in Ubuntu Karmic Koala 9.10 to be released in next October. That means that current Karmic has a coherent set of OCaml packages, which I consider a worthwhile property.

Unfortunately, OCaml 3.11.1 has just been released and Debian developers are starting a transition to OCaml 3.11.1 in Debian unstable. As until the 25th of June all packages are directly imported from Debian unstable to Ubuntu Karmic, that would break various OCaml packages in Karmic, certain packages being compiled with 3.11.0 while others with 3.11.1.

Consequently, after discussion with Debian and Ubuntu developers[1], I have decided:

  1. To block the automatic import of OCaml packages from Debian to Ubuntu[2]. This blocking is currently effective. So, from now, Karmic will ship with OCaml 3.11.0 and the current package versions;
  2. To monitor transition from 3.11.0 to 3.11.1 in Debian and, if done quickly enough, to trigger a similar transition in Karmic. The Feature Freeze is set to the 27th of August so this is the absolute limit date for such a transition to end.

I am also considering providing 3.11.1 packages through Ubuntu PPA (Personal Package Archive) system. But I first need to learn how to use it. :-) But even if Karmic does not ship with 3.11.1, Karmic+1 which is LTS (Long Term Support) will have it.

If you read this blog entry and have an issue with this decision, let me know either through the comments or by sending an email at: dmentre AT linux-france.org.

Notes

[1] Several Ubuntu people were in favor of also doing such a transition in Karmic, but I cannot commit to monitor and handle it during that time period.

[2] I have been pretty conservative and blocked all OCaml based packages (because an updated package might need in up-to-date version of OCaml). We might lift this constraint a bit and allows synchronization of certain packages. Right now, I have not seen any such need. You can monitor the status of out-of-sync package in Karmic on this page.

Thu 11 Jun 2009

OCaml 3.11.0 on Ubuntu Karmic Koala nearly complete

OCaml As I have previously stated, there is no OCaml developers on Ubuntu and all OCaml packages in Ubuntu are coming from Debian. So there is apparently no much work to do in order to have a large set of OCaml packages on Ubuntu. Except that there are synchronisation issues. :-)

Debian's OCaml packages are imported automatically from unstable repository a the beginning of each new development cycle of Ubuntu[1] until a Debian Import Freeze takes effect (the 25th of June according to Karmic release schedule). Once imported, packages are automatically build. But OCaml packages have a stringent need to be compiled in the right order and against the correct version of the OCaml tool chain. In case of change (e.g. going from 3.10.2 to 3.11.0) all packages should be recompiled.

Therefore, I have adapted original Debian's monitoring scripts to Ubuntu:

Ocaml transition monitor for Ubuntu

On the 124 of such OCaml packages in Ubuntu, only 3 have remaining issues:

Once done, all OCaml packages should be correctly rebuild for OCaml 3.11.0. \o/

Of course, OCaml 3.11.1 should be released Really Soon Now™ and all that work should be redone once again. "There is no such thing as a simple job".[2] ;-)

Notes

[1] One can monitor the import of new packages on page http://packages.ubuntu.com/karmic/n....

[2] Tim Daily, of Axiom's fame.

Mon 11 May 2009

Un client demexp pour Ubuntu 9.04 / amd64

J'ai compilé un client demexp (client de vote pour l'expérience démocratique) pour la version Ubuntu 9.04 Jaunty Jackalope en architecture amd64 (version 64 bits pour processeurs x86 d'Intel et d'AMD). Il est disponible dans cette archive.

J'ai aussi remis à jour le code et les notes de version dans les arbres Mercurial de la version de développement (la 0.9) et la dernière version stable 0.8.

Avec la doc fournie, il doit être relativement facile de compiler un client demexp stable 0.8 sur une Debian Lenny ou une Ubuntu 9.04, sur toutes les architectures x86, 32 ou 64 bits.

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.

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 2 / 2