Lecture de debian-private via SSH

Je me suis récemment aperçu que l'on peut consulter les archives de debian-private via SSH. Je trouve que c'est un bon compromis entre l'abonnement et l'ignorance. Voici par exemple la commande pour Novembre.

ssh -t master.debian.org mutt -f /home/debian/archive/debian-private/debian-private.201411
Posted
Fallait-il une résolution générale ?

En 2009 j'ai appelé à voter par résolution générale au sujet des règles d'adhésion à Debian, pour contrer un changement qui me semblait aller à l'encontre de nos valeurs. Le vote a causé un fort ressentiment et la question s'est posée si une synthèse aurait pu être négociée sans utiliser une procédure contraignante. Personnellement je n'étais pas convaincu, mais pas au point de ne pas avoir de doute, et donc de regrets.

Cette année nous votons à nouveau au sujet d'un changement qui semble pour certains aller à l'encontre de nos valeurs, et l'existence même du vote rend tout compromis difficile. L'amertume sera le vainqueur quel que soit le résultat. Fallait-il appeler à ce vote ? Pour écarter les doutes, j'ai proposé l'amendement numéro trois, disant que cette procédure de résolution générale n'aurait pas du être démarrée.

J'espère que cet amendement battra la proposition originale et fera réfléchir les personnes tentés de tirer la sonnette d'alarme à la prochaine occasion.

PS: l'amendement numéro trois, c'est à dire l'amendement C, c'est à dire le choix numéro quatre. S'il fallait un exemple de plus que la procédure est compliquée, le voici...

Posted
Consultation européenne sur les copyrights.

Ça y est, j'ai répondu à la Consultation publique sur la révision des règles de l’Union européenne en matière de droit d’auteur. Coïncidence, la radio diffusait European Super State de Killing Joke.

On peut voir en filigrane dans la consultation un Internet taillé sur mesure pour contrôler la diffusion et la copie des œuvres non-Libres, et surveiller les possibles infractions. Il est donc important de répondre pour rappeler la primauté de la présomption d'innocence et l'importance du respect de la vie privée.

J'ai néanmoins recommandé la minimisation des exceptions au copyright, car donner un accès gratuit temporaire aux documents non-libres, c'est aussi décourager la création d'alternatives que l'on peut copier, modifier et redistribuer librement.

Posted
Fatigué

En voulant préparer la mise à jour d'un paquet, j'ai vu une image au format PNG, et avant même de l'ouvrir je me suis senti vieux, usé, abattu, et incapable de faire face. Après inspection, c'est évident image n'a pas été faite à la main, il manque le ficher source. Une autre image dans le même répertoire a le même style et a une source au format SVG, c'est la preuve. Il manque quand même les instructions pour convertir le SVG en PNG. De plus en plus dans ces situations-là, je baisse les bras et je laisse tomber le paquet. J'ai perdu le temps et l'énergie pour exiger des auteurs des changements pour lesquels je n'ai personnellement aucun intérêt concret. Le SVG en plus du PNG, c'est mieux, mais le PNG sans SVG, pour la documentation d'un programme, c'est suffisamment libre à mon goût. Mais les points de vue exprimés sur debian-devel me donnent l'impression que ce n'est pas assez bon pour Debian, alors je laisse tomber…

Posted
La source d'un paquet développé dans un dépôt Git est ce dépôt.

Dans son blog, Lars met les mots justes sur toutes ces situations où je ressens une grande lassitude, en particulier sur tous les efforts qu'on nous demande pour que nos paquets soient modifiables par nos contributeurs qui ne peuvent, ne savent, ou ne veulent pas utiliser Git.

La plupart de nous outils de base, dpkg, debhelper, lintian ou debian-installer pour ne citer qu'eux, sont développés dans des dépôts Git. Une personne voulant contribuer au cœur de Debian peut difficilement éviter Git.

Il est temps d'adapter nos méthodes et nos outils pour prendre le meilleur parti de Git. Cela demande de dire « non merci » aux contributions qui se basent sur le paquet source dans notre archive FTP plutôt que sur le dépôt dans lequel le paquet est préparé, ce qui pose la question de quelle est la véritable source des paquets binaires, mais c'est une question que l'on peut difficilement éviter.

Posted
L'installeur Debian dans le nuage Amazon.

J'ai préparé des images machines de l'installeur Debian sur chaque région du nuage élastique Amazon, en suivant la méthode que j'avais décrite auparavant, et que j'ai mise à jour et documentée sur le wiki de Debian.

Démarrés avec un fichier de pré-configuration, ces images installent Debian à la carte sur un volume de stockage qui peut ensuite être enregistré comme une nouvelle image machine. Cette partie n'est pas encore automatique, mais j'y travaille. En attendant, il est possible d'installer Debian interactivement en utilisant la console réseau.

Posted
Mise à jour de EMBOSS explorer dans Wheezy.

EMBOSS explorer était cassé dans Debian 7 (Wheezy) pour cause d'incompatiblité avec EMBOSS 6.4. Le paquet a été réparé avec la deuxième mise à jour (7.2). Le dévelopment et la maintenance d'EMBOSS explorer sont au point mort depuis plusieurs années. Si un nouveau bug sérieux apparaît, nous risquons de devoir retirer le paquet plutôt que de le réparer. En conséquence, n'hésitez pas à nous suggerer une alternative, ou si vous êtes programmeur et que vous avez-besoin d'EMBOSS explorer, à voir comment revigorer ce projet (actuellement sur SourceForge).

