Oi, pessoal.

Segue em anexo o patch para revisão.

Grato.

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, 17 de June de 2020 às 11:16, Harley Sousa 
<harleyso...@protonmail.com> wrote:

> Estarei fazendo a atualização desta página.
>
> Abraços.
>
> Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.
diff --git a/portuguese/devel/buildd/index.wml b/portuguese/devel/buildd/index.wml
index 56aad668c7d..78a57e5dd86 100644
--- a/portuguese/devel/buildd/index.wml
+++ b/portuguese/devel/buildd/index.wml
@@ -1,5 +1,5 @@
 #use wml::debian::template title="Rede de construtores automáticos (<q>Autobuilder network</q>)" BARETITLE="true"
-#use wml::debian::translation-check translation="c9760a65ef12fddf196808e203b60ad7e18b4787"
+#use wml::debian::translation-check translation="cc0db4d4087a4f97b1a3955e3ca0f84b31caf8a9"
 
 <p>A rede de construtores automáticos (<q>autobuilder network</q>) é um
 desenvolvimento Debian que ajuda a agilizar as recompilações de pacotes
@@ -13,30 +13,32 @@ repositório Debian e reconstruí-los para a arquitetura alvo.</p>
 é necessária?</h2>
 
 <p>A distribuição Debian suporta <a href="$(HOME)/ports/">algumas
-arquiteturas</a>,
-mas os mantenedores de pacote usualmente só compilam as versões
-binárias para uma única arquitetura (normalmente i386).
-Desenvolvedores para outras arquiteturas precisam acompanhar
-novas versões dos pacotes e recompilá-los se eles querem ficar
-atualizados com a distribuição Intel.</p>
+arquiteturas</a>, mas os(as) mantenedores(as) de pacote usualmente só
+compilam as versões binárias para uma única arquitetura
+(normalmente i386 ou amd64). As outras construções são
+produzidas automaticamente, garantindo que cada pacote seja
+construído apenas uma vez. As falhas são rastreadas no banco
+de dados do autobuilder.</p>
 
 <p>
-Quando o Debian/m68k (o primeiro porte não-Intel) começou, tudo isto
-era feito manualmente: desenvolvedores olhavam a lista de discussão
-de <q>uploads</q> em busca de novos pacotes e pegavam alguns deles para
-construção. A coordenação para que nenhum pacote fosse construído duas
-vezes por diferentes pessoas era feita através de anúncios em uma lista de
-discussão. É óbvio que este procedimento é suscetível a erros e consome
-muito tempo. Isto foi, no entanto, a forma usual de manter distribuições
-não-i386 atualizadas por um bom tempo.
+Quando o Debian/m68k (o primeiro porte não Intel) começou, os
+desenvolvedores tinham que ficar atentos a novas versões de pacotes
+e recompilá-los se quisessem manter-se atualizados com a distribuição
+da Intel. Tudo isso era feito manualmente: desenvolvedores olhavam a
+lista de discussão de <q>uploads</q> em busca de novos pacotes e pegavam
+alguns deles para construção. A coordenação para que nenhum pacote fosse
+construído duas vezes por diferentes pessoas era feita através de
+anúncio em uma lista de discussão. É óbvio que este procedimento é
+suscetível a erros e consome muito tempo. No entanto, essa era a maneira
+usual de manter as distribuições não i386 atualizadas.
 </p>
 
 <p>
 O sistema de daemon de construção automatiza a maioria deste processo.
 Ele consiste de um conjunto de scripts (escritos em Perl e Python) que
 evoluíram através do tempo para ajudar portadores em várias tarefas.
-Eles finalmente desenvolveram um sistema que é capaz de manter distribuições
-Debian não-i386 atualizadas quase que automaticamente.
+Eles finalmente desenvolveram um sistema que é capaz de manter
+distribuições Debian não i386 atualizadas quase que automaticamente.
 </p>
 
 
@@ -48,43 +50,32 @@ na verdade ele é feito de diferentes partes:</p>
 
 <dl>
 
-<dt><a href="http://svn.cyberhqz.com/svn/wanna-build/";>wanna-build</a></dt>
+<dt>wanna-build</dt>
 <dd>
 uma ferramenta que ajuda a coordenar a (re)construção de pacotes através
 de um banco de dados que mantém uma lista de pacotes e seus estados. Há
 um banco de dados central por arquitetura que armazena os estados dos
