7 astuces pour rapporter les bogues Debian efficacement et voir vos problèmes résolus

Remplir des rapports de bogue constitue la façon la plus courante de contribuer pour les utilisateurs. Bien que cela ne soit pas très difficile, je vais vous donner quelques conseils pour améliorer la qualité de vos rapports. Après tout, lorsque vous prenez du temps pour rapporter un bogue, c’est dans l’espoir de le voir résolu… Alors voyons comment mettre le plus de chances de votre côté.

1. Essayez de reproduire le bug

Si vous ne pouvez pas reproduire le bogue, il sera alors impossible de trouver sa cause d’origine, et par conséquent de le résoudre. Dans ce cas, je vous suggère d’attendre jusqu’à ce que vous ayez rencontré ce bogue plusieurs fois. Vous trouverez peut-être ce qui le provoque (ou ce qui semble favoriser son apparition). Si l’application a un mode debug/verbose, ce serait une bonne idée de l’activer jusqu’à ce que le bug apparaisse une deuxième fois. Les logs générés seront très utiles au développeur pour comprendre ce qui s’est exactement passé.

Par conséquent, ne remplissez pas un rapport de bogue tout de suite, à moins que vous puissiez le reproduire. L’exception à la règle, c’est lorsque l’application donne quelques informations telles qu’un core-dump, une back-trace ou un message d’erreur.

Bien entendu, si le bogue apparaît lors d’une mise à jour, il est difficile de le reproduire (à moins de posséder plusieurs ordinateurs), mais vous devriez tout de même le rapporter. Assurez-vous d’y intégrer toutes les informations qui s’y rapportent (version des paquets avant et après la mise à jour logs de la mise à jour, etc).

2. Faîtes de votre mieux pour identifier le paquet mis en cause

Lorsque vous rapportez un bogue à Debian, vous devez l’assigner à un paquet. Bien qu’il existe des pseudo-paquets utiles pour les problèmes ne se rapportant pas directement à un véritable paquet, dans la plupart des cas vous devrez rapporter le bogue concernant le paquet particulier qui semble être la cause du problème rencontré.

De la même façon, vous devrez autant que possible attribuer le problème à un fichier (par exemple l’exécutable de l’application buggée). À partir du moment où vous connaissez le nom du fichier, vous pouvez utiliser dpkg -S pour identifier le paquet correspondant.

$ dpkg -S /usr/bin/hamster-time-tracker
hamster-applet: /usr/bin/hamster-time-tracker 

Notez que reportbug accepte pour paramètre un nom de fichier et fera la conversion ci-dessus à votre place.

Si vous ne connaissez que le nom de l’application (mais pas le nom du fichier de l’exécutable associé), vous pouvez utiliser dpkg -S avec un motif afin qu’il retourne tous les résultats correspondants :

$ dpkg -S hamster
hamster-applet: /usr/share/applications/hamster-applet.desktop
hamster-applet: /usr/share/gnome/help/hamster-applet/es/statistics.page
[…]
hamster-applet: /usr/bin/hamster-time-tracker
[…]

Ou vous pouvez aussi vérifier dans la liste des paquets installés :

$ dpkg -l "*hamster*"
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom Version Architecture Description
+++-=========================-=================-=================-=======================================================
ii hamster-applet 2.91.3+git2012051 all time tracking applet for GNOME 

3. Vérifiez que le bogue n’est pas déjà signalé ou résolu

Si une nouvelle version du logiciel est disponible, c’est une bonne idée d’essayer de reproduire le problème aussi avec cette dernière version. Étant donné que les développeurs ont tendance à se préoccuper uniquement de la dernière version, ils essaieront de le reproduire dans cette version, et risquent d’être agacés si le bogue que vous rapportez est déjà résolu. C’est pourquoi les rapports de bogue des utilisateurs de testing/unstable ont tendance à être plus utile que les rapports des utilisateurs de la stable.

Dans tous les cas, vous devrez vérifier que le bogue n’a pas encore été rapporté : créer un doublon est inutile et génère seulement plus de travail pour le développeur qui doit fusionner les deux bogues.

Notez que reportbug vous montrera automatiquement la liste des bogues ouverts avant de vous permettre d’en soumettre un nouveau.

4. Utilisez reportbug

Bien que le système de rapport de bogue Debian permette à quiconque de soumettre un nouveau bug avec un simple mail, vous devriez vraiment utiliser un programme fait pour ça tel que reportbug (ou reportbug-ng) car il inclura automatiquement de nombreuses informations utiles dans le rapport généré (version des dépendances, architecture actuelle, etc.) et vous assistera à chaque étape.

5. Décrivez le problème afin que le développeur puisse le reproduire

Idéalement, votre rapport devrait inclure tout ce qui est nécessaire au développeur pour reproduire le problème sur son système. Si un quelconque document provoque le bogue, attachez-le au rapport.

Décrivez les étapes permettant de reproduire le bogue avec autant de détails que si vous vouliez l’expliquer à votre grand-mère. Expliquez le comportement attendu du programme, et ce qui s’est passé à la place.

Vous pouvez en apprendre bien plus sur la façon d’écrire un bon rapport de bug dans cet article : How to report bugs effectively. C’est un peu long mais ça en vaut la peine si vous envisagez de rapporter des bogues, et donc d’interagir avec les développeurs.

6. Soyez sympa et prêt à aider

Lorsque vous remplissez un rapport de bogue, gardez à l’esprit que vous êtes en train d’écrire à un développeur bénévole de logiciel libre, et non à un service consommateur. Vous devriez être respectueux et suivre les règles usuelles de courtoisie. Le temps disponible des développeurs est limité, et de devrait pas être gaspillé.

Soyez prêt à aider, car si un développeur commence à examiner votre problème, il peut avoir besoin d’informations supplémentaires (en particulier s’il ne peut le reproduire), et vous devriez être prêt à lui fournir. C’est pourquoi il est important de garder tout ce dont vous avez besoin pour reproduire le problème.

