Olá Thiago,
Segue em anexo o meu patch com pequenos ajustes.
Abraços,
Em 02/06/2020 15:39, Paulo Henrique de Lima Santana escreveu:
> Olá,
>
> Estou pegando esse arquivo pra revisar.
>
> Abs
>
> Em 31/05/2020 19:04, Thiago Pezzo escreveu:
>> Segue o arquivo para revisão.
>> É uma revisão longa e técnica,sugiro reservar por ITR.
>>
>>
>> Abraços,
>> Thiago Pezzo (Tico)
>>
>> Sent with ProtonMail Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Sunday, May 31, 2020 7:30 PM, Thiago Pezzo <pe...@protonmail.com> wrote:
>>
>>> Começando mais uma tradução para o sprint.
>>>
>>
>>> Abraços,
>>> Thiago Pezzo (Tico)
>>>
>>
>>> Sent with ProtonMail Secure Email.
>>
>
--
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Debian Developer
Diretor do Instituto para Conservação de Tecnologias Livres
Site: http://www.phls.com.br
GNU/Linux user: 228719 GPG ID: 0443C450
diff --git a/portuguese/devel/testing.wml b/portuguese/devel/testing.wml
index 7634c2efb67..60ead6c4265 100644
--- a/portuguese/devel/testing.wml
+++ b/portuguese/devel/testing.wml
@@ -1,29 +1,30 @@
-#use wml::debian::template title="A distribuição Debian “testing”" BARETITLE=true
+#use wml::debian::template title="A distribuição Debian teste (“testing”)" BARETITLE=true
#include "$(ENGLISHDIR)/releases/info"
-#use wml::debian::translation-check translation="dff9a7e24a95a70c3a3ceb430a8a02e9f3afb7d0" translation_maintainer="Felipe Augusto van de Wiel (faw)"
+#use wml::debian::translation-check translation="ff05f695462dd08fe524856384ed03a2dbb6763f" translation_maintainer="Felipe Augusto van de Wiel (faw)"
-<p>Para informações básicas, orientadas ao usuário, sobre a distribuição
-<q>testing</q>, veja a <a href="$(DOC)/manuals/debian-faq/ftparchives#testing">FAQ do
+<p>Para informações básicas aos(às) usuários(as) sobre a distribuição teste
+(<q>testing</q>), veja a <a href="$(DOC)/manuals/debian-faq/ftparchives#testing">FAQ do
Debian</a>.</p>
-<p>Uma coisa importante a ser notada, tanto para usuários regulares quanto
-para desenvolvedores, é que as atualizações de segurança <strong>não são
-gerenciadas pela equipe de segurança</strong>. Para mais informações
-veja a <a href="../security/faq#testing">FAQ da Equipe de Segurança</a>.</p>
+<p>Uma coisa importante a ser notada, tanto para usuários(as) regulares quanto
+para desenvolvedores(as), é que as atualizações de segurança da <q>testing</q>
+<strong>não são gerenciadas pela equipe de segurança</strong>. Para mais
+informações veja a
+<a href="../security/faq#testing">FAQ da equipe de segurança</a>.</p>
-<p>Esta página cobre primariamente os aspectos da <q>testing</q> que são
-importantes para desenvolvedores Debian.</p>
+<p>Esta página cobre, fundamentalmente, os aspectos da <q>testing</q> que são
+importantes para desenvolvedores(as) Debian.</p>
<h2>Como a <q>testing</q> funciona</h2>
<p>A distribuição <q>testing</q> é uma distribuição gerada automaticamente. Ela
-é gerada da distribuição instável (<q>unstable</q>) por um conjunto de scripts
-que tentam mover pacotes que provavelmente não possuem bugs críticos ao
+é gerada a partir da distribuição instável (<q>unstable</q>) por um conjunto de
+scripts que buscam mover pacotes que provavelmente não possuem bugs críticos ao
lançamento (<q>release-critical</q>). Eles o fazem de modo a garantir que as
dependências dos outros pacotes na <q>testing</q> sempre possam ser
satisfeitas.</p>
-<p>Uma versão particular de um pacote se moverá para a <q>testing</q> quando
+<p>Um pacote, de uma determinada versão, se moverá para a <q>testing</q> quando
ele satisfizer todos os seguintes critérios:</p>
<ol>
@@ -33,12 +34,12 @@ ele satisfizer todos os seguintes critérios:</p>
<li>Ele precisa estar compilado e atualizado em todas as arquiteturas
nas quais ele foi anteriormente compilado na instável (<q>unstable</q>);</li>
- <li>Ele precisa ter menos bugs críticos ao lançamento
- (<q>release-critical</q>) ou o mesmo número que a versão atualmente na
- <q>testing</q> (veja abaixo para <a href="#faq">mais informações</a>);</li>
+ <li>Não pode haver nenhum bug crítico (<q>release-critical</q>), o que também
+ se aplica à versão atualmente na <q>testing</q> (veja abaixo para
+ <a href="#faq">mais informações</a>);</li>
- <li>Todas as suas dependências precisam ser satisfeitas <em>ou</em>
- pelos pacotes que já estão na <q>testing</q> <em>ou</em> pelo grupo de
+ <li>Todas as suas dependências precisam ser satisfeitas, <em>ou</em>
+ pelos pacotes que já estão na <q>testing</q>, <em>ou</em> pelo grupo de
pacotes que serão instalados ao mesmo tempo;</li>
<li>A operação de instalação do pacote na <q>testing</q> não deve quebrar
@@ -46,8 +47,8 @@ ele satisfizer todos os seguintes critérios:</p>
<a href="#faq">mais informações</a>.)</li>
</ol>
-<p>Um pacote que satisfaz as três primeiras condições é considerado um
-<q>Candidatos Válido</q>.</p>
+<p>Um pacote que satisfaz as três primeiras condições acima é considerado um
+<q>candidato válido</q> (<q>valid candidate</q>).</p>
<p>O script de atualização mostra quando cada pacote deve mover-se da instável
(<q>unstable</q>) para a <q>testing</q>. A saída é dividida em duas partes:</p>
@@ -58,46 +59,49 @@ ele satisfizer todos os seguintes critérios:</p>
[<a href="https://release.debian.org/britney/update_excuses.html.gz";>\
compactadas com gzip</a>]:
listam todos as versões candidatas dos pacotes e o estado básico de sua
- propagação para a <q>testing</q>; ele é um pouco mais curto e mais
- agradável
+ propagação para a <q>testing</q>; é um pouco mais curto e mais
+ agradável que
</li>
<li>A <a href="https://release.debian.org/britney/update_output.txt";>\
saída de atualização (update output) </a>
[<a href="https://release.debian.org/britney/update_output.txt.gz";>\
compactada com gzip</a>]:
- a saída completa, quase sem processamento dos scripts da <q>testing</q>
+ a saída completa, pouco refinada, dos scripts da <q>testing</q>
conforme eles passam pelos candidatos
</li>
</ul>
-<h2><a name="faq">Questões Feitas/Respondidas Freqüentemente</a></h2>
+<h2><a name="faq">Dúvidas frequentes</a></h2>
-<h3><q>O que são bugs críticos ao lançamento (<q>release-critical</q>), e como
+# Nota para tradutores: estes dois primeiros itens são quase idênticos ao
+# https://www.debian.org/doc/manuals/developers-reference/pkgs.html#faq
+
+<h3><q>O que são bugs críticos ao lançamento (release-critical), e como
eles são contados?</q></h3>
-<p>Todos os bugs de algumas severidades altas são considerados
+<p>Todos os bugs de severidades altas são considerados
<em><a href="https://bugs.debian.org/release-critical/";>críticos ao
-lançamento</a></em> por padrão; atualmente, estas severidades são
-<strong>crítico</strong>, <strong>grave</strong> e <strong>sério</strong>.</p>
+lançamento</a></em> por padrão; atualmente, esses bugs são denominados de
+<strong>críticos (critical)</strong>, <strong>graves (grave)</strong> e
+<strong>sérios (serious)</strong>.</p>
<p>Presume-se que tais bugs tenham um impacto nas probabilidades do pacote
-ser lançado com a versão estável do Debian: em geral, se um pacote tem bugs
-críticos ao lançamento, ele não irá para a <q>testing</q>, e conseqüentemente
+ser lançado com a versão estável (<q>stable</q>) do Debian: em geral, se um pacote tem bugs
+críticos ao lançamento, ele não irá para a <q>testing</q>, e consequentemente
não será lançado na estável (<q>stable</q>).</p>
-<p>A contagem de bugs na <q>testing</q> de um pacote é considerada como
-aproximadamente a contagem de bugs no último momento no qual a versão na
-<q>testing</q> era a mesma da instável (<q>unstable</q>). Os bugs com tag
-<strong><current_release_name></strong> ou
-<strong><current_testing_name></strong> não serão contados. No entanto,
-bugs com a tag <strong>sid</strong> serão contados.</p>
+<p>
+A contagem de bugs na <q>testing</q> é constituída de todos os bugs críticos ao
+lançamento (<q>release-critical</q>) que, marcados para serem aplicados como
+combinações <tt>pacote/versão</tt>, ficam disponíveis na <q>testing</q> para
+lançamento em uma determinada arquitetura.</p>
-<h3><q>Como instalar um pacote na <q>testing</q> poderia quebrar os outros
-pacotes?</q></h3>
+<h3><q>Como a instalação de um pacote na testing poderia quebrar os
+outros pacotes?</q></h3>
<p>A estrutura dos repositórios da distribuição é tal que ela pode conter
somente uma versão de um pacote; um pacote é definido por seu nome. Assim,
-quando o pacote fonte <tt>acmefoo</tt> é instalado na <q>testing</q>, junto com
+quando o pacote-fonte <tt>acmefoo</tt> é instalado na <q>testing</q>, junto com
seus pacotes binários <tt>acme-foo-bin</tt>, <tt>acme-bar-bin</tt>,
<tt>libacme-foo1</tt> e <tt>libacme-foo-dev</tt>, a versão antiga é
removida.</p>
@@ -107,28 +111,28 @@ binário com um <q>soname</q> antigo de uma biblioteca, como
<tt>libacme-foo0</tt>. Remover o <tt>acmefoo</tt> antigo removerá o
<tt>libacme-foo0</tt>, quebrando qualquer pacote que dependa dele.</p>
-<p>Evidentemente, isto afeta principalmente pacotes que tem alterações
+<p>Evidentemente, isto afeta principalmente pacotes que têm alterações
de pacotes binários em versões diferentes (assim sendo, principalmente
bibliotecas). No entanto, pacotes nos quais há dependências de versões
declaradas com as comparações ==, <= ou << também serão afetados.</p>
-<p>Quando os pacotes binários vindos de um pacote fonte se alteram deste modo,
-todos os pacotes que dependem das bibliotecas antigas tem que ser
+<p>Quando os pacotes binários vindos de um pacote-fonte se alteram deste modo,
+todos os pacotes que dependam das bibliotecas antigas terão que ser
atualizados para depender dos binários novos. Como a instalação de tais
pacotes na <q>testing</q> quebram todos os pacotes que dependem deles na
<q>testing</q>, algum cuidado tem que ser tomado: todos os pacotes dependentes
precisam estar atualizados e prontos para serem instalados de modo que eles não
-estejam quebrados e, assim que tudo esteja pronto, a intervenção manual do
-gerenciador de lançamento ou um assistente geralmente é necessária.</p>
+se quebrarão e, assim que tudo esteja pronto, geralmente é necessária a
+intervenção manual do gerenciador de lançamento ou um assistente.</p>
<p>Se você está tendo problemas com grupos complicados de pacotes como estes,
-contate a debian-devel ou a debian-release para receber ajuda.</p>
+contate as listas de discussão debian-devel ou a debian-release para receber ajuda.</p>
<h3><q>Eu ainda não entendo! Os scripts da testing dizem
que este pacote é um candidato válido, mas ele ainda não foi para a
testing.</q></h3>
-<p>Isto tende a acontecer quando de algum modo, direto ou indireto,
+<p>Isto tende a acontecer quando, de algum modo direto ou indireto,
instalar o pacote vai quebrar algum outro pacote.</p>
<p>Lembre-se de considerar as dependências do seu pacote. Suponha que
@@ -149,33 +153,35 @@ texto</a>
[<a href="https://release.debian.org/britney/update_output.txt.gz";>\
compactada com gzip</a>]
é útil: ela dá dicas (embora bastante resumidas) de quais pacotes quebram
-quando um candidato válido é adicionado à <q>testing</q>.</p>
+quando um candidato válido é adicionado à <q>testing</q> (veja a
+<a href="$(DOC)/manuals/developers-reference/pkgs.html#details">\
+referência para desenvolvedores(as) para mais detalhes</a>).</p>
<h3><q>Por que algumas vezes é difícil ter pacotes <kbd>Architecture: all</kbd>
na testing?</q></h3>
<p>Se o pacote <kbd>Architecture: all</kbd> deve ser instalado, ele precisa
satisfazer suas dependências em <strong>todas</strong> as arquiteturas.
-Se ele depende de dados pacotes que compilam somente em um conjunto
+Se ele depende de determinados pacotes que compilam somente em um conjunto
limitado das arquiteturas do Debian, isto não será possível.</p>
-<p>No entanto, por enquanto, a <q>testing</q> ignorará a instalabilidade dos
-pacotes <kbd>Architecture: all</kbd> em arquiteturas não-i386. (<q>Isto
-é um hack grosseiro e eu não estou realmente feliz em ter feito isto,
-mas aí vai.</q> —aj)</p>
+<p>No entanto, e por enquanto, a <q>testing</q> ignorará a capacidade de
+instalação dos pacotes <kbd>Architecture: all</kbd> em arquiteturas não-i386.
+(<q>Isto é um hack grosseiro e eu não estou realmente feliz em ter feito isto,
+mas que seja.</q> —aj)</p>
<h3><q>Meu pacote está parado porque ele está desatualizado em alguma
arquitetura. O que eu devo fazer?</q></h3>
<p>Verifique o estado de seu pacote no
<a href="https://buildd.debian.org/build.php";>banco de dados de logs de
-construção</a>. Se o pacote não pode ser compilado, ele estará marcado como
-<em>failed</em>; investigue os logs e corrija todos os problemas
+construção</a>. Se o pacote não pode ser construído, ele estará marcado como
+<em>failed</em> (falha); investigue os logs e corrija todos os problemas
que foram causados pelas fontes do seu pacote.</p>
<p>Se você notar que alguma arquitetura construiu a versão nova do seu
-pacote mas ele não está aparecendo na saída dos scripts da <q>testing</q>,
-você só precisa ser um pouco mais paciente até que o mantenedor do
+pacote, mas ele não está aparecendo na saída dos scripts da <q>testing</q>,
+você só precisa ser um pouco mais paciente até que o(a) mantenedor(a) do
respectivo buildd faça o upload dos arquivos para o repositório Debian.</p>
<p>Se você notar que algumas arquiteturas não construíram a nova versão de
@@ -183,40 +189,40 @@ seu pacote, apesar de você ter feito o upload de uma correção para uma
falha anterior, o motivo provavelmente é que ele está marcado como
esperando por dependências (Dep-Wait). Você também pode ver a lista dos
chamados <a href="https://buildd.debian.org/stats/";>wanna-build states</a>
-(estados quer-construir) para se certificar.</p>
+(estados quer construir) para se certificar.</p>
-<p>Estes problemas geralmente são corrigidos eventualmente, mas se você
+<p>Estes problemas acabam sendo corrigidos eventualmente, mas se você
está esperando por um período longo de tempo (digamos, duas semanas ou mais),
-notifique o mantenedor do buildd do respectivo porte se tal endereço estiver
-documentado nas <a href="$(HOME)/ports/">páginas dos portes</a>, ou a lista
-de discussão do porte.</p>
+notifique o(a) mantenedor(a) do buildd do respectivo porte se tal contato
+estiver documentado nas <a href="$(HOME)/ports/">páginas dos portes</a>, ou
+notifique a lista de discussão do porte.</p>
-<p>Se você explicitamente removeu uma arquitetura da lista Architecture no
+<p>Se você explicitamente removeu uma arquitetura da lista <kbd>Architecture</kbd> no
arquivo de controle (<q>control</q>), e o pacote foi construído para aquela
-arquitetura anteriormente, você precisa requisitar a remoção do antigo pacote
-binário para esta arquitetura seja removido do repositório antes que seu
-pacote possa fazer a transição para a <q>testing</q>. Você precisa reportar
+arquitetura anteriormente, você precisa requisitar a remoção, no repositório,
+do antigo pacote binário para esta arquitetura antes que seu pacote possa fazer
+a transição para a <q>testing</q>. Você precisa reportar
um bug contra <q>ftp.debian.org</q> requisitando remoção de todos os pacotes
das arquiteturas removidas do repositório instável (<q>unstable</q>).
-Geralmente a lista do <q>porte</q> em questão deveria ser informada como forma
+Geralmente, a lista do <q>porte</q> em questão deve ser informada como forma
de cortesia.</p>
-<h3><q>Há alguma exceção? Eu tenho certeza que o <tt>acmefoo</tt>
+<h3><q>Existem algumas exceções? Eu tenho certeza que o <tt>acmefoo</tt>
entrou na testing apesar de não satisfazer todos os requerimentos.</q></h3>
-<p>O gerente de lançamento pode sobrepujar as regras de dois modos:</p>
+<p>Os(As) gerentes de lançamento podem sobrepujar as regras de dois modos:</p>
<ul>
- <li>Ele pode decidir que a quebra causada pela instalação de uma nova
- biblioteca irá tornar as coisas melhores ao invés de piores, e deixá-la
+ <li>Eles(as) podem decidir que a quebra causada pela instalação de uma nova
+ biblioteca irá tornar as coisas melhores em vez de piores, e deixá-la
entrar na <q>testing</q> junto com suas dependências.</li>
- <li>Ele também pode remover manualmente pacotes da <q>testing</q> que
+ <li>Eles(as) também podem remover manualmente pacotes da <q>testing</q> que
ficariam quebrados, para que o novo material possa ser instalado.</li>
</ul>
-<h3><q>Você pode dar um exemplo real, não-trivial?</q></h3>
+<h3><q>Você pode dar um exemplo real e não trivial?</q></h3>
-<p>Aqui está um: quando o pacote fonte <tt>apache</tt> é instalado na
+<p>Aqui está um: quando o pacote-fonte <tt>apache</tt> é instalado na
<q>testing</q>, junto com seus pacotes binários <tt>apache</tt>,
<tt>apache-common</tt>, <tt>apache-dev</tt> e <tt>apache-doc</tt>, a
versão antiga é removida.</p>
@@ -224,30 +230,30 @@ versão antiga é removida.</p>
<p>No entanto, todos os pacotes de módulos do Apache dependem de
<code>apache-common (>=<var>alguma-coisa</var>), apache-common
(<< <var>alguma-coisa</var>)</code>, assim esta alteração quebra
-todas estas dependências. Conseqüentemente, todos os módulos Apache
+todas essas dependências. Consequentemente, todos os módulos Apache
precisam ser recompilados contra a nova versão do Apache para a
<q>testing</q> ser atualizada.</p>
<p>Vamos elaborar mais um pouco: depois que todos os módulos foram
-atualizadas na <q>instável</q> para trabalhar com o novo Apache, os scripts
+atualizados na <q>instável</q> para trabalhar com o novo Apache, os scripts
da <q>testing</q> tentam <tt>apache-common</tt> e descobrem que ele quebra
todos os módulos Apache porque eles tem <code>Depends: apache-common
-(<< <var>a versão atual</var>)</code>, e então tentam
+(<< <var>a versão atual</var>)</code>; e então tentam
<tt>libapache-<var>foo</var></tt> para descobrir que ele não instala
porque ele tem <code>Depends: apache-common (>= <var>a versão
nova</var>)</code>.</p>
<p>No entanto, posteriormente eles aplicarão uma lógica diferente
-(algumas vezes pedidas por uma intervenção manual): eles ignorarão o
-fato que o <tt>apache-common</tt> quebra coisas, e continuar indo com as
-coisas que funcionam; se isto ainda não funcionar depois que nós fizermos
-tudo que nós podíamos, muito mal, mas talvez isto <strong>irá</strong>
+(algumas vezes isso é requisitado por uma intervenção manual): eles ignorarão o
+fato de que o <tt>apache-common</tt> quebra coisas, e continuarão com o que
+funciona; se isto ainda não funcionar depois que nós fizermos
+tudo que podíamos, tudo bem, mas talvez isto <strong>irá</strong>
funcionar. Posteriormente eles tentarão todos os pacotes
-<tt>libapache-<var>foo</var></tt> e verificar se eles realmente funcionam.</p>
+<tt>libapache-<var>foo</var></tt> e verificarão se eles realmente funcionam.</p>
<p>Depois que tudo tiver sido tentado, eles verificam quantos pacotes
-foram quebrados, analisam se isto é melhor ou pior que o que havia
-originalmente e aceitar tudo ou esquecer sobre isto. Você verá isto no
+foram quebrados, analisam se isto é melhor ou pior do que havia
+originalmente, e aceitam tudo ou esquecem tudo. Você verá isto no
<tt>update_output.txt</tt> nas linhas <q><code>recur:</code></q>.</p>
<p>Por exemplo:</p>
@@ -256,12 +262,13 @@ originalmente e aceitar tudo ou esquecer sobre isto. Você verá isto no
recur: [<var>foo</var> <var>bar</var>] <var>baz</var>
</pre>
-<p>basicamente diz <q>já tendo descoberto que <var>foo</var> e
-<var>bar</var> torna as coisas melhores, Eu estou agora tentando
-<var>baz</var> para ver o que acontece, apesar disto quebrar coisas</q>. As
-linhas do <tt>update_output.txt</tt> que começam com
-<q><code>accepted</code></q> indicam coisas que parecem tornar as coisas
-melhores, e linhas <q><code>skipped</code></q> deixam as coisas piores.</p>
+<p>basicamente diz que, <q>já tendo descoberto que <var>foo</var> e
+<var>bar</var> tornam as coisas melhores, eu estou agora tentando
+<var>baz</var> para ver o que acontece, mesmo sabendo que vai quebrar algo</q>.
+As linhas do <tt>update_output.txt</tt> que começam com
+<q><code>accepted</code></q> (aceito) indicam algo que parece tornar as
+coisas melhores, e linhas <q><code>skipped</code></q> (ignorado) indicam algo
+que deixam as coisas piores.</p>
<h3><q>O arquivo <tt>update_output.txt</tt> é completamente ilegível!</q></h3>
@@ -276,30 +283,32 @@ melhores, e linhas <q><code>skipped</code></q> deixam as coisas piores.</p>
</pre>
<p>Isto significa que se o <tt>cln</tt> entrar na <q>testing</q>,
-<tt>ginac-cint</tt> e <tt>libginac-dev</tt> tornam-se não-instaláveis
+<tt>ginac-cint</tt> e <tt>libginac-dev</tt> tornam-se não instaláveis
na <q>testing</q> no i386. Note que as arquiteturas são verificadas em ordem
alfabética e que somente os problemas na primeira arquitetura problemática
são mostrados — é por isso que a arquitetura alpha é mostrada tão
-freqüentemente.</p>
+frequentemente.</p>
<p>A linha <q>got</q> inclui o número de problemas na <q>testing</q> nas
-arquiteturas diferentes (até a primeira arquitetura onde um problema é
+diferentes arquiteturas (até a primeira arquitetura onde um problema é
encontrado — veja acima). <q>i-45</q> significa que se o <tt>cln</tt>
fosse para a <q>testing</q>, haveria 45 pacotes não-instaláveis na i386.
Algumas das entradas acima e abaixo do <tt>cln</tt> mostram que havia 43
-pacotes não-instaláveis na <q>testing</q> nesta arquitetura naquele momento.</p>
+pacotes não-instaláveis na <q>testing</q>, na arquitetura i386 e naquele
+momento.</p>
<p>A linha <q>skipped: cln (0) (150+4)</q> significa que ainda há 150 pacotes
-para checar após este pacote até esta verificação de todos os pacotes ser
-completada, e que 4 pacotes que não vão ser planejados para atualização pois
-quebrariam dependências já foram encontrados. O <q>(0)</q> é irrelevante, você
-pode ignorá-lo seguramente.</p>
+para checar, após o pacote em questão, até que a verificação de todos os pacotes
+seja completada; e que 4 pacotes já estão planejados para não serem atualizados,
+pois quebrariam dependências. O <q>(0)</q> é irrelevante, você
+pode ignorá-lo sem receios.</p>
-<p>Note que há várias verificações de todos os pacotes em uma rodada dos
+<p>Observe que há várias verificações de todos os pacotes em uma rodada dos
scripts da <q>testing</q>.</p>
-<p><em>Jules Bean montou inicialmente as questões freqüentemente feitas e
-as respostas.</em></p>
+<p><em>Jules Bean organizou inicialmente as questões e respostas frequentemente
+feitas.</em></p>
+# Created: Sat Dec 8 12:44:29 GMT 2001
<h2>Informações Adicionais</h2>
@@ -308,30 +317,22 @@ as respostas.</em></p>
<ul>
<li>Estatísticas sobre pacotes binários que estão desatualizados para
-<q><a href="https://release.debian.org/britney/testing_outdate.txt";>\
-testing</a></q>,
-<a href="https://release.debian.org/britney/stable_outdate.txt";>\
-estável</a>
-</li>
-<li>
-<q><a href="https://qa.debian.org/debcheck.php?list=INDEX&dist=testing";>\
-testing</a></q>,
-<a href="https://qa.debian.org/debcheck.php?list=INDEX&dist=stable";>\
-estável</a>
-</li>
-<li><a href="https://release.debian.org/migration/";>Interface web</a> agradável
-para ajudá-lo a encontrar porque pacotes estão sendo retidos fora da
-<q>testing</q>.
-</li>
+<a href="https://release.debian.org/britney/testing_outdate.txt";><q>testing</q></a>,
+<a href="https://release.debian.org/britney/stable_outdate.txt";>estável (<q>stable</q>)</a></li>
+<li>Problemas de dependência em
+<a href="https://qa.debian.org/debcheck.php?list=INDEX&dist=testing";><q>testing</q></a>,
+<a href="https://qa.debian.org/debcheck.php?list=INDEX&dist=stable";>estável (<q>stable</q>)</a></li>
+<li>Um <a href="https://release.debian.org/migration/";>front-end web</a> legal
+para te ajudar a saber quais pacotes estão sendo mantidos fora da <q>testing</q>.</li>
</ul>
<p>Você pode estar interessado em ler um antigo
<a href="https://lists.debian.org/debian-devel-0008/msg00906.html";>e-mail de
-explicação</a>. Sua única grande falha é que ela não leva em conta o pool dos
-pacotes, porque ele foi implementado por James Troup depois que ela foi
-escrita.</p>
+explicação</a>. Sua única grande falha é que ele não leva em conta o pool dos
+pacotes, porque isto foi implementado por James Troup depois que o e-mail foi
+escrito.</p>
<p>O código da <q>testing</q> está disponível em
<a href="https://release.debian.org/britney/update_out_code/";>ftp-master</a>.</p>
-<p><em>Anthony Towns leva os créditos pela implementação da testing.</em></p>
+<p><em>Anthony Towns leva os créditos pela implementação da <q>testing</q>.</em></p>
