Macsim's mind: $tail -f macsim

Debian à une forte utilisation de son système de suivit de bug, (BTS) pour la coordination des travaux, et pour que les développeurs sachent quels problèmes doivent être corrigé.
Cet article est dédié à ceux qui n'ont jamais vu le BTS avant, ou ceux qui l'on utilisé un peu, mais qui voudraient savoir comment manipuler les bugs.

1. Regarder les bugs.

Si vous voulez voir quels bugs ont été reporté sur le BTS c'est simple à faire en utilisant l'interface web. Elle est accessible à http://www.debian.org/Bugs/. Si vous allez sur cette page vous pouvez voir un formulaire pour rechercher les rapports de bug. Le système est basé sur les packages, donc vous pouvez entrer le nom d'un package et rechercher tous les bugs en relation avec ce package.

Par exemple, entrez apt dans la boite de recherche, et assurez vous que l'option "package" est sélectionnée juste au dessus.
Ensuite cliquez sur le bouton de recherche "find". Cela va faire apparaître une page avec tous les bugs apparentés à apt.
Vous pouvez cliquer sur n'importe quel titre de bug pour avoir plus d'information à son sujet.

Il y a aussi des raccourcis que vous pouvez utiliser ex: http://bugs.debian.org/apt pour avoir tous les bugs d'apt et http://bugs.debian.org/383487 pour le bug #383487.


2. Etat (States), Sévérité (Severities) et Etiquette (Tags).


Vous pouvez voir que les bugs sont divisés en sections. Ces section sont basées sur les états dans lesquels les bugs se trouvent, et les sévérités (Severities) qu'il leur ont été assignées. Ceci aide le mainteneur du package à voir ce qui doit être fait et ordonner ses travaux par priorité.

Les états pour les bugs sont:


• Open (Ouvert) - Le bug n'as pas été corrigé.
• Forwarded (Transféré) - Le bug a été transféré au mainteneur supérieur car le bug requiert ces compétences
• Resolved (Résolu)- Le bug a été corrigé.

Les sévérités sont:


• wishlist (liste de souhait) - La personne qui a soumit voudrait qu'une nouvelle fonctionnalité soit ajoutée au package.
• minor (mineur) - Il y a quelque chose qui ne va pas avec le package mais qui n'a pas vraiment d'importance, mais devrait être corrigé quand même, cela peut être une typo dans la description d'un package, par exemple.
• normal (normal) - Celui ci est le plus courant. Il y a un problème avec le package, mais il ne casse pas tout le package, ou ne pose pas trop de problèmes dans son fonctionnement.
• important (important)- Ce bug a un gros impact sur la stabilité du système.

Ce sont les sévérités que vous utiliserez normalement. Il y a trois autres sévérités, et elles ont une définition spéciale. Elles ont aussi un traitement spécial quand elle ne sont pas fixées. Vous ne pouvez utiliser ces sévérités que si vous comprenez vraiment ce qu'elles définissent. Ne vous en faites pas trop, si vous reportez un bug qui nécessite une de ses sévérité, il sera mis à niveau.


• serious (sérieux) - Une violation de la politique de Debian. Les règles définies dans la politique visent à ce qu'aucun package ne casse le système sur lequel il est installé, et essayent aussi de garder les packages cohérents. Jetez un oeil au document sur la politique de debian (Debian policy) si vous êtes intéressés.
• grave (grave) - Un bug qui rend le package inutilisable quelque soit la situation. Cela couvre par exemple les packages ininstallable, les segmentations fault au démarrage, les fichiers manquants. Il ne devrait cependant être utilisé que quand il casse le logiciel pour la plupart des utilisateurs, il peut être difficile de savoir quand c'est le cas mais l'expérience aide. Cette sévérité peut aussi couvrir les trous de sécurités.
• critical (critique) - L'installation du package casse les autres logiciels installés sur le système, ou bien sur tout le système. Cela couvre les programmes qui provoquent des pertes de données et le reste des bugs de sécurité

Les étiquettes sont utilisées par les développeurs pour garder une trace de ce qui se passe sur les bugs. Une liste complète est disponible à http://www.debian.org/Bugs/Developer#tags.
La plupart de ceux que vous rencontrerez sont:


• patch - Quelqu'un à soumit un patch pour résoudre le problème. Ceci ne s'applique pas à toutes les situations.
• wontfix (ne sera pas fixé)- Le mainteneur ou le développeur a dit qu'il ne fixerai pas le bug pour certaines raisons. Il y aura habituellement une explication dans le rapport du bug.
• moreinfo (Plus d'info)- L'envoyeur n'a pas fournit assez d'information pour le mainteneur. Si vous êtes touchés par un bug avec un étiquette "moreinfo" alors vous devez suivre ce que le mainteneur souhaite comme indiqué si dessous.
• unreproducible (inreproductible)- Le mainteneur ne peut reproduire le bug sur son système. C'est similaire à l'étiquette moreinfo, dans ce cas si vous pouvez reproduire le bug vous pouvez aider le mainteneur en lui envoyant plus d'informations dans le rapport de bug.
• help (aide)- Le mainteneur ne peut pas corriger le bug par lui-même (par exemple il se produit sur une architecture où il n'a pas accès), et il voudrait que d'autres personnes l'aident à trouver la solution.
• pending (en attente) - Le problème est résolu et une mise à jour devrait arriver bientôt pour fixer le problème.

Certaines des autres étiquettes sont plus ou moins évidentes (ex: security) ou sont plus utilisées pour le traçage à travers la distribution (ex: ipv6).


3. Reporter un bug.


Si vous trouvez un bug et que vous voudriez le voir fixer alors vous devez utiliser le BTS pour avertir les mainteneurs et travailler avec eux pour le résoudre. Mais avant tout, vous devez rapporter le bug.

Avant de le reporter il y a quelques choses que vous devez savoir.
1. Trouver de quel package le bug provient.
• Parfois c'est vraiment simple, et vous saurez immédiatement quel package
• Si vous savez qu'il ne se produit uniquement que sur un certain fichier ou programme, vous pouvez utiliser dpkg -S avec le nom du fichier pour trouver à quel package il appartient.
• Si vous ne pouvez savoir d'où il provient, alors vous allez essayer de deviner à quel package ce bug peut être lié, et vous allez le reporter sur le package. Vous devrez reporter que vous ne faites qu'une supposition et le mainteneur du package essayera de vous aider pour identifié la cause.
2. Trouver si un bug n'a pas déjà été reporté.
• Utilisez le champs de recherche de package pour voir la liste des bugs sur ce package et regardez si votre bug n'est pas déjà listé. Si il est déjà listé alors ne refaite pas un nouveau bug, vous pouvez ajouter des informations à la suite de l'existant.
• Vous devriez vérifier les quelques packages associés pour être sûr que vous ne mettez pas les mainteneurs sur la mauvaise voie.
3. Récupérez le plus d'informations que possible. Idéalement un rapport devrait contenir:
• Les étapes de reproductions, ex: la séquence complète de commandes utilisées qui provoque un problème.
• Tous les fichiers de configurations relatifs au problème, ou les options du programme.
• Tous les fichiers de log pertinent. Vous pouvez les joindre au rapport.
• Toutes les informations que vous jugez utiles.
• Tous les tests que vous avez essayé, ou toutes choses intéressantes que vous avez notées sur le bug.
• Si vous savez comment ajouter une trace avec gdb, ou la sortie d'un strace. Ceux-ci peuvent être d'une aide précieuse dans certains cas.
Maintenant, vous avez toutes ces informations vous êtes prêts à reporter le bug. La méthode préférable pour faire ça est d'utiliser le programme reportbug, ainsi

# apt-get install reportbug


Et lancer simplement



$ reportbug


Il y a beaucoup d'options que vous pouvez passer à reportbug (man reportbug vous aidera), mais reportbug va vous guider a travers les étapes nécessaires pour envoyer le rapport.

Donc en premier lieu, il vous est demandé le nom du package sur lequel vous désirez reporter un bug.



Please enter the name of the package in which you have found a problem, or type 'other' to report a more general problem.


Une fois que vous avez entré le nom du package vous allez voir une liste des bugs déjà fichés pour ce package. Assurez vous que votre bug n'est pas déjà listé et continuez. S'il est déjà listé vous pouvez ajouter plus informations (voir ci-dessous).

Quand vous avez vérifié les reports de bug, vous serez invité à saisir le sujet de votre rapport de bug.



Please briefly describe your problem (you can elaborate in a moment; an empty response will stop reportbug). This should be a concise summary of what is wrong with the package, for example, "fails to send email" or "does not start with -q option specified."


Beaucoup de personne aiment démarrer avec le nom du package (Sachez que ce n'est pas essentiel) ex:



apt: does not download correct version of dpkg


Vous serez ensuite invité à saisir la sévérité de votre rapport. Sélectionnez le numéro depuis la liste qui correspond au mieux d'après vous. Si vous n'êtes pas sûr appuyez simplement sur Entrée et il sera par defaut en normal et les mainteneurs le changerons si besoin est.

reportbug peut vous demandez s' il peut inclure certains fichiers de configuration dans le rapport. Vous devriez dire oui (yes), sauf si les fichiers contiennent des données sensibles (ex: des mots de passes).

Un éditeur va alors apparaître pour que vous tapiez votre rapport de bug. Remplissez les informations comme décrites ci dessus, ensuite sauvez le fichier et fermez l'editeur.

Vous arriverez ensuite au menu final



Report will be sent to "Debian Bug Tracking System" Submit this report on apt (e to edit) [y|n|a|c|E|i|l|m|p|q|?]?


Il y a beaucoup d'options ici. Tapez ? pour obtenir une liste. Les plus intéressantes sont:

• e - (éditez encore le rapport)
• a - (joindre un autre fichier ex: fichier de log, une trace de gdb)
• y - (envoyer le rapports par email).

Quand vous avez fini, choisissez y pour l'envoyez (ou si nécessaire vous pouvez choisir d'autres options pour l'envoyer vous même) C'est fait après ça, vous avez envoyé votre premier rapport.

Vous allez recevoir une copie de votre rapport dans la foulée, et une confirmation du BTS dans l'heure.

C'est possible d'envoyer un rapport de bug par email si vous le voulez. Les instructions sont données à http://www.debian.org/Bugs/Reporting. Ne pas utiliser reportbug a pour inconvénients que vous devez faire beaucoup de choses vous même, comme la vérification des bugs, l'inclusion automatique de certaines informations.


4. Ajouter à un bug.


Si vous désirez envoyer plus d'information sur un rapport de bug il y a deux façons pour le faire.


• Utiliser reportbug à nouveau.
• Utiliser l'email.
Je ne vais pas décrire reportbug dans le détail, étant donné qu'il vous procure de l'aide, et la procédure est similaire à celle vue avant.

Pour utiliser reportbug pour ajouter des détails sur un bug, démarrez reportbug et entrez le nom du package. Ensuite quand la liste des bugs est affichée pressez y, ce qui va vous demander le numéro du bug. Vous pouvez procéder comme avant. Si vous voyez le bug dans la liste, vous entrez le numéro à gauche, et reportbug vous affichera le rapport de bug. Si vous appuyez sur x, alors il vous sera possible d'ajouter des information au bug.

Pour envoyer des information par email vous avez juste besoin d'envoyer un mail à numéro-du-bug@bugs.debian.org, ex: 22334@bugs.debian.org. Le contenu de l'email fera partie intégrante du rapport de bug.

Quelque soit la méthode que vous utilisez il est préférable de ne pas envoyer d' email comme


Subject: Bug #12345
I am seeing this bug as well, can I help fixing it?



Autant il est bien d'offrir son aide, il est nécessaire pour les personnes qui reçoivent cet email (et beaucoup de personnes reçoivent ce mail) d'aller voir le bug. Il serait mieux d'envoyer quelque chose comme:



Subject: Re: Bug#13245: apt doesn't download correct version of dpkg
I am also seeing this bug. I have tried giving the version on the
command line to apt, but it still downloads version 1.2.3 of dpkg.

Is there anything else I can do to help?




Cela dit la même chose, mais donne un meilleur contexte à la personne qui reçoit le email, et ils peuvent répondre directement à votre email s'ils veulent, sans avoir à rechercher le bug.


5. Manipuler les bugs.


Vous pouvez manipuler les bugs en utilisant les mails. Cela implique d'envoyer un email à control@bugs.debian.org avec un certain format. Le message sera alors traité, et les instructions seront exécutées.

La documentation complète pour savoir comment faire est diszponible à http://www.debian.org/Bugs/server-control et c'est une bonne référence.

Un exemple d'email devrait ressembler à



#Considérer le bug comme appartenant à apt
package apt
#Changer la sévérité
severity 12345 normal
#Réassigné le bug
reassign 12345 dpkg
#Stoper.
stop


Les commentaires sont optionnels et ne sont utilisés ici que pour illustrer ce qui se passe. La commande stop est utilisée de cette façon le serveur ne traite pas plus que l'email et ne se trompe pas.


6. Fermer et réouvrir des bugs.


Si vous voulez fermer un rapport de bug (normalement seul le créateur et les mainteneurs peuvent faire ça), vous pouvez envoyer un email à numerodubug-done@bugs.debian.org et inclure un Version: pseudo-header qui dira au système dans quelle version le bug à été fixé. ex:


To: 12345-done@bugs.debian.org
Version: 1.2.3
This is fixed in the latest upload. Thanks for your patience.


La version est utilisée donc il est possible de tracer quand un bug à été ouvert et fermé, donc on peut savoir à quelles versions un bug s'applique.

Si vous découvrez un bug qui a déjà été fermé, mais réapparait dans une nouvelle version, vous pouvez envoyer un email avec la commande de recherche à control@bugs.debian.org (voir ci-dessus), ex:


found 1234 1.2.4
stop

I have found this in version 1.2.4, it occurs in the same conditions
as before.




Vous ne devez faire celà que si c'est le meme bug. Postez un nouveau si c'est un bug différent.


7. Autres astuces.


Il y a beaucoup d'autres choses que vous pouvez faire avec le BTS. Je vais vous laissez découvrir comment les utiliser. La documentation http://www.debian.org/Bugs/ couvre la majorité d'entre eux.
• bts tool - Ce package de script de développement contiend un outils appelé bts. C'est un manière facile d'envoyé des commands au BTS. ex: bts severity 12345 normal
• subscriptions - il est possible de souscrire à un rapport de bug, alors vous recevrez toutes les informations envoyé au rapport, vous serez ainsi informé quand il est fermé.
• usertags - Vous permet d'étiqueter les bugs pour vous-même. Les autres personnes qui regarderont les rapports ne les verront pas en principe. Ceci sont la plupart du temps utilisé par les mainteneurs qui recherche beaucoup de bug de façon à ce qu'ils puissent les trier et leur donner une priorité.