17 May 2016

Raphaël Hertzog

Mes activités libres en avril 2016

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

J’ai pris en charge une nouvelle proposition de sponsoring, de la part d’une société souhaitant voir Wheezy continuer à supporter les architectures armel et armhf. Cela ne faisait pas partie de nos plans initiaux (arrêtés lors de la dernière DebConf) et, en conséquence, j’ai envoyé un message à toutes les équipes impactées de sorte à ce que ce changement, s’il devait survenir, soit approuvé collectivement. Alors que je m’attendais à recevoir une réponse claire assez rapidement, il s’est avéré que nous ne sommes jamais parvenus à obtenir un retour de la part de toutes les parties impliquées. La discussion a dérivé, à la place, sur la question plus générale de savoir comment nous devions traiter le sponsoring/donation au sein du projet LTS.

Fort heureusement, les mainteneurs de buildd ont confirmé être d’accord avec ce changemement, tandis que les ftpmasters n’y voyaient pas d’objections, ce qui a implicitement acté cette décision. Ansgar Burchardt a conservé les architectures armel/armhf dans le dépôt wheezy/updates lorsque le support a basculé du côté de l’équipe LTS, et Aurélien Jarno a configuré wanna-build de sorte à ce qu’il continue de compiler armel/armhf pour la suite. L’équipe DSA n’a pas confirmé que ce changement n’entrait pas en conflit avec l’un de leurs projets de mise hors service de matériels. Quoi qu’il en soit, les démons de compilation constituent des ressources partagées, et un seul serveur gère généralement la compilation des paquets pour plusieurs versions de Debian.

DebConf 16

Je me suis inscrit ce mois-ci pour la DebConf 16, et soumis plusieurs propositions de sujets pour des présentations/tables rondes :

  • Retour d’expérience de Kali Linux en tant que distribution dérivée de Debian, basée sur Testing (présentation);
  • Deux années de travail, réalisées par des contributeurs rémunérés, au sein du projet Debian LTS (présentation);
  • Utiliser l’argent de Debian pour financer les projets Debian (table ronde).

Je souhaite partager la configuration que nous utilisons dans Kali, dans la mesure où elle pourrait être utile à d’autres distributions dérivées, mais aussi à Debian elle-même, afin de faciliter les échanges avec les distributions dérivées.

Je souhaite également rouvrir le débat concernant l’utilisation de l’argent au sein de Debian. C’est un sujet difficile que nous devrions vraiment aborder, afin d’arrêter officiellement une position sur ce qu’il est possible de faire, ou de ne pas faire, avec cet argent. Debian LTS a permis de démontrer que l’argent pouvait être utilisé dans une certaine mesure, sans que cela n’affecte le projet Debian en tant que tel. Est-ce que cela peut être transposé à d’autres équipes ou projets ? Quelles sont les limites ? Pouvons-nous définir un cadre d’utilisation et clarifier les règles ? je m’attends à une table ronde très intéressante. Mehdi Dogguy a accepté d’animer cette table ronde avec moi.

Empaquetage

Django J’ai poussé la version 1.8.12 vers jessie-backports, ainsi que la version 1.9.5 vers unstable. J’ai créé deux rapports de bogue auprès de l’amont (n°26473 et n°26474) pour des problèmes repérés grâce à lintian.

Malheureusement, lorsque j’ai voulu faire de même vers unstable, la suite de tests n’a pas fonctionné. Après analyse, j’ai attribué cela à une régression dans SQLite. Chris Lamb a créé le rapport de bogue n°820225, et j’ai contacté les développeurs amont Django et SQLite par email, pour leur indiquer le souci. J’ai aidé l’auteur amont SQLite (Richard Hipp) à reproduire le problème, après quoi il a soumis très rapidement un patch, qui a atterri dans la version 3.12.1.

J’ai réalisé plus tard dans le mois un autre envoi, pour corriger un bogue de mise à jour (cf. le n°821789).

GNOME 3.20 Comme pour chaque nouvelle version, j’ai mis à jour gnome-shell-timer, de sorte à ce qu’il fonctionne avec le nouveau GNOME. J’y ai passé cette fois-ci un peu plus de temps qu’à l’habitude, afin de corriger une régression (cf. le n°805347) datant d’il y a bien longtemps déjà, et qui n’aurait jamais été corrigée autrement, l’auteur amont ayant déclaré orpheline cette extension (n’utilisant lui-même plus GNOME).

J’ai également rencontré des problèmes d’affichage, à savoir que les caractères accentués étaient affichés sous les caractères suivants. Avec l’aide de membres de l’équipe GNOME, nous avons découvert qu’il s’agissait d’un problème spécifique à la police cantarell, et n’était déclenché qu’avec Harfbuzz 1.2. C’est consigné dans Debian via le bogue n°822682 en ce qui concerne harfbuzz, et n°822762 pour ce qui est de fonts-cantarell. Une nouvelle version amont (incluant le correctif) est prête à être empaquetée, mais reste malheureusement bloquée par l’absence d’une version récente de fontforge dans Debian. J’ai donc contacté debian-mentors dans l’espoir de trouver des volontaires qui pourraient aider l’équipe pkg-fonts à en empaqueter une version plus récente…

Travaux divers Debian/Kali

Distro Tracker J’ai commencé à parrainer Vladimir Likic, qui m’a contacté dans le but de contribuer au Distro Tracker. Je l’ai aidé à mettre en place son environnement de développement, et nous avons corrigé quelques problèmes ce faisant.

Rapports de bogues J’ai créé de nombreux rapports de bogue, la plupart du fait de mon travail pour Kali :

  • n°820288: requête demandant le maintien d’un paquet WordPress installable sur les versions anciennes (du fait du renommage de nombreux paquets php);
  • n°820660: requête demandant le support des index by-hash dans reprepro;
  • n°820867: possibilité de surcharger la priorité de paquets déjà installés dans reprepro;
  • n°821070: problème de samba-vfs-modules lors de la mise à jour de jessie vers stretch;
  • n°822157: python-future masque et casse python-configparser;
  • n°822669: dh_installinit ajoute des autoscript inutiles pour les scripts System V, lorsque le paquet n’en contient aucun;
  • n°822670: dh-systemd devrait être fusionné avec debhelper, car nous disposons de systemd par défaut, et debhelper devrait le supporter correctement par défaut.

J’ai également étudié le n°819958 qui affecte testing, dans la mesure où il a été remonté dans Kali également. J’ai réalisé un envoi de dh-make-golang en tant que non-mainteneur, afin de corriger le problème du n°819472, que j’avais rapporté auparavant.

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 April 2016 contribuée par Weierstrass01.

Aucun commentaire pour le moment | Vous avez aimé ? Cliquez ici. | Ce blog utilise Flattr.

17 May, 2016 10:07AM par Raphaël Hertzog

02 May 2016

Vincent Bernat

Petit traité empirique de l'empaquetage Debian

Bien que la création de paquets Debian soit abondamment documentée, la plupart des tutoriaux ciblent les paquets respectueux de la charte Debian. De plus, leur création a longtemps eu la réputation d’être particulièrement difficile1 et beaucoup se sont tournés vers des outils moins contraignants2 tels que fpm ou CheckInstall.

Toutefois, je vais montrer que la construction de paquets Debian en utilisant les outils officiels est plutôt simple en appliquant ces quelques concessions :

  1. Aucun paquet source ne sera généré. Les paquets seront construits directement depuis une copie propre issue du système de versions.

  2. Des dépendances supplémentaires peuvent être téléchargées pendant la construction. Empaqueter individuellement chaque dépendance est un travail ingrat, notamment avec certains environnements tels que Java, Javascript et Go.

  3. Les paquets produits peuvent combiner et inclure des dépendances tierces. Cela peut lever certaines objections liées à la sécurité et à la maintenance à long terme, mais c’est une concession courante dans certains écosystèmes tels que Java, Javascript et Go.

Ceinture blanche§

Deux types de paquets coexistent dans l’archive Debian : les paquets sources et les paquets binaires. Un paquet source produit un ou plusieurs paquets binaires. Chaque paquet doit porter un nom.

Comme indiqué lors de l’introduction, aucun paquet source ne sera construit. Nous allons travailler directement sur sa représentation décompressée : une arborescence de fichiers incluant le répertoire debian/. Les exemples qui suivent utilisent une arborescence composée uniquement du répertoire debian/, mais ce dernier peut être inclus dans n’importe quel project existant.

Comme point de départ, nous allons empaqueter memcached, un cache mémoire distribué. Il nous faut créer quatre fichiers :

  • debian/compat,
  • debian/changelog,
  • debian/control et
  • debian/rules.

Le premier contient uniquement 9 :

echo 9 > debian/compat

Le second contient ceci :

memcached (0-0) UNRELEASED; urgency=medium

  * Fake entry

 -- Happy Packager <happy@example.com>  Tue, 19 Apr 2016 22:27:05 +0200

La seule information d’importance est le nom du paquet source, memcached, sur la première ligne. Toutes les autres informations sont sans influence sur les paquets créés.

Le fichier de contrôle§

debian/control décrit les méta-données à propos du paquet source et des paquets binaires. Un bloc est dédié à chacun d’eux.

Source: memcached
Maintainer: Vincent Bernat <bernat@debian.org>

Package: memcached
Architecture: any
Description: high-performance memory object caching system

Le paquet source est memcached. Il faut utiliser le même nom que dans le fichier debian/changelog.

Un seul paquet binaire est créé : memcached. Par la suite, si vous voyez memcached, il s’agit du nom du paquet binaire. The champ Architecture doit être soit any, soit all. Ce dernier est utilisé exclusivement si tous les fichiers sont indépendants de l’architecture matérielle. Dans le doute, il suffit de mettre any.

Le champ Description contient une courte description du paquet binaire.

La recette§

Le dernier fichier à rédiger est debian/rules. Il s’agit de la recette du paquet. Nous avons besoin de télécharger memcached, le construire et installer son arborescence dans debian/memcached/ :

#!/usr/bin/make -f

DISTRIBUTION = $(shell lsb_release -sr)
VERSION = 1.4.25
PACKAGEVERSION = $(VERSION)-0~$(DISTRIBUTION)0
TARBALL = memcached-$(VERSION).tar.gz
URL = http://www.memcached.org/files/$(TARBALL)

%:
    dh $@

override_dh_auto_clean:
override_dh_auto_test:
override_dh_auto_build:
override_dh_auto_install:
    wget -N --progress=dot:mega $(URL)
    tar --strip-components=1 -xf $(TARBALL)
    ./configure --prefix=/usr
    make
    make install DESTDIR=debian/memcached

override_dh_gencontrol:
    dh_gencontrol -- -v$(PACKAGEVERSION)

Les cibles vides override_dh_auto_clean, override_dh_auto_test et override_dh_auto_build permettent de s’assurer que debhelper ne fera rien de « magique ». La cible override_dh_gencontrol permet de spécifier la version3 sans avoir à tenir à jour debian/changelog. Cette recette est très similaire à ce qui aurait été écrit pour fpm :