Dans certains cas, le mainteneur Debian peut être surchargé de travail. Vous pouvez offrir votre aide en transférant le bogue au traqueur de bogue amont.(Voir Upstream bug tracker) Ce sera toujours apprécié. Si vous êtes à peu près certain que le problème n’est pas spécifique à Debian, vous pouvez faire ça directement et définir l’URL du rapport de bug amont dans le champ « transféré » (par exemple avec bts forwarded <bogue> <url>).

7. Utilisez le niveau de gravité convenable

Le système de suivi de bug Debian vous permet de définir la gravité initiale du rapport de bug (en ordre décroissant de gravité : critical, grave, serious, important, normal, minor, wishlist). Choisissez la gravité convenable selon les définitions officielles et ne les interprétez pas de travers.

En particulier, n’exagérez pas la gravité : par exemple, si vous avez perdu des données à cause d’une mauvaise utilisation du logiciel, il ne s’agit pas d’une sévérité « critical » (i.e. "rm -rf *" n’est pas un bogue critique de rm). Si vous utilisez seulement une petite partie d’un logiciel, et que cette partie ne fonctionne pas, le paquet peut être inutilisable pour vous, mais pas pour tout le monde. Il ne s’agit donc pas d’une gravité « grave ». La gravité « important » est la plupart du temps un bon choix dans ce cas.

Ne sous-estimez pas non plus la gravité, si un problème est suffisamment important pour devoir être réparé avec la prochaine version stable (par exemple une régression par rapport à la version précédente), choisissez alors une gravité de niveau release-critical (i.e au moins « serious »). Le mainteneur et le gestionnaire de version peut toujours abaisser le niveau de gravité s’il n’est pas en accord avec votre jugement initial.

Et maintenant, lancez-vous à cœur joie dans la soumission de bogues ! Vous pouvez vous référer à cet article via cette URL raccourcie : http://raphaelhertzog.fr/go/bugreporting/

Ceci est une traduction sous licence CC-BY-SA 3.0 de mon article 7 tips de file useful Debian bug reports and get your problem solved contribuée par Xavier Cartron. Si vous avez apprécié cet article, cliquez ici pour découvrir comment m’encourager à en fournir d’autres.

