Introdução ao servidor de e-mail para controle e manipulação de bugs
Assim como request@bugs.debian.org
permite a
obtenção de dados e documentação de bugs por e-mail,
control@bugs.debian.org
permite que os relatórios de bug sejam
manipulados de várias formas.
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
nnn@bugs.debian.org
. Faça isso iniciando o e-mail com os comandos
prefixados Control:
.
Outra forma comum é enviar uma cópia do e-mail para
control@bugs.debian.org
e iniciar o e-mail com comandos terminados
com thanks
.
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.
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.
Por favor consulte a
introdução ao servidor de requisição
disponível na World Wide Web, no arquivo
bug-log-mailserver.txt
, ou enviando
help
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.
O cartão de referência para os servidores de
e-mail está disponível via WWW em bug-mailserver-refcard.txt
ou
por e-mail usando o comando refcard
.
Comandos disponíveis no servidor de e-mail de controle
Geral | Versionamento | Duplicados | Outros |
reassign
número-do-bug pacote [ versão ]-
Registra que o bug #número-do-bug é um bug no pacote. 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).
Se você fornecer uma versão, o sistema de acompanhamento de bugs perceberá que o bug afeta aquela versão do pacote recém-atribuído.
Você pode atribuir um bug para dois pacotes de uma vez separando os nomes dos pacotes com uma vírgula. Entretanto, você só deve fazê-lo se o bug pode ser corrigido por uma mudança em qualquer um dos pacotes. Se este não é o caso, você deve clonar o bug e o atribuir para o outro pacote.
reopen
número-do-bug [ endereço-do(a)-relator(a) |=
|!
]-
Reabre #número-do-bug caso o mesmo esteja fechado.
Por padrão, ou se você especificar
=
, 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.Caso você forneça um endereço-do(a)-relator(a) 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
!
ou especificar seu próprio endereço de e-mail.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.
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
submitter
; note que isto notificará o(a) relator(a) original sobre esta mudança.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
found
. found
número-do-bug [ versão ]-
Registra que #número-do-bug foi encontrado em determinada versão do pacote ao qual ele está atribuído. A versão pode ser uma versão totalmente qualificada da forma nome-do-pacote-fonte/versão.
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.
Caso nenhuma versão seja fornecida, então a lista de versões corrigidas para o bug é esvaziada. Isto é idêntico ao comportamento do
reopen
. A versão pode ser uma versão totalmente qualificada da forma nome-do-pacote-fonte/versão.Este comando só fará com que um bug seja marcado como não concluído se nenhuma versão for especificada, ou se a versão sendo marcada como encontrada (found) é igual ou maior que a maior versão que foi marcada como corrigida (fixed). (Se você tem certeza de que quer o bug marcado como não concluído, use
reopen
em conjunto comfound
).Este comando foi introduzido como substituto do
reopen
porque era difícil adicionar uma versão à sintaxe desse comando sem sofrer ambiguidade. notfound
número-do-bug versão-
Remove o registro de que #número-do-bug foi encontrado em determinada versão do pacote ao qual ele está atribuído. A versão pode ser uma versão totalmente qualificada da forma nome-do-pacote-fonte/versão.
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.
fixed
número-do-bug versão-
Indica que o bug #número-do-bug foi corrigido na versão informada do pacote para o qual está designado. A versão pode ser uma versão totalmente qualificada da forma nome-do-pacote-fonte/versão.
Isto não 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
-done
para fechar um bug e marcá-lo como corrigido em uma versão particular. notfixed
número-do-bug versão-
Remove o registro que o bug #número-do-bug foi corrigido na versão informada. A versão pode ser uma versão totalmente qualificada da forma nome-do-pacote-fonte/versão.
Este comando é equivalente ao
found
seguido pelonotfound
(ofound
remove o estado de corrigido de uma versão particular e onotfound
remove ofound
) 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 éfound
, e nãonotfixed
. submitter
número-do-bug endereço-do(a)-relator(a) |!
-
Altera o(a) relator(a) original do #número-do-bug para endereço-do(a)-relator(a).
Se você deseja ser o(a) novo(a) remetente original do relatório você pode usar a abreviação
!
ou especificar seu próprio endereço de e-mail.Enquanto o comando
reopen
altera o(a) relator(a) original dos outros bugs unidos (merged) com o que está sendo aberto novamente, osubmitter
não afeta bugs unidos. forwarded
número-do-bug endereço-
Marca que número-do-bug foi encaminhado para o(a) desenvolvedor(a) original em endereço. 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 endereço 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.
Exemplo de uso:
forwarded 12345 http://bugz.illa.foo/cgi/54321
notforwarded
número-do-bug-
Esquece qualquer vestígio de que o número-do-bug 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.
retitle
número-do-bug novo-título-
Muda o título de um relatório de bug (o padrão é o cabeçalho
Subject
(Assunto
) 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). severity
número-do-bug severidade-
Define o nível de severidade para o relatório de bug #número-do-bug para severidade. Nenhuma notificação é enviada para o(a) usuário(a) que reportou o bug.
As severidades são
critical
,grave
,serious
,important
,normal
,minor
,wishlist
.Para os significados das severidades, por favor, consulte a documentação geral dos(as) desenvolvedores(as) sobre o sistema de bugs.
affects
número-do-bug [+
|-
|=
] pacote [ pacote ... ]-
Indica que um bug afeta outro pacote. No caso onde o numero-do-bug causa quebra no pacote 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 pacote. 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
=
define os efeitos na lista de pacotes fornecida, e é a ação padrão se nenhum pacote foi fornecido; o-
remove os pacotes fornecidos da lista de efeitos; o+
adiciona os pacotes fornecidos na lista de efeitos, e é o padrão se pacotes são fornecidos. summary
número-do-bug [número-da-mensagem | texto do resumo]-
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.
Se o número-da-mensagem não é dado, limpa o resumo. O número-da-mensagem é o número da mensagem como listada na saída do script cgi do relatório do bug; se um número-da-mensagem 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).
Se número-da-mensagem não é numérico e não é uma cadeia de caracteres vazia, presume-se que seja o texto para definir o resumo.
outlook
número-do-bug [número-da-mensagem | texto da observação]-
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).
Se número-da-mensagem não é fornecido, limpa a observação. O número-da-mensagem é o número da mensagem como listada na saída do script cgi do relatório do bug; se um número-da-mensagem 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).
Se número-da-mensagem não é numérico e não é uma cadeia de caracteres vazia, presume-se que seja o texto para definir a observação.
clone
número-do-bug NovoID [ Novos IDs ... ]-
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.
Novos IDs
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.Exemplo de uso:
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
Lembre-se de escrever o seu relatório de bug em inglês. Se precisar de ajuda você pode enviar uma mensagem para debian-devel-portuguese@lists.debian.org ou para debian-l10n-portuguese@lists.debian.org.
merge
número-do-bug número-do-bug ...-
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.
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
reassign
,reopen
e assim por diante para certificar-se de que os mesmos estejam no mesmo estado antes de usarmerge
. 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.Caso qualquer um dos bugs listados em um comando
merge
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.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.
Relatórios unidos são todos expirados simultaneamente e somente quando todos os relatórios separadamente atinjam os critérios para expiração.
forcemerge
número-do-bug número-do-bug ...-
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.
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.
unmerge
número-do-bug-
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.
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.
Você pode somente desconectar um relatório com cada comando
unmerge
; caso você queira desconectar mais de um bug simplesmente inclua diversos comandosunmerge
em sua mensagem. tags
número-do-bug [+
|-
|=
] tag [ tag ... ] [+
|-
|=
tag ... ] ]-
Define tags para o relatório de bug #número-do-bug. Nenhuma notificação é enviada para o(a) usuário(a) que relatou o bug. Definir a ação como
+
significa adicionar cada tag seguinte,-
significa remover cada tag seguinte, e=
significa marcar as tags seguintes para a lista fornecida. Intervir com+
,-
, ou=
muda a ação das tags seguintes. A ação padrão é adicionar.Exemplo de uso:
# 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
As tags disponíveis atualmente incluem
patch
,wontfix
,moreinfo
,unreproducible
,help
,security
,upstream
,pending
,confirmed
,ipv6
,lfs
,d-i
,l10n
,newcomer
,a11y
,ftbfs
,fixed-upstream
,fixed
,fixed-in-experimental
,potato
,woody
,sarge
,etch
,lenny
,squeeze
,wheezy
,jessie
,stretch
,buster
,bullseye
,bookworm
,trixie
,forky
,sid
,experimental
,sarge-ignore
,etch-ignore
,lenny-ignore
,squeeze-ignore
,wheezy-ignore
,jessie-ignore
,stretch-ignore
,buster-ignore
,bullseye-ignore
,bookworm-ignore
,trixie-ignore
forky-ignore
.Para os significados das tags, por favor, consulte a documentação geral dos(as) desenvolvedores(as) sobre o sistema de bugs.
block
número-do-bugby
bug ...- Note que a correção para o primeiro bug está bloqueada pelos outros bugs listados.
unblock
número-do-bugby
bug ...- Note que a correção para o primeiro bug deixou de estar bloqueada pelos outros bugs listados.
close
número-do-bug [ versão-corrigida ] (obsoleto)-
Fecha o relatório de bug #número-do-bug.
Uma notificação é enviada para o(a) usuário(a) que relatou o bug, mas (ao contrário do envio de uma mensagem para número-do-bug
-done@bugs.debian.org
) o texto da mensagem que fechou o bug não é 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 como fechar um bug corretamente.Se você fornecer uma versão-corrigida, o sistema de acompanhamento de bugs perceberá que o bug foi corrigido para aquela versão do pacote.
package
[ nome-do-pacote ... ]-
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.
Exemplo de uso:
package foo reassign 123456 bar 1.0-1 package bar retitle 123456 bar: bar fede severity 123456 normal package severity 234567 wishlist
owner
número-do-bug endereço |!
-
Define endereço como dono(a) do #número-do-bug. 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).
Se você quer se tornar o(a) dono(a) de um bug, você pode usar a abreviação
!
ou especificar seu endereço de e-mail. noowner
número-do-bug- 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.
archive
número-do-bug- 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.
unarchive
número-do-bug-
Desarquiva um bug que foi previamente arquivado. Desarquivar deve ser
geralmente acompanhado com
reopen
efound/fixed
conforme for apropriado. Bugs que foram desarquivados podem ser arquivados usandoarchive
, 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. #
...-
Comentário de uma linha. O
#
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. quit
stop
thank
thanks
thankyou
thank you
--
- 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.
Other BTS pages:
- Página principal dos conteúdos do sistema de gerenciamento de bugs.
- Instruções para reportar bugs.
- Acessando os logs do sistema de gerenciamento de bugs.
- Informações para desenvolvedor(a) no sistema de gerenciamento de bugs.
- Informações do(a) desenvolvedor(a) na manipulação de bugs usando a interface de controle de e-mail.
- Cartão de referência de servidores de mail.
- Requisitando reports de bug pelo e-mail.
Debian BTS administrators <owner@bugs.debian.org>
Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
1994-1997 Ian Jackson.