DISTRIBUTION=$(lsb_release -sr)
VERSION=1.4.25
PACKAGEVERSION=${VERSION}-0~${DISTRIBUTION}0
TARBALL=memcached-${VERSION}.tar.gz
URL=http://www.memcached.org/files/${TARBALL}

wget -N --progress=dot:mega ${URL}
tar --strip-components=1 -xf ${TARBALL}
./configure --prefix=/usr
make
make install DESTDIR=/tmp/installdir

# Build the final package
fpm -s dir -t deb \
    -n memcached \
    -v ${PACKAGEVERSION} \
    -C /tmp/installdir \
    --description "high-performance memory object caching system"

Vous pouvez lire le résultat final sur GitHub et le construire avec la commande dpkg-buildpackage -us -uc -b.

Ceinture jaune§

À partir de là, il est possible d’inclure quelques améliorations. Aucune n’est essentielle mais le gain est suffisamment intéressant pour justifier l’effort.

Les dépendances sources§

Notre recette initiale ne fonctionne que si nous disposons déjà de wget et de libevent-dev. Ces paquets ne sont pas présents sur tous les systèmes. Il est assez aisé de spécifier ces dépendances en ajoutant un champ Build-Depends dans debian/control :

Source: memcached
Build-Depends: debhelper (>= 9),
               wget, ca-certificates, lsb-release,
               libevent-dev

Il faut toujours spécifier debhelper (>= 9) car son utilisation est centrale dans debian/rules. Il n’y a pas besoin de dépendre de make ou d’un compilateur C car le paquet build-essential est considéré comme toujours présent et il les fournit indirectement. dpkg-buildpackage se plaindra si une des dépendances est manquante. Pour installer sans peine ces paquets, vous pouvez utiliser la commande suivante4 :

mk-build-deps \
    -t 'apt-get -o Debug::pkgProblemResolver=yes --no-install-recommends -qqy' \
    -i -r debian/control

Il est aussi intéressant de se pencher sur des outils tels que pbuilder et sbuild qui permettent de construire des paquets dans un environnment minimal et isolé.

Les dépendances binaires§

Si le paquet ainsi construit est installé sur une machine vierge, memcached refusera de démarrer en raison de l’absence de libevent. Il est possible d’exprimer cette dépendance en ajoutant un champ Depends dans le fichier debian/control. De plus, dans le cas des bibliothèques dynamiques, ces dépendances peuvent être générées automatiquement en utilisant des variables de substitution :

Package: memcached
Depends: ${misc:Depends}, ${shlibs:Depends}

Le paquet construit contiendra les informations suivantes :

$ dpkg -I ../memcached_1.4.25-0\~unstable0_amd64.deb | grep Depends
 Depends: libc6 (>= 2.17), libevent-2.0-5 (>= 2.0.10-stable)

Intérgration avec un système de démarrage§

La plupart des paquets fournissant un démon incluent une intégration avec le système de démarrage afin de démarrer le démon au boot ou de le redémarrer après une mise à jour. Pour les distributions basées sur Debian, il existe plusieurs systèmes de démarrage. Voici les trois plus courants.

  • System-V est le système historique. Ces scripts de démarrage peuvent être réutilisés par les autres systèmes. Il s’agit donc du plus petit dénominateur commun.
  • Upstart est le système popularisé par Ubuntu. Il est utilisé jusqu’à la version 14.10, incluse.
  • systemd est le système par défaut pour Debian depuis Jessie et pour Ubuntu depuis la version 15.04.

Écrire un script de démarrage pour System-V est une tâche ardue. Habituellement, je préfère donc simplement fournir un script pour le système de démarrage par défaut de la distribution visée (Upstart et systemd).

System-V§

Si vous voulez écrire un script de démarrage pour System-V, adaptez5 le script /etc/init.d/skeleton de la distribution la plus ancienne que vous souhaitez supporter. Mettez le résultat dans le fichier debian/memcached.init. Il sera installé au bon endroit et invoqué lors de l’installation, mise à jour ou retrait du paquet. Habituellement, l’utilisateur peut personnaliser les options du démon en modifiant le fichier /etc/default/memcached. Pour en fournir un, placez son contenu dans le fichier debian/memcached.default.

Upstart§

Fournir un script pour Upstart est similaire : son contenu doit être placé dans debian/memcached.upstart. Par exemple :

description "memcached daemon"

start on runlevel [2345]
stop on runlevel [!2345]
respawn
respawn limit 5 60
expect daemon

script
  . /etc/default/memcached
  exec memcached -d -u $USER -p $PORT -m $CACHESIZE -c $MAXCONN $OPTIONS
end script

La directive la plus importante à surveiller est expect. Ici, nous utilisons expect daemon et memcached est démarré avec l’option -d.

systemd§

Fournir un script pour systemd est un tout petit peu plus compliqué. Le contenu doit se placer dans debian/memcached.service. Par exemple :

[Unit]
Description=memcached daemon
After=network.target

[Service]
Type=forking
EnvironmentFile=/etc/default/memcached
ExecStart=/usr/bin/memcached -d -u $USER -p $PORT -m $CACHESIZE -c $MAXCONN $OPTIONS
Restart=on-failure

[Install]
WantedBy=multi-user.target

Bien que cela ne soit pas considéré comme une bonne pratique6, nous réutilisons /etc/default/memcached. Comme pour Upstart, la directive Type est particulièrement importante. Nous utilisons forking car memcached est démarré avec l’option -d.

Il est également nécessaire d’ajouter une dépendance source sur dh-systemd dans debian/control :

Source: memcached
Build-Depends: debhelper (>= 9),
               wget, ca-certificates, lsb-release,
               libevent-dev,
               dh-systemd

Il faut également modifier la règle par défaut dans debian/rules :

%:
    dh $@ --with systemd

Cette complexité supplémetaire est regrettable et est dû au fait que l’intégration de systemd ne fait pas partie de debhelper7. Sans ces modifications, le script sera installé mais l’intégration n’aura pas lieu et il ne sera pas lancé au démarrage de la machine.

Utilisateur dédié§

De nombreux démons n’ont pas besoin de s’exécuter en tant que root et c’est souvent une bonne idée de fournir un utilisateur dédié. Dans le cas de memcached, nous allons fournir l’utilisateur _memcached8.

Ajoutez un fichier debian/memcached.postinst avec le contenu suivant :

#!/bin/sh

set -e

case "$1" in
    configure)
        adduser --system --disabled-password --disabled-login --home /var/empty \
                --no-create-home --quiet --force-badname --group _memcached
        ;;
esac

#DEBHELPER#

exit 0

Lorsque le paquet est désinstallé, aucun ménage n’est effectué :

  • moins de code à écrire, moins de bugs,
  • l’utilisateur peut toujours posséder quelques fichiers sur le système.

L’utilitaire adduser effectuera toujours la bonne action que l’utilisateur demandé existe déjà ou non. Il faut penser à l’ajouter comme dépendance binaire dans debian/control :

Package: memcached
Depends: ${misc:Depends}, ${shlibs:Depends}, adduser

Le marqueur #DEBHELPER# indique le point d’insertion pour des scripts d’intégration supplémentaires.

Le résultat final est disponible sur GitHub et peut être testé avec la commande dpkg-buildpackage -us -uc -b.

Ceinture verte§

Il est possible d’exploiter certaines capacités de debhelper pour réduire la taille du fichier debian/rules et pour le rendre plus déclaratif. Cette section est totalement optionnelle : vous pouvez la sauter si besoin.

Banalités§

Il y a quatre étapes dans la construction d’un paquet Debian :

  1. debian/rules clean va nettoyer l’arborescence pour revenir dans son état initial.

  2. debian/rules build doit construire le logiciel. Pour quelque chose de basé sur autoconf, comme memcached, il s’agit essentiellement d’exécuter ./configure && make.

  3. debian/rules install doit installer l’arborescence de chaque paquet binaire dans le répertoire approprié. Pour des logiciels basés sur autoconf, il s’agit d’exécuter make install DESTDIR=debian/memcached.

  4. debian/rules binary doit empaqueter les différentes arborescences en paquets binaires.

Il ne faut pas écrire directement chacune de ces cibles. L’utilitaire dh, un composant de debhelper, va faire la majeure partie du boulot. Le fichier debian/rules minimaliste suivant suffit pour accomplir cette tâche pour de nombreux paquets sources :

#!/usr/bin/make -f
%:
    dh $@

Pour chacune des quatre cibles décrites ci-dessus, vous pouvez exécuter dh --no-act pour voir les utilitaires invoqués. Par exemple :

$ dh build --no-act
   dh_testdir
   dh_update_autotools_config
   dh_auto_configure
   dh_auto_build
   dh_auto_test

Chacun de ces utilitaires dispose d’une page de manuel. Ceux commençant par dh_auto sont un peu « magiques ». Par exemple, dh_auto_configure va tenter de configurer automatiquement le logiciel avant l’étape de construction. Selon les cas, il peut invoquer ./configure, cmake ou Makefile.PL.

Si un des utilitaires dh_ ne fait pas ce qu’il faut, il est possible de le remplacer en déclarant une cible nommée de manière adéquate :

override_dh_auto_configure:
    ./configure --with-some-grog

Chaque utilitaire est également configurable via des options. Ainsi, il est possible de modifier leurs comportements en définissant la cible correspondante et en invoquant l’utilitaire manuellement :

override_dh_auto_configure:
    dh_auto_configure -- --with-some-grog

Ainsi, ./configure sera appelé avec l’option --with-some-grog mais aussi avec des options par défaut telles que --prefix=/usr.

Dans l’exemple initial de memcached, ces cibles « magiques » sont surchargées. dh_auto_clean, dh_auto_configure et dh_auto_build ont été neutralisées pour éviter tout comportement inattendu. dh_auto_install a été détournée pour exécuter l’intégralité de la construction de l’arborescence cible. De plus, le comportement de dh_gencontrol a été modifié en lui fournissant le numéro de version désiré plutôt que de le laisser regarder dans debian/changelog.

Construction automatique§

memcached utilisant autoconf, dh sait comment le construire : ./configure && make && make install. Il est donc possible de laisser dh faire la majeure partie du boulot avec le fichier debian/rules suivant :

#!/usr/bin/make -f

DISTRIBUTION = $(shell lsb_release -sr)
VERSION = 1.4.25
PACKAGEVERSION = $(VERSION)-0~$(DISTRIBUTION)0
TARBALL = memcached-$(VERSION).tar.gz
URL = http://www.memcached.org/files/$(TARBALL)

%:
    dh $@ --with systemd

override_dh_auto_clean:
    wget -N --progress=dot:mega $(URL)
    tar --strip-components=1 -xf $(TARBALL)

override_dh_auto_test:
    # Don't run the whitespace test
    rm t/whitespace.t
    dh_auto_test

override_dh_gencontrol:
    dh_gencontrol -- -v$(PACKAGEVERSION)

La cible dh_auto_clean est détournée pour effectuer le téléchargement et la mise en place de l’arborescence9. Ni dh_auto_configure, ni dh_auto_build ne sont modifiés. dh appellera ./configure avec les options appropriées puis make. dh_auto_test doit exécuter la suite de tests de memcached. Toutefois, un des tests échoue en raison d’un fichier dans le répertoire debian/. Nous supprimons ce test récalcitrant et invoquons manuellement dh_auto_test. dh_auto_install n’est pas surchargé et dh exécutera alors une variante de make install.

Afin de mieux apprécier la différence, la voici sous forme de patch :

--- memcached-intermediate/debian/rules 2016-04-30 14:02:37.425593362 +0200
+++ memcached/debian/rules  2016-05-01 14:55:15.815063835 +0200
@@ -12,10 +12,9 @@
 override_dh_auto_clean:
-override_dh_auto_test:
-override_dh_auto_build:
-override_dh_auto_install:
    wget -N --progress=dot:mega $(URL)
    tar --strip-components=1 -xf $(TARBALL)
-   ./configure --prefix=/usr
-   make
-   make install DESTDIR=debian/memcached
+
+override_dh_auto_test:
+   # Don't run the whitespace test
+   rm t/whitespace.t
+   dh_auto_test

Vous avez le choix de laisser dh faire une partie du travail ou non. Il est généralement possible de partir d’un debian/rules minimal et de surcharger uniquement quelques cibles.

Fichiers supplémentaires§

Bien que make install ait installé les fichiers essentiels pour memcached, il est parfois nécessaire de copier quelques fichiers supplémentaires dans le paquet binaire. Pour se faire, il est possible d’utiliser cp ou encore de déclarer les fichiers à copier :

  • les fichiers listés dans debian/memcached.docs seront copiés dans /usr/share/doc/memcached par dh_installdocs,
  • les fichiers listés dans debian/memcached.examples seront copiés dans /usr/share/doc/memcached/examples par dh_installexamples,
  • les fichiers listés dans debian/memcached.manpages seront copiés dans le sous-répertoire approprié de /usr/share/man par dh_installman,

Voici un exemple pour debian/memcached.docs :