Posted
Les « triggers » de Dpkg et RPM : comparaison.

Dpkg et RPM proposent un mécanisme appelé triggers en anglais. Dans le cas de Dpkg, la traduction française est actions différées. Je ne connais pas de traduction pour RPM, et la version française ne s'appliquerait pas bien, pour les raisons qui suivent.

Il existe deux types d'actions différées pour Dpkg : explicite et fichier. Dans le cas du type explicite, un script d'un paquet A va activer un paquet B. Le type fichier est plus courant. Dans ce cas, l'installation, la modification ou l'effacement par un paquet A d'un ficher dans un chemin prédéterminé par un paquet B va activer le paquet B. Les actions différées sont souvent utilisées quand un paquet A doit enregistrer une information auprès d'un paquet B. Par exemple, lorsqu'une application graphique est installée, son paquet peut ajouter sa description dans le répertoire /usr/share/applications, ce qui va activer le paquet desktop-file-utils, qui fera le nécessaire pour ajouter une entrée dans le système de menu de l'environnement graphique.

Les triggers de RPM fonctionnent différemment. L'installation, la mise à jour ou le retrait d'un paquet A va activer un paquet B si le paquet B déclare son intérêt pour le paquet A dans son fichier SPEC (en mettant des conditions sur la version du paquet A si nécessaire). Les documentations de RPM et de Fedora donnent quelques exemples d'utilisation, comme la mise à jour de liens symboliques lors du remplacement d'un serveur de courriels par un autre.

Au bout du compte, bien que les deux mécanismes portent le même nom en anglais, ils n'ont pas le même but. Dans le cas de Dpkg, les actions différées sont particulièrement utiles pour regrouper des actions similaires. Par exemple, mettre à jour la liste des pages de manuels une seule fois après l'installation de cent paquets, plutôt que cent fois après l'installation de chaque paquet. Elles servent aussi à remplacer des commandes répétées dans un grand nombre de paquets par une commande unique dans un paquet central, et ainsi faciliter l'évolution du système. Dans le cas de RPM, les triggers semblent plus spécialisées, puisqu'elles concernent à chaque instance la relation entre deux paquets.

Posted
Les « actions différées » de Dpkg bientôt dans la Charte Debian.

Dpkg permet de ré-executer le script postinst d'un paquet dans certaines conditions déclenchées par l'installation d'autres paquet. C'est le mécanismes des actions différées (« triggers » en anglais). Leur description est éparpillée entre les pages de manuel dpkg-trigger (1) et deb-triggers (5) ainsi que le fichier /usr/share/doc/dpkg-dev/triggers.txt.gz.

Pour donner un aperçu plus large et promouvoir l'utilisation des actions différées, nous allons ajouter une section à leur sujet dans la Charte Debian. Le travail en cours est bien avancé et suivi dans le bug numéro 582109. Le patch le plus récent est disponible à ce lien.

Il ne manque qu'un avis positif pour accepter ce patch. Les avis positifs (seconds en anglais) ne sont pas des avis à titre personnel, mais sont donnés quand on pense que le patch représente le consensus au sein de Debian (voir la procédure pour changer la Charte). Si après avoir inspecté le patch vous vous sentez qualifié pour donner un avis positif, il sera le bienvenu, ainsi bien sûr que tout autre commentaire ou proposition pour améliorer le texte.

Posted
A-t-on vraiment besoin de « contrib » ?

Le projet Debian distribue des paquets de logiciels via son archive, propagée à travers un réseau de miroirs. Cette archive est organisée en trois zones, main, qui contient le système Debian, et contrib et non-free qui contiennent des paquets accessoires qui ne sont pas libres. Les paquets dans non-free contiennent des fichiers dont la licence est privatrice. Les paquets source dans contrib ne contiennent que des fichiers libres, mais les paquets binaires produits sont soit inutilisables sans service extérieur, soit contiennent des fichiers non libres ou demandent l'installation de paquets non libres.

La zone contrib est l'objet de sempiternelles questions car il n'est pas toujours facile de tracer une ligne entre utilisable et inutilisable. Je me demande s'il ne vaudrait pas mieux remplacer la zone contrib par un nouveau niveau de priorité, « remote », plus bas qu'extra. Les paquets entièrement libres (source et binaire) et ne causant pas l'installation de logiciels privateurs y auraient leur place. Pour les paquets qui ne peuvent pas fonctionner sans code privateur, étant donné que l'effort sera le même pour les libérer que ce code privateur soit inclut dans le même paquet source (cas de non-free) ou non (cas de contrib), je pense qu'on devrait les placer dans non-free dans tous les cas : ils ne sont pas libres en pratique.

Cela permettrait de trancher avec un critère simple : la sélection d'un paquet binaire entraînera-t-elle l'installation de logiciels privateurs ? Si oui, le paquet et sa source appartiennent à non-free. Si non, ils appartiennent à main. Ensuite, s'ils demandent l'accès à un service extérieur impossible à mettre en place sur un réseau où seule Debian serait disponible, leur priorité sera remote.

Posted