Guide de rapport de bogue de Gentoo

1.  Introduction

Préface

L'un des facteurs qui fait qu'un bogue tarde à être corrigé réside dans la manière dont il est rapporté. En créant ce guide, nous espérons aider à améliorer la communication entre les développeurs et les utilisateurs en ce qui concerne la résolution de bogues. La correction de bogues constitue une part importante sinon cruciale de l'assurance de qualité quelque soit le projet alors espérons que ce guide aidera à y contribuer.

Bogues !!!!

Vous êtes en train d'installer un paquet ou de travailler avec un programme quand soudainement, le pire arrive : vous trouvez un bogue. Les bogues surviennent de différentes manières, il y a par exemple les erreurs qui se produisent lors de la commande emerge ou les erreurs de segmentation. Quelqu'en soit la cause, le fait est qu'un tel bogue doit être corrigé. Voici quelques exemples de ce genre de bogues.

$ ./bad_code `perl -e 'print "A"x100'`
Segmentation fault

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2 of
the C++ standard. Examples include substituting the <X> header for the <X.h>
header for C++ includes, or <sstream> instead of the deprecated header
<strstream.h>. To disable this warning use -Wno-deprecated.
In file included from main.cc:40:
menudef.h:55: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:62: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:70: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:78: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
main.cc: In member function `void OXMain::DoOpen()':
main.cc:323: warning: unused variable `FILE*fp'
main.cc: In member function `void OXMain::DoSave(char*)':
main.cc:337: warning: unused variable `FILE*fp'
make[1]: *** [main.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xclass-0.7.4/work/xclass-0.7.4/example-app'
make: *** [shared] Error 2

!!! ERROR: x11-libs/xclass-0.7.4 failed.
!!! Function src_compile, Line 29, Exitcode 2
!!! 'emake shared' failed

Ces erreurs peuvent être très gênantes. Toutefois, une fois que vous les avez décelées, que devez-vous faire ? Les sections suivantes vont présenter deux outils importants dans la gestion des erreurs d'exécution. Après cela, nous jetterons un œil aux erreurs de compilation et à la manière de les traiter. Commençons dès à présent avec le premier outil de débogage pour les erreurs d'exécution, GDB.

2.  Débogage grâce à GDB

Introduction

GDB, pour le (G)NU (D)e(B)ugger, est un programme utilisé pour trouver les erreurs d'exécution qui impliquent généralement une corruption de la mémoire. Tout d'abord, jetons un œil à ce qui permet le débogage. L'une des principales choses que vous devez faire afin de déboguer un programme est d'installer le programme avec FEATURES="nostrip". Cela évite la suppression des symboles de débogage. Pourquoi les programmes sont-ils privés de ceux-ci par défaut ? La raison est la même que celle pour laquelle les pages du manuel sont compressées avec gzip : l'économie de place. Voici la façon dont varie la taille d'un programme avec et sans la suppression des symboles de débogage.

(symboles de débogage supprimés)
-rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
(symboles de débogage intacts)
-rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code

Juste pour indication, bad_code est le programme que nous allons déboguer avec GDB plus tard. Comme vous pouvez le voir, le programme privé des symboles de débogage ne pèse que 3140 octets, tandis que le même programme avec ces symboles en pèse 6374, soit près du double ! Deux autres choses peuvent être faites pour aider au débogage. La première est d'ajouter ggdb dans votre CFLAGS et dans votre CXXFLAGS. Cette variable ajoute plus d'informations de débogage que la normale. Nous verrons ce que cela signifie plus tard. Voici ce à quoi pourrait ressembler votre fichier /etc/make.conf après l'ajout de ces nouvelles variables.

CFLAGS="-O1 -pipe -ggdb"
CXXFLAGS="${CFLAGS}"

Enfin, vous pouvez ajouter l'option debug de la variable USE à vos paquets, par l'intermédiaire du fichier package.use.

# echo "catégorie/paquet debug" >> /etc/portage/package.use

Ensuite, nous allons réinstaller le paquet avec les modifications faites plus haut comme montré ci-dessous.

# FEATURES="nostrip" emerge paquet

Maintenant que les symboles de débogage sont mis, nous pouvons continuer avec le débogage du programme.

Exécution du programme avec GDB

Disons que nous avons un programme appelé ici « bad_code ». Quelqu'un a affirmé que le programme plantait et a fourni un exemple. Vous allez tester sa sortie.

$ ./bad_code `perl -e 'print "A"x100'`
Segmentation fault

Il semble que cette personne avait raison. Puisque le programme est effectivement corrompu, nous avons un bogue sous la main. À présent, il est temps d'utiliser GDB pour nous aider à résoudre ce problème. Tout d'abord nous lançons GDB avec --args suivi du programme complet avec ses arguments comme voici :

$ gdb --args ./bad_code `perl -e 'print "A"x100'`
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

Vous devriez voir une invite de commande indiquant « (gdb) » et attendant une saisie clavier. D'abord, nous devons exécuter le programme. En écrivant run sur la ligne de commande nous obtenons une information telle que celle-ci :

(gdb) run
Starting program: /home/chris/bad_code

Program received signal SIGSEGV, Segmentation fault.
0xb7ec6dc0 in strcpy () from /lib/libc.so.6

Ici nous pouvons voir le programme démarrer ainsi qu'une notification de SIGSEGV, c'est-à-dire une erreur de segmentation. C'est GDB qui nous dit que notre programme a planté. Il nous donne également la dernière fonction exécutée qu'il a pu remonter quand le programme a planté. Toutefois, ceci n'est pas très utile puisqu'il peut y avoir de nombreux « strcpy » dans le programme, rendant difficile pour les développeurs de déceler celui qui cause ce problème. Afin de les aider, nous allons faire ce qu'on appelle un traçage (NdT : « backtrace »). Un traçage exécute à l'envers toutes les fonctions qui existent dès l'exécution du programme jusqu'à la fonction qui produit la faute. Les fonctions qui retournent quelque chose (sans causer de plantage) ne seront pas montrées dans le traçage. Pour obtenir un traçage, sur l'invite de commande (gdb), écrivez bt. Vous obtiendrez quelque chose comme ceci :

(gdb) bt
#0  0xb7ec6dc0 in strcpy () from /lib/libc.so.6
#1  0x0804838c in run_it ()
#2  0x080483ba in main ()

Vous pouvez remarquer clairement la trace du patron. La fonction main() est appelée en premier, suivie de la fonction run_it(), et quelque part dans run_it() se trouve le strcpy() qui commet la faute. De telles informations aident les développeurs à réduire les problèmes. Il y a des cas où vous n'obtiendrez pas cette sortie. Le premier se produit si vous oubliez d'activer les symboles de débogage avec FEATURES="nostrip". Si les symboles sont supprimés, la sortie ressemblera plutôt à quelque chose comme cela :

(gdb) bt
#0  0xb7e2cdc0 in strcpy () from /lib/libc.so.6
#1  0x0804838c in ?? ()
#2  0xbfd19510 in ?? ()
#3  0x00000000 in ?? ()
#4  0x00000000 in ?? ()
#5  0xb7eef148 in libgcc_s_personality () from /lib/libc.so.6
#6  0x080482ed in ?? ()
#7  0x080495b0 in ?? ()
#8  0xbfd19528 in ?? ()
#9  0xb7dd73b8 in __guard_setup () from /lib/libc.so.6
#10 0xb7dd742d in __guard_setup () from /lib/libc.so.6
#11 0x00000006 in ?? ()
#12 0xbfd19548 in ?? ()
#13 0x080483ba in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0xb7deebcc in __new_exitfn () from /lib/libc.so.6
#17 0x00000000 in ?? ()
#18 0xbfd19560 in ?? ()
#19 0xb7ef017c in nullserv () from /lib/libc.so.6
#20 0xb7dd6f37 in __libc_start_main () from /lib/libc.so.6
#21 0x00000001 in ?? ()
#22 0xbfd195d4 in ?? ()
#23 0xbfd195dc in ?? ()
#24 0x08048201 in ?? ()

Ce traçage contient un grand nombre de marques « ?? ». Cela est dû au fait que GDB ne connaît pas la façon dont le programme a été exécuté puisqu'il n'y a pas de symboles de débogage. Il est donc crucial de ne pas supprimer ces symboles. À présent, rappelez-vous qu'au-dessus nous avions mentionné l'existence d'une option -ggdb. Voyons à quoi ressemble la sortie si celle-ci est active :

(gdb) bt
#0  0xb7e4bdc0 in strcpy () from /lib/libc.so.6
#1  0x0804838c in run_it (input=0x0) at bad_code.c:7
#2  0x080483ba in main (argc=1, argv=0xbfd3a434) at bad_code.c:12

Nous pouvons voir que beaucoup plus d'informations sont disponibles pour les développeurs. Non seulement le nom de la fonction est affiché, mais il y a également les numéros de lignes exacts dans la source des fichiers. Cette méthode est celle qui est préférée si vous pouvez libérer un peu d'espace supplémentaire. Voici comment varie la taille des fichiers avec la présence des symboles de débogage, sans ces symboles, et avec l'activation de l'option -ggdb.

(symboles de débogage supprimés)
-rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
(symboles de débogage intacts)
-rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code
(variable -ggdb active)
-rwxr-xr-x  1 chris users 19552  6/28 13:11 bad_code

Comme vous pouvez le remarquer, -ggdb ajoute environ 13178 octets de plus à la taille du fichier par rapport à celui qui contient les symboles de débogage. Toutefois, comme nous l'avons vu, ce poids supplémentaire peut valoir le coup pour présenter les informations de débogage aux développeurs. Le traçage peut être sauvegardé dans un fichier en copiant et collant depuis le terminal. (Si c'est un terminal qui n'utilise pas le serveur X, vous pouvez utiliser GPM. Afin de garder cette documentation simple, je vous recommande de lire la documentation pour GPM pour voir comment copier et coller avec.) Maintenant que nous avons fait ce que nous devions avec GDB, nous pouvons en sortir.

(gdb) quit
The program is running. Exit anyway? (y or n) y
$

Ceci clôt la découverte de GDB. En utilisant GDB, nous espérons que vous serez en mesure de l'utiliser pour créer de meilleurs rapports de bogue. Toutefois, il y a d'autres types d'erreurs qui peuvent causer l'interruption d'un programme durant son exécution. L'un des autres cas peut être une erreur d'accès à un fichier. Nous pouvons les retrouver en utilisant un petit outil bien chouette du nom de strace.

3.  Utiliser strace pour chercher les erreurs d'accès aux fichiers

Introduction

Les programmes utilisent souvent des fichiers pour récupérer des informations de configuration, accéder au matériel ou écrire des journaux. Parfois, un programme tente d'accéder à de tels fichiers de manière incorrecte. Un outil nommé strace a été créé afin de faciliter leur détection. strace trace les appels systèmes (d'où le nom), ce qui implique les appels qui utilisent la mémoire et les fichiers. Pour notre exemple, nous allons prendre un programme nommé foobar2, qui est une version mise à jour de foobar. Cependant, durant la transition vers foobar2, vous vous apercevez que tous les fichiers de configuration sont manquants ! Vous aviez configuré la première version de foobar pour qu'elle affiche « foo », mais maintenant elle affiche la valeur par défaut « bar ».

