Nota: La página original es más nueva que esta traducción.

Estados de Wanna-build: una explicación

Esta página intenta explicar lo que significa cada estado de wanna-build y qué le pasará al paquete cuando esté en ese estado. El público al que va destinada son los responsables de los paquetes de Debian que intentan entender por qué su paquete ha sido o no compilado para una arquitectura específica. También se da una explicación de los distintos resultados del registro que se pueden obtener.

Finalmente, está disponible una versión del diagrama de flujo entre los estados de wanna-build, pero tenga en cuenta que no habla de todo lo que se menciona en este documento.

Estados de wanna-build

Para cada arquitectura a la que Debian da soporte, hay una base de datos de wanna-build instalada en buildd.debian.org, con todos los paquetes y su estado de compilación actual. Hay 8 estados: needs-build, building, uploaded, dep-wait, BD-Uninstallable, failed, not-for-us, e installed.

Sus significados son los siguientes:

needs-build

Un paquete marcado needs-build ha visto que su responsable ha enviado una nueva versión, pero para una arquitectura diferente de la arquitectura para la que es esta base de datos de wanna-build; así que necesita que se recompile. Si el estado es needs-build, no le ha escogido un autocompilador todavía, pero lo hará (una vez uno esté disponible en un momento en el que el paquete específico esté cerca del principio de la lista). La gente comúnmente dice que un paquete está en la cola para la recompilación cuando hablan sobre un paquete en estado needs-build.
Puede ser interesante darse cuenta de que la cola needs-build no es una cola FIFO; más bien, el orden usado se basa en los siguientes criterios:

Paquetes con estados previos de compilación: a los paquetes que se han compilado previamente se les da prioridad sobre los paquetes nuevos.
prioridades (los paquetes con prioridad required se compilan antes que los paquetes con prioridad extra)
La sección en que esté un paquete. Este orden está basado en qué paquetes se consideran más importantes; e.g., la sección games se compila más tarde que la sección base, y la sección libs se compila antes que devel.
en orden ASCIIbético en el nombre del paquete.

Adicionalmente, bajo ciertas condiciones, puede suceder que un buildd no tome paquetes del principio de la cola; por ejemplo, cuando un buildd no puede encontrar las fuentes de un paquete dado, lo pondrá de nuevo en la cola (donde ocupará de nuevo su posición anterior, esto es, la cabeza de la cola), pero ignorará el paquete durante unas pocas horas. Otro ejemplo donde puede suceder esto es cuando una arquitectura tiene autocompiladores múltiples; en ese caso, los adaptadores a arquitecturas pueden elegir compilar los paquetes más grandes en sus autocompiladores más rápidos, y dejar los más pequeños para las máquinas más lentas. Un buildd teóricamente también puede pedir explícitamente un orden de secciones diferente, pero no se hace normalmente.
Podría haber otras situaciones donde el orden de la cola parezca que se ignora; pero dese cuenta que todas son excepciones.

building

Un paquete se marca building desde el momento en que un autocompilador lo coja del principio de la cola de wanna-build hasta el momento en que el administrador del autocompilador contesta al registro. Como los paquetes no se cogen uno a uno, esto quiere decir que un paquete puede estar (y normalmente lo está) marcado como building antes de que la compilación haya comenzado en realidad; sin embargo, como buildd compila paquetes en su cola local según una cola FIFO, no debería tomar demasiado. También tenga en cuenta que el estado del paquete no se modifica una vez que se complete la compilación, sino cuando el administrador del autocompilador venga a responder al registro.

uploaded

Cuando un intento de compilación es satisfactorio, se envía un registro de la compilación al administrador y a buildd.debian.org. El responsable del autocompilador firma el archivo .changes que está incluido dentro del registro de compilación, y lo envía al autocompilador. Como consecuencia, el autocompilador envía el paquete y pone su estado como uploaded. Como tal, un paquete se puede encontrar en la cola de entrada (en cualquier sitio).
Un autocompilador no tocará más un paquete una vez que su estado sea uploaded, al menos no hasta el siguiente envío o hasta que algún responsable de adaptaciones a otras arquitecturas modifique manualmente el estado del paquete.

dep-wait

Cuando un paquete falla debido a que no se encuentran dependencias en el momento de la compilación, el responsable del autocompilador enviará un correo al autocompilador, dándole instrucciones para quitar las fuentes del paquete y marcarlo como dep-wait esperando las dependencias de compilación no encontradas. Un paquete es ese estado, automáticamente, sin intervención humana, se marcará como needs-build una vez dichas dependencias estén disponibles.
Originariamente, un paquete tenía que ver un intento de compilación antes de que el responsable lo pusiera manualmente en estado dep-wait. Sin embargo, en agosto de 2005 se añadió algún código a wanna-build que hará que un paquete se mueva del estado installed directamente al estado dep-wait, si eso es lo apropiado.
Hay dos casos específicos en los que puede suceder que un paquete se marque como dep-wait para siempre; estas son cuando sucede un error de mecanografía especificando las dependencias de dep-wait (de forma que un paquete se marca como que está esperando una dependencia de un paquete que no existe ni existirá) y cuando se declara una dependencia en tiempo de compilación en un paquete que está marcado como not-for-us, o que está en la lista packages-arch-specific.
Como último ejemplo, considere tres paquetes: un paquete foo, que existe sólo para i386; un paquete bar, que existe sólo para m68k (y que aproximadamente desarrolla la misma función); y un paquete baz, que se puede compilar con uno de ellos, foo o bar. El responsable del paquete baz olvida añadir bar a las dependencias de compilación, y lo añade cuando se le avisa de que baz está en dep-wait esperando un inexistente foo para m68k, entonces el estado dep-wait para m68k lo tendrán que cambiar manualmente los responsables de m68k.

BD-Uninstallable

Durante la debconf9, Joachim Breitner tuvo la idea de usar edos-debcheck para verificar si los paquetes eran instalables respecto a dependencias de construcción, pues de otra manera irían al estado Needs-Build. En ese punto, wanna-build ya tenía la capacidad de comprobar la disponibilidad inmediata de las dependencias de construcción; pero si el paquete «a» no podía instalarse porque dependía de otro «b» que dependía de otro «c» (>=1.2.3) y «c» aún está en versión 1.2.2, esto no sería detectado, y la construcción fallaría tempranamente por la no disponibilidad de dependencias de construcción. Averiguar esto era un proceso manual del administrador buildd, y usualmente, un proceso largo. Con el parche BD-Uninstallable, esto ya no era un problema. Cuando su paquete está en BD-Uninstallable, significa que una de las dependencias para construirlo no es instalable (ya sea inmediatamente, o porque parte de su árbol de dependencia no está disponible). Desafortunadamente, el parche BD-Uninstallable no proporciona información sobre qué paquete falta exactamente; por favor use edos-debcheck para averiguarlo. Este problema, no obstante, se resuelve por sí mismo una vez que las dependencias que faltan están ya disponibles, y en algún punto su paquete se moverá automáticamente otra vez a Needs-Build.

failed

Si un intento de compilación falló, el responsable del autocompilador decide si realmente es un fallo que no se debería reintentar, y el paquete se marca como failed. Un paquete no dejará este estado hasta que un responsable decida que debería hacerlo, o hasta que una nueva versión esté disponible. Sin embargo, cuando una nueva versión de un paquete que se marcó como failed en la versión anterior, el autocompilador preguntará a su administrador si se debe o no reintentar compilarlo; esto es así para que los paquetes que obviamente fallarán de nuevo no hagan perder el tiempo a buildd. Aunque descartar un paquete antes de intentar compilarlo apenas alguna vez es la manera correcta de hacerlo, la opción está disponible para el administrador del autocompilador.
Dese cuenta de que un paquetenunca se marcará como failed sin intervención humana.

not-for-us

Ciertos paquetes concretos son específicos de arquitecturas; por ejemplo, lilo, un gestor de arranque para i386, no se debería recompilar para alpha, m68k, o s390. Sin embargo, wanna-build no mira en el archivo de control de un paquete cuando crea su base de datos; solo el nombre del paquete y sección, el estado anterior de compilación, y su prioridad. De esta forma, al enviar por primera vez un paquete específico de una arquitectura que no se debería compilación para otras, no obstante se intenta (pero falla incluso antes de que se descarguen y/o instalen las dependencias del momento de la compilación)
Ya que los autocompiladores no deberían perder tiempo intentado compilar paquetes que no se necesitan para su arquitectura, se necesita una manera de listar los paquetes para los que no es necesario ni si quiera un intento de compilación. La primera solución a este problema fue not-for-us; sin embargo, como eso es difícil de mantener, not-for-us está desaprobado hoy en día; los responsables de los autocompiladores deberían usar en su lugar packages-arch-specific, que es una lista de paquetes específicos para una o más arquitecturas en lugar de un estado de wanna-build.
Un paquete en not-for-us o packages-arch-specific no dejará este estado automáticamente; si su paquete excluye específicamente una arquitectura dada previamente, pero ahora incluye más arquitecturas, se debería reintroducir en la cola manualmente.
Si se llega a encontrar en la posición de tener que preguntar qué sucede con esto, puede hacerlo preguntando al mantenedor de buildd pertinente. Se les puede localizar en $arch@buildd.debian.org.

installed

Como sugiere el nombre, un paquete marcado como installed está compilado para la arquitectura para la que es la base de datos de wanna-build. Antes de la publicación de Woody, el estado de un paquete cambiaba de uploaded a installed tras la ejecución diaria de katie. Con la implementación de Accepted-autobuild, sin embargo, esto ya no es así; ahora, un paquete pasa del estado uploaded a installed cuando se acepta en el repositorio. Esto significa que un paquete normalmente se marca como installed tras una media de 15 minutos.

Además de estos ocho estados, wanna-build también reconoce dos -estados eliminados, que en realidad son casos excepcionales. Estos dos estados son dep-wait-removed y failed-removed. Están relacionados con sus estados simples de la siguiente manera: cuando un paquete en estado failed o dep-wait no aparece en un nuevo archivo Packages que se le pasa a wanna-build – cuando parece que ha sido borrado – la información sobre ese paquete no se desecha, ya que podría ser que el paquete no apareciese por un error temporal, o que esté borrado temporalmente por alguna razón (pero que reaparecerá en el repositorio, pasado un tiempo). En vez de eso, en tal caso, un paquete se mueve al estado -removed, así la información sobre porqué falló o qué está esperando se puede retener. El paquete reaparecería en el siguiente archivo Packages que se le pasa a wanna-build, y se moverá de nuevo de failed-removed a failed, o de dep-wait-removed a dep-wait antes de seguir el proceso.

No es posible acceder a la base de datos de wanna-build directamente; esta base de datos está instalada en ftp-master.debian.org, que es un servidor restringido, y solo los autocompiladores tienen una llave ssh que les permite acceder a la base de datos de wanna-build de su arquitectura. Este ha sido el caso incluso antes de que ftp-master fuese restringido; como wanna-build hace un bloqueo a nivel de base de datos cuando accede, incluso solo para lectura, de los datos, tiene que estar en el grupo adecuado (wb-<arch>) para poder acceder directamente a la base de datos de wanna-build.

Dicho eso, puede ver en qué estado está un paquete yendo a la página de estadísticas de Debian, excepto si está en estado installed (bueno, no puede a menos que no le moleste escarbar en los archivos "<arch>-all.txt" de varios megabytes...).

Los resultados del registro de compilación

Cuando sbuild compila un paquete (el componente de buildd que hace la compilación en realidad), se envía un correo con el registro del resultado, al administrador del autocompilador y a logs@buildd.debian.org (así que puede terminar en https://buildd.debian.org). El registro que resulta de la compilación puede ser successful, attempted (antes conocido como failed), given-back, o skipped. Dese cuenta que, en la página que muestra el registro de buildd, el prefijo maybe- se añade, porque entre otras cosas, el hecho de que una compilación se pueda marcar failed ahí para cosas que realmente no son un fallo ha causado confusión en el pasado (o, de otra forma, a veces un paquete que aparentemente se compiló satisfactoriamente realmente está roto y hay que recompilarlo)..

El significado del registro de resultados es el siguiente:

successful: La compilación fue satisfactoria. Cuando el responsable del autocompilador recibe este registro, extraerá el archivo .changes incluido, lo firma, y lo envía de vuelta al autocompilador, lo que hará que se envíe el paquete.
attempted (antes, failed): La compilación terminó con un estado de salida distinto de cero, indicando que probablemente falló. Como puede haber un gran número de razones por las que falle, enumerarlos todos sería tedioso, así que no se intentará hacer aquí. Si un paquete suyo se marca (maybe-)failed, querrá leer lo de más arriba, y comprobar su estado en wanna-build.
given-back: La compilación falló debido a un problema temporal con el autocompilador; como ejemplos hay problemas de red, la no disponibilidad de los paquetes fuentes en el actual sources.list, poco espacio de disco, y otros.
Un paquete que es given-back se marca como needs-build de nuevo; como tal, será automáticamente escogido por un autocompilador diferente una vez esté preparado.
skipped: En el momento entre que el paquete es escogido por un autocompilador y se marca como building y el intento de compilación, se envía una nueva versión de este paquete, o un adaptador modifica manualmente el estado en wanna-build por otra razón. Cuando se hace eso, se envía un correo al autocompilador, que marcará el paquete como que no va a ser compilado; sbuild ve esto, y se saltará la compilación (aunque se envía un registro con ese resultado, describiendo el hecho que ocasionó esto).

La versión gráfica

Para ilustrar lo de más arriba, también hemos proporcionado una versión de diagrama de flujo de este procedimiento. De nuevo, tenga en cuenta que no contiene todo lo mencionado en este documento.