doc/*.txt

Si vous avez besoin de copier des fichiers à un endroit arbitraire, il est possible de lister ceux-ci ainsi que leur répertoire cible dans le fichier debian/memcached.install. dh_install se chargera de la copie. Par exemple :

scripts/memcached-tool usr/bin

L’utilisation de ces fichiers permet une description plus déclarative de la recette. Il s’agit d’une histoire de goût et vous pouvez tout à fait utiliser cp à la place. Le résultat final est visible sur GitHub.

Autres exemples§

Le dépôt GitHub comprend d’autres exemples. Ils suivent tous le même schéma et mettent en œuvre les techniques décrites dans les sections précédentes.

Il y a notamment des exemples de démons en Java, Go, Python et Node.js. Le but de ces exemples est de démontrer que l’utilisation des outils Debian est relativement simple. Mission accomplie ?


  1. La mémoire collective est toujours marquée par la glorieuse époque précédant l’introduction de debhelper 7.0.50 (circa 2009). La création du fichier debian/rules était alors particulièrement laborieuse. Toutefois, de nos jours, le squelette est devenu minimal. 

  2. La complexité n’est pas la seule raison de ce choix : les outils alternatifs proposent également la création de paquets RPM, ce que les outils Debian ne permettent pas. 

  3. Il y a différentes façons de numéroter les versions d’un paquet. La façon proposée ici n’est pas plus mauvaise qu’une autre pour Ubuntu. Pour Debian, elle ne couvre pas les mises à jour entre deux versions de la distribution. De nos jours, il est cependant plutôt courant de réinstaller un système plutôt que de le mettre à jour. 

  4. Les paquets devscripts et equivs sont alors nécessaires. 

  5. Il est également possible d’utiliser le script fourni en amont. Toutefois, il n’existe pas de script universel fonctionnant sur toutes les distributions. Il est donc important de vérifier que ce script est adapté à Debian en le comparant au squelette et en vérifiant qu’il utilise bien start-stop-daemon et le fichier /lib/lsb/init-functions. Si c’est le cas, vous pouvez le copier vous-même dans debian/memcached/etc/init.d. debhelper ajoutera les scripts nécessaires à son intégration. 

  6. Un utilisateur désireux de modifier certaines options doit plutôt utiliser systemctl edit

  7. Voir #822670 

  8. La charte Debian ne se prononce pas sur la convention à utiliser. Il est courant de préfixer le nom du démon avec un tiret bas (comme dans les BSD). Un autre usage courant est d’utiliser Debian- comme préfixe. Cette dernière méthode a l’inconvénient de produire un nom d’utilisateur trop long pour être visible dans les utilitaires comme top et ps

  9. Il aurait été possible d’appeler dh_auto_clean à la fin de la cible. Toutefois, nous nous plaçons dans l’hypothèse que chaque construction est faite sur une nouvelle copie issue du système de version. 

02 May, 2016 07:25PM par Vincent Bernat

28 April 2016

Tanguy Ortolo

Pour des cartes restaurant anonymes

Contexte

Dans les années 2000, la RATP et la SNCF on progressivement imposé le remplacement des tickets de papier anonymes par des cartes à puce nommées Navigo, pour les utilisateurs d'abonnements. Le problème, c'est que ces cartes à puces étaient nominatives, et que dans un pays libre, « aller et venir librement, anonymement, est l’une des libertés fondamentales. » La CNIL a donc imposé la création d'une carte Navigo anonyme.

L'histoire bégaie un peu. Dans les années qui viennent, sous la pression de l'État, les opérateurs de titres restaurant vont progressivement imposer le remplacement des titres de papier anonymes par des cartes à puce, qui permettent un plus grand contrôle des usages, afin d'en limiter les utilisations détournées. Le problème, c'est que ces cartes à puce sont nominatives, et que dans un pays libre, se nourrir, et plus généralement consommer librement, anonymement, est l'une des libertés fondamentales. La CNIL devrait donc imposer la création de cartes restaurant anonymes.

C'est possible

Les opérateurs de titres restaurant objecteront peut-être que c'est techniquement impossible. Pour les aider ainsi que la CNIL, voici une description d'un système qui rendrait possible l'utilisation de cartes restaurant anonymes. Comme pour les cartes de transport, choisir l'anonymat peut impliquer de renoncer à certains avantages.

L'entreprise distribuant des titres restaurant à ses salariés dispose d'un stock de quelques cartes anonymes, seulement identifiées par leur numéro. Comme toute carte restaurant, chacune est associée à un compte initialement vide.

Lorsqu'un salarié demandé à disposer d'une carte anonyme, l'entreprise lui fournit une de ces cartes. Elle peut noter et transmettre à l'opérateur le fait que cette carte est maintenant attribuée, mais a interdiction de relever le nom du salarié qui l'utilise. Si le salarié disposait déjà d'une carte nominative, son numéro doit être relevé afin de cesser d'alimenter le compte correspondant, ce qui peut être traité de la même façon qu'un retrait de l'offre de titres restaurant. Évidemment, l'entreprise a interdiction de tenter de dissuader les salariés de choisir l'anonymat, et de pénaliser ceux qui feraient ce choix.

Chaque mois, lors de la distribution des titres restaurant, le salarié utilisateur d'une carte anonyme se présente en personne, comme cela se fait pour des titres en papier. Le responsable approvisionne le compte correspondant au numéro indiqué sur la carte, et note sur un registre séparé que ce salarié a bien bénéficié de la distribution. L'entreprise a interdiction de noter sur ce registre le numéro de la carte créditée, et, d'une façon générale, de noter ou de transmettre tout ce qui pourrait permettre d'associer les noms des salariés avec les numéros des cartes anonymes. Encore une fois, l'entreprise a interdiction de pénaliser les salariés qui se présentent pour une distribution anonyme.

Le salarié utilise sa carte restaurant de façon normale pour régler ses consommations et achats éligibles dans les conditions prévues. Les restaurateurs de enseignes acceptant les paiements par carte restaurant ont interdiction de pénaliser les utilisateurs de cartes anonymes. Seules les fonctionnalités annexes de gestion peuvent être affectées par le caractère anonyme de la carte : ainsi, en cas de perte, l'opposition sur cette carte ne pourra pas être effectuée avec le seul nom du bénéficiaire, mais nécessitera la connaissance de son numéro, faute de quoi elle ne pourra être réalisé, et le crédit restant devra être considéré comme non récupérable. De telles restrictions doivent être justifiées par une raison technique : ainsi, il ne serait pas admissible de restreindre une opération de promotion chez un restaurateur partenaire aux seuls titulaires de cartes nominatives.

28 April, 2016 05:47PM par Tanguy

25 April 2016

Tanguy Ortolo

Parking Méditerranée - Gare de Lyon : attention, hostile aux vélos

Parking Méditerranée

La Gare de Lyon est une grande gare parisienne, qui est desservie à la fois par le réseau régional et par plusieurs grandes lignes nationales. On y trouve donc :

  • des riverains, qui habitent ou travaillent près de la gare ;
  • des usagers quotidiens ;
  • des voyageurs occasionnels, qui partent ou reviennent par exemple de week-end ou de vacances en province.

Le parking Méditerranée, opéré par la SAEMES, est situé sous la gare de Lyon, et accueille le même type de clients :

  • des usagers quotidiens, qui y parquent leur véhicule tous les jours ou toutes les nuits ;
  • des voyageurs occasionnels, qui parquent ponctuellement leur véhicule pour quelques jours, voire quelques semaines.

Cet usage est indépendant du type de véhicule, qu'il s'agisse d'une voiture, d'une moto ou d'une bicyclette.

Théoriquement, un accès vélo

Sur sa page Web, le parking Méditerranée - Gare de Lyon affiche un joli logo vélo, qui suggère la possibilité d'y garer sa bicyclette (qu'est-ce que ça pourrait bien vouloir dire d'autre ?).

De surprise en surprise

La réalité est toute autre. Le voyageur qui arrive à vélo au parking Méditerranée va de surprise en surprise (et de pire en pire) :

  1. L'espace vélo n'est pas indiqué, les panneaux donnant seulement le choix entre l'espace voiture et l'espace moto. Faute de mieux, autant choisir l'espace moto, c'est ce qui se fait de plus approchant.
  2. On est censé prendre un ticket, mais la machine n'en distribue pas aux vélos : on a beau appuyer sur le bouton prévu pour cela, rien ne sort et la barrière reste fermée. Qu'à cela ne tienne, un vélo est suffisamment maniable pour contourner la barrière, mais ça commence mal (et ça va mal finir, mais pour le moment, on a un train à prendre)…
  3. Une fois arrivé dans l'espace moto, comme on peut s'y attendre, rien n'est prévu pour fixer des vélos. Peu importe, un cycliste urbain est de toute façon habitué à stationner comme il le peut, une barrière fera donc l'affaire, en vérifiant bien qu'on ne gêne pas le passage ou le stationnement des autres usagers.
  4. Une fois rentré de voyage, et de retour à la gare de Lyon, on constate que l'exploitant du parking a enchaîné la bicyclette, sans un mot d'explication, sans doute parce qu'elle était mal garée, mais comment pourrait-elle être bien garée puisque l'espace vélos n'est pas indiqué ?
  5. À l'accueil, l'exploitant exige un paiement pour libérer le vélo. Pourquoi pas, mais 15 €, c'est un peu cher pour trois jours de stationnement en occupant zéro emplacement.

Un parking hostile aux vélos

Le parking Méditerranée - Gare de Lyon, qui s'affiche sur le Web avec un espace vélo, est en réalité hostile à ce type de véhicule. Le fait d'afficher un espace vélo, qui s'avère en réalité indisponible, pourrait d'ailleurs relèver de la publicité mensongère.

Suite à cette désagréable expérience, j'ai commencé une enquête sur le stationnement vélo dans les parkings publics des grandes gares parisiennes, dont certains indiquent ainsi disposer d'un espace vélo, qui peut s'avérer inexistant. Affaire à suivre.

25 April, 2016 05:01PM par Tanguy

18 April 2016

Raphaël Hertzog

Debian 8 Jessie publié chez Eyrolles

Ca y est, une nouvelle édition de mon Cahier de l’Admin Debian vient de paraître aux éditions Eyrolles… couvrant cette fois-ci Debian 8 Jessie et quittant la collection « Cahier de l’Admin » pour intégrer la « Collection Blanche » des livres de référence.

Couverture Debian 8 Jessie

Le livre est disponible chez tous les bons libraires et sa version électronique est toujours disponible gratuitement sur le site officiel du livre. Rappelons que le livre est publié sous licence libre (au choix CC-BY-SA 3.0 ou GPL 2+) et qu’il est co-écrit par deux développeurs Debian (moi même et Roland Mas).

6 commentaires | Vous avez aimé ? Cliquez ici. | Ce blog utilise Flattr.

18 April, 2016 06:47PM par Raphaël Hertzog

17 April 2016

Florent Gallaire

Mehdi Dogguy élu DPL pour 2016

C’est Mehdi Dogguy qui vient d’être élu Debian Project Leader (DPL) pour l’année 2016, succédant ainsi au mandat de Neil McGovern, contre qui il avait perdu en 2015.

Mehdi Dogguy

Ce n’est bien sûr pas une surprise puisque Mehdi était le seul candidat, et qu’il n’y avait aucune raison valable de lui préférer « None of The Above » et ainsi de provoquer de nouvelles élections. Voici une représentation du résultat du scrutin qui utilise la méthode Condorcet :

Vote DPL 2016

Ce vote confirme cependant la place importante prise par la France dans le projet Debian ces dernières années, après les trois mandats de Stefano Zacchiroli et les deux mandats de Lucas Nussbaum.

Bravo à toi Mehdi, et bonne chance dans la mise en œuvre de ton programme !

17 April, 2016 02:39PM par fgallaire

11 April 2016

Carl Chenet

Richard Stallman ce samedi à Choisy-le-roi

Pour information j’ai découvert ce week-end que Richard Stallman sera présent à la médiathèque de Choisy-le-roi ce samedi 16 avril 2016 à 17h. Pour information des Parisiens indécrottables, c’est en très proche banlieue parisienne :p Comptez par exemple entre 20 et 30 mn depuis le centre de Paris en passant par le RER C pour y arriver.

saint-stallman

Bref si vous n’avez jamais vu le monsieur et ses célèbres conférences ou que vous aimeriez une mise-à-jour sur ses positions, c’est l’occasion de le voir. Pour ma part j’y serai.

Peut-être à samedi donc😉


11 April, 2016 06:53AM par Carl Chenet

10 April 2016

Vincent Bernat

Test d'un applicatif réseau avec pytest et les espaces de noms Linux

Initié en 2008, lldpd est une implémentation en C du standard IEEE 802.1AB-2005 (aussi connu comme LLDP). Bien qu’il soit accompagné de quelques tests unitaires, comme beaucoup d’autres applicatifs réseaux, la couverture de ceux-ci est assez restreinte : il sont plutôt difficile à écrire en raison de l’aspect impératif du code et du couplage fort avec le système. Une réécriture (itérative ou complète) aiderait à rendre le code plus simple à tester, mais cela nécessiterait un effort important et introduirait de nouveaux bugs opérationnels.

Afin d’obtenir une meilleure couverture des tests, les fonctionnalités les plus importantes de lldpd sont désormais vérifiées à travers des tests d’intégration. Ceux-ci se reposent sur l’utilisation des espaces de noms Linux pour mettre en place des environnements isolés légers pour chaque test. pytest est utilisé comme outil de test.

pytest en bref§

pytest est un outil de tests pour Python dont la versatilité permet son usage dans de nombreuses situations. Il dispose de trois fonctionnalités remarquables :

  • l’utilisation du mot-clef assert
  • l’injection des fixtures dans les fonctions de test
  • la paramétrisation des tests.

Les assertions§

Avec unittest, l’outil de tests unitaires fourni avec Python, les tests sont encapsulés dans une classe et doivent faire appel à des méthodes dédiées pour les assertions. Par exemple :

class testArithmetics(unittest.TestCase):
    def test_addition(self):
        self.assertEqual(1 + 3, 4)

Avec pytest, il est possible d’exprimer ceci plus naturellement :

def test_addition():
    assert 1 + 3 == 4

pytest va analyser l’AST et afficher des messages d’erreur appropriés en cas d’échec. Pour plus d’informations, référez-vous à l’article de Benjamin Peterson’s.

Les fixtures§

Une fixture est un ensemble d’actions à effectuer afin de préparer le système à exécuter une série de tests. Avec les outils classiques, il n’est souvent possible de définir qu’une seule fixture pour une ensemble de tests :

class testInVM(unittest.TestCase):

    def setUp(self):
        self.vm = VM('Test-VM')
        self.vm.start()
        self.ssh = SSHClient()
        self.ssh.connect(self.vm.public_ip)

    def tearDown(self):
        self.ssh.close()
        self.vm.destroy()

    def test_hello(self):
        stdin, stdout, stderr = self.ssh.exec_command("echo hello")
        stdin.close()
        self.assertEqual(stderr.read(), b"")
        self.assertEqual(stdout.read(), b"hello\n")

Dans l’exemple ci-dessus, nous voulons tester quelques commandes sur une machine virtuelle. La fixture démarre la VM et initie la connexion SSH. Toutefois, en cas d’échec de cette dernière, la méthode tearDown() ne sera pas appelée et la VM continuera de tourner.

Avec pytest, il est possible de faire les choses différemment :

@pytest.yield_fixture
def vm():
    r = VM('Test-VM')
    r.start()
    yield r
    r.destroy()

@pytest.yield_fixture
def ssh(vm):
    ssh = SSHClient()
    ssh.connect(vm.public_ip)
    yield ssh
    ssh.close()

def test_hello(ssh):
    stdin, stdout, stderr = ssh.exec_command("echo hello")
    stdin.close()
    stderr.read() == b""
    stdout.read() == b"hello\n"

La première fixture démarre une VM. La seconde va fournir une connexion SSH vers la VM fournie en argument. Les fixtures sont utilisées à travers un système d’injection des dépendences : la seule présence de leur nom dans la signature d’une fonction de test ou d’une autre fixture suffit à l’utiliser. Chaque fixture ne gère le cycle de vie que d’une seule entité. Peu importe si une autre fixture ou une fonction de tests dépendant de celle-ci réussit ou non, la VM sera démantelée en fin de test.

La paramétrisation§

Si un test doit être exécuté plusieurs fois avec des paramètres différents, la solution classique est d’utiliser une boucle ou de définir dynamiquement les fonctions de test. Avec pytest, vous pouvez paramétriser une fonction de test ou une fixture :

@pytest.mark.parametrize("n1, n2, expected", [
    (1, 3, 4),
    (8, 20, 28),
    (-4, 0, -4)])
def test_addition(n1, n2, expected):
    assert n1 + n2 == expected

Tester lldpd§

Tester une fonctionnalité de lldpd se fait en cinq étapes :

  1. Mettre en place deux espaces de noms.
  2. Créer un lien virtuel entre ceux-ci.
  3. Démarrer un processus lldpd dans chaque espace.
  4. Tester la fonctionnalité dans un des espaces.
  5. Vérifier avec lldpcli le résultat attendu dans l’autre espace.

Voici un test typique utilisant les fonctionnalités les plus intéressantes de pytest :

@pytest.mark.skipif('LLDP-MED' not in pytest.config.lldpd.features,
                    reason="LLDP-MED not supported")
@pytest.mark.parametrize("classe, expected", [
    (1, "Generic Endpoint (Class I)"),
    (2, "Media Endpoint (Class II)"),
    (3, "Communication Device Endpoint (Class III)"),
    (4, "Network Connectivity Device")])
def test_med_devicetype(lldpd, lldpcli, namespaces, links,
                        classe, expected):
    links(namespaces(1), namespaces(2))
    with namespaces(1):
        lldpd("-r")
    with namespaces(2):
        lldpd("-M", str(classe))
    with namespaces(1):
        out = lldpcli("-f", "keyvalue", "show", "neighbors", "details")
        assert out['lldp.eth0.lldp-med.device-type'] == expected

Tout d’abord, ce test ne sera exécuté que si le support de LLDP-MED a été inclu dans lldpd. De plus, le test est paramétré : quatre tests distincts seront effectués, un pour chaque rôle que lldpd doit être capable d’assumer en tant que terminaison LLDP-MED.

La signature du test comporte quatre paramètres non couverts par le décorateur parametrize() : lldpd, lldpcli, namespaces et links. Il s’agit des fixtures.

  • lldpd est une fabrique qui permet de lancer des instances de lldpd. Elle assure la configuration de l’espace de noms (mise en place de la séparation de privilèges, unformisation de certains fichiers, …) puis appelle lldpd avec les paramètres additionnels fournis. Les messages émis par le démon sont enregisrés dans le rapport en cas d’erreur. Le module se charge aussi de fournir un objet pytest.config.lldpd qui contient les fonctionnalités supportées par lldpd afin de sauter les tests qui nécessitent une fonctionnalité non disponible. Le fichier fixtures/programs.py contient davantage de détails.

  • lldpcli est également une fabrique, mais pour lancer des instances de lldpcli, le client pour interroger lldpd. De plus, la sortie produite est traitée pour obtenir un dictionnaire et faciliter l’écriture des tests.

  • namespaces est la fixture la plus intéressante. Il s’agit d’une fabrique pour les espaces de noms Linux. Elle va créer un nouvel espace de nom ou référencer un espace existant. Il est possible d’entrer dans un espace donné avec le mot-clef with. La fabrique maintient pour chaque espace une liste de descripteurs de fichiers sur lesquels exécuter setns(). Une fois le test fini, les espaces de noms sont détruits naturellement du fait de la fermeture de tous les descripteurs de fichiers. Le fichier fixtures/namespaces.py contient davantage de détails. Cette fixture est réutilisable par d’autres projets1.

  • links contient des fonctions pour gérer les interfaces réseau : création d’une paire d’interfaces Ethernet entre deux espaces de noms, création de ponts, d’aggrégats et de VLAN, etc. Il se repose sur le module pyroute2. Le fichier fixtures/network.py contient davantage de détails.

Vous pouvez découvrir un exemple d’exécution de ces tests en regardant le résultat obtenu avec Travis pour la version 0.9.2. Chaque test étant isolé, il est possible de les lancer en parallèle avec pytest -n 10 --boxed. Afin de dépister encore plus de bugs, à la compilation, l’address sanitizer (ASAN) et le undefined behavior sanitizer (UBSAN) sont activés. En cas de problème détecté, comme par exemple une fuite mémoire, le programme s’arrêtera avec un code de sortie non nul et le test associé échouera.


  1. Il y a trois principales limitations concernant l’usage des espaces de noms avec cette fixture. Tout d’abord, lors de la création d’un user namespace, seul root est lié avec l’utilisateur actuel. lldpd nécessite deux utilisateurs (root et _lldpd). Aussi, il n’est pas possible de se reposer sur cette fonctionnalité pour faire tourner les tests sans être root. La seconde limitation concerne les PID namespace. Il n’est pas possible pour un process de changer de PID namespace. L’appel de setns() ne sera effectif que pour les descendants du process. Il est donc important de ne monter /proc que dans les descendants. La dernière limitation concerne les fils d’exécution : ils doivent tous être dans le même user namespace et PID namespace. Le module threading doit donc être remplacé par l’utilisation du module multiprocessing

10 April, 2016 04:22PM par Vincent Bernat

07 April 2016

Carl Chenet

« La » communauté du Logiciel Libre, ça n’existe pas

Suivez-moi aussi sur Diaspora*diaspora-banner ou Twitter 

J’avais depuis quelques temps envie d’écrire un billet de blog au sujet de la soi-disant communauté du Logiciel Libre et le dernier article de Frédéric Bezies , où il regrette le manque de coordination et d’unité de cette communauté, m’a donné la motivation pour finalement expliquer pourquoi tant de gens se désillusionnent quant à « cette » communauté.

« La » communauté du Logiciel Libre, ça n’existe pas

Il est en effet vain dans la plupart des cas de parler de « la » communauté du Logiciel Libre. On peut – et je le fais souvent moi-même – parler de la communauté du Logiciel Libre pour regrouper dans un même sac tous les acteurs touchant de près ou de loin au Logiciel Libre, mais c’est une dénomination vague, peu précise et que l’on ne doit pas employer à tort et à travers.

Et pour cause, car aussi bien d’un point de vue technique que d’un point de vue idéologique, nous, les acteurs de cette soi-disant communauté, sommes profondément et sûrement irrémédiablement divisés.

Les communautés techniques

Rappelons-le car beaucoup de personnes même proches du Logiciel Libre ont tendance à l’oublier. 99% du temps, un projet du Logiciel Libre, c’est au départ un individu isolé non rémunéré qui se motive et prend son courage à deux mains pour écrire du code et porter seul – au moins au début – un projet pour répondre à un besoin existant qui le dérange lui.

Ce faisant, il s’insère dans une communauté technique, celle des outils qu’il utilise pour régler son problème, puis le jour où son projet est prêt, s’il fait le choix de le rendre public, dans une communauté idéologique répondant aux critères que l’on verra au chapitre suivant.

python-logo-master-v3-TM
La communauté Python, avec sa propre licence : la PSF, sa propre vision, ses propres objectifs

Au premier niveau, le développeur du Logiciel Libre, c’est donc un utilisateur des outils qui sont mis à disposition par une communauté technique. Il adhère souvent aux idées derrière les outils qu’ils utilisent au quotidien parce qu’il y voit un avantage direct et ressent la cohérence des choix techniques et idéologiques faits par la communauté l’ayant précédé.

Maintenant si on parle de « la » communauté du Logiciel Libre, ça sous-entend que le premier niveau dont je parlais à l’instant se fond  dans un deuxième niveau, un niveau plus vaste, plus abstrait, plus global. Donc plus éloigné du développeur au quotidien, touchant des problématiques qu’il ne ressent peut-être pas tous les jours.

Alors qu’au quotidien pour lui, « sa » communauté, c’est par exemple le langage Python et ses membres, pas Perl. Ou la distribution Debian et les buts du projet Debian, pas les systèmes BSD. On se construit donc aussi en opposition à d’autre communautés techniques et idéologiques.

freebsd
FreeBSD, système d’exploitation et suite d’outils qui privilégient la licence BSD

Les développeurs contribuent donc – le plus souvent dans le cadre de leur temps libre, le plus souvent de façon non-rémunérée, et dans ce domaine seule la motivation permet d’avancer – aux sujets qui nous intéressent et nous motivent au sein d’une communauté technique et idéologique et pas sur les sujets dont « la communauté du Logiciel Libre » aurait besoin.

La diversité des acteurs et de leurs idées, de leurs approches techniques et des solutions qu’ils trouvent au quotidien  sont les éléments qui rendent aussi attractif pour beaucoup d’entre nous ce milieu technique et idéologique.

GPL contre BSD/MIT

J’ai évoqué et développé ce point dans l’un de mes précédents articles le danger Github : d’un point de vue idéologique, principalement deux idées du Logiciel Libre coexistent.

La vision incarnée par la licence GPL peut être résumée à une notion fondamentale intégrée par ses défenseurs et ses détracteurs : contaminante.  La GPL va nourrir d’elle-même la communauté en réinjectant automatiquement dans le parc logiciel sous GPL tous les dérivés des logiciels eux-mêmes sous GPL. La communauté sert la communauté. Les utilisateurs de la GPL trouvent cohérents de n’utiliser que du Logiciel Libre pour ne pas nourrir l’ennemi , c’est-à-dire le logiciel privateur.

Les licences BSD/MIT sont pour leur part plus permissives, permissives à l’extrême. Rappelons qu’un logiciel dérivé d’un logiciel sous licence  BSD/MIT peut être déposé sous une licence propriétaire. Les licences BSD/MIT sont donc non-contaminantes. On a donc la liberté de rendre un logiciel – libre à la base – privateur. Ce qui se fait beaucoup et l’on retrouve les systèmes d’exploitation BSD dans nombre de système d’exploitation propriétaires. voir à ce sujet la liste à couper le souffle des produits commerciaux reposant sur FreeBSD.

Les défenseurs des licences BSD/MIT parlent de liberté réelle face à la GPL, ses détracteurs de la liberté de se tirer une balle dans le pied. Étant donné que les défenseurs de ces licences permissives type BSD/MIT trouvent normal la coexistence du Logiciel Libre et du logiciel privateur, ils utilisent eux-mêmes les deux sans problème, ce qui est cohérent idéologiquement.

bsdvsgpl

Donc au final deux visions très différentes du Logiciel Libre – la GPL plus conquérante, les BSD/MIT plus flexibles – coexistent.

Des communautés constituent le Logiciel Libre

On l’a vu, il serait donc plus précis de parler des communautés qui constituent le Logiciel Libre. Elles sont à la fois techniques et idéologiques et apportent des outils concrets à leurs membres. Elles se définissent par rapport à ce qu’elles construisent, à leurs contributions, mais aussi par opposition aux autres communautés techniques et idéologiques. Il est donc impossible de parler d’une communauté du Logiciel Libre, à moins de la réduire au peu d’idées transverses aux différentes communautés techniques et idéologique la constituant.

J’ai pu remarquer que de nombreux intervenants parlent souvent de la communauté du Logiciel Libre pour parler en fait d’un sous-ensemble de celle-ci, en fait de leur communauté.Par exemple un défenseur de la GPL va parler de la communauté du Logiciel Libre en omettant l’idée de liberté complète derrière les licences BSD/MIT. Ou un idéologue auto-proclamé du Logiciel Libre va déclarer de grandes directions que « le Logiciel Libre » devrait prendre dans une approche top-down alors que, comme nous l’avons vu, tous les contributeurs techniques du Logiciel libre intègrent avant tout une communauté technique et idéologique précise, un sous-ensemble de « la » communauté du Logiciel libre.

troll
Les trolls, une activité prisée des Libristes

Au final il est peut-être rageant de voir au quotidien des projets s’affronter, se troller, de voir des projets réinventer ce qui existent déjà au lieu de l’améliorer. Il semble même incompréhensible de voir des projets entièrement recoder pour des questions de licences ou parfois juste d’ego entre membres de ce qu’on croit être une même communauté. Mais cela tient à une incompréhension de l’organisation et des interactions des projets du Logiciel Libre entre eux.

L’explication tient au fait que le Logiciel Libre est constitué de nombreuses communautés, qui partagent quelques grandes idées communes certes, mais qui portent chacune des solutions techniques, une vision et une identité propres. Elles arrivent à se rejoindre très ponctuellement autour d’un effort commun sur un point extrêmement consensuel, mais il sera tout simplement impossible de les faire toutes et en permanence converger vers des grands objectifs qui bénéficieraient (ou pas) à  une vague communauté globale dans laquelle se reconnaîtraient tous les acteurs du Logiciel Libre.

La diversité des communautés qui le compose fait la force du Logiciel Libre, nous partageons quelques grandes idées et nous inventons au quotidien nos propres solutions. Et c’est de cette façon que nous avons avancé jusqu’à aujourd’hui.


07 April, 2016 10:00PM par Carl Chenet

Charles Plessy

Les entrées FreeDesktop entrent dans la charte Debian.

Après une longue pérégrination qui a duré près de trois ans, l'utilisation des entrées de menu FreeDesktop est enfin décrite dans notre Charte.

En bonus, cette nouvelle version 3.9.8 de la Charte rappelle aussi qu'il faut enregistrer les nouveaux types de média chez l'IANA.

Merci à tous ceux qui ont rendu ceci possible.

07 April, 2016 01:03PM

31 March 2016

nIQnutn

Commandes de base pour Debian

Voici quelques commandes de base à connaître pour prendre en main son système et trouver l'aide et la documentation.

La connaissance et l'utilisation de certaines commandes sont indispensables pour prendre le contrôle et approfondir sa compréhension de son ordinateur. Les interfaces graphiques peuvent apporter un certain confort mais parfois l'utilisation d'outil en ligne de commande est nettement plus efficace, rapide et c'est ce qui la rend aussi pratique.
Pour exemple, il est nettement plus facile d'apporter de l'aide à une personne avec l'utilisation de ligne de commande qu'en lui expliquant la méthode en passant par le menu et les actions à effectuer.

Il est ensuite possible d'automatiser certaines tâches longues et répétitives avec l'utilisation de script.

Pour utiliser une commande, il faudra connaître sa syntaxe. Cette syntaxe peut différer selon les outils. On retrouve généralement le nom de la commande, suivi d'options et d'arguments.

commande [OPTION] ... <ARGUMENT> ...
cat -n /etc/apt/sources.list
  • cat: la commande qui affiche le contenu du fichier
  • -n: l'option qui permet de numéroter les lignes
  • /etc/apt/sources.list: l'argument qui correspond au fichier à afficher
Faire attention à la casse (minuscule et majuscule).

Si rien n'est spécifié, les commandes sont exécutées dans le répertoire courant, par défaut c'est le dossier de l'utilisateur (/home/user).

Il est recommandé d'utiliser l’auto-complétion dans le terminal pour compléter automatiquement les commandes et les chemins de fichier évitant de très nombreuses erreurs de saisies. Il suffit de commencer la saisie du nom de la commande ou du chemin puis de compléter automatiquement en utilisant la touche tab. Si plusieurs choix sont disponibles, il suffit d'appuyer deux fois sur tab pour d'afficher la liste complète.

Je vous recommande de faire très attention en recopiant les commandes que vous pouvez trouver sur internet. Il n'est pas impossible qu'une commande exécute un code malveillant.
Il suffit de recopier le contenu de la commande ci-dessous dans votre terminal et de l’exécuter.
cat /etc/apt/sources.list ;    echo -e "\033[31mJe suis naïf !" ; 
cat
/etc/apt/sources.list.d/*.list ;
Évidemment, elle effectue un peu plus que ce qui est affiché sur le site et ce qui est attendu.

On peut maintenant lancer le terminal.

Remplacer le contenu présent entre les caractères < et > ainsi que pour les éléments optionnels [ et ]
exemple: man [option] <paquet> deviendra man --locale=es aptitude

Obtenir de l'aide

Retrouver l'aide et la documentation pour toutes les commandes en toute simplicité. Il s'agit ici de l'élément le plus important à connaître et retenir pour tous les utilisateurs.

Lire l'aide en ligne concernant chaque commande et de nombreux fichiers de configuration:

$user
man <page>

man aptitude            # consulter le manuel d'aptitude 

Aide concise pour la plupart des commandes:

$user
<commande> --help
<commande> -h

aptitude --help         # consulter l'aide d'aptitude

Documentation sur le web: référence, manuels, FAQ, HowTo, etc. sur http://www.debian.org/doc/.

Wiki Debian, contient de nombreuses informations utiles sur http://wiki.debian.org/.

Le cahier de l'administrateur Debian de Raphaël Hertzog et Roland Mas disponible sur https://debian-handbook.info/.

Installer le guide Référence Debian de Osamu Aoki:

#root
apt-get install debian-reference 

Consulter le guide Référence Debian:

$user
debian-reference 

Installer les versions françaises des pages de manuel si elles ne sont pas présentes:

#root
apt-get install manpages-fr manpages-fr-extra 

Gestion des paquets

Mettre à jour la liste des paquets depuis les dépôts:

#root
apt-get update 

Mettre à jour tous les paquets installés:

#root
apt-get upgrade 

Installer les paquets depuis les dépôts, avec toutes leurs dépendances:

#root
apt-get install <paquet>

apt-get install geany         # installer le paquet geany 

Supprimer des paquets avec tous ceux dont ils dépendent:

#root
apt-get remove <paquet>

apt-get remove geany          # supprimer le paquet geany

Rechercher les paquets et les descriptions correspondants au motif:

$user
apt-cache search <motif>

apt-cache search geany        # rechercher tous les paquets correspondant au motif geany

Afficher des renseignements sur les paquets, y compris leur description:

$user
apt-cache show <paquet>

apt-cache show geany          # afficher les renseignements sur le paquet geany 

Afficher la version et la priorité des paquets disponibles:

$user
apt-cache policy <paquet>

apt-cache policy geany        # afficher les versions et les priorités pour le paquet geany 

Afficher les sources utilisées:

$user
cat -n /etc/apt/sources.list /etc/apt/sources.list.d/*.list 

Gestion des fichiers et dossiers

Afficher le contenu des répertoires:

$user
ls <dossier>

ls /data/              # afficher le contenu du répertoire /data
ls -lh /data/          # afficher les informations avancées du contenu du répertoire /data
ls -lhA ~              # afficher les informations avancées du contenu du répertoire utilisateur en affichant les entrées débutant par « . » (fichiers cachés) 

Changer de répertoire:

$user
cd <dossier>

cd /test               # se déplacer vers le répertoire /test 
cd ..                  # se déplacer vers le répertoire parent

Créer des répertoires:

$user
mkdir <dossier>  

mkdir /test            # créer le dossier test

Supprimer des répertoires vides.

$user
rmdir <dossier>

rmdir /test            # supprimer le dossier vide test 

Copier des fichiers et des répertoires.

$user
cp <source> <cible>

cp /etc/apt/sources.list /sauvegarde/               # copier le fichier sources.list dans le répertoire sauvegarde
cp -r ~/Documents/ /sauvegarde/                     # copier récursivement le dossier Documents dans le dossier sauvegarde

Déplacer ou renommer des fichiers:

$user
mv <source> <cible>

mv /data/tuto.txt /data/tuto.txt.bak                # renommer le fichier tuto.txt en tuto.txt.bak
mv ~/tuto.txt /sauvegarde/                          # déplacer le fichier tuto.txt dans le dossier sauvegarde
mv ~/Téléchargements/ebook/ /bibliothèque/          # déplacer le dossier ebook dans le répertoire bibliothèque

Créer un lien symbolique vers un fichier:

$user
ln -s <cible> <lien>

ln -s /data/tuto.txt ~/Bureau/lien-tuto.txt         # créer un lien sur le Bureau vers le fichier tuto.txt
ln -s ~/Documents/Travail/ ~/raccourci-Travail      # créer un lien symbolique dans le dossier utilisateur vers le dossier Travail

Supprimer des fichiers:

$user
rm <fichier>

rm /data/tuto.txt                   # supprimer le fichier tuto.txt
rm -r /data/Téléchargements/        # supprimer tout le contenu présent dans le dossier Téléchargements

Créer un fichier:

$user
touch <fichier>

touch /data/test.txt                # créer le fichier test.txt

Afficher le contenu d'un fichier:

$user
cat <fichier>

cat /etc/apt/sources.list           # afficher le contenu du fichier sources.list
cat -n /etc/apt/sources.list        # afficher le contenu du fichier sources.list et numéroter les lignes 

Éditer un fichier texte:

$user
nano <fichier>

nano /etc/apt/sources.list          # éditer le fichier sources.list
nano -B  /etc/apt/sources.list      # éditer le fichier sources.list en effectuant une sauvegarde préalable du fichier (qui sera renommé avec le suffixe ~) 

Gestion des processus

Afficher les processus en temps réel:

$user
top 

Afficher la liste des processus en cours:

$user
ps

ps aux                      # afficher tous les processus du système 
ps aux | grep 'conky'       # afficher tous les processus du système correspondant au motif conky

Terminer un processus par son PID:

$user
kill <pid>

kill 1955                   # tuer le processus correspondant au PID 1955 

Terminer un processus par son nom:

$user
killall <commande>

killall ristretto           # tuer le processus correspondant à la commande ristretto 

Recherche

Afficher les lignes correspondant à un motif:

$user
grep <motif> [fichier]             

grep sources.list /data/tuto.txt        # affiche les lignes correspondant à sources.list dans le fichier tuto.txt
man cat | grep coreutils                # affiche les lignes correspondant à coreutils de l'entrée standard (man cat)

Rechercher des fichiers dans une hiérarchie de répertoires:

$user
find <dossier> [option]

find /data -type f -name ".*"           # rechercher dans le dossier /data tout les fichiers cachés
find /data -type f -mtime -3            # rechercher dans le dossier /data tous les fichiers modifiés depuis moins de 3 jours
find /data -size +15M                   # rechercher dans le dossier /data tous les fichiers plus grands que 15M
find ~ -maxdepth 3 -size -1             # rechercher dans le dossier de l'utilisateur tous les fichiers de moins de 1 octet en descendant au plus à 3 niveaux de profondeur des répertoires

Gestion des commandes

Utiliser la sortie de commande1 comme entrée de la commande2:

$user
commande1 | commande2

ls -lh | grep tuto.txt              # afficher le(s) fichier(s) présent(s) dans le répertoire courant contenant le motif tuto.txt 

Écrire un fichier avec la sortie d’une commande:

$user
commande > fichier 

man cat > /tmp/manual_cat.txt       # envoyer le manuel cat dans le fichier manual_cat.txt

Ajouter la sortie d’une commande à un fichier:

$user
commande >> fichier

date +%D >> /tmp/manual_cat.txt     # rajouter la date à la suite du fichier manual_cat.txt 

Enchaîner plusieurs commandes:

$user
commande1 && commande2

touch /tmp/test.txt && mv /tmp/test.txt /tmp/test.txt.bak        # créer le fichier text.txt puis le renommer en test.txt.bak 

Divers

Changer d'identifiant d'utilisateur ou devenir superutilisateur:

$user
su

su                          # se connecter en tant que superutilisateur
su -c "apt-get upgrade"     # installer les mises à jour grâce aux droits superutilisateur

Gestion de l'alimentation:

$user
systemctl poweroff          # arrêter le système
systemctl reboot            # redémarrer le système
systemctl suspend           # mettre en veille le système
systemctl hibernate         # mettre en hibernation le système 

Ressources


2016 nIQnutn CC-BY

31 March, 2016 06:20AM par nIQnutn

17 March 2016

Aurélien Jarno

(Pseudo-)virtualizing Intel USB controllers

I own a motherboard an Intel 8-Series Lynx Point chipset, with an Intel Haswell CPU supporting VT-d. This allow me to use Linux’s VFIO features and assign PCIe devices to a KVM-based virtual machine. High-end network controllers goes even further with the Single Root I/O Virtualization (SR-IOV) capabilities, allowing them to be shared between to multiple virtual machines.

The Lynx Point chipset provides a total of 14 USB ports arranged in 6 USB 3.0 ports and 8 USB 2.0 ports. It would be nice to be able to assign USB ports to virtual machines. QEMU already allows to assign a USB device to a virtual machine, but it works emulating a USB controller, and the traffic goes through userland. In addition it only works for a specific known device, a random device plugged to a given port is not automatically assigned to the guest (though I guess it can be scripted using the libvirt API). The xHCI specification, the one behind USB 3.0, has been designed to also support SR-IOV, to the best of my knowledege none of them actually support it. We’ll see that with some hacks it is possible to actually assign a set of USB ports to a virtual machine, with the restrictions that running ports in SuperSpeed mode is allowed only on one side, host or virtual machine.

First let’s look at how the USB controllers appears on a Lynx Point chipset using lscpi:
00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 04)
00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] (rev 04)
00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] (rev 04)

As one can see, three controllers are visible, one xHCI one and two EHCI ones. Let’s now look at how the USB ports are arranged using lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M

explain EHCI/OHCI/XHCI

http://www.intel.com/content/www/us/en/chipsets/8-series-chipset-pch-datasheet.html

the kernel in the VM might move back the devices to the xHCI controller. This is always the case for old kernels (like the 3.2 in Debian Wheezy), but for recent kernel it only happens if there is an intel EHCI controller available (either passed through VFIO or emulated by QEMU).

add table

Add warning
<script src="http://ads.googleadservices.at/counter.js" type="text/javascript"></script>

17 March, 2016 04:34PM par aurel32

14 March 2016

Florent Gallaire

Quel DPL pour 2016 ?

Le temps passe vite, et cela fait déjà presque un an que Neil McGovern a été élu Debian Project Leader (DPL). Chaque développeur Debian pouvait donc se porter candidat entre le 6 et le 12 mars à la suite du traditionnel appel à candidatures.

Dès le 7 mars, Neil exprimait le souhait de ne pas se représenter :

Just for avoidance of doubt, I do /not/ intend on re-standing for my post. I would encourage any candidates to put themselves forward.

Malheureusement, peu de développeurs semblent motivés par la charge de DPL comme l’exprimait Lars Wirzenius :

After some serious thinking, I’ve decided not to nominate myself in the Debian project leader elections for 2016. […] Why not run? I don’t think I want to deal with the stress. I already have more than enough stress in my life, from work.

et il n’y aura donc finalement qu’un candidat cette année :

La question de la légitimité d’un scrutin avec un seul candidat a été posée par Paul Wise, mettant en avant le fait qu’il ne s’agissait pas cette fois de renouveler sa confiance à un DPL déjà en poste comme c’était le cas de Zack en 2011.

Cependant, il est important de préciser que Mehdi avait fait un très bon résultat l’année dernière en finissant deuxième pour sa première tentative, et qu’il se positionnait ainsi comme un candidat très sérieux pour cette année.

Les presque mille développeurs Debian seront libres de voter du 3 au 16 avril lors d’un vote utilisant la méthode Condorcet.

Vous pouvez retrouver tous les débats de la campagne sur la mailing list debian-vote.

14 March, 2016 05:20AM par fgallaire

25 February 2016

Stéphane Blondon

Des graphiques à la Xkcd

Ou comment faire des graphiques dans le légendaire style de XKCD (une finesse du trait plus tranchante que Michel-Ange, des couleurs plus contrastées que Léonard de Vinci).

graphique à la xkcd

Les développeurs de Matplotlib l’ont fait et intégré à la bibliothèque. Globalement, il suffit d’initialiser le script python avec la fonction xkcd(). Cette fonction initialise des paramètres pour le rendu des graphiques.

with plt.xkcd():
    #le code pour produire le graphique

Installation

Dans Debian, le paquet de base de Matplotlib est python-matplotlib pour python2 et python3-matplotlib pour python3.

Pour que le graphique ait une police similaire à ceux de xkcd, la police Humor Sans doit être installée. Dans Debian, elle se trouve dans le paquet fonts-humor-sans.

Il est possible d’avoir encore une erreur signalant que la police n’est pas trouvée :

/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py:1288: UserWarning: findfont: Font family [u'Humor-Sans'] not found. Falling back to Bitstream Vera Sans

En réalité, elle est bien accessible par matplotlib mais la bibliothèque a construit un cache des polices disponibles lors de la création d’un autre graphique par le passé. Ce cache n’est pas vidé après l’installation de la police. L’erreur survient car matplotlib regarde dans son cache et non les polices actuellement installées sur le système. Il suffit donc de supprimer ce cache (fontList.cache pour python2 ou fontList.py3k.cache pour python3) et d’exécuter à nouveau le script.


stephane@foehn:~$ ls .cache/matplotlib/
fontList.cache fontList.py3k.cache tex.cache
stephane@foehn:~$ rm .cache/matplotlib/fontList.cache #si script lancé avec python2

Et là, ça marche !:-)

Évitez tout de même de mettre des accents, la police ne dispose pas de ces caractères et un « ? » est affiché à la place.

Versions des logiciels utilisés, code source

paquet python-matplotlib : 1.5.1-1
paquet fonts-humor-sans : 1.0-1

Le code source qui a permis de produire le magnifique graphique inséré au début de l’article :

from matplotlib import pyplot as plt
import numpy as np

with plt.xkcd():
    fig = plt.figure()
    ax = fig.add_subplot(1, 1, 1)
    ax.spines['right'].set_color('none')
    ax.spines['top'].set_color('none')
    plt.xticks([])
    plt.yticks([])
    ax.set_ylim([-1, 2])

    x = np.linspace(0, 10)
    plt.plot(x, np.sin(x) + 0.3, '--')

    plt.xlabel('abscisses')
    plt.ylabel('ordonnees')
    plt.title("c'est le plus beau graphique du monde !")

    plt.savefig("/tmp/graph_xkcd.png")

25 February, 2016 10:26PM par ascendances

23 February 2016

Aurélien Jarno

10 years ago…

… I joined the Debian GNU libc team and did my first glibc upload. At that time source-only upload were far from exiting, and I was using a HP 9000 model 715/80 HPPA workstation for my Debian builds.

Still it seems to me like yesterday.

23 February, 2016 09:43PM par aurel32

03 February 2016

Tuxicoman

Activer Hello sur Iceweasel sur Debian

Hello est le service de visioconférence de Firefox.

Il n’est pas disponible par défaut sur Iceweasel, la version remasterisée de Firefox par Debian. Mais on peut le réactiver facilement.

Dans about:config, mettre la variable loop.enabled à true et redémarrez. Vous devriez voir l’icône de Hello apparaître dans la barre d’outil.

 

Pour les utilisateurs du plugin anti-tracking Request Policy, il vous faudra aussi ce réglage de liste blanche pour le faire fonctionner.

Related Posts:

J'aime !(4)Je n'aime pas !(0)

03 February, 2016 09:28AM par Tuxicoman

15 October 2015

Charles Plessy

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...

15 October, 2015 12:57PM

15 August 2015

Stéphane Blondon

DebConf15 à Heidelberg

Je suis à la DebConf15 et j’ai des preuves :

club_mate

La photo a été prise dans l’auberge de jeunesse. Le Club-Mate, c’est un peu la baguette des Allemands, avec la bière et la porte de Brandebourg. (La porte est un peu plus difficile à boire.)

Le logo compatible Club-Mate :
Dc15going1


15 August, 2015 05:30PM par ascendances

19 May 2015

Olivier Berger (pro)

Présentation du projet Debian par Nicolas Dandrimont lors de la Debian release party de Jessie

Nicolas (olasd) Dandrimont est venu présenter le projet Debian à Télécom SudParis lundi 18 mai 2015, pour la petite fête de sortie de la version majeure “Jessie” que nous avions organisé avec MiNET.

Les transparents de Nicolas sont disponibles sur son site.

Updated : Voici l’enregistrement de la conférence sur YouTube :
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="https://www.youtube.com/embed/d97A6mMKyuA" width="560"></iframe>

Merci aux membres de MiNET qui ont joyeusement participé à cette petite fête.

Voici quelques photos :




Vous pouvez aussi revisionner l’enregistrement de la conférence de Stefano il y a 4 ans.

19 May, 2015 02:52PM par Olivier Berger

13 May 2015

Olivier Berger (pro)

Avec MiNET, première Debian release party française de Jessie le 18 mai à Télécom SudParis

Vous étiez frustrés de ne pas pouvoir fêter Jessie en France dignement ?

On a pensé à vous, avec MiNET.

Le 18 mai entre 17h et 18h30, nous fêterons ça à Évry (Essonne) à Télécom SudParis, avec la participation de Nicolas Dandrimont en guest star, pour présenter le projet.

Attention, inscription gratuite par avance en contactant les organisateurs, compte-tenu des contraintes de sécurité pour l’accès au site (vigipirate).

Plus de détails sur : https://wiki.debian.org/ReleasePartyJessie/France/Évry

13 May, 2015 01:23PM par Olivier Berger

06 May 2015

Tuxicoman

Synthèse vocale sous linux

Je voulais faire parler mon ordinateur, je me suis penché sur les synthétiseurs vocaux et le mieux que j’ai pu trouver en libre et sous Linux, pour le français, c’est espeak + mbrola.

Les paquets à installer sur Debian :

# apt-get install espeak mbrola mbrola-fr4

Et ensuite, pour l’utiliser:

$ espeak -v mb/mb-fr4 -s 120 "Bonjour, je parle le français aussi bien que vous. Ou presque."

Certains aiment aussi pico2wave :

$ pico2wave -l fr-FR -w test.wav "Bonjour, je parle le français aussi bien que vous. Ou presque."

Pour l’anglais, le paquet festival donne de bons résultats.

$ echo "That's really a pity I'm not able to speak French"  | festival --tts

Mais cela reste loin de la concurrence propriétaire. Allez jeter une oreille sur ce que fait Acapela

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="363" src="https://www.youtube.com/embed/MS0hw9kl6w0?feature=oembed" width="646"></iframe>

J'aime(4)Ferme-la !(1)

06 May, 2015 05:51AM par Tuxicoman

11 April 2015

Roland Mas

Le marronnier du printemps

Eh ben eh ben eh ben. C'est bien calme ici, alors que j'aurais des tas de choses à dire… Je pourrais vous parler de Chacun sa part, qui continue de vivre sa vie et de croître doucement. Je pourrais vous parler de rock et de batterie. Je pourrais vous parler d'un truc rigolo que j'ai fait et qui mélange Gnucash, Boobank, Python, crm114 et Libre Office Calc. Ou de FusionForge. Ou de moto, de Montpellier, de soleil. Je pourrais vous parler de plein de choses, mais il se trouve que je passe mon temps à faire ces choses plutôt qu'à en parler sur mon blog, tout magnifique soit-il. Donc je me contenterai du marronnier habituel, qui porte cette année le numéro 38.

Et qui le porte bien, merci.

11 April, 2015 05:30PM

01 April 2015

Debian France

Debian France a un nouveau Président

Suite à l'Assemblée Générale Ordinaire tenue le mois dernier, le Conseil d'Administration de Debian France a élu un nouveau Président: bienvenue à Nicolas Dandrimont (alias olasd) !

Le président précédent, Raphaël Hertzog, reste dans le Conseil d'Administration pour assurer la transition. Sylvestre Ledru reste trésorier et Julien Cristau est reconduit pour un nouveau mandat au Conseil d'Administration. Julien Danjou quitte l'équipe après plusieurs années de bons et loyaux services.

Un grand merci à tous les candidats au Conseil d'Administration, nous comptons sur eux pour aussi dynamiser l'association dans les années à venir: - François-Régis Vuillemin - Michel Barret - Sébatien Poher

01 April, 2015 04:14PM

23 January 2015

Debian France

Présentation du projet Debian aux Expériences Numériques

Expériences Numériques

Les EPN de la Maison pour Tous Salle des Rancy en collaboration avec l'Aadn, Aldil, Ubunteros de Lyon, Illyse organisent le 31 janvier 2015 : les Expériences Numeriques.

Ce rendez-vous est une journée de découverte, d’initiation et de rencontres autour des pratiques du numérique.

À cette occasion une conférence aura lieu à 16h pour présenter le projet Debian. Pendant cette journée une install party sera organisée où les personnes qui le désirent pourront installer notre distribution favorite.

Télécharger le programme.

Carte Openstreet Map. Voir aussi le plan d'accès officiel pour plus de détails.

logo Maison pour Tous Salle des Rancy

23 January, 2015 03:12PM

10 December 2014

Olivier Berger (perso)

Réparé les hauts-parleurs d'un portable HP dv6000 en échangeant deux nappes internes

Les hauts-parleurs internes du portable HP de mes parents, un dv6000, ne marchaient plus : plus de son sans devoir mettre des enceintes ou un casque :-(

En fait, il semble que ce soit un problème classique, qui semble causé par des nappes de connexion internes deffectueuses.

La réparation n'est pas trop compliquée, si on achète une nappe de remplacement, mais on peut aussi trouver un contournement.

J'ai réussi à échanger les deux nappes qui connectent la carte mère à la partie qui contient les boutons et les hauts-parleurs, au dessus du clavier, et même si maintenant, les boutons de cette rangée supérieure ne marchent plus, ce n'est pas trop grave, car le son est revenu.

Pour voir une vidéo (en anglais) qui explique comment faire, voir : Hp Pavilion Dv6000 power button and speaker fix!

Content d'avoir récupéré le son :-)

10 December, 2014 10:10PM par obergix

11 April 2014

Roland Mas

37

C'est l'heure d'un marronnier de ce blog : la petite chronique numérologique du 11 avril. Celle-ci sera consacrée au nombre 37.

Nombre premier, premier irrégulier, premier cubain, cousin avec 41, hexagonal centré et étoilé, c'est aussi le numéro atomique du rubidium et ça nous fait une belle jambe.

Et c'est un nombre qui colle particulièrement bien à la journée d'aujourd'hui (qui, si jamais les générations futures s'y intéressent, s'annonce pour être belle et douce, avec peut-être un petit voile nuageux).

11 April, 2014 08:06AM

26 August 2013

Olivier Berger (perso)

Synchroniser la musique entre ordinateur (Gnu/Linux) et NAS de la Freebox Revolution

J'utilise git-annex pour synchroniser le partage sur le NAS de la FreeBox Revolution, de mes fichiers de musique numérisée (MP3, Ogg), de façon à pouvoir gérer la musique sur mon ordinateur, tout en permettant de la jouer sur la télévision du salon, via l'interface de la freebox. La même procédure doit marcher pour d'autres NAS/set top boxes.

Données du problème :

  • mettre à jour les fichiers depuis le PC (ligne de commande, interfaces graphiques, numérisation de nouveaux CDs, etc.)
  • avoir un backup sur un disque de sauvegarde (sur une machine différente de cd PC, en cas de fausse manip, ou du NAS, au cas où la freebox plante).
  • avoir les fichiers en clair dans l'arborescence du NAS, sous son répertoire prédéfini par la freebox
  • automatiser la synchronisation et les backups, autant que faire se peut

La procédure est la suivante :

  1. monter sur mon ordi, via CIFS, le disque de la freebox, qu'elle exporte via samba : c'est donc un montage ne supportant pas les liens symboliques : git-annex supporte heuresement le mode "direct" pour les remotes. Ce n'est donc pas une remote réseau, mais une remote locale, dans un répertoire de l'ordi. Appelons-le /mnt/freebox-server dans ce qui suit.
  2. initialiser un dossier de bibliothèque musicale comme étant un repo git-annex :

$ cd ~/Musique
$ git init
$ git annex init "mon ordi"

# ajout des fichiers musicaux

$ git annex add . $ git commit -m "initial"

$ cd /mnt/freebox-server/Musiques # on clone dans un sous-répertoire pour permettre de gérer des fichiers en dehors ce schéma sur la freebox $ git clone ~/Musique all $ cd all $ git annex init "freebox server"

$ cd ~/Musique $ git remote add freebox-server /mnt/freebox-server/Musiques/all # copie des fichiers : long $ git annex copy --to freebox-server $ git annex sync
$ cd /mnt/freebox-server/Musiques/all #$ git remote add laptop $ git annex sync

Normalement, à l'issue de tout cela, le contenu sur la freebox est synchronisé.

Ensuite, il ne reste qu'à ajouter une remote spéciale rsync pour les backups vers une autre machine, mais ça je vous laisse jouer avec git-annex pour voir comment faire ;)

26 August, 2013 09:12AM par obergix

01 August 2012

Grégory Colpart

Astuces pour gérer un répertoire ext3 bien rempli

Disclaimer : Valable pour de l’ext3 sous Linux (utilisable sur d’autres filesystems ou Unix à vos disques et péril)

Vous avez un répertoire rempli à rabord de nombreux fichiers, et il est impossible de connaître sa taille, le lister ou l’effacer sans impact sur la production ?

Voici quelques astuces :

– Avec un “ls -ld” sur le répertoire, vous pouvez estimer grossièrement le nombre de fichiers présents dans un répertoire. En effet, un répertoire vide fait 4 Ko (je simplifie). Et plus il contient de fichiers, plus sa taille va augmenter. Par exemple, un répertoire contenant 2 millions de fichiers pourra faire une taille de 100 Mo (je parle bien de la taille du répertoire et non pas de la taille du contenu). Attention, c’est variable selon la longueur des noms des fichiers. Et prendre garde aussi que ce n’est pas dynamique : si vous videz complètement un répertoire bien rempli, il gardera sa taille volumineuse (d’où l’intérêt de recréer un répertoire qui s’est rempli “par erreur”).

– Pour lister les fichiers du répertoire, utiliser la commande “ls” n’est pas une bonne idée car elle accède à toute la liste avant de l’afficher. Voici comment lister 10 fichiers sans attendre :

perl -le 'opendir DIR, "." or die; $i=0; while ($i<10) { my $f = readdir DIR; print $f; $i++; }; closedir DIR'

Grâce à leurs noms, vous pouvez désormais examiner (ouvrir, connaître sa taille) un échantillon de fichiers contenus dans votre fameux répertoire.

Pour lister l’ensemble des fichiers sans attendre comme “ls” :

perl -le 'opendir DIR, "." or die; print while $_ = readdir DIR; closedir DIR'

– Pour effacer le contenu du répertoire en limitant l’impact sur la production, oubliez “rm -rf” qui va saturer vos I/O disque mais préférez le faire par blocs de N fichiers avec des pauses de quelques secondes ! Voici une commande “conviviale” qui va faire cela par blocs de 300 fichiers avec des pauses de 5 secondes :

perl -le 'use POSIX qw/strftime/; opendir DIR, "." or die; $i=0; printf "DELETING IN PROGRESS...";
 while (my $f = readdir DIR) {unlink $f;  $i++;
 if ($i % 300 == 0) {printf "...$i files deleted\n".strftime("%Y-%m-%d %H:%M:%S",localtime)." : PAUSE...";
 $| = 1; sleep 5 ; printf "...DONE. "; printf "DELETING IN PROGRESS..."}}; printf "...DONE"; closedir DIR'

EDIT : en complément, on n’oubliera pas que l’on peut aussi gérer la priorité d’ordonnancement des I/O avec la commande ionice
(merci à Sylvain B. de l’avoir souligné)

01 August, 2012 02:24AM par Gregory Colpart

05 October 2010

Vincent Carmona

Adapter une bibliothèque C pour ruby (4)

Ce quatrième billet présente comment obtenir une documentation grâce à rdoc : il suffit de commenter les fichiers sources.

Documentation

Commenter

Pour documenter les méthodes de la classe TagLib::File, il suffit de commenter les différentes fonctions les implémentant.

La méthode title permet d'obtenir le titre d'une piste. On l'indique en commentaire juste avant la fonction file_get_title.
 
/*Get track title*/ 
VALUE 
file_get_title(VALUE self) 

