Mon rapport mensuel couvre une grande partie de mes contributions au logiciel libre. Je l’écris pour mes donateurs (merci à eux !) mais aussi pour la communauté Debian au sens large parce que cela peut donner des idées aux nouveaux venus et que c’est également un des moyens les plus effectifs de trouver des volontaires pour travailler sur les projets qui me tiennent à cœur.

Debian LTS

Ce mois-ci ce sont 15 heures de travail sur Debian LTS qui ont été subventionnées. Elles ont été consacrées aux tâches suivantes :

• J’ai fini de travailler sur l’affichage du statut détaillé de sécurité pour chaque version supportée sur tracker.debian.org (voici un exemple);
• J’ai préparé et publié la DLA-261-2, corrigeant une régression dans la mise à jour de sécurité d’aptdaemon (régression qui ne survenait que lorsque vous aviez python 2.5 d’installé);
• J’ai préparé et publié la DLA-272-1, corrigeant 3 vulnérabilités CVE dans python-django;
• J’ai préparé et publié la DLA-286-1 corrigeant une vulnérabilité CVE dans squid3. Le patch fut plutôt compliqué à rétroporter. Heureusement l’amont fut d’une grande aide : ils ont passé en revue et testé mon patch;
• J’ai effectué une semaine de « guichet LTS », triant les vulnérabilités CVE. J’ai poussé 19 commits vers le suiveur de sécurité.

Travaux concernant Kali Linux / Debian Stretch

Kali Linux souhaite expérimenter un processus proche de Debian Constantly Usable Testing : nous avons une distribution kali-rolling – à publication continue – basée sur Debian Testing, et nous voulons en prendre un instantané tous les quatre mois (de sorte à avoir 3 versions par an).

Plus précisément, nous avons un dépôt kali-dev qui correspond exactement à Debian Stretch plus nos propres paquets Kali (ces derniers ayant priorité), mis à jour quatre fois par jour, tout comme testing. Une installation de britney2 génère également quatre fois par jour kali-rolling à partir de kali-dev (sans aucun prérequis en termes de délai ou de bogues bloquants pour la publication, juste un contrôle de dépendances cassées).

Un job jenkins contrôle que les métapaquets peuvent être installés sur kali-dev (et kali-rolling), et que nous pouvons compiler nos images ISO. Lorsque quelque chose cloche, je dois intervenir, et j’essaye de corriger d’abord côté Debian. Voici quelques exemples des actions que j’ai prises en réponse à différents problèmes :

• J’ai créé le n°791588 concernant texinfo. Il manquait une dépendance versionnée sur tex-common, et migrée trop tôt. Le paquet n’a pas pu être installé sur testing pendant quelques jours;
• J’ai créé le n°791591 concernant pinba-engine-mysql-5.5 : le paquet était ininstallable (il a du être recompilé). Il est apparu sur les fichiers de sortie de notre instance britney;
• J’ai envoyé (en tant que non-mainteneur) une version de chkrootkit, afin de corriger deux bogues bloquants pour la publication, de sorte à ce que le paquet puisse migrer vers testing. Ce paquet est installé par nos métapaquets;
• J’ai créé le n°791647 : debtags ne supporte plus « debtags update –local » (une fonctionnalité qui a été retirée, mais qui est utilisée par Kali);
• J’ai envoyé (en tant que non-mainteneur) une version de debtags, afin de corriger un bogue critique pour la publication (n°791561 debtags: dépendance manquante vis-à-vis de python3-apt et python3-debian). kali-debtags ne pouvait être installé, car il appelait debtags dans son script de post-installation;
• J’ai créé le n°791874 concernant python-guess-language, afin de demander un paquet de module compatible Python 2. Un tel paquet est présent dans Kali mais, lorsque j’ai essayé de le récupérer depuis Debian, j’ai cassé quelque chose d’autre dans Kali, qui dépend de la version Python 2 de ce paquet;
• J’ai envoyé (en tant que non-mainteneur) une version de tcpick afin de corriger une erreur de compilation avec GCC5, de sorte à ce que le paquet puisse retourner dans testing (il fait partie de nos métapaquets);
• J’ai demandé un envoi de binaire en tant que non-mainteneur pour jemalloc, et la recompilation de hiredis pour l’architecture powerpc via le n°792246. Ceci afin de corriger le #788591 (échec à la compilation de hiredis sur powerpc). J’ai également abaissé le degré de sévérité du n°784768 à « important », de sorte à ce que le paquet puisse retourner vers testing. hiredis est une dépendance d’OpenVAS, et nous avons besoin du paquet en testing.

