Archive for the 'Articles' Category

Aujourd’hui la Haute-Marne est un des départements qui n’a pas d’association pour manifester et proclamer l’existence des logiciels libres, leur utilisation ainsi que leur bien fondé. Dans ce contexte Antoine cherche des équipiers pour porter le projet de création d’un GULL (LUG).
Toutes les personnes motivées à participer au projet peuvent contacter Antoine par le biais de l’association COAGUL (courriel, IRC).

Site : http://www.coagul.org

IRC : https://webchat.freenode.net/?channels=#coagul

Courriel : Vous pouvez contacter l’association par courriel à l’adresse suivante c-bureau_CHEZ_outils.coagul.org
Nous avons remplacé @ par _CHEZ_ afin d’éviter les robots de récupérer notre adresse et de de polluer notre boîte de pourriels (SPAM).

 

BSP aux Tanneries – atelier Lunar – Comment bien rapporter un bogue dans Debian ?

Rapporter un bogue, c’est rendre service aux développeurs. Ou plutôt, bien reporter un bogue, c’est rendre service aux développeurs. Voici une liste de conseils que nous donne Lunar pour rapporter utilement un bogue :

Prérequis (rien ne sert de courir…)

Avant de rédiger le rapport, il il y a plusieurs choses à faire :

“Est ce que j’hallucine ?”

Essayer de reproduire le bogue permet de s’assurer que l’erreur se produit bien toujours de la mème manière, qu’il y a effectivement un bogue et qu’il ne s’agit pas d’une fausse manip, et qu’on a bien cerné la problématique. Un bogue qu’on ne peut pas reproduire ne peut pas être corrigé.

Est-ce que ça n’a pas déjà été reporté ?

Autant c’est très utile de rapporter un bogue, autant c’est une perte de temps pour tout le monde de le rapporter en double. Il est nécessaire de consulter au préalable la liste des rapports de bogues existants, au cas où il soit déjà rapporté par quelqu’un. (attention aux versions de Debian et des logiciels, un bogue rapporté dans stable et pas dans unstable, ou inversement.)

Les bogues de Debian sont rendus publics et sont visibles sur les pages du bug tracking system Debian.

Pré-diagnostiquer la panne

Pour qu’il soit possible aux développeurs de corriger, il leur faut une description précise du problème. D’abord il faut connaître le nom du paquet contenant le logiciel causant la panne : grâce à dpkg -S

% dpkg -S nomdulogiciel