$ ./foobar2
La configuration dit: bar

Notre configuration précédente était spécialement définie à « foo », utilisons donc strace pour savoir ce qui se passe.

Utiliser strace pour chercher le problème

Nous utilisons strace pour enregistrer les résultats des appels systèmes. Pour cela, nous lançons strace avec l'argument -o[fichier]. Utilisons-le sur foobar2 comme suit :

# strace -ostrace.log ./foobar2

Cela crée un fichier nommé strace.log dans le répertoire courant. Nous vérifions le fichier, et en voici ci-dessous la partie intéressante :

open(".foobar2/config", O_RDONLY)       = 3
read(3, "bar", 3)                       = 3

Aha! Voilà donc le problème. Quelqu'un a changé l'emplacement du répertoire de configuration vers .foobar2 au lieu de .foobar. Nous voyons également que le programme lit « bar » comme prévu. Dans ce cas-ci, nous recommandons au mainteneur de l'ebuild d'ajouter un avertissement à ce propos. Pour le moment toutefois, nous pouvons remplacer le fichier de configuration avec celui du répertoire .foobar et le modifier afin d'obtenir le résultat correct.

Conclusion

Nous nous sommes donc occupés de rechercher les bogues d'exécution du programme. Ces bogues sont souvent problématiques lorsque vous essayez et lancez vos programmes. Cependant, ces erreurs d'exécution s'avèrent sans grande importance lorsque votre programme ne compile pas du tout. Intéressons-nous donc à la manière d'aborder les erreurs de compilation d'emerge.