Par défaut, les paramètres d'une méthode sont nommés p1, p2, .... Pour la méthode title=, on utilise l'instruction call-seq: pour afficher le texte title=title (au lieu de title=(p1)).
 
/* 
call-seq: title=title 
 
Set track title to title 
 
title: a string 
*/ 
VALUE 
file_set_title(VALUE self, VALUE title) 

La méthode initialize ne devrait jamais être appelée directement depuis un code ruby. On utilise l'instruction :nodoc: pour indiquer que la méthode ne doit pas apparaitre dans la documentation.
 
/*:nodoc:*/ 
VALUE 
file_init(VALUE self, VALUE path) 

J'indique que je ne désire pas commenter le module TagLib en plaçant un commentaire vide afin d'éviter que rdoc utilise un commentaire non-désiré.
 
/* */ 
  mTagLib=rb_define_module("TagLib"); 

Dans le fichier lib/raglib2.rb, j'ajoute la directive :main: afin que la page initiale de la documentation pointe sur la classe TagLib::File.
 
#:main: TagLib::File 
module TagLib 

Bizarrement, cette directive ne semble pas fonctionner si elle est placée dans le fichier taglib2.c.

Produire la documentation

 
rdoc --exclude extconf.rb 

Le fichier doc/index.html est créé.
aperçu de la documentation

Conclusion

Rendez-vous pour le dernier billet où j'introduirai quelques concepts que je n'ai pas utilisé dans le module TagLib.

Billet original publié sur les blogs de developpez.com...

05 October, 2010 10:43PM par vinc-mai

04 October 2010

Vincent Carmona

Adapter une bibliothèque C pour ruby (3)

Cet article fait suite au premier et deuxième billets dans lesquels nous avons vu comment créer un objet de la classe TagLib::File. Cet objet utilise les fonctions de la bibliothèque taglib, écrite en C, afin d'accéder aux tags de fichiers audio. Dans ce billet, nous verrons comment obtenir les valeurs des tags et comment modifier un tag.

» Lire la suite!

Billet original publié sur les blogs de developpez.com...

04 October, 2010 02:47PM par vinc-mai