Que faire si vous trouvez un bug ?#

Pour commencer, vérifiez que vous avez vraiment trouvé un bug :

  • regardez bien dans des livres traitant de ou tout autre variante que vous utilisez ;

  • comparez ce que vous observez avec les réponses de cette FAQ ;

  • demandez aux personnes que vous connaissez et qui ont une expertise en lien avec

Les raisons de cette prudence sont nombreuses.

Si vous avez trouvé un bug dans lui-même, vous appartenez en effet à une espèce fort rare. Donald Knuth est tellement sûr de la qualité de son code qu’il offre de l’argent aux découvreurs de bug ; les chèques qu’il rédige sont si rares qu’ils ne sont quasiment jamais encaissés. Si vous pensez que vous avez réellement trouvé une erreur dans (ou ou les fontes Computer Modern ou le ‹book), n’écrivez pas immédiatement à Knuth. Il analyse les bugs de façon assez sporadique, même si ces derniers ont été validés par une petite équipe d’experts. Dans un premier temps, contactez Karl Berry du TUG (en anglais).

Si vous avez trouvé un bug dans déclarez-le (voir ci-dessous) en utilisant les mécanismes mis en place par l’équipe Soyez bien attentif à vous assurer qu’il s’agit d’un bug de ou d’une des extensions distribuées par l’équipe

Si vous avez trouvé un bug dans une extension, le mieux est de commencer par les lieux usuels pour obtenir de l’aide en ligne ou les différentes listes de diffusion spécialisées. L’auteur de l’extension pourrait bien vous répondre en ligne mais, si personne d’autre ne vous fournit d’aide, vous pouvez tenter de lui écrire directement (en supposant que vous arrivez à trouver son adresse).

Si vous avez trouvé un bug dans 2.09 ou dans un des autres logiciels qui ne sont plus maintenus, votre seul espoir est l’aide en ligne.

Si tout ceci échoue, envisagez de payer pour obtenir de l’aide : le TUG tient à jour un registre de consultants Ceci suppose que vous avez les ressources et un besoin tel que vous puissiez recruter quelqu’un.

1.  Comment savoir si un bug vient de ou d’une extension ?#

L’équipe fait la maintenance de et traite tout rapport de bug. Mais elle ne traite pas les bugs des multiples extensions dont elle n’est pas l’auteur : elle ne suit que les logiciels qui font partie de la distribution à savoir et les seules extensions qui lui sont « indispensables ».

Si le bug que vous avez trouvé est dans une extension maintenue par d’autres développeurs, c’est à eux que vous devez faire votre rapport.

Pour vous aidez à savoir à qui déclarer le bug, l’équipe de développement de fournit l’extension latexbug. Vous devez vous en servir pendant que vous composez l’exemple qui illustrera votre rapport de bug. Pour cela, il suffit d’ajouter la ligne \RequirePackage{latexbug} en tout début de fichier :

\RequirePackage{latexbug} % Première ligne obligatoire

\documentclass{article} % Ensuite, votre exemple
...                     % de code qui illustre le bug
\end{document}

Pendant la compilation, sur le terminal, vous verrez des indications à propos des extensions chargées, qui les maintient, et où vous devez envoyer votre rapport de bug :

Package latexbug Error: Third-party file(s)
(latexbug)
(latexbug)         This test file uses third-party file(s)
(latexbug)
[...]
[... Liste des extensions et de leurs mainteneurs ...]
[...]
(latexbug)         So you should contact the authors
(latexbug)         of these files, not the LaTeX Team!
(latexbug)         (Or remove the packages that load
(latexbug)         them, if they are not necessary to
(latexbug)         exhibit the problem).

Si vous pensez que l’une ou l’autre des extensions indiquées n’est pas à l’origine du bug, adaptez votre exemple pour les retirer. Ceci vous permettra de réduire votre exemple pour former un ECM, et de cerner l’origine du bug, ce qui aidera les mainteneurs à vous aider.

2.  Comment déclarer un bug de #

Dans tous les cas, vous devez bien faire attention à produire un rapport de bug qui soit utilisable par l’équipe. Voici les étapes à suivre :

  1. Utilisez-vous une version récente de La maintenance n’est possible que sur des versions suffisamment à jour de

  2. Votre bug a-t-il déjà été rapporté ? Parcourez l’actuelle base d’anomalies et l’ancienne base GNATS pour trouver un éventuel rapport antérieur de votre bug. Dans de nombreux cas, ces bases listeront des solutions de contournement.

  3. Préparez un exemple minimal qui présente le problème. Idéalement, ce fichier ne doit contenir que des extensions « indispensables » suivies par l’équipe car les autres extensions font l’objet de suivis par leurs propres auteurs. L’exemple minimal doit être auto-suffisant : si un membre de l’équipe le compile dans un répertoire propre avec un système n’ayant que les extensions « indispensables », l’anomalie doit se produire. Vous pouvez consulter les conseils de l’équipe pour plus de détails.

  4. Compilez votre fichier de test avec le rapport de bug doit inclure le fichier .log créé par la compilation.

  5. Enfin, déclarez l’incident dans la base d’anomalies .

Sources