4.  Gérer les erreurs d'emerge

Introduction

Les erreurs d'emerge, comme celle affichée précédemment, peuvent être une cause majeure de frustration pour les utilisateurs. Leur signalisation est donc considérée commme cruciale pour garantir la santé de Gentoo. Prenons pour exemple un ebuild, foobar2, qui contient des erreurs de compilation.

Évaluer les erreurs d'emerge

Intéressons-nous à cette très simple erreur d'emerge :

gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-7.o foobar2-7.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-8.o foobar2-8.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-9.o foobar2-9.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2.o foobar2.c
foobar2.c:1:17: ogg.h: Aucun fichier ou répertoire de ce type
make: *** [foobar2.o] Error 1

!!! ERROR: sys-apps/foobar2-1.0 failed.
!!! Function src_compile, Line 19, Exitcode 2
!!! Make failed!
!!! If you need support, post the topmost build error, NOT this status message

La compilation du programme se déroule très bien jusqu'à ce qu'elle s'arrête et affiche un message d'erreur. Cette erreur particulière peut se décomposer en trois parties : les messages de compilation, l'erreur de construction et le message d'erreur d'emerge comme montré ci-dessous.

(Les messages de compilation)
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-7.o foobar2-7.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-8.o foobar2-8.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-9.o foobar2-9.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2.o foobar2.c

(L'erreur de construction)
foobar2.c:1:17: ogg.h: Aucun fichier ou répertoire de ce type
make: *** [foobar2.o] Error 1

(L'erreur d'emerge)
!!! ERROR: sys-apps/foobar2-1.0 failed.
!!! Function src_compile, Line 19, Exitcode 2
!!! Make failed!
!!! If you need support, post the topmost build error, NOT this status message

Ce sont les messages de compilation qui amènent à l'erreur. Le plus souvent, il est préférable d'inclure au moins dix lignes d'informations de compilation afin que le développeur sache où la compilation en était quand l'erreur est arrivée.

Veuillez vous assurer de toujours inclure les messages d'erreur en anglais, même si votre langage système est réglé sur autre chose. Vous pouvez temporairement basculer votre système en anglais en préfixant la commande emerge avec LC_ALL=C comme ceci :

# LC_ALL=C emerge sys-apps/foobar2

Les erreurs de make sont de véritables erreurs et fournissent les informations dont le développeur a besoin. Quand vous voyez « make: *** », il s'agit souvent de l'endroit où l'erreur est arrivée. Normalement, vous pouvez copier et coller les dix lignes précédentes et le développeur sera capable d'identifier le problème. Cependant, il se peut que ça ne fonctionne pas et nous allons voir une alternative peu après.

L'erreur d'emerge est ce que la commande renvoie comme une erreur. Parfois, elle peut contenir aussi des informations importantes. Souvent, les gens font l'erreur de ne poster que l'erreur d'emerge et rien d'autre. Elle est inutile toute seule, mais avec l'erreur de make et les informations de compilation, un développeur peut savoir quelle application et quelle version du paquet a ce problème. Petite parenthèse, make est communément utilisé pour le processus de compilation des programmes (mais pas toujours). Si vous ne trouvez d'erreur « make: *** » nulle part, alors copiez et collez simplement les vingt lignes précédant l'erreur d'emerge. Cela devrait couvrir la majorité des messages d'erreurs du système de compilation. Disons maintenant que l'erreur paraît très grande. Dix lignes ne suffiront pas pour tout comprendre. C'est là qu'entre en jeu PORT_LOGDIR.

La commande emerge et PORT_LOGDIR

PORT_LOGDIR est une variable de Portage qui définit un répertoire pour séparer les journaux d'emerge. Intéressons-nous-y et voyons ce que cela requiert. Tout d'abord, lancez emerge en définissant PORT_LOGDIR à votre emplacement préféré. Disons que nous avons un répertoire /var/log/portage. Nous allons l'utiliser pour notre répertoire de journaux :

# PORT_LOGDIR=/var/log/portage emerge cate-gorie/foobar2

Maintenant, emerge va encore échouer. Cependant, nous avons cette fois-ci un journal avec lequel nous pouvons travailler, et que l'on pourra joindre au bogue plus tard. Jetons un œil à notre fichier journal.

# ls -la /var/log/portage
total 16
drwxrws---   2 root root 4096 Jun 30 10:08 .
drwxr-xr-x  15 root root 4096 Jun 30 10:08 ..
-rw-r--r--   1 root root 7390 Jun 30 10:09 cate-gorie:foobar2-1.0:20090110-213217.log

Les fichiers de journaux ont le format [categorie]:[nom du paquet]-[version]:[date].log. Un coup d'œil rapide au journal montre le processus entier d'emerge. Il pourra être joint plus tard comme nous le verrons dans la section de rapport de bogues. Maintenant que nous avons correctement obtenu nos informations nécessaires pour rapporter le bogue, nous pouvons continuer. Cependant, avant d'aborder ce point, nous devons nous assurer que personne n'a déjà rapporté le problème. Intéressons-nous donc à la recherche de bogues.

5.  Recherche avec Bugzilla

Introduction

Bugzilla est ce que nous utilisons chez Gentoo pour gérer les bogues. Le Bugzilla de Gentoo est joignable en HTTPS et en HTTP. La version HTTPS est disponible pour ceux qui sont sur des réseaux non sécurisés ou simplement pour les paranoïaques :). Pour respecter une certaine uniformité, nous utiliserons la version HTTPS dans les exemples qui suivent. Rendez-vous sur Gentoo Bugs pour voir à quoi cela ressemble.

