Get Gentoo!
gentoo.org sites
gentoo.org Wiki Bugs Forums Packages
Planet Archives Sources
Infra Status

Gentoo Archives: gentoo-commits

From: "Marion Age (titefleur)" <titefleur@g.o>
To: gentoo-commits@l.g.o
Subject: [gentoo-commits] gentoo commit in xml/htdocs/doc/fr: bugzilla-howto.xml
Date: Sun, 28 Oct 2007 00:49:25
Message-Id: E1IlwL5-0007GS-3e@stork.gentoo.org
1 titefleur 07/10/28 00:49:15
2
3 Added: bugzilla-howto.xml
4 Log:
5 New translation: bugzilla-howto.xml
6
7 Revision Changes Path
8 1.1 xml/htdocs/doc/fr/bugzilla-howto.xml
9
10 file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/fr/bugzilla-howto.xml?rev=1.1&view=markup
11 plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/fr/bugzilla-howto.xml?rev=1.1&content-type=text/plain
12
13 Index: bugzilla-howto.xml
14 ===================================================================
15 <?xml version="1.0" encoding="UTF-8"?>
16 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
17 <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/fr/bugzilla-howto.xml,v 1.1 2007/10/28 00:49:14 titefleur Exp $ -->
18
19 <guide link="/doc/fr/bugzilla-howto.xml">
20 <title>Guide de rapport de bogue de Gentoo</title>
21
22 <author title="Auteur">
23 <mail link="chriswhite@g.o">Chris White</mail>
24 </author>
25 <author title="Correcteur">
26 <mail link="fox2mike@g.o">Shyam Mani</mail>
27 </author>
28 <author title="Traducteur">
29 <mail link="titefleur@g.o">Marion Agé</mail>
30 </author>
31 <author title="Traducteur">
32 <mail link="geekounet@×××××.com">Pierre Guinoiseau</mail>
33 </author>
34
35 <abstract>
36 Ce document montre de quelle manière se fait le rapport de bogues avec le
37 Bugzilla.
38 </abstract>
39
40 <!-- The content of this document is licensed under the CC-BY-SA license -->
41 <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
42 <license/>
43
44 <version>1.9</version>
45 <date>2007-04-01</date>
46
47 <chapter>
48 <title>Introduction</title>
49 <section>
50 <title>Préface</title>
51 <body>
52
53 <p>
54 L'un des facteurs qui fait qu'un bogue tarde à être corrigé réside dans la
55 manière dont il est rapporté. En créant ce guide, nous espérons aider à
56 améliorer la communication entre les développeurs et les utilisateurs en ce qui
57 concerne la résolution de bogues. La correction de bogues constitue une part
58 importante sinon cruciale de l'assurance de qualité quelque soit le projet alors
59 espérons que ce guide aidera à y contribuer.
60 </p>
61
62 </body>
63 </section>
64 <section>
65 <title>Bogues&nbsp;!!!!</title>
66 <body>
67
68 <p>
69 Vous êtes en train d'installer un paquet ou de travailler avec un programme
70 quand soudainement, le pire arrive&nbsp;: vous trouvez un bogue. Les bogues
71 surviennent de différentes manières, il y a par exemple les erreurs qui se
72 produisent lors de la commande <c>emerge</c> ou les erreurs de segmentation.
73 Quelqu'en soit la cause, le fait est qu'un tel bogue doit être corrigé. Voici
74 quelques exemples de ce genre de bogues.
75 </p>
76
77 <pre caption="Une erreur d'exécution">
78 $ <i>./bad_code `perl -e 'print Ax100'`</i>
79 Segmentation fault
80 </pre>
81
82 <pre caption="Un échec de la part d'emerge">
83 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3/backward/backward_warning.h:32:2:
84 warning: #warning This file includes at least one deprecated or antiquated
85 header. Please consider using one of the 32 headers found in section 17.4.1.2 of
86 the C++ standard. Examples include substituting the &lt;X&gt; header for the &lt;X.h&gt;
87 header for C++ includes, or &lt;sstream&gt; instead of the deprecated header
88 &lt;strstream.h&gt;. To disable this warning use -Wno-deprecated.
89 In file included from main.cc:40:
90 menudef.h:55: error: brace-enclosed initializer used to initialize `
91 OXPopupMenu*'
92 menudef.h:62: error: brace-enclosed initializer used to initialize `
93 OXPopupMenu*'
94 menudef.h:70: error: brace-enclosed initializer used to initialize `
95 OXPopupMenu*'
96 menudef.h:78: error: brace-enclosed initializer used to initialize `
97 OXPopupMenu*'
98 main.cc: In member function `void OXMain::DoOpen()':
99 main.cc:323: warning: unused variable `FILE*fp'
100 main.cc: In member function `void OXMain::DoSave(char*)':
101 main.cc:337: warning: unused variable `FILE*fp'
102 make[1]: *** [main.o] Error 1
103 make[1]: Leaving directory
104 `/var/tmp/portage/xclass-0.7.4/work/xclass-0.7.4/example-app'
105 make: *** [shared] Error 2
106
107 !!! ERROR: x11-libs/xclass-0.7.4 failed.
108 !!! Function src_compile, Line 29, Exitcode 2
109 !!! 'emake shared' failed
110 </pre>
111
112 <p>
113 Ces erreurs peuvent être très gênantes. Toutefois, une fois que vous les avez
114 décelées, que devez-vous faire&nbsp;? Les sections suivantes vont présenter deux
115 outils importants dans la gestion des erreurs d'exécution. Après cela, nous
116 jetterons un œil aux erreurs de compilation et à la manière de les traiter.
117 Commençons dès à présent avec le premier outil de débogage pour les erreurs
118 d'exécution, <c>GDB</c>.
119 </p>
120
121 </body>
122 </section>
123 </chapter>
124
125 <chapter>
126 <title>Débogage grâce à GDB</title>
127 <section>
128 <title>Introduction</title>
129 <body>
130
131 <p>
132 GDB, pour le (G)NU (D)e(B)ugger, est un programme utilisé pour trouver les
133 erreurs d'exécution qui impliquent généralement une corruption de la mémoire.
134 Tout d'abord, jetons un œil à ce qui permet le débogage. L'une des principales
135 choses que vous devez faire afin de déboguer un programme est d'installer le
136 programme avec <c>FEATURES="nostrip"</c>. Cela évite la suppression des symboles
137 de débogage. Pourquoi les programmes sont-ils privés de ceux-ci par
138 défaut&nbsp;? La raison est la même que celle pour laquelle les pages du manuel
139 sont compressées avec gzip&nbsp;: l'économie de place. Voici la façon dont varie
140 la taille d'un programme avec et sans la suppression des symboles de débogage.
141 </p>
142
143 <pre caption="Comparaison de la taille des fichiers">
144 <comment>(symboles de débogage supprimés)</comment>
145 -rwxr-xr-x 1 chris users 3140 6/28 13:11 bad_code
146 <comment>(symboles de débogage intacts)</comment>
147 -rwxr-xr-x 1 chris users 6374 6/28 13:10 bad_code
148 </pre>
149
150 <p>
151 Juste pour indication, <e>bad_code</e> est le programme que nous allons déboguer
152 avec <c>GDB</c> plus tard. Comme vous pouvez le voir, le programme privé des
153 symboles de débogage ne pèse que 3140 bytes, tandis que le même programme avec
154 ces symboles en pèse 6374, soit près du double&nbsp;! Deux autres choses peuvent
155 être faites pour aider au débogage. La première est d'ajouter ggdb3 dans votre
156 CFLAGS et dans votre CXXFLAGS. Cette variable ajoute plus d'informations de
157 débogage que la normale. Nous verrons ce que cela signifie plus tard. Voici ce à
158 quoi <e>pourrait</e> ressembler votre fichier <path>/etc/make.conf</path> après
159 l'ajout de ces nouvelles variables.
160 </p>
161
162 <pre caption="Paramètres du make.conf">
163 CFLAGS="-O1 -pipe -g -ggdb"
164 CXXFLAGS="${CFLAGS}"
165 </pre>
166
167 <p>
168 Enfin, vous pouvez ajouter l'option debug de la variable USE à vos paquets, par
169 l'intermédiaire du fichier <path>package.use</path>.
170 </p>
171
172 <pre caption="Ajout de l'option debug de la variable USE dans le fichier
173 package.use">
174 # <i>echo "catégorie/paquet debug" >> /etc/portage/package.use</i>
175 </pre>
176
177 <note>
178 Le répertoire <path>/etc/portage</path> n'existe pas par défaut, vous devrez le
179 créer, si vous ne l'avez pas déjà fait. Si le paquet possède déjà des variables
180 USE indiquées dans le fichier <path>package.use</path>, vous devrez les modifier
181 manuellement à l'aide de l'éditeur de votre choix.
182 </note>
183
184 <p>
185 Ensuite, nous allons réinstaller le paquet avec les modifications faites plus
186 haut comme montré ci-dessous.
187 </p>
188
189 <pre caption="Réinstallation d'un paquet avec le débogage">
190 # <i>FEATURES="nostrip" emerge paquet</i>
191 </pre>
192
193 <p>
194 Maintenant que les symboles de débogage sont mis, nous pouvons continuer avec le
195 débogage du programme.
196 </p>
197
198 </body>
199 </section>
200 <section>
201 <title>Exécution du programme avec GDB</title>
202 <body>
203
204 <p>
205 Disons que nous avons un programme appelé ici «&nbsp;bad_code&nbsp;». Quelqu'un
206 a affirmé que le programme plantait et a fourni un exemple. Vous allez tester sa
207 sortie.
208 </p>
209
210 <pre caption="Corruption du programme">
211 $ <i>./bad_code `perl -e 'print Ax100'`</i>
212 Segmentation fault
213 </pre>
214
215 <p>
216 Il semble que cette personne avait raison. Puisque le programme est
217 effectivement corrompu, nous avons un bogue sous la main. À présent, il est
218 temps d'utiliser <c>GDB</c> pour aider à résoudre ce problème. Tout d'abord nous
219 lançons <c>GDB</c> avec <c>--args</c> suivi du programme complet avec ses
220 arguments comme voici&nbsp;:
221 </p>
222
223 <pre caption="Exécution de notre programme dans GDB">
224 $ <i>gdb --args ./bad_code `perl -e 'print Ax100'`</i>
225 GNU gdb 6.3
226 Copyright 2004 Free Software Foundation, Inc.
227 GDB is free software, covered by the GNU General Public License, and you are
228 welcome to change it and/or distribute copies of it under certain conditions.
229 Type "show copying" to see the conditions.
230 There is absolutely no warranty for GDB. Type "show warranty" for details.
231 This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
232 </pre>
233
234 <note>
235 On peut également déboguer avec des sauvegardes d'image mémoire (NdT&nbsp;:
236 «&nbsp;core dumps&nbsp;»). Ces fichiers du noyau contiennent les mêmes
237 informations que ce que le programme produirait en l'exécutant avec GDB. Pour
238 déboguer notre programme bad_code avec un tel fichier, vous devez exécuter
239 <c>gdb ./bad_code core</c> où «&nbsp;core&nbsp;» est le nom du fichier de
240 sauvegarde.
241 </note>
242
243 <p>
244 Vous devriez voir une invite de commande indiquant «&nbsp;(gdb))&nbsp;» et
245 attendant une saisie clavier. D'abord, nous devons exécuter le programme. En
246 écrivant <c>run</c> sur la ligne de commande nous obtenons une information telle
247 que celle-ci&nbsp;:
248 </p>
249
250 <pre caption="Exécution du programme dans GDB">
251 (gdb) <i>run</i>
252 Starting program: /home/chris/bad_code
253
254 Program received signal SIGSEGV, Segmentation fault.
255 0xb7ec6dc0 in strcpy () from /lib/libc.so.6
256 </pre>
257
258 <p>
259 Ici nous pouvons voir le programme démarrer ainsi qu'une notification de
260 SIGSEGV, c'est-à-dire une erreur de segmentation. C'est GDB qui nous dit que
261 notre programme a planté. Il nous donne également la dernière fonction exécutée
262 qu'il a pu remonter quand le programme a planté. Toutefois, ceci n'est pas très
263 utile puisqu'il peut y avoir de nombreux «&nbsp;strcpy&nbsp;» dans le programme,
264 rendant difficile pour les développeurs de déceler celui qui cause ce problème.
265 Afin de les aider, nous allons faire ce qu'on appelle un traçage (NdT&nbsp;:
266 «&nbsp;backtrace&nbsp;»). Un traçage exécute à l'envers toutes les fonctions qui
267 existent dès l'exécution du programme jusqu'à la fonction qui produit la faute.
268 Les fonctions qui retournent quelque chose (sans causer de plantage) ne seront
269 pas montrées dans le traçage. Pour obtenir un traçage, sur l'invite de commande
270 (gdb), écrivez <c>bt</c>. Vous obtiendrez quelque chose comme ceci&nbsp;:
271 </p>
272
273 <pre caption="Traçage du programme">
274 (gdb) <i>bt</i>
275 #0 0xb7ec6dc0 in strcpy () from /lib/libc.so.6
276 #1 0x0804838c in run_it ()
277 #2 0x080483ba in main ()
278 </pre>
279
280 <p>
281 Vous pouvez remarquer clairement la trace du patron. La fonction main() est
282 appelée en premier, suivie de la fonction run_it(), et quelque part dans
283 run_it() se trouve le strcpy() qui commet la faute. De telles informations
284 aident les développeurs à réduire les problèmes. Il y a des cas où vous
285 n'obtiendrez pas cette sortie. Le premier se produit si vous oubliez d'activer
286 les symboles de débogage avec <c>FEATURES="nostrip"</c>. Si les symboles sont
287 supprimés, la sortie ressemblera plutôt à quelque chose comme cela&nbsp;:
288 </p>
289
290 <pre caption="Traçage du programme sans les symboles de débogage">
291 (gdb) <i>bt</i>
292 #0 0xb7e2cdc0 in strcpy () from /lib/libc.so.6
293 #1 0x0804838c in ?? ()
294 #2 0xbfd19510 in ?? ()
295 #3 0x00000000 in ?? ()
296 #4 0x00000000 in ?? ()
297 #5 0xb7eef148 in libgcc_s_personality () from /lib/libc.so.6
298 #6 0x080482ed in ?? ()
299 #7 0x080495b0 in ?? ()
300 #8 0xbfd19528 in ?? ()
301 #9 0xb7dd73b8 in __guard_setup () from /lib/libc.so.6
302 #10 0xb7dd742d in __guard_setup () from /lib/libc.so.6
303 #11 0x00000006 in ?? ()
304 #12 0xbfd19548 in ?? ()
305 #13 0x080483ba in ?? ()
306 #14 0x00000000 in ?? ()
307 #15 0x00000000 in ?? ()
308 #16 0xb7deebcc in __new_exitfn () from /lib/libc.so.6
309 #17 0x00000000 in ?? ()
310 #18 0xbfd19560 in ?? ()
311 #19 0xb7ef017c in nullserv () from /lib/libc.so.6
312 #20 0xb7dd6f37 in __libc_start_main () from /lib/libc.so.6
313 #21 0x00000001 in ?? ()
314 #22 0xbfd195d4 in ?? ()
315 #23 0xbfd195dc in ?? ()
316 #24 0x08048201 in ?? ()
317 </pre>
318
319 <p>
320 Ce traçage contient un grand nombre de marques «&nbsp;??&nbsp;». Cela est dû au
321 fait que <c>GDB</c> ne connaît pas la façon dont le programme a été exécuté
322 puisqu'il n'y a pas de symboles de débogage. Il est donc crucial de ne
323 <e>pas</e> supprimer ces symboles. À présent, rappelez-vous qu'au-dessus nous
324 avions mentionné l'existence d'une option -ggdb. Voyons à quoi ressemble la
325 sortie si celle-ci est active&nbsp;:
326 </p>
327
328 <pre caption="Traçage du programme avec -ggdb3">
329 (gdb) <i>bt</i>
330 #0 0xb7e4bdc0 in strcpy () from /lib/libc.so.6
331 #1 0x0804838c in run_it (input=0x0) at bad_code.c:7
332 #2 0x080483ba in main (argc=1, argv=0xbfd3a434) at bad_code.c:12
333 </pre>
334
335 <p>
336 Nous pouvons voir que beaucoup plus d'informations sont disponibles pour les
337 développeurs. Non seulement le nom de la fonction est affiché, mais il y a
338 également les numéros de lignes exacts dans la source des fichiers. Cette
339 méthode est celle qui est préférée si vous pouvez libérer un peu d'espace
340 supplémentaire. Voici comment varie la taille des fichiers avec la présence des
341 symboles de débogage, sans ces symboles, et avec l'activation de l'option -ggdb.
342 </p>
343
344 <pre caption="Différences avec l'option -ggdb">
345 <comment>(symboles de débogage supprimés)</comment>
346 -rwxr-xr-x 1 chris users 3140 6/28 13:11 bad_code
347 <comment>(symboles de débogage intacts)</comment>
348 -rwxr-xr-x 1 chris users 6374 6/28 13:10 bad_code
349 <comment>(variable -ggdb active)</comment>
350 -rwxr-xr-x 1 chris users 19552 6/28 13:11 bad_code
351 </pre>
352
353 <p>
354 Comme vous pouvez le remarquer, -ggdb ajoute environ <e>13178</e> octets de plus
355 à la taille du fichier par rapport à celui qui contient les symboles de
356 débogage. Toutefois, comme nous l'avons vu, ce poids supplémentaire peut valoir
357 le coup pour présenter les informations de débogage aux développeurs. Le traçage
358 peut être sauvegardé dans un fichier en copiant et collant depuis le terminal
359 (si c'est un terminal qui n'utilise pas le serveur X, vous pouvez utiliser GPM.
360 Afin de garder cette documentation simple, je vous recommande de lire la
361 <uri link="/doc/fr/gpm.xml#doc_chap4">documentation pour GPM</uri> pour voir
362 comment copier et coller avec). Maintenant que nous avons fait ce que nous
363 devions avec <c>GDB</c>, nous pouvons en sortir.
364 </p>
365
366 <pre caption="Quitter GDB">
367 (gdb) <i>quit</i>
368 The program is running. Exit anyway? (y or n) <i>y</i>
369 $
370 </pre>
371
372 <p>
373 Ceci clôt la découverte de <c>GDB</c>. En utilisant <c>GDB</c>, nous espérons
374 que vous serez en mesure de l'utiliser pour créer de meilleurs rapports de
375 bogue. Toutefois, il y a d'autres types d'erreurs qui peuvent causer
376 l'interruption d'un programme durant son exécution. L'un des autres cas peut
377 être une erreur d'accès à un fichier. Nous pouvons les retrouver en utilisant un
378 petit outil bien chouette du nom de <c>strace</c>.
379 </p>
380
381 </body>
382 </section>
383 </chapter>
384
385 <chapter>
386 <title>Utiliser strace pour chercher les erreurs d'accès aux fichiers</title>
387 <section>
388 <title>Introduction</title>
389 <body>
390
391 <p>
392 Les programmes utilisent souvent des fichiers pour récupérer des informations de
393 configuration, accéder au matériel ou écrire des journaux. Parfois, un programme
394 tente d'accéder à de tels fichiers de manière incorrecte. Un outil nommé
395 <c>strace</c> a été créé afin de faciliter leur détection. <c>strace</c> trace
396 les appels systèmes (d'où le nom), ce qui implique les appels qui utilisent la
397 mémoire et les fichiers. Pour notre exemple, nous allons prendre un programme
398 nommé foobar2, qui est une version mise à jour de foobar. Cependant, durant la
399 transition vers foobar2, vous vous apercevez que tous les fichiers de
400 configuration sont manquants&nbsp;! Vous aviez configuré la première version de
401 foobar pour qu'elle affiche «&nbsp;foo&nbsp;», mais maintenant elle affiche la
402 valeur par défaut «&nbsp;bar&nbsp;».
403 </p>
404
405 <pre caption="Foobar2 avec une configuration invalide">
406 $ <i>./foobar2</i>
407 La configuration dit: bar
408 </pre>
409
410 <p>
411 Notre configuration précédente était spécialement définie à «&nbsp;foo&nbsp;»,
412 utilisons donc <c>strace</c> pour savoir ce qui se passe.
413 </p>
414
415 </body>
416 </section>
417 <section>
418 <title>Utiliser strace pour chercher le problème</title>
419 <body>
420
421 <p>
422 Nous utilisons <c>strace</c> pour enregistrer les résultats des appels systèmes.
423 Pour cela, nous lançons <c>strace</c> avec l'argument -o[fichier]. Utilisons-le
424 sur foobar2 comme suit&nbsp;:
425 </p>
426
427 <pre caption="Lancer foobar2 avec strace">
428 # <i>strace -ostrace.log ./foobar2</i>
429 </pre>
430
431 <p>
432 Cela crée un fichier nommé <path>strace.log</path> dans le répertoire courant.
433 Nous vérifions le fichier, et en voici ci-dessous la partie intéressante&nbsp;:
434 </p>
435
436 <pre caption="Un coup d'œil au journal de strace">
437 open(".foobar2/config", O_RDONLY) = 3
438 read(3, "bar", 3) = 3
439 </pre>
440
441 <p>
442 Aha! Voilà donc le problème. Quelqu'un a changé l'emplacement du répertoire de
443 configuration vers <path>.foobar2</path> au lieu de <path>.foobar</path>. Nous
444 voyons également que le programme lit &nbsp;bar&nbsp;» comme prévu. Dans ce
445 cas-ci, nous recommandons au mainteneur de l'ebuild d'ajouter un avertissement à
446 ce propos. Pour le moment toutefois, nous pouvons remplacer le fichier de
447 configuration avec celui du répertoire <path>.foobar</path> et le modifier afin
448 d'obtenir le résultat correct.
449 </p>
450
451 </body>
452 </section>
453 <section>
454 <title>Conclusion</title>
455 <body>
456
457 <p>
458 Nous nous sommes donc occupés de rechercher les bogues d'exécution du programme.
459 Ces bogues sont souvent problématiques lorsque vous essayez et lancez vos
460 programmes. Cependant, ces erreurs d'exécution s'avèrent sans grande importance
461 lorsque votre programme ne compile pas du tout. Intéressons-nous donc à la
462 manière d'aborder les erreurs de compilation d'<c>emerge</c>.
463 </p>
464
465 </body>
466 </section>
467 </chapter>
468
469 <chapter>
470 <title>Gérer les erreurs d'emerge</title>
471 <section>
472 <title>Introduction</title>
473 <body>
474
475 <p>
476 Les erreurs d'<c>emerge</c>, comme celle affichée précédemment, peuvent être une
477 cause majeure de frustration pour les utilisateurs. Leur signalisation est donc
478 considérée commme cruciale pour garantir la santé de Gentoo. Prenons pour
479 exemple un ebuild, foobar2, qui contient des erreurs de compilation.
480 </p>
481
482 </body>
483 </section>
484 <section id="emerge_error">
485 <title>Évaluer les erreurs d'emerge</title>
486 <body>
487
488 <p>
489 Intéressons-nous à cette très simple erreur d'<c>emerge</c>&nbsp;:
490 </p>
491
492 <pre caption="Erreur d'emerge">
493 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
494 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
495 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
496 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
497 foobar2.c:1:17: ogg.h: Aucun fichier ou répertoire de ce type
498 make: *** [foobar2.o] Error 1
499
500 !!! ERROR: sys-apps/foobar2-1.0 failed.
501 !!! Function src_compile, Line 19, Exitcode 2
502 !!! Make failed!
503 !!! If you need support, post the topmost build error, NOT this status message
504 </pre>
505
506 <p>
507 La compilation du programme se déroule très bien jusqu'à ce qu'elle s'arrête et
508 affiche un message d'erreur. Cette erreur particulière peut se décomposer en
509 trois parties&nbsp;: les messages de compilation, l'erreur de construction et le
510 message d'erreur d'<c>emerge</c> comme montré ci-dessous.
511 </p>
512
513 <pre caption="Parties de l'erreur">
514 <comment>(Les messages de compilation)</comment>
515 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
516 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
517 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
518 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
519
520 <comment>(L'erreur de construction)</comment>
521 foobar2.c:1:17: ogg.h: Aucun fichier ou répertoire de ce type
522 make: *** [foobar2.o] Error 1
523
524 <comment>(L'erreur d'emerge)</comment>
525 !!! ERROR: sys-apps/foobar2-1.0 failed.
526 !!! Function src_compile, Line 19, Exitcode 2
527 !!! Make failed!
528 !!! If you need support, post the topmost build error, NOT this status message
529 </pre>
530
531 <p>
532 Ce sont les messages de compilation qui amènent à l'erreur. Le plus souvent, il
533 est préférable d'inclure au moins dix lignes d'informations de compilation afin
534 que le développeur sache où la compilation en était quand l'erreur est arrivée.
535 </p>
536
537 <p>
538 Les erreurs de <c>make</c> sont de véritables erreurs et fournissent les
539 informations dont le développeur a besoin. Quand vous voyez «&nbsp;make:
540 ***&nbsp;», il s'agit souvent de l'endroit où l'erreur est arrivée.
541 Normalement, vous pouvez copier et coller les dix lignes précédentes et le
542 développeur sera capable d'identifier le problème. Cependant, il se peut que ça
543 ne fonctionne pas et nous allons voir une alternative peu après.
544 </p>
545
546 <p>
547 L'erreur d'<c>emerge</c> est ce que la commande renvoie comme une erreur.
548 Parfois, elle peut contenir aussi des informations importantes. Souvent, les
549 gens font l'erreur de ne poster que l'erreur d'<c>emerge</c> et rien d'autre.
550 Elle est inutile toute seule, mais avec l'erreur de <c>make</c> et les
551 informations de compilation, un développeur peut savoir quelle application et
552 quelle version du paquet a ce problème. Petite parenthèse, <c>make</c> est
553 communément utilisé pour le processus de compilation des programmes (<b>mais pas
554 toujours</b>). Si vous ne trouvez d'erreur «&nbsp;make: ***&nbsp;» nulle part,
555 alors copiez et collez simplement les vingt lignes précédant l'erreur
556 d'<c>emerge</c>. Cela devrait couvrir la majorité des messages d'erreurs du
557 système de compilation. Disons maintenant que l'erreur paraît très grande. Dix
558 lignes ne suffiront pas pour tout comprendre. C'est là qu'entre en jeu
559 PORT_LOGDIR.
560 </p>
561
562 </body>
563 </section>
564 <section>
565 <title>La commande emerge et PORT_LOGDIR</title>
566 <body>
567
568 <p>
569 PORT_LOGDIR est une variable de Portage qui définit un répertoire pour séparer
570 les journaux d'<c>emerge</c>. Intéressons-nous-y et voyons ce que cela requiert.
571 Tout d'abord, lancez <c>emerge</c> en définissant PORT_LOGDIR à votre
572 emplacement préféré. Disons que nous avons un répertoire
573 <path>/var/log/portage</path>. Nous allons l'utiliser pour notre répertoire de
574 journaux&nbsp;:
575 </p>
576
577 <note>
578 Dans la configuration par défaut, <path>/var/log/portage</path> n'existe pas, et
579 vous allez devoir le créer. Si vous ne le faites pas, Portage n'arrivera pas à
580 écrire les journaux.
581 </note>
582
583 <pre caption="Utiliser emerge avec PORT_LOGDIR">
584 # <i>PORT_LOGDIR=/var/log/portage emerge foobar2</i>
585 </pre>
586
587 <p>
588 Maintenant, <c>emerge</c> va encore échouer. Cependant, nous avons cette fois-ci
589 un journal avec lequel nous pouvons travailler, et que l'on pourra joindre au
590 bogue plus tard. Jetons un œil à notre fichier journal.
591 </p>
592
593 <pre caption="Contenu de PORT_LOGDIR">
594 # <i>ls -la /var/log/portage</i>
595 total 16
596 drwxrws--- 2 root root 4096 Jun 30 10:08 .
597 drwxr-xr-x 15 root root 4096 Jun 30 10:08 ..
598 -rw-r--r-- 1 root root 7390 Jun 30 10:09 2115-foobar2-1.0.log
599 </pre>
600
601 <p>
602 Les fichiers de journaux ont le format [compteur]-[nom du paquet]-[version].log.
603 Le compteur est une variable spéciale qui représente le paquet comme le n-ième
604 paquet que vous avez installé. Cela prévient l'apparition de journaux dupliqués.
605 Un coup d'œil rapide au journal montre le processus entier d'<c>emerge</c>. Il
606 pourra être joint plus tard comme nous le verrons dans la section de rapport de
607 bogues. Maintenant que nous avons correctement obtenu nos informations
608 nécessaires pour rapporter le bogue, nous pouvons continuer. Cependant, avant
609 d'aborder ce point, nous devons nous assurer que personne n'a déjà rapporté le
610 problème. Intéressons-nous donc à la recherche de bogues.
611 </p>
612
613 </body>
614 </section>
615 </chapter>
616
617 <chapter>
618 <title>Recherche avec Bugzilla</title>
619 <section>
620 <title>Introduction</title>
621 <body>
622
623 <p>
624 <uri link="http://www.bugzilla.org">Bugzilla</uri> est ce que nous utilisons
625 chez Gentoo pour gérer les bogues. Le Bugzilla de Gentoo est joignable en HTTPS
626 et en HTTP. La version HTTPS est disponible pour ceux qui sont sur des réseaux
627 non sécurisés ou simplement pour les paranoïaques&nbsp;:). Pour respecter une
628 certaine uniformité, nous utiliserons la version HTTPS dans les exemples qui
629 suivent. Rendez-vous sur <uri link="https://bugs.gentoo.org">Gentoo Bugs</uri>
630 pour voir à quoi cela ressemble.
631 </p>
632
633 <p>
634 L'une des choses les plus frustrantes pour les développeurs et les mainteneurs
635 de bogues est de trouver des rapports de bogues dupliqués. Cela leur coûte un
636 temps non négligeable qu'ils pourraient plutôt utiliser pour travailler sur des
637 bogues plus importants. Généralement, ceci pourrait être évité avec quelques
638 méthodes simples de recherche. Nous allons ainsi voir comment rechercher des
639 bogues et détecter si vous en avez un similaire. Dans cet exemple, nous allons
640 utiliser l'erreur décelée tout à l'heure avec l'installation de xclass.
641 </p>
642
643 <pre caption="Erreur lors de l'emerge de xclass">
644 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3/backward/backward_warning.h:32:2:
645 warning: #warning This file includes at least one deprecated or antiquated
646 header. Please consider using one of the 32 headers found in section 17.4.1.2 of
647 the C++ standard. Examples include substituting the &lt;X&gt; header for the &lt;X.h&gt;
648 header for C++ includes, or &lt;sstream&gt; instead of the deprecated header
649 &lt;strstream.h&gt;. To disable this warning use -Wno-deprecated.
650 In file included from main.cc:40:
651 menudef.h:55: error: brace-enclosed initializer used to initialize `
652 OXPopupMenu*'
653 menudef.h:62: error: brace-enclosed initializer used to initialize `
654 OXPopupMenu*'
655 menudef.h:70: error: brace-enclosed initializer used to initialize `
656 OXPopupMenu*'
657 menudef.h:78: error: brace-enclosed initializer used to initialize `
658 OXPopupMenu*'
659 main.cc: In member function `void OXMain::DoOpen()':
660 main.cc:323: warning: unused variable `FILE*fp'
661 main.cc: In member function `void OXMain::DoSave(char*)':
662 main.cc:337: warning: unused variable `FILE*fp'
663 make[1]: *** [main.o] Error 1
664 make[1]: Leaving directory
665 `/var/tmp/portage/xclass-0.7.4/work/xclass-0.7.4/example-app'
666 make: *** [shared] Error 2
667
668 !!! ERROR: x11-libs/xclass-0.7.4 failed.
669 !!! Function src_compile, Line 29, Exitcode 2
670 !!! 'emake shared' failed
671 </pre>
672
673 <p>
674 Pour commencer la recherche, rendons-nous sur la <uri
675 link="https://bugs.gentoo.org/">page d'accueil du Bugzilla</uri>.
676 </p>
677
678 <figure link="/images/docs/bugzie-homepage.png" caption="Page d'accueil du
679 Bugzilla"/>
680
681 <p>
682 Cliquons sur «&nbsp;Query Existing bug reports&nbsp;» (NdT&nbsp;:
683 «&nbsp;Recherche de rapports de bogues existants&nbsp;»). Nous choisissons cette
684 recherche plutôt que la recherche classique car la recherche classique a
685 tendance à donner des résultats vagues et empêche souvent les utilisateurs de
686 trouver leur bogue à cause d'un grand nombre de résultats de recherche. Une fois
687 que nous avons cliqué sur ce lien, nous obtenons la page suivante&nbsp;:
688 </p>
689
690 <figure link="/images/docs/bugzie-search.png" caption="Page de recherche du
691 Bugzilla"/>
692
693 <note>
694 Si vous avez déjà utilisé la recherche avancée auparavant, vous aurez plus de
695 chances de voir cet écran à la place.
696 </note>
697
698 <p>
699 Cliquez sur le lien «&nbsp;Advanced search&nbsp;» (NdT&nbsp;: «&nbsp;Recherche
700 avancée&nbsp;») pour atteindre la page de recherche avancée.
701 </p>
702
703 <figure link="/images/docs/bugzie-adv-search.png" caption="Page de recherche
704 avancée"/>
705
706 <p>
707 Voici comment la page de recherche avancée se présente. Bien que cela puisse
708 s'avérer bouleversant au premier abord, nous allons voir que quelques simples
709 renseignements permettent de réduire quelque peu les résultats vagues que le
710 Bugzilla retourne.
711 </p>
712
713 <figure link="/images/docs/bugzie-content.png" caption="Contenu"/>
714
715 <p>
716 Le premier champ est le résumé du bogue. Ici nous allons simplement mettre le
717 nom du paquet qui a planté. Si Bugzilla ne retourne aucun résultat, essayez de
718 retirer le nom du paquet, juste au cas où quelqu'un ne l'aurez pas mis dans le
719 résumé (hautement déconseillé, mais nous avons déjà vu un certain nombre de
720 rapports de bogues étranges).
721 </p>
722
723 <p>
724 Les champs «&nbsp;Product &nbsp;» (NdT&nbsp;: «&nbsp;produit&nbsp;»),
725 «&nbsp;Component&nbsp;» (NdT&nbsp;: pour la partie) et «&nbsp;Version &nbsp;»
726 vont tous être laissés par défaut. Cela nous évite d'être trop précis et de
727 manquer tous les bogues.
728 </p>
729
730 <p>
731 La partie «&nbsp;Comment&nbsp;» (NdT&nbsp;: «&nbsp;commentaire&nbsp;») est la
732 plus importante. Utilisez ce champ pour lister ce qui semble être un cas
733 caractéristique de l'erreur. En gros, n'utilisez pas quelque chose comme le
734 début de l'erreur de compilation, mais trouvez une ligne avant faisant état
735 d'une vraie erreur. Aussi vous pouvez filtrer la ponctuation pour éviter que
736 Bugzilla n'interprète les résultats des commentaires de la mauvaise façon. Voici
737 l'exemple de notre erreur de xclass&nbsp;:
738 </p>
739
740 <pre caption="Contenu de la ligne commentée">
741 menudef.h:78: error: brace-enclosed initializer used to initialize `OXPopupMenu'
742 <comment>(Remove the quotes ' ')</comment>
743 menudef.h 78 error brace-enclosed initializer used to initialize OXPopupMenu
744 </pre>
745
746 <p>
747 L'exemple ci-dessus est assez caractéristique de l'endroit où nous trouverions
748 le bogue sans patauger avec d'autres résultats candidats pour cette erreur de
749 compilation de xclass.
750 </p>
751
752 <p>
753 «&nbsp;URI&nbsp;», «&nbsp;Whiteboard&nbsp;» (NdT&nbsp;: «&nbsp;tableau
754 blanc&nbsp;»), et «&nbsp;Keywords&nbsp;» (NdT&nbsp;: «&nbsp;mots clefs&nbsp;»)
755 peuvent être laissés vides. Ce que nous avons mis avant devrait suffir à trouver
756 notre bogue. Jetons un œil à ce que nous avons renseigné.
757 </p>
758
759 <figure link="/images/docs/bugzie-comp-search.png" caption="Formulaire de
760 recherche complété"/>
761
762 <p>
763 À présent, cliquons sur le bouton «&nbsp;Search&nbsp;» (NdT&nbsp;:
764 «&nbsp;Rechercher&nbsp;») et voici les résultats...
765 </p>
766
767 <figure link="/images/docs/bugzie-search-result.png" caption="Résultats de
768 recherche"/>
769
770 <p>
771 Seulement deux bogues&nbsp;! C'est ainsi beaucoup plus facile de s'en occuper.
772 Cliquons sur le premier pour vérifier et être suffisamment sûr que c'est celui
773 que nous cherchons.
774 </p>
775
776 <figure link="/images/docs/bugzie-located.png" caption="Bogue localisé"/>
777
778 <p>
779 Non seulement c'est celui que nous voulons, mais en plus il a déjà été résolu.
780 En vérifiant le dernier commentaire, nous trouvons la solution et savons ce
781 qu'il faut faire pour le résoudre. Maintenant, voyons ce qu'il se serait passé
782 si nous n'avions pas utilisé la recherche avancée.
783 </p>
784
785 <figure link="/images/docs/bugzie-basic-search-result.png" caption="Résultats de
786 recherche classique"/>
787
788 <p>
789 Quatre bogues à inspecter&nbsp;! Cela aurait été bien pire avec de plus gros
790 paquets. Néanmoins, avec ces simples outils, nous sommes capables de réduire de
791 manière significative le temps de recherche pour essayer de localiser un bogue
792 spécifique.
793 </p>
794
795 </body>
796 </section>
797 <section>
798 <title>Conclusion</title>
799 <body>
800
801 <p>
802 Disons que vous avez cherché et cherché mais que vous n'avez toujours pas trouvé
803 un bogue correspondant sur le Bugzilla. Alors vous avez trouvé vous-même un
804 nouveau bogue. Nous allons voir le processus de rapport de bogue pour soumettre
805 votre nouveau bogue.
806 </p>
807
808 </body>
809 </section>
810 </chapter>
811
812 <chapter>
813 <title>Le rapport de bogues</title>
814 <section>
815 <title>Introduction</title>
816 <body>
817
818 <p>
819 Dans ce chapitre, nous allons voir comment utiliser Bugzilla pour répertorier
820 un nouveau bogue de façon claire. Rendez-vous pour cela sur la page de <uri
821 link="https://bugs.gentoo.org">Gentoo Bugs</uri>...
822 </p>
823
824 <figure link="/images/docs/bugzie-homepage.png" caption="Page d'accueil de
825 Bugzilla"/>
826
827 <p>
828 Cliquez sur "Report a Bug - Using the guided format" (NdT&nbsp;:
829 «&nbsp;Rapporter un bogue, utilisation du format guidé&nbsp;»).
830 </p>
831
832 <figure link="/images/docs/bugzie-prod-select.png" caption="Sélection du
833 produit"/>
834
835 <p>
836 Comme vous pouvez le voir, l'accent <b>majeur</b> a été mis sur le fait de
837 placer votre bogue au bon endroit. «&nbsp;Gentoo Linux&nbsp;» est l'endroit où
838 la grande majorité des bogues vont trouver leur place.
839 </p>
840
841 <p>
842 En dépit de ceci, certaines personnes posteront les bogues d'ebuild dans la
843 partie du développement de Portage (pensant que l'équipe de Portage gère l'arbre
844 de Portage) ou dans «&nbsp;infra&nbsp;» (pensant que l'équipe a accès aux
845 miroirs pouvant ainsi synchroniser et régler le problème directement). Ce n'est
846 simplement pas comme ça que les choses fonctionnent.
847 </p>
848
849 <p>
850 Une autre idée reçue et qui est fausse concerne nos bogues de documentation.
851 Par exemple, un utilisateur trouve un bogue avec la
852 <uri link="/proj/en/releng/catalyst/">documentation des Catalyst</uri>. La
853 tendance générale est de répertorier un bogue dans «&nbsp;Docs-user&nbsp;», qui
854 est en fait assigné à la <uri link="http://gdp.gentoo.org">GDP</uri>, alors
855 qu'il devrait être envoyé à un membre de l'équipe du projet <uri
856 link="/proj/en/releng/">Release Engineering</uri>. En général, seule la
857 documentation se trouvant dans <path>http://www.gentoo.org/doc/*</path>
858 appartient à la GDP. Toute documentation se trouvant dans
859 <path>http://www.gentoo.org/proj/*</path> appartient aux équipes respectives.
860 </p>
861
862 <note>
863 Nous préférons voir un bogue dont le produit n'est pas censé être «&nbsp;Gentoo
864 Linux&nbsp;» mais qui a été classé dans cette catégorie plutôt que de voir un
865 bogue qui appartient au produit «&nbsp;Gentoo Linux&nbsp;» et rangé autre part.
866 Même si aucun des deux n'est privilégié, le premier est plus recevable et
867 compréhensible (à l'exception des bogues du site... nous pourrions avoir un
868 problème avec cela...).
869 </note>
870
871 <p>
872 Notre bogue va dans «&nbsp;Gentoo Linux&nbsp;» car c'est un bogue d'ebuild. Nous
873 nous rendons là-bas et nous nous trouvons face au processus multi-étapes de
874 rapport de bogue. Passons donc à présent à l'étape 1...
875 </p>
876
877 <figure link="/images/docs/bugzie-guide-step1.png" caption="Format guidé de
878 l'étape 1"/>
879
880 <p>
881 Cette première étape est vraiment très importante (comme vous le montre le texte
882 rouge). C'est l'endroit où vous cherchez pour voir si quelqu'un d'autre n'a pas
883 déjà relevé le même bogue que vous. Si vous zappez cette étape et qu'un bogue
884 comme le vôtre existe, il sera marqué en DUPLICATE gaspillant de ce fait un
885 grand effort de la part des QA. Pour vous donner une idée, les numéros de bogues
886 qui sont barrés ci-dessus concernent des bogues dupliqués. Vient maintenant
887 l'étape 2, où nous renseignons l'information.
888 </p>
889
890 </body>
891 </section>
892 <section>
893 <title>Information requise</title>
894 <body>
895
896 <figure link="/images/docs/bugzie-basic.png" caption="Informations de base"/>
897
898 <p>
899 Jetons un petit coup d'œil à qui est quoi.
900 </p>
901
902 <ul>
903 <li>
904 En premier, c'est le produit, «&nbsp;Product&nbsp;». Le produit va réduire
905 le bogue à un domaine spécifique de Gentoo comme le Bugzilla (pour les
906 bogues en relation avec bugs.gentoo.org), Docs-user (pour la documentation
907 utilisateur) ou Gentoo Linux (pour les ebuilds et semblables).
908 </li>
909 <li>
910 La partie («&nbsp;Composent&nbsp;») est où exactement le problème est
911 apparu, plus précisément dans quelle partie du produit sélectionné le bogue
912 est arrivé. Cela rend la classification plus facile.
913 </li>
914 <li>
915 La plateforme matérielle («&nbsp;Hardware Platform&nbsp;») est
916 l'architecture que vous utilisez. Si vous utilisez SPARC, vous devrez mettre
917 SPARC.
918 </li>
919 <li>
920 «&nbsp;Operating System&nbsp;», pour système d'exploitation, correspond au
921 système que vous utilisez. Gentoo étant considérée comme une
922 "méta-distribution", elle peut également fonctionner sur des systèmes
923 d'exploitation autres que Linux.
924 </li>
925 </ul>
926
927 <p>
928 Donc, pour notre exemple de bogue, nous avons&nbsp;:
929 </p>
930
931 <ul>
932 <li>Product - Gentoo Linux (puisque c'est un problème d'ebuild)</li>
933 <li>
934 Composent - Application (c'est une erreur provenant d'une application,
935 foobar2)
936 </li>
937 <li>
938 Hardware Platform - All (cette erreur pourrait apparaître sur toutes les
939 architectures)
940 </li>
941 <li>
942 Operating System - All (cela pourrait se produire sur tous les types de
943 systèmes)
944 </li>
945 </ul>
946
947 <figure link="/images/docs/bugzie-basic-comp.png" caption="Informations de base
948 complétées"/>
949
950 <ul>
951 <li>
952 La marque de construction, «&nbsp;Build Identifier&nbsp;» est généralement
953 l'application utilisateur (NdT&nbsp;: «&nbsp;User Agent&nbsp;») du
954 navigateur utilisée pour rapporter les bogues (pour enregistrer les
955 propositions). Vous pouvez laisser comme tel.
956 </li>
957 <li>
958 L'URL est optionnelle et sert à pointer l'information appropriée sur un
959 autre site (un bogue parent sur le Bugzilla, les notes de publications sur
960 la page d'accueil du paquet, etc.). Vous ne devriez jamais utiliser une URL
961 qui mène sur un pastebin pour les messages d'erreurs, les logs, la sortie de
962 <c>emerge --info</c>, les captures d'écran ou les informations similaires.
963 Celles-ci doivent toujours être attachées au bogue.
964 </li>
965 <li>
966 Dans le résumé, «&nbsp;Summary&nbsp;», vous devriez mettre la catégorie du
967 paquet, son nom, et son numéro.
968 </li>
969 </ul>
970
971 <p>
972 Ne pas inclure la catégorie dans le résumé n'est pas vraiment une catastrophe,
973 mais c'est recommandé. Si vous ne mettez pas le nom du paquet, en revanche,
974 nous ne saurons pas sur quoi vous remplissez un rapport de bogue, et nous serons
975 obligés de vous le demander plus tard. Le numéro de version est important pour
976 les personnes cherchant les bogues. Si vingt personnes remplissent des bogues et
977 qu'aucun d'entre eux ne met de numéro de version, comment vont faire les gens
978 qui cherchent si un bogue similaire au leur existe déjà&nbsp;? Ils vont devoir
979 inspecter chaque bogue individuellement, ce qui n'est pas trop difficile, mais
980 s'il y a, disons, 200 bogues... ce n'est pas aussi facile. Après toutes les
981 informations concernant le paquet, vous devrez écrire une petite description du
982 problème. Ici par exemple&nbsp;:
983 </p>
984
985 <figure link="/images/docs/bugzie-summary.png" caption="Résumé"/>
986
987 <p>
988 Ces quelques règles simples peuvent simplifier grandement la gestion des bogues.
989 Ensuite viennent les détails. Ici nous renseignons les informations concernant
990 le bogue. Nous allons voir cela avec un exemple&nbsp;:
991 </p>
992
993 <figure link="/images/docs/bugzie-details.png" caption="Détails"/>
994
995 <p>
996 À présent, les développeurs savent pourquoi nous avons rapporté ce bogue. Ils
997 peuvent alors essayer de le reproduire. Le champ «&nbsp;Reproducibility&nbsp;»
998 (NdT&nbsp;: «&nbsp;Reproduction&nbsp;») nous dit à quelle fréquence on a pu
999 reproduire le problème. Dans cet exemple, nous pouvons le reproduire chaque fois
1000 simplement en exécutant foobar2. Renseignons cette information.
1001 </p>
1002
1003 <figure link="/images/docs/bugzie-reprod.png" caption="Reproduction"/>
1004
1005 <p>
1006 Nous avons expliqué comment nous avons trouvé le bogue. La prochaine étape
1007 consiste à expliquer quels étaient résultats que vous avions obtenus et ce que
1008 nous pensons qu'ils devraient être en réalité.
1009 </p>
1010
1011 <figure link="/images/docs/bugzie-results.png" caption="Résultats"/>
1012
1013 <p>
1014 Nous pourrions alors fournir des informations supplémentaires. Cela peut être
1015 des choses telles que les traces de pile, des <b>morceaux</b> (puisque le
1016 journal complet est généralement lourd et pas très utile) des journaux de
1017 strace, mais plus important, notre sortie de <c>emerge --info</c>. Voici un
1018 exemple.
1019 </p>
1020
1021 <figure link="/images/docs/bugzie-addl-info.png" caption="Informations
1022 supplémentaires"/>
1023
1024 <p>
1025 Enfin nous désignons la sévérité du bogue. Veuillez passer en revue ceci
1026 attentivement. Dans la plupart des cas, il est bon de laisser le choix par
1027 défaut et quelqu'un augmentera ou baissera le niveau de criticité pour vous.
1028 Toutefois, si vous relevez le niveau de sévérité du bogue, assurez-vous de le
1029 renseigner très soigneusement et assurez-vous que vous ne faites pas une erreur.
1030 Un aperçu des différents niveaux de criticité est donné ci-dessous.
1031 </p>
1032
1033 <ul>
1034 <li>
1035 Blocker (NdT&nbsp;: «&nbsp;Bloquant&nbsp;») - Le programme ne veut tout
1036 simplement pas s'installer ou représente une entrave majeure au système. Par
1037 exemple, un problème de <c>baselayout</c> qui empêche le système de démarrer
1038 pourrait être un candidat à cet estampillage.
1039 </li>
1040 <li>
1041 Critical (N.D.T: pour «&nbsp;Critique&nbsp;») - Le programme connaît des
1042 pertes de données ou de graves fuites de mémoire durant son exécution. De
1043 nouveau, un programme important tel que <c>net-tools</c> échouant durant sa
1044 compilation pourrait être étiqueté comme critique. Il ne va pas empêcher le
1045 système de démarrer, mais est assez essentiel dans l'utilisation de tous les
1046 jours.
1047 </li>
1048 <li>
1049 Major (N.D.T: pour «&nbsp;Majeur&nbsp;») - Le programme plante, mais rien ne
1050 cause des dommages sévères à votre système ou ne crée des pertes
1051 d'informations.
1052 </li>
1053 <li>
1054 Minor (N.D.T: pour «&nbsp;Mineur&nbsp;») - Votre programme plante ici et là
1055 avec des fonctions claires.
1056 </li>
1057 <li>
1058 Normal - Le choix par défaut. Si vous n'êtes pas sûr, laissez ceci comme tel
1059 à moins que ce soit une nouvelle version, ou un changement d'apparence, dans
1060 ce cas regardez ci-dessous pour plus d'informations.
1061 </li>
1062 <li>
1063 Trivial - Des choses telles qu'un mot oublié ou pour enlever un espace
1064 blanc.
1065 </li>
1066 <li>
1067 Enhancement (N.D.T: pour «&nbsp;Amélioration&nbsp;» - Une requête pour
1068 activer une nouvelle fonctionnalité dans un programme, ou plus
1069 particulièrement des <e>nouveaux ebuilds</e>.
1070 </li>
1071 </ul>
1072
1073 <figure link="/images/docs/bugzie-sev.png" caption="Sévérité"/>
1074
1075 <p>
1076 Ici, nous mettons le bogue au niveau Normal.
1077 </p>
1078
1079 <p>
1080 À présent, nous pouvons soumettre notre rapport de bogue en cliquant sur la
1081 boîte «&nbsp;Submit Bug Report&nbsp;» (NdT&nbsp;: «&nbsp;Soumettre un rapport de
1082 bogue&nbsp;»). Vous pouvez dès à présent voir votre nouveau bogue. Regardez le
1083 <uri link="https://bugs.gentoo.org/show_bug.cgi?id=97265">Bogue 97561</uri> pour
1084 voir à quoi cela ressemble. Nous avons rapporté notre bogue&nbsp;! Voyons
1085 comment cela est traité.
1086 </p>
1087
1088 </body>
1089 </section>
1090 <section>
1091 <title>Les requêtes d'estampillage de 0-jour</title>
1092 <body>
1093
1094 <p>
1095 Plus haut, nous avons vu comment rapporter un bogue. Maintenant nous allons voir
1096 ce qu'il ne faut <e>pas</e> faire.
1097 </p>
1098
1099 <p>
1100 Supposons que vous avez ardemment suivi la planification d'un projet ascendant,
1101 et quand vous vérifiez sa page d'accueil, que voyez-vous&nbsp;? Ils viennent
1102 juste de sortir une nouvelle version quelques minutes avant&nbsp;! La plupart
1103 des utilisateurs se précipiteraient immédiatement sur le Bugzilla de Gentoo pour
1104 dire que la nouvelle version est disponible&nbsp;: veuillez estampiller la
1105 version existante et l'ajouter à Portage, etc. Toutefois, c'est exactement ce
1106 que vous ne devez <b>pas</b> faire. Les requêtes de ce genre sont appelées des
1107 requêtes d'estampillage de zéro jour (ou des 0-jour), car elles sont faites
1108 le même jour que la sortie de la nouvelle version.
1109 </p>
1110
1111 <impo>
1112 <b>Veuillez patienter <e>au moins</e> 48 heures avant de rapporter une nouvelle
1113 version sur notre Bugzilla.</b> Aussi, vous <e>devez</e> vérifier Bugzilla
1114 avant de poster une demande afin de vous assurer que personne ne l'a déjà
1115 rapporté, ou que les mainteneurs de Gentoo ne sont pas déjà en train de traiter
1116 la nouvelle version.
1117 </impo>
1118
1119 <p>
1120 Pourquoi devez-vous attendre&nbsp;? Premièrement, c'est assez impoli d'exiger
1121 des développeurs de Gentoo d'abandonner quelque chose qu'ils sont en train de
1122 faire juste pour ajouter une nouvelle version qui est sortie quinze minutes
1123 avant. Votre demande pourrait être marquée comme INVALID ou LATER, car les
1124 développeurs ont plein de problèmes urgents qui les gardent occupés.
1125 Deuxièmement, les développeurs sont généralement au courant des sorties de
1126 nouvelles versions bien avant les utilisateurs, puisqu'ils doivent suivre la
1127 version en amont d'assez près. Ils savent déjà qu'une nouvelle version est en
1128 cours. Dans bien des cas, ils ont déjà ouvert un bogue, ou peut-être même l'ont
1129 déjà ajouté à Portage comme paquet masqué.
1130 </p>
1131
1132 <p>
1133 Soyez judicieux quand vous testez et demandez des nouvelles versions de paquets.
1134 Cherchez dans Bugzilla avant de poster votre requête d'estampillage&nbsp;: n'y
1135 a-t-il pas déjà un bogue ouvert&nbsp;? Avez-vous synchronisé il y a longtemps;
1136 n'est-ce pas déjà dans Portage&nbsp;? Le paquet a-t-il bien été libéré par
1137 l'équipe en amont&nbsp;? Un peu de bon sens fera bon chemin, et vous fera
1138 apprécier des développeurs qui ont déjà beaucoup à faire. Si cela fait quelques
1139 jours que la version est sortie et que vous êtes sûr qu'il n'y a pas d'autres
1140 demandes pour celle-ci (et qu'elle n'est pas non plus dans Portage), alors vous
1141 pouvez ouvrir un nouveau bogue. Assurez-vous de mentionner qu'il compile et
1142 fonctionne bien sur votre architecture. Toute autre information pouvant aider
1143 et que vous fournirez sera la bienvenue.
1144 </p>
1145
1146 <p>
1147 Vous voulez voir la nouvelle version de votre logiciel favori dans
1148 Portage&nbsp;? Répertoriez des bogues intelligents.
1149 </p>
1150
1151 </body>
1152 </section>
1153 </chapter>
1154
1155 <chapter>
1156 <title>S'occuper de votre bogue</title>
1157 <section>
1158 <body>
1159
1160 <p>
1161 En regardant le bogue, nous voyons les informations que nous avons fournies
1162 précédemment. Vous noterez que le bogue a été assigné à
1163 bug-wranglers@g.o. C'est l'attribution par défaut pour les bogues de la
1164 composante Application.
1165 </p>
1166
1167 <figure link="/images/docs/bugzie-new-basic.png" caption="Informations de base
1168 d'un nouveau bogue"/>
1169
1170 <p>
1171 Les détails que nous avons entrés à propos du bogue sont également disponibles.
1172 </p>
1173
1174 <figure link="/images/docs/bugzie-new-details.png" caption="Détails du nouveau
1175 bogue"/>
1176
1177 <p>
1178 Cependant, les mainteneurs de bogues ne vont (généralement) pas corriger nos
1179 bogues, donc nous allons les réassigner à quelqu'un qui peut le faire (vous
1180 pouvez aussi laisser les mainteneurs de bogues le réassigner pour vous). Pour
1181 cela, nous utilisons le fichier metadata.xml du paquet. Vous pouvez normalement
1182 le trouver dans <path>/usr/portage/categorie/paquet/metadata.xml</path>. Voici
1183 celui que j'ai créé pour foobar2.
1184 </p>
1185
1186 <note>
1187 Vous devez être le rapporteur du bogue ou un membre de certains groupes du
1188 Bugzilla de Gentoo (comme celui des Développeurs Gentoo) pour pouvoir réassigner
1189 les bogues.
1190 </note>
1191
1192 <pre caption="metadata.xml">
1193 &lt;?xml version="1.0" encoding="UTF-8"?&gt;
1194 &lt;!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"&gt;
1195 &lt;pkgmetadata&gt;
1196 &lt;herd&gt;chriswhite&lt;/herd&gt;
1197 &lt;maintainer&gt;
1198 &lt;email&gt;chriswhite@g.o&lt;/email&gt;
1199 &lt;name&gt;Chris White&lt;/name&gt;
1200 &lt;/maintainer&gt;
1201 &lt;longdescription lang="en"&gt;
1202 Foobar2 is a package that uses a configuration file to display a word.
1203 &lt;/longdescription&gt;
1204 &lt;/pkgmetadata&gt;
1205 </pre>
1206
1207 <p>
1208 Notez la section «&nbsp;maintener&nbsp;» (NdT&nbsp;: «&nbsp;mainteneur&nbsp;»).
1209 Elle renseigne sur le mainteneur du paquet, qui est moi-même, Chris White, dans
1210 ce cas-ci. L'adresse électronique listée est chriswhite@g.o. Nous allons
1211 l'utiliser afin de réassigner le bogue à la bonne personne. Pour se faire,
1212 cliquez sur la bulle à côté de «&nbsp;Reassign bug to&nbsp;» (NdT&nbsp;:
1213 «&nbsp;Réassigner le bogue à&nbsp;»), puis renseignez l'adresse électronique.
1214 </p>
1215
1216 <note>
1217 Pour un paquet qui n'a pas de fichier metadata.xml, le bogue doit être réassigné
1218 à maintainer-needed@g.o et un paquet qui a besoin d'un développeur Gentoo
1219 pour être maintenu doit être assigné à maintainer-wanted@g.o.
1220 </note>
1221
1222 <figure link="/images/docs/bugzie-reassign.png" caption="Réassignement d'un
1223 bogue"/>
1224
1225 <p>
1226 Puis cliquez sur le bouton «&nbsp;Commit&nbsp;» (NdT&nbsp;:
1227 «&nbsp;Envoyer&nbsp;») pour appliquer les changements. Le bogue m'a été
1228 réassigné. Peu après, vous remarquerez (par email habituellement) que j'ai
1229 répondu à votre bogue. J'ai indiqué que j'aimerais voir un journal de strace
1230 afin de voir comment le programme essaie d'atteindre son fichier de
1231 configuration. Suivez les instructions précédentes sur l'utilisation de strace
1232 pour obtenir un journal. Maintenant vous devez le joindre au bogue. Pour ce
1233 faire, cliquez sur «&nbsp;Create A New Attachment&nbsp;» (NdT&nbsp;:
1234 «&nbsp;Créer une nouvelle pièce jointe&nbsp;»).
1235 </p>
1236
1237 <figure link="/images/docs/bugzie-new-attach.png" caption="Nouvelle pièce
1238 jointe"/>
1239
1240 <p>
1241 Maintenant, nous devons joindre le journal. Allons-y à grands pas.
1242 </p>
1243
1244 <ul>
1245 <li>
1246 File (NdT&nbsp;: Fichier) - C'est l'emplacement du fichier sur votre
1247 machine. Dans cet exemple, l'emplacement de <path>strace.log</path>. Vous
1248 pouvez utiliser le bouton «&nbsp;Browse...&nbsp;» (NdT&nbsp;: Parcourir ...)
1249 pour sélectionner le fichier, ou entrer le chemin directement dans le champ
1250 de texte.
1251 </li>
1252 <li>
1253 Description - Une courte ligne, ou quelques mots décrivant la pièce jointe.
1254 Nous allons juste entrer «&nbsp;strace.log&nbsp;» ici, puisque c'est
1255 suffisamment explicite.
1256 </li>
1257 <li>
1258 Content Type (NdT&nbsp;: Type de Contenu) - C'est le type du fichier que
1259 nous joignons au bogue.
1260 </li>
1261 <li>
1262 Obsoletes (NdT&nbsp;: Obsolètes) - S'il y avait des pièces jointes
1263 attachées au bogue avant l'actuel, vous avez une option pour les déclarer
1264 obsolètes par les vôtres. Puisque nous n'avons pas de pièces jointes
1265 précédemment attachées à ce bogue, nous n'avons pas à nous en occuper.
1266 </li>
1267 <li>
1268 Comment (NdT&nbsp;: Commentaire) - Entrez des commentaires qui seront
1269 visibles avec cette pièce jointe. Vous pouvez donner des précisions sur
1270 celle-ci, si besoin.
1271 </li>
1272 </ul>
1273
1274 <p>
1275 Pour le respect du type de contenu, voici quelques détails supplémentaires. Vous
1276 pouvez cocher la case «&nbsp;patch&nbsp;» si vous joignez un correctif.
1277 Autrement, vous pouvez demander à Bugzilla d'auto-détecter le type de fichier
1278 (non recommandé). Les autres options sont dans «&nbsp;select from list&nbsp;»
1279 (NdT&nbsp;: sélectionner depuis une liste), qui est le plus fréquemment utilisé.
1280 Utiliser le texte simple (text/plain) pour la plupart des pièces jointes sauf
1281 pour les fichiers binaires comme les images (qui peuvent utiliser image/gif,
1282 image/jpeg ou image/png selon leur type) ou les fichiers compressés comme
1283 .tar.bz2 qui utiliseraient application/octet-stream comme type de fichier.
1284 </p>
1285
1286 <figure link="/images/docs/bugzie-new-attach-comp.png" caption="Nouvelle pièce
1287 jointe complétée"/>
1288
1289 <p>
1290 Nous envoyons <path>strace.log</path> qui va être appliqué au rapport de bogue.
1291 </p>
1292
1293 <figure link="/images/docs/bugzie-strace.png" caption="strace log attaché"/>
1294
1295 <p>
1296 Nous avons mentionné auparavant que les ebuilds vont parfois nécessiter que vous
1297 joignez un fichier avec l'erreur d'<c>emerge</c>. Voici un exemple ci-dessous.
1298 </p>
1299
1300 <pre caption="Exemple de demande de fichier joint">
1301 configure: error: PNG support requires ZLIB. Use --with-zlib-dir=&lt;DIR&gt;
1302
1303 !!! Please attach the config.log to your bug report:
1304 !!! /var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/config.log
1305
1306 !!! ERROR: dev-php/php-5.0.3-r1 failed.
1307 !!! Function econf, Line 485, Exitcode 0
1308 !!! econf failed
1309 !!! If you need support, post the topmost build error, NOT this status message.
1310 </pre>
1311
1312 <p>
1313 Veuillez s'il-vous-plaît joindre tout fichier demandé comme ceci à votre rapport
1314 de bogue.
1315 </p>
1316
1317 <p>
1318 Parfois un développeur peut vous demander de joindre un fichier diff ou un
1319 correctif pour un fichier. Les fichiers diff standards peuvent être obtenus de
1320 la façon suivante&nbsp;:
1321 </p>
1322
1323 <pre caption="Création d'un fichier diff standard">
1324 $ <i>cp fichier fichier.old</i>
1325 $ <i>nano fichier</i>
1326 $ <i>diff -u fichier.old fichier</i>
1327 </pre>
1328
1329 <p>
1330 Pour les fichiers source C/C++, l'option <b>-p</b> est ajoutée pour montrer à
1331 quels appels de fonction s'applique le fichier diff&nbsp;:
1332 </p>
1333
1334 <pre caption="Fichier diff d'un fichier source C/C++">
1335 $ <i>cp fichier.c fichier.c.old</i>
1336 $ <i>nano fichier.c</i>
1337 $ <i>diff -up fichier.c.old fichier.c</i>
1338 </pre>
1339
1340 <p>
1341 L'équipe de documentation demandera la combinaison d'options <b>-Nt</b> ainsi
1342 que <b>-u</b>. C'est surtout en rapport avec les espaces des tabulations. Vous
1343 pouvez créer un tel fichier diff avec&nbsp;:
1344 </p>
1345
1346 <pre caption="Fichier diff pour la documentation">
1347 $<i> cp fichier.xml fichier.xml.old</i>
1348 $<i> nano fichier.xml</i>
1349 $<i> diff -Nut fichier.xml.old fichier.xml</i>
1350 </pre>
1351
1352 <p>
1353 Votre fichier diff est ainsi créé. Pendant que nous faisons tout ça, supposez
1354 qu'une autre personne trouve votre bogue en cherchant sur le bugzilla et est
1355 curieuse de garder sa trace, elle peut le faire en ajoutant son adresse email au
1356 champ CC du bogue comme montré ci-dessous. Vous pouvez également suivre la trace
1357 d'autres bogues de la même façon.
1358 </p>
1359
1360 <figure link="/images/docs/bugzie-add-email.png" caption="Ajouter un email au
1361 CC"/>
1362
1363 <note>
1364 Les adresses électroniques doivent être enregistrées avec le Bugzilla Gentoo.
1365 Afin d'ajouter plusieurs adresses email, séparez-les simplement avec des
1366 virgules ou des espaces.
1367 </note>
1368
1369 <p>
1370 Après tout ce travail, le bogue peut passer par divers états. C'est généralement
1371 fait par les développeurs Gentoo et parfois par le rapporteur. Les valeurs
1372 suivantes sont les divers états possibles qu'un bogue peut avoir durant sa vie.
1373 </p>
1374
1375 <ul>
1376 <li>
1377 UNCONFIRMED (NdT&nbsp;: Non confirmé) - Vous ne le rencontrerez généralement
1378 pas souvent. Cela signifie qu'un rapporteur de bogue en a ouvert un en
1379 utilisant la méthode avancée et n'est pas certain que c'en est vraiment un.
1380 </li>
1381 <li>
1382 NEW (NdT&nbsp;: Nouveau) - Les bogues ouverts pour la première fois sont
1383 considérés comme nouveaux.
1384 </li>
1385 <li>
1386 ASSIGNED (NdT&nbsp;: Assigné) - Quand la personne à qui vous avez assigné
1387 votre bogue le valide, il va généralement recevoir le statut ASSIGNED le
1388 temps que les développeurs trouvent le problème. Ceci vous permet de savoir
1389 que votre bogue a été accepté comme un vrai bogue.
1390 </li>
1391 <li>
1392 REOPENED (NdT&nbsp;: Ré-ouvert) - Quelqu'un a résolu le bogue et vous pensez
1393 que la solution n'est pas faisable ou que le problème persiste. À ce
1394 moment-là, vous pouvez ré-ouvrir le bogue. <b>N'en abusez pas</b>
1395 s'il-vous-plaît. Si un développeur ferme un bogue une seconde ou troisième
1396 fois, il y a de grandes chances pour que votre bogue soit fermé.
1397 </li>
1398 <li>
1399 RESOLVED (NdT&nbsp;: Résolu) - Une décision a été prise au sujet du bogue.
1400 Ceci aboutit généralement au statut FIXED (NdT&nbsp;: corrigé) pour indiquer
1401 que le bogue est résolu et que le sujet est clos même si d'autres
1402 résolutions sont possibles. Nous allons y regarder en détail peu après.
1403 </li>
1404 <li>
1405 VERIFIED (NdT&nbsp;: Vérifié) - Les étapes de travail du bogue sont
1406 correctes. C'est généralement une histoire d'assurance qualité.
1407 </li>
1408 <li>
1409 CLOSED (NdT&nbsp;: Fermé) - Signifie simplement la fermeture du bogue qui
1410 est enterré sous le flux sans fin des nouveaux bogues.
1411 </li>
1412 </ul>
1413
1414 <p>
1415 Maintenant ci-dessous, nous trouvons l'erreur de le journal de strace,
1416 corrigeons le bogue, le marquons comme RESOLVED FIXED, mentionnons qu'il y a eu
1417 un changement de l'emplacement des fichiers de configuration, et mettons à jour
1418 l'ebuild avec un avertissement à ce propos. Le bogue est alors résolu, et il
1419 vous est affiché ceci&nbsp;:
1420 </p>
1421
1422 <figure link="/images/docs/bugzie-reso.png" caption="Bogue résolu"/>
1423
1424 <p>
1425 Un peu en dessous, vous allez voir ceci&nbsp;:
1426 </p>
1427
1428 <figure link="/images/docs/bugzie-options.png" caption="Options du bogue"/>
1429
1430 <p>
1431 Cela vous donne la possibilité de ré-ouvrir le bogue si vous le souhaitez (par
1432 exemple le développeur pense que c'est résolu mais ce n'est vraiment pas selon
1433 vos standards). Maintenant notre bogue est corrigé&nbsp;! Cependant, différentes
1434 résolutions peuvent arriver. En voici une courte liste&nbsp;:
1435 </p>
1436
1437 <ul>
1438 <li>
1439 FIXED (NdT&nbsp;: Corrigé) - le bogue est corrigé, suivez les instructions
1440 pour résoudre le problème.
1441 </li>
1442 <li>
1443 INVALID (NdT&nbsp;: Invalide) - Vous n'avez pas fait quelque chose de
1444 spécialement documenté, causant le bogue.
1445 </li>
1446 <li>
1447 DUPLICATE (NdT&nbsp;: Dupliqué) - Vous n'avez pas utilisé ce guide et avez
1448 rapporté un bogue dupliqué.
1449 </li>
1450 <li>
1451 WORKSFORME (NdT&nbsp;: Fonctionne pour moi) - Le développeur ou la personne
1452 assigné au bogue ne peut pas reproduire votre erreur.
1453 </li>
1454 <li>
1455 CANTFIX (NdT&nbsp;: Non corrigeable) - Le bogue ne peut pas être résolu à
1456 cause de certaines circonstances. Celles-ci seront notées par la personne
1457 prenant en charge le bogue.
1458 </li>
1459 <li>
1460 WONTFIX (NdT&nbsp;: Ne sera pas corrigé) - C'est souvent appliqué aux
1461 nouveaux ebuilds ou aux demandes de nouvelles fonctionnalités. Le
1462 développeur ne veut simplement pas ajouter une certaine fonctionnalité parce
1463 que ce n'est pas nécessaire, qu'une meilleure alternative existe, ou que ça
1464 ne fonctionne pas. Il vous sera parfois donné une solution pour considérer
1465 le problème résolu.
1466 </li>
1467 <li>
1468 UPSTREAM (NdT&nbsp;: En amont) - Le bogue ne peut pas être corrigé par
1469 l'équipe de développement de Gentoo, et ils vous demandent de signaler le
1470 problème en amont (les personnes ayant fait le programme) pour une révision.
1471 Ils ont quelques moyens pour la gestion des bogues. Ceux-ci inclus les
1472 listes de mails, les canaux IRC, et aussi des systèmes de rapport de bogue.
1473 Si vous n'êtes pas sûr de la manière de les contacter, demandez dans le
1474 bogue et quelqu'un vous donnera la direction à suivre.
1475 </li>
1476 </ul>
1477
1478 <p>
1479 Parfois, avant qu'un bogue soit résolu, un développeur peut vous demander de
1480 tester un ebuild mis à jour. Dans le chapitre suivant, nous allons voir comment
1481 faire cela.
1482 </p>
1483
1484 </body>
1485 </section>
1486 </chapter>
1487
1488 <chapter>
1489 <title>Test des ebuilds</title>
1490 <section>
1491 <title>Récupérer les fichiers</title>
1492 <body>
1493
1494 <p>
1495 Disons que vous avez rapporté un bogue pour la correction de l'erreur de
1496 compilation de foobar2 obtenue auparavant. À présent, les développeurs peuvent
1497 chercher quel est le problème et peuvent avoir besoin que vous testiez l'ebuild
1498 pour eux afin d'être sûr que celui-ci fonctionne également pour vous&nbsp;:
1499 </p>
1500
1501 <figure link="/images/docs/bugzie-ebuild-request.png" caption="Demande de test
1502 d'ebuild"/>
1503
1504 <p>
1505 Plusieurs termes de vocabulaire plutôt confus sont utilisés ici. Tout d'abord,
1506 voyons ce qu'est un «&nbsp;overlay&nbsp;» (NdT : ici, «&nbsp;surcouche&nbsp;»).
1507 Une surcouche est un répertoire spécial, comme <path>/usr/portage</path>, à la
1508 différence près que quand vous faites un <c>emerge sync</c>, les fichiers
1509 contenus à l'intérieur de celui-ci ne sont pas effacés. Heureusement, un
1510 répertoire spécial <path>/usr/local/portage</path> est créé dans ce but. Nous
1511 allons donc indiquer notre surcouche de Portage dans le fichier
1512 <path>/etc/make.conf</path>. Pour cela, ouvrez le fichier avec votre éditeur
1513 favori et ajoutez ceci vers la fin.
1514 </p>
1515
1516 <pre caption="Renseignement de la variable PORTDIR_OVERLAY">
1517 PORTDIR_OVERLAY="/usr/local/portage"
1518 </pre>
1519
1520 <p>
1521 Maintenant nous pouvons créer les répertoires appropriés pour mettre les
1522 fichiers de notre ebuild à tester. Dans le cas présent, nous sommes supposés
1523 les mettre dans le répertoire sys-apps/foobar2. Vous remarquerez que le second
1524 commentaire recommande un répertoire «&nbsp;files&nbsp;» pour le correctif. Le
1525 répertoire «&nbsp;files&nbsp;» contient les digests (sommes md5 des fichiers
1526 pour une version particulière du paquet) et d'autres fichiers requis qui ne sont
1527 pas inclus dans l'archive standard des sources (correctifs, scripts init.d...).
1528 Il s'agit d'un sous-répertoire dans le répertoire du paquet, qui est appelé
1529 «&nbsp;files&nbsp;». Nous allons donc créer ces répertoires.
1530 </p>
1531
1532 <pre caption="Création des répertoires de la catégorie et du paquet">
1533 # <i>mkdir -p /usr/local/portage/sys-apps/foobar2/files</i>
1534 </pre>
1535
1536 <note>
1537 L'option -p dans la commande mkdir permet de créer également les répertoires
1538 parents du répertoire que vous désirez s'ils n'existent pas (sys-apps et
1539 foobar2 dans ce cas).
1540 </note>
1541
1542 <p>
1543 Ok à présent, nous allons pouvoir récupérer les fichiers. D'abord,
1544 téléchargez l'ebuild dans <path>/usr/local/portage/sys-apps/foobar2</path>, et
1545 ajoutez alors le correctif (NdT&nbsp;: «&nbsp;patch&nbsp;») dans
1546 <path>/usr/local/portage/sys-apps/foobar2/files</path>. Maintenant que vous
1547 avons les fichiers, nous pouvons commencer à tester l'ebuild.
1548 </p>
1549
1550 </body>
1551 </section>
1552 <section>
1553 <title>Test de l'ebuild</title>
1554 <body>
1555
1556 <p>
1557 Le processus pour créer un ebuild qui peut être utilisé par emerge est assez
1558 simple. Vous devez créer un fichier Manifest et un fichier digest pour
1559 l'ebuild, grâce à la commande <c>ebuild</c>. Exécutez cette commande comme
1560 ceci&nbsp;:
1561 </p>
1562
1563 <pre caption="Création des fichiers Manifest et digest">
1564 # <i>ebuild foobar2-1.0.ebuild digest</i>
1565 &gt;&gt;&gt; Generating digest file...
1566 &lt;&lt;&lt; foobar2-1.0.tar.bz2
1567 &gt;&gt;&gt; Generating manifest file...
1568 &lt;&lt;&lt; foobar2-1.0.ebuild
1569 &lt;&lt;&lt; files/digest-foobar2-1.0
1570 &lt;&lt;&lt; files/foobar2-1.0-Makefile.patch
1571 &gt;&gt;&gt; Computed message digests.
1572 </pre>
1573
1574 <p>
1575 À présent, essayons de voir si cela marche comme prévu.
1576 </p>
1577
1578 <pre caption="Test avec emerge -pv">
1579 # <i>emerge -pv foobar2</i>
1580
1581 These are the packages that I would merge, in order:
1582
1583 Calculating dependencies ...done!
1584 [ebuild N ] sys-apps/foobar2-1.0 0 kB [1]
1585
1586 Total size of downloads: 0 kB
1587 Portage overlays:
1588 [1] /usr/local/portage
1589 </pre>
1590
1591 <p>
1592 Cela semble avoir fonctionné&nbsp;! Vous pourrez remarquer le [1] à côté de la
1593 ligne [ebuild]. Cela pointe vers <path>/usr/local/portage</path>, qui est la
1594 surcouche que vous avons créée auparavant. Maintenant allons-y et installons le
1595 paquet.
1596 </p>
1597
1598 <pre caption="Résultat de la commande emerge">
1599 # <i>emerge foobar2</i>
1600 Calculating dependencies ...done!
1601 <comment>(Informations de compilation coupées)</comment>
1602 >>> Unpacking foobar2-1.0.tar.bz2 to /var/tmp/portage/foobar2-1.0/work
1603 * Applying foobar2-1.0-Makefile.patch ... [ ok ]
1604 <comment>(Informations de compilation coupées)</comment>
1605 >>> Merging sys-apps/foobar2-1.0 to /
1606 >>> chris +sandbox(preinst)
1607 --- /usr/
1608 --- /usr/bin/
1609 >>> /usr/bin/foobar2
1610 </pre>
1611
1612 <p>
1613 Dans la première section nous voyons que la commande emerge a commencé comme il
1614 fallait. La seconde section montre que notre correctif a été appliqué avec
1615 succès grâce au message de statut [ ok ] sur la droite. La dernière section
1616 nous informe que la compilation du programme est réussie. Le correctif
1617 fonctionne&nbsp;! Nous pouvons donc prévenir les développeurs que leur correctif
1618 fonctionne correctement, et qu'ils peuvent l'envoyer dans l'arbre Portage.
1619 </p>
1620
1621 </body>
1622 </section>
1623 <section>
1624 <title>Conclusion</title>
1625 <body>
1626
1627 <p>
1628 Ceci conclut la documentation sur le fonctionnement du Bugzilla. J'espère que
1629 vous l'aurez trouvée utile. Si vous avez des questions, des commentaires ou des
1630 idées à propos de ce document, veuillez me les envoyer à
1631 <mail>chriswhite@g.o</mail>. Remerciements particuliers à moreon pour ses
1632 notes au sujet des options -g et des erreurs de compilations, aux personnes de
1633 #gentoo-bugs pour leur aide sur les querelles de bogues, à Griffon26 pour ses
1634 notes sur les indispensables mainteneurs, à robbat2 pour les suggestions d'ordre
1635 général et à fox2mike pour la correction de ce document et l'ajout des choses
1636 nécessaires.
1637 </p>
1638
1639 </body>
1640 </section>
1641 </chapter>
1642 </guide>
1643
1644
1645
1646 --
1647 gentoo-commits@g.o mailing list
Report Message
Find on MARC Find on Google Groups