Outils pour utilisateurs

Outils du site


openbsd.org:report

Ceci est une ancienne révision du document !


Version de traduction basée sur la 6.1 officielle


Rapporter des problèmes

Rapport d'un problème version release

Avant de rapporter un bogue/problème avec la release, vérifiez les points suivants :

  1. Ensuite, regardez s'il n'y a pas une nouvelle release disponible.
  2. Finalement, vérifiez les changements de versions d'OpenBSD.

Si rien ne ressemble à votre problème, veuillez vous familiariser avec sendbug(1) avant de soumettre un rapport de bogue.

Rapport d'un problème version current

Si votre problème est avec l'arbre des sources -current plutôt que -release ou -stable,

  1. Testez le problème au-moins deux fois, avec des sources mises-à-jours à intervalle de quelques jours.
  2. Ne pas rapporter des problèmes de compilation de l'arbre de source, à moins qu'ils soient persistants. C'est presque toujours une erreur de votre part, ou ils sont mises-à-jour au moment où vous les remonter. Les personnes qui travaillent sur le projet construisent au moins une fois par jour, et généralement plusieurs fois par jour pour les différentes architectures.
  3. Rappelez vous que les mises-à-jours des serveurs AnonCVS durent plusieurs heures, après l'actuel arbre des sources.
  4. Vérifiez les changements de versions OpenBSD pour voir si le problème a été transmis.
  5. Prenez bien soin dans la création des snapshots. Parfois quelques erreurs sont faites, nous nous excusons pour cela. Lire et écrire aux listes de mails est plus approprié qu'envoyer un rapport de bogue.

Comment créer un rapport

Toujours fournir le plus d'informations possibles. Essayez de pointer le problème exact. Donnez des instructions claires pour reproduire le problème. Essayez de le décrire avec autant de précision que possible et des mots ne portant pas à confusion, spécifiquement si le problème n'est pas facile à reproduire. Décrire les problèmes en disant “Cela crashe” ou “J'ai un problème étrange avec cette construction” est inutile. Communiquez avec les autres (sur les listes de mails ou sur tout forum où des utilisateurs compétents se rassemblent) pour confirmer que le problème est nouveau et de préférence répété. SVP, assurez vous que ce ne soit pas un problème local par l'utilisation d'un matériel défectueux ou non supporté, ou par l'usage d'un logiciel ou d'une option de construction non supportée.

SVP, ne commencez pas à fixer des problèmes qui requiert un travail significatif à moins que vous ne soyez capable de les comprendre, spécialement durant les périodes de publication pendant lesquelles nous ne faisons aucun changement majeur de code. Si vous vous apprêtez à écrire des quantités importantes de code, mentionnez-le sur les listes de mails afin de vous assurez que personne d'autre ne travaille sur ce problème (cela économise les efforts).

Les différents points suivants devraient être contenus dans chaque rapport de bogue :

  1. La séquence exacte des étapes depuis le débur sont nécessaires pour reproduire le problème. This should be self-contained ; il ne suffit pas d'envoyer une commande nue sans les arguments et autres données utilisées. Si le bogue requiert une séquence particulière d'évenements, veuillez les lister. Bien que cela ne soit pas absolument nécessaire, vous êtes encouragé à minimiser la taille de votre exemple. Si le bogue est reproductible, nous le trouverons de toute manière.
  2. La sortie que vous obtenez. SVP, ne dites pas “cela ne fonctionne pas” ou “c'est en échec”. S'il y a un message d'erreur, montrez-le, même si vous ne le comprenez pas. Si OpenBSD panique avec une erreur particulière, restituez-la. Si rien du tout ne se passe, dites-le. Même si le résultat de votre test restitue un problème ou tout autre comportement aberrant, il se peut qu'il ne se passe rien durant nos tests. La chose la plus facile à faire est de copier la sortie depuis le terminal, si possible.
    1. Note : Dans le cas d'erreurs fatales, le message d'erreur peut ne pas contenir toutes les informations disponibles. Dans ce cas, regardez aussi la sortie des journaux systèmes tels que ceux enregistrés dans /var/log. De plus, si vous utilisez une application qui a ses propres fichiers journaux, tel que httpd, vérifiez les erreurs que peuvent renfermer ses logs.
  3. La sortie du noyau OpenBSD. Vous pouvez l'obtenir avec la commande dmesg, mais il est possible que la sortie de dmesg ne contienne pas toutes les informations capturées dans /var/run/dmesg.boot. Dans ce cas, incluez les informations des deux. Veuillez inclure cela dans tous les rapports de bogue.
  4. Si vous utilisez un logiciel tiers relatif à votre bogue, dites-le, incluant la version. Si vous parlez d'un snapshot, mentionnez-le, incluant ses dates et heures.
  5. Une trace de votre kernel panic. Si votre noyau panique et que vous avez l'invite ddb(4), veuillez fournir le message d'erreur, aussi bien la sortie des commandes trace et ps dans votre rapport de bogue tels que retournés. Si le machine se bloque, essayez d'activer sysctl ddb.console=1 et d'obtenir dans DDB via Ctl+Alt+Esc (en-dehors de X), ou d'envoyer BREAK si vous utilisez une console série. Si, pour une raison quelconque, le message panic n'est pas visible, vous pouvez l'obtenir à nouveau avec la commande show panic. Ceci est essentiel chaque fois que possible. Les rapports de panic sans messages panic, retour des sorties trace et ps sont inutiles. La sortie des show registers pourrait être aussi intéressante. Vous voudrez redémarrer avec boot dump afin que l'image du noyau soit sauvé par savecore(8) pour un débogage post-mortem ultérieur, tel que décrit dans la page de manuel crash(8).
  6. Si vous rapportez un problème avec le Système X Window sur une architecture qui utilise le serveur X.org, veuillez inclure le fichier complet /var/log/Xorg.0.log dans votre rapport en complément de l'information de dmesg.boot.

Ne soyez pas effrayé que votre rapport soit long. C'est un fait. Il est préférable de rapporter chaque chose dès la première fois. D'autre part, si vos fichiers d'entrées sont énormes, il vaut mieux demander en premier si quelqu'un est intéressé à les voir.

Envoyer des rapports de bogues

Si possible, utilisez la commande sendbug(1) pour aider à générer votre rapport de bogue. Il inclura automatiquement quelques informations utiles à-propos de votre matériel ce qui aide à diagnostiquer beaucoup d'issues. Cet outil requiert que votre système puisse proprement envoyer un courriel. Si vous ne pouvez utiliser sendbug sur une machine OpenBSD fonctionnelle, veuillez envoyer votre rapport de bogue à bugs@openbsd.org.

Peut-être voulez vous envoyer une demande de fonctionnalité, pas nécessairement un bogue. Les nouvelles fonctionnalités sont acceptées, spécialement avec le code qui implémente votre nouvelle fonctionnalité suggérée.

Pour déboguer quelques problèmes, nous devons avoir le matériel avec lequel est le problème. SVP souvenez vous que les ressources du projet OpenBSD sont limitées. Vous pouvez donner quelques matériels.


Cette page est la traduction officieuse de la page “Problem Reports” de la FAQ officielle d'OpenBSD.
En cas de doute, merci de vous y référer !

Si vous voulez participer à l'effort de traduction, merci de lire ce topic.

openbsd.org/report.1495615178.txt.gz · Dernière modification: 2020/01/19 16:22 (modification externe)