Olá, Faw, eu tinha feito suas modificações na mão ao invés de aplicar o patch, e acabei deixando passar algumas besteirinhas :( Por favor, desconsidere o arquivo que mandei mais cedo. Em anexo está o wml corrigido e o patch de algumas modificações que fiz em cima de sua correção. Espero que desta vez eu tenha feito certo :) Abraços,
On Sun, Jun 25, 2006 at 10:53:12PM -0300, Felipe Augusto van de Wiel (faw) wrote: > > Tassia, aproveitei pra revisar outros itens e sugerir mudanças. > O diff está em anexo. Note que eu converti o formato de quebra de linha > do dos para o unix. O patch atual não tem os ^M no final, portanto antes > de aplicar o patch, se você usa vi, faça um :set ff=unix no ser arquivo > .wml. > > > Eu também reverti poucas mudanças que você fez e fiz ajustes de > comprimento de linha, se aprovar as alterações envio ao repositório, se > tiver dúvidas ou questionamentos vamos discutí-las para que o WML possa > ser publicado o quanto antes. > > > Abraço, > > - -- > Felipe Augusto van de Wiel (faw) > "Debian. Freedom to code. Code to freedom!" -- Tássia Camões - http://tassia.org 0x1D1D1702 - http://pgp.mit.edu
#use wml::debian::template title="Debian BTS — servidor de controle" NOHEADER=yes NOCOPYRIGHT=true #use wml::debian::translation-check translation="1.53" <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>[EMAIL PROTECTED]</code>, o qual permite a recuperação de dados e documentação de bugs por e-mail, existe um outro servidor em <code>[EMAIL PROTECTED]</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 por possuir 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>Como os comandos específicos para o servidor de controle alteram o estado de um bug, uma notificação sobre o processamento dos comandos é enviado para o mantenedor do pacote para os quais os bugs alterados estão designados. Adicionalmente, a mensagem para o servidor e as alterações resultantes são registradas no relatório e portanto disponiblizadas 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 um dos servidores para detalhes básicos de operações dos servidores de e-mail e 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> <dl> <dt><code>reassign</code> <var>número-do-bug</var> <var>pacote</var> [ <var>versão</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 tenha esquecido o pseudo-cabeç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>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. <dt><code>reopen</code> <var>número-do-bug</var> [ <var>endereço-do-relator</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 o 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-relator</var> o remetente será definido como o endereço que você fornecer. Caso você deseje se tornar o novo remetente 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 avisar à pessoa que está prestes a ser registrada como o relator 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 relator. Para alterar o remetente de um relatório de bug aberto, use o comando <code>submitter</code>; note que isto notificará o relator original sobre esta mudança. <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>. <dt><code>found</code> <var>número-do-bug</var> [ <var>versão</var> ] <dd>Registra que #<var>número-do-bug</var> foi encontrado em determinada <var>versão</var> do pacote ao qual ele está atribuído. <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 é encontrado ("found") novamente após ter sido corrigido. <p>Caso nenhuma <var>versão</var> seja fornecida, a lista de versões corrigidas para o bug é esvaziada. Isto é idêntico ao comportamento do <code>reopen</code>. <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 ambigüidade. <dt><code>notfound</code> <var>número-do-bug</var> <var>versão</var> <dd>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. <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. <dt><code>submitter</code> <var>numéro-do-bug</var> <var>endereço-do-relator</var> | <code>!</code> <dd> Altera o relator do #<var>numéro-do-bug</var> para <var>endereço-do-relator</var>. <p>Se você deseja ser o novo relator do relatório você pode usar o <code>!</code> ou especificar seu próprio endereço de email.</p> <p>Enquanto o comando <code>reopen</code> altera o relator dos outros bugs unidos com o que está sendo aberto novamente, <code>submitter</code> não afeta bugs unidos.</p> <dt><code>forwarded</code> <var>número-do-bug</var> <var>endereço</var> <dd> Marca que <var>número-do-bug</var> foi encaminhado para o mantenedor 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 tenha sido marcado como tendo sido encaminhado. <dt><code>notforwarded</code> <var>número-do-bug</var> <dd> Esquece qualquer vestígio de que <var>número-do-bug</var> foi encaminhado para qualquer mantenedor original. Caso o bug não tenha sido marcado 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>Subject</code> — Assunto — da mensagem do relatório original). <p>Diferente da maioria dos outros comandos de manipulação de bugs, quando usado em um relatório de 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>. Nenhuma 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 a documentação geral dos desenvolvedores sobre o sistema de bugs. <dt><code>clone</code> <var>número-do-bug</var> <var>Novo ID</var> [ <var>Novos IDs</var> ... ] <dd>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. "<var>Novos IDs</var>" são números negativos, separados por espaços, que podem ser usados em comandos de controle subseqüentes 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 -3 reassign -3 foo retitle -3 foo: foo fede merge -1 -3 </pre> <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> <dt><code>merge</code> <var>número-do-bug</var> <var>número-do-bug</var> ... <dd> 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>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 não marcados como encaminhados, todos atribuídos para o(s) mesmo(s) pacote(s) (uma comparação exata de strings é 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 pelo merge. 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 log 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. <dt><code>forcemerge</code> <var>número-do-bug</var> <var>número-do-bug</var> ...</dt> <dd>Une forçadamente dois ou mais relatórios de bug. O primeiro bug listado é o bug principal, e suas configurações (as configurações que devem ser iguais numa união normal) são atribuídas aos bugs listados em seguida. Para evitar que erros de digitação unam bugs erroneamente, os bugs precisam estar no mesmo pacote. Veja o texto acima para uma descrição do que união ("merge") significa. <p>Note que isto torna possível o fechamento de bugs na união; você é responsável por notificar os relatores dos bugs com uma mensagem de fechamento apropriada se você fizer isto.</p> </dd> <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> [ <var>tag</var> ... ] <dd>Define tags para o relatório de bug #<var>número-do-bug</var>. Nenhuma notificação é enviada para o usuário que relatou o bug. Definir a ação como <code>+</code> significa que cada <var>tag</var> dada deve ser adicionada, <code>-</code> significa que cada <var>tag</var> deve ser removida, e <code>=</code> significa que o conjunto atual de tags deve ser ignorado e definido a partir da lista fornecida. A ação padrão é adicionar. <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 </pre> <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>fixed-in-experimental</code>, <code>fixed-upstream</code>, <code>security</code>, <code>upstream</code>, <code>confirmed</code>, <code>d-i</code>, <code>ipv6</code>, <code>lfs</code>, <code>l10n</code> <code>potato</code>, <code>woody</code>, <code>sarge</code>, <code>sarge-ignore</code>, <code>etch</code>, <code>etch-ignore</code>, <code>sid</code> e <code>experimental</code>. <p>Para <a href="Developer#tags">os significados das tags</a> por favor consulte a documentação geral dos desenvolvedores sobre o sistema de bugs. <dt><code>close</code> <var>número-do-bug</var> [ <var>versão-corrigida</var> ] (ultrapassado) <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 (ao contrário do envio de uma mensagem para <var>número-do-bug</var><code>[EMAIL PROTECTED]</code>) o texto da mensagem que fechou o bug <strong>não</strong> é 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 é portanto desencorajado. Veja as informações para desenvolvedores sobre <a href="Developer#closing">como fechar um relatório de bug</a>. <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. <dt><code>package</code> [ <var>nome-de-pacote</var> ... ] <dd>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 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>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> <dt><code>owner</code> <var>número-do-bug</var> <var>endereço</var> | <code>!</code> <dd>Define <var>endereço</var> como "dono" do #<var>número-do-bug</var>. O dono de um bug clama a responsabilidade de corrigí-lo e irá receber todos os e-mails a seu respeito. Isto é útil para dividir o trabalho em pacotes que possuem equipes de mantenedores. <p>Se você quer se tornar o dono de um bug, você pode usar a abreviação <code>!</code> ou especificar seu endereço de e-mail.</p> <dt><code>noowner</code> <var>número-do-bug</var> <dd>Esquece qualquer dono que o bug tenha além do mantenedor usual. Se o bug não tiver algum dono registrado, esta opção não fará nada. <dt><code>#</code>... <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 enviada pelo remetente e para os mantenedores afetados, portanto você pode utilizar isto para documentar as razões de seus comandos. <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. </dl> <hr> #use "otherpages.inc" #use "$(ENGLISHDIR)/Bugs/footer.inc"
--- server-control.wml.faw.2006062500 2006-06-27 01:59:21.000000000 -0400 +++ server-control.wml.tassia.2006062600 2006-06-27 02:10:46.000000000 -0400 @@ -37,7 +37,7 @@ <dl> -<dt><code>reassign</code> <var>número do bug</var> <var>pacote</var> +<dt><code>reassign</code> <var>número-do-bug</var> <var>pacote</var> [ <var>versão</var> ] <dd> @@ -66,8 +66,8 @@ especificar seu próprio endereço de e-mail.</p> <p>Normalmente é uma boa idéia avisar à pessoa que está prestes a ser -registrada como o relator que você está reabrindo o relatório, assim ela -estará avisada para esperar a notificação que receberá quando o bug for +registrada como o relator 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 @@ -76,7 +76,7 @@ relator original sobre esta mudança. <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 +mas reapareceu em uma versão posterior, é melhor utilizar o comando <code>found</code>. <dt><code>found</code> <var>número-do-bug</var> [ <var>versão</var> ] @@ -88,7 +88,7 @@ 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 é encontrado (found) mais recentemente do que havia sido corrigido. +bug é encontrado ("found") novamente após ter sido corrigido. <p>Caso nenhuma <var>versão</var> seja fornecida, a lista de versões corrigidas para o bug é esvaziada. Isto é idêntico ao comportamento do <code>reopen</code>. @@ -107,14 +107,14 @@ sobre aquela versão será conhecida. O objetivo é corrigir erros no registro de quando um bug foi encontrado. -<dt><code>submitter</code> <var>número-do-bug</var> +<dt><code>submitter</code> <var>numéro-do-bug</var> <var>endereço-do-relator</var> | <code>!</code> <dd> -Altera o relador do #<var>número-do-bug</var> para +Altera o relator do #<var>numéro-do-bug</var> para <var>endereço-do-relator</var>. -<p>Se você deseja ser o novo remetente do relatório você pode usar o +<p>Se você deseja ser o novo relator do relatório você pode usar o <code>!</code> ou especificar seu próprio endereço de email.</p> <p>Enquanto o comando <code>reopen</code> altera o relator dos outros bugs @@ -133,7 +133,7 @@ <dt><code>notforwarded</code> <var>número-do-bug</var> <dd> -Esquece qualquer vestígio de que <var>número do bug</var> foi encaminhado +Esquece qualquer vestígio de que <var>número-do-bug</var> foi encaminhado para qualquer mantenedor original. Caso o bug não tenha sido marcado como tendo sido encaminhado então isso não causará nada. @@ -164,13 +164,13 @@ favor consulte a documentação geral dos desenvolvedores sobre o sistema de bugs. -<dt><code>clone</code> <var>número-do-bug</var> <var>NovoID</var> [ <var>Novos IDs</var> ... ] +<dt><code>clone</code> <var>número-do-bug</var> <var>Novo ID</var> [ <var>Novos IDs</var> ... ] <dd>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. "<var>Novos IDs</var>" são números negativos, - separados por espaços, que podem ser usados em comandos de controle - subseqüentes para se referir aos novos bugs duplicados. Um novo relatório + distintos ocorreram. "<var>Novos IDs</var>" são números negativos, + separados por espaços, que podem ser usados em comandos de controle + subseqüentes para se referir aos novos bugs duplicados. Um novo relatório é gerado para cada novo ID. <p>Exemplo de uso:</p> @@ -188,11 +188,11 @@ merge -1 -3 </pre> - <p>Lembre-se de escrever o seu relatório de bug em inglês, se precisar de + <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> - + <dt><code>merge</code> <var>número-do-bug</var> <var>número-do-bug</var> ... <dd> @@ -209,14 +209,14 @@ (uma comparação exata de strings é 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 que os mesmos +<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 pelo merge. 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: é +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 log de cada relatório @@ -226,15 +226,16 @@ <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>forcemerge</code> <var>número-do-bug</var> <var>número-do-bug</var> ...</dt> +<dt><code>forcemerge</code> <var>número-do-bug</var> <var>número-do-bug</var> +...</dt> <dd>Une forçadamente dois ou mais relatórios de bug. O primeiro bug listado - é o bug principal, e suas configurações (as configurações que devem ser + é o bug principal, e suas configurações (as configurações que devem ser iguais numa união normal) são atribuídas aos bugs listados em seguida. Para evitar que erros de digitação unam bugs erroneamente, os bugs precisam estar no mesmo pacote. Veja o texto acima para uma descrição do que união ("merge") significa. - <p>Note que isto torna possível o fechamento de bugs na união; você é + <p>Note que isto torna possível o fechamento de bugs na união; você é responsável por notificar os relatores dos bugs com uma mensagem de fechamento apropriada se você fizer isto.</p> </dd> @@ -298,7 +299,7 @@ <code>sid</code> e <code>experimental</code>. <p>Para <a href="Developer#tags">os significados das tags</a> por favor - consulte a documentação geral dos desenvolvedores sobre sistema de bugs. + consulte a documentação geral dos desenvolvedores sobre o sistema de bugs. <dt><code>close</code> <var>número-do-bug</var> [ <var>versão-corrigida</var> ] (ultrapassado) @@ -307,7 +308,7 @@ 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 (ao -contrário do envio de uma mensagem para +contrário do envio de uma mensagem para <var>número-do-bug</var><code>[EMAIL PROTECTED]</code>) o texto da mensagem que fechou o bug <strong>não</strong> é incluído na notificação. O mantenedor que fecha o relatório precisa certificar-se, provavelmente @@ -320,7 +321,7 @@ acompanhamento de bugs perceberá que o bug foi corrigido para aquela versão do pacote. -<dt><code>package</code> [ <var>nome-do-pacote</var> ... ] +<dt><code>package</code> [ <var>nome-de-pacote</var> ... ] <dd>Limita os próximos comandos, fazendo com que eles sejam aplicados somente em erros relativos aos pacotes listados. Você pode listar um ou @@ -338,7 +339,7 @@ package bar retitle 123456 bar: bar fede severity 123456 normal - + package severity 234567 wishlist </pre> @@ -381,3 +382,4 @@ #use "otherpages.inc" #use "$(ENGLISHDIR)/Bugs/footer.inc" +
signature.asc
Description: Digital signature