Si vous analysez cette liste, vous pourrez constater qu’une grande partie des problèmes que nous avons rencontrés provient de paquets retirés de testing, du fait de bogues bloquants pour la publication. Nous devrions être capables d’anticiper ces soucis et de suivre les paquets qui ont un impact sur Kali. Nous allons probablement ajouter un nouveau job jenkins qui installe tous les métapaquets et lance how-can-i-help -s testing-autorm --old… Je viens de soumettre le n°94238 listant nos demandes d’amélioration concernant how-can-i-help.

Dans le même temps, des bogues sont apparus du côté de testing, que j’ai corrigés ou pour lesquels j’ai trouvé une solution de contournement côté Kali. Mais ces corrections/solutions alternatives pourraient être plus utiles si elles étaient poussées vers testing via testing-proposed-updates. J’ai essayé de voir si d’autres distributions dérivées avaient des besoins similaires, afin de savoir si nous pouvions joindre nos efforts à ce niveau. Ce qui ne semble pas le cas pour l’instant.

Last but not least, des bogues remontés côté Kali ont également eu pour résultats des améliorations côté Debian :

• J’ai créé le n°793360 concernant apt (APT::Never-MarkAuto-Sections ne fonctionne pas comme décrit). J’ai également soumis un patch;
• J’ai déclaré dnswalk comme orphelin, et ai effectué un upload QA afin de corriger son seul bogue;
• Nous souhaitions une nouvelle version des pilotes nvidia. J’ai créé le n°793079, demandant la nouvelle version amont, et le mainteneur l’a rapidement envoyée vers experimental. Je l’ai importée vers Kali mais j’ai découvert que cette version ne fonctionnait pas sur i386. J’ai donc soumis le #793160, avec un patch;
• J’ai remarqué que les daemons de compilation de Kali avaient tendance à accumuler de nombreux points de montage /dev/shm, et j’ai creusé le problème jusqu’à remonter à schroot. J’ai remonté le souci via le n°793081.

Autres travaux Debian

Parrainage J’ai parrainé de multiples paquets pour Daniel Stender, qui empaquète prospector, un logiciel dont j’ai fait la demande précédemment (à travers un rapport de bogue RFP). J’ai donc passé en revue et poussé python-requirements-detector, python-setoptconf, pylint-celery et pylint-common. Lors d’une de ces revues j’ai également découvert un joli bogue dans dh-python (n°793609 : un commentaire au milieu d’un Build-Depends peut casser un paquet). J’ai aussi parrainé un envoi de notmuch-addrlookup (un nouveau paquet demandé par un client de Freexian).

Empaquetage J’ai poussé python-django 1.7.9 dans unstable et 1.8.3 dans experimental, afin de corriger des problèmes de sécurité. J’ai de même uploadé une version amont de ditaa en tant que non-mainteneur (ici encore à la demande d’un client de Freexian).

Distro Tracker Au-delà du travail réalisé pour intégrer un statut de sécurité détaillé, j’ai corrigé le code pour qu’il soit compatible avec Django 1.8, et modifié la configuration tox, de sorte à ce que la suite de tests soit régulièrement déroulée avec Django 1.8. J’ai aussi fusionné de multiples patchs de Christophe Siraut (cf. le n°784151 et le n°754413).

Merci

Rendez-vous au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Free Software Activities in July 2015 contribuée par Weierstrass01.