1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
|
#use wml::debian::template title="Debian BTS — servidor de controle" NOHEADER=yes NOCOPYRIGHT=true
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
#use wml::debian::translation-check translation="eeaeaa4686ab3760dcfb69cfc7763efb9f48537b"
<h1>Introdução ao servidor de e-mail para controle e manipulação de bugs</h1>
<p>
Assim como <code>request@bugs.debian.org</code> permite a
<a href="server-request">obtenção de dados e documentação de bugs por e-mail</a>,
<code>control@bugs.debian.org</code> permite que os relatórios de bug sejam
manipulados de várias formas.
</p>
<p>
Caso você precise escrever uma mensagem para o bug e também manipular os
metadados do bug, os comandos também podem ser incluídos no e-mail para
<code>nnn@bugs.debian.org</code>. Faça isso iniciando o e-mail com os comandos
prefixados <code>Control: </code>.
Outra forma comum é enviar uma cópia do e-mail para
<code>control@bugs.debian.org</code> e iniciar o e-mail com comandos terminados
com <code>thanks</code>.
</p>
<p>
O servidor de controle funciona da mesma maneira que o servidor de
requisição, exceto por possuir comandos adicionais; de fato, é o mesmo
programa. Os dois endereços são separados somente para evitar que usuários(as)
cometam erros e causem problemas quando tentam meramente requisitar
informação.
</p>
<p>
Como os comandos específicos para o servidor de controle na realidade alteram o
estado de um bug, uma notificação sobre o processamento dos comandos
é enviado para o(a) mantenedor(a) do(s) pacote(s) cujos bugs alterados
estão designados. Adicionalmente, a mensagem para o servidor e as
alterações resultantes são registradas no relatório e portanto
disponibilizadas nas páginas WWW.
</p>
<p>
Por favor consulte a
<a href="server-request#introduction">introdução ao servidor de requisição</a>
disponível na World Wide Web, no arquivo
<code>bug-log-mailserver.txt</code>, ou enviando
<code>help</code> para qualquer servidor de e-mail, para detalhes básicos de
operações dos servidores de e-mail e para os comandos básicos disponíveis ao
enviar mensagens para qualquer um dos endereços.
</p>
<p>
O <a href="server-refcard">cartão de referência</a> para os servidores de
e-mail está disponível via WWW em <code>bug-mailserver-refcard.txt</code> ou
por e-mail usando o comando <code>refcard</code>.
</p>
<h1>Comandos disponíveis no servidor de e-mail de controle</h1>
<table style="margin-left:auto;margin-right:auto">
<tr>
<td align="center">Geral</td>
<td align="center">Versionamento</td>
<td align="center">Duplicados</td>
<td align="center">Outros</td>
</tr>
<tr>
<!-- Geral -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#reassign">reassign</a></li>
<li><a href="#severity">severity</a></li>
<li><a href="#tag">tags</a></li>
<li><a href="#retitle">retitle</a></li>
<li><a href="#submitter">submitter</a></li>
<li><a href="#affects">affects</a></li>
<li><a href="#summary">summary</a></li>
<li><a href="#outlook">outlook</a></li>
</ul>
</td>
<!-- Versionamento -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#found">found</a> | <a href="#notfound">notfound</a></li>
<li><a href="#fixed">fixed</a> | <a href="#notfixed">notfixed</a></li>
<li><a href="#reopen">reopen</a></li>
<!-- <dt>(close)</dt> Obsoleto -->
</ul>
</td>
<!-- Duplicados -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#merge">merge</a> | <a href="#unmerge">unmerge</a></li>
<li><a href="#forcemerge">forcemerge</a></li>
<li><a href="#clone">clone</a></li>
</ul>
</td>
<!-- Outros -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#thanks">thanks</a></li>
<li><a href="#comment">#</a></li>
<li><a href="#forwarded">forwarded</a> | <a href="#notforwarded">notforwarded</a></li>
<li><a href="#owner">owner</a> | <a href="#noowner">noowner</a></li>
<li><a href="#block">block</a> | <a href="#unblock">unblock</a></li>
<li><a href="#archive">archive</a> | <a href="#unarchive">unarchive</a></li>
<li><a href="server-request#user">user</a> |
<a href="server-request#usertag">usertag</a> |
<a href="server-request#usercategory">usercategory</a></li>
</ul>
</td>
</tr>
</table>
<dl>
<dt><a name="reassign"><code>reassign</code> <var>número-do-bug</var>
<var>pacote</var> [ <var>versão</var> ]</a></dt>
<dd>
<p>
Registra que o bug #<var>número-do-bug</var> é um bug no <var>pacote</var>.
Pode ser usado para definir o pacote caso o(a) usuário(a) tenha esquecido o
pseudocabeçalho ou para mudar uma atribuição anterior. Nenhuma notificação
é enviada para ninguém (a não ser a informação normal no processamento da
transcrição).
</p>
<p>
Se você fornecer uma <var>versão</var>, o sistema de acompanhamento de bugs
perceberá que o bug afeta aquela versão do pacote recém-atribuído.
</p>
<p>
Você pode atribuir um bug para dois pacotes de uma vez separando os
nomes dos pacotes com uma vírgula. <em>Entretanto</em>, você só deve
fazê-lo se o bug pode ser corrigido por uma mudança em
<em>qualquer</em> um dos pacotes. Se este não é o caso, você deve
<a href="#clone">clonar</a> o bug e o atribuir para o outro pacote.
</p>
</dd>
<dt><a name="reopen"><code>reopen</code> <var>número-do-bug</var>
[ <var>endereço-do(a)-relator(a)</var> | <code>=</code> | <code>!</code> ]</a></dt>
<dd>
<p>
Reabre #<var>número-do-bug</var> caso o mesmo esteja fechado.
</p>
<p>
Por padrão, ou se você especificar <code>=</code>, a pessoa que enviou
originalmente o relatório de bug continua como o(a) remetente do relatório,
assim a mesma poderá receber uma notificação quando o bug for fechado
novamente.
</p>
<p>
Caso você forneça um <var>endereço-do(a)-relator(a)</var> o(a) remetente
original será definido(a) como o endereço que você fornecer. Caso você
deseje tornar-se o(a) novo(a) remetente original do relatório reaberto, você
pode usar a abreviação <code>!</code> ou especificar seu próprio endereço de
e-mail.
</p>
<p>
Normalmente é uma boa ideia avisar à pessoa que está prestes a ser
registrada como o(a) relator(a) original que você está reabrindo o
relatório, assim ela estará avisada para esperar a notificação que receberá
quando o bug for fechado novamente.
</p>
<p>
Caso o bug não esteja fechado, reabrir o mesmo não resultará em nada, nem
mesmo mudar o(a) relator(a) original. Para alterar o(a) relator(a) original
de um relatório de bug aberto, use o comando <code>submitter</code>; note
que isto notificará o(a) relator(a) original sobre esta mudança.
</p>
<p>
Se o bug foi registrado como fechado em determinada versão de um pacote,
mas reapareceu em uma versão posterior, é melhor utilizar o comando
<code>found</code>.
</p>
</dd>
<dt><a name="found"><code>found</code> <var>número-do-bug</var> [
<var>versão</var> ]</a></dt>
<dd>
<p>
Registra que #<var>número-do-bug</var> foi encontrado em determinada
<var>versão</var> do pacote ao qual ele está atribuído.
A <var>versão</var> pode ser uma versão totalmente qualificada da
forma <var>nome-do-pacote-fonte/versão</var>.
</p>
<p>
O sistema de acompanhamento de bugs utiliza essa informação, em conjunto
com as versões corrigidas que são registradas quando bugs são fechados,
para exibir listas de bugs abertos em várias versões de cada pacote. O
sistema considera um bug como aberto quando não há uma versão corrigida,
ou quando o bug foi encontrado (found) mais recentemente do que havia
sido corrigido.
</p>
<p>
Caso nenhuma <var>versão</var> seja fornecida, então a lista de versões
corrigidas para o bug é esvaziada. Isto é idêntico ao comportamento do
<code>reopen</code>.
A <var>versão</var> pode ser uma versão totalmente qualificada da
forma <var>nome-do-pacote-fonte/versão</var>.
</p>
<p>
Este comando só fará com que um bug seja marcado como não concluído
se nenhuma versão for especificada, ou se a <var>versão</var> sendo marcada
como encontrada (found) é igual ou maior que a maior <var>versão</var>
que foi marcada como corrigida (fixed). (Se você tem certeza de que quer
o bug marcado como não concluído, use <code>reopen</code> em conjunto
com <code>found</code>).
</p>
<p>
Este comando foi introduzido como substituto do <code>reopen</code> porque
era difícil adicionar uma <var>versão</var> à sintaxe desse comando sem
sofrer ambiguidade.
</p>
</dd>
<dt><a name="notfound"><code>notfound</code> <var>número-do-bug</var>
<var>versão</var></a></dt>
<dd>
<p>
Remove o registro de que #<var>número-do-bug</var> foi encontrado em
determinada <var>versão</var> do pacote ao qual ele está atribuído.
A <var>versão</var> pode ser uma versão totalmente qualificada da
forma <var>nome-do-pacote-fonte/versão</var>.
</p>
<p>
Isso é diferente de fechar o bug na versão especificada, uma vez que o
bug também não está listado como corrigido naquela versão; nenhuma
informação sobre aquela versão será conhecida. O objetivo é corrigir
erros no registro de quando um bug foi encontrado.
</p>
</dd>
<dt><a name="fixed"><code>fixed</code> <var>número-do-bug</var>
<var>versão</var></a></dt>
<dd>
<p>
Indica que o bug #<var>número-do-bug</var> foi corrigido na
<var>versão</var> informada do pacote para o qual está designado.
A <var>versão</var> pode ser uma versão totalmente qualificada da
forma <var>nome-do-pacote-fonte/versão</var>.
</p>
<p>
Isto <em>não</em> faz com que o bug seja marcado como fechado,
isto apenas adiciona outra versão na qual o bug foi corrigido.
Use o endereço número-do-bug<code>-done</code> para fechar um bug e marcá-lo
como corrigido em uma versão particular.
</p>
</dd>
<dt><a name="notfixed"><code>notfixed</code> <var>número-do-bug</var>
<var>versão</var></a></dt>
<dd>
<p>
Remove o registro que o bug #<var>número-do-bug</var> foi corrigido
na <var>versão</var> informada.
A <var>versão</var> pode ser uma versão totalmente qualificada da
forma <var>nome-do-pacote-fonte/versão</var>.
</p>
<p>
Este comando é equivalente ao <code>found</code> seguido pelo
<code>notfound</code> (o <q>found</q> remove o estado de corrigido de
uma versão particular e o <q>notfound</q> remove o <q>found</q>) com a
exceção que o bug não é reaberto se a versão encontrada é maior que
qualquer versão corrigida existente. O objetivo é corrigir erros no registro
de quando um bug foi encontrado; na maioria dos casos, o que você realmente
quer é <code>found</code>, e não <code>notfixed</code>.
</p>
</dd>
<dt><a name="submitter"><code>submitter</code> <var>número-do-bug</var>
<var>endereço-do(a)-relator(a)</var> | <code>!</code></a></dt>
<dd>
<p>
Altera o(a) relator(a) original do #<var>número-do-bug</var> para
<var>endereço-do(a)-relator(a)</var>.
</p>
<p>
Se você deseja ser o(a) novo(a) remetente original do relatório você pode
usar a abreviação <code>!</code> ou especificar seu próprio endereço de
e-mail.
</p>
<p>
Enquanto o comando <code>reopen</code> altera o(a) relator(a) original dos
outros bugs unidos (merged) com o que está sendo aberto novamente, o
<code>submitter</code> não afeta bugs unidos.
</p>
</dd>
<dt><a name="forwarded"><code>forwarded</code> <var>número-do-bug</var>
<var>endereço</var></a></dt>
<dd>
<p>
Marca que <var>número-do-bug</var> foi encaminhado para o(a) desenvolvedor(a)
original em <var>endereço</var>. Isto na verdade não encaminha o relatório.
Isso pode ser usado para modificar um endereço de encaminhamento incorreto
existente, ou para registrar um novo endereço para um bug que não foi
anteriormente marcado como tendo sido encaminhado. O <var>endereço</var>
geralmente deveria ser uma URI, ou possivelmente um endereço de e-mail.
Use uma URI onde for possível para permitir que as ferramentas consultem
um sistema de acompanhamento de bugs remoto (como bugzilla) para saber o
estado de um bug.
</p>
<p>
Exemplo de uso:
</p>
<pre>
forwarded 12345 http://bugz.illa.foo/cgi/54321
</pre>
</dd>
<dt><a name="notforwarded"><code>notforwarded</code>
<var>número-do-bug</var></a></dt>
<dd>
<p>
Esquece qualquer vestígio de que o <var>número-do-bug</var> foi encaminhado
para qualquer desenvolvedor(a) original. Caso o bug não tenha sido marcado
como tendo sido encaminhado então isso não causará nada.
</p>
</dd>
<dt><a name="retitle"><code>retitle</code> <var>número-do-bug</var>
<var>novo-título</var></a></dt>
<dd>
<p>
Muda o título de um relatório de bug (o padrão é
o cabeçalho <code>Subject</code> (<code>Assunto</code>) da mensagem do
relatório original).
Também mudará os títulos de todos os relatórios de bug em que este bugs
estejam unidos (merged).
</p>
</dd>
<dt><a name="severity"><code>severity</code> <var>número-do-bug</var>
<var>severidade</var></a></dt>
<dd>
<p>
Define o nível de severidade para o relatório de bug #<var>número-do-bug
</var> para <var>severidade</var>. Nenhuma notificação é enviada para o(a)
usuário(a) que reportou o bug.
</p>
<p>
As severidades são <bts_severities>.
</p>
<p>
Para <a href="Developer#severities">os significados das severidades</a>, por
favor, consulte a documentação geral dos(as) desenvolvedores(as) sobre o
sistema de bugs.
</p>
</dd>
<dt><a name="affects"><code>affects</code> <var>número-do-bug</var>
[ <code>+</code> | <code>-</code> | <code>=</code>
] <var>pacote</var> [ <var>pacote</var> ... ]</a></dt>
<dd>
<p>
Indica que um bug afeta outro pacote. No caso onde o
<var>numero-do-bug</var> causa quebra no <var>pacote</var> apesar de que o
bug está realmente presente no pacote para qual foi atribuído, isto faz
com que o bug seja listado por padrão na lista de bugs do <var>pacote</var>.
Isto geralmente deve ser usado quando o bug é grave o suficiente para
causar vários relatos de usuários(as) que está atribuído ao pacote errado.
O <code>=</code> define os efeitos na lista de pacotes fornecida,
e é a ação padrão se nenhum pacote foi fornecido; o
<code>-</code> remove os pacotes fornecidos da lista de efeitos; o
<code>+</code> adiciona os pacotes fornecidos na lista de efeitos, e é o
padrão se pacotes são fornecidos.
</p>
</dd>
<dt><a name="summary"><code>summary</code> <var>número-do-bug</var>
[<var>número-da-mensagem</var> | <var>texto do resumo</var>]</a></dt>
<dd>
<p>
Seleciona uma mensagem para usar como um resumo de um bug. O primeiro
parágrafo que não é um pseudocabeçalho/controle dessa mensagem é
analisado e definido como o resumo do bug, que é apresentado na parte
superior da página do relatório de bug. Isto é útil nos casos em que
o relatório original não descreve corretamente o problema ou o bug tem
muitas mensagens que tornam difícil identificar o problema real.
</p>
<p>
Se o <var>número-da-mensagem</var> não é dado, limpa o resumo. O
<var>número-da-mensagem</var> é o número da mensagem como
listada na saída do script cgi do relatório do bug; se
um <var>número-da-mensagem</var> igual a 0 é dado, a mensagem atual
é utilizada (isto é, a mensagem que foi enviada para o
control@bugs.debian.org que contém o resumo do comando de controle).
</p>
<p>
Se <var>número-da-mensagem</var> não é numérico e não é uma cadeia de
caracteres vazia, presume-se que seja o texto para definir o resumo.
</p>
</dd>
<dt><a name="outlook"><code>outlook</code> <var>número-do-bug</var>
[<var>número-da-mensagem</var> | <var>texto da observação</var>]</a></dt>
<dd>
<p>
Selecione uma mensagem para usar como observação (outlook) de correção de
um bug (ou a situação atual da correção de um bug). O primeiro parágrafo
que não é um pseudocabeçalho/controle dessa mensagem é analisado
e definido como a observação do bug que é que é apresentado na parte
superior da página do relatório de bug. Isso é útil para coordenar com
outras pessoas que estão trabalhando na correção do bug (por exemplo, em
uma festa de caça a bugs).
</p>
<p>
Se <var>número-da-mensagem</var> não é fornecido, limpa a observação.
O <var>número-da-mensagem</var> é o número da mensagem como
listada na saída do script cgi do relatório do bug; se
um <var>número-da-mensagem</var> igual a 0 é dado, a mensagem atual
é utilizada (isto é, a mensagem que foi enviada para o
control@bugs.debian.org que contém a observação do comando de controle).
</p>
<p>
Se <var>número-da-mensagem</var> não é numérico e não é uma cadeia de
caracteres vazia, presume-se que seja o texto para definir a observação.
</p>
</dd>
<dt><a name="clone"><code>clone</code> <var>número-do-bug</var>
<var>NovoID</var> [ <var>Novos IDs</var> ... ]</a></dt>
<dd>
<p>
O comando de controle clone permite duplicar um relatório de bug. Ele é
útil quando um único relatório na verdade indica que múltiplos bugs
distintos ocorreram. <q><var>Novos IDs</var></q> são números negativos,
separados por espaços, que podem ser usados em comandos de controle
subsequentes para se referir aos novos bugs duplicados. Um novo relatório
é gerado para cada novo ID.
</p>
<p>
Exemplo de uso:
</p>
<pre>
clone 12345 -1 -2
reassign -1 foo
retitle -1 foo: foo fede
reassign -2 bar
retitle -2 bar: bar fede quando usado com foo
severity -2 wishlist
clone 123456 -3
reassign -3 foo
retitle -3 foo: foo fede
merge -1 -3
</pre>
## portuguese only
<p>
Lembre-se de escrever o seu relatório de bug em inglês. Se precisar de
ajuda você pode enviar uma mensagem para
<email "debian-devel-portuguese@lists.debian.org"> ou para
<email "debian-l10n-portuguese@lists.debian.org">.
</p>
## /portuguese
</dd>
<dt><a name="merge"><code>merge</code> <var>número-do-bug</var>
<var>número-do-bug</var> ...</a></dt>
<dd>
<p>
Une dois ou mais relatórios de bug. Quando relatórios são unidos: abrir,
fechar, marcar ou desmarcar como encaminhados, e reatribuir quaisquer dos
bugs para um novo pacote, terá o efeito idêntico em todos os relatórios
que foram unidos.
</p>
<p>
Antes que os bugs possam ser unidos, os mesmos precisam estar exatamente
no mesmo estado: ou todos são bugs abertos, ou todos são bugs fechados, com
o mesmo endereço de encaminhamento para o(a) autor(a) original ou todos não
marcados como encaminhados, todos atribuídos para o(s) mesmo(s) pacote(s)
(uma comparação exata de cadeia de caracteres é feita no pacote para o qual
o bug está atribuído), e todos da mesma severidade.
Caso os mesmos não estejam inicialmente no mesmo estado você deve usar
<code>reassign</code>, <code>reopen</code> e assim por diante para
certificar-se de que os mesmos estejam no mesmo estado antes de usar
<code>merge</code>. Os títulos não precisam ser os mesmos, e não serão
afetados pela unificação. As tags também não precisam ser as mesmas,
elas serão unidas.
</p>
<p>
Caso qualquer um dos bugs listados em um comando <code>merge</code> já
esteja unido com um outro bug, todos os relatórios unidos com quaisquer um
dos relatórios listados serão todos unidos. Unir é como a igualdade: é
reflexivo, transitivo e simétrico.
</p>
<p>
Unir relatórios faz com que uma nota apareça no registro de cada relatório
de bug; nas páginas WWW isto faz com que sejam incluídos links para os
outros bugs.
</p>
<p>
Relatórios unidos são todos expirados simultaneamente e somente quando
todos os relatórios separadamente atinjam os critérios para expiração.
</p>
</dd>
<dt><a name="forcemerge"><code>forcemerge</code> <var>número-do-bug</var>
<var>número-do-bug</var> ...</a></dt>
<dd>
<p>
Une forçadamente dois ou mais relatórios de bug. As configuração do primeiro
bug listado, que deve ser igual à configuração de outros bugs numa união
normal, agora é atribuída aos bugs listados em seguida. As tags são unidas
normalmente. Para evitar que erros de digitação unam bugs incorretamente, os
bugs precisam estar no mesmo pacote. Veja o texto acima para uma descrição
do que união significa.
</p>
<p>
Note que isto torna possível o fechamento de bugs na união; você é
responsável por notificar os(as) relatores(as) dos bugs com uma mensagem de
fechamento apropriada se você fizer isto.
</p>
</dd>
<dt><a name="unmerge"><code>unmerge</code> <var>número-do-bug</var></a></dt>
<dd>
<p>
Desconecta um relatório de bug de quaisquer outros relatórios com os quais
o relatório em questão possa ter sido unido. Caso o relatório listado seja
unido com diversos outros, então os mesmos serão todos mantidos unidos;
somente suas associações com o bug explicitamente nomeado serão removidas.
</p>
<p>
Caso muitos relatórios de bugs sejam unidos e você deseje separá-los em
dois grupos de relatórios unidos, você deve desconectar cada
relatório em um dos novos grupos separadamente e então uni-los na forma
do novo grupo desejado.
</p>
<p>
Você pode somente desconectar um relatório com cada comando
<code>unmerge</code>; caso você queira desconectar mais de um bug
simplesmente inclua diversos comandos <code>unmerge</code> em sua
mensagem.
</p>
</dd>
<dt><a name="tags"><!-- match tags too --></a><a name="tag"><code>tags</code> <var>número-do-bug</var> [ <code>+</code> |
<code>-</code> | <code>=</code> ] <var>tag</var> [ <var>tag</var>
... ] [ <code>+</code> | <code>-</code>
| <code>=</code> <var>tag</var> ... ] ]</a></dt>
<dd>
<p>
Define tags para o relatório de bug #<var>número-do-bug</var>. Nenhuma
notificação é enviada para o(a) usuário(a) que relatou o bug. Definir a ação
como <code>+</code> significa adicionar cada <var>tag</var> seguinte,
<code>-</code> significa remover cada <var>tag</var> seguinte,
e <code>=</code> significa marcar as tags seguintes para a lista fornecida.
Intervir com <code>+</code>, <code>-</code>, ou <code>=</code> muda a ação
das tags seguintes. A ação padrão é adicionar.
</p>
<p>
Exemplo de uso:
</p>
<pre>
\# o mesmo que 'tags 123456 + patch'
tags 123456 patch
\# o mesmo que 'tags 123456 + help security'
tags 123456 help security
\# adiciona as tags 'fixed' e 'pending'
tags 123456 + fixed pending
\# remove a tag 'unreproducible'
tags 123456 - unreproducible
\# define as tags exatamente como 'moreinfo' e 'unreproducible'
tags 123456 = moreinfo unreproducible
\# remove a tag 'moreinfo' e adiciona a tag 'patch'
tags 123456 - moreinfo + patch
</pre>
<p>
As tags disponíveis atualmente incluem <bts_tags>.
</p>
<p>
Para <a href="Developer#tags">os significados das tags</a>, por favor,
consulte a documentação geral dos(as) desenvolvedores(as) sobre o sistema de
bugs.
</p>
</dd>
<dt><a name="block"><code>block</code> <var>número-do-bug</var>
<code>by</code> <var>bug</var> ...</a></dt>
<dd>
Note que a correção para o primeiro bug está bloqueada pelos outros bugs
listados.
</dd>
<dt><a name="unblock"><code>unblock</code> <var>número-do-bug</var>
<code>by</code> <var>bug</var> ...</a></dt>
<dd>
Note que a correção para o primeiro bug deixou de estar bloqueada pelos
outros bugs listados.
</dd>
<dt><a name="close"><code>close</code> <var>número-do-bug</var>
[ <var>versão-corrigida</var> ] (obsoleto)</a></dt>
<dd>
<p>
Fecha o relatório de bug #<var>número-do-bug</var>.
</p>
<p>
Uma notificação é enviada para o(a) usuário(a) que relatou o bug, mas (ao
contrário do envio de uma mensagem para
<var>número-do-bug</var><code>-done@bugs.debian.org</code>) o texto da
mensagem que fechou o bug <strong>não</strong> é incluído na notificação.
O(A) mantenedor(a) que fecha o relatório precisa certificar-se,
provavelmente enviando uma mensagem separada, que o(a) usuário(a) que
reportou o bug fique sabendo a razão pela qual o bug está sendo fechado. O
uso deste comando é, portanto, obsoleto. Veja as informações para
desenvolvedores(as) sobre
<a href="Developer#closing">como fechar um bug corretamente</a>.
</p>
<p>
Se você fornecer uma <var>versão-corrigida</var>, o sistema de
acompanhamento de bugs perceberá que o bug foi corrigido para aquela
versão do pacote.
</p>
</dd>
<dt><a name="package"><code>package</code> [ <var>nome-do-pacote</var> ...
]</a></dt>
<dd>
<p>
Limita os próximos comandos, fazendo com que eles sejam aplicados
somente em erros relativos aos pacotes listados. Você pode listar um ou
mais pacotes. Se você não listar nenhum pacote, os próximos comandos
serão aplicados em todos os bugs. Você é encorajado(a) a usar isto como uma
medida de segurança para o caso de você, acidentalmente, usar os números
errados dos relatórios de bug.
</p>
<p>
Exemplo de uso:
</p>
<pre>
package foo
reassign 123456 bar 1.0-1
package bar
retitle 123456 bar: bar fede
severity 123456 normal
package
severity 234567 wishlist
</pre>
</dd>
<dt><a name="owner"><code>owner</code> <var>número-do-bug</var>
<var>endereço</var> | <code>!</code></a></dt>
<dd>
<p>
Define <var>endereço</var> como dono(a) do #<var>número-do-bug</var>.
O(A) dono(a) de um bug reivindica a responsabilidade de corrigi-lo.
Isto é útil para dividir o trabalho em
pacotes que possuem equipes de mantenedores(as).
</p>
<p>
Se você quer se tornar o(a) dono(a) de um bug, você pode usar a abreviação
<code>!</code> ou especificar seu endereço de e-mail.
</p>
</dd>
<dt><a name="noowner"><code>noowner</code> <var>número-do-bug</var></a></dt>
<dd>
Remove qualquer dono(a) que o bug tenha além do(a) mantenedor(a) usual. Se
o bug não tiver algum(a) dono(a) registrado(a), esta opção não fará nada.
</dd>
<dt><a name="archive"><code>archive</code> <var>número-do-bug</var></a></dt>
<dd>
Arquiva um bug que foi arquivado em algum momento no passado, mas que
atualmente não está arquivado, se o bug preencher os requisitos para
arquivamento, e ignorando o tempo.
</dd>
<dt><a name="unarchive"><code>unarchive</code>
<var>número-do-bug</var></a></dt>
<dd>
Desarquiva um bug que foi previamente arquivado. Desarquivar deve ser
geralmente acompanhado com <code>reopen</code> e <code>found/fixed</code>
conforme for apropriado. Bugs que foram desarquivados podem ser arquivados
usando <code>archive</code>, assumindo
que os requisitos de arquivamento não baseados em tempo sejam atendidos.
Você não deve desarquivar para fazer mudanças triviais em um bug arquivado,
como por exemplo mudar o(a) relator(a) original; o propósito primário é
permitir a reabertura de bugs que foram arquivados sem a intervenção dos(as)
administradores(as) do BTS.
</dd>
<dt><a name="comment"><code>#</code>...</a></dt>
<dd>
Comentário de uma linha. O <code>#</code> precisa estar no começo da
linha. O texto dos comentários será incluído na mensagem de confirmação
enviada para o(a) remetente e para os(as) mantenedores(as) afetados(as),
portanto você pode utilizar isto para documentar as razões de seus comandos.
</dd>
<dt><a name="thanks"><code>quit</code></a></dt>
<dt><code>stop</code></dt>
<dt><code>thank</code></dt>
<dt><code>thanks</code></dt>
<dt><code>thankyou</code></dt>
<dt><code>thank you</code></dt>
<dt><code>--</code></dt>
<!-- #366093, I blame you! -->
<!-- <dt><code>kthxbye</code></dt> -->
<!-- See... I documented it! -->
<dd>
Em uma linha sozinha, em qualquer caso, possivelmente seguido por um
espaço em branco, informa ao servidor de controle para parar de
processar a mensagem; no restante da mensagem é possível incluir explicações,
assinaturas ou qualquer outra coisa, porque nada disso será detectado
pelo servidor de controle.
</dd>
</dl>
<hr />
#use "otherpages.inc"
#use "$(ENGLISHDIR)/Bugs/footer.inc"
|