[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[wml]



olá, aí estao algumas correcoes que eu fiz, espero que tenha feito da maneira correta, estas foram as primeiras modificacoes que eu fiz, por isso nao sei se é assim mesmo que se faz. Peco que qualquer erro que eu tenha cometido me avisem para eu nao fazer mais. De noite eu corrigo os outros arquivos. Uma observacao os erros :
Line 354, character 13:  document type does not allow element "A" here
Line 355, character 6:  document type does not allow element "LI" here
Line 355, character 31:  document type does not allow element "A" here
Line 357, character 6: document type does not allow element "LI" here; missing one of "UL", "OL", "DIR", "MENU" start-tag
Line 357, character 31:  document type does not allow element "A" here
Line 358, character 6: document type does not allow element "LI" here; missing one of "UL", "OL", "DIR", "MENU" start-tag
Line 358, character 31:  document type does not allow element "A" here
Line 359, character 5: end tag for "A" omitted, but its declaration does not permit this Line 359, character 5: end tag for "A" omitted, but its declaration does not permit this Estao presentes no log de todos os arquivos, porem nao existe no proprio arquivo, entao imagino que seja de algum template incluso.... que eu ainda nao consegui identificar.. mas pela noite, com mais tempo eu procuro. Espero ter ajudado. --Sheldon--




--
POP. Nem parece internet grátis.
Seja POP você também!
Acesse: http://www.pop.com.br/pop_discador.php e baixe o POPdiscador.
#use wml::debian::template title="Debian BTS - métodos de acesso" NOHEADER=yes NOCOPYRIGHT=true
#use wml::debian::translation-check translation="1.16" translation_maintainer="André Luís Lopes"

# the explicit links to http://bugs.debian.org/ without anchors are
# included because of the text version, do not remove them

<h1>Métodos de acesso aos logs do Sistema de Gerenciamento de Bugs</h1>

<h2>Accessando relatórios de bugs ativos</h2>

<p>Cada mensagem recebida em ou enviada pelo sistema de gerenciamento
de bugs é logada e tornada disponível de diversas maneiras.</p>

<p>O método primário de acesso é usar as páginas web. Veja as maneiras
na <a href="./">página principal do BTS</a> em
<code>http://bugs.debian.org/</code>

<p>Existe um <a href="server-request">servidor de e-mails</a> que pode
enviar relatórios de bugs como texto puro mediante requisições. Para usá-lo
envie a palavra <code>help</code> como o único conteúdo de um e-mail para
<code>request@bugs.debian.org</code> (o <code>Assunto</code> da
mensagem é ignorado), ou leia as instruções <a href="server-request">na
World Wide Web</a> ou no arquivo <code>bug-log-mailserver.txt</code>.

<h2>Accessando relatórios de bugs arquivados</h2>

<p>Cada relatório de bug fechado é arquivado 28 dias depois que a última
mensagem relacionada ao mesmo seja recebida e arquivada. Isto significa
que não é mais possível acessá-lo ou mudar qualquer coisa sobre o mesmo
usando os bots <code>control</code> e <code>service</code>. Porém, os
relatórios continuam acessíveis para visualização.

<p>Você pode procurar pelo arquivo de relatório de bugs usando os
<a href="./">formulários WWW</a> em <code>http://bugs.debian.org/</code>,
simplesmente selecione a opção "bugs arquivados".

<p>Note que o mesmo não contém os relatórios de bugs fechados mais antigos,
somente aqueles depois de #40000, aproximadamente.

<hr>

#use "otherpages.inc"

#use "$(ENGLISHDIR)/Bugs/footer.inc"
#use wml::debian::template title="Debian BTS - informação para desenvolvedores" NOHEADER=yes NOCOPYRIGHT=true
#use wml::debian::translation-check translation="1.34" 

<H1>Informações para Desenvolvedores sobre o sistema de processamento de bugs</H1>

<P>Inicialmente, um relatório de bug é enviado por um usuário como
uma mensagem de e-mail comum para <CODE>submit@bugs.debian.org</CODE>.
Um número é então atribuído ao relatório, informado ao usuário, e
encaminhado para <CODE>debian-bugs-dist</CODE>.  Caso o usuário que
reportou o bug tenha incluído uma linha <CODE>Package</CODE> listando
uma pacote com um mantenedor conhecido o mantenedor receberá também
uma cópia.</P>

<P>A linha <CODE>Subject</CODE> terá
<CODE>Bug#</CODE><VAR>nnn</VAR><CODE>:</CODE> adicionado, e o
<CODE>Reply-To</CODE> será definido para incluir ambos o usuário que
enviou o relatório e <VAR>nnn</VAR><CODE>@bugs.debian.org</CODE>.</P>

<hrline>

<ul>
  <li><a href="#closing">Fechando relatórios de bugs</a></li>
  <li><a href="#followup">Mensagens de Acompanhamento</a></li>
  <li><a href="#severities">Níveis de Severidade</a></li>
  <li><a href="#tags">Tags para relatórios de bugs</a></li>
  <li><a href="forward">Registrando que você passou adiante um relatório de bug</a></li>
  <li><a href="#maintincorrect">Mantenedores de pacotes incorretamente listados</a></li>
  <li><a href="#requestserv">Reabrindo, redesignando e manipulando bugs</a></li>
  <li><a href="#subjectscan">Recurso de procura-no-assunto mais-ou-menos obsoleto</a></li>
  <li><a href="#x-debian-pr">Recurso <code>X-Debian-PR: quiet</code> obsoleto</a></li>
</ul>

<hrline>


<h2><a name="closing">Fechando relatórios de bugs</a></h2>

<p>Relatórios de bugs Debian devem ser fechados quando um problema é
corrigido. Problemas em pacotes podem ser considerados corrigidos
quando um pacote que inclui a correção para o bug entra no repositório
Debian.</p>

<p>Normalmente, as únicas pessoas autorizadas a fechar um relatório
de bug são o usuário que relatou o bug e o(s) mantendor(es) do pacote
para o qual o bug foi enviado. Existem exceções para esta regra. Por
exemplo, os bugs relatados para pacotes desconhecidos ou para certos
pseudo-pacotes. Em caso de dúvidas, não feche o bug : peça primeiro
por ajuda na lista de discussão debian-devel.</p>

<p>Relatórios de bugs devem ser fechados através do envio de uma
mensagem para <var>nnn</var><code>-done@bugs.debian.org</code>.
O corpo da mensagem precisa conter uma explicação de como o bug
foi corrigido.</p>

<p>Com as mensagens recebidas do sistema de geranciamento de bugs, tudo
o que você precisa para fechar um bug é enviar uma resposta através de
seu programa de leitura de mensagens e editar o campo <code>To</code> para
que o mesmo contenha <VAR>nnn</VAR><CODE>-done@bugs.debian.org</CODE> ao
invés de <VAR>nnn</VAR><CODE>@bugs</CODE>
(<VAR>nnn</VAR><CODE>-close</CODE> é fornecido como uma apelido para
<VAR>nnn</VAR><CODE>-done</CODE>).</P>

<p>A pessoa fechando o bug, a pessoa que o relatou e a lista de discussão
<code>debian-bugs-closed</code> irão todos receber uma notificação sobre
o status do relatório. A pessoa que enviou o relatório e a lista de
discussão também receberão o conteúdo da mensagem enviada para
<var>nnn</var><code>-done</code>.</p>


<h2><a name="followup">Mensagens de Acompanhamento</a></h2>

<p>O sistema de gerenciamento de bugs incluirá o endereço da pessoa que
relatou o bug e o endereço do bug (<var>nnn</var><code>@bugs</code>) no
cabeçalho <code>Reply-To</code> depois de encaminhar o relatório do bug.
Por favor note que estes são dois endereços distintos.</p>

<p>Caso um desenvolvedor deseje responder a um relatório de bugs o mesmo
deve simplesmente responder a mensagem, respeitando o cabeçalho
<code>Reply-To</code>. Isto <strong>não</strong> fechará o bug.</p>

<p>O sistema de gerenciamento de bugs receberá a mensagem em
<VAR>nnn</VAR><CODE>@bugs</CODE>, irá passá-la para o mantenedor do
pacote, arquivar a resposta com o restante dos logs para este relatório
de bugs e encaminhá-lo para <CODE>debian-bugs-dist</CODE>.</P>

<p>Um desenvolvedor pode explicitamente enviar mensagens para a pessoa
que relatou o bug com mensagens para
<var>nnn</var><code>-submitter@bugs</code>.</p>

<P>Caso você deseje enviar um acompanhamento para a mensagem que não seja
apropriado para <CODE>debian-bugs-dist</CODE> você pode fazer isso
enviando o mesmo para <VAR>nnn</VAR><CODE>-quiet@bugs</CODE> ou para
<VAR>nnn</VAR><CODE>-maintonly@bugs</CODE>.
Mensagens para <VAR>nnn</VAR><CODE>-quiet@bugs</CODE> são arquivadas no
Sistema de Gerenciamento de Bugs mas não são entregues para quaisquer
indivíduos ou listas de discussão. Mensagens para
<VAR>nnn</VAR><CODE>-maintonly@bugs</CODE> são arquivadas no Sistema de
Gerenciamento de Bugs e são entregues somente para o mantenedor do
pacote em questão.</P>

<P><EM>Não</EM> use os recursos `Responder a todos os detinatários' ou
`Acompanhar' de seu cliente de e-mail a menos que você edite os
destinatários para retirá-los substancialmente. Em particular, perceba
que você não envia acompanhamentos para
<CODE>submit@bugs.debian.org</CODE>.</P>


<H2><A name="severities">Níveis de Severidade</A></H2>

<P>O sistema de gerenciamento de bugs grava um nível de severidade com
cada relatório de bug. Este é definido como <CODE>normal</CODE> por
padrão, mas pode ser sobreescrito incluindo uma linha
<CODE>Severity</CODE> no pseudo-cabeçalho quando o bug é enviado
(consulte as <A href="Reporting#pseudoheader">instruções para reportar
bugs</A>) ou usando o comando <CODE>severity</CODE> com o
<A href="#requestserv">servidor de requisição de controle</A>.</P>

<P>Os níveis de severidade são :

<DL>
<DT><CODE>critical</CODE>
<DD>faz com que softwares não-relacionados no sistema (ou o sistema
todo) parem ou causa séria perda de dados ou introduz uma falha de
segurança nos sistemas onde você instala o pacote.

<DT><CODE>grave</CODE>
<DD>torna o pacote em questão inutilizável ou quase inutilizável ou causa
perda de dados ou introduz uma falha de segurança permitindo acesso às
contas dos usuários que utilizam o pacote.

<DT><CODE>serious</CODE>
<DD>é uma severa violação da política Debian (isto é, viola uma diretiva
"deve" ou "requerida"), ou, na opinião do mantenedor do pacote, torna o
pacote impróprio para o release.

<DT><CODE>important</CODE>
<DD>um bug que tem um efeito maior na usabilidade de um pacote, sem
torná-lo completamente inutizável para todos.

<DT><CODE>normal</CODE>
<DD>o valor padrão, aplicável a maioria dos bugs.
 
<DT><CODE>minor</CODE>
<DD>um problema que não afeta a utilidade do pacote e de correção
presumivelmente trivial.

<DT><CODE>wishlist</CODE>
<DD>para quaisquer requisições de inclusão de novos recursos e também
para quaisquer bugs que sejam muito difíceis de corrigir devido a
considerações maiores de design.

<DT><CODE>fixed</CODE>
<DD>para bugs que são corrigidos mas não devem ainda ser fechados.
Esta é uma excessão para bugs de uploads de não-mantenedores. Nota:
a <strong>tag</strong> "fixed" deve ser usada nesse caso.
</DL>

<p>Certas severidades são consideradas
<em><a href="http://bugs.debian.org/release-critical/";>release-critical</a></em>,
significando que o bug terá um impacto caso o pacote que o contém seja
fornecido em uma versão estável do Debian. Atualmente, as severidades
nesta categoria são <strong>critical</strong>, <strong>grave</strong> e
<strong>serious</strong>.</p>

<H2><a name="tags">Tags para relatórios de bugs</a></H2>

<p>Cada bug pode ter zero ou mais de um conjunto de tags. Estas tags são
exibidas na lista de bugs quando você consulta a página do pacote e quando
você consulta o log completo do bug.

<p>Tags podem ser definidas incluíndo uma linha <code>Tags</code> no
pseudo-cabeçalho quando o bug é reportado (consulte as
<a href="Reporting#pseudoheader">instruções para reportar bugs</a>)
ou usando o comando <code>tags</code> com o
<a href="#requestserv">servidor de requisição de controle</a>.

<p>As tags de bugs atuais são :

<dl>

<dt><code>patch</code>
  <dd>Um patch ou outro procedimento fácil para corrigir o bug é incluído
	nos logs do bug. Caso exista um patch, mas o mesmo não corrija o bug
	adequadamente ou cause outros problemas, esta tag não deve ser usada.

<dt><code>wontfix</code>
  <dd>Este bug não será corrigido. Possivelmente porque esta é uma escolha
	entre duas maneiras arbitrárias de corrigir o problema e o mantenedor e a
	pessoa que relatou o bug preferem maneiras diferentes de corrigir o
	problema, possivelmente porque a mudança de comportamento causará
	outros problemas, piores, ou possivelmente por outras razões.

<dt><code>moreinfo</code>
  <dd>Este bug não pode ser corrigido até que mais informações sejam
	fornecidas pela pessoa que relatou o mesmo. O bug será fechado caso a
	pessoa que o relatou não forneça maiores informações em um período de
	tempo razoável (alguns meses). Esta é para bugs como "Isso não funciona".
	O que não funciona ?

<dt><code>unreproducible</code>
  <dd>Este bug não pode ser reproduzido no sistema do mantenedor.
	Assistência de terceiros é necessária para diagnosticar a causa do
	problema.

<dt><code>help</code>
  <dd>O mantenedor está requisitando ajuda para lidar com este bug.

<dt><code>pending</code>
  <dd>O problema descrito no bug está sendo trabalhado ativamente, ou
	seja, uma solução está pendente.

<dt><code>fixed</code>
  <dd>Este bug está corrigido (por um upload de não-mantenedor, por
	exemplo), mas ainda existe um problema que precisa ser resolvido. Esta
	tag substitui a antiga severidade "fixed".

<dt><code>security</code>
  <dd>Este bug descreve um problema de segurança em um pacote (por
	exemplo, permissões erradas permitindo o acesso a dados que não
	deveriam estar acessíveis; buffer overruns permitindo que pessoas
	controlem um sistema de uma maneira que não deveriam ser capazes
	de fazê-lo; ataques de negação de serviço que precisam ser
	corrigidos, etc). A maioria dos bugs de segurança devem também
	ser definidos para uma severidade crítica ou grave.

<dt><code>upstream</code>
  <dd>Este bug aplica-se a parte do pacote de responsabilidade do
	desenvolvedor original.

<dt><code>potato</code>
  <dd>Este bug particularmente aplica-se ao release potato do Debian.

<dt><code>woody</code>
  <dd>Este bug particularmente aplica-se a distribuição woody.

<dt><code>sarge</code>
  <dd>Este bug particularmente aplica-se a distibuição sarge (ainda não lançada).

<dt><code>sid</code>
  <dd>Este bug particularmente aplica-se a uma arquitetura que atualmente
	ainda não foi lançada (isto é, na distribuição sid).

<dt><code>experimental</code>
  <dd>Este bug particularmente aplica-se a distribuição experimental.

</dl>

<p>As últimas três tags foram criadas param ser usadas especialmente para
bugs críticos ao release, para os quais é importante conhecer qual
distribuição é afetada para certificar-se que as correções (ou remoções)
aconteçam no local correto.

<H2><A name="forward">Registrando que você passou adiante um relatório de bug</A></H2>

<P>Quando um desenvolvedor encaminha um relatório de bugs para o
desenvolvedor original do pacote fonte do qual o pacote Debian é
derivado, o mesmo deve anotar isso no sistema de gerenciamento de
bugs como abaixo :</P>

<P>Certifique-se de que o campo <CODE>To</CODE> de sua mensagem possua
apenas o(s) endereçõ(s) do(s) autor(es); coloque ambos a pessoa que
reportou o bug e <VAR>nnn</VAR><CODE>-forwarded@bugs.debian.org</CODE>
no campo <CODE>CC</CODE>.</P>

<P>Peça ao autor para preservar o <CODE>CC</CODE> para
<VAR>nnn</VAR><CODE>-forwarded@bugs</CODE> quando responder, assim
o sistema de gerenciamento de bugs irá arquivar a resposta com o
relatório original.</P>

<P>Quando o sistema de gerenciamento de bugs recebe uma mensagem em
<VAR>nnn</VAR><CODE>-forwarded</CODE> o mesmo marca o bug relevante
como tendo sido encaminhado para o(s) endereço(s) no campo
<CODE>To</CODE> da mensagem que ele recebe.</P>

<P>Você pode também manipular a informação `encaminhado para' enviando
mensagens para
<A href="server-control"><CODE>control@bugs.debian.org</CODE></A>.</P>


<H2><a name="maintincorrect">Mantenedores de pacotes incorretamente listados</a></H2>

<p>Caso o mantenedor de um pacote esteja listado incorretamente,
isto é normalmente devido ao mantenedor ter mudado recentemente e
o novo mantenedor não ter ainda feito upload de uma nova versão do
pacote com um campo <CODE>Maintainer</CODE> do arquivo de controle
modificado.  Isto será corrigido quando o upload do pacote for feito;
alternativamente, os mantenedores do repositório podem sobreescrever
o registro do mantenedor de um pacote manualmente, por exemplo se uma
recompilação e re-upload do pacote não é esperada como necessária tão cedo.
Contacte <CODE>override-change@debian.org</CODE> para mudanças no arquivo
de sobreescrita (override file).</P>


<H2><A name="requestserv">Reabrindo, redesignando e manipulando bugs</A></H2>

<P>É possível redesignar relatórios de bugs para outros pacotes para
reabrir bugs fechados erroneamente, para modificar a informação dizendo
para onde, caso exista, um relatório de bug foi encaminhado, para mudar
as severidades e títulos de relatórios e para juntar e separar relatórios
de bugs. Isto é feito enviando mensagens para
<CODE>control@bugs.debian.org</CODE>.</P>

<P>O <A href="server-control">formato destas mensagens</A> é descrito em
outro documento disponível na World Wide Web ou no arquivo
<CODE>bug-maint-mailcontrol.txt</CODE>.  Uma versão em texto puro
pode também ser obtida enviando uma mensagem com a palavra
<CODE>help</CODE> para o servidor no endereço acima.</P>

<h2><a name="subjectscan">Recurso de procura-no-assunto mais-ou-menos obsoleto</a></h2>

<P>Mensagens que chegam em <CODE>submit</CODE> ou <CODE>bugs</CODE> as
quais o Assunto inicie com <CODE>Bug#</CODE><VAR>nnn</VAR> serão tratadas
como tendo sido enviadas para <VAR>nnn</VAR><CODE>@bugs</CODE>. Isto é para
compatibilidade anterior com mensagens encaminhadas a partir do endereço
antigo e para pegar mensagens enviadas para <CODE>submit</CODE> por
engano (por exemplo, usando responder para todos os destinatários).</P>

<P>Um esquema similar opera para <CODE>maintonly</CODE>,
<CODE>done</CODE>, <CODE>quiet</CODE> e <CODE>forwarded</CODE>,
os quais tratam mensagens que chegam com uma tag Assunto como tendo
sido enviadas para o endereço
<VAR>nnn-whatever</VAR><CODE>@bugs</CODE> correspondente.</P>

<P>Mensagens que chegam com <CODE>forwarded</CODE> puro e
<CODE>done</CODE> - por exemplo, sem número do relatório de bugs no
endereço - e sem um número de bug no Assunto serão arquivadas sob
`junk' e mantidas por algumas poucas semanas, mas de outra forma
ignoradas.</P>


<h2><a name="x-debian-pr">Recurso <code>X-Debian-PR: quiet</code> obsoleto</a></h2>

<P>É usado para ser possível prevenir que o sistema de gerenciamento
de bugs encaminhe a qualquer lugar mensagens que o mesmo recebeu em
<CODE>debian-bugs</CODE>, colocando uma linha
<CODE>X-Debian-PR: quiet</CODE> no cabeçaho da mensagem atual.</P>

<P>Esta linha de cabeçalho é agora ignorada. Ao invés disso, envie
sua mensagem para <CODE>quiet</CODE> ou
<VAR>nnn</VAR><CODE>-quiet</CODE> (ou <CODE>maintonly</CODE> ou
<VAR>nnn</VAR><CODE>-maintonly</CODE>).</P>

<HR>

#use "otherpages.inc"

#use "$(ENGLISHDIR)/Bugs/footer.inc"

--=-2beK+dZH1TdCId/WbJ5U--


-- 
To UNSUBSCRIBE, email to debian-l10n-portuguese-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

#use wml::debian::template title="Debian BTS - servidor de controle" NOHEADER=yes NOCOPYRIGHT=true
#use wml::debian::translation-check translation="1.27" translation_maintainer="André Luís Lopes"

<h1>Introdução ao servidor de e-mail para controle e manipulação de bugs</h1>

<P>Em adição ao servidor de e-mail em <code>request@bugs.debian.org</code>,
o qual permite a recuperação de dados e documentação de bugs por e-mail,
existe um outro servidor em <code>control@bugs.debian.org</code>, o qual
também permite que relatórios de bugs sejam manipulados de várias maneiras.</P>

<P>O servidor de controle funciona da mesma maneira que o servidor de requisição,
exceto que ele possui comandos adicionais; de fato, é o mesmo programa. Os dois
endereços são separados somente para evitar que usuários cometam erros e causem
problemas quando tentam meramente requisitar informação.</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 o servidor de e-mail para detalhes básicos de operações do
servidor de e-mail e os comandos básicos disponíveis ao enviar mensagens para
ambos os endereços.</P>

<P>O <A href="server-refcard">cartão de referência</A> para o servidor 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 somente no servidor de e-mail de controle</H1>

<dl>

<dt><code>reassign</code> <var>número do bug</var> <var>pacote</var>
<dd>

Registra que o bug #<var>número do bug</var> é um bug em <var>pacote</var>.
Pode ser usado para definir o pacote caso o usuário esqueça o pseudo-cabeçalho
ou para mudar a atribuição anterior. Nenhuma notificação é enviada para ninguém
(a não ser a informação normal no processamento da transcrição).

<dt><code>reopen</code> <var>número do bug</var>
 [ <var>endereço-de-origem</var> | <code>=</code> | <code>!</code> ]
<dd>

Reabre #<var>número do bug</var> caso o mesmo esteja fechado.

<p>Por padrão, ou se você especificar <code>=</code>, a pessoa que enviou
originalmente o relatório de bug continua como a origem 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-de-origem</var> a origem será definida
para o endereço que você fornecer. Caso você deseje se tornar a nova origem
do relatório reaberto você pode usar o atalho <code>!</code> ou especificar
seu próprio endereço de e-mail.</p>

<p>Normalmente é uma boa idéia dizer para a pessoa que está prestes a ser
registrada como a origem que você está reabrindo o relatório, assim ela saberá
que poderá esperar a notificação que ela 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 a origem. Para alterar a origem de um relatório de bug aberto, use o 
comando <code>submitter</code>; note que isto informará o endereço da pessoa que fez a mudança.
<dt><code>submitter</code> <var>bugnumber</var>
<var>originator-address</var> | <code>!</code>
<dd>

Altere a origem do #<var>bugnumber</var> para
<var>originator-address</var>.

<p>Se você deseja ser a nova origem do relatório voce pode usar o 
<code>!</code> ou especificar seu próprio endereço de email.</p>

<p>Enquanto o comando <code>reopen</code> altera a origem dos outros bugs mesclados com um que está sendo aberto novamente, <code>submiiter</code> não afeta bugs mesclados.</p>

<dt><code>forwarded</code> <var>número do bug</var> <var>endereço</var>
<dd>

Note que <var>número do bug</var> foi encaminhado para o mantenedor original
em <var>endereço</var>.  Atualmente isso 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 tenha sido marcado como
tendo sido encaminhado.

<dt><code>notforwarded</code> <var>número do bug</var>
<dd>

Esquece qualquer vestígio que <var>número do bug</var> foi encaminhado para
qualquer mantenedor original. Caso o bug não tenha sido registrado como tendo
sido encaminhado então isso não causará nada.

<dt><code>retitle</code> <var>número do bug</var> <var>novo-título</var>
<dd>

Muda o título de um relatório de bug para o especificado (o padrão é
o cabeçalho <code>Assunto</code> da mensagem do relatório original.).

<p>Diferente da maioria dos outros comandos de manipulação de bugs, quando
usado em um ou em um conjunto de relatórios unidos, modificará somente o
título do bug individual requisitado e não todos aqueles com os quais o mesmo
está unido.

<dt><code>severity</code> <var>número do bug</var> <var>severidade</var>
<dd>

<p>Define o nível de severidade para o relatório de bug #<var>número do bug</var>
para <var>severidade</var>.  Menhuma notificação é enviada para o usuário que
reportou o bug.</p>

<p>As severidades são <code>critical</code>, <code>grave</code>,
<code>serious</code>, <code>important</code>, <code>normal</code>,
<code>minor</code>, e <code>wishlist</code>.

<p>Para <A href="Developer#severities">os significados das severidades</A> por
favor consulte o documentação geral para desenvolvedores do sistema de bugs.

<dt><code>clone</code> <var>número do bug</var> [ <var>novos IDs</var> ]

  <dd>O controle de comando clone permite duplicar um relatório de bug. Ele é
	útil quando um único relatório indica que múltiplos bugs distintos ocorreram.
  "<var>Novos IDs</var>" são números negativos, separados por espaços, que podem
	ser usados em subsequentes comandos control para se referir aos novos bugs
	duplicados. Um novo relatório é gerado para cada novo ID.

  <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 -2
        reassign -2 foo
        retitle -2 foo: foo fede
        merge -1 -2
  </pre>

<dt><code>merge</code> <var>número do bug</var> <var>número do bug</var> ...
<dd>

Junta 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>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 autor original ou todos marcados
como encaminhados, todos atribuídos para o mesmo pacote(s) (uma comparação
exata de strings é feita no pacote para o qual o bug está sendo 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 que os mesmos estejam no mesmo estado antes, usando
<code>merge</code>.</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 juntamente. Unir é como equalizar: é reflexivo,
transitivo e simétrico.</p>

<P>Unir relatórios faz com que uma nota apareça no relatório de log de cada
relatório de bug; nas páginas WWW isto se reflete em ligações de inclusões para
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.

<dt><code>unmerge</code> <var>número do bug</var>
<dd>

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>Caso muitos relatórios de bugs sejam unidos e você deseje separá-los em dois
grupos separados de relatórios unidos você deve desconectar cada relatório em
um dos novos grupos separadamente e então uní-los na forma do novo grupo
requerido.</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.

<dt><code>tags</code> <var>número do bug</var> [ <code>+</code> | <code>-</code> | <code>=</code> ] <var>tag</var>

  <dd>Define uma tag particular para o relatório de bug #<var>número do bug</var>
	para <var>tag</var>. Nenhuma notificação é enviada para o usuário que reportou
	o bug. <code>+</code> significa adicionar, <code>-</code> significa subtrair e
  <code>=</code> significa ignorar as tags atuais e definí-las novamente. A ação
	padrão é adicionar. 

  <p>As tags disponíveis atualmente incluem <code>patch</code>, <code>wontfix</code>,
  <code>moreinfo</code>, <code>unreproducible</code>, <code>help</code>,
  <code>pending</code>, <code>fixed</code>, <code>security</code>,
  <code>upstream</code>, <code>potato</code>, <code>woody</code>,
  <code>sarge</code>,
  <code>sid</code> e <code>experimental</code>.

  <p>Para <a href="Developer#tags">os siginficados das tags</a> por favor consulte
	a documentação geral para desenvolvedores do sistema de bugs.

<dt><code>close</code> <var>número do bug</var>
<dd>

Fecha o relatório de bug #<var>número do bug</var>.

<p>Uma notificação é enviada para o usuário que reportou o bug, mas (em contraste
de enviar uma mensagem para <var>número do bug</var><code>-done@bugs</code>) o texto
da mensagem é incluído na notificação. O mantenedor que fecha o relatório precisa
certificar-se, provavelmente enviando uma mensagem separada, que o usuário que
reportou o bug fique sabendo a razão pela qual o bug está sendo fechado. O uso deste
comando é então não encorajado.

<dt><code>quit</code>
<dt><code>stop</code>
<dt><code>thank</code>...
<dt><code>--</code>...

  <dd>Informa ao servidor de controle para parar de processar a mensagem; é possível incluir explicações, assinaturas 
  ou qualquer outra coisa no resto da mensagem, nada disso será detectado pelo servidor de controle.

<dt><code>#</code>...

  <dd>Comentário por linha. O caractere <code>#</code> deve estar presente no começo da linha.

</dl>

<hr>

#use "otherpages.inc"

#use "$(ENGLISHDIR)/Bugs/footer.inc"
#use wml::debian::template title="Debian BTS - reportando bugs" NOHEADER=yes NOCOPYRIGHT=true
#use wml::debian::translation-check translation="1.32"

<h1>Como reportar um bug no Debian</h1>

<h2>Pontos importantes a serem considerados <strong>antes</strong> de reportar</h2>

<p>Por favor, não reporte diversos bugs não relacionados - especialmente
em pacotes diferentes - em um único relatório de bug.

<p>Você deve checar se seu relatório de bug já não foi reportado por
outra pessoa antes de enviá-lo. Listas de bugs atuais estão disponíveis
<a href="./">na World Wide Web</a> e <a href="Access">em outros locais</a>
- consulte outros documentos para detalhes. Você pode enviar seus comentários
para um relatório de bugs existente #<var>&lt;número&gt;</var> enviando
uma mensagem para <var>&lt;número&gt;</var>@bugs.debian.org</p>

<p>Caso você não consiga determinar qual pacote contém o problema, por
favor envie uma mensagem para a <a href="mailto:debian-user@lists.debian.org";>
lista de discussão dos usuários Debian</a> pedindo por ajuda. Caso seu
problema não esteja relacionado somente a um pacote mas a algum serviço
Debian geral, existem diversos <a href="pseudo-packages">pseudo-pacotess</a>
ou mesmo <a href="../MailingLists/">listas de discussão</a> que
você pode usar para transmitir sua mensagem para nós.

<p>Caso você prefira enviar uma cópia de seu relatório de bug para
destinatários adicionais (como listas de discussões), você não deverá
usar os cabeçalhos de mensagens normais, mas sim
<a href="#xcc">um método diferente, descrito abaixo</a>.</p>


<h2>Enviando relatórios de bugs usando uma ferramenta automática para relatar bugs</h2>


<p>Existe um programa que nós desenvolvemos no Debian para ajudar no envio de relatórios
de bugs, chamado de <code><a href="http://packages.debian.org/stable/utils/bug.html";>reportbug</a></code>
e <code><a href="http://packages.debian.org/stable/utils/reportbug.html";>reportbug</a></code>.

It will guide you through the bug reporting process step by step,
 and probably ease filing bugs that way.

<h2>Enviando o relatório de bugs via e-mail</h2>

<P>Envie mensagens para
<A href="mailto:submit@bugs.debian.org";><code>submit@bugs.debian.org</code></A>,
como descrito abaixo.</P>

<P>É claro, como em qualquer mensagem, você deve incluir uma linha de
<code>Assunto</code> clara e descritiva no cabeçalho principal.
O assunto que você usar será usado como o título inicial
do bug no sistema de gerenciamento, portanto tente utilizar algo
informativo !</P>

<P>Você precisa colocar um pseudo-cabeçalho no início do corpo da mensagem.
Isto significa que a primeira linha do corpo da mensagem deve conter:

<pre>
Package: &lt;nome do pacote&gt;
</pre>

<p>Subtitua <code>&lt;nome do pacote&gt;</code> pelo nome do pacote que
possui o bug.

<p>A segunda linha da mensagem deve conter :

<pre>
Version: &lt;versão do pacote&gt;
</pre>

<p>Substitua <code>&lt;versão do pacote&gt;</code> pela versão do pacote.

<p>Você precisa informar uma linha <code>Package</code> correta no
pseudo-cabeçalho para que o sistema de gerenciamento de bugs entregue
a mensagem para o mantenedor do pacote. Consulte
<a href="#findpkgver">este exemplo</a> para informações sobre como
encontrar essa informação.

<p>Os campos de pseudo-cabeçalhos devem iniciar bem no início de suas
linhas.</p>

<p>Por favor inclua em seu relatório :

<ul>
<li>O texto <em>exato</em> e <em>completo</em> de quaisquer mensagens
impressas ou logadas. Isto é muito importante !
<li>Exatamente o que você digitou ou fez para demonstrar o problema.
<li>Uma descrição do comportamento incorreto : exatamente qual
comportamento você estava esperando e o que você observou. Uma transcrição
de uma sessão de exemplo é uma boa maneira de mostrar isso.
<li>Uma correção sugerida, ou até mesmo um patch, caso você tenha preparado
um.
<li>Detalhes da configuração do programa com o problema. Inclua o texto
completo dos arquivos de configuração do programa em questão.
<li>As versões de quaisquer pacotes dos quais o pacote com problemas dependa.
<li>Qual versão de kernel você está usando (digite <code>uname -a</code>),
sua biblioteca C compartilhada (digite <code>ls -l /lib/libc.so.6</code> ou
<code>dpkg -s libc6 | grep ^Version</code>) e quaisquer outros detalhes sobre seu
sistema Debian, caso pareçam aproriados. Por exemplo, caso você tenha um
problema com um script Perl você pode informar a versão do binário `perl'
(digite <code>perl -v</code> ou
<code>dpkg -s perl | grep ^Version:</code>).
<li>Detalhes apropriados do hardware em seu sistema. Caso você esteja
reportando um problema com um controlador de dispositivo por favor
liste <em>todo</em> hardware em seu sistema, uma vez que problemas são
normalmente causados por conflitos de endereços de I/O e IRQ.
</ul>

<P>Inclua quaisquer detalhes que pareça relevante - não existem muitos
problemas em fazer seu relatório muito longo incluindo muita informação.
Caso eles sejam pequenos, por favor inclua em seu relatório quaisquer
arquivos que você estava usando para reproduzir o problema (use o programa
uuencode nos mesmos caso eles contenham caracteres estranhos, etc.).</P>


<h2><A name="example">Exemplo</A></h2>

<P>Um relatório de bug, com o cabeçalho da mensagem, se parece como esse :
<PRE>
  To: submit@bugs.debian.org
  From: diligent@testing.linux.org
  Subject: Hello diz `goodbye'

  <A name="pseudoheader">Package: hello</A>
  Version: 1.3-16

  Quando eu invoco `hello' sem argumentos a partir de um shell comum
	o mesmo imprime `goodbye' ao invés do esperado `hello, world'.
	Aqui está uma transcrição :

  $ hello
  goodbye
  $ /usr/bin/hello
  goodbye
  $

  Sugiro que a string de saída, em hello.c, seja corrigida.

  Estou usando GNU/Linux 2.2, kernel 2.2.17-pre-patch-13
  e libc6 2.1.3-10.
</PRE>


<h2><A name="xcc">Enviando cópias de relatórios de bugs para outros endereços</A></h2>

<P>Algumas vezes é necessário enviar uma cópia do relatório de bug para
algum outro endereço adicional além de <code>debian-bugs-dist</code> e
para o mantenedor do pacote, que são os endereços para os quais o mesmo
é normalmente enviado.</P>

<P>Você pode fazer isso enviando uma cópia de seu relatório de bug (usando
o campo CC) para o(s) outro(s) endereço(s), mas assim as outras cópias
não teriam o número do relatório de bug no campo <code>Reply-To</code> e
na linha <code>Assunto</code>.
Quando os destinatários responderem eles provavelmente preservarão a
entrada <code>submit@bugs.debian.org</code> no cabeçalho e terão suas
mensagens enviadas como um novo relatório de bug. Isto leva à muitos
relatórios duplicados.</P>

<P>A maneira <em>correta</em> de fazer isso é usar o cabeçalho
<code>X-Debbugs-CC</code>. Adicione uma linha como essa ao cabeçalho
de sua mensagem (e não ao pseudo cabeçalho com o campo
<code>Package</code>) :</P>
<pre>
 X-Debbugs-CC: outra-lista@cosmic.edu
</pre>
<P>Isto fará com que o sistema de gerenciamento de bugs envie uma cópia
de seu relatório para o(s) endereço(s) na linha <code>X-Debbugs-CC</code>
e também para <code>debian-bugs-dist</code>.</P>

<P>Este recurso pode geralmente ser combinado de maneria útil com
<code>quiet</code> - veja abaixo.</P>


<h2><A name="severities">Níveis de Severidade</A></h2>

<P>Caso um relatório seja de um bug particularmente sério ou seja meramente
uma requisição de um novo recurso você pode definir o nível de severidade
do bug no momento em que o reporta. Porém, isto não é requerido e os
desenvolvedores atribuirão um nível de severidade apropriado para seu
relatório caso você não o faça.</P>

<p>Para atribuir um nível de severidade, coloque uma linha como essa no
pseudo-cabeçalho :

<pre>
Severity: &lt;<var>severidade</var>&gt;
</pre>

<p>Subtitua &lt;<var>severidade</var>&gt; por um dos níveis de severidade
disponíveis, como descrito na
<A href="Developer#severities">documentação para desenvolvedores</A>.</P>


<h2>Endereços de envio diferentes (relatórios de bugs menores ou em massa)</h2>

<p>Caso um relatório de bug seja menor, por exemplo, um erro ortográfico na
documentação ou um problema de compilação trivial, por favor ajuste a
severidade aproriadamente e envie o mesmo para <code>maintonly@bugs</code>
ao invés de <code>submit@bugs</code>.
<code>maintonly</code> irá encaminhar o relatório somente para o mantenedor
do pacote e não irá encaminhá-lo para as lista de discussão do BTS.

<p>Caso você esteja enviando muitos relatórios de uma vez, você deverá
definitivamente usar <code>maintonly@bugs</code> para que você não cause
muito tráfego redundante nas listas de discussão do BTS. Antes de enviar
muitos bugs similares você pode também querer postar um sumário em
<code>debian-bugs-dist</code>.

<p>Caso deseje reportar um bug para o sistema de gerenciamento de bugs que
já tenha sido enviado para o mantenedor você pode usar
<code>quiet@bugs</code>. Bugs enviados para <code>quiet@bugs</code> não
serão encaminhados para lugar algum, somente reportados.

<p>Quando você utiliza endereços de envio diferentes, o sistema de
gerenciamento de bugs irá definir o <code>Reply-To</code> para quaisquer
mensagens encaminhadas para que as respostas sejam por padrão processadas
da mesma maneira que o relatório original. Isto significa que, por exemplo,
repostas para <code>maintonly</code> irão para
<var>nnn</var><code>-maintonly@bugs</code> ao invés de
<var>nnn</var><code>@bugs</code>, a menos é claro que alguém sobreescreva
isso manualmente.


<h2>Relatórios de bugs para pacotes desconhecidos</h2>

<P>Caso o sistema de gerenciamento de bugs não saiba quem é o mantenedor
do pacote relevante o mesmo encaminhará o relatório para
<code>debian-bugs-dist</code> mesmo caso <code>maintonly</code> seja usado.</P>

<p>Ao enviar para <code>maintonly@bugs</code> ou
<var>nnn</var><code>-maintonly@bugs</code> você deve certicar-se de atribuir
o relatório de bug ao pacote correto, colocando um <code>Package</code>
correto no topo de um envio original de um relatório ou usando
<A href="server-control">o serviço <code>control@bugs</code></A> para
(re)atribuir o relatório apropriadamente primeiro caso o mesmo já não
esteja correto.</P>


<h2><a name="findpkgver">Usando o <code>dpkg</code> para encontrar o pacote e
versão para o relatório</a></h2>

<P>Caso você esteja reportando um bug em um comando você pode encontrar
qual pacote instalou esse comando usando <code>dpkg --search</code>. Você
pode encontrar qual versão de um pacote você possui instalada usando
<code>dpkg --list</code> ou <code>dpkg --status</code>.
</P>

<P>Por exemplo :
<pre>
$ which apt-get
/usr/bin/apt-get
$ type apt-get
apt-get is /usr/bin/apt-get
$ dpkg --search /usr/bin/apt-get
apt: /usr/bin/apt-get
$ dpkg --list apt
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  apt            0.3.19         Advanced front-end for dpkg
$ dpkg --status apt
Package: apt
Status: install ok installed
Priority: standard
Section: base
Installed-Size: 1391
Maintainer: APT Development Team &lt;deity@lists.debian.org&gt;
Version: 0.3.19
Replaces: deity, libapt-pkg-doc (&lt;&lt; 0.3.7), libapt-pkg-dev (&lt;&lt; 0.3.7)
Provides: libapt-pkg2.7
Depends: libapt-pkg2.7, libc6 (&gt;= 2.1.2), libstdc++2.10
Suggests: dpkg-dev
Conflicts: deity
Description: Advanced front-end for dpkg
 This is Debian's next generation front-end for the dpkg package manager.
 It provides the apt-get utility and APT dselect method that provides a
 simpler, safer way to install and upgrade packages.
 .
 APT features complete installation ordering, multiple source capability
 and several other unique features, see the Users Guide in
 /usr/doc/apt/guide.text.gz

</pre>

<hr>

#use "otherpages.inc"

#use "$(ENGLISHDIR)/Bugs/footer.inc"

Reply to: