Salut à tous, Voici les corrections des fichiers que j'ai mis à jour il y a un certain temps déjà. Bugs/Developer.wml Bugs/Reporting.wml Bugs/server-control.wml Bugs/server-refcard.wml Bugs/server-request.wml international/Korean.wml intro/free.wml intro/license_disc.wml mirror/push_server.wml vote/howto_proposal.wml Merci à Nicolas Bertolissio, Sebastien Kalt et Alain Reinhardt pour leurs relectures. Et merci à tous pour les éclaircissements concernant les expressions latines et la GPL. (J'ai laissé « à priori » tel quel et j'ai laissé « Licence publique générale » comme traduction de « General Public License ».) A+, Christian.#use wml::debian::template title="Gestion des bogues Debian - informations pour les développeurs" NOHEADER=yes NOCOPYRIGHT=true #use wml::debian::translation-check translation="1.22" translation_maintainer="Christian Couder
Initialement, un rapport de bogue est soumis par un utilisateur
comme un message ordinaire à submit@bugs.debian.org.
Il lui sera alors donné un numéro, un accusé de réception sera envoyé
à l'utilisateur, et il sera transmis à
debian-bugs-dist. Si celui qui a soumis le rapport a
inclus une ligne
Package indiquant un paquet ayant un mainteneur connu,
le mainteneur recevra aussi une copie.
La ligne Subject se verra rajouter
Bug#nnn:, et le
Reply-To sera modifié pour inclure à la fois celui qui
a soumis le rapport et nnn@bugs.debian.org.
Un développeur qui reçoit un bogue du système de gestion, ou qui le voit sur
debian-bugs-dist, et prend la responsabilité de celui-ci
doit répondre à l'aide de son logiciel de courrier préféré,
et modifier le champ To pour y inscrire
nnn-done@bugs.debian.org à la place de
nnn@bugs
(nnn-close est fourni comme alias pour
nnn-done).
L'adresse de celui qui a soumis le rapport de bogue sera incluse
dans le champ To par défaut, parce que le système de
gestion des bogues l'a inclus dans le Reply-To.
Les messages « Done » sont automatiquement envoyés à la liste
de diffusion debian-bugs-closed uniquement.
Si d'autres développeurs sont susceptibles d'être intéressés il
peut être parfois utile d'inclure la liste de diffusion
debian-devel@lists.debian.org.
La personne fermant le bogue et la personne l'ayant soumis recevront une notification du changement de statut du rapport.
Si un développeur souhaite répondre à un rapport de bogue, il peut
simplement répondre au message (cela ne marquera pas le bogue comme
ayant été traité). Sa réponse ira (par défaut s'il respecte le champ
Reply-To:) à nnn@bugs, et à celui qui a
soumis le rapport de bogue original (note : ce sont deux adresses
distinctes). Le système de gestion des bogues recevra le message à
nnn@bugs, le transmettra au mainteneur du
paquet, enregistrera la réponse avec les autres enregistrements
de ce rapport de bogue et le transmettra à debian-bugs-dist.
Un développeur pourra explicitement envoyer un message à celui qui a soumis
le bogue en envoyant un message à
nnn-submitter@bugs.
Si vous souhaitez envoyer un message de réponse qui n'est pas approprié pour
debian-bugs-dist vous pouvez le faire en l'envoyant à
nnn-quiet@bugs ou
nnn-maintonly@bugs.
Un message envoyé à nnn-quiet@bugs est
enregistré dans le système de gestion des bogues
mais n'est transmis à aucun individu ni aucune liste de diffusion.
Un message envoyé à nnn-maintonly@bugs
est enregistré dans le système de gestion des bogues
et est transmis au mainteneur du paquet en question.
N'utilisez pas les fonctions « répondre à tous les
destinataires » ou « transférer » de votre logiciel de courrier sauf si
vous avez l'intention d'éditer la liste des destinataires de manière
substantielle.
En particulier, vérifiez que vous n'envoyez pas de réponse à
submit@bugs.debian.org.
Le système de bogues enregistre un niveau de gravité avec chaque rapport
de bogue.
Celui-ci est mis à normal par défaut, mais peut être modifié soit
en fournissant une ligne Severity dans le pseudo-en-tête quand le
bogue est soumis (voir
les instructions pour signaler les
bogues), soit en utilisant la commande severity avec le
serveur de requêtes de contrôle.
Les niveaux de gravité sont :
critical (critique)
grave (grave)
serious (sérieux)
important (important)
normal (normal)
minor (mineur)
wishlist (liste de souhaits)
fixed (corrigé)
Chaque bogue peut avoir zéro, un ou plusieurs ensembles de certaines marques. Ces marques sont affichées dans la liste des bogues quand vous regardez la page d'un paquet, et quand vous regardez l'enregistrement complet du bogue.
Les marques peuvent être indiquées en fournissant une ligne
Tags dans le pseudo-en-tête quand le bogue est soumis (voyez les
instructions pour signaler des bogues),
ou en utilisant la commande tags avec le
serveur de requêtes de contrôle.
Les marques disponibles actuellement pour les bogues sont :
patch (patch)
wontfix (ne va pas être résolu)
moreinfo (plus d'info)
unreproducible (non reproductible)
fixed (résolu)
security (sécurité)
potato
woody
sid
Les trois marques qui précèdent sont destinées à être utilisées principalement pour les bogues critiques pour la sortie de la version, pour lesquels il est important de savoir quelles distributions sont affectées afin d'appliquer les corrections (ou les suppressions) au bon endroit.
Quand un développeur envoie un rapport de bogue au développeur du paquet source original depuis lequel le paquet Debian est dérivé, il devrait noter cela dans le système de gestion de la manière suivante :
S'assurer que le champ To de son message à l'auteur
ne comporte que l'adresse du ou des auteurs ; mettre à la fois la personne qui
a rapporté le bogue et
nnn-forwarded@bugs.debian.org dans le champ
CC.
Demander à l'auteur de garder tel quel le CC vers
nnn-forwarded@bugs quand il répond, de
façon à ce que le système de gestion des bogues enregistre sa réponse
avec le rapport original.
Quand le système de gestion des bogues reçoit un message à
nnn-forwarded il marquera le bogue correspondant
comme ayant été transmis à(aux) adresse(s) dans le champ To du
message qu'il reçoit.
Vous pouvez aussi manipuler les informations « forwarded to » en envoyant
des messages à
control@bugs.debian.org.
debian-bugs-reportsChaque vendredi une liste de rapports de bogues non encore corrigés est
postée à debian-bugs-reports, triée par date du rapport.
Chaque mardi une liste de rapports de bogues auxquels il n'a pas été répondu
depuis trop longtemps est postée, triée par mainteneur de paquet.
Si le mainteneur d'un paquet est inscrit de manière incorrecte cela
est généralement dû au fait que le mainteneur a changé récemment, et que le
nouveau mainteneur n'a pas encore soumis une nouvelle version du paquet
avec le champ de contrôle Maintainer modifié. Cela sera
corrigé quand le paquet sera remis à jour ; autrement, les mainteneurs des
archives peuvent écraser à la main les informations concernant le
mainteneur, par exemple si une reconstruction ou une remise à jour du
paquet n'est pas prévue avant un certain temps. Contactez
override-change@debian.org pour les modifications du fichier
d'écrasement (override file).
Il est possible de réassigner des rapports de bogues à d'autres paquets,
de rouvrir des bogues fermés par erreur, de modifier l'information disant
où, s'il y a lieu, un rapport de bogue a été transmis, de changer les
gravités et titres des rapports et de fusionner et de diviser des rapports
de bogue. Ceci se fait en envoyant un message à
control@bugs.debian.org.
Le format de ces messages est
décrit dans un autre document disponible sur la Toile ou dans
le fichier bug-maint-mailcontrol.txt. Une version en texte seul
peut aussi être obtenue en envoyant le mot help au serveur à
l'adresse ci-dessus.
Les messages qui arrivent à submit ou bugs et
dont le champ « Objet » (Subject) commence par
Bug#nnn seront traités comme ayant été envoyés à
nnn@bugs. Ceci pour
assurer la compatibilité ascendante avec les messages envoyés depuis les
anciennes adresses, et pour récupérer les réponses envoyées à
submit par erreur (par exemple, en utilisant la commande
« répondre à tous les destinataires »).
Un schéma identique opère pour maintonly,
done, quiet et forwarded,
qui traite les messages arrivant avec un tel Objet comme ayant été
envoyés à l'adresse correspondante
nnn-XXXXXX@bugs.
Les messages arrivant à forwarded et
done sans identificateur - i.e., sans numéro de rapport
de bogue dans l'adresse - et sans numéro de bogue dans l'Objet seront
enregistrés sous « junk » et gardés pendant quelques semaines, mais
à part cela ignorés.
X-Debian-PR: quietIl était possible d'empêcher le système de gestion des bogues de
transmettre les messages qu'il recevait à debian-bugs,
en mettant une ligne X-Debian-PR: quiet dans l'en-tête
du message.
Cette ligne d'en-tête est maintenant ignorée. À la place, envoyez votre
message à quiet ou nnn-quiet (ou
maintonly ou nnn-maintonly).
Envoyez un message à
submit@bugs.debian.org, comme décrit ci-dessous.
S'il vous plaît, ne signalez pas plusieurs bogues qui n'ont pas de liens
entre eux - en particulier s'ils sont dans des paquets différents - dans un
même message.
Merci aussi de n'envoyer votre message de rapport de bogue
à aucune liste de diffusion ou aucun destinataire autre que
submit@bugs (pour les détails sur la manière de le faire
correctement, voyez ci-dessous).
Les listes des bogues non encore résolus sont disponibles sur la Toile et ailleurs - voyez les autres documents pour plus de détails.
Vous devez mettre en pseudo-en-tête au début du corps du message,
en utilisant les lignes Package: et Version:
qui donnent le nom et la version du paquet ayant le bogue.
(Les champs du pseudo-en-tête devraient commencer au tout début de leur ligne.
Actuellement, le système de gestion des bogues ne comprend pas les
messages MIME ou PGP, et peut échouer à reconnaître les pseudo-en-têtes
dans de tels messages.)
(Vous pouvez obtenir cela en utilisant
dpkg --search et dpkg --list ; voyez
dpkg --help.
Voyez ci-dessous les exigences supplémentaires.
Il y a des pseudo-paquets disponibles pour remplir la ligne
Package quand on signale un bogue dans autre chose qu'un paquet
logiciel Debian.
Il y a une liste de ceux-ci sur les
pages web concernant les bogues.
Note du traducteur : La langue des rapports de bogue est l'anglais, afin que ceux-ci puissent être compris par le maximum de développeurs. Aucune traduction des rapports de bogue n'a été mise en place pour l'instant.
Un rapport de bogue, avec un en-tête de message, ressemble à quelque chose comme ceci :
To: submit@bugs.debian.org From: diligent@testing.linux.org Subject: Hello says `goodbye' Package: hello Version: 1.3-16 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 GNU/Linux 2.2, kernel 2.2.17-pre-patch-13 and libc6 2.1.3-10.
Note du traducteur : Pour information, une traduction de ce message serait :
A: submit@bugs.debian.org De: diligent@testing.linux.org Objet: Hello affiche « goodbye » Package: hello Version: 1.3-2 Quand je lance « hello » sans arguments depuis un shell ordinaire cela affiche « goodbye », plutôt que le « hello, world » attendu. Voici une transcription : $ hello goodbye $ /usr/bin/hello goodbye $ Je suggère que la chaîne de caractère en sortie, dans hello.c, soit corrigée. J'utilise Debian 1.1, noyau version 1.3.99.15z et libc 5.2.18.3.2.1.3-beta.
uname -a),
votre librairie C partagée (tapez ls -l /lib/libc.so.6 ou
dpkg -s libc6 | grep ^Version),
et tout autre détail à propos de votre système Debian, si cela semble
approprié. Par exemple si vous avez eu un problème avec un script Perl,
vous pourriez fournir la version du binaire « perl »
(tapez perl -v ou
dpkg -s perl-5.005 | grep ^Version:)
Incluez tout détail qui semble lié - il y a très peu de risque de rendre votre rapport trop long en incluant trop d'informations. S'ils sont petits, merci d'inclure dans votre rapport tout fichier que vous avez utilisé pour reproduire le problème (en les uuencodant s'ils peuvent contenir des caractères spéciaux).
Bien sûr, comme pour tout message, vous devriez mettre une ligne
Objet (Subject en anglais) claire, descriptive dans
votre en-tête de message.
L'objet que vous donnez sera utilisé comme le titre initial du bogue dans le
système de gestion, aussi merci d'essayer d'être informatifs !
Il est parfois nécessaire d'envoyer une copie d'un rapport de bogue ailleurs
qu'à debian-bugs-dist et au mainteneur du paquet,
où le rapport est normalement envoyé.
Vous pourriez faire cela en utilisant les autres adresses dans le champs
Copies-A (CC en anglais) de votre logiciel de
messagerie, mais alors les autres copies n'auraient pas de numéro de rapport
de bogue mis dans le champ Répondre-A (Reply-To
en anglais) et dans la ligne Objet (Subject en
anglais). Quand les destinataires répondront ils garderont probablement
l'entrée submit@bugs.debian.org dans l'en-tête et verront leur
message enregistré comme un nouveau rapport de bogue. Cela engendre beaucoup
de rapports dupliqués.
La bonne manière de procéder est d'utiliser l'en-tête
X-Debbugs-CC. Ajoutez une ligne comme celle ci à votre en-tête
de message (pas au pseudo-en-tête contenant le champs
Package) :
X-Debbugs-CC: autre-liste@cosmic.eduCela fera envoyer par le système de gestion des bogues une copie de votre rapport à l'adresse (aux adresses) de la ligne
X-Debbugs-CC
aussi bien qu'à debian-bugs-dist.
Cette fonctionnalité peut souvent être utilement combinée avec le code de
message quiet - voyez ci-dessous.
Si un rapport concerne un bogue particulièrement grave, ou si c'est plutôt une demande de fonctionnalité, vous pouvez indiquer un niveau de gravité pour le bogue lorsque vous le signalez. Ce n'est cependant pas indispensable et les développeurs assigneront un niveau de gravité approprié à votre rapport si vous ne le faites pas.
Pour indiquer un niveau de gravité mettez une ligne
Severity: sévérité dans le pseudo-en-tête,
avec les lignes Package et Version. Les
niveaux de gravité disponibles sont décrits dans la
documentation des développeurs.
Si un rapport de bogue est mineur (par exemple, une typo dans la
documentation ou tout autre problème trivial de compilation), ou si vous
envoyez plusieurs rapports en une seule fois, envoyez-les à
maintonly@bugs ou quiet@bugs.
maintonly enverra le rapport au mainteneur de paquet
(pourvu que vous ayez fourni une ligne Package correcte
dans le pseudo-en-tête et que le mainteneur soit connu), et quiet
ne le transmettra nulle part mais l'enregistrera seulement comme un bogue
(utile si, par exemple, vous envoyez beaucoup de bogues similaires et si vous
voulez poster seulement un résumé).
Si vous faites cela, le système de gestion des bogues remplira le champ
Répondre-A (Reply-To) de tout message transmis
de façon à ce que les réponses soient par défaut traitées de la même manière
que le rapport original.
Si le système de gestion des bogues ne peut trouver qui est le mainteneur du paquet
concerné il enverra le rapport à
debian-bugs-dist même si le code maintonly a été utilisé.
Quand vous envoyez un message à maintonly@bugs ou
nnn-maintonly@bugs vous devriez vérifier que
le rapport de bogue est assigné au bon paquet, en remplissant correctement le
champ Package en haut de la soumission originale d'un rapport,
ou en utilisant le service
control@bugs pour tout d'abord (ré)assigner correctement le
rapport si ce n'est pas déjà correct.
dpkg pour trouver le paquet et la version pour le
rapportSi vous signalez un bogue dans une commande, vous pouvez déterminer quel
paquet l'a installée en utilisant dpkg --search. Vous pouvez
trouver la version d'un paquet que vous avez installé en utilisant
dpkg --list ou dpkg --status.
Par exemple :
$ which apt-get /usr/bin/apt-get $ type apt-get apt-get is /usr/bin/apt-get $ dpkg --search /usr/bin/apt-get apt: /usr/bin/apt-get $ dpkg --list apt Desired=Unknown/Install/Remove/Purge/Hold | 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 apt 0.3.19 Advanced front-end for dpkg $ dpkg --status apt Package: apt Status: install ok installed Priority: standard Section: base Installed-Size: 1391 Maintainer: APT Development Team <deity@lists.debian.org> Version: 0.3.19 Replaces: deity, libapt-pkg-doc (<< 0.3.7), libapt-pkg-dev (<< 0.3.7) Provides: libapt-pkg2.7 Depends: libapt-pkg2.7, libc6 (>= 2.1.2), libstdc++2.10 Suggests: dpkg-dev Conflicts: deity Description: Advanced front-end for dpkg This is Debian's next generation front-end for the dpkg package manager. It provides the apt-get utility and APT dselect method that provides a simpler, safer way to install and upgrade packages. . APT features complete installation ordering, multiple source capability and several other unique features, see the Users Guide in /usr/doc/apt/guide.text.gz#use "otherpages.inc" #use "footer.inc" #use wml::debian::template title="Gestion des bogues Debian - serveur de contrôle" NOHEADER=yes NOCOPYRIGHT=true #use wml::debian::translation-check translation="1.16" translation_maintainer="Christian Couder
En plus du serveur de messages à request@bugs.debian.org
qui permet de récupérer les données et la documentation des bogues par
courrier électronique, il y a un autre serveur à
control@bugs.debian.org
qui permet aussi de manipuler des rapports de bogue de différentes façons.
Le serveur de contrôle fonctionne simplement comme le serveur de requêtes, excepté qu'il dispose de commandes supplémentaires ; en fait, c'est le même programme. Les deux adresses sont simplement distinctes pour éviter aux utilisateurs de faire des erreurs et de causer des problèmes en essayant juste de récupérer des informations.
Merci de lire au préalable
l'introduction au serveur de requêtes
disponible sur la Toile, dans le fichier
bug-log-mailserver.txt, ou en envoyant
help à l'un des serveurs de messages, pour connaître les détails
de l'utilisation de base de ces serveurs et les commandes usuelles disponibles
lors de l'envoi de message à ces adresses.
La carte de référence pour les serveurs de messages
est disponible sur la Toile, à
bug-mailserver-refcard.txt ou par courrier électronique en utilisant
la commande refcard).
close NuméroDeBogue
Ferme le rapport de bogue #NuméroDeBogue.
Une notification est envoyée à l'utilisateur qui a signalé le bogue, mais (contrairement à l'envoi à NuméroDeBogue-done@bugs) le
texte du message qui a servi à fermer le bogue n'est pas
inclus dans cette notification. Le mainteneur qui ferme un rapport
devrait s'assurer, probablement en envoyant un message séparément, que
l'utilisateur qui a signalé le bogue sait pourquoi le rapport est fermé.
reassign NuméroDeBogue Paquet
Enregistre le fait que le bogue #NuméroDeBogue est un bogue dans Paquet.
Cela peut être utilisé pour indiquer le paquet si l'utilisateur a oublié le pseudo-en-tête, ou de changer un assignement préalable. Aucune notification n'est envoyée à quiconque (autre que l'information habituelle lors de la transcription en cours).
reopen NuméroDeBogue
[ AdresseDOrigine | = | ! ]
Rouvre #NuméroDeBogue s'il a été fermé.
Par défaut, ou si vous spécifiez =, celui qui a soumis
initialement le rapport reste l'origine du rapport, de façon à ce qu'il
reçoive une confirmation quand il sera de nouveau refermé.
Si vous fournissez une AdresseDOrigine l'origine sera
l'adresse que vous fournissez. Si vous souhaitez devenir la nouvelle
origine du rapport rouvert vous pouvez utiliser le raccourcis
! ou spécifier votre propre adresse.
C'est habituellement une bonne idée de dire à la personne qui va être enregistrée comme l'origine du rapport que vous le rouvrez, de façon à ce qu'elle s'attende à la confirmation qu'elle recevra quand il sera de nouveau fermé.
Si le bogue n'est pas fermé alors « reopen » ne fera rien, même pas changer l'origine du bogue. Il n'y a pas de moyen de changer l'origine d'un rapport de bogue ouvert (c'est un choix délibéré, de façon à ne pas avoir un bogue fermé et ensuite détruit 28 jours plus tard sans que quelqu'un n'en soit averti).
forwarded NuméroDeBogue Adresse
Enregistre le fait que NuméroDeBogue a été transmis au mainteneur original à Adresse. Cela ne transmet pas en réalité le rapport. Cela peut être utilisé pour changer une adresse « forwarded-to » existante incorrecte, ou pour en enregistrer une nouvelle pour un bogue qui n'a pas été signalé auparavant comme ayant été transmis.
notforwarded NuméroDeBogue
Oublie toute idée que le bogue NuméroDeBogue ait pu être envoyé à un mainteneur original. Si le bogue n'a pas été enregistré comme ayant été transmis alors cela ne fera rien.
retitle NuméroDeBogue NouveauTitre
Remplace le titre d'un rapport de bogue par celui qui est spécifié (le titre
par défaut est l'Objet en en-tête du message du rapport original.
Au contraire de la plupart des autres commandes de manipulation des bogues, quand celle-ci est utilisée sur un rapport faisant partie d'un ensemble de rapports fusionnés, cela changera le titre uniquement du rapport du bogue en question, et non pas de tous ceux avec lesquels il est fusionné.
severity NuméroDeBogue Sévérité
Le niveau de sévérité du rapport de bogue #NuméroDeBogue est mis à Sévérité. Aucune notification n'est envoyée à l'utilisateur qui a signalé le bogue.
Les niveaux de sévérité sont
critical (critique), grave (grave),
serious (sérieux), important (important),
normal (normal), minor (mineur),
et wishlist (souhaitable).
Pour leur signification merci de consulter la documentation générale des développeurs concernant le système de gestion des bogues.
merge NuméroDeBogue NuméroDeBogue ...
Fusionne plusieurs rapports de bogues. Une fois les rapports fusionnés, l'ouverture, la fermeture, le marquage ou le démarquage comme ayant été envoyé et la réassignation de n'importe lequel des bogues à un nouveau paquet auront un effet identique sur tous les rapports fusionnés.
Avant que les bogues puissent être fusionnés, ils doivent être exactement
dans le même état : tous ouverts ou tous fermés, avec la même adresse de
l'auteur original dans le champs « forwarded-to » ou alors aucun n'ayant été
marqué comme ayant été envoyé, tous assignés au(x) même(s) paquet(s) (une
comparaison exacte de chaîne de caractère est faite sur le paquet auquel le
bogue est assigné), et tous de la même gravité.
S'ils ne sont pas tous dans le même état au début vous devriez utiliser
reassign, reopen
et ainsi de suite pour être sûr qu'ils le sont avant d'utiliser
merge.
Si des bogues contenus dans une commande merge sont déjà
fusionnés avec d'autre bogues alors tous les rapports fusionnés avec l'un
de ceux de la commande seront aussi fusionnés. Les fusions sont comme les
égalités : elles sont réflexives, transitives and symétriques.
La fusion de rapports entraîne l'apparition d'une note sur chacun des enregistrement du rapport ; sur les pages web cela contient des liens vers les autres bogues.
Les rapports fusionnés expirent tous simultanément, et seulement quand chacun des rapport pris séparément à atteint le critère d'expiration.
unmerge NuméroDeBogue
Déconnecte un rapport de bogue de n'importe quel autre rapport avec lequel il a pu être fusionné. Si le rapport en question est fusionné avec plusieurs autres alors les autres sont tous laissés comme étant fusionnés ensemble ; seulement leurs associations avec le bogue explicitement désigné sont retirées.
Si beaucoup de rapports de bogues sont fusionnés et si vous désirez les diviser en deux groupes séparés de rapports fusionnés, vous devez déconnecter chaque rapport de l'un des nouveaux groupes séparément et ensuite les fusionner dans le nouveau groupe.
Vous ne pouvez déconnecter qu'un seul rapport par commande
unmerge ; si vous voulez déconnecter plus d'un seul rapport
incluez simplement plusieurs commandes unmerge dans votre
message.
tags NuméroDeBogue [ + | - | = ] Marque
+ signifie ajouter la marque,
- signifie supprimer la marque, et
= signifie ignorer les marques courantes et les mettre en
repartant de zero.
L'action par défaut est l'ajout. Un espace est nécessaire entre le
caractère +/-/= et le nom de la marque.
Les marques courantes sont
patch (patch),
wontfix (ne sera pas résolu),
moreinfo (plus d'info),
unreproducible (non reproductible),
fixed (résolu),
security (sécurité),
potato (potato),
woody (woody) et
sid (sid).
Pour leur signification merci de consulter la documentation des dévelopeurs sur le système de gestion des bogues.
La documentation complète des serveurs de message est disponible sur
la Toile, dans les fichiers
bug-log-mailserver.txt et
bug-maint-mailcontrol.txt ou en
envoyant le mot help à chaque serveur de message.
request@bugs.debian.orgsend NuméroDeBogue
send-detail NuméroDeBogue
index [full]
index-summary by-package
index-summary by-number
index-maint
index maint SousChaineDeMainteneur
index-packages
index packages SousChaineDePaquet
send-unmatched [this|0]
send-unmatched last|-1
send-unmatched old|-2
getinfo NomDeFichier (ftp.debian.org/debian/doc/*)
help
refcard
quit|stop|thank...|--...
#... (commentaire)
debug Niveau
close NuméroDeBogue
(vous devez par ailleurs dire à la personne ayant signalé le bogue
pourquoi vous le fermez)
reassign NuméroDeBogue Paquet
severity NuméroDeBogue Gravité
reopen NuméroDeBogue
[ AdresseDOrigine | = | ! ]
forwarded NuméroDeBogue Adresse
notforwarded NuméroDeBogue
retitle NuméroDeBogue NouveauTitre
merge NuméroDeBogue NuméroDeBogue ...
unmerge NuméroDeBogue
tags NuméroDeBogue
[ + | - | = ] Marque
reopen avec = ou sans adresse d'origine laisse
l'origine du rapport de bogue telle qu'elle ; ! la modifie et
met votre adresse à la place, du moins celle de la personne faisant la
réouverture.
Les gravités possibles sont
critical (critique),
grave (grave),
serious (sérieuse),
important (importante),
normal (normale),
minor (mineure), et
wishlist (souhait).
Les marques actuellement possibles sont
patch (rustine),
wontfix (ne sera pas résolu),
moreinfo (plus d'info),
unreproducible (non reproductible),
fixed (résolu),
security (sécurité),
potato (potato),
woody (woody) et
sid (sid).
Il y a un serveur de message qui peut envoyer des rapports de bogues et des index en texte seul à la demande.
Pour l'utiliser il faut envoyer un message à
request@bugs.debian.org.
L'Objet (Subject en anglais) du message est ignoré, sauf pour
générer l'Objet de la réponse.
Le corps du message que vous envoyez doit être une série de commandes, une par ligne. Vous recevrez une réponse qui ressemblera à une transcription de votre message ayant été interprété, avec une réponse pour chaque commande. Aucune notification n'est envoyée à personne pour la plupart des commandes ; cependant, les messages sont enregistrés et rendus disponibles sur les pages web.
Tout texte d'une ligne commençant par un caractère dièse # est
ignorée ; le serveur arrête de traiter un message lorsqu'il trouve une ligne
commençant par quit, stop, thank ou
deux traits d'union (pour éviter de traiter une signature). Il arrêtera
aussi s'il rencontre trop de commandes inconnues ou mal formatées.
Si aucune commande n'est traitée avec succès il enverra le texte d'aide
du serveur.
send NuméroDeBogue
send-detail NuméroDeBogue
send-detail envoie tous les messages « ennuyeux » de la
transcription, comme les diverses auto-confirmations (vous devriez
généralement utiliser la commande send en même temps,
car les messages intéressants ne sont pas envoyés par
send-detail).
index [full]
index-summary by-package
index-summary by-number
index-maint
index maint Mainteneur
index-packages
index packages Paquet
send-unmatched [this|0]
send-unmatched last|-1
send-unmatched old|-2
getinfo NomDeFichier
maintainers
Packages,
les fichiers « override » et les fichiers de pseudo-paquets.
override.Distribution
override.Distribution.non-free
override.Distribution.contrib
override.experimental
Packages dans l'archive
FTP. Ces informations sont disponibles pour chacun des principaux arbres
disponibles de la distribution à partir de leur nom de code.
pseudo-packages.description
pseudo-packages.maintainers
refcard
help
quit
stop
thank...
--...
#, par
exemple pour le plus grand bénéfice des lecteurs humains de votre message
(qui le lisent depuis les enregistrements du système de gestion ou à cause
d'un Copies-A (« CC » en anglais) ou d'un
Copies-Cachées-A (« BCC » en anglais).
#...
# doit être au début de la ligne.
debug Niveau
Il y a une carte de référence du serveur de
message, disponible sur la Toile, dans
bug-mailserver-refcard.txt ou par courrier électronique en
utilisant la commande refcard (voyez plus haut).
Si vous souhaitez manipuler les rapports de bogue vous devriez utiliser
l'adresse control@bugs.debian.org, qui comprend un
sur-ensemble des commandes listées plus
haut. Cet ensemble de commandes est décrit dans un autre document,
disponible sur la Toile, dans le fichier
bug-maint-mailcontrol.txt,
ou en envoyant la commande help à
control@bugs.
Au cas où vous lisiez ceci dans un fichier en texte seul ou dans un
message :
une version HTML est disponible à partir de la page principale du système de
gestion des bogues http://www.debian.org/Bugs/.
Note : En février 1998, un groupe a décidé de remplacer le terme « logiciel libre » (Free Software) par « logiciel ouvert » (Open Source Software). Comme cela apparaîtra clairement dans la suite, ces termes font tous les deux référence à la même chose ou presque.
Beaucoup de néophytes des logiciels libres sont embrouillés car en anglais le mot « free » dans l'_expression_ « free software » (logiciel libre) a une autre signification, qui n'est pas celle qu'ils attendent. Pour eux, « free » signifie gratuit. Un dictionnaire anglais propose presque un vingtaine de sens au mot « free ». Un seul signifie gratuit. Les autres font référence à la liberté et à l'absence de contraintes. Lorsque l'on parle de Free Software ou de logiciel libre, nous parlons de liberté et non de prix.
NdT : En français, la traduction limite la confusion, mais elle existe dans les documents en anglais.
Un logiciel gratuit est rarement complètement libre. Il se peut qu'il soit interdit de le donner à quelqu'un et vous ne pouvez vraisemblablement pas l'améliorer. Les logiciels distribués gratuitement sont en général une arme dans une campagne marketing, pour promouvoir un produit apparenté, ou pour mener un concurrent plus petit à la faillite. Il n'y a aucune garantie que ce logiciel reste gratuit.
Les véritables logiciels libres demeurent toujours libres. Un logiciel placé dans le domaine public peut être récupéré et transformé en un logiciel non-libre. Toutes les améliorations faites alors sont perdues pour la société. Pour rester libres, les logiciels doivent posséder un copyright et une licence.
Pour les non-initiés, un logiciel est libre ou ne l'est pas. La réalité est bien plus complexe. Pour comprendre ce que les gens entendent lorsqu'ils qualifient un logiciel de libre, nous devons faire un petit détour vers les licences des logiciels.
Le copyright est une méthode pour protéger les droits du créateur de certains types d'oeuvre. Dans la plupart des pays, les logiciels que vous écrivez acquièrent automatiquement un copyright. Une licence est un moyen d'autoriser l'utilisation d'une création (le logiciel dans ce cas) par d'autres personnes, dans les conditions acceptables par l'auteur. C'est à lui d'ajouter une licence qui indique de quelles façons, le logiciel peut être utilisé. Pour une discussion précise (en anglais) sur le copyright, regardez http://lcweb.loc.gov/copyright/.
Bien sûr des circonstances différentes entraînent des licences différentes. Les sociétés de logiciels cherchent à protéger leurs intérêts, aussi elles ne publient que le code compilé (qui n'est pas humainement lisible) et imposent beaucoup de restrictions sur l'utilisation du logiciel. D'un autre côté, les auteurs de logiciels libres cherchent une combinaison des propriétés suivantes :
De nombreuses personnes écrivent leur propre licence. Ceci est déconseillé, car écrire une licence correspondant à vos souhaits engendre des difficultés subtiles. Trop souvent les termes utilisés sont ambigus ou les conditions sont contradictoires. Écrire une licence juridiquement valide est encore plus difficile. Heureusement, de nombreuses licences déjà écrites répondent à vos besoins.
Trois des licences les plus répandues dans le monde sont :
Quelques unes des caractéristiques que ces licences ont en commun.
Ce dernier point, qui autorise la vente des logiciels semble aller contre l'idée générale des logiciels libres. C'est en fait, l'une de ses forces. Puisque les licences permettent une redistribution libre, une fois qu'une personne a récupéré une copie, elle peut la distribuer elle-même. Elle peut même essayer de la vendre. En pratique il ne coûte quasiment rien de faire des copies électroniques de logiciel. La règle de l'offre et la demande va maintenir des prix peu élevés. S'il est pratique pour un gros logiciel ou pour un ensemble de logiciels d'être distribués sur des supports, comme des CD-ROM, les vendeurs sont libres de faire payer ce qu'ils veulent. Cependant, si la marge de profit est trop importante, de nouveaux vendeurs apparaitront sur le marché et la concurrence entrainera une baisse des prix. En conséquence, vous pouvez acheter une distribution complète de Debian sur 3 CD-ROM pour seulement 6$ (45 francs français).
Bien que les logiciels libres ne soient pas complètement libres de contraintes (seule la mise dans le domaine public libère de toutes les contraintes), ils laissent à l'utilisateur la flexibilité de faire ce dont il a besoin pour accomplir son travail. En même temps, il protège les droits de l'auteur. C'est cela la liberté.
Debian GNU/Linux est un chaud partisan des logiciels libres. Et puisque plusieurs licences sont utilisées pour les logiciels, un ensemble de lignes directrices, les Directives Debian pour le logiciel libre (Debian Free Software Guidelines ou DFSG) ont été développées pour arriver à une définition correcte de ce qui constitue les logiciels libres. Seuls les logiciels qui obéissent aux règles du DFSG sont autorisés à figurer dans la distribution principale (main) de la Debian.
#use wml::debian::template title="Comparaison des Licences de logiciel" #use wml::debian::translation-check translation="1.10" translation_maintainer="Christian Couder <chcouder@club-internet.fr>" <P><STRONG>******Ce document est en cours de développement*******</STRONG> <P>Les gens qui évoluent autour du Logiciel ouvert ont tendance à développer une opinion très forte au sujet des licences. Les débutants ne s'en soucient guère tant qu'ils sont plus concernés par la fin du travail en cours et ne comprennent pas les implications à long terme du choix pour un logiciel d'une licence plutôt qu'une autre (il est douteux de penser qu'il y ait beaucoup de gens qui comprennent les nuances des licences et n'aient pas d'opinions fortes sur le sujet). <P>Au cours des années un certain nombre de licences ont gagné de l'importance en donnant aux auteurs de logiciels le type de contrôle sur leurs créations que la plupart d'entre eux désiraient. Il est encore courant de trouver du logiciel qui n'a pas de copyright visible ou qui contient une unique licence développée par son auteur. Ce dernier cas peut être assez ennuyeux pour les distributeurs de logiciel (à la fois en ligne et ceux créant des CD) car beaucoup de ces licences contiennent des <A HREF="#mistakes">erreurs courantes</A> qui rendent le logiciel difficile à distribuer. <P>Ce qui suit est une liste des licences les plus courantes de Logiciel libre (ouvert) et pour chacune quelques uns de leurs bons et mauvais côtés. Seuls les points de la licence intéressants pour la discussion sont donnés. De plus, beaucoup de points sont placés sous le simple titre « BON/MAUVAIS ». Ce sont des points qui peuvent être bons ou mauvais, selon le point de vue duquel on se trouve. <UL> <LI>La <A HREF="http://www.gnu.org/";>GNU General Public License (GPL)</A> (Licence publique générale GNU). <BR> <B>RÉSUMÉ :</B> Le code source doit être rendu disponible ; le logiciel peut être vendu ; les travaux dérivés doivent utiliser la même licence. <BR> <B>BON :</B> Il y a de bonnes raisons pour lesquelles c'est la licence la plus utilisée pour le Logiciel libre (ouvert). Elle permet une bonne protection des droits des développeurs de logiciel et la disponibilité du code source garantit que les utilisateurs n'auront pas à se soucier de perdre le support dans le futur. <BR> <B>BON/MAUVAIS :</B> Le logiciel distribué en utilisant la GPL ne peut être incorporé dans du logiciel propriétaire. La question de savoir si c'est en fait une bonne chose dépend de votre point de vue. Les gens qui développent du logiciel propriétaire se sentent souvent frustrés quand il y a une solution disponible qui ne peut être utilisée à cause de conflits de licences. Bien sûr, rien ne les empêche de contacter l'auteur et de voir s'ils peuvent acheter une version utilisant une licence différente. La plupart des gens qui distribuent du logiciel avec la GPL ne considèrent pas ces restrictions comme mauvaises, parce que cela permet aux autres d'utiliser et d'améliorer le logiciel alors que cela empêche (en pratique) les autres de se faire de l'argent à partir de leur dur travail sans leur permission. <LI>La Licence artistique <A HREF="http://language.perl.com/misc/Artistic.html";>http://language.perl.com/misc/Artistic.html</A>. <BR> <B>RÉSUMÉ :</B> <BR> <B>BON :</B> <BR> <B>MAUVAIS :</B> <LI><A HREF="../misc/bsd.license">Les licences de type BSD</A>. <BR> <B>RÉSUMÉ :</B> Les binaires et le code source doivent contenir la licence ; la publicité doit reconnaître le travail des développeurs inscrits sur la licence. <BR> <B>BON/MAUVAIS :</B> Les entreprises qui veulent qu'un exécutable soit largement disponible (éventuellement gratuitement) sans publier le code source utilisent souvent cette licence. Un bon exemple est une entreprise qui veut distribuer un pilote de carte graphique. Les avocats du logiciel « Open Source » préféreraient de toute façon que l'entreprise distribue les spécifications matérielles. Si le développement des pilotes pour XFree86 peut donner une indication, c'est que les meilleurs pilotes sont ceux écrit avec le code source disponible. Les entreprises n'arrivent qu'à faire apparaître comme mauvais leurs produits en distribuant des pilotes propriétaires qui sont lents et bogués. Elles peuvent aussi gagner sur les coûts de développement en laissant les autres développer les pilotes pour eux. <BR> <B>BON/MAUVAIS :</B> N'importe qui peut récupérer le source, le modifier, et distribuer le résultat sans rendre public les changements. Trouver cela bon ou mauvais est une question de préférence personnelle. </UL> <HR> <P><A NAME="mistakes">Quelques erreurs fréquentes dans les licences écrites soi-même</A> : <UL> <LI>Soit ne pas permettre, ou restreindre les ventes du logiciel à but lucratif. Cela rend difficile la distribution du logiciel sur CD. Les gens font souvent l'erreur d'utiliser des termes qui ne sont pas bien définis, comme un « coût raisonnable ». Il vaut mieux simplement utiliser une des licences mentionnées ci-dessus car elles reviennent au même sans avoir recours à de telles phrases. Par exemple, en permettant à n'importe qui de distribuer le logiciel, la GPL maintient les prix suffisamment bas grâce aux forces naturelles du marché. Si quelqu'un vend un CD avec une grosse marge il ne faudra pas attendre longtemps avant que des concurrents n'entrent sur le marché et le vendent à un prix plus bas. <BR>Note : la Licence Artistique utilise le terme « Cachet raisonnable pour la copie », mais elle définit ce terme pour essayer de le rendre moins vague. <LI>Ne pas permettre la distribution de versions modifiées du logiciel. Cela empêche la distribution du logiciel par certains groupes. Par exemple, depuis que Debian distribue des logiciels compilés, il est souvent nécessaire de modifier le code source pour le compiler ou pour le rendre compatible avec la <A HREF="ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/";>FSSTND</A>. Mais en faisant cela, nous n'avons alors pas le droit de le distribuer. <LI>Obliger à ce que tous les changements soient rapportés à l'auteur. Bien que ce soit une bonne idée de rapporter à l'auteur les modifications/améliorations afin qu'elles puissent être plus largement distribuées, l'obliger peut entraîner des problèmes. Combien de personnes savent où elles seront dans 5 ans ? Modifiez cela en « Les modifications au logiciel devraient être rapportées à l'auteur ». La plupart des gens le feront. <BR>Cette clause est habituellement inclue pour empêcher que des projets sous-branche se développent. L'histoire a montré que, tant que le développement sur le code original ne s'interrompt pas, les sous-branches n'auront du succès que si une autre force motive la séparation. <LI>Déclarer que le logiciel est dans le domaine public, mais ensuite ajouter des contraintes (comme le fait de ne pas autoriser la vente à but lucratif). Soit une chose est dans le domaine public soit elle ne l'est pas - il n'y a pas de milieu. De telles licences n'ont aucun sens et il est probable que les conditions supplémentaires ne tiendront pas devant un tribunal. </UL>#use wml::debian::template title="Mettre en place un serveur « Push »" #use wml::debian::translation-check translation="1.9" translation_maintainer="Christian Couder
Mettre en place un serveur « Push » se résume à effectuer deux tâches relativement simples : mettre en place un accès rsync (comme pour faire un miroir « Pull » standard) et mettre en place un mécanisme déclencheur utilisant ssh (pour déclencher la mise à jour du miroir « Pull »).
(Pour plus d'information sur ce qu'est un serveur « Push », merci de lire l'explication des miroirs « Push ».)
Installez rsync 2.1.1 ou une version supérieure. Si votre
site tourne sous Debian, installez simplement le dernier paquet
rsync.
Créez un fichier rsyncd.conf et mettez quelque chose comme
ceci dans celui-ci :
uid = nobody gid = nogroup max connections = 25 syslog facility = daemon socket options = SO_KEEPALIVE [debian] path = /org/ftp.debian.org/ftp comment = Archive FTP Debian (~24 Go) auth users = compte_authorise1,compte_authorise2,compte_authoriseN read _only_ = true secrets file = /etc/rsyncd/debian.secrets [debian-web] path = /org/www.debian.org/debian.org comment = Site Web Debian (~400 Mo) auth users = compte_authorise1,compte_authorise2,compte_authoriseN read _only_ = true secrets file = /etc/rsyncd/debian.secrets
Pour chaque site dont vous faite un miroir « Push », ajoutez une entrée
au fichier /etc/rsyncd/debian.secrets :
compte_authorise1:un_mot_de_passe compte_authorise2:autre_mot_de_passe compte_authoriseN:_mot_de_passe
Vous avez alors donné accès à l'archive se trouvant sur votre machine aux miroirs clients de votre machine.
Vous voudrez probablement lancer le démon rsync depuis inetd. Pour cela,
vous devez d'abord ajouter le service rsync dans le fichier
/etc/services (s'il n'y est pas déjà), comme ceci :
rsync 873/tcpPour lancer le démon avec inetd, ajoutez ce qui suit à votre fichier
/etc/inetd.conf :
rsync stream tcp nowait root /usr/bin/rsync rsyncd --daemon(N'oubliez pas d'envoyer à inetd un signal HUP pour lui dire de relire son fichier de configuration après que vous l'avez modifié.)
Créez une nouvelle clé ssh pour le compte que vous utilisez pour faire un miroir de Debian. Faites attention à ne pas écraser votre clé ssh originale et pour cela utilisez l'option -f, par exemple :
ssh-keygen -f ~/.ssh/identite.monsite
Vérifiez que la nouvelle clé publique (~/.ssh/identite.monsite.pub) contient ceci au début du fichier :
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="~/websync &"
(remplacez « websync » par « ftpsync » ou « ftpsync-non-US » ou encore autre chose suivant le nom de la commande que vous utilisez pour lancer le processus de miroir)
Vous devez aussi mettre en place le script qui contactera les miroirs
clients.
Créez un fichier nommé signal, contenant ceci :
#!/bin/sh
# Ce script est appelé pour signaler à l'hôte distant qu'il est temps de
# mettre à jour le miroir à partir de l'archive.
echo Signalling $1
ssh -o"BatchMode yes" -o"user $2" "$1" -i $HOME/.ssh/identite.monsite sleep 1
Ce script va se loguer sur un hôte distant en utilisant la clé ssh spéciale que vous avez créée ci-dessus. Ce script lui-même ne fera rien d'utile sur l'hôte distant, la commande ~/websync (ou ~/ftpsync, ou ~/ftpsync-non-US) sera lancée à partir de la clé.
Pour déclencher effectivement les miroirs, vous devez ajouter des
lignes du type
./signal <site> <nom_utilisateur> soit à la
fin du script websync, soit si c'est plus simple pour vous,
dans un nouveau script, et ensuite lancer ce script depuis
websync.
Ce nouveau script, runmirrors, devrait contenir quelque
chose comme ceci :
#!/bin/sh
# Ce script est appellé par websync pour déclencher les miroirs clients.
./signal un.autre.site archvsync
./signal et.un.autre.site autrecompte
De cette façon, dès que votre site a terminé de mettre à jour son miroir à partir de son serveur, vous allez déclencher la mise à jour des sites clients de votre serveur.
Si vous avez le moindre problème avec ceci,
contactez-nous.#use wml::debian::basic title="Votes Debian - Soumettre une proposition" BARETITLE="true"
#use wml::debian::votebar
#use wml::debian::translation-check translation="1.6" translation_maintainer="Christian Couder Ne pas suivre certaines de ces étapes n'entraînera pas la
disqualification d'une proposition. Cependant, considérez
celles-ci comme une politesse aidant les développeurs à
trouver et comprendre votre proposition dans les listes de
diffusion qui génèrent déjà d'énormes quantités de messages.
Toutes les directives sont incluses dans ce
modèle
(qui devrait bientôt être ajouté).
Quand vous avez terminé votre proposition,
envoyez-la à la liste de diffusion debian-vote
ou directement à secretary@debian.org (qui la réexpédiera
à -vote de toute façon). Les propositions ne seront
pas prises en compte dans toute autre liste de diffusion
ni à aucune autre adresse électronique. Ceci afin d'éviter que
le secrétaire du projet ne rate une proposition parmi
l'énorme volume de messages généré sur certaines de nos
listes et aussi de lui éviter d'avoir à s'abonner
à toutes les listes créées par le projet.
Les noms des personnes soutenant une proposition doivent aussi
être envoyés à la liste debian-vote ou à secretary@debian.org
pour que les soutiens soient considérés comme valables.
Si vous proposez une modification dans le texte d'un
document, indiquez quel document et incluez les modifications
de la même façon que pour un fichier diff contextuel (voyez :
info diff (-c) pour plus de détails). Par courtoisie, commencez un nouveau fil de discussion
pour votre proposition.
Ce sera l'endroit où vous pourrez donner tous les détails
relatifs à la proposition et essayer de convaincre tout le
monde de « Quelle Bonne Idée(tm), celle là ! ». Mettez dans
l'objet de votre message quelque chose comme
Sauf si l'on vous indique la liste de diffusion à utiliser,
envoyez la proposition à -devel-announce et les discussions
à -devel. La seule exigence est celle de la section 4.2.5 de
la constitution qui dit que tout doit avoir lieu « sur une
liste de diffusion électronique à accès public en lecture... »
Évidemment, si la proposition est strictement relative à
quelque chose, par exemple python, envoyez-la à -python et
non pas à -www.
Si la proposition arrive à un point où un vote formel
utilisant le système de vote Debian devient nécessaire,
envoyez une copie de la proposition et les noms de ceux qui
la soutiennent à secretary@vote.debian.org.
Les propositions peuvent être amendées à tout moment tant
que le vote n'a pas commencé.
Une proposition est automatiquement amendée si celui qui est
à son origine et tous ceux qui la soutiennent sont d'accord
avec l'amendement.
Si l'un d'entre eux n'est pas d'accord, l'amendement
doit avoir un nombre identique de gens qui le soutiennent.
Quand arrive le moment de voter la proposition, celui qui est
à son origine appelle à voter chaque amendement séparément ou
tous ensemble ou encore tous ensemble avec la proposition
originale.
Les directives
L'objet
Tout d'abord, formattez le sujet du message comme ceci :
Subject: Proposal - {une description} De cette
façon, les gens peuvent filtrer les messages pour trouver les
propositions.
Le texte
Autrement, essayez d'être aussi clair que vous le pouvez.
Indiquez ce que vous voulez voir se réaliser et donnez les
motifs des raisons sans entrer dans de longs détails. Vous
pourrez toujours donner la version longue au cours de la
discussion.
La discussion
Discussion - {même description} et essayez de
maintenir la discussion sur ce fil et laissez les nouveaux
fils à leurs sponsors.
Les messages
Les amendements
Reply to: