Estados wanna-build: uma explicação

Esta página tenta explicar o que significa cada estado wanna-build e o que acontecerá com um pacote quando ele estiver nesse estado. 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, é dada uma explicação dos diferentes resultados de log.

Se precisar de uma reconstrução do seu pacote, você pode solicitar ações wanna-build

Finalmente, uma versão em fluxograma dos estados wanna-build está disponível, mas note que ele não fala sobre tudo que é mencionado neste documento.

Os estados wanna-build

Para toda 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: needs-build, building, uploaded, dep-wait, BD-Uninstallable, failed, not-for-us e installed.

Seus significados:

needs-build

Um pacote marcado needs-build 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 é needs-build, ele ainda não foi pego por um 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 um pacote está na fila para reconstruir quando elas estão falando sobre um pacote no estado needs-build.
Pode ser interessante notar que a fila needs-build não é uma fila FIFO; ao contrário, a ordenação utilizada é baseada nos seguintes critérios:

Estados anteriores de compilação dos pacotes; os pacotes que foram previamente construídos recebem prioridade sobre novos pacotes.
prioridades (pacotes com prioridade required - requerido - são construídos antes que pacotes com prioridade extra)
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 games é construída depois da seção base, e a seção libs é construída antes de devel.
uma ordem "asciibética" pelo nome do pacote.

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 autobuilders; neste caso, as pessoas que portam a arquitetura podem escolher construir pacotes maiores em seus autobuilders 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.
Poderiam existir outras situações onde a ordem da fila parece ser ignorada; mas note que são sempre exceções.

building

Um pacote é marcado com building do momento em que um autobuilder o pega do topo da fila wanna-build até o momento em que a administração do autobuilder 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 building 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 não é modificado um vez que a construção foi completada; somente quando a administração do autobuilder aparece para responder aos logs.

uploaded

Quando uma tentativa de construção é bem sucedida, um log de construção é enviado para a administração do autobuilder e para buildd.debian.org. Então o(a) mantenedor(a) do autobuilder assina o arquivo .changes que está embutido no log de construção e o envia para o autobuilder. Como reação, o autobuilder fará o upload do pacote e definirá seu estado para uploaded. Como tal, um pacote neste estado pode ser encontrado na fila do repositório de entrada (incoming) (em algum lugar).
Um autobuilder não tocará mais em um pacote uma vez que seu estado é uploaded, 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.

dep-wait

Quando um pacote falha devido à ausência de dependências durante o tempo de construção (build-time), o(a) mantenedor(a) do autobuilder enviará um e-mail para o aautobuilder, instruindo-o a remover as fontes do pacote e a marcar o pacote como dep-wait 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.
Originalmente, um pacote tinha que passar por uma tentativa de construção antes que o(a) mantenedor(a) pudesse colocá-lo manualmente no estado dep-wait. 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 installed diretamente para o estado dep-wait se isso for apropriado.
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 dep-wait (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 not-for-us, que está na lista packages-arch-specific.
Como um exemplo deste último caso, considere três pacotes: um pacote foo, que existe para i386 somente; um pacote bar, que existe para m68k somente (e que realiza aproximadamente a mesma função); e um pacote baz, que pode ser construído com um deles, foo ou bar. Se o(a) mantenedor(a) do pacote baz esquecer de adicionar bar ao Build-Depends, e se ela ou ele adicioná-lo quando notificar-se que baz está em dep-wait para um pacote foo não existente para m68k, então o estado dep-wait para m68k terá que ser manualmente retirado pela equipe de porte do m68k.

BD-Uninstallable

Durante a DebConf9, o Joachim Breitner teve a ideia 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.

failed

Se uma tentativa de construção falhou, e o(a) mantenedor(a) do autobuilder decidir que é mesmo uma falha cuja tentativa não deve ser repetida, um pacote é marcado como failed. 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 failed em uma versão anterior, o autobuilder 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.
Note que o pacote nunca será marcado como failed sem intervenção humana

not-for-us

Certos pacotes são específicos a uma arquitetura; por exemplo, o lilo, um boot loader do i386, não deve ser reconstruído em alpha, m68k ou s390. Contudo, o wanna-build não olha para o arquivo control 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).
Já que os autobuilders 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 not-for-us; contudo, como é difícil de manter, o not-for-us está atualmente obsoleto; mantenedores(as) de autobuilders devem usar packages-arch-specific, que é uma lista de pacotes específicos para uma ou mais arquiteturas em vez de um estado wanna-build.
Um pacote em not-for-us ou packages-arch-specific não sairá deste estado automaticamente; se previamente seu pacote excluiu uma dada arquitetura em seu arquivo control, mas agora inclui mais arquiteturas, ele deve ser manualmente recolocado na fila.
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.

installed

Como o nome sugere, um pacote marcado com installed (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 uploaded para installed após a execução diária do katie. Com a implementação do Accepted-autobuild, contudo, isto não é mais verdade; hoje em dia, um pacote vai do estado uploaded para installed quando ele é aceito no repositório. Isto significa que um pacote é geralmente marcado como installed após 15 minutos, na média.

Além desses oito estados, o wanna-build também conhece dois estados -removed, que realmente são casos excepcionais. Esses dois estados são dep-wait-removed e failed-removed. Eles se relacionam aos seus respectivos estados normais dessa forma: quando um pacote no estado failed ou dep-wait não aparece em um novo arquivo Packages, que é alimentado para wanna-build – quando aparece, já foi removido – a informação sobre aquele pacote nã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 -removed 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 failed-removed para failed, ou de volta de dep-wait-removed para dep-wait antes de novos processamentos.

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 autobuilders 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.

Dito isso, você pode ver qual estado um pacote está na página de estatísticas do buildd, exceto se ele está no estado installed (bem, é possível, se você não liga de escavar multimegabytes através de arquivos "<arch>-all.txt" ...).

Os resultados do log de construção

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 autobuilder 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 successful, attempted (antes conhecido por failed), given-back ou skipped. Note que na página de síntese do log do buildd, o prefixo maybe- é adicionado, porque entre outras coisas, o fato de que uma construção possa ser marcada com failed para coisas que não são realmente 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).

O significado dos resultados do log estão a seguir:

successful: A construção foi bem sucedida. Quando o(a) mantenedor(a) do autobuilder recebe este log, ele(a) extrairá o arquivo .changes embutido, assinará e o enviará de volta para o autobuilder, que fará o upload do pacote.
attempted (antes: failed): 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 (maybe-)failed, você vai querer ler o que escrevemos acima e verificar o atual estado wanna-build.
given-back: A construção falhou devido a um problema temporário com o autobuilder; exemplos incluem problemas de rede, a indisponibilidade do fonte do pacote com o atual sources.list, pouco espaço em disco, e outros.
Um pacote que está com given-back é marcado com needs-build novamente; como tal, ele será automaticamente escolhido por um autobuilder diferente quando estiver pronto.
skipped: No período entre o pacote ter sido escolhido por um autobuilder e marcado com building, 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 autobuilder, 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).

A versão gráfica

Para ilustrar o que foi escrito acima, nós também providenciamos uma versão-fluxograma deste procedimento. Novamente, note que ele não contém tudo o que foi mencionado neste documento.