-pacotes, versões, e algumas outras informações.
+pacotes, versões, e algumas outras informações. Ele é abastecido com
+arquivos de fontes e pacotes recuperados dos vários arquivos de pacotes
+que o Debian possui (por exemplo, ftp-master e security-master).
 </dd>
 
-<dt><a href="http://svn.cyberhqz.com/svn/wanna-build/";>buildd</a></dt>
+<dt><a href="https://packages.debian.org/buildd";>buildd</a></dt>
 <dd>
 um daemon que, periodicamente, verifica o banco de dados mantido pela
 <em>wanna-build</em> e chama o <em>sbuild</em> para construir os pacotes.
-Ele acompanha falhas e sucessos na construção, e também envia pacotes
-após o log de construção ter sido reconhecido pelo administrador.
+Após o log de construção ter sido reconhecido pelo administrador, o
+pacote é enviado para o arquivo apropriado.
 </dd>
 
 <dt><a href="https://packages.debian.org/sbuild";>sbuild</a></dt>
 <dd>
-é responsável pela real compilação dos pacotes em chroots isoladas.
-Ele usa principalmente ferramentas Debian padrão para isto, mas também
-cuida das dependências de código fonte e alguns outros pequenos detalhes.
-</dd>
-
-<dt><a href="https://packages.debian.org/quinn-diff";>quinn-diff</a></dt>
-<dd>
-Alimenta o banco de dados wanna-build com novos pacotes. Ele compara
-as versões de pacotes disponíveis para duas arquiteturas e fornece as
-diferenças (comparando um arquivo Sources e um arquivo Packages).
-Mais informação sobre o quinn-diff está disponível
-<a href="https://buildd.debian.org/quinn-diff/";>aqui</a>.
-</dd>
-
-<dt>andrea</dt>
-<dd>
-Uma ferramenta que gera algumas dependências de código fonte
-automaticamente e mescla estes dados com dependências adicionadas
-manualmente.
+é responsável pela compilação real dos pacotes em chroots isoladas.
+Ele garante que todas as dependências de origem necessárias sejam
+instaladas no chroot antes da compilação e depois chama as ferramentas
+padrão do Debian para iniciar o processo de compilação. Os logs de
+construção são enviados ao
+<a href="https://buildd.debian.org";>banco de dados de logs de construção</a>.
 </dd>
 
 </dl>
@@ -101,28 +92,33 @@ adicionado ao banco de dados para todas as arquiteturas (no estado
 <em>Needs-Build</em>).
 Máquinas construtoras consultarão o banco de dados de construção em
 busca de pacotes neste estado e, rotineiramente, pegarão pacotes desta
-lista. A lista é priorizada pelo estado de compilação anterior, prioridade,
-seção e, finalmente, nome do pacote.</p>
-
-<p>Se o processo de construção for bem sucedido em todas as arquiteturas, o
-mantenedor não precisará fazer nada. Todos esses pacotes binários serão
-enviados ao local principal da arquitetura. Se o processo de construção
-falhar o pacote entrará em um estado especial (<em>Failed</em> ou
-<em>Dep-Wait</em>, se ele possui dependências de construção específicas
-que não estão disponíveis). Os administradores da rede de construtores
-automáticos revisarão os pacotes cuja construção falhou e entrarão em
-contato com o mantenedor, usualmente, abrindo um bug no Sistema de
-Acompanhamento de Bug.</p>
+lista. A lista é priorizada pelo estado de compilação anterior
+(either <em>desatualizado</em> ou <em>não compilado</em>), prioridade,
+seção e nome do pacote. Além disso, para impedir que alguns pacotes
+passem tempo demais no final da fila, as prioridades são ajustadas
+dinamicamente com o aumento do tempo de espera na fila.</p>
+
+<p>Se o processo de construção for bem sucedido em todas as arquiteturas,
+o mantenedor não precisará fazer nada. Todos esses pacotes binários serão
+enviados ao arquivo correspondente. Se o processo de construção
+falhar, o pacote entrará em um estado especial (<em>Build-Attempted</em>
+para falhas de construção que não foram revisadas, <em>Failed</em> para
+erros revisados e relatados no pacote ou <em>Dep-Wait</em>, se ele possui
+dependências de construção específicas que não estão disponíveis).
+Os administradores da rede de construtores automáticos revisarão os
+pacotes cuja construção falhou e entrarão em contato com o mantenedor,
+usualmente, abrindo um bug no Sistema de Acompanhamento de Bug.</p>
 
 <p>Algumas vezes um pacote leva um longo tempo para construir em uma dada
 arquitetura e isso impede que o pacote entre na
