[RFR] wml://www.debian.org/devel/buildd/wanna-build-states.wml
Segue uma nova tradução para revisão.
Abraços,
Thiago Pezzo (Tico)
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, 12 de September de 2020 às 14:58, Thiago Pezzo <pezzo@protonmail.com> wrote:
> Vou traduzir esses arquivos.
>
> Abraços,
> Thiago Pezzo (Tico)
>
> Sent with ProtonMail Secure Email.
#use wml::debian::template title="Estados wanna-build: uma explicação" BARETITLE="true"
#use wml::debian::translation-check translation="b8114b588961778dbd04974c1464a2f388a90c28"
<p>Esta página tenta explicar o que significa cada estado wanna-build (em
português, "quer-construir"). Sua audiência-alvo é mantenedores(as) de
pacotes Debian que tentam entender porque seu pacote foi, ou não foi,
construÃdo para uma determinada arquitetura. Além disso, uma explicação
dos diferentes resultados de log é dada.</p>
<p>Finalmente, uma versão em fluxograma dos estados wanna-build está
<a href="#graphlink">disponÃvel</a>, mas note que ele não fala sobre
tudo que é mencionado neste documento.</p>
<h2>Os estados wanna-build</h2>
<p>Para cada arquitetura suportada pelo Debian, existe um banco de dados
wanna-build instalado em buildd.debian.org, com todos os pacotes e seus estados
atuais de compilação. Existem 8 estados: <em>needs-build</em>,
<em>building</em>, <em>uploaded</em>, <em>dep-wait</em>,
<em>BD-Uninstallable</em>, <em>failed</em>, <em>not-for-us</em> e
<em>installed</em>.</p>
<p>Seus significados:</p>
<dl>
<dt><a name="needs-build">needs-build</a></dt>
<dd>Um pacote marcado <em>needs-build</em> (precisa-construir) teve uma
nova versão enviada pelo(a) mantenedor(a), mas para uma arquitetura
diferente daquela que este banco de dados wanna-build dirige-se;
como tal, ele precisa de uma reconstrução. Se o estado é
<em>needs-build</em>, ele ainda não foi pego por um autoconstrutor
(autobuilder), mas será (quando um esteja disponÃvel no momento que tal
pacote esteja próximo ao topo da lista). As pessoas normalmente dizem
que <q>um pacote está na fila para reconstruir</q> quando elas estão
falando sobre um pacote no estado <em>needs-build</em>.<br />
Pode ser interessante notar que a fila <em>needs-build</em>
não é uma fila FIFO; ao contrário, a ordenação utilizada é baseada
nos seguintes critérios:
<ol>
<li>Estados anteriores de compilação dos pacotes; os pacotes que
foram previamente construÃdos recebem prioridade sobre novos
pacotes.
</li>
<li>prioridades (pacotes com prioridade <em>required</em> - requerido
- são construÃdos antes que pacotes com prioridade <em>extra</em>)
</li>
<li>A seção em que um pacote está. Este ordenamento é baseado naquilo
que se considera mais importante sobre os pacotes; por exemplo, a
seção <em>games</em> é construÃda depois da seção <em>base</em>, e
a seção <em>libs</em> é construÃda antes de <em>devel</em>.
</li>
<li>uma ordem "asciibética" pelo nome do pacote.</li>
</ol>
Adicionalmente, sob certas condições, pode acontecer que um buildd
não receba pacotes do começo da fila; por exemplo,
quando um buildd não consegue encontrar a fonte de um dado pacote, ele
o colocará de volta na fila (onde então ele será novamente colocado
em sua posição anterior, isto é, no começo da fila), mas ele ignorará
o pacote por algumas horas. Outro exemplo onde isto poderia acontecer
é quando uma arquitetura tem múltiplos autoconstrutores;
neste caso, as pessoas que portam a arquitetura podem escolher construir
pacotes maiores em seus autoconstrutores mais rápidos e deixar os
pacotes menores para as máquinas mais lentas do grupo. Um buildd também
pode, em tese, requisitar explicitamente uma ordenação de seção
diferente, mas isto geralmente não é feito.<br />
Poderiam existir outras situações onde a ordem da fila parece ser
ignorada; mas note que são sempre exceções.
</dd>
<dt><a name="building">building</a></dt>
<dd>Um pacote é marcado com <em>building</em> (construindo) do momento em
que um autoconstrutor o pega do topo da fila wanna-build
até o momento em que a administração do autoconstrutor responde ao log.
Como os pacotes não são escolhidos um a um, isto significa que um pacote
pode ser (e geralmente é) marcado com <em>building</em> antes que a
construção tenha realmente iniciado; contudo, como o buildd constrói
pacotes em sua fila local com base em FIFO, não deve demorar muito.
Além disso, note que o estado de um pacote <strong>não</strong> é
modificado um vez que a construção foi completada; somente
quando a administração do autoconstrutor aparece para responder aos
logs.</dd>
<dt><a name="uploaded">uploaded</a></dt>
<dd>Quando uma tentativa de construção é bem sucedida, um log de
construção é enviado para a administração do autoconstrutor e para
buildd.debian.org. Então o(a) mantenedor(a) do autoconstrutor assina o
arquivo .changes que está embutido no log de construção e o envia para
o autoconstrutor. Como reação, o autoconstrutor fará o upload do
pacote e definirá seu estado para <em>uploaded</em>. Como tal, um
pacote neste estado pode ser encontrado na fila do repositório de
entrada (incoming) (em algum lugar).<br />
Um autoconstrutor não tocará mais em um pacote uma vez que seu estado
é <em>uploaded</em>, ou pelo menos não o fará até o próximo upload
ou até que a equipe de porte manualmente modifique o estado do pacote.
</dd>
<dt><a name="dep-wait">dep-wait</a></dt>
<dd>Quando um pacote falha devido à ausência de dependências durante o
tempo de construção (build-time), o(a) mantenedor(a) do autoconstrutor
enviará um e-mail para o autoconstrutor, instruindo-o a remover as
fontes do pacote e a marcar o pacote como <em>dep-wait</em>
(aguarda-dependência) para as dependências de construção
(build-dependencies). Um pacote em tal estado, automaticamente e sem
intervenção humana, será marcado com needs-build quando essas
dependências estiverem disponÃveis.<br />
Originalmente, um pacote tinha que passar por uma tentativa de
construção antes que o(a) mantenedor(a) pudesse colocá-lo manualmente
no estado <em>dep-wait</em>. Contudo, em agosto de 2005, alguns códigos
foram adicionados para o wanna-build, os quais fazem com que um pacote
se mova do estado <em><a href='#installed'>installed</a></em>
(instalado) diretamente para o estado <em>dep-wait</em> se isso for
apropriado.<br />
Existem dois casos especÃficos em que pode acontecer que um
pacote fique marcado como dep-wait para sempre; quando um erro de
digitação ocorre ao especificar as dependências <em>dep-wait</em>
(de modo que o pacote é marcado como dep-wait para um pacote que não
existe e nunca existirá) e quando uma dependência de tempo de construção
é declarada em um pacote que está marcado como <em>not-for-us</em>,
que está na lista <em>packages-arch-specific</em>
(pacotes-de-arquitetura-especÃfica).<br />
Como um exemplo deste último caso, considere três pacotes: um pacote
<tt>foo</tt>, que existe para <tt>i386</tt> somente; um pacote
<tt>bar</tt>, que existe para <tt>m68k</tt> somente (e que realiza
aproximadamente a mesma função); e um pacote <tt>baz</tt>, que pode ser
construÃdo com um deles, <tt>foo</tt> ou <tt>bar</tt>. Se o(a)
mantenedor(a) do pacote <tt>baz</tt> esquecer de adicionar <tt>bar</tt>
ao Build-Depends, e se ela ou ele adicioná-lo quando notificar-se que
<tt>baz</tt> está em <em>dep-wait</em> para um pacote <tt>foo</tt> não
existente para <tt>m68k</tt>, então o estado <em>dep-wait</em> para
<tt>m68k</tt> terá que ser manualmente retirado pela equipe de porte
do <tt>m68k</tt>.
</dd>
<dt><a name="bd-uninstallable">BD-Uninstallable</a></dt>
<dd>Durante a DebConf9, o <a
href='https://lists.debian.org/debian-wb-team/2009/07/msg00089.html'>Joachim
Breitner teve a ideia</a> de usar edos-debcheck para verificar
a instalabilidade de dependências de construção (build-dependency) dos
pacotes que, de outro modo, iriam para o estado Needs-Build. Naquele
momento, o wanna-build já tinha a capacidade de verificar a
disponibilidade imediata de dependências de construção; mas se um
pacote não pudesse ser instalado porque, na construção, ele depende de
a, que depende de b, que depende de c (>=1.2.3), e c ainda está na
versão 1.2.2, isto não seria detectado e a construção logo falharia
devido a dependências de construção não disponÃveis. Essa descoberta
era um processo manual para a administração do buildd e, geralmente,
era um processo demorado. Com o patch BD-Uninstallable, não é mais
um problema. Quando seu pacote está em BD-Uninstallable, significa que
uma das dependências de construção não é instalável (imediatamente ou
porque parte de sua árvore de dependências não está disponÃvel).
Infelizmente, o patch BD-Uninstallable não fornece
informações sobre qual pacote, exatamente, está faltando;
por favor, use edos-debcheck para descobrir. Entretanto, este problema
será resolvido por si mesmo uma vez que as dependências ausentes estejam
de fato disponÃveis e, neste momento, seu pacote automaticamente se
moverá para Needs-Build novamente.
</dd>
<dt><a name="wanna-build-state-failed">failed</a></dt>
<dd>Se uma tentativa de construção falhou, e o(a) mantenedor(a) do
autoconstrutor decidir que é mesmo uma falha cuja tentativa não deve ser
repetida, um pacote é marcado como <em>failed</em> (falhou). Um pacote
não sairá deste estado até que alguém do porte decida que isso ocorra ou
até que uma nova versão esteja disponÃvel. Contudo, quando uma nova
versão de um pacote está disponÃvel, o qual foi marcado como
<em>failed</em> em uma versão anterior, o autoconstrutor perguntará para
sua administração se o pacote deve ser tentado novamente ou não; isso
é feito para que os pacotes que obviamente falharão novamente não gastem
o tempo do buildd. Embora falhar um pacote antes de tentar uma
construção dificilmente seja a coisa certa a se fazer, a opção está
disponÃvel para a administração do autobuilder.<br />
Note que o pacote <strong>nunca</strong> será marcado como
<em>failed</em> sem intervenção humana
</dd>
<dt><a name="not-for-us">not-for-us</a></dt>
<dd>Certos pacotes são especÃficos a uma arquitetura; por
exemplo, o <tt>lilo</tt>, um boot loader do i386, não deve ser
reconstruÃdo em alpha, m68k ou s390. Contudo, o <em>wanna-build</em> não
olha para o arquivo de controle de um pacote quando cria seu banco
de dados; somente para o nome e a seção do pacote, o estado anterior
de construção e sua prioridade. Desse modo, quando ocorre o primeiro
upload de um pacote de arquitetura especÃfica que não deve ser
construÃdo em outras arquiteturas, uma tentativa de construção é
ainda assim realizada (mas falha mesmo antes que as dependências
de tempo de construção sejam baixadas e/ou instaladas).<br />
Já que os autoconstrutores não devem perder tempo tentando
construir pacotes que não são requisitados para sua arquitetura,
não existe necessidade de uma listagem de pacotes os quais uma
única tentativa de construção não é requerida. A primeira solução
para este problema foi o <em>not-for-us</em> (não-é-nosso); contudo,
como é difÃcil de manter, o <em>not-for-us</em> está atualmente
obsoleto; mantenedores(as) de autoconstrutores devem usar
<em>packages-arch-specific</em>, que é uma lista de pacotes especÃficos
para uma ou mais arquiteturas em vez de um estado wanna-build.<br />
Um pacote em <em>not-for-us</em> ou <em>packages-arch-specific</em>
<strong>não</strong> sairá deste estado automaticamente; se previamente
seu pacote excluiu uma dada arquitetura em seu arquivo de controle,
mas agora inclui mais arquiteturas, ele deve ser
<strong>manualmente</strong> recolocado na fila.<br />
Se alguma vez você se encontrar em uma posição em que tenha que pedir
para que isto aconteça, você deve fazê-lo perguntando ao(à )
mantenedor(a) do buildd relevante. Eles(as) podem ser encontrados(as)
em $arch@buildd.debian.org.
</dd>
<dt><a name="installed">installed</a></dt>
<dd>Como o nome sugere, um pacote marcado com <em>installed</em>
(instalado) está compilado para a arquitetura apontada pelo banco de dados
wanna-build. Antes do Woody ter sido lançado, um estado de pacote mudava
de <em>uploaded</em> para <em>installed</em> após a execução diária do
katie. Com a implementação do <a
href="https://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00002.html";>Accepted-autobuild</a>,
contudo, isto não é mais verdade; hoje em dia, um pacote vai
do estado <em>uploaded</em> para <em>installed</em> quando ele é
aceito no repositório. Isto significa que um pacote é geralmente
marcado como <em>installed</em> após 15 minutos, na
média.
</dd>
</dl>
<p>Além desses oito estados, o <em>wanna-build</em> também
conhece dois estados -removed (-removido), que realmente são casos
excepcionais. Eles são <em>dep-wait-removed</em> e
<em>failed-removed</em>. Eles se relacionam aos seus respectivos estados
<q>normais</q> dessa forma: quando um pacote no estado <em>failed</em> ou
<em>dep-wait</em> não aparece em um novo arquivo Packages, que é
alimentado para <em>wanna-build</em> – quando aparece, já foi
removido Рa informa̤̣o sobre aquele pacote ṇo ̩ jogada
fora como poderia ser feito, já que o pacote que não aparece no
arquivo Packages é somente uma pequena falha temporária, ou aquele
pacote foi temporariamente removido por alguma razão (mas vai reaparecer
no repositório depois de algum tempo). Em vez disso, em tal caso, um
pacote é movido para um estado <em>-removed</em> para que a
informação sobre o porquê ele falhou ou o que está aguardando possa
ser retida. Caso o pacote reapareça em um próximo arquivo Packages
que é alimentado no wanna-build, ele então será movido de volta de
<em>failed-removed</em> para <em>failed</em>, ou de volta de
<em>dep-wait-removed</em> para <em>dep-wait</em> antes de novos
processamentos.</p>
<p>
Não é possÃvel acessar o banco de dados wanna-build diretamente;
este banco de dados é instalado em ftp-master.debian.org, que é um
host restrito, e somente autoconstrutores tem uma chave SSH que
permite que eles acessem o banco de dados wanna-build para suas
arquiteturas. Isto tem sido a norma desde antes de ftp-master ter sido
restringido; como o wanna-build faz um bloqueio em nÃvel de banco de
dados quando acessado, mesmo na leitura de dados, você tem que estar
no grupo correto (wb-<arch>) para ser capaz de acessar diretamente
um banco de dados wanna-build.
</p>
<p>Dito isso, você pode ver qual estado um pacote está
na <a href="https://buildd.debian.org/stats/";>página de
estatÃsticas do buildd</a>, exceto se ele está no estado
<em>installed</em> (bem, é possÃvel, se você não liga de escavar
multimegabytes através de arquivos "<arch>-all.txt" ...).
</p>
<h2>Os resultados do log de construção</h2>
<p>
Quando um pacote é construÃdo por sbuild (o componente do buildd que
realmente faz a construção), um log com o resultado da construção é
enviado, por e-mail, para a administração do autoconstrutor e para
logs@buildd.debian.org (de modo que ele chegue até
https://buildd.debian.org). O resultado do log de construção pode ser
<em>successful</em> (bem sucedido), <em>attempted</em> (tentado - antes
conhecido por <em>failed</em>), <em>given-back</em> (retornado) ou
<em>skipped</em> (ignorado). Note que na <a
href="https://buildd.debian.org/";>página de sÃntese do log do
buildd</a>, o prefixo <em>maybe-</em> (talvez-) é adicionado, porque entre
outras coisas, o fato de que uma construção possa ser marcada com
<em>failed</em> para coisas que não são <em>realmente</em> uma
falha causou confusão no passado (ou, por outro lado,
algumas vezes um pacote que aparentemente construiu com sucesso está
realmente quebrado e precisa ser reconstruÃdo).</p>
<p>O significado dos resultados do log estão a seguir:</p>
<dl>
<dt><a name="successful">successful</a></dt>
<dd>A construção foi bem sucedida. Quando o(a) mantenedor(a) do
autoconstrutor recebe este log, extrairá o arquivo
<code>.changes</code> embutido, assinará e o enviará de volta para
o autoconstrutor, que fará o upload do pacote.</dd>
<dt><a name="failed">attempted</a> (antes: failed)</dt>
<dd>A construção terminou com um estado de saÃda não zero, indicando que
provavelmente falhou. Como pode haver um bom número de razões da falha
da construção, enumerá-las todas seria tedioso, então não vamos tentar
fazer isso aqui. Se um pacote seu está marcado com
<em>(maybe-)failed</em>, você vai querer ler o que escrevemos acima e
verificar o atual estado wanna-build.
</dd>
<dt><a name="given-back">given-back</a></dt>
<dd>A construção falhou devido a um problema temporário com o
autoconstrutor; exemplos incluem problemas de rede, a
indisponibilidade da fonte do pacote com o atual
sources.list, pouco espaço em disco, e outros.<br />
Um pacote que está com <em>given-back</em> é marcado com
<em><a href="#needs-build">needs-build</a></em> novamente; como
tal, ele será automaticamente escolhido por um autoconstrutor
diferente quando estiver pronto.
</dd>
<dt><a name="skipped">skipped</a></dt>
<dd>No perÃodo entre o pacote ter sido escolhido por um
autoconstrutor e marcado com <em><a
href="#building">building</a></em>, e a tentativa de construção,
uma nova versão para este pacote foi enviada, ou a equipe de porte
manualmente modificou o estado wanna-build por alguma outra razão.
Quando estiver pronto, um e-mail é enviado para o
autoconstrutor, que marcará o pacote para não ser construÃdo; o
sbuild verá e ignorará a construção (embora o log de construção
com este resultado seja enviado, descrevendo o fato que fez isso
acontecer).
</dd>
</dl>
<h2><a name="graphlink">A versão gráfica</a></h2>
<p>Para ilustrar o que foi escrito acima, nós também providenciamos uma <a
href="wanna-build.png">versão-fluxograma</a> deste procedimento. Novamente,
note que ele não contém tudo o que foi mencionado neste documento.
</p>
Reply to: