=head1 NOM perlbug - comment soumettre des rapports de bug sur Perl =head1 SYNOPSIS B S<[ B<-v> ]> S<[ B<-a> I

]> S<[ B<-s> I ]> S<[ B<-b> I | B<-f> I ]> S<[ B<-F> I ]> S<[ B<-r> I ]> S<[ B<-e> I ]> S<[ B<-c> I | B<-C> ]> S<[ B<-S> ]> S<[ B<-t> ]> S<[ B<-d> ]> S<[ B<-A> ]> S<[ B<-h> ]> B S<[ B<-v> ]> S<[ B<-r> I ]> S<[ B<-A> ]> S<[ B<-ok> | B<-okay> | B<-nok> | B<-nokay> ]> =head1 DESCRIPTION Un programme pour aider à produire des rapports de bug au sujet de perl ou des modules qui l'accompagne, et qui les poste. Si vous avez trouvé un bug avec un port spécial (un de qui ne fait pas partie de la distribution standard), une distribution binaire, ou un module spécial (tel que Tk, CGI, etc) alors, s'il vous plaît, voyez la documentation qui est fournie avec cette distribution pour déterminer où rapporter des bugs. C est conçu pour être utilisé interactivement. Normalement aucun argument n'est nécessaire. Lancez-le simplement, et suivez ses indications. Si vous ne pouvez pas lancer B (le plus souvent parce que votre configuration pour poster n'est pas reconnue par B), vous devez composer votre propre rapport, et le poster à B. Vous pouvez alors trouver l'option B<-d> utile pour obtenir une information sommaire dans ce cas. En tout cas, pour rapporter un bug, assurez-vous, s'il vous plaît, d'avoir parcouru cette liste de contrôle: =over 4 =item Quelle version de Perl utilisez-vous ? Tapez C à la ligne de commande pour la trouver. =item Utilisez-vous la dernière version disponible de perl ? Regardez à http://www.perl.com/ pour la trouver. Si vous n'avez pas la plus récente version disponible, procurez-vous cette dernière et regarder si votre bug a été corrigé. Notez que les rapports de bug relatifs à de vieilles versions de Perl, surtout celles d'avant la version 5.0, ont des chances de tomber dans l'oreille d'un sourd. Vous ne pouvez compter que sur vous-même si vous continuez à utiliser perl1.. perl4. =item Êtes-vous sûr que vous avez trouvé un bug ? Un nombre considérable de rapports de bug que nous recevons se rapporte à des fonctions documentées de Perl. Assurez-vous que le comportement que vous observez ne tombe pas dans cette catégorie, en jetant un coup d'oeil à la documentation fournie avec Perl (nous admettons que ce n'est pas une mince affaire, vu son grand volume, mais au moins jetez un coup d'oeil aux sections qui I pertinentes). Prenez connaissance des pièges usuels dans lesquels tombent les divers programmeurs de perl. Voyez L. Vérifiez dans L la signification de tout message d'erreur obtenu. Si le message n'est pas dans perldiag, il n'est probablement pas produit par Perl. Consultez alors la documentation du système d'exploitation. Si vous êtes sur une plate-forme non UNIX examinez L : certaines fonctions peuvent être non implémentées ou bien travailler différemment. Essayez d'étudier le problème sous le débogueur Perl, si nécessaire. Voyez L. =item Avez-vous un test adéquat de ce cas ? Plus votre bug sera reproduit facilement, plus il aura de chance d'être corrigé, parce que si personne ne peut dupliquer le problème, personne ne peut l'arranger. Un bon test de cas possède la plupart des attributs suivants : le plus petit nombre possible de lignes; peu de dépendances avec les commandes externes, les modules, ou les bibliothèques; tourne sur la plupart des plate-formes libres; et est autodocumenté. Un bon test de cas est presque toujours un bon candidat pour être dans la suite des tests de perl. Si vous avez le temps, arrangez votre test de telle manière qu'il s'insère aisément dans la suite des tests standards. Souvenez-vous aussi d'inclure le message d'erreur B, s'il y en a un. "Perl s'est plaint de quelque chose" n'est pas un message d'erreur exact. Si vous obtenez un vidage mémoire [core dump] (ou équivalent), vous pouvez utiliser un débogueur (B, B, etc) pour produire une trace de la pile à inclure dans le rapport de bug. NOTE: à moins que votre Perl n'ait été compilé avec l'option debug-info (souvent B), il est possible que la trace de la pile soit difficile à utiliser parce qu'elle contiendra seulement les noms de fonction et non leurs arguments. Si possible, recompilez votre Perl avec l'option debug-info et reproduisez le vidage mémoire et la trace de la pile. =item Pouvez-vous décrire le bug en bon anglais ? Plus il est facile de comprendre un bug reproductible, plus il y a de chance qu'il soit corrigé. Tout ce que vous pouvez fournir de pertinent à propos du problème aide énormément. En d'autres termes, essayez d'analyser le problème (autant que vous pouvez) et rapportez vos découvertes. =item Pouvez-vous corriger le bug vous-même ? Un rapport de bug qui I sera corrigé presque sans aucun doute. Utilisez le programme C pour produire vos patchs (C est maintenu par les gens du GNU comme partie du paquetage B, donc vous devriez pouvoir l'obtenir dans l'un des dépôts des logiciels du GNU). Si vous soumettez un patch, le compteur de mecs-cool à perlbug@perl.org vous inscrira comme un sauveur du monde. Votre patch peut vous être retourné avec des demandes de changements, ou des demandes d'explications plus détaillées au sujet de votre correction. Donnons ici quelques indices pour créer des patch de qualité : Utilisez les options B<-c> ou B<-u> du programme C (pour créer un fichier diff avec contexte ou unifié). Assurez-vous que le patch n'est pas inversé (typiquement le premier argument de C est le fichier original, le second argument est votre fichier modifié). Testez votre patch en l'appliquant avec le programme C avant de l'envoyer. Essayez de suivre le même style que le code que vous essayez de corriger. Assurez-vous vraiment que votre patch fonctionne (faites un C, si ce que vous essayez de corriger le permet). =item Pouvez-vous utiliser C pour soumettre le rapport ? B doit, entre autres choses, s'assurer que votre rapport inclut des informations cruciales au sujet de votre version de perl. Si C est incapable de poster votre rapport après que vous l'ayez tapé au clavier, vous devrez composer le message vous-même, ajouter la sortie produite par C et poster le tout à B. Si, pour quelque raison, vous ne pouviez pas lancer du tout C sur votre système, assurez-vous d'inclure la sortie entière produite en lançant C (notez le V majuscule). Que vous utilisiez C ou que vous envoyiez l'email manuellement, mettez une ligne Subject significative. "un bug" n'est pas significatif. "perl plante" non plus, ni "À L'AIDE !!!". Ça n'apporte rien. Une description compacte de ce qui ne va pas est bien préférable. =back Ayant fait votre part, préparez-vous à attendre, à vous entendre dire que le bug est dans votre code, ou même à n'obtenir aucune réponse du tout. Les gens qui assurent la maintenance de Perl sont des gens occupés, donc si votre problème est petit ou s'il est difficile à comprendre ou déjà connu, ils peuvent ne pas vous répondre personnellement. S'il est important pour vous que votre bug soit corrigé, surveillez le fichier C dans tout développement publié depuis le moment où vous avez soumis un bug, et encouragez les mainteneurs avec des mots gentils (mais jamais de flames!). N'hésitez pas à renvoyer votre rapport de bug si la dernière version de perl sort et que votre bug est toujours présent. =head1 OPTIONS =over 8 =item B<-a> Adresse où envoyer le rapport. Par défaut `perlbug@perl.org'. =item B<-A> Ne pas envoyer d'accusé de réception de rapport de bug à l'adresse de retour. En général, cette option n'est seulement utile que si vous êtes un mainteneur de perl qui scrute les perl porters pour voir si vos messages arrivent. =item B<-b> Corps du rapport. Si non inclus sur la ligne de commande, ou dans un fichier avec B<-f>, vous aurez une possibilité d'éditer le message. =item B<-C> Ne pas envoyer de copie à l'administrateur. =item B<-c> Adresse pour envoyer une copie du rapport. Par défaut l'adresse de l'administrateur du perl local (enregistré quand perl a été construit). =item B<-d> Mode données (par défaut si vous redirigez la sortie ou utilisez des pipes). Cela imprime vos données de configuration, sans rien poster. Vous pouvez l'utiliser avec B<-v> pour obtenir des données plus complètes. =item B<-e> Éditeur à utiliser. =item B<-f> Fichier contenant le corps du rapport. À utiliser pour envoyer rapidement un message déjà préparé. =item B<-F> Fichier où envoyer le résultat plutôt que d'envoyer un email. Utile surtout quand on utilise perlbug sur une machine sans connexion internet directe. =item B<-h> Affiche un court sommaire des options. =item B<-ok> Envoie un rapport de compilation réussie sur ce système aux perl-porters. Force les options B<-S> et B<-C>. Force et donne des valeurs aux options B<-s> and B<-b>. Demande seulement une adresse de retour s'il ne peut pas la deviner (pour utilisation avec B). Tient compte de l'adresse de retour spécifiée avec B<-r>. Vous pouvez l'utiliser avec B<-v> pour obtenir plus de données. Fait un rapport seulement si le système est vieux de moins de 60 jours. =item B<-okay> Identique à B<-ok> excepté qu'il peut envoyer un rapport sur un plus vieux système. =item B<-nok> Envoie un rapport de d'échec de compilation sur ce système. Force l'option B<-C>. Force et donne une valeur pour l'option B<-s>, puis vous demande d'éditer le rapport pour dire ce qui ne va pas. Ou bien, un rapport déjà préparé peut être fourni avec B<-f>. Demande seulement une adresse de retour s'il ne peut pas la deviner (pour utilisation avec B). Tient compte de l'adresse de retour spécifiée avec B<-r>. Vous pouvez l'utiliser avec B<-v> pour obtenir plus de données. Fait un rapport seulement si le système est vieux de moins de 60 jours. =item B<-nokay> Identique à B<-nok> excepté qu'il peut envoyer un rapport sur un plus vieux système. =item B<-r> Votre adresse de retour. Le programme demandera que vous confirmiez sa valeur par défaut si vous n'utilisez pas cette option. =item B<-S> Envoie sans demander de confirmation. =item B<-s> Sujet à inclure avec le message. Le programme vous le demandera si vous ne le fournissez pas sur la ligne de commande. =item B<-t> Mode test. L'adresse par défaut de la cible est `perlbug-test@perl.com'. =item B<-v> Inclut dans le rapport des informations étendues sur la configuration. =back =head1 AUTEURS Kenneth Albanowski (Ekjahds@kjahds.comE), subsequently Itored by Gurusamy Sarathy (Egsar@activestate.comE), Tom Christiansen (Etchrist@perl.comE), Nathan Torkington (Egnat@frii.comE), Charles F. Randall (Ecfr@pobox.comE), Mike Guy (Emjtg@cam.a.ukE), Dominic Dunlop (Edomo@computer.orgE), Hugo van der Sanden (Ehv@crypt0.demon.co.ukE), Jarkko Hietaniemi (Ejhi@iki.fiE), Chris Nandor (Epudge@pobox.comE), Jon Orwant (Eorwant@media.mit.eduE, and Richard Foley (Erichard@rfi.netE). =head1 VOIR AUSSI perl(1), perldebug(1), perldiag(1), perlport(1), perltrap(1), diff(1), patch(1), dbx(1), gdb(1) =head1 BUGS Aucun de connu (devinez ce qui a dû être utilisé pour les rapporter ?) =head1 TRADUCTION EN FRANÇAIS Jean-Louis Morel =cut