Qui a fini DEP 5 ?

Beaucoup de monde a travaillé à finir DEP 5. Je trouve que le blog de Lars ne montre pas assez l'aspect collectif du processus.

Si l'on regarde dans le texte de la spécification, on y trouve:

The following alphabetical list is incomplete; please suggest missing people:
Russ Allbery, Ben Finney, Sam Hocevar, Steve Langasek, Charles Plessy, Noah
Slater, Jonas Smedegaard, Lars Wirzenius.

Le journal des changements de la charte Debian mentionne:

  * Include the new (optional) copyright format that was drafted as DEP-5.
    This is not yet a final version; that's expected to come in the
    3.9.3.0 release.  Thanks to all the DEP-5 contributors and to Lars
    Wirzenius and Charles Plessy for the integration into the Policy
    package.  (Closes: #609160)

 -- Russ Allbery <rra@debian.org>  Wed, 06 Apr 2011 22:48:55 -0700

et

debian-policy (3.9.3.0) unstable; urgency=low

  [ Russ Allbery ]
  * Update the copyright format document to the version of DEP-5 from the
    DEP web site and apply additional changes from subsequent discussion
    in debian-devel and debian-project.  Revise for clarity, to add more
    examples, and to update the GFDL license versions.  Thanks, Steve
    Langasek, Charles Plessy, Justin B Rye, and Jonathan Nieder.
    (Closes: #658209, #648387)

Pour ma part, je suis très reconnaissant à Bill Alombert d'avoir enregistré le document dans le dépôt Git, ce qui a mis fin aux débats.

Posted
Nuage Amazon : remise à niveau.

Cela faisait quelques années que je n'avais pas fait de travail sérieux utilisant le nuage Amazon. Il m'a fallu un petit moment pour retrouver mes marques et m'adapter aux changements. En particulier, les instances à plus petit prix, t2.nano ne sont plus accessible que depuis les nuages virtuels privés (« Virtual Private Cloud », VPC), et j'ai eu un peu de mal à trouver comment en créer un simple. Je pense qu'une des raisons est que les utilisateurs arrivés après le 18 mars 2013 on automatiquement un VPC par défaut et que les autres ont déjà créé leur VPC depuis longtemps. Au final, ce n'était pas compliqué du tout. C'est certainement pour ça que je n'avais pas trouvé de tutoriel à ce sujet.

En résumé il faut d'abords créer un VPC. Pour lancer une instance de temps en temps, la plage IP privée importe peu. Les VPCs par défaut utilisent 172.31.0.0/16; alors faisons de même.

CIDR_BLOCK=172.31.0.0/16
aws ec2 create-vpc --cidr-block $CIDR_BLOCK

La commande renvoie un identifiant de VPC, que je stocke à la main dans la variable VPC par copié-collé. Le même principe sera répété pour chaque commande créant quelque chose. On peut retrouver l'identifiant avec la commande aws ec2 describe-vpcs.

VPC=vpc-XXXXXXXX  # Et ainsi de suite

Après, créer un sous-réseau. Là encore, pas la peine de faire compliqué, on peut lui donner la plage IP entière. Je récupère l'identifiant renvoyé et le stocke dans la variable SUBNET. Pour que les instances reçoivent une IP publique comme dans les VPCs par défaut et l'ancien comportement du nuage sans VPC, il faut activer l'attribut MapPublicIpOnLaunch.

aws ec2 create-subnet --vpc-id $VPC --cidr-block $CIDR_BLOCK
SUBNET=subnet-XXXXXXXX
aws ec2 modify-subnet-attribute --subnet-id $SUBNET --map-public-ip-on-launch 

Ensuite, créer une passerelle (je récupère l'identifiant dans GATEWAY) et l'attacher au VPC.

aws ec2 create-internet-gateway
GATEWAY=igw-XXXXXXXX
aws ec2 attach-internet-gateway --internet-gateway-id $GATEWAY --vpc-id $VPC

Une table de routage a été créée automatiquement, et on peut trouver son identifiant via la commande describe-route-tables, pour créer ensuite une route par défaut vers la passerelle.

aws ec2 describe-route-tables
ROUTETABLE=rtb-XXXXXXXX
aws ec2 create-route --route-table-id $ROUTETABLE --destination-cidr-block 0.0.0.0/0 --gateway-id $GATEWAY

Bien sûr, si on n'ouvre pas le trafic, on ne pourra pas contacter la machine... Ici, j'ouvre le port 22 pour un accès SSH.

aws ec2 describe-security-groups
SECURITY_GROUP=sg-XXXXXXXX
aws ec2 authorize-security-group-ingress --group-id $SECURITY_GROUP --protocol tcp --port 22 --cidr 0.0.0.0/0

Autre changement, Amazon distribue maintenant des outils libres pour la ligne de commande, qui sont plus complets qu'euca2ools.

Prochaine étape, je vais recommencer les tests utilisant l'installeur Debian dans le Nuage.

Posted
La pente glissante.

Étape par étape, on glisse vers le fond :

  1. Il faut s'exprimer durement avec ceux qui ont tort.
  2. On s'exprime durement quand on a raison.
  3. Quand on pense qu'on a raison, on est s'exprime durement.
  4. On a tort et on s'exprime durement.

Notons tout de même qu'on peut toucher le fond sans être vulgaire ou insultant. Dans tout grand projet comme Debian, on finit par trouver quelques gens qui savent être très oppressants, tout en restant très « corrects ». Debian est vaste, et il est facile de les éviter, mais dès que l'on s'essaye à des contributions qui collent à des mots-clés tels que « comité », « code », « charte », « délégation », etc., il vaut mieux ressortir la bonne vielle peau dure du placard où on l'avait rangée après l'adoption de notre nouveau code de conduite...

Posted
Longue vie à Jessie !

Debian a publié Jessie le mois dernier. Toutes mes félicitations à l'équipe de publication et tous les contributeurs; la qualité est encore au rendez-vous !

Cette fois-ci, je n'ai pas pu contribuer grand chose, étant accaparé par des activités parentales (coucou mon fils, si tu me lis), si ce n'est de m'assurer que mes paquets soient en bon état pour le Jour J. Ce travail a été grandement facilité par le système de radiation automatique des paquets buggés, mis en place par l'équipe de publication. Un grand bravo pour ce développement.

J'espère utiliser Jessie longtemps sans avoir besoin de mettre à jour vers la version de test. Pour le moment j'ai tout ce qui me faut, y compris la cohabitation entre la saisie du Japonais et le basculement entre agencements japonais (ou américain) et canadien multilingue, ce qui n'était plus possible facilement sous Wheezy.

Encore merci.

Posted
Nouvelles du paquet mime-support.

Le paquet mime-support est installé par défaut dans les systèmes Debian. Il a deux rôles: premièrement fournir le fichier /etc/mime.types qui associe des types de médias (anciennement appelés types MIME) à des suffixes de noms de fichiers, et deuxièmement mettre en place le système mailcap, qui associe des type de média à des programmes. J'ai adopté ce paquet à la fin du cycle de développement de Wheezy.

Changements depuis Wheezy.

La version distribuée dans Jessie apporte quelques additions dans /etc/mime.types. Parmi elles, application/vnd.debian.binary-package et text/vnd.debian.copyright, qui comme leurs noms l'indiquent décrivent des formats de fichiers conçus par Debian. J'ai enregistré ces types auprès de l'IANA, qui depuis la RFC 6838 est beaucoup plus ouverte à l'addition de nouveaux types.

Le changement le plus important consiste à extraire automatiquement les associations entre programmes et types de média qui sont déclarées dans les fichiers de menu au format FreeDesktop. Ces fichiers sont souvent fournis directement amont. Auparavant c'est le responsable du paquet Debian qui devait extraire l'information et la traduire à la main au format mailcap. L'automatisation se fait via des actions différées de dpkg.

Un grand merci à Kevin Ryde qui m'a apporté une aide précieuse pour les développement et corrections apportées au programme run-mailcap, et à tous les autres contributeurs. Votre aide est toujours bienvenue !

Mise à jour de sécurité.

En décembre, Debian a été contacté par Timothy D. Morgan, qui avait trouvé qu'un attaquant pouvait faire exécuter des commandes à run-mailcap en les insérant dans des noms de fichiers (CVE-2014-7209). Cette première mise à jour de sécurité pour moi s'est bien passée, un grand merci à Salvatore Bonaccorso de l'équipe sécurité pour son aide et ses instructions. Le problème est résolu dans Wheezy, Jessie et Sid, ainsi que dans Squeeze via son projet de suivi à long terme.

Une des conséquences de cette mise à jour est que run-mailcap va systématiquement utiliser le chemin absolu vers les fichiers à ouvrir. Pour les fichiers aux noms sans danger, c'est un peu laid. Cela sera peut-être amélioré après la sortie de Jessie.

Projets pour le futur

Le fichier /etc/mime.types est tenu à jour à la main; c'est lent et inefficace. Le paquet shared-mime-info contient des informations équivalentes, qui pourraient être utilisées pour autogénérer ce fichier, mais cela demanderait de traiter une source XML assez complexe. Pour le moment je pense importer le paquet mailcap de chez Fedora, dont le fichier /etc/mime.types est très bien tenu à jour. Je n'ai pas encore décidé comment faire, mais peut-être simplement en transférant ce fichier d'un paquet à l'autre. Dans ce cas, on se retrouverait avec un paquet mime-support qui en fait fournit le système mailcap, et un paquet dont le nom de la source chez Fedora est mailcap, mais dont le rôle dans Debian serait de fournir /etc/mime.types. Peut-être sera-t-il préférable d'utiliser des noms de paquets binaires plus clairs, comme mailcap-support pour le premier et media-types pour le second ?

La séparation des deux fonctions premières de mime-support aurait une autre conséquence intéressante: la possibilité de ne pas installer la prise en charge du système mailcap ou de la rendre optionnelle, et d'utiliser le système FreeDesktop (xdg-open), du paquet xdg-utils. Une idée à creuser...

Posted
nodejs-legacy

apt install nodejs-legacy, sinon npm install ne fonctionnera pas.

Posted
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