L'une des choses les plus frustrantes pour les développeurs et les mainteneurs de bogues est de trouver des rapports de bogues dupliqués. Cela leur coûte un temps non négligeable qu'ils pourraient plutôt utiliser pour travailler sur des bogues plus importants. Généralement, ceci pourrait être évité avec quelques méthodes simples de recherche. Nous allons ainsi voir comment rechercher des bogues et détecter si vous en avez un similaire. Dans cet exemple, nous allons utiliser l'erreur décelée tout à l'heure avec l'installation de xclass.

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2 of
the C++ standard. Examples include substituting the <X> header for the <X.h>
header for C++ includes, or <sstream> instead of the deprecated header
<strstream.h>. To disable this warning use -Wno-deprecated.
In file included from main.cc:40:
menudef.h:55: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:62: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:70: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:78: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
main.cc: In member function `void OXMain::DoOpen()':
main.cc:323: warning: unused variable `FILE*fp'
main.cc: In member function `void OXMain::DoSave(char*)':
main.cc:337: warning: unused variable `FILE*fp'
make[1]: *** [main.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xclass-0.7.4/work/xclass-0.7.4/example-app'
make: *** [shared] Error 2

!!! ERROR: x11-libs/xclass-0.7.4 failed.
!!! Function src_compile, Line 29, Exitcode 2
!!! 'emake shared' failed

Pour commencer la recherche, rendons-nous sur la page d'accueil du Bugzilla.

Figure 5.1 : Page d'accueil du Bugzilla

Cliquons sur « Query Existing bug reports » (NdT : « Recherche de rapports de bogues existants »). Nous choisissons cette recherche plutôt que la recherche classique car la recherche classique a tendance à donner des résultats vagues et empêche souvent les utilisateurs de trouver leur bogue à cause d'un grand nombre de résultats de recherche. Une fois que nous avons cliqué sur ce lien, nous obtenons la page suivante :

Figure 5.2 : Page de recherche du Bugzilla

Cliquez sur le lien « Advanced search » (NdT : « Recherche avancée ») pour atteindre la page de recherche avancée.

Figure 5.3 : Page de recherche avancée

Voici comment la page de recherche avancée se présente. Bien que cela puisse s'avérer bouleversant au premier abord, nous allons voir que quelques simples renseignements permettent de réduire quelque peu les résultats vagues que le Bugzilla retourne.

Figure 5.4 : Contenu

Le premier champ est le résumé du bogue. Ici nous allons simplement mettre le nom du paquet qui a planté. Si Bugzilla ne retourne aucun résultat, essayez de retirer le nom du paquet, juste au cas où quelqu'un ne l'aurez pas mis dans le résumé (hautement déconseillé, mais nous avons déjà vu un certain nombre de rapports de bogues étranges).

Les champs « Product  » (NdT : « produit »), « Component » (NdT : « pour la partie ») et « Version  » vont tous être laissés par défaut. Cela nous évite d'être trop précis et de manquer tous les bogues.

La partie « Comment » (NdT : « commentaire ») est la plus importante. Utilisez ce champ pour lister ce qui semble être un cas caractéristique de l'erreur. En gros, n'utilisez pas quelque chose comme le début de l'erreur de compilation, mais trouvez une ligne avant faisant état d'une vraie erreur. Aussi vous pouvez filtrer la ponctuation pour éviter que Bugzilla n'interprète les résultats des commentaires de la mauvaise façon. Voici l'exemple de notre erreur de xclass :

menudef.h:78: error: brace-enclosed initializer used to initialize `OXPopupMenu'
(Enlevez la ponctuation ` ' :.)
menudef.h 78 error brace-enclosed initializer used to initialize OXPopupMenu

L'exemple ci-dessus est assez caractéristique de l'endroit où nous trouverions le bogue sans patauger avec d'autres résultats candidats pour cette erreur de compilation de xclass.

« URI », « Whiteboard » (NdT : « tableau blanc »), et « Keywords » (NdT : « mots clefs ») peuvent être laissés vides. Ce que nous avons mis avant devrait suffir à trouver notre bogue. Jetons un œil à ce que nous avons renseigné.

Figure 5.5 : Formulaire de recherche complété

À présent, cliquons sur le bouton « Search » (NdT : « Rechercher ») et voici les résultats...

Figure 5.6 : Résultats de recherche

Seulement deux bogues ! C'est ainsi beaucoup plus facile de s'en occuper. Cliquons sur le premier pour vérifier et être suffisamment sûr que c'est celui que nous cherchons.

Figure 5.7 : Bogue localisé

Non seulement c'est celui que nous voulons, mais en plus il a déjà été résolu. En vérifiant le dernier commentaire, nous trouvons la solution et savons ce qu'il faut faire pour le résoudre. Maintenant, voyons ce qu'il se serait passé si nous n'avions pas utilisé la recherche avancée.

Figure 5.8 : Résultats de recherche classique

Quatre bogues à inspecter ! Cela aurait été bien pire avec de plus gros paquets. Néanmoins, avec ces simples outils, nous sommes capables de réduire de manière significative le temps de recherche pour essayer de localiser un bogue spécifique.

Conclusion

Disons que vous avez cherché et cherché mais que vous n'avez toujours pas trouvé un bogue correspondant sur le Bugzilla. Alors vous avez trouvé vous-même un nouveau bogue. Nous allons voir le processus de rapport de bogue pour soumettre votre nouveau bogue.

6.  Le rapport de bogues

Introduction

Dans ce chapitre, nous allons voir comment utiliser Bugzilla pour répertorier un nouveau bogue de façon claire. Rendez-vous pour cela sur la page de Gentoo Bugs...

Figure 6.1 : Page d'accueil de Bugzilla

Cliquez sur « Report a Bug - Using the guided format » (NdT : « Rapporter un bogue, utilisation du format guidé »).

Figure 6.2 : Sélection du produit

Comme vous pouvez le voir, l'accent majeur a été mis sur le fait de placer votre bogue au bon endroit. « Gentoo Linux » est l'endroit où la grande majorité des bogues vont trouver leur place.

En dépit de ceci, certaines personnes posteront les bogues d'ebuild dans la partie du développement de Portage (pensant que l'équipe de Portage gère l'arbre de Portage) ou dans « infra » (pensant que l'équipe a accès aux miroirs pouvant ainsi synchroniser et régler le problème directement). Ce n'est simplement pas comme ça que les choses fonctionnent.