Ensuite il faut collecter des informations sur l’erreur. Il est nécessaire de bien décrire l’erreur pour que les développeurs puissent la corriger.
Il est bien utile par exemple de lancer dans un terminal un programme graphique pour savoir ce qui se passe quand il plante, et de copier-coller les erreurs significatives dans le rapport ; ou d’utiliser les outils catchsegv et strace (outils qui pourront aider à détecter l’erreur au lieu de simplement dire “ça segfault..”

Il est conseillé de lire les informations sur le bug tracking system disponibles sur le site web, pour savoir quelles options choisir, et bien formuler son mail.

Écrire son rapport

Enfin, on peut se mettre à la rédaction. Un rapport de bogue doit contenir un titre, le nom du paquet, les rapports se font par mail, ils sont rédigés en anglais correct. Ils sont lus par des humains bénévoles et grognons, il faut être poli (hihi^^), et pas baragouiner dans sa barbe.
reportbug et reportbug-ng (ce dernier est un outil graphique) sont des outils utiles à la bonne rédaction du rapport.

Un bogue a un degré de sévérité :

Les bogues critiques, graves et sérieux, doivent être nécessairement fermés avant le freeze de la prochaine version stable de Debian. Si le bogue du paquet n’est pas corrigé, le paquet peut ne pas apparaître dans la nouvelle version stable.

Donner les informations environnementales : quelle architecture, quels composants logiciels concernés (noyau, paquets..). reportbug et reportbug-ng collectent automatiquement ces informations pour vous.
Précisez dans quelles circonstances vous avez fait la découverte de l’erreur, décrivez le problème, ses conséquences directes et, éventuellement, si vous en avez trouvé un, son palliatif. Dites ce que vous cherchiez à faire au moment du bogue, décrivez ce qui ne marche pas précisemment.

  • À ne pas faire : “Quand je veux lire un CD, ca ne marche pas.” (avec quel logiciel essayait-t-on de lire le CD, quelle erreur s’est produite précisément, etc ?)

BSP aux Tanneries – Comment corriger un bogue dans Debian ?

Prérequis

Il faut avoir une clef gpg qu’un développeur Debian a signée (ou qu’il considère de confiance) pour certifier de votre identité auprès de celui-ci pour qu’il
uploade votre paquet. Une adresse email (attention, elle sera spammée) doit être associée à cette clef.

Les outils de construction de paquets doivent connaître cette adresse email. Ce sera votre adresse Debian. Pour la déclarer en tant que telle :

export DEBEMAIL=adresse@mail

paquets utiles : devscripts, lintian, patchutils

Vocabulaire

NMU (non-maintainer upload) : upload d’un paquet par quelqu’un d’autre que son mainteneur officiel
paquet source : paquet contenant les sources du logiciel et à partir duquel un ou plusieurs paquets binaires sont construits
paquet binaire : paquet résultant de la compilation
bug upstream : bogue dont l’auteur du logiciel est responsable et qui n’est pas causé par la création du paquet Debian
FTBFS (fails to build from source) : le bogue touche le paquet source et bloque sa compilation. On corrige beaucoup de ce genre de bug lors d’une bug squashing party

Voir aussi

Corrections

Correction de l’erreur dans les sources du paquet.

Téléchargez les sources du paquet dans un répertoire temporaire, puis rendez-vous dans le répertoire du paquet pour faire vos modifications :

cd /tmp
apt-get source nom-du-paquet
cd repertoire-du-paquet

Faites vos corrections.

Mettre à jour le changelog

Ajoutez ensuite les modifs au changelog à l’aide de la commande dch qui permet de modifier proprement ce fichier :

dch --close numero-du-bug --nm

La commande dch prépare le nouveau paragraphe du changelog comprenant vos modification, mais il est important de compléter les informations préremplies par quelques précisions. Si vous avez déclaré (avec export DEBEMAIL) votre adresse mail, celle-ci s’ajoutera automatiquement dans le changelog.

Vérifications

Vous devez reconstruire le paquet. C’est le moment de vérifier que vos modifications n’ont rien abîmé et que tout compile bien.

Pour cela, vous utiliserez la commande debuild qui compile le paquet source et produit un ou plusieurs paquets binaires, debuild générera aussi un nouveau fichier .dsc nécessaire à la création de votre patch.

Certains paquets sources demandent des dépendances particulières pour être compilés ; ils sont listés à dans la section “Build-depends” du fichier debian/control de votre paquet source. La commande apt-get build-dep vous permettra d’installer automatiquement ces paquets.
La partie spécifique à Debian du numéro de version d’un nouveau paquet doit être différente pour un nouvel upload. Si l’upload précédent était fait par le mainteneur officiel, on ajoutera .1 aprés le numéro de la version (exemple 2.0-3 => 2.0-3.1). Si c’était déjà une NMU, on incrémentera le numéro de version précédent (exemple 2.0-3.1 => 2.0-3.2).

À la fin de la compilation, le mot de passe de votre clef gpg vous sera demandé pour signer le nouveau paquet.

Après la compilation du paquet, debuild lance lintian qui vous informe des potentielles infractions du paquet à la Debian policy. Il est parfois intéressant de corriger ces erreurs-là aussi. (attention, certaines de ces modifications peuvent bloquer la recompilation.)

lintian-info explique la signification de la ligne d’erreur :

echo 'ligne d'erreur lintian' | lintian-info

Dans ce cas, corriger à nouveau les erreurs, puis ajouter ces changements dans le changelog avec la commande dch. Recompiler avec debuild et revérifier que tout se passe bien.

Création du fichier patch

Avec debdiff, créer un fichier “patch” contenant les différences entre l’ancien et le nouveau fichier .dsc (descriptions) :

debdiff nomdupaquet_2.0-3.dsc nomdupaquet_2.0-3.1.dsc > nomdupaquet-2.0-3.1-nmu.patch

Publier votre patch

Écrire à : numéro-du-bug@bugs.debian.org pour signaler humainement la correction du bug. Joindre votre patch.

Mettre en copie control@bugs.debian.org pour rajouter le tag patch au bug (voir la page debian-control pour la syntaxe et les options, et ne pas oublier de finir votre message aux robots par “thanks” qui leur indiquera la fin de votre message). Attention, la rédaction des mails se fait impérativement en anglais.

===exemple===

pour : 666@bug.debian.org
cc : control@debian.org
objet : NMU diff for nomdupaquet_2.7.0-1

tags 666 + patch pending
thanks

hi,

Here’s the diff for my NMU.

Regards,

nomdupaquet-2.7.0/debian/control
=======================================
diff -u nomdupaquet-2.7.0/debian/control nomdupaquet-2.7.0/debian/control
— nomdupaquet-2.7.0/debian/control
+++ nomdupaquet-2.7.0/debian/control
@@ -53,7 +53,7 @@
Package:·nomdupaquet-source
Architecture:·all
-Depends:·module-assistant,·debhelper·(>=·5),·make,·bzip2
+Depends:·module-assistant,·debhelper·(>=·5),·make,·bzip2,·dpatch
Description:·Source·for·the·Fuse·kernel·module
·Simple·interface·for·userspace·programs·to·export·a·virtual
·filesystem·to·the·Linux·kernel.

nomdupaquet-2.7.0/debian/changelog
=======================================
diff -u nomdupaquet-2.7.0/debian/changelog nomdupaquet-2.7.0/debian/changelog
— nomdupaquet-2.7.0/debian/changelog
+++ nomdupaquet-2.7.0/debian/changelog
@@ -1,3 +1,10 @@
+nomdupaquet·(2.7.0-1.1)·unstable;·urgency=low
+
+··*·Non-maintainer·upload.
+··*·nomdupaquet-source:·fixed·missing·dependency·to·dpatch·package·(Closes:·#666)
+
+·–·Prenom Nom···Sun,·30·Sep·2007·18:00:53·+0200
+
nomdupaquet·(2.7.0-1)·unstable;·urgency=low
··*·New·upstream·release:

Choisir ces pièces jointes

Assurer la promotion des Logiciels Libres nécessite une attitude cohérente dans l’ensemble des activités informatiques. Aujourd’hui, je vous propose un exemple simple de promotion : la gestion des pièces jointes dans votre messagerie.

Que ce soit à destination personnelle ou à vocation professionnelle, l’envoi de pièces jointes est devenue monnaie courante. Toutefois, faites vous attention aux formats utilisés pour vos différents fichiers ?

L’envoi de fichiers enregistrés dans des formats propriétaires semblent tout à fait contre-indiqué. Nous ne citerons ici que le plus connu d’entre eux, le format .DOC émanant de la suite bureautique de la firme Microsoft.

Il est donc préférable d’utiliser des formats ouverts et de préférence inter-opérables… A ce point, le débat s’ouvre et les querelles s’affichent ! Si nous sommes d’accord sur le format à ne pas utiliser, l’ambiguité est de mise lorsqu’il s’agit de se mettre d’accord sur un format commun…

Le plus simple et le plus radical. Le .txt qui outre le fait que la plupart des mises en page disparaissent, permet un stockage de données infiniment plus réduit (quelques ko) que les autres.

Ensuite le format .rtf (Rich Text Format) semble être un bon compromis entre conservation des données de mise en page et poids de fichier.

Ce qui est valable pour un fichier issu d’un traitement de texte, l’est aussi pour toutes les autres applications. Alors attention, maintenant veillez à ne plus transmettre des fichiers sous n’importe quel format dans vos courriers électroniques.

Et si on allait plus loin, et que l’on refusait aussi les fichiers enregistrés dans des fichiers propriétaires. Je vous conseille de lire l’article suivant à ce sujet :

http://www.gnu.org/philosophy/no-word-attachments.fr.html

Bonne pièce jointe !