-<a href="$(HOME)/devel/testing">testing</a>. Infelizmente, o pacote terá
-que esperar até que uma máquina o pegue. Administradores buildd não
-aceitarão pedidos para agilizar a construção de um pacote uma vez que a
-lista de prioridade já está estabelecida.
-
-<p>Você pode verificar esse estado das diferentes tentativas das buildds dos
-pacotes que pertencem a qualquer mantenedor verificando os
+<a href="$(HOME)/devel/testing">testing</a>. Se um pacote conter uma
+transição, as prioridades de criação são geralmente ajustadas mediante
+solicitação pela Equipe de Lançamento. Outras solicitações não serão
+aceitas, pois o aumento do tempo de espera na fila, resultará em uma
+prioridade de compilação mais alta automaticamente.</p>
+
+<p>Você pode verificar esse estado das diferentes tentativas das buildds
+dos pacotes que pertencem a qualquer mantenedor verificando os
 <a href="https://buildd.debian.org/status/";>logs da buildd</a>.
 Estes logs também estão ligados a partir da Visão Geral do Mantenedor
 do Pacote.</p>
@@ -135,14 +131,14 @@ estar, por favor, leia <a href="wanna-build-states">wanna-build-states</a>.</p>
 <p>É claro que, tanto a documentação quando o código fonte disponíveis
 para estas diferentes ferramentas são a melhor forma de entender como a
 rede buildd funciona. Adicionalmente, a seção
-<a href="$(HOME)/doc/manuals/developers-reference/pkgs#porting">\
-Portando e sendo portado</a> (<q>Porting and being ported</q>) da
+<a href="$(HOME)/doc/manuals/developers-reference/pkgs.html#porting">\
+Portando e sendo portado</a> (<q>Porting and being ported</q>) da-
 <a href="$(HOME)/doc/manuals/developers-reference/">Referência do
 Desenvolvedor Debian</a> fornece informação complementar sobre como
 a rede funciona e também fornece alguma informação sobre
-<a href="$(HOME)/doc/manuals/developers-reference/tools#tools-builders">\
+<a href="$(HOME)/doc/manuals/developers-reference/tools.html#tools-builders">\
 construtores de pacotes</a> e
-<a href="$(HOME)/doc/manuals/developers-reference/tools#tools-porting">\
+<a href="$(HOME)/doc/manuals/developers-reference/tools.html#tools-porting">\
 ferramentas de <q>porting</q></a> que estão envolvidas no processo tanto de
 configuração quanto de manutenção da rede buildd.</p>
 
@@ -155,9 +151,6 @@ configuração quanto de manutenção da rede buildd.</p>
 pode querer configurar e usar uma rede de construtores automáticos:</p>
 
 <ul>
-<li>Para testar localmente se o campo <tt>Build-Depends</tt> do pacote está
-apropriadamente definido (i.e. pela compilação do pacote dentro do ambiente
-de construção automática).</li>
 <li>Para ajudar no desenvolvimento de um porte para uma dada arquitetura
 (quanto construtores automáticos são necessários).</li>
 <li>Para avaliar o impacto de uma dada otimização de compilador ou patch
@@ -169,21 +162,16 @@ como uma forma de contornar pacotes usando <tt>dpatch</tt>.</li>
 </ul>
 
 <p>Você pode ler mais informação sobre como você pode
-<a href="setting-up">configurar um construtor automático
+<a href="https://wiki.debian.org/BuilddSetup";>configurar um construtor automático
 (<q>autobuilder</q>)</a>.</p>
 
 <h2>Contatando os administradores das buildds</h2>
 
 <p>Os administradores responsáveis pelas buildds para uma arquitetura
-específica podem ser contatados em <email arquitet...@buildd.debian.org>,
+específica podem ser contatados em <email a...@buildd.debian.org>,
 por exemplo <email i...@buildd.debian.org>. (Lembre-se que os contatos
 deverão ser feitos em inglês).</p>
 
-<p>Nomes dos administradores das buildds também podem ser encontrados em
-<a href="http://www.buildd.net/";>www.buildd.net</a>. Escolha uma arquitetura
-e uma distribuição para ver as buildds disponíveis e seus respectivos
-administradores.</p>
-
 <hrline />
 <p><small>Esta introdução à rede de construtores automáticos foi escrita
 com bits e peças fornecidos por Roman Hodek,

Responder a