Une autre idée reçue et qui est fausse concerne nos bogues de documentation. Par exemple, un utilisateur trouve un bogue avec la documentation de Catalyst. La tendance générale est de répertorier un bogue dans « Docs-user », qui est en fait assigné à l'équipe du GDP, alors qu'il devrait être envoyé à un membre de l'équipe du projet Release Engineering. En général, seule la documentation se trouvant dans http://www.gentoo.org/doc/* appartient à la GDP. Toute documentation se trouvant dans http://www.gentoo.org/proj/* appartient aux équipes respectives.

Notre bogue va dans « Gentoo Linux » car c'est un bogue d'ebuild. Nous nous rendons là-bas et nous nous trouvons face au processus multi-étapes de rapport de bogue. Passons donc à présent à l'étape 1...

Figure 6.3 : Format guidé de l'étape 1

Cette première étape est vraiment très importante (comme vous le montre le texte rouge). C'est l'endroit où vous cherchez pour voir si quelqu'un d'autre n'a pas déjà relevé le même bogue que vous. Si vous zappez cette étape et qu'un bogue comme le vôtre existe, il sera marqué en DUPLICATE gaspillant de ce fait un grand effort de la part des QA. Pour vous donner une idée, les numéros de bogues qui sont barrés ci-dessus concernent des bogues dupliqués. Vient maintenant l'étape 2, où nous renseignons l'information.

Information requise

Figure 6.4 : Informations de base

Jetons un petit coup d'œil à qui est quoi.

• En premier, c'est le produit, « Product ». Le produit va réduire le bogue à un domaine spécifique de Gentoo comme le Bugzilla (pour les bogues en relation avec bugs.gentoo.org), Docs-user (pour la documentation utilisateur) ou Gentoo Linux (pour les ebuilds et semblables).
• La partie (« Component ») est où exactement le problème est apparu, plus précisément dans quelle partie du produit sélectionné le bogue est arrivé. Cela rend la classification plus facile.
• La plate-forme matérielle (« Hardware Platform ») est l'architecture que vous utilisez. Si vous utilisez SPARC, vous devrez mettre SPARC.
• « Operating System », pour système d'exploitation, correspond au système que vous utilisez. Gentoo étant considérée comme une "méta-distribution", elle peut également fonctionner sur des systèmes d'exploitation autres que Linux.

Donc, pour notre exemple de bogue, nous avons :

• Product - Gentoo Linux (puisque c'est un problème d'ebuild)
• Component - Application (c'est une erreur provenant d'une application, foobar2)
• Hardware Platform - All (cette erreur pourrait apparaître sur toutes les architectures)
• Operating System - All (cela pourrait se produire sur tous les types de systèmes)

Figure 6.5 : Informations de base complétées

• La marque de construction (« Build Identifier ») est simplement le nom du navigateur (l'« User Agent ») utilisé pour rapporter le bogue (à des fins de journalisation). Vous pouvez laisser comme tel.
• L'URL est optionnelle et sert à pointer l'information appropriée sur un autre site (un bogue parent sur le Bugzilla, les notes de publications sur la page d'accueil du paquet, etc.). Vous ne devriez jamais utiliser une URL qui mène sur un pastebin pour les messages d'erreurs, les logs, la sortie de emerge --info, les captures d'écran ou les informations similaires. Celles-ci doivent toujours être attachées au bogue.
• Dans le résumé, « Summary », vous devriez mettre la catégorie du paquet, son nom, et son numéro.

Ne pas inclure la catégorie dans le résumé n'est pas vraiment une catastrophe, mais c'est recommandé. Si vous ne mettez pas le nom du paquet, en revanche, nous ne saurons pas sur quoi vous remplissez un rapport de bogue, et nous serons obligés de vous le demander plus tard. Le numéro de version est important pour les personnes cherchant les bogues. Si vingt personnes remplissent des bogues et qu'aucun d'entre eux ne met de numéro de version, comment vont faire les gens qui cherchent si un bogue similaire au leur existe déjà ? Ils vont devoir inspecter chaque bogue individuellement, ce qui n'est pas trop difficile, mais s'il y a, disons, 200 bogues... ce n'est pas aussi facile. Après toutes les informations concernant le paquet, vous devrez écrire une petite description du problème. Ici par exemple :

Figure 6.6 : Résumé

Ces quelques règles simples peuvent simplifier grandement la gestion des bogues. Ensuite viennent les détails. Ici nous renseignons les informations concernant le bogue. Nous allons voir cela avec un exemple :

Figure 6.7 : Détails

À présent, les développeurs savent pourquoi nous avons rapporté ce bogue. Ils peuvent alors essayer de le reproduire. Le champ « Reproducibility » (NdT : « Reproduction ») nous dit à quelle fréquence on a pu reproduire le problème. Dans cet exemple, nous pouvons le reproduire chaque fois simplement en exécutant foobar2. Renseignons cette information.

Figure 6.8 : Reproduction

Nous avons expliqué comment nous avons trouvé le bogue. La prochaine étape consiste à expliquer quels ont été les résultats que nous avons obtenus et ce que nous pensons qu'ils auraient dû être en réalité.

Figure 6.9 : Résultats

Nous pourrions alors fournir des informations supplémentaires. Cela peut être des choses telles que les traces de pile, des morceaux (puisque le journal complet est généralement lourd et pas très utile) des journaux de strace, mais plus important, notre sortie de emerge --info. Voici un exemple.

Figure 6.10 : Informations supplémentaires

Enfin nous désignons la sévérité du bogue. Veuillez passer en revue ceci attentivement. Dans la plupart des cas, il est bon de laisser le choix par défaut et quelqu'un augmentera ou baissera le niveau de criticité pour vous. Toutefois, si vous relevez le niveau de sévérité du bogue, assurez-vous de le renseigner très soigneusement et assurez-vous que vous ne faites pas une erreur. Un aperçu des différents niveaux de criticité est donné ci-dessous.

• Blocker (NdT : « Bloquant ») - Le programme ne veut tout simplement pas s'installer ou représente une entrave majeure au système. Par exemple, un problème de baselayout qui empêche le système de démarrer pourrait être un candidat à cet estampillage.
• Critical (N.D.T: pour « Critique ») - Le programme connaît des pertes de données ou de graves fuites de mémoire durant son exécution. De nouveau, un programme important tel que net-tools échouant durant sa compilation pourrait être étiqueté comme critique. Il ne va pas empêcher le système de démarrer, mais est assez essentiel dans l'utilisation de tous les jours.
• Major (N.D.T: pour « Majeur ») - Le programme plante, mais rien ne cause des dommages sévères à votre système ou ne crée des pertes d'informations.
• Minor (N.D.T: pour « Mineur ») - Votre programme plante ici et là avec des fonctions claires.
• Normal - Le choix par défaut. Si vous n'êtes pas sûr, laissez ceci comme tel à moins que ce soit une nouvelle version, ou un changement d'apparence, dans ce cas regardez ci-dessous pour plus d'informations.
• Trivial - Des choses telles qu'un mot oublié ou pour enlever un espace blanc.
• Enhancement (N.D.T: pour « Amélioration » - Une requête pour activer une nouvelle fonctionnalité dans un programme, ou plus particulièrement des nouveaux ebuilds.

Figure 6.11 : Sévérité

Ici, nous mettons le bogue au niveau Normal.

À présent, nous pouvons soumettre notre rapport de bogue en cliquant sur la boîte « Submit Bug Report » (NdT : « Soumettre un rapport de bogue »). Vous pouvez dès à présent voir votre nouveau bogue. Regardez le Bogue 97561 pour voir à quoi cela ressemble. Nous avons rapporté notre bogue ! Voyons comment cela est traité.

Les requêtes d'estampillage de 0-jour

Plus haut, nous avons vu comment rapporter un bogue. Maintenant nous allons voir ce qu'il ne faut pas faire.

Supposons que vous avez ardemment suivi la planification d'un projet ascendant, et quand vous vérifiez sa page d'accueil, que voyez-vous ? Ils viennent juste de sortir une nouvelle version quelques minutes avant ! La plupart des utilisateurs se précipiteraient immédiatement sur le Bugzilla de Gentoo pour dire que la nouvelle version est disponible : veuillez estampiller la version existante et l'ajouter à Portage, etc. Toutefois, c'est exactement ce que vous ne devez pas faire. Les requêtes de ce genre sont appelées des requêtes d'estampillage de zéro jour (ou des 0-jour), car elles sont faites le même jour que la sortie de la nouvelle version.

Pourquoi devez-vous attendre ? Premièrement, c'est assez impoli d'exiger des développeurs de Gentoo d'abandonner quelque chose qu'ils sont en train de faire juste pour ajouter une nouvelle version qui est sortie quinze minutes avant. Votre demande pourrait être marquée comme INVALID ou LATER, car les développeurs ont plein de problèmes urgents qui les gardent occupés. Deuxièmement, les développeurs sont généralement au courant des sorties de nouvelles versions bien avant les utilisateurs, puisqu'ils doivent suivre la version en amont d'assez près. Ils savent déjà qu'une nouvelle version est en cours. Dans bien des cas, ils ont déjà ouvert un bogue, ou peut-être même l'ont déjà ajouté à Portage comme paquet masqué.

Soyez judicieux quand vous testez et demandez des nouvelles versions de paquets. Cherchez dans Bugzilla avant de poster votre requête d'estampillage : n'y a-t-il pas déjà un bogue ouvert ? Avez-vous synchronisé il y a longtemps ; n'est-ce pas déjà dans Portage ? Le paquet a-t-il bien été libéré par l'équipe en amont ? Un peu de bon sens fera bon chemin, et vous fera apprécier des développeurs qui ont déjà beaucoup à faire. Si cela fait quelques jours que la version est sortie et que vous êtes sûr qu'il n'y a pas d'autres demandes pour celle-ci (et qu'elle n'est pas non plus dans Portage), alors vous pouvez ouvrir un nouveau bogue. Assurez-vous de mentionner qu'il compile et fonctionne bien sur votre architecture. Toute autre information pouvant aider et que vous fournirez sera la bienvenue.

Vous voulez voir la nouvelle version de votre logiciel favori dans Portage ? Répertoriez des bogues intelligents.

7.  S'occuper de votre bogue

En regardant le bogue, nous voyons les informations que nous avons fournies précédemment. Vous noterez que le bogue a été assigné à bug-wranglers@gentoo.org. C'est l'attribution par défaut pour les bogues de la composante Application.

Figure 7.1 : Informations de base d'un nouveau bogue

Les détails que nous avons entrés à propos du bogue sont également disponibles.

Figure 7.2 : Détails du nouveau bogue

Cependant, les mainteneurs de bogues ne vont (généralement) pas corriger nos bogues, donc nous allons les réassigner à quelqu'un qui peut le faire (vous pouvez aussi laisser les mainteneurs de bogues le réassigner pour vous). Pour cela, nous utilisons le fichier metadata.xml du paquet. Vous pouvez normalement le trouver dans /usr/portage/categorie/paquet/metadata.xml. Voici celui que j'ai créé pour foobar2.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<herd>chriswhite</herd>
<maintainer>
<email>chriswhite@gentoo.org</email>
<name>Chris White</name>
</maintainer>
<longdescription lang="en">
Foobar2 is a package that uses a configuration file to display a word.
</longdescription>
</pkgmetadata>

Notez la section « maintainer » (NdT : « mainteneur »). Elle renseigne sur le mainteneur du paquet, qui est moi-même, Chris White, dans ce cas-ci. L'adresse électronique listée est chriswhite@gentoo.org. Nous allons l'utiliser afin de réassigner le bogue à la bonne personne. Pour se faire, cliquez sur la bulle à côté de « Reassign bug to » (NdT : « Réassigner le bogue à »), puis renseignez l'adresse électronique.

Figure 7.3 : Réassignement d'un bogue

Puis cliquez sur le bouton « Commit » (NdT : « Envoyer ») pour appliquer les changements. Le bogue m'a été réassigné. Peu après, vous remarquerez (par email habituellement) que j'ai répondu à votre bogue. J'ai indiqué que j'aimerais voir un journal de strace afin de voir comment le programme essaie d'atteindre son fichier de configuration. Suivez les instructions précédentes sur l'utilisation de strace pour obtenir un journal. Maintenant vous devez le joindre au bogue. Pour ce faire, cliquez sur « Create A New Attachment » (NdT : « Créer une nouvelle pièce jointe »).

Figure 7.4 : Nouvelle pièce jointe

Maintenant, nous devons joindre le journal. Allons-y à grands pas.

• File (NdT : Fichier) - C'est l'emplacement du fichier sur votre machine. Dans cet exemple, l'emplacement de strace.log. Vous pouvez utiliser le bouton « Browse... » (NdT : Parcourir ...) pour sélectionner le fichier, ou entrer le chemin directement dans le champ de texte.
• Description - Une courte ligne, ou quelques mots décrivant la pièce jointe. Nous allons juste entrer « strace.log » ici, puisque c'est suffisamment explicite.
• Content Type (NdT : Type de Contenu) - C'est le type du fichier que nous joignons au bogue.
• Obsoletes (NdT : Obsolètes) - S'il y avait des pièces jointes attachées au bogue avant l'actuel, vous avez une option pour les déclarer obsolètes par les vôtres. Puisque nous n'avons pas de pièces jointes précédemment attachées à ce bogue, nous n'avons pas à nous en occuper.
• Comment (NdT : Commentaire) - Entrez des commentaires qui seront visibles avec cette pièce jointe. Vous pouvez donner des précisions sur celle-ci, si besoin.

Pour le respect du type de contenu, voici quelques détails supplémentaires. Vous pouvez cocher la case « patch » si vous joignez un correctif. Autrement, vous pouvez demander à Bugzilla d'auto-détecter le type de fichier (non recommandé). Les autres options sont dans « select from list » (NdT : sélectionner depuis une liste), qui est le plus fréquemment utilisé. Utiliser le texte simple (text/plain) pour la plupart des pièces jointes sauf pour les fichiers binaires comme les images (qui peuvent utiliser image/gif, image/jpeg ou image/png selon leur type) ou les fichiers compressés comme .tar.bz2 qui utiliseraient application/octet-stream comme type de fichier.

Figure 7.5 : Nouvelle pièce jointe complétée

Nous envoyons strace.log qui va être appliqué au rapport de bogue.

Figure 7.6 : strace log attaché

Nous avons mentionné auparavant que les ebuilds vont parfois nécessiter que vous joignez un fichier avec l'erreur d'emerge. Voici un exemple ci-dessous.

configure: error: PNG support requires ZLIB. Use --with-zlib-dir=<DIR>

!!! Please attach the config.log to your bug report:
!!! /var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/config.log

!!! ERROR: dev-php/php-5.0.3-r1 failed.
!!! Function econf, Line 485, Exitcode 0
!!! econf failed
!!! If you need support, post the topmost build error, NOT this status message.

Veuillez s'il-vous-plaît joindre tout fichier demandé comme ceci à votre rapport de bogue.

Parfois un développeur peut vous demander de joindre un fichier diff ou un correctif pour un fichier. Les fichiers diff standards peuvent être obtenus de la façon suivante :

$ cp fichier fichier.old
$ nano fichier
$ diff -u fichier.old fichier

Pour les fichiers source C/C++, l'option -p est ajoutée pour montrer à quels appels de fonction s'applique le fichier diff :

$ cp fichier.c fichier.c.old
$ nano fichier.c
$ diff -up fichier.c.old fichier.c

L'équipe de documentation demandera la combinaison d'options -Nt ainsi que -u. C'est surtout en rapport avec les espaces des tabulations. Vous pouvez créer un tel fichier diff avec :

$ cp fichier.xml fichier.xml.old
$ nano fichier.xml
$ diff -Nut fichier.xml.old fichier.xml

Votre fichier diff est ainsi créé. Pendant que nous faisons tout ça, supposez qu'une autre personne trouve votre bogue en cherchant sur le Bugzilla et est curieuse de garder sa trace, elle peut le faire en ajoutant son adresse email au champ CC du bogue comme montré ci-dessous. Vous pouvez également suivre la trace d'autres bogues de la même façon.

Figure 7.7 : Ajouter un email au CC

Après tout ce travail, le bogue peut passer par divers états. C'est généralement fait par les développeurs Gentoo et parfois par le rapporteur. Les valeurs suivantes sont les divers états possibles qu'un bogue peut avoir durant sa vie.

• UNCONFIRMED (NdT : Non confirmé) - Vous ne le rencontrerez généralement pas souvent. Cela signifie qu'un rapporteur de bogue en a ouvert un en utilisant la méthode avancée et n'est pas certain que c'en est vraiment un.
• NEW (NdT : Nouveau) - Les bogues ouverts pour la première fois sont considérés comme nouveaux.
• ASSIGNED (NdT : Assigné) - Quand la personne à qui vous avez assigné votre bogue le valide, il va généralement recevoir le statut ASSIGNED le temps que les développeurs trouvent le problème. Ceci vous permet de savoir que votre bogue a été accepté comme un vrai bogue.
• REOPENED (NdT : Ré-ouvert) - Quelqu'un a résolu le bogue et vous pensez que la solution n'est pas faisable ou que le problème persiste. À ce moment-là, vous pouvez ré-ouvrir le bogue. N'en abusez pas s'il-vous-plaît. Si un développeur ferme un bogue une seconde ou troisième fois, il y a de grandes chances pour que votre bogue soit fermé.
• RESOLVED (NdT : Résolu) - Une décision a été prise au sujet du bogue. Ceci aboutit généralement au statut FIXED (NdT : corrigé) pour indiquer que le bogue est résolu et que le sujet est clos même si d'autres résolutions sont possibles. Nous allons y regarder en détail peu après.
• VERIFIED (NdT : Vérifié) - Les étapes de travail du bogue sont correctes. C'est généralement une histoire d'assurance qualité.
• CLOSED (NdT : Fermé) - Signifie simplement la fermeture du bogue qui est enterré sous le flux sans fin des nouveaux bogues.

Maintenant ci-dessous, nous trouvons l'erreur dans le journal de strace, corrigeons le bogue, le marquons comme RESOLVED FIXED, mentionnons qu'il y a eu un changement de l'emplacement des fichiers de configuration, et mettons à jour l'ebuild avec un avertissement à ce propos. Le bogue est alors résolu, et il vous est affiché ceci :

Figure 7.8 : Bogue résolu

Un peu en dessous, vous allez voir ceci :

Figure 7.9 : Options du bogue

Cela vous donne la possibilité de ré-ouvrir le bogue si vous le souhaitez (par exemple le développeur pense que c'est résolu mais ce n'est vraiment pas selon vos standards). Maintenant notre bogue est corrigé ! Cependant, différentes résolutions peuvent arriver. En voici une courte liste :

• FIXED (NdT : Corrigé) - Le bogue est corrigé, suivez les instructions pour résoudre le problème.
• INVALID (NdT : Invalide) - Vous n'avez pas fait quelque chose de spécialement documenté, causant le bogue.
• DUPLICATE (NdT : Dupliqué) - Vous n'avez pas utilisé ce guide et avez rapporté un bogue dupliqué.
• WORKSFORME (NdT : Fonctionne pour moi) - Le développeur ou la personne assigné au bogue ne peut pas reproduire votre erreur.
• CANTFIX (NdT : Non corrigeable) - Le bogue ne peut pas être résolu à cause de certaines circonstances. Celles-ci seront notées par la personne prenant en charge le bogue.
• WONTFIX (NdT : Ne sera pas corrigé) - C'est souvent appliqué aux nouveaux ebuilds ou aux demandes de nouvelles fonctionnalités. Le développeur ne veut simplement pas ajouter une certaine fonctionnalité parce que ce n'est pas nécessaire, qu'une meilleure alternative existe, ou que ça ne fonctionne pas. Il vous sera parfois donné une solution pour considérer le problème résolu.
• UPSTREAM (NdT : En amont) - Le bogue ne peut pas être corrigé par l'équipe de développement de Gentoo, et ils vous demandent de signaler le problème en amont (les personnes ayant fait le programme) pour une révision. Ils ont quelques moyens pour la gestion des bogues. Ceux-ci inclus les listes de mails, les canaux IRC, et aussi des systèmes de rapport de bogue. Si vous n'êtes pas sûr de la manière de les contacter, demandez dans le bogue et quelqu'un vous donnera la direction à suivre.

Parfois, avant qu'un bogue soit résolu, un développeur peut vous demander de tester un ebuild mis à jour. Dans le chapitre suivant, nous allons voir comment faire cela.

8.  Test des ebuilds

Récupérer les fichiers

Disons que vous avez rapporté un bogue pour la correction de l'erreur de compilation de foobar2 obtenue auparavant. À présent, les développeurs peuvent chercher quel est le problème et peuvent avoir besoin que vous testiez l'ebuild pour eux afin d'être sûr que celui-ci fonctionne également pour vous :

Figure 8.1 : Demande de test d'ebuild

Plusieurs termes de vocabulaire plutôt confus sont utilisés ici. Tout d'abord, voyons ce qu'est un « overlay » (NdT : ici, « surcouche »). Une surcouche est un répertoire spécial, comme /usr/portage, à la différence près que quand vous faites un emerge sync, les fichiers contenus à l'intérieur de celui-ci ne sont pas effacés. Heureusement, un répertoire spécial /usr/local/portage est créé dans ce but. Nous allons donc indiquer notre surcouche de Portage dans le fichier /etc/make.conf. Pour cela, ouvrez le fichier avec votre éditeur favori et ajoutez ceci vers la fin.

PORTDIR_OVERLAY="/usr/local/portage"

Maintenant nous pouvons créer les répertoires appropriés pour mettre les fichiers de notre ebuild à tester. Dans le cas présent, nous sommes supposés les mettre dans le répertoire sys-apps/foobar2. Vous remarquerez que le second commentaire recommande un répertoire files pour le correctif. Le répertoire files contient les fichiers requis qui ne sont pas inclus dans l'archive standard des sources (correctifs, scripts init.d...). Il s'agit d'un sous-répertoire dans le répertoire du paquet, qui est appelé « files ». Nous allons donc créer ces répertoires.

# mkdir -p /usr/local/portage/sys-apps/foobar2/files

Ok à présent, nous allons pouvoir récupérer les fichiers. D'abord, téléchargez l'ebuild dans /usr/local/portage/sys-apps/foobar2, et ajoutez alors le correctif (NdT : « patch ») dans /usr/local/portage/sys-apps/foobar2/files. Maintenant que vous avons les fichiers, nous pouvons commencer à tester l'ebuild.

Test de l'ebuild

Le processus pour créer un ebuild qui peut être utilisé par emerge est assez simple. Vous devez créer un fichier Manifest pour l'ebuild, grâce à la commande ebuild. Exécutez cette commande comme ceci :

# ebuild foobar2-1.0.ebuild manifest
>>> Creating Manifest for /usr/local/portage/sys-apps/foobar2

À présent, essayons de voir si cela marche comme prévu.

# emerge -pv foobar2

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N    ] sys-apps/foobar2-1.0  0 kB [1]

Total size of downloads: 0 kB
Portage overlays:
 [1] /usr/local/portage

Cela semble avoir fonctionné ! Vous pourrez remarquer le [1] à côté de la ligne [ebuild]. Cela pointe vers /usr/local/portage, qui est la surcouche que vous avons créée auparavant. Maintenant allons-y et installons le paquet.

# emerge foobar2
 Calculating dependencies ...done!
(Informations de compilation coupées)
>>> Unpacking foobar2-1.0.tar.bz2 to /var/tmp/portage/foobar2-1.0/work
 * Applying foobar2-1.0-Makefile.patch ...                                    [ ok ]
(Informations de compilation coupées)
>>> Merging sys-apps/foobar2-1.0 to /
>>> chris +sandbox(preinst)
--- /usr/
--- /usr/bin/
>>> /usr/bin/foobar2

Dans la première section nous voyons que la commande emerge a commencé comme il fallait. La seconde section montre que notre correctif a été appliqué avec succès grâce au message de statut [ ok ] sur la droite. La dernière section nous informe que la compilation du programme est réussie. Le correctif fonctionne ! Nous pouvons donc prévenir les développeurs que leur correctif fonctionne correctement, et qu'ils peuvent l'envoyer dans l'arbre Portage.

Conclusion

Ceci conclut la documentation sur le fonctionnement du Bugzilla. J'espère que vous l'aurez trouvée utile. Si vous avez des questions, des commentaires ou des idées à propos de ce document, veuillez me les envoyer à Chris White. Remerciements particuliers à moreon pour ses notes au sujet des options -g et des erreurs de compilations, aux personnes de #gentoo-bugs pour leur aide sur les querelles de bogues, à Griffon26 pour ses notes sur les indispensables mainteneurs, à robbat2 pour les suggestions d'ordre général et à fox2mike pour la correction de ce document et l'ajout des choses nécessaires.

Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5.