Mes activités Debian en août 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 (88,41 €, 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

Les choses sont relativement calmes durant la période de gel de Wheezy. Je me suis juste occupé de corriger trois bogues : une régression du format « 3.0 (quilt) » (cf. n°683547), une erreur de segmentation de “dpkg-query -W -f  »” (cf. ce commit), et enfin une mauvaise auto-complétion pour les utilisateurs français (cf. n°685863).

Test de la mise à jour vers Wheezy

Plusieurs rapports de bogues nous sont parvenus faisant état d’échecs de la mise à jour vers Wheezy du fait de l’exécution du trigger par dpkg, tandis que les dépendances de paquets avec des triggers en attente ne sont pas satisfaites. Corriger ce comportement dans dpkg ne va malheureusement pas sans problèmes (cf. n°671711 pour plus de détails) … Guillem a, en conséquence, décidé de différer la correction à Jessie. Ma proposition d’une solution intermédiaire est tombée aux oubliettes. Nous devons maintenant trouver à la place des solutions dans chacun des cas pouvant provoquer cette erreur. (comme par exemple : n°680626).

Une autre manière d’éviter ces erreurs consiste à s’assurer que les triggers sont exécutés le plus tard possible, comportement que nous pouvons améliorer de plusieurs façons.

La première manière de procéder consiste à modifier la plupart des triggers de telle manière qu’ils utilisent la directive « interest-noawait ». Les paquets activant le trigger sont dans ce cas immédiatement marqués comme configurés (plutôt que « triggers-awaited » – en attente de triggers), et le trigger ne devra plus être exécuté comme étape d’une résolution de dépendances ultérieure. Mais il n’y a, à l’heure actuelle, aucun paquet qui utilise cette nouvelle directive, et ce malgré un appel sur debian-devel-announce. :-(

Une deuxième méthode consiste à modifier APT de sorte qu’il utilise dpkg –no-triggers, et de laisser le traitement du trigger pour la fin (avec un dernier appel à “dpkg –configure -a”). Chose que j’ai demandée de manière assez précoce dans le cycle de Wheezy mais, pour de multiples raisons, les mainteneurs de APT n’ont pas donné suite. Le les ai relancés de nouveau dans le bogue n°626599, mais il est maintenant trop tard pour Wheezy. Je trouve cela un peu triste dans la mesure où j’ai utilisé ces options durant tout le cycle de Wheezy et cela a bien fonctionné pour moi (et je les ai également utilisées lors d’une mise à jour (dist-upgrade) sur le portable de ma femme).

Il aurait été intéressant de tout avoir en place pour Wheezy, de sorte que nous n’ayons pas à endurer les mêmes problèmes pour la mise à jour vers Jessie. Mais à moins que quelqu’un monte au créneau pour piloter ces changements, cela semble peu probable.

Nous en sommes réduits en lieu et place à utiliser des solutions de contournement douteuses, paquet par paquet.

Empaquetage

J’ai préparé des mises à jour de sécurité pour python-django (1.4.1 pour unstable, 1.2.3-3+squeeze3 pour stable), et empaqueté une nouvelle version upstream pour cpputest (3.2-1). J’ai également passé en revue ledgersmb 1.3.21-1, préparée par Robert James Clay, et lui ai demandé de s’occuper d’une nouvelle version avec d’autres corrections.

J’ai publié nautilus-dropbox 1.4.0-2 avec des modifications de mon cru afin de supporter https_proxy d’une part, ainsi qu’un meilleur affichage des informations de diagnostic lors de l’échec d’un téléchargement.

Avec l’aide de Paul van der Vlis et de Michael Ziegler, j’ai fait le nécessaire afin d’être capable de migrer python-django-registration 0.8 vers Wheezy, et ce même s’il s’agit d’une nouvelle version upstream dotée de modifications qui ne sont pas rétrocompatibles. Nous avons maintenant la bonne version dans Wheezy grâce à Adam D. Barratt, qui a débloqué le paquet, et ce malgré le fait que j’ai manqué l’échéance du gel de Wheezy.

Debian France

Julien Cristau a rappelé au conseil d’administration de Debian France que nous devions élire le bureau (Président, Secrétaire et Trésorier), dans la mesure où les titulaires actuels se sont retirés. J’étais quelque peu inquiet que personne ne veuille reprendre la main, et j’ai donc contacté chaque membre afin de trouver des volontaires. Ce qui est maintenant chose faite (Julien Danjou, Sylvestre Ledru et moi-même). Il ne reste plus qu’à procéder à l’élection, dès que Julien trouvera un peu de temps pour l’organiser.

Divers

J’ai mis en place, avec l’aide de l’équipe d’administration Debian (DSA – Debian System Administration), des règles antispams pour l’alias owner@packages.qa.debian.org, vu la quantité de spams rencontrés. L’équipe DSA m’a demandé d’en profiter pour tout documenter dans une page de wiki sur dsa.debian.org, afin de pouvoir s’y référer dans le futur.

J’ai également testé un patch upstream concernant gnome-keyring (cf. n°681081), qui réintroduit la possibilité d’oublier les phrases de passe GPG après un délai configurable.

Merci

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

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

Mes activités Debian en juillet 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 (72,65 €, 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

Mon travail concernant dpkg ce mois-ci se résume à un ensemble de petites tâches :

  • Upload de dpkg 1.16.7 comportant la correction d’une régression importante ;
  • J’ai relancé la discussion sur la manière de résoudre le problème des paquets source avec des binaires « Multi-Arch: same » qui ne peuvent pas faire l’objet de bin-nmus individuels ;
  • Pour faire suite à cette discussion, j’ai ouvert de nombreux rapports de bogues, afin de discuter/planifier la transition des fichiers de changelog/copyright au sein des métadonnées des paquets (n°681289 pour debian-policy, n°681293 pour apt-listchanges, n°681295 concernant www.debian.org pour packages.debian.org).
  • J’ai également soumis le n°681292 concernant sbuild, pour le faire utiliser la nouvelle syntaxe de dpkg pour bin-nmu. Cela nous permettra de faire des re-compilations binary-only avec des versions arbitraires (au lieu des suffixes « +b1″ uniquement). Ubuntu pourrait l’utiliser pour leur +rebuild1, nous pourrions l’utiliser pour compiler des backports qui ne nécessitent pas de modifications des sources (et donc partager les paquets sources communs plutôt que de les dupliquer). Cela peut également être utile si nous en arrivons à une situation où les transitions sont préparées dans des dépôts externes et où nous voulons que les bin-nmus de ces dépôts aient des versions uniques (même si le même paquet peut être « bin-nmué » dans de multiples dépôts, dans le cas de transitions concurrentes) ;
  • J’ai créé une demande de déblocage pour dpkg une fois la version arrivée à presque 10 jours d’existence ;
  • J’ai reconsidéré le bogue n°316521 où il est question d’une perte par dpkg des répertoires partagés où des fichiers ont été créés manuellement, puis proposé un patch. Encore aucun commentaire de Guillem concernant ce patch. Corriger ce problème aiderait à en corriger un certain nombre d’autres relatif à piuparts ;
  • Juste avant le début de mes vacances, j’ai créé plusieurs rapports de bogues concernant dpkg, déplaçant certains points s’accumulant sur ma « To-Do list » vers un espace public où d’autres personnes pourraient en prendre connaissance et apporter leur aide (je serais ravi de parrainer quiconque souhaiterait s’attaquer à l’un d’entre eux) :
    • n°681443 : dpkg-source –commit devrait être capable de fusionner les modifications dans un patch existant ;
    • n°681470 : dpkg-shlibdeps : devrait également scanner Build-Depends-Arch pour les versions minimales ;
    • n°681474 : Dpkg::Vendor : devrait supporter /etc/os-release et /etc/os-release.d/* ;
    • n°681477 : dpkg-vendor : implémenter la commande –select-closest ;
    • n°681480 : base-files : fournir HOME_URL, SUPPORT_URL et BUG_REPORT_URL dans /etc/os-release ;
    • n°681489 : base-files : ajouter /etc/os-release.d/debian et rendre simple l’ajout de fichiers /etc/os-release.d/* supplémentaires ;
  • Dans le n°595112, nous avons discuté des spécificités d’une nouvelle fonctionnalité de dpkg-mainstscript-helper, permettant de déplacer un fichier conffile d’un paquet à un autre.

Empaquetage

J’ai mis à jour nautilus-dropbox à la version 1.4.0, ainsi que python-django-registration à la version 0.8. Les deux ont été uploadés vers unstable, et je souhaitais initialement demander un déblocage (de freeze) pour le dernier. Il s’est ensuite avéré que ce paquet avait gagné des dépendances inverses. La version 0.8 introduisant des changements d’API, et compte tenu du gel de squeeze, il n’était donc plus question d’un tel déblocage.

Assurance Qualité

J’ai creusé et résolu le bogue n°678356, où il était question d’un disfonctionnement des nouvelles statiques du Système de Suivi des Paquets (PTS – Packages Tracking System).

J’ai également débloqué au début du mois le méconnu mais important service mole… il était dépassé de plusieurs semaines et de nombreuses personnes étaient gênées par des informations de nouvelles versions amonts obsolètes.

Vacances

Quasiment aucun travail lié à Debian pendant mes vacances, mais l’absence de wifi dans les environs m’a forcé à rechercher des moyens de connecter mon ordinateur au Net via la connexion 3G/GPRS de mon Nokia N900. J’ai découvert l’application « Mobile Hotspot » (page d’accueil), qui a fonctionné sans aucun problème (bien qu’elle requiert le dépôt Maemo devel non standard, afin de pouvoir installer le noyau alternatif pour les « utilisateurs avancés »).

Cahier de l’Admin Debian anglais aka Debian Handbook

Michal Čihař nous a proposé d’héberger une instance Weblate, ce afin d’aider à traduire le livre au travers d’une interface Web. Il a gentiment accepté d’apporter quelques améliorations pour mieux répondre à mes besoins. L’instance améliorée est maintenant disponible à l’adresse debian.weblate.org.

L’utilisation de Weblate par les équipes de traduction ne nécessite aucun prérequis. Cela rend le recrutement de volontaires sans aucune connaissance préalable de Git ou des fichiers PO bien plus facile. Si vous souhaitez apporter votre aide, jetez quand même un œil en premier à cette page ; vous ne devriez pas démarrer avec Weblate sans avoir au préalable pris contact avec l’équipe de traduction concernée.

Mis à part les traductions, j’ai également eu le plaisir d’intégrer quelques patchs de Philipp Kern améliorant la section couvrant IPv6, ainsi que quelques autres parties. Nous pouvons encore améliorer la qualité du livre si d’autres contributeurs partagent leurs expertises des domaines qu’ils maîtrisent mieux que Roland ou moi dans les chapitres correspondants. :-)

Merci

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

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

Mes activités Debian en juin 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 (168,12 €, 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

Ce mois-ci, j’ai repris mon travail sur dpkg, et concentré mes efforts sur la « finition » du format « 3.0 (quilt) ». Dans la dernière version (1.16.6 – uploadée juste avant le freeze) dpkg-source rétablit l’arborescence source dans un état cohérent après l’échec de l’application d’un patch (cf. n°652970), n’écrase pas l’en-tête du patch automatique pré-existant, met à jour automatiquement debian/source/include-binaries pendant dpkg-source –commit, et supporte une nouvelle option –no-unapply-patches, destinée à ceux qui n’aiment pas le retrait automatique à la fin du processus, lorsque les patchs n’ont pas été appliqués au début.

Je souhaitais aller plus loin et offrir une nouvelle fonctionnalité permettant l’insertion du patch automatique au début des séries quilt, mais le temps m’a manqué pour aller au bout. J’ai juste réussi à factoriser les appels quilt dans un module Perl dédié (Dpkg::Source::Quilt), afin d’avoir un code plus propre dans le module gérant le format source (Dpkg::Source::Package::V3::quilt).

À ceux qui se posent la question : cette fonctionnalité est destinée principalement à l’équipe X Strike Force qui maintient des paquets dans Git et fait énormément de cherry-picks ciblés (pour corriger des régressions, …). Mais ils utilisent également quilt au sommet de cette arborescence afin de conserver certains changements Debian spécifiques. Le « diff automatique » est un peu brouillon avec le format 1.0 mais au moins devient-il plus petit automatiquement lorsqu’une nouvelle version amont sort : il n’y a alors rien à nettoyer. Je souhaiterais qu’ils puissent utiliser le format « 3.0 (quilt) » tout en gardant leur workflow. Je penche pour une solution permettant « --auto-commit=first:cherry-picks« , qui nommerait « cherry-picks » le patch automatique et le mettrait en première position dans les séries quilt. (Les retours sur ce point sont les bienvenus, en passant).

Empaquetage

Pas mal d’activités question empaquetage ce mois-ci, le dernier avant le gel de Wheezy :

  • J’ai empaqueté CppUTest (un framework de test pour C/C++), et rédigé un billet le concernant ;
  • J’ai préparé une mise à jour de Publican pour stable, afin de corriger un problème de dépendance manquante. J’ai également mis à jour la version présente dans unstable afin d’inclure le backport d’un correctif, conformément à ce que certains utilisateurs m’ont demandé ;
  • J’ai mis à jour dh-linktree, afin d’améliorer sa documentation (suivant une discussion survenue sur debian-devel) d’une part, et de gérer proprement les slashs finaux en entrée (cf. n°673408) ;
  • J’ai parrainé dblatex 0.3.4-1, ainsi que ledgersmb 1.3.18-1 ;
  • J’ai mis à jour gnome-shell-timer avec une nouvelle version amont marquée comme compatible avec GNOME 3.4 (cf. n°6776516) ;
  • J’ai empaqueté WordPress 3.4, et passé une journée entière à classer les vieux bogues, qui s’accumulaient. Quelques jours plus tard, j’ai développer une nouvelle infrastructure permettant de gérer proprement les fichiers de thèmes/langues/plugins. Le répertoire canonique dans lequel l’utilisateur doit copier ses thèmes/plugins est maintenant /var/lib/wordpress/wp-content/. Les plugins/thèmes officiels y sont « installés » via des liens symboliques pointant vers /usr/share/wordpress/wp-content/, où les fichiers réels résident ;
  • J’ai voulu envoyer deux patchs pour developers-reference, mais j’ai noté que certaines traductions étaient complètes et en attente d’un upload. J’ai nettoyé (passage à dh) l’empaquetage et uploadé la version 3.4.8 avant l’envoi des patchs correspondant aux n°678710 et n°678712.

Tandis que j’effectuais ce travail d’empaquetage, j’ai trouvé deux améliorations possibles, que j’ai consignées dans des rapports de bogue :

  • n°676606: debcommit devrait être capable d’identifier tout seul qu’une nouvelle version est préparée (lorsque le champs distribution du changelog passe du statut UNRELEASED à quelque chose d’autre) ;
  • n°679132: lintian remonte des faux positifs pour le tag package-uses-local-diversion lorsque ni –local ni –package n’est passé à dpkg-divert.

Stand Debian France à Solutions Linux

J’ai tenu, du 19 au 21 juin et conjointement avec Carl Chenet, Tanguy Ortolo, ainsi que d’autres membres de l’association, le stand Debian France à l’édition 2012 du salon Solutions Linux. Nous avons répondu à quantité de questions, vendu tous nos t-shirts et parapluies, que Carl avait importés depuis l’Allemagne et la Suisse (il est vraiment temps que tous nos goodies soient produits en France !), et accueilli de nouvelles personnes dans l’association. Nous avons également présenté une version imprimée du Debian Administrator’s Handbook et de sa version française initiale.

Vous pouvez voir Carl, Tanguy et moi sur la photo suivante (cliquez dessus pour obtenir une version agrandie : merci à Sébastien Dubois d’Evolix pour celle-ci !) :

Je sais qu’un nombre important de personnes se préparent pour DebConf, mais, en ce qui me concerne, j’ai décidé de ne pas y assister cette année : le prix du billet d’avion — un peu élevé — et le conflit de dates avec les vacances familiales y ont concouru. Je pensais pouvoir participer aux RMLL à la place… mais je n’irai pas non plus (Roland Mas y sera bien présent lui !), la faute à la charge de travail restante avant mes propres vacances, dans deux semaines.

Merci

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

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

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.

La traduction anglaise du Cahier de l’Admin Debian est disponible

The Debian Administrator's Handbook Cover Je suis vraiment content qu’on ait terminé ce projet. Roland et moi avons passé tellement de temps sur ce livre depuis décembre dernier… aussi bien pour la traduction à proprement parler que pour toutes les autres choses que l’on a tendance à oublier: une jolie couverture, une mise en page agréable et irréprochable pour le livre imprimé, la coordination du travail des relecteurs, s’enregistrer comme éditeur pour avoir un numéro ISBN, etc. Je reviendrai sûrement sur certains aspects de cette aventure dans de futurs articles.

En attendant, profitez pleinement de ce livre conforme aux principes du logiciel libre selon Debian:

Consultez l’annonce officielle (il y a une remise pour ceux qui achètent le livre papier dans les 8 premiers jours).

Mes activités Debian en avril 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 (186,38 €, 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.

Nouvelles de Dpkg

Pour la première fois depuis plusieurs années, il y a eu une nouvelle version de dpkg (1.16.3) dont le changelog ne mentionne pas mon nom. Les 3-4 commits que j’ai effectués ne méritaient pas une entrée de changelog. Je dois reconnaître qu’il m’a été assez facile de mettre dpkg de côté compte tenu de l’ambiance actuelle avec Guillem et de comment j’ai été occupé avec mes autres projets.

Faire profil bas pendant un certain temps ne peut pas faire de mal. Mais je n’ai pas l’intention d’arrêter de contribuer à dpkg. Au contraire même, c’est une activité que j’apprécie beaucoup (habituellement).

Travail d’empaquetage

J’ai mis en paquet la version 3.0.0 de SQL-Ledger, et plus tard dans le mois j’ai parrainé le paquets de LedgerSMB, un fork de SQL-Ledger qui — contrairement à ce dernier — est développé comme un vrai projet libre.

J’ai également empaqueté la version 0.56 de Zim, et mis à jour WordPress en version 3.3.2 avec ses nombreuses corrections de sécurité.

The Debian Administrator’s Handbook

Comme depuis plusieurs mois, la plus grande partie de mon temps a été consacrée à la traduction anglaise du Cahier de l’Admin Debian. La grande nouvelle est que le fond de libération a été complété (merci à l’École Ouverte Francophone qui a fait le don nécessaire pour compléter le fond). Cela veut donc dire que le livre sera publié sous des licences compatibles aux principes du logiciel libre selon Debian (GPL-2+ / CC-BY-SA 3.0) dès sa publication.

On espère le publier la semaine prochaine (c’est-à-dire entre le 7 et le 11 mai). La sortie PDF pour le livre imprimé est quasiment prête. Il reste du travail sur la sortie HTML/EPUB et on doit aussi prépaper la publication des sources…

Souhaitons que tout se déroule comme prévu.

Merci

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

Ceci est une traduction de mon article My Debian Activities in April 2012.

Mes activités Debian en mars 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 (227,83 €, 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

dpkg accompagné du support multiarch est maintenant disponible dans Sid, grâce à Guillem. La route fut sinueuse, et de nombreux retards survinrent même après l’annonce faite par Guillem sur debian-devel-announce. L’upload est intervenu, enfin, le 19 mars.

Je n’ai pas vraiment apprécié son annonce dans la mesure où elle n’était absolument pas coordonnée et, ayant été impliqué depuis le début, nous aurions pu la rendre beaucoup moins effrayante pour le public. J’ai finalement mis à disposition un script permettant à quiconque de vérifier s’il est affecté par l’un des problèmes potentiels soulevés par Guillem. Bien que réels, ces problèmes ont une faible probabilité d’apparition dans le cas d’un usage normal de multiarch.

Bernhard R. Link a soumis un patch ajoutant une nouvelle commande –status à dpkg-buildflags. Cette commande afficherait toutes les informations nécessaires pour comprendre quels drapeaux sont activés et pourquoi ils le sont. Elle serait naturellement appelée pendant le processus de compilation par debian/rules afin de garder une trace de la configuration des drapeaux de compilation. Le but étant d’aider le déboguage, ainsi que de rendre possible l’extraction automatique de cette information depuis les logs. J’ai passé en revue le patch et, après plusieurs itérations, ce dernier est pratiquement prêt à être intégré. Il reste néanmoins un point sur lequel Bernhard et moi sommes en désaccord, à la suite de quoi j’ai sollicité l’avis de Guillem afin de prendre une décision. Malheureusement ni lui ni personne d’autre ne s’est manifesté.

J’ai également uploadé, à la demande de Alexander Wirt, un nouveau rétroportage (backport) de dpkg dans lequel j’ai supprimé la variable DEB_HOST_MULTIARCH dans dpkg-architecture, ce afin d’être certain que le multiarch ne soit jamais activé dans d’autres backports.

Une dernière chose que je n’ai pas mentionnée publiquement jusqu’à présent : j’ai contacté Lennart Pottering pour lui suggérer une amélioration du fichier /etc/os-release qu’il essaye actuellement d’harmoniser entre les différentes distributions. Il m’est apparu que ce fichier pourrait également remplacer notre fichier /etc/dpkg/origins/default (et pas seulement /etc/debian_version), à la condition qu’il puisse aussi contenir des informations d’ascendance. Après quelques échanges, Lennart documenta de nouveaux champs officiels pour ce fichier (ID_LIKE, HOME_URL, SUPPORT_URL, BUG_REPORT_URL). La prochaine étape pour moi consiste maintenant à améliorer dpkg-vendor afin qu’il supporte ce fichier (en tant que solution de secours ou en tant que comportement par défaut, je ne sais pas encore).

Empaquetage

J’ai empaqueté quilt 0.60 (nous sommes maintenant tombés à 9 patchs spécifiques Debian, alors que nous en étions à un ébouriffant 26 pour la version 0.48 !) ainsi que zim 0.55.

En prévision de la prochaine publication upstream de Publican, j’ai demandé à l’équipe Perl d’empaqueter quelques modules Perl dont a maintenant besoin Publican. Moins de deux semaines plus tard, ils étaient tous dans unstable ! Félicitations et merci beaucoup à l’équipe Perl (et en particulier à Salvatore Bonaccorso, dont j’ai fait la connaissance alors que nous partagions le même vol lors de la dernière DebConf).

Sur un tout autre registre, être le mainteneur de nautilus-dropbox est devenu de moins en moins drôle ces derniers mois, en particulier parce que les auteurs amont ont essayé de passer outre certaines des décisions (correctes, à mon sens) d’empaquetage que j’avais prises et se sont mis en relation avec les community managers d’Ubuntu pour avoir gain de cause. Enfin, je continue à recevoir des doublons d’un bogue qui ne concerne pas mon paquet, mais le paquet officiel, pour lequel Dropbox n’a pas répondu à ma requête.

Version anglaise du Cahier de l’Admin Debian

La traduction est maintenant finie et c’est l’intégralité du livre qui est actuellement en relecture. Cela prend un peu plus de temps qu’escompté, d’une part car nous essayons d’harmoniser le style et d’autre part car il n’est pas facile de coordonner le travail de plusieurs relecteurs volontaires.

La couverture du livre est pour sa part quasi-finalisée (cliquez sur l’image pour la voir en plus haute définition) :

Nous avons également fait des progrès en ce qui concerne le design intérieur de la version papier. Je n’ai malheureusement rien à vous montrer pour l’instant, mais ça sera vraiment chouette… et fait uniquement à partir d’une feuille de style LaTeX adaptée pour dblatex.

La campagne de libération a ralenti ce mois-ci, avec seulement 41 nouveaux donateurs. Elle a néanmoins fait un joli bond en avant grâce à une généreuse donation de 1000€ de la part de Offensive security, l’entreprise derrière Backtrack Linux. Ils vont prochainement communiquer sur ce don, espérons que ça donnera un coup de boost à l’opération. Ce serait une belle réussite que de réussir à réunir les 3000€ restants dans les quelques semaines qui précèdent la publication officielle du livre !

Le livre a monopolisé mon temps de travail ce mois-ci et explique ma relative inactivité sur d’autres fronts. J’ai travaillé plus qu’à l’accoutumée, et ma femme n’arrête pas de me répéter que j’ai l’air fatigué et que je devrais aller au lit plus tôt… mais j’aperçois maintenant le bout du tunnel : si tout va bien, la publication du livre devrait intervenir dans les prochaines semaines et je pourrais alors revenir à un style de vie plus sain.

Merci

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

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

Mes activités Debian en février 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 (384,14 €, 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 et multiarch

Le mois a débuté par une décision du Comité Technique m’autorisant à procéder à l’upload d’un dpkg multi-architectures, et ce même si Guillem n’avait pas encore fini sa revue de code (ainsi que les changements associés). Compte tenu de cette décision, Guillem effectua lui-même l’envoi dans experimental.

Envoi à la suite duquel j’ai annoncé la disponibilité d’une version test, et invité les bonnes volontés à l’essayer. Tout cela a conduit à de nouvelles discussions sur la liste debian-devel.

Au cours de ces discussions, nous avons appris que Guillem avait changé son fusil d’épaule concernant la possibilité de partager deux fichiers (identiques) entre plusieurs paquets Multi-Arch: same, et qu’il avait abandonné cette fonctionnalité. Si cette dernière avait été retirée des spécifications multi-arch, cela aurait signifié encore une nouvelle mise à jour de toutes les bibliothèques déjà mises à jour pour multi-arch. À ce stade, la discussion s’est arrêtée, avec une dernière note de Guillem expliquant qu’il existait des tensions, à chaque fois que nous discutions de changements invasifs, entre choisir la facilité et ce qu’il convient de faire.

Après quelques semaines (ainsi qu’un précieux résumé de Russ Allbery), Guillem annonça que, bien que toujours pas convaincu, il réactivait ladite fonctionnalité. De plus, il ajouta avoir bientôt fini le travail, et qu’il pousserait les derniers morceaux de la branche multiarch vers la branche master du dépôt Git cette semaine (l’upload de la 1.16.2 étant planifié la semaine prochaine).

Voilà qui clôt le résumé. J’ai bien évidemment participé aux discussions, mais je n’ai pas fait grand chose de plus… Je dispose d’un « mandat » me permettant d’effectuer l’upload de la version multi-arch de dpkg vers sid, mais je n’ai pas souhaité m’en servir vu que ces discussions n’avaient pas abouties sur une conclusion claire. De plus, Guillem a été très clair sur le fait qu’il considérait l’implémentation de multiarch comme « boguée », « bancale » et « inachevée », et qu’il avait retravaillé le code afin de corriger quelques erreurs… Étant donné qu’il n’a jamais partagé l’avancement de ses travaux, je n’avais aucun moyen de l’aider, même simplement en examinant ce qu’il faisait.

Nous avons également recueilli quelques rapports de bogue en lien avec multi-arch, mais je n’ai pas pu m’en occuper dans la mesure où Guillem avait clairement la main sur la base de code, dans laquelle il a effectué de nombreux changements dans son coin… Ce n’est pas exactement comme cela que j’espérais participer à un projet de logiciel libre, mais la vie est pleine de surprises !

Je serai soulagé une fois cette histoire terminée. Pendant ce temps, j’ai ajouté une nouvelle entrée sur ma TODO list depuis ma proposition de gestion des changelogs bin-nmu, qui pourrait également corriger le bogue n°440094.

Travaux divers concernant dpkg

Après en avoir discuté avec Guillem, nous sommes tombés d’accord sur le fait que les informations de copyright devaient uniquement apparaître dans les sources, et non dans les pages de manuel, ou dans la sortie de --version. Les deux derniers cas sont soumis à traduction et demandent un effort inutile aux traducteurs lors des mises à jour. Guillem disposait déjà de codes pour gérer les chaînes --version, et de mon côté je me suis occupé des modifications concernant les pages de manuel.

J’ai intégré quelques mises à jour mineures concernant la documentation, et corrigé un bogue relatif à une page de man manquante. J’ai découvert un peu plus tard que certaines modifications récentes avaient entraîné la perte de toutes les pages de manuel traduites. Pour remédier à cela, j’ai suggéré une amélioration de dh_installman (et même préparé un patch). Guillem choisit finalement une autre manière d’installer les pages de manuel traduites.

Aiguillonné par une discussion sur la liste debian-devel, j’ai ajouté une nouvelle entrée à ma TODO list : implémenter dpkg-maintscript-helper rm_conffile_if_owner, afin de gérer le cas où un conffile est déplacé dans un autre paquet qui peut être installé (ou pas) .

Travaux divers d’empaquetage

J’ai empaqueté quilt 0.51 au début du mois. Le nombre de patchs spécifiques à Debian diminue doucement. Cinq patchs ont été supprimés dans la version 0.51, et un nouveau a été ajouté. J’ai soumis upstream, plus tard dans le mois, quatre patchs supplémentaires, qui ont été acceptés pour la version 0.60.

Cette nouvelle version (qui vient juste d’être publiée, je vais rapidement l’empaqueter) constitue un jalon important dans la mesure où elle est la première dépourvue de tout code en C (c’était le cas pour la version Debian depuis longtemps, mais au prix d’un patch intrusif). Le développeur upstream Jean Delvare a travaillé là-dessus en se basant sur notre patch, puis est allé encore plus loin pour le rendre plus efficace.

Mis à part quilt, j’ai également uploadé dh-linktree 0.2 (mise à jour mineure de la documentation), sql-ledger 2.8.36 (nouvelle version upstream), logidee-tools 1.2.12 (corrections mineures) et publican 2.8-2 (correction du bogue critique pour la publication n°660795).

Consultants Debian

Le Chef de Projet Debian travaille à fédérer les entreprises Debian. En tant que propriétaire de Freexian SARL, je ne pouvais qu’être extrêmement intéressé puisque Freexian « contribue, offre un support et trouve un intérêt stratégique à Debian ». Il n’y a qu’un seul problème : il faut deux employés au minimum, et je n’en ai aucun (je suis tout seul ) ! J’ai essayé d’argumenter en avançant que j’avais déjà travaillé, en de multiples occasions, avec d’autres développeurs Debian (en tant que sous-traitants/partenaires) lorsque les projets étaient trop conséquents pour moi tout seul (ou que je n’avais pas assez de temps). Mais cet argument a été rejeté.

À la place, et dans la mesure où notre intrépide leader n’est jamais effrayé à l’idée de proposer des compromis, il m’a suggéré (ainsi qu’à MJ Ray, qui avait avancé des idées similaires aux miennes) d’animer la liste de diffusion Debian Consultants qui, selon lui, serait plus appropriée aux entreprises d’indépendants telles que la mienne. J’ai accepté d’aider à « animer » cette liste et, de son côté, il s’est engagé à promouvoir à la fois les listes « Debian Companies » et « Debian Consultants ».

Quoi qu’il en soit, la liste « Debian Consultants » a connu un peu de trafic dernièrement et vous êtes encouragés à vous y abonner si vous êtes un indépendant proposant des services gravitant autour de Debian. Le point le plus prometteur reste la proposition de James Bromberger d’implémenter une vraie base de données des consultants, en lieu et place de l’actuelle page statique.

Nouvelles de la traduction du Cahier de l’Admin

Nous avons bien avancé ce mois-ci, et il ne reste plus qu’un seul chapitre à traduire. En conséquence, j’ai décidé de commencer la relecture, et j’ai lancé un appel aux volontaires en soumettant un chapitre différent à cinq relecteurs.

La campagne de libération a effectué un joli bond en avant, et ce grâce à sa couverture sur barrapunto.com. Nous avons ainsi atteint 80% du montant total, alors que nous n’en étions qu’à 72% au début du mois (grâce à 113 nouveaux donateurs !). Il reste moins de 5000€ à réunir pour permettre la publication du livre sous une licence libre.

Vu la progression sur ces derniers mois, il est cependant assez improbable que la somme soit réunie à temps pour la publication du livre en avril. Ce qui serait pourtant bien… aussi soyez sympas et passez le mot autour de vous !

En parlant de la publication du livre : je suis en train de la préparer petit à petit. Traduire les fichiers docbooks ne suffit pas, je dois être capable de générer des versions HTML, ePub et PDF du livre. J’utilise Publican pour la plupart des formats, mais pour ce qui est des PDF, Publican s’éloigne de fop et son remplaçant (basé sur webkit) est loin d’être satisfaisant en ce qui concerne la génération d’une version prête à imprimer. J’envisage donc d’utiliser dblatex, et de faire supporter dblatex comme backend par Publican.

J’ai embauché Benoît Guillon, l’auteur de dblatex, afin qu’il corrige certains bogues ennuyeux et qu’il améliore le logiciel afin de couvrir mes besoins pour le livre (le résultat est déjà, pour partie, dans le dépôt CVS de dblatex). Je travaille également avec un maquettiste professionnel afin d’obtenir une mise en page irréprochable.

Je me suis également lancé à la recherche d’un développeur Python Django pour la réalisation du site par lequel le livre sera commercialisé (et diffusé). L’objectif de ce site sera plus large que la simple mise en avant du livre (« aider à financer les développeurs de logiciel libre »), mais dans le monde du logiciel libre, il est toujours bon de commencer par s’occuper de son propre cas. :-)

Il reste à espérer que tout sera prêt en avril. Je travaille dur pour respecter cette échéance ! Vous devez avoir remarqué que mon blog était relativement calme le mois dernier….

Merci

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

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

Recommandations pour le parrainage de paquets Debian

Parrainer un paquet signifie l’uploader pour le compte d’une autre personne (qui se trouve être, la plupart du temps, un nouveau contributeur voulant devenir mainteneur de paquet). Le parrainage est réservé aux développeurs Debian, car ils sont réputés connaître les tenants et aboutissants de l’empaquetage. Cet article essaye ici de documenter ce processus, afin de s’assurer que le parrain effectue un travail satisfaisant, au regard des standards Debian.

Parrainer un paquet dans l’archive Debian n’est pas une tâche triviale. Cela suppose que vous ayez vérifié son empaquetage et jugé qu’il était du niveau de qualité attendu par Debian. Voyons voir ce que vous pouvez et devriez faire dans un tel cas :

Parrainer l’envoi initial

Parrainer un tout nouveau paquet requiert une analyse méthodique de son empaquetage : compiler le paquet et tester le logiciel proprement dit n’est absolument pas suffisant ! Vous devez ouvrir chaque fichier dans le répertoire debian à la recherche de problèmes potentiels. Voici une liste que vous pouvez utiliser pour réaliser cet audit :

  • Vérifier que l’archive TAR amont fournie est identique à celle distribuée par l’auteur amont (dans le cas où les sources ont été ré-empaquetées pour Debian, il vous faudra générer l’archive par vous-même) ;
  • Lancer lintian. Ce dernier remontera beaucoup de problèmes « habituels ». Vérifier que les overrides employés pour masquer des erreurs sont pleinement justifiés ;
  • Lancer licensecheck et vérifier que debian/copyright est correct et exhaustif. Rechercher les problèmes de licences (comme les fichiers dont l’en-tête comporte « All rights reserved », ou une licence non compatible avec les principes du logiciel libre selon Debian) ;
  • Compiler le paquet avec pbuilder (ou équivalent), afin de s’assurer que les dépendances de compilation soient complètes ;
  • Rechercher les erreurs dans debian/control : est-ce qu’il suit les bonnes pratiques ? Est-ce que la liste des dépendances est complète ?
  • Rechercher les erreurs dans debian/rules : est-ce qu’il suit les bonnes pratiques ? Est-il améliorable ?
  • Rechercher les erreurs dans les scripts de configuration (preinst, postinst, prerm, postrm, config) : est-ce que les scripts preinst et postrm fonctionneront si les dépendances ne sont pas installées ? Est-ce que tous les scripts sont bien idempotents (c’est à dire qu’ils peuvent être lancés un nombre arbitraire de fois sans conséquences fâcheuses) ?
  • Passer en revue toutes les modifications faites aux fichiers amont (soit dans les fichiers .diff.gz, soit dans debian/patches/ ou directement embarquées dans le tarball debian en ce qui concerne les fichiers binaires). Est-ce que ces modifications sont justifiées ? Sont-elles proprement documentées (en utilisant DEP-3 dans le cas des patchs) ?
  • Pour chaque fichier, il vous faut vous demander pourquoi il est là et s’il constitue la meilleure manière d’atteindre le but recherché. Est-ce que le mainteneur suit bien les bonnes pratiques de l’empaquetage décrites dans la Référence du Développeur Debian ?
  • Compiler, installer les paquets, et essayer les logiciels. Assurez-vous de pouvoir supprimer et purger les paquets. Vous pouvez aussi tester les paquets grâce à piuparts.

Si cet audit n’a révélé aucun problème, vous pouvez alors uploader le paquet. Mais souvenez-vous que même si vous n’en êtes pas le mainteneur, le parrain reste responsable de ce qu’il a envoyé dans l’archive Debian. C’est pourquoi vous êtes encouragé à suivre le paquet grâce au PTS (Package Tracking System – Système de Suivi des Paquets).

Parrainer la mise à jour d’un paquet déjà existant

Vous supposerez généralement que le paquet a déjà été l’objet d’un examen minutieux. Donc plutôt que de recommencer, vous analyserez avec beaucoup d’attention les différences entre l’ancienne et la nouvelle version préparée par le mainteneur. Si vous n’avez pas vous-même effectué la revue initiale, vous souhaiterez peut-être jeter un coup d’oeil un peu plus approfondi au paquet en lui-même, juste au cas où le premier « relecteur » ait été un peu négligeant.

Pour comparer, il vous faut les deux versions. Télécharger la version source actuelle (grâce à apt-get source) et recompiler-là (ou télécharger le fichier binaire correspondant : aptitude download). Télécharger ensuite le paquet source à parrainer (la plupart du temps via dget).

Lisez les nouvelles entrées du fichier de suivi des modifications (changelog) : il devrait vous dire à quoi vous attendre. L’outil principal que vous allez utiliser est debdiff, que vous pouvez lancer avec deux paquets sources (fichiers .dsc) ou deux fichiers binaires, ou encore deux fichiers .changes (il comparera alors tous les fichiers binaires listés dans les fichiers .changes).

Si vous comparez les paquets sources (en excluant les fichiers upstream dans le cas d’une nouvelle version upstream, par exemple en filtrant la sortie de debdiff grâce à filterdiff -i '*/debian/*'), vous devez comprendre toutes les modifications qui s’affichent, et elles doivent être proprement documentées dans le suivi des modifications Debian.

S’il n’y a rien à relever, compiler le paquet et comparer les fichiers binaires, afin de vérifier que les modifications vues dans les sources n’ont aucun effet de bord (comme des fichiers supprimés par erreurs, des dépendances manquantes, …).

Il peut également être utile de contrôler l’état du paquet sur le PTS, histoire de vérifier que le mainteneur n’a rien manqué d’important : peut-être que des traductions en attente auraient pu être intégrées, ou bien le paquet a fait l’objet d’une mise à jour indépendante (NMU – Non-Maintener Upload) mais le mainteneur a oublié d’en reprendre les modifications dans sa nouvelle version. Il se peut également qu’un bogue critique pour la publication ait été laissé de côté et bloque la migration vers testing… bref : quelle qu’en soit la nature, si vous trouvez quelque chose qui aurait pu être (mieux) fait, il est temps de le dire au mainteneur de sorte à ce qu’il puisse s’améliorer la prochaine fois, et qu’il ait plus justement conscience de ses responsabilités.

Si vous n’avez trouvé aucun problème, alors il est temps d’uploader la nouvelle version. Dans tous les autres cas, demandez au mainteneur de vous envoyer une version corrigée.


Cet article a servi de base à la rédaction de la section correspondante de la Référence du développeur Debian (cf #453313). Cliquez ici pour soutenir mon travail sur la documentation Debian.

Ceci est une traduction de mon article Best practices when sponsoring Debian packages contribuée par Weierstrass01.