Состояния wanna-build: объяснение

На этой странице объясняется значение каждого состояния wanna-build и то, что произойдёт с пакетом, если он находится в этом состоянии. Целевой аудиторией настоящего документа являются сопровождающие пакетов Debian, которые пытаются понять, почему их пакет был или не был собран для какой-то конкретной архитектуры. Кроме того, в документе даётся объяснение различных результатов журнала сборки.

Если вам требуется повторно собрать ваш пакет, то вы можете использовать действия wanna-build

Также доступна диаграмма состояний wanna-build, но заметьте, что она не сообщает всего того, о чём говорится в этом документе.

Состояния wanna-build

Для каждой поддерживаемой в Debian архитектуры существует база данных wanna-build на buildd.debian.org, которая содержит все пакеты и их текущее состояние компиляции. Существует 8 состояний: needs-build, building, uploaded, dep-wait, BD-Uninstallable, failed, not-for-us и installed.

Значение этих состояний таково:

needs-build
Пакет, отмеченный как needs-build, имеет новую версию, загруженную сопровождающим этого пакета, но для другой архитектуры, чем та, базу данных которой вы просматриваете; по сути, этот пакет должен быть пересобран. Если пакет имеет состояние needs-build, он ещё не был выбран утилитой автоматической сборки, но будет выбран ей (как только эта утилита будет доступна, а этот пакет будет недалеко от верха списка). Обычно люди говорят: пакет поставлен в очередь на пересборку, когда они говорят о пакете, имеющем состояние needs-build.
Интересно будет отметить, что очередь needs-build не является FIFO очередью; скорее она упорядочивается на основе следующих критериев:
  1. Состояния предыдущей компиляции пакетов; пакеты, которые были собраны ранее, получают приоритет над новыми пакетами.
  2. Приоритета (пакеты с приоритетом необходимый имеют больший приоритет по сравнению с пакетами, имеющими приоритет дополнительный)
  3. Раздела, в котором находится пакет. Этот порядок основан на том, какие пакеты считаются более важными; например, пакеты из раздела games собираются после сборки пакетов из раздела base, а из раздела libs собираются перед devel.
  4. В соответствии с порядком букв в ASCII.
Кроме того, при определённых условиях, может случиться так, что buildd не будет брать пакеты из головы очереди; например, когда buildd не может найти исходный код данного проекта, он поместит его обратно в очередь (куда этот пакет помещается на предыдущую позицию, т. е. в голову списка), но этот пакет будет игнорироваться в течении нескольких часов. Другим примером того, когда это может произойти, является случай, когда какая-то архитектура имеет несколько машин автоматической сборки; в этом случае те, кто занимается переносом пакетов на эту архитектуру, могут решить собрать большие пакеты на быстрых машинах автоматической сборки и оставить небольшие пакеты для более медленных машин. Также утилита buildd теоретически может явным образом запрашивать другой порядок разделов, но это обычно не делается.
Могут быть и другие ситуации, когда порядок в очереди, как кажется, игнорируется; но заметьте, что все эти случаи являются исключениями.
building
Пакет отмечается как building с того момента, когда машина автоматической сборки выбирает его с верха очереди wanna-build, эта отметка сохраняется до тех пор, пока администратор машины автоматической сборки не ответит на высланный ему журнал сборки. Поскольку пакеты не выбираются один за другим, пакет может быть (и обычно является) обозначен как building до того момента, как сборка фактически начнётся; тем не менее, поскольку buildd собирает пакеты в своей локальной очереди на основе принципа FIFO, этот процесс больше не должен занимать долгое время. Кроме того, заметьте, что состояние пакета не изменяется сразу же после завершения сборки, а лишь после того, как администратор машины автоматической сборки сможет ответить на сообщение, содержащее журнал сборки.
uploaded
Если попытка сборки оказалась успешной, журнал сборки высылается администратору машины сборки и на buildd.debian.org. Сопровождающий машины автоматической сборки должен подписать файл .changes, который содержится в журнале сборки, и переслать его на машину автоматической сборки. В ответ машина автоматической сборки загрузит этот пакет и установит ему состояние uploaded. Как таковой, пакет в этом состоянии может быть найден во входящей очереди (где-то).
Машина автоматической сборки больше не будет трогать пакет после того, как его состояние станет uploaded, по меньшей мере, до следующей загрузки или до тех пор, пока тот, кто занимается переносом этого пакета, вручную не изменит его состояние.
dep-wait
Если пакет не может быть собран из-за того, что отсутствуют пакеты, необходимые для сборки, сопровождающий машины автоматической сборки вышлет письмо на машину автоматической сборки, сообщив ей команду удалить исходный код данного пакета и отметить его как dep-wait из-за отсутствия зависимостей для его сборки. Пакет в этом состоянии будет автоматически, без какого-либо вмешательства человека отмечен как needs-build, когда эти зависимости будут доступны.
Изначально должна была быть проведена попытка собрать пакет до того, как сопровождающий смог бы вручную поместить его в состояние dep-wait. Тем не менее, в августе 2005 года в wanna-build был добавлен код, который производит перемещение пакета из состояния installed напрямую в состояние dep-wait, если это возможно.
Существует два особых случая, когда может произойти так, что пакет оказывает отмеченным как dep-wait навсегда; в частности, когда сделана опечатка при указании зависимостей dep-wait (то есть, пакет обозначен как dep-wait от пакета, который не существует сейчас и вообще не будет существовать), и когда зависимости, требуемые для сборки, объявлены для пакета, который отмечен как not-for-us, либо который находится в списке packages-arch-specific.
В качестве примера последнего случая рассмотрим три пакета: пакет foo, которые существует только для архитектуры i386; пакет bar, который существует только для архитектуры m68k (и который приблизительно выполняет ту же функцию); и пакет baz, который может быть собран либо с foo, либо с bar. Если сопровождающий пакета baz забудет добавить bar в список Build-Depends, и если он или она добавит последний пакет, когда будет обозначено, что baz зависит (dep-wait) от несуществующего пакета foo для архитектуры m68k, то состояние dep-wait для архитектуры m68k должно быть вручную поднято теми, кто осуществляет перенос на m68k.
BD-Uninstallable
Во время конференции debconf9, Йоахим Брайтнер (Joachim Breitner) высказал идею о том, чтобы использовать edos-debcheck для проверки возможности установки зависимостей для сборки тех пакетов, которые в противном случае перешли бы в состояние Needs-Build. В тот момент в wanna-build уже присутствовала возможность проверки непосредственной доступности зависимостей для сборки; но если пакет не может быть установлен потому, что его сборка зависит от какого-то пакета a, который зависит от какого-то пакета b, который зависит от какого-то пакета c (>=1.2.3), а пакет c доступен только в версии 1.2.2, это не было бы определено, а сборка бы почти сразу же завершилась бы с ошибкой из-за того, что зависимости для сборки недоступны. Раньше обнаружение этой ситуации было делом администратора buildd и выполнялось вручную, как правило это было довольно длительным процессом. С заплатой BD-Uninstallable это более не является проблемой. Когда ваш пакет находится в состоянии BD-Uninstallable, это означает, что одна из его зависимостей для сборки не может быть установлена (непосредственно, либо из-за того, что часть её дерева зависимостей недоступна). К сожалению, заплата BD-Uninstallable не предоставляет информации о том, какой точно пакет отсутствует; пожалуйста, чтобы узнать это, используйте edos-debcheck. Тем не менее, эта проблема будет решена сама — когда отсутствующие зависимости станут доступны, тогда ваш пакет будет снова автоматически перемещён в Needs-Build.
failed
Если попытка сборки была неудачной, и сопровождающий машины автоматической сборки решил, что это действительно является проблемой, которая не должна быть повторена, пакет отмечается как failed. Пакет будет оставаться в этом состоянии, пока тот, кто занимается переносом пакета, не решит, что ему следует устранить проблему, либо пока не будет доступна новая версия пакета. Тем не менее, когда будет доступна новая версия пакета, предыдущая версия которого была отмечена как failed, машина автоматической сборки спросит своего администратора о том, следует ли повторить сборку; это сделано для того, чтобы пакеты, сборка которых очевидно завершится неудачно, не тратили время buildd. Хотя до того, как будет предпринята попытка сборки, вряд ли может считаться правильным решением, такая опция доступна администратору машины автоматической сборки.
Заметьте, пакет никогда не будет отмечен как failed без вмешательства человека.
not-for-us
Определённые пакеты являются специфичными для какой-то архитектуры; например, lilo, загрузчик для i386, не должен быть пересобран для alpha, m68k или s390. Тем не менее, wanna-build не проверяет управляющий файл пакета при создании своей базы данных, а лишь имя и раздел пакета, предыдущее состояние сборки и приоритет. Таким образом, при первой загрузке пакета, предназначенного для какой-то конкретной архитектуры, который не должен быть собран на других архитектурах, попытка сборки всё равно будет произведена (но она завершится неудачно даже до того как будут загружены и/или установлены зависимости, необходимые для сборки).
Поскольку машины автоматической сборки не должны тратить время на попытки сборки пакетов, которые не требуются для их архитектур, существует необходимость указывать пакеты, которые не нужно даже пытаться собирать. Первым решением этой проблемы было not-for-us; тем не менее, поскольку его сложно сопровождать, состояние not-for-us в настоящее время считается устаревшим; сопровождающим машин автоматической сборки следует использовать packages-arch-specific, последнее представляет собой скорее список пакетов, специфичных для одной или нескольких архитектур, а не состояние wanna-build.
Пакет находящийся в состоянии not-for-us, либо в packages-arch-specific не выйдет из этого состояния автоматически; если ранее ваш пакет явно исключал данную архитектуру в своём управляющем файле, а теперь включает больше архитектур, он должен быть заново помещён в очередь вручную.
Если окажется, что вам следует попросить об этом, вы можете попросить соответствующего сопровождающего buildd. Вы можете связаться с ними по адресу $arch@buildd.debian.org.
installed
Как предполагается этим именем, пакет, отмеченный как installed, скомпилирован для архитектуры данной базы данных wanna-build. До выпуска Woody состояние пакета изменялось с uploaded на installed после ежедневного запуска katie. Тем не менее, с реализацией Accepted-autobuild, это больше не так; теперь пакет переходит из состояния uploaded в installed, когда он будет принят в архив. Это означает, что пакет обычно отмечается как installed через, в среднем, 15 минут.

