Mes activités Debian en mai 2012

Voici le récapitulatif mensuel de toutes mes activités gravitant autour de Debian. Si vous faites partie des personnes ayant fait un don pour soutenir mon travail (338,26 €, merci à tous !), c’est l’occasion de constater ce que je fais de votre argent. Sinon, c’est toujours quelques nouvelles intéressantes sur l’avancement de mes différents projets.

Dpkg

A l’instar du mois dernier, je n’ai quasiment rien fait ce mois-ci concernant dpkg. Situation qui va probablement changer en juin, maintenant que la traduction anglaise de mon livre est sorti…

Seule chose méritant d’être mentionnée, le fait que j’ai aidé Carey Underwood, alors qu’il essayait de comprendre pourquoi les performances de btrfs étaient si mauvaises (en regard de celles d’ext4) lors du dépaquetage des paquets Debian.

Travail qui a déjà entraîné certaines améliorations de btrfs apparemment, mais pas autant qu’on aurait pu l’espérer. En effet, les appels sync_file_range() effectués par dpkg ne forcent l’écriture que des données sous-jacentes, et non celle des métadonnées. En conséquence, les nombreux fsync() qui suivent entraînent toujours pléthores de transactions du journal, qui auraient été bien mieux traitées par une seule grosse transaction. Pour preuve : le remplacement de fsync() par un sync() ramène les performances au niveau de celles d’ext4.

(Attention : il s’agit là d’une synthèse personnelle des débats : bien que je me sois efforcé de la rendre aussi fidèle que possible, elle ne l’est probablement pas à 100% en ce qui concerne le comportement de btrfs.)

Empaquetage

J’ai uploadé de nouvelles versions pour smarty-gettext et smarty-validate, car ils ne pouvaient plus être installés après le retrait de smarty. L’histoire entière de smarty dans Debian/Ubuntu a été une pitoyable saga depuis le début…

En effet, un beau jour vit l’apparition d’un paquet smarty et quelques plugins. Tout allait pour le mieux, excepté le fait que les fichiers étaient installés d’une manière différente de ce que l’upstream recommandait. C’est ainsi qu’Ubuntu changea le chemin d’accès dans leur version de paquet, sans se soucier le moins du monde si cela casserait quoi que ce soit (ce qui fut le cas : cela cassa tous les plugins). En dépit de l’état des plugins, cette divergence survécut pendant des années. C’est ainsi que plusieurs paquets utilisant Smarty furent modifiés afin d’utiliser dpkg-vendor, ce afin de savoir quel chemin d’accès était le bon, selon qu’ils étaient compilés sur Debian ou Ubuntu.

2010 vit la parution de Smarty 3.0 et, plutôt que de mettre à jour le paquet smarty vers cette version, un des co-mainteneurs de smarty introduisit un paquet smarty3 utilisant encore un autre chemin d’accès (en dépit du fait que smarty 3 disposait d’un mode de compatibilité avec smarty 2).
Je finis par l’informer qu’il devait se charger de la migration des utilisateurs de smarty vers smarty3… il acquiesça puis perdit tout intérêt pour smarty (« Je ne l’utilise plus ») et ne fit donc rien.

L’année d’après, un des membres de l’équipe chargée de la sécurité apposa de force le statut « orphelin » à smarty (août 2011). Et en mars de cette année, le paquet a été supprimé d’unstable, et ce en dépit du fait qu’il possédait des dépendances inverses (les suppressions n’interviennent généralement que lorsqu’elles n’impactent aucun autre paquet. Je ne sais pas pourquoi cette règle n’a pas été appliquée ici).

Un mal pour un bien : au moins cette situation attira l’attention et Mike Gabriel me contacta à ce sujet. Je lui ai proposé de reprendre à son compte tous les paquets, dans la mesure où ils nécessitaient tous un vrai mainteneur. Il accepta. J’ai parrainé ses uploads concernant tous les paquets en lien avec smarty (portant par la même occasion les paquets au niveau des dernières versions amont).

En conclusion, on peut dire que la situation paraît meilleure aujourd’hui, bien qu’il n’existe aucun mécanisme de migration pour les utilisateurs utilisant smarty sur Squeeze. Ils découvriront qu’ils ont besoin de smarty3 dans Wheezy, et que les différents chemins d’accès nécessitent d’être ajustés. C’est probablement acceptable dans la mesure où les nouvelles versions amont ne sont plus rétrocompatibles avec smarty 2…

Cahier de l’Admin Debian

J’ai été occupé en début de mois par la publication du livre. J’ai uploadé le paquet publican-debian dans unstable. Il s’agit d’un « brand Publican » (c’est-à-dire un ensemble de feuilles de style XSL et CSS contrôlant la sortie de Publican) qui utilise les couleurs et le logo Debian. Ce dernier est utilisé par le livre.

J’ai également créé le paquet debian-handbook et mis en place le dépôt public Git sur alioth.debian.org.

J’étais prêt… ou du moins je le croyais : quelques heures après l’annonce, le site était devenu inutilisable en raison du trop grand nombre de visiteurs, dépassant le nombre de connexions maximum. Et je ne pouvais pas augmenter cette limite, en raison de l’empreinte mémoire d’Apache (avec PHP et WordPress). Nous avons rapidement détourné la majorité du trafic des fichiers statiques vers une autre machine et mis en place un bittorrent. Le problème était alors réglé (du moins sur le court terme). Des milliers de personnes ont téléchargé l’ebook et, à cette date, 135 exemplaires de la version papier ont été vendus.

J’ai ensuite pris une semaine de vacances et, bien que l’endroit où je me trouvais soit dépourvu d’accès Internet, j’ai arpenté les rues pour trouver un accès FreeWiFi (dont l’accès est gratuit pour les clients ADSL Free) et pouvoir gérer le flux de mails quotidiens. Nous avons rapidement reçu quelques rapports de bogues, dont j’ai immédiatement traité les plus faciles (erreurs typographiques, …).

A mon retour à la maison, j’ai passé — l’une après l’autre — les 54 commandes lulu pour les personnes ayant opté pour la version papier comme récompense de la campagne de levée de fonds. Quelque peu fastidieux mais ça devait être fait (si seulement lulu offrait une manière de traiter plusieurs commandes d’un coup…).

J’ai également cherché à mettre en place une solution m’évitant l’utilisation d’un hôte externe pour servir les fichiers statiques (des fois qu’un nouveau pic de trafic arriverait…). Pour se faire, j’ai installé nginx comme frontend : ce dernier sert les fichiers statiques directement, de même que les pages WordPress qui ont été mises en cache par wp-super-cache. Apache est toujours à l’écoute sur un port local, prêt à servir les autres requêtes transmises par nginx. Je vais peut-être complètement me passer d’Apache une fois que j’aurais migré vers Wheezy, et utiliser php5-fpm pour gérer les pages PHP.

Enfin, j’ai cherché à mettre en route les projets de traduction du livre, après les nombreuses offres de traductions qui m’ont été faites. J’ai documenté le processus pour les traducteurs intéressés et ai rédigé un article de blog à ce propos pour attirer l’attention des volontaires potentiels. Cela prend forme doucement… pensez à y jeter un coup d’œil si vous êtes intéressés !

Merci

Au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Debian Activities in May 2012 contribuée par Weierstrass01.