Le système de gestion des bugs de Debian (BTS) <author>Ian Jackson <email/ijackson@gnu.ai.mit.edu/ <author>Christian Schwarz <email/schwarz@debian.org/ <version>version 0.2, <date> <copyright>Copyright ©1997 Ian Jackson and Christian Schwarz. This manual is free software; you may redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details. A copy of the GNU General Public License is available as <tt>/usr/doc/copyright/GPL</tt> in the Debian GNU/Linux distribution or on the World Wide Web at <tt>http://www.gnu.org/copyleft/gpl.html</tt>. You can also obtain it by writing to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. <toc sect> <chapt>A propos de ce manuel Ce manuel détaille le système de gestion des bugs de Debian. Il a été conçu comme une introduction et comme une référence pour les utilisateurs et les développeurs Debian. A la base, un rapport de bug est envoyé par un utilisateur, sous forme d'un e-mail à <tt>submit@bugs.debian.org</tt>. Ce bug reçoit alors un numéro, vérifié par l'utilisateur, et est envoyé à la liste de diffusion <tt>debian-bugs-dist</tt>. Si le rapporteur a inclus une ligne `Package` donnant un nom de paquet connu, le mainteneur de ce paquet recevra également une copie du mail. <tt>Bug#nnn:</tt> sera rajouté à la ligne `Objet` du mail, et le champ `Répondre à` inclura à la fois le rapporteur du bug et <tt>nnn@bugs.debian.org</tt>. <chapt>Rapporter un bug <sect>La procédure Si vous désirez rapporter un bug (dans n'importe quelle partie du système Debian GNU/Linux, c'est à dire dans un document ou dans un paquet), envoyez un mail à <tt>submit@bugs.debian.org</tt>. Le rapport de bug sera automatiquement traité par un programme, posté à la liste de diffusion <tt>debian-bugs-dist</tt> (bien que vous puissiez empêcher ceci, voir plus bas), et transmis au mainteneur responsable. C'est pourquoi le rapport de bug doit inclure, à son début, un pseudo-entête permettant au système de gestion des bugs d'assigner le bug au paquet spécifié, et de déterminer le mainteneur. Le pseudo-entête pour un rapport de bug concernant le paquet <tt>foo</tt>, dans sa version <tt>1.0-1</tt>, sera ainsi : <example> Package: foo Version: 1.0-1 </example> Etant donné que c'est un 'entête', il devra être placé au début du mail. (Attention ,le système de gestion des bugs de gère pas les emails MIME correctement, à l'heure actuelle. C'est pourquoi il est recommandé de ne pas signer votre rapport de bug avec PGP, étant donné que la ligne de séparation PGP serait considérée comme un entête erroné ). Le système de gestion des bugs connaît un certain nombre de pseudo-paquets pour les parties de Debian qui ne sont pas de paquets. Il y a: <taglist> <tag><tt/base/ <item>Bugs généraux dans le système de base <tag><tt/bootdisk/ <item>Bugs dans la disquette "boot" <tag><tt/rootdisk/ <item>Bugs dans la disquette "root <tag><tt/bugs.debian.org/ <item>Le système de gestion de bugs, @bugs.debian.org <tag><tt/ftp.debian.org/ <item>Problèmes avec le site FTP <tag><tt/nonus.debian.org/ <item>Problèmes avec le site FTP non-US <tag><tt/www.debian.org/ <item>Problèmes avec le site web <tag><tt/project/ <item>Problèmes liés à l'administration du Projet <tag><tt/general/ <item>Problèmes généraux (comme par exemple, de mauvaises permissions sur les pages de manuel) <tag><tt/kernel/ <item>Problèmes avec le noyau Linux, ou celui livré avec Debian. <tag><tt/lists.debian.org/ <item>Les listes de diffusion, debian-*@lists.debian.org. </taglist> (Une liste tenue à jour des <em/pseudo-paquets/ existe sur l'interface web du système de gestion des bugs. Si vous avez un programme buggé, pour lequel vous voulez remplir un rapport de bug, il vous faudra tout d'abord déterminer le nom du paquet et sa version. Vous pouvez les obtenir en utilisant <tt>dpkg --search</tt> et <tt>dpkg --list</tt>; voir <tt>dpkg --help</tt> pour plus d'explications. <sect>Contenu du rapport de bug Votre rapport de bug devrait contenir les informations suivantes : <list> <item> Le texte exact et complet de tout message d'erreur affiché ou enregistré. Ceci est très important ! <item> Ce ques vous avez tapé ou fait pour produire le problème. <item> Un description du comportement incorrect: quel comportement attendiez-vous et que s'est-il passé ? Un résumé d'une session type est une bonne facon de faire cette partie. <item> Une solution suggérée, voire même un patch, si vous en avez un. <item> Les détails de la configuration du programme incriminé Incluez le texte complet des fichiers de configuration. <item> La version du système Debian que vous utilisez. <item> La version du noyau que vous utilisez (faites uname -a). <item> La librairie C que vous utilisez (faites <tt>ls -l /lib/libc.so.5</tt>). <item> Tout autre détail de votre système Linux, si cela vous semble approprié. Par exemple, si vous avez eu un problème avec un script Perl, vous pouvez vouloir donner la version de votre programme perl (perl -v). <item> Des détails appropriés sur votre matériel. Si votre problème concerne un gestionnaire de périphérique, merci de lister la totalité du matériel de votre système. En effet, ces problèmes sont souvent causés par des conflits d'IRQ ou d'adresses I/O. <item> Incluez tout détail qui peut vous paraître utile. Il y a peu de risque que votre rapport contienne trop d'informations ! S'ils ne sont pas trop gros, vous pouvez inclure dans votre rapport tout fichier que vous avez utilisé pour reproduire le problème (encodez-les avec UUE s'ils contiennent des caractères spéciaux, ...) </list> Merci de ne pas rapporter plusieurs bugs sans liens entre eux - particulièrement s'ils concernent des paquets différents - dans un seul message. De même, merci de ne pas envoyer votre rapport de bug à d'autres listes de diffusions ou personnes que <tt>submit@bugs.debian.org</tt>. <sect>Un exemple Un rapport de bug, avec les entêtes du mail, sera ainsi du type <example> To: submit@bugs.debian.org From: diligent@testing.linux.org Subject: Hello says `goodbye' Package: hello Version: 1.3-2 When I invoke `hello' without arguments from an ordinary shell prompt it prints `goodbye', rather than the expected `hello, world'. Here is a transcript: $ hello goodbye $ /usr/bin/hello goodbye $ I suggest that the output string, in hello.c, be corrected. I am using Debian 1.1, kernel version 1.3.99.15z and libc 5.2.18.3.2.1.3-beta. </example> <sect>Utilisation de dpkg pour trouver le paquet et la version Si vous désirez rapporter un bug dans une commande, vous pouvez retrouver le paquet qui l'a installé en utilisant <tt/dpkg --search/. Vous pouvez trouver la version d'un paquet installé en utilisant <tt/dpkg --list/ ou <tt/dpkg --status/. Par exemple: <example> $ which dpkg /usr/bin/dpkg $ type dpkg dpkg is hashed (/usr/bin/dpkg) $ dpkg --search /usr/bin/dpkg dpkg: /usr/bin/dpkg $ dpkg --search '*/dpkg' dpkg: /usr/doc/copyright/dpkg dpkg: /var/lib/dpkg dpkg: /usr/bin/dpkg dpkg: /usr/lib/dpkg dpkg: /usr/doc/dpkg $ dpkg --list dpkg Desired=Unknown/Install/Remove/Purge | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-===============-==============-============================================ ii dpkg 1.2.9elf Package maintenance system for Debian Linux $ dpkg --status dpkg Package: dpkg Essential: yes Status: install ok installed Priority: required Section: base Maintainer: Ian Jackson <ian@chiark.chu.cam.ac.uk> Version: 1.2.9elf Replaces: dpkgname Pre-Depends: libc5 (>= 5.2.18-2), ncurses3.0 Conflicts: dpkgname Description: Package maintenance system for Debian Linux This package contains the programs which handle the installation and removal of packages on your system. . The primary interface for the dpkg suite is the `dselect' program; a more low-level and less user-friendly interface is available in the form of the `dpkg' command. $ </example> <sect>Bugs mineurs Si un bug est mineur (une faute d'ortographe dans la documentation, ou un petit problème), ou que vous envoyez un certain nombre de rapports en même temps, envoyez-les à <tt>maintonly@bugs.debian.org</tt> ou <tt>quiet@bugs.debian.org</tt>. <tt>maintonly</tt> n'enverra le rapport qu'au mainteneur du paquet (si vous avez donné une ligne "Package" correcte dans le pseudo-entête et que le mainteneur est connu et <tt>quiet</tt> ne le transmettra nulle part, et ne fera qu'enregistrer le bug (utile si vous postez un grand nombre de bugs similaires, et que vous ne désirez poster qu'un résumé). De plus, le système de gestion des bugs règlera le champ <tt>Reply-To</tt> de facon à ce que les réponses soient traitées comme le rapport original. <sect>Envoyer une copie du rapport à d'autres adresses Il est parfois nécessaire d'envoyer une copie d'un rapport de bug ailleurs que sur la liste <tt>debian-devel</tt> et au mainteneur du paquet (où il est normalement envoyé). Vous pourriez faire ceci en mettant en Cc de votre rapport les autres adresses, mais en faisant ainsi, les autres copies n'auraient pas le numéro du rapport de bug dans les champs <tt>Reply-To</tt> et <tt>Objet</tt> du mail. De plus, si les destinataires répondent, il est probable qu'ils laissent le champ <tt>To: submit@bugs.debian.org</tt>. Leurs messages sont ainsi traités comme de nouveaux rapports de bug, ce qui conduit à de nombreux doublons. La bonne façon de procéder est d'utiliser l'entête <tt>X-Debian-CC</tt>. Ajoutez cette ligne à l'entête de votre mail (pas le pseudo-entête) : <example> X-Debian-CC: other-list@cosmic.edu </example> Ceci fera que le système de gestion des bugs enverra une copie de votre rapport à ou aux adresses spécifiées dans la ligne <tt>X-Debian-CC</tt> en plus de la liste <tt>debian-devel</tt>. Cette fonctionnalité peut souvent être combinée avec l'utilisation de <tt>quiet@bugs.debian.org</tt> <sect>Paquets inconnus ou bugs sans champ 'Package' Si le système de gestion des bugs ne connait pas le mainteneur du paquet, le rapport sera envoyé à la liste <tt>debian-devel</tt>, même si <tt>maintonly</tt> était utilisé. Lors de l'envoi à <tt>maintonly@bugs.debian.org</tt> ou à <tt>nnn-maintonly@bugs.debian.org</tt>, vous devez vérifier que le bug est assigné au bon paquet en mettant une ligne 'Package' correct dans le rapport de bug, ou en utilisant le système <tt>control@bugs.debian.org</tt> pour (ré)assigner le rapport si une erreur a eu lieu (voir plus bas). <chapt>Obtenir des informations sur les bugs Chaque message reçu ou envoyé par le système de gestion des bugs est enregistré et disponible d'un certain nombre de façons. Des copies des logs sont disponibles sur le Web à l'adresse <tt>http://www.chiark.greenend.org.uk/debian/Bugs/</tt> et <tt>http://www.debian.org/Bugs/</tt>. Les fichiers HTML contenant le log du rapport de bug sont disponibles dans le répertoire WebPages de l'archive FTP de Debian et seront disponibles sur les miroirs qui ne l'ont pas explicitement desactivé dans leur configuration. Un serveur web configuré pour servir cette partie du FTP comme un web fournira ainsi une copie locale de ces pages. Il existe un serveur mail qui peut envoyer des rapports de bug au format texte sur demande. Pour l'utiliser, envoyez le mot <tt/help/ comme seul contenu d'un mail pour <tt>request@bugs.debian.org</tt> (l'objet est ignoré), ou lisez les instructions sur le web ou dans ce document. <sect>L'interface mail Il existe un serveur mail qui peut envoyer des rapports de bug et des informations au format texte sur demande. Pour l'utiliser, envoyez un message à <tt>request@bugs.debian.org</tt>. Le sujet est ignoré, à part pour générer le sujet de la réponse. Le corps doit être une série de commandes, une par ligne. Vous recevrez une réponse, qui est la transcription de l'interprétation de votre message, avec une réponse pour chaque commande. Pour la plupart des commandes, aucune notification n'est envoyée; mais, les messages sont enregistrés et mis à disposition sur les pages web. Tout texte sur une ligne commençant par un '#' sera ignoré; le serveur arrêtera de traiter le mail dès qu'il aura trouvé une ligne commencant par quit, stop, thank ou deux tirets, pour éviter de traiter une signature. Il s'arrêtera également s'il trouve trop de commandes non reconnues ou mal formatées. Si aucune commande n'est correctement traitée, un texte d'aide sera envoyé. Voici la liste des commandes disponibles: <taglist> <tag><tt>send bugnumber</tt> <item> <tag><tt>send-detail bugnumber</tt> <item> Demande la transcription de session pour le rapport de bug en question. send-detail envoie tous les messages de debug, tels que les réponses automatiques. (vous devez également utiliser send, car send-detail n'envoie pas les messages "interessants"). <tag><tt>index [full]</tt> <item> <tag><tt>index-summary by-package</tt> <item> <tag><tt> index-summary by-number</tt> <item> Demande l'index complet, avec tous les détails, incluant les rapports traités et transmis, ou le résumé, trié par paquet ou par numéro respectivement. <tag><tt> index-maint</tt> <item> Demande la page d'index donnant la liste des mainteneurs ayant des bugs (ouverts et fermés récemement) du système. <tag><tt> index maint maintainer</tt> <item> Demande les pages d'index des bugs du système, pour tous les mainteneurs dont le nom contient 'maintainer'. La recherche ne prend pas la casse en compte. L'index des bugs de chaque mainteneur sera envoyé dans un message séparé. <tag><tt> send-unmatched [this|0]</tt> <item> <tag><tt> send-unmatched last|-1</tt> <item> <tag><tt> send-unmatched old|-2</tt> <item> Demande les logs de messages qui n'appartiennent pas à un rapport de bug particulier, pour cette semaine, la semaine précédente et celle d'avant. (Une semaine se finit le mercredi). <tag><tt> getinfo filename</tt> <item> Demande un fichier d'information sur le(s) paquets et le(s) mainteneurs. Les fichiers disponibles sont: maintainers La liste des mainteneurs utilisée le système de gestion des bugs. Celle-ci est construite à partir du fichier Packages et a priorité sur les fichiers et les pseudo-paquets. override.stable override.development override.contrib override.non-free override.experimental override.codeword Informations sur les priorités et les sections des paquets et les valeurs pour les mainteneurs. Ces informations sont utilisées par le système qui génère le fichier Packages de l'archive FTP. L'information est disponible pour chaque arbre de la distribution. Les versions stables et en développement sont accessible par leur status et par leur nom de code. pseudo-packages.description pseudo-packages.maintainers Liste des descriptions et des mainteneurs pour les pseudo-paquets. <tag><tt> refcards</tt> <item> Demande l'envoi en ASCII de la référence du serveur mail. <tag><tt> help</tt> <item> Demande l'envoi du document d'aide en ASCII. <tag><tt>quit</tt>, <tt>stop</tt> <item> <tag><tt> thank...</tt> <item> <tag><tt> --...</tt> <item> Interrompt le traitement du message. Vous pouvez inclure tout le texte que vous désirez après ce point, il sera ignoré. Vous pouvez utiliser ceci pour inclure des commentaires plus longs que ceux pour lesquels un # est adapté, pour le bénéfice des lecteurs humains de votre message (qui peuvent le lire par les logs du BTS ou via un Cc ou Bcc.) <tag><tt> #... </tt> <item> Commentaire sur une ligne. Le # doit être au début de la ligne. <tag><tt> debug level</tt> <item> Règle le niveau de débuggage à 'level', qui doit être un entier positif. 0 correspond à un débuggage nul, 1 suffit généralement. La sortie de débuggage apparait dans la transcription. Il est peu probable que ceci soit utile aux utilisateurs du système de gestion des bugs. </taglist> Il existe une référence des serveurs de mail, disponible sur le web, dans le fichier bug-mailserver-refcard.txt ou par mail, en utilisant la commande refcard (voir ci-dessus). Si vous désirez manipuler des rapports de bug, vous devez utiliser l'adresse <tt>control@bugs.debian.org</tt>, qui acceptent une série de commandes listées ci-dessus. Ceci est décrit dans <ref id="mailcontrol"> ou en envoyant un mail à control@bugs.debian.org Si vous lisez ceci en mode texte ou par mail: une version HTML est disponible par la page principale du système de gestion des bugs <tt>http://www.debian.org/Bugs/</tt>. Toutes les suggestions sont les bienvenues. Envoyez un mail à owner@bugs.debian.org, debian-user@lists.debian.org ou debian-devel@lists.debian.org. <sect>Résumés Chaque vendredi, une liste de rapports de bugs est postée à <tt>debian-devel</tt>, triés par âge; chaque mardi, une liste de rapports de bugs auxquels aucune réponse n'a été apportée depuis trop longtemps est postée, triée par mainteneur. Si le mainteneur d'un paquet n'est pas listé correctement, ceci est généralement dû au fait que le mainteneur a changé récemment, et que le nouveau mainteneur n'a pas encore envoyé une nouvelle version du paquet avec le champ 'Mainteneur' du fichier de contrôle modifié. Ceci sera réglé dès que le nouveau paquet aura été envoyé; sinon, il existe un fichier "override" dans lequel les mainteneurs de distribution peuvent éditer le mainteneur, si, par exemple, une nouvelle version du paquet n'est pas prévue pour avant un certain temps. Contactez: <tt>iwj-mastercron@master.debian.org</tt> pour changer ce fichier. <chapt>Gérer les rapports de bug <sect>Messages de suivi Si un développeur désire répondre à un rapport de bug sans marquer le bug comme résolu, il doit simplement répondre au message. Par défaut, la réponse sera envoyée à <tt>nnn@bugs</tt> et au rapporteur initial du bug. Le BTS enregistrera la réponse avec le reste des logs pour ce rapport de bug et la fera suivre à <tt>debian-devel</tt>. Le bug ne sera pas marqué comme résolu. Si vous désirez envoyer un message de suivi qui n'est pas approprié pour <tt>debian-devel</tt>, envoyez-le à <tt>nnn-quiet@bugs</tt> ou <tt>nnn-maintonly@bugs</tt>, ce qui fera qu'il ne sera qu'enregistré (pas transmis) ou envoyé seulement au mainteneur du paquet en question, respectivement. N'utilisez pas les fonctions 'Répondre à tous' ou 'Faire suivre' de votre logiciel de mail, à part si vous éditez manuellement les destinataires. Tout particulièrement, n'envoyez pas de message à la fois à <tt>nnn@bugs.debian.org</tt> et à <tt>submit@bugs.debian.org</tt>, car le BTS en recevrait alors deux copies, qui seraient toutes deux transmises à <tt>debian-devel</tt>. <sect>Montrer que vous avez pris en compte un rapport de bug Quand un développeur transmet un rapport de bug au développeur du paquet source duquel le paquet Debian est extrait, il doit le faire savoir dans le BTS, comme suit: S'assurer que le champ 'To:' du message à l'auteur ne contient que l'adresse de l'auteur; mettre à la fois le rapporteur et <tt>nnn-forwarded@bugs.debian.org</tt> en copie. Demander à l'auteur de conserver le 'Cc' sur <tt>nnn-forwarded@bugs</tt> dans leur réponse, de facon à ce que le BTS garde la trace de toute la correspondance. Quand le BTS recoit un message à <tt>nnn-forwarded</tt>, il marque le bug comme étant transmis à l'adresse marquée dans le 'To' du message. Vous pouvez également manipuler les informations 'transmis à' en envoyant des messages à <tt>control@bugs</tt>. <sect>Fermer des rapports de bug Un développeur qui voit un bug dans <tt>debian-devel</tt> et qui le prend en charge doit faire "Répondre" dans son logiciel de mail, et éditer le champ 'To' pour mettre <tt>nnn-done@bugs.debian.org</tt> à la place de <tt>nnn@bugs</tt> (<tt>nnn-close</tt> est un alias pour <tt>nnn-done</tt>). L'adresse du rapporteur original du bug sera inclue dans le champ 'To' car le BTS l'a mise dans 'Reply-To'. Les messages 'Done' ne sont pas automatiquement transmis à la liste de diffusion, il peut donc parfois être utile de mettre <tt>debian-devel</tt> en Cc si les autres développeurs sont susceptibles d'être interessés. La personne qui ferme le bug, et la personne qui l'a rapporté recevront une notification de changement de status. <sect>Réouvrir, réassigner, et manipuler des bugs. Il est possible de réassigner des bugs à d'autres paquets, de les réouvrir (s'ils ont été fermés par erreur), de modifier les informations de suivi, de changer les titres, et de fusionner des rapports. Tout ceci peut se faire par l'envoi de mails à <tt>control@bugs.debian.org</tt>. La section suivant décrit le format de ces messages. <chapt id="mailcontrol">L'interface de contrôle par mail <sect>Comment ca marche ? En plus du serveur de mail<tt>request@bugs.debian.org</tt>, qui permet de récupérer des informations sur les bugs, il existe un autre serveur: <tt>control@bugs.debian.org</tt>, qui permet la manipulation des rapports de bugs. Le serveur de contrôle fonctionne comme celui de requête, avec des commandes différentes (c'est en fait le même programme). Les deux adresses ne sont séparées que pour éviter que les utilisateurs fassent des erreurs en essayant simplement de récupérer des informations. Voici la liste des commandes disponibles. <taglist> <tag><tt> close bugnumber</tt> <item> Ferme le rapport `#bugnumber.' Une notification est envoyée au rapporteur, mais (à la différence de l'envoi d'un mail à <tt>bugnumber-done@bugs</tt>), le texte du mail qui a causé la fermeture n'est pas inclus dedans. Le mainteneur qui ferme le bug doit s'assurer, par exemple par un message séparé, que le rapporteur sait pourquoi le bug a été fermé. <tag><tt> reassign bugnumber package</tt> <item> Assigne le bug `#bugnumber' à 'package'. Ceci peut être utilisé en cas d'oubli du pseudo-entête, ou pour changer un assignement antérieur. Aucune notification spéciale n'est envoyée. <tag><tt> reopen bugnumber [originator-address|=]</tt> <item> Réouvre `#bugnumber' si celui-ci est fermé. Par défaut, vous êtes enregistré comme origine du rapport, de sorte que vous recevrez une notification à la fermeture. Ceci permet d'éviter de flooder des utilisateurs avec plusieurs notifications concernant le même rapport de bug. Si vous donnez une adresse d'origine, le rapporteur sera réglé à l'adresse donnée; vous pouvez utiliser '<tt>=</tt>' pour garder la même adresse d'origine que précédemment. Il est généralement conseillé de dire à la personne que vous enregistrez comme origine ce que vous faites, afin qu'elle ne soit pas surprise en recevant la notification pour la nouvelle fermeture. Si le bug n'est pas fermé, "reopen" ne fait rien, et ne change pas l'origine. Il n'existe pas de moyen de changer l'origine d'un rapport de bug ouvert (ceci est fait en sorte qu'il ne soit pas possible de fermer un bug, et que celui-ci soit détruit 28 jours plus tard sans que personne ne le sache). <tag><tt> forwarded bugnumber address</tt> <item> Enregistre le fait que le rapport a été transmis à l'auteur à son adresse "address". Ceci ne transmet pas effectivement le rapport. Ceci peut être utilisé pour changer une adresse de transmission erronnée, ou pour en ajouter une pour un bug qui n'a pas été marqué précédemment comme transmis. <tag><tt> notforwarded bugnumber</tt> <item> Efface le fait que le rapport a été transmis à l'auteur. Si ceci n'était pas enregistré, rien ne se passe. <tag><tt> retitle bugnumber new-title</tt> <item> Change le titre du rapport de bug pour new-title. Par défaut, il s'agit du sujet du mail du rapport original. A la différence de la plupart des commandes, si vous l'utilisez sur un bug faisant partie d'un groupe, le changement ne se fera que sur le bug en question et pas sur tous ceux du groupe. <tag><tt> merge bugnumber bugnumber ...</tt> <item> Fusionne plusieurs rapports de bug. Quand des rapports sont fusionnés, l'ouverture, la fermeture, l'ajout de tags et le réassignement d'un bug se transmettent sur tous les rapports fusionnés. Pour que des bugs puissent être fusionnés, ils doivent être exactement dans le même état: tous ouverts ou fermés, avec la même adresse de transmision à l'auteur, ou qu'aucun ne soit marqué comme transmis, et tous doivent être assigné au même paquet(s) (une comparaison des noms exacte est effectuée). Si ce n'est pas le cas, vous pouvez réouvrir, réassigner, ... certains bugs afin de leur donner le même état. Si l'un des bugs listés dans la commande "merge" est déjà fusionné avec un autre bug, tous les rapports sont alors fusionnés. La fusion s'apparente à l'égalité: elle est réflexive, transitive et symétrique. Quand des rapports sont fusionnés, une note apparait dans les logs de chacun des bugs dans les pages web. Les rapports fusionnés expirent en même temps, une fois que tous les rapports ont remplis les critères d'expiration. <tag><tt> unmerge bugnumber</tt> <item> Retire un rapport de bug du groupe de ceux avec qui il aurait pu être fusionné. Si le rapport est fusionné avec plusieurs autres, les liaisons entre ces autres sont gardées, et seule l'association avec le bug spécifié est détruite. Si de nombreux bugs sont fusionnés, et que vous désirez faire deux groupes séparés de bugs fusionnés, vous devez séparer chaque rapport du nouveau groupe, et les fusionner pour faire le nouveau groupe. Vous ne pouvez retirer qu'un rapport par l'utilisation de la commande. Utilisez plusieurs commandes "unmerge" si vous désirez en retirer plusieurs. </taglist> <sect>Résumé des options disponibles <sect1>Synopsis des commandes de `request@bugs.debian.org' <list> <item><tt>send bugnumber</tt> <item><tt>send-detail bugnumber</tt> <item><tt>index [full]</tt> <item><tt>index-summary by-package</tt> <item><tt>index-summary by-number</tt> <item><tt>index-maint</tt> <item><tt>index maint maintainer-substring</tt> <item><tt>send-unmatched [this|0]</tt> <item><tt>send-unmatched last|-1</tt> <item><tt>send-unmatched old|-2</tt> <item><tt>getinfo filename</tt> (see below) <item><tt>help</tt> <item><tt>refcard</tt> <item><tt>quit|stop|thank...|--...</tt> <item><tt>#...</tt> _(comment)_ <item><tt>debug level</tt> </list> <sect1>Liste des fichiers pour `getinfo' <list> <item><tt>maintainers</tt> <item><tt>override.stable</tt> <item><tt>override.development</tt> <item><tt>override.contrib</tt> <item><tt>override.non-free</tt> <item><tt>override.experimental</tt> <item><tt>override.codeword</tt> <item><tt>pseudo-packages.description</tt> <item><tt>pseudo-packages.maintainers</tt> </list> <sect1>Synopsis des commandes supplémentaires du serveur de contrôle <list> <item><tt>close bugnumber</tt> (vous devez expliquer la raison au rapporteur) <item><tt>reassign bugnumber package</tt> <item><tt>reopen bugnumber [originator-address|=]</tt> <item><tt>forwarded bugnumber address</tt> <item><tt>notforwarded bugnumber</tt> <item><tt>retitle bugnumber new-title</tt> <item><tt>merge bugnumber bugnumber ...</tt> <item><tt>unmerge bugnumber</tt> </list> <chapt>Fonctionnalités additionnelles du système de gestion des bugs <sect>Fonctionnalités plus ou moins obsolètes de scan de l'objet Les messages qui arrivent à 'submit' ou 'bugs', et dont le sujet commence par <tt>Bug#nnn</tt> sont traités comme s'ils avaient été envoyés à <tt>nnn@bugs</tt>. Ceci est utilisé pour des questions de compatibilité avec les mails transmis à d'anciennes adresses, et pour attraper les mails transmis envoyés à 'submit' par erreur (en utilisant répondre à tous, par exemple). Il se passe la même chose pour `maintonly,' `done,' `quiet,' et `forwarded,' qui traitent les mails arrivant avec un tag 'Subject' comme envoyé à l'adresse <tt>nnn-foo@bugs</tt> correspondant. Les messages arrivant comme transmis et faits, c'est à dire sans numéro de rapport de bug dans l'adresse ni dans le sujet seront envoyés dans 'junk', et gardés quelques semaines, mais aucun traitement ne sera appliqué. <sect>Projets futurs Il est possible que le champ 'Package' du pseudo-entête devienne obligatoire. Pour l'instant, son omission ne fait qu'afficher un message d'avertissement. <sect>Fonctionnalité obsolète: 'X-Debian-PR' Cette fonctionnalité était utilisée pour empêcher le BTS de faire suivre les messages recus à <tt>debian-bugs</tt>, en mettant un <tt>X-Debian-PR: quiet</tt> dans l'entête du mail. Cet entête est maintenant ignoré. Envoyez votre message à <tt>quiet</tt> ou <tt>nnn-quiet</tt> (ou maintonly ou <tt>nnn-maintonly</tt>). </book>