В дополнение к этим трём состояниям, wanna-build также известны два состояния -removed, которые являются крайними случаями. Это два следующих состояния: dep-wait-removed и failed-removed. Они связаны со своими соответствующими обычными состояниями следующим образом: когда пакет в состоянии failed или dep-wait не встречается в новом файле Packages, который передаётся wanna-build — если кажется, что он был удалён — информация об этом пакете не выбрасывается, как это произошло бы, если бы этот пакет, не встречающийся в файле Packages, был лишь временной ошибкой, или этот пакет был временно удалён по некоторой причине (но снова появится в архиве через некоторое время). Вместо этого в таком случае пакет переходит в состояние -removed, так что информация о том, почему его сборка была неудачной или какие пакеты ожидались данным пакетом, может быть сохранена. В случае, если этот пакет снова появится в следующем файле Packages, который передаётся wanna-build, он будет перемещён из состояния failed-removed обратно в состояние failed, либо из состояния dep-wait-removed обратно в состояние dep-wait до его дальнейшей обработки.

Невозможно получить прямой доступ к базе данных wanna-build; эта база данных установлена на ftp-master.debian.org, который является ограниченным узлом, лишь машины автоматической сборки имеют SSH-ключ, который позволяет им получать доступ к базе данных wanna-build их архитектуры. Так было ещё до того, как ftp-master был ограничен; поскольку wanna-build осуществляет блокировку базы данных, когда кто-то получает к ней доступ (даже для чтения), вы должны быть членом соответствующей группы (wb-<arch>), чтобы иметь возможность получить прямой доступ к базе данных wanna-build.

Однако, вы можете увидеть в каком состоянии находится тот или иной пакет, обратившись к странице статистики buildd, исключением являются пакеты, находящиеся в состоянии installed (ну, если вы, конечно, не хотите копаться в многомегабайтных файлах "<arch>-all.txt"...).

Журналы результатов сборки

Когда пакет собирается при помощи sbuild (компонент buildd, который осуществляет фактическую сборку), по почте администратору машины автоматической сборки, а также на logs@buildd.debian.org высылается журнал с результатом сборки (последнее нужно для того, чтобы журнал попал на https://buildd.debian.org). Результат журнала сборки может быть successful, attempted (ранее этот результат был известен как failed), given-back или skipped. Заметьте, что на обзорной странице журнала buildd, добавляется префикс maybe-, поскольку, помимо прочего, тот факт, что сборка может быть отмечена как failed, существование таких состояний, которые в действительности не являются неудачными, в прошлом вызывали путаницу (либо, наоборот, иногда пакет, который, по-видимому, был успешно собран, в действительности оказывается сломанным и требует своей пересборки).

Значение результатов журнала определяется следующим образом:

successful
Сборка была успешной. Когда сопровождающий машины автоматической сборки получает этот журнал, он вынимает прикреплённый файл .changes, подписывает его и отправляет обратно на машину автоматической сборки, что приводит к загрузке пакета.
attempted (ранее: failed)
Сборка завершилась с ненулевым кодом ответа, что означает, что сборка вероятнее всего была неудачной. Поскольку существует много причин, почему сборка может быть неудачной, перечисление всех возможных причин было бы утомительно, поэтому здесь мы их не приводим. Если ваш пакет отмечен как (maybe-)failed, вам следует прочитать первую часть настоящего документа и проверить текущее состояние wanna-build для вашего пакета.
given-back
Сборка была неудачна из-за временной проблемы с машиной автоматической сборки; например, это могут быть проблемы с сетью, недоступность источников пакетов с текущим файлом sources.list, недостаточное количество места на диске и др.
Пакет, имеющий состояние given-back отмечается как needs-build снова; как таковой, он будет автоматически выбран другой машиной автоматической сборки, как только она будет готова.
skipped
Между тем моментом, когда пакет был выбран машиной автоматической сборки и отмечен как building, и моментом самой попытки сборки, была загружена новая версия этого пакета, либо тот, кто осуществляет перенос, вручную изменил состояние wanna-build по какой-то другой причине. Когда такое происходит, на машину автоматической сборки высылается сообщение, которое отмечает этот пакет как пакет, который не нужно собирать; sbuild видит это и пропускает сборку (хотя и высылается журнал сборки с результатом, описывающим произошедший факт).

Графическая версия

Для иллюстрации приведённой выше информации, мы подготовили блок-схему процедуры сборки. Опять же, заметьте, что эта схема не содержит всего того, что указано в настоящем документе.