[devel] girar-builder

[devel] girar-builder

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 11586 bytes --]

Я подготовил предварительный вариант системы сборки из girar.
Пока продумана и реализована только часть идей из protva-2008.pdf
(тестовая пересборка пакетов не реализована).  С другой стороны,
уже на уровне текущей функциональности система может работать в основном
не хуже, а лучше, чем incoming.

ftp://ftp.altlinux.org/pub/people/at/protva-2008.pdf
http://git.altlinux.org/people/at/packages/girar.git
http://git.altlinux.org/people/at/packages/girar-builder.git

Я предлагаю уже в ближайшее время запустить girar-builder в тестовом
режиме, параллельно с incoming.  Это значит, что incoming будет, как
и раньше, принимать на сборку src.rpm пакеты, а girar-builder будет
принимать на сборку gear-репозитарии.  При таком раскладе потребуется
более аккуратно разграничивать конкурентный доступ между incoming и
girar-builder к общему репозитарию пакетов, но, в целом, это не должно
создать серьезных проблем.

К преимуществам girar-builder я отношу автоматические проверки,
направленные на поддержку целостности репозитария пакетов.

К недостаткам системы можно отнести следующее:

- Нет поддержки дополнительных архитектур; работа с двумя основными
  архитектурами (i586 и x86_64) реализована в hardcoded виде (с другой
  стороны, мы все-таки автоматически получаем жесткую синхронизацию
  пакетов между основными архитектурами).

- Слабое распараллеливание; серьезный подход к распараллеливанию
  пока не продуман.  С другой стороны, реально распараллеливание
  больше всего нужно для тестовой пересборки пакетов.  Еженедельная
  тестовая пересборка пакетов (beehive) пока будет работать как обычно.

- Слабая стратегия распределения ресурсов: система принципиально
  подвержена примитивным DoS атакам (пользователь-злоумышленник
  может легко блокировать сборку для всех остальных пользователей).

Далее следуют некоторые детали и пояснения.
Краткое резюме: будет работать команда

$ ssh git.alt build [-b <sisyphus-branch>] pkg1.git 1.0-alt1 [pkg2.git 2.0-alt2]...

* * *

Пользователь взаимодействует со сборочной системой в терминах заданий
(task).  Каждое задание имеет уникальный целочисленный идентификатор
(идентификаторы заданий инкрементно увеличиваются).  Каждое задание
ассоциировано с пользователем, который создал задание (владелец задания,
task owner).  Задание по умолчанию, или же "подразумеваемое" задание,
означает задание с наибольшим идентификатором среди заданий, созданных
данным пользователем (владельцем задания).

Задание должно включать в себя один или несколько gear-репозитариев,
которые нужно собрать.  Примитивы работы с заданиями следующие (они
будут доступны как 'ssh git.alt <команда>...'):

- task new [<binary-repo>]
  Создает задание и возвращает его идентификатор; <binary-repo> означает
  "sisyphus", "4.0" или "4.1"; по умолчанию "sisyphus" (и на первое время
  будет работать только "sisyphus").  Таким образом, задание изначально
  ассоциировано с репозитарием пакетов, для которого придётся собирать
  пакеты.

- task add [<id>] <gear-repo> <gear-tag>
  Добавляет gear-репозитарий в задание на сборку.  Если идентификатор
  задания <id> опущен, подразумевается текущее задание.  <gear-repo>
  означает gear-репозитарий в каталоге /people/$GIRAR_USER/packages/,
  например, perl.git (суффикс .git писать не обязательно, но нужно
  помнить, что речь идёт о соответствующем каталоге).

  Таг <gear-tag> должен быть подписан gpg ключом из alt-gpgkeys,
  поле 'tagger' должно содержать GIRAR_USER@altlinux (то есть значение
  тага должно соответствовать текущему пользователю, который работает
  с girar).  Другими словами, "чужие" таги на сборку не принимаются.

- task run [<id>]
  Когда задание укомплектовано, его надо запустить на сборку.

Задание может находится в одном из четырех состояний:
0) none -- на ранних стадиях формирования задания; это состояние
не представляет принципиального интереса;
1) scheduled for run -- задание готово к сборке;
2) running -- выполняется сборка задания;
3) ret -- сборка задания выполнена (либо успешно, либо с ошибками).

Состояние задания сейчас реализовано как инкрементная последовательность
sequence number с остатком по модулю 3 (для состояний 1-3).

Команда 'task run' должна переводить задание в состояние 1 -- scheduled
for run.  Это возможно, только если задание находится в состоянии 0 (none)
или 3 (ret).

Когда задание завершилось с ошибкой, можно добавить в него
дополнительные gear-репозитарии для сборки (которые предположительно
исправляют ошибки) и повторно запустить на сборку.

	Сейчас состояние 3 (ret) не интерпретируется: грубо говоря,
	пока нельзя узнать, завершилось ли задание успешно или с
	ошибкой (не считая отчета, который отправляется по почте).
	Это довольно неудобно, и это надо будет исправить в первую
	очередь, но это не настолько глупо, как может показаться с
	первого взгляда.

	Если повторно запустить задание, которое успешно завершилось,
	то оно завершится с ошибкой, потому что после первого успешного
	запуска собранные пакеты сразу поступают в репозитарий пакетов,
	а при повторном запуске сработает проверка на одинаковые версии
	пакетов.  Ничего страшного в этом нет.

Будет работать комбинированная команда

- build [-b <binary-repo>] <gear-repo-1> <gear-tag-1> [<gear-repo-2> <gear-tag-2>]...

Она эквивалентна последовательности команд
  id = task new [<binary-repo>]
  task add $id <gear-repo-1> <gear-tag-1>
 [task add $id <gear-repo-2> <gear-tag-2>]
  ...
  task run $id

- task rm [<id>]
  Задание можно удалить, если только оно не находится в состоянии
  running.

- task share [<id>]
  По умолчанию только владелец задания может комплектовать задание
  gear-репозитариями на сборку.  "Расшаривание" задания означает,
  что владелец задания разрешает другим пользователям добавлять
  в свое задание их gear-репозитарии.  Требование добавлять только
  свои таги всё ещё должно выполняться (расшаривание позволяет
  добавлять свои таги в чужие задания).

* * *

Выполнение задание сводится к последовательному выполнению "стадий"
в режиме "sh -e" (если очередная стадия завершается с ошибкой, то
последующие стадии не выполняются).  Последняя стадия -- копирование
собранных пакетов в репозитарий.

- gb-task-pkgtar
  Для каждого gear-репозитария в задании собирает pkg.tar (промежуточное
  между .gear и src.rpm представление исходного пакета).

["gb" означает "girar-builder".]

- gb-task-build
  Собирает rpm пакеты из pkg.tar.
  
  Сборка выполняется строго в той последовательности, в которой
  gear-репозитарии были добавлены в задание.  Если сборка очередного
  gear-репозитария завершается с ошибкой, то сборка всех последующих
  gear-репозитариев отменяется (и задание завершается с ошибкой).
  
  Сборка выполняется в режиме 'hsh --with-stuff', то есть ранее
  собранные в пределах задания пакеты доступны в hasher-репозитарии (и,
  как правило, они "перекрывают" соответствующие пакеты в Сизифе).

  При повторном запуске пересборка пакета будет выполняться, только если
  при повторной сборке меняется содержимое сборочного чрута.  (В
  противном случае, если пакет был ранее успешно собран, а содержимое
  сборочного чрута остается прежним, то повторная пересборка пакета не
  выполняется.)

  Сборка всех пакетов должна успешно завершиться на всех архитектурах
  (i586 и x86_64).  Специальная обработка ExclusiveArch пока не реализована.

- gb-task-check-build
  Проверка собранных rpm пакетов.
  Должны выполняться ряд ограничений для набора пакетов в целом:

  + При сборке gear-репозитария на разных архитектурах должен получиться
    один и тот же src.rpm пакет (обнаруживает атаки на "имя проекта").

  + Если при сборке gear-репозитария получились noarch.rpm пакеты, то
    набор noarch.rpm пакетов должен быть одинаковым для всех архитектур;
    и сами noarch.rpm пакеты, собранные на разных архитектурах, должны быть
    идентичны: список файлов и всех зависимостей у noarch.rpm пакетов
    при сборке на i586 и x86_64 должен совпадать.

  + В результате сборки должен получиться уникальный список src.rpm
    пакетов (с точностью до имени -- то есть внутри задания нельзя
    собирать один и тот же исходный пакет разных версий).

  + Аналогично, в результате сборки должен получиться уникальный список
    бинарных пакетов, с точностью до имени (при переименовании пакетов
    возможны необычные коллизии).

  + Должно существовать однозначное соответствие между собранными
    src.rpm пакетами и бинарными пакетами.  Точнее, лучше говорить
    о "кортеже" (src,bin+).  (Терминология однозначного соответствия,
    как и терминология кортежей, оказывается слишком неточной:
    соответствие src->bin не однозначное, а "значением" в кортеже
    является не элемент, а множество.)

- gb-task-repo-plan
  Нужно составить план обновления репозитария пакетов: исходя из того,
  что все собранные пакеты, как src.rpm, так и бинарные, должны попасть
  в репозитарий, нужно вычислить, каким образом новые пакеты замещают
  старые пакеты в репозитарии.  Замещение происходит как по имени
  исходного пакета, так и по имени бинарных пакетов, и дополняется
  по однозначному соответствию между исходными и бинарными пакетами.

- gb-task-repo-vercheck
  Нужно убедиться, что составленный план обновления репозитария
  корректен по части изменения версий пакетов: при обновлении пакетов
  версии должны увеличиваться ("обновление" означает совпадение по
  имени; увеличение версии проверяется как для исходных, так и для
  бинарных пакетов).  Кроме того, не допускается, чтобы имя файла
  rpm пакета оставалось прежним (такое возможно в случае, если добавился
  Serial, а Version-Release остались прежними).

- gb-task-repo-unmets
  Проверка на неудовлетворенные зависимости.
  
  Создается временный репозитарий, к которому применяется план
  обновления репозитария (то есть добавляются новые пакеты и удаляются
  старые пакеты).  Не должно возникнуть новых удовлетворенных
  зависимостей.  Понятие "новой" удовлетворенной зависимости трактуется
  строго (как в cybertalk unmets): если обновленный пакет сохраняет
  неудовлетворенную зависимость, то она считается "новой".  Короче,
  нельзя отправлять на сборку пакеты с анметами, даже если эти анметы
  ранее существовали.

- gb-task-check-acl
  Проверка на ACL (право заливать определенные пакеты) выполняется последней.
  С одной стороны, это связано с тем, что имена пакетов заранее неизвестны
  (проверка доступа идет по имени src.rpm пакета, а соответствия между
  gear-репозитариями и src.rpm пакетами изначально не предполагается).
  С другой стороны, должен быть механизм NMU, то есть контролируемого
  нарушения ACL, но только при условии, что все остальные проверки были
  выполнены успешно.  Увы, механизм разрешения NMU пока не реализован.

  Проверка ACL реализована корректно для случая переименования пакетов
  (с учетом того, что задание может быть "расшарено", нужно специально
  вычислять ответственность за переименование пакетов).

- gb-task-repo-commit
  Подписывает собранные пакеты и копирует их в репозитарий.
  Метаданные репозитария перегенерируются (genbasedir и т.д.).
  После этого собранные пакеты сразу же доступны для последующих заданий.

* * *

Пропускная способность такой системы -- несколько заданий в час,
при условии, что сама сборка пакетов не занимает слишком много.
То есть чистый оверхед выполнения задания, включая две перегенерации
репозитария (для repo-unmets и repo-commit) -- несколько минут.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] girar-builder

[Mikhail Gusarov]

Twas brillig at 02:40:45 10.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Это значит, что incoming будет, как и раньше, принимать на сборку
 AT> src.rpm пакеты, а girar-builder будет принимать на сборку
 AT> gear-репозитарии.

Кажется, в доках где-то было упоминание про то, что src.rpm-пакеты из
incoming можно укладывать в gear-архив и в таком виде и подавать на вход
сборщику. Это ещё не реализовано или просто слишком рискованно сразу
переключить incoming на girar-builder?

-- 

Re: [devel] girar-builder

[Michael Shigorin]

On Wed, Dec 10, 2008 at 02:40:45AM +0300, Alexey Tourbin wrote:
> С другой стороны, уже на уровне текущей функциональности
> система может работать в основном не хуже, а лучше, чем
> incoming.

Гм...

> Специальная обработка ExclusiveArch пока не реализована.

А много у нас такого эксклюзива?

> Увы, механизм разрешения NMU пока не реализован.

При живом incoming это несмертельно.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] girar-builder

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On Wed, Dec 10, 2008 at 02:40:45AM +0300, Alexey Tourbin wrote:
>   Таг <gear-tag> должен быть подписан gpg ключом из alt-gpgkeys,
>   поле 'tagger' должно содержать GIRAR_USER@altlinux (то есть значение
>   тага должно соответствовать текущему пользователю, который работает
>   с girar).  Другими словами, "чужие" таги на сборку не принимаются.

Так ли нужна проверка tagger? Я привык использовать другой e-mail для
git'а.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] girar-builder

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On Wed, Dec 10, 2008 at 12:08:50PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 02:40:45 10.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:
> 
>  AT> Это значит, что incoming будет, как и раньше, принимать на сборку
>  AT> src.rpm пакеты, а girar-builder будет принимать на сборку
>  AT> gear-репозитарии.
> 
> Кажется, в доках где-то было упоминание про то, что src.rpm-пакеты из
> incoming можно укладывать в gear-архив и в таком виде и подавать на вход
> сборщику. Это ещё не реализовано или просто слишком рискованно сразу
> переключить incoming на girar-builder?

Это реализовал legion@, и мне придётся скрестить 2 реализации,
поскольку Алексеи, похоже, испытывают взаимную неприязнь. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] girar-builder

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

On Wed, Dec 10, 2008 at 12:08:50PM +0600, Mikhail Gusarov wrote:
>  AT> Это значит, что incoming будет, как и раньше, принимать на сборку
>  AT> src.rpm пакеты, а girar-builder будет принимать на сборку
>  AT> gear-репозитарии.
> 
> Кажется, в доках где-то было упоминание про то, что src.rpm-пакеты из
> incoming можно укладывать в gear-архив и в таком виде и подавать на вход
> сборщику. Это ещё не реализовано или просто слишком рискованно сразу
> переключить incoming на girar-builder?

Так и будет сделано, но не сразу.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] girar-builder

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

On Wed, Dec 10, 2008 at 02:22:41PM +0300, Dmitry V. Levin wrote:
> On Wed, Dec 10, 2008 at 12:08:50PM +0600, Mikhail Gusarov wrote:
> > Twas brillig at 02:40:45 10.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:
> > 
> >  AT> Это значит, что incoming будет, как и раньше, принимать на сборку
> >  AT> src.rpm пакеты, а girar-builder будет принимать на сборку
> >  AT> gear-репозитарии.
> > 
> > Кажется, в доках где-то было упоминание про то, что src.rpm-пакеты из
> > incoming можно укладывать в gear-архив и в таком виде и подавать на вход
> > сборщику. Это ещё не реализовано или просто слишком рискованно сразу
> > переключить incoming на girar-builder?
> 
> Это реализовал legion@, и мне придётся скрестить 2 реализации,
> поскольку Алексеи, похоже, испытывают взаимную неприязнь. :)

Нет никакой неприязни.  Нельзя всё сразу протестировать и запустить.
Отдельные куски кода girar-builder я тестировал, но энная часть кода
просто написана "вслепую".  С ходу что-нибудь не заведётся.

Поэтому лучше увеличивать сложность системы (и возможности
неблагоприятных исходов, которые не были заранее продуманы)
поэтапано.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] girar-builder

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 183 bytes --]

On Wed, Dec 10, 2008 at 12:59:11PM +0200, Michael Shigorin wrote:
> > Специальная обработка ExclusiveArch пока не реализована.
> А много у нас такого эксклюзива?

Не знаю точно.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] girar-builder

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

On Wed, Dec 10, 2008 at 01:03:24PM +0200, Kirill A. Shutemov wrote:
> On Wed, Dec 10, 2008 at 02:40:45AM +0300, Alexey Tourbin wrote:
> >   Таг <gear-tag> должен быть подписан gpg ключом из alt-gpgkeys,
> >   поле 'tagger' должно содержать GIRAR_USER@altlinux (то есть значение
> >   тага должно соответствовать текущему пользователю, который работает
> >   с girar).  Другими словами, "чужие" таги на сборку не принимаются.
> 
> Так ли нужна проверка tagger? Я привык использовать другой e-mail для
> git'а.

Сейчас поле tagger используется как packager (запускается
'hsh --packager=$tagger', и это значение используется, если
Packager не указан в spec-файле).

Можно брать значение packager из gpg ключа, но в gpg ключах чаще
всего перечислено несколько адресов.

Я подумаю и напишу ещё раз.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] girar-builder

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 6799 bytes --]

On Wed, Dec 10, 2008 at 12:59:11PM +0200, Michael Shigorin wrote:
> On Wed, Dec 10, 2008 at 02:40:45AM +0300, Alexey Tourbin wrote:
> > Специальная обработка ExclusiveArch пока не реализована.
> 
> А много у нас такого эксклюзива?

$ rpm -qp --qf '%{NAME} %{EXCLUSIVEARCH}\n' * | grep -v '(none)$'
apmd i386
appliance-fake-cedega i386
appliance-fake-utm i386
appliance-fake-vzmc i386
atlas i386
cpuburn i386
dev86 i386
eclipse-cdt i386
eclipse-changelog i386
eclipse-photran i386
eclipse-rpm-editor i386
efibootmgr i386
etherboot i386
fglrx_glx i386
firmwarekit i386
fpc i386
gramps i586
grub i386
gstreamer-pitfdll i386
hex-a-hop i386
indilib x86_64
jai i386
java-1.4.2-blackdown i586
java-1.4.2-sun i586
java-1.5.0-sun i586
java-1.6.0-sun i586
jpeg-mmx i386
kernel-headers-common i386
kernel-image-led-tc i586
kernel-image-ovz-smp i586
kernel-image-std-def i586
kernel-image-std-ll i586
kernel-image-std-pae i586
kernel-image-std-srv i586
kernel-modules-alsa-led-tc i586
kernel-modules-atl2-ovz-smp i386
kernel-modules-drbd8-ovz-smp i386
kernel-modules-drbd8-std-def i386
kernel-modules-drbd8-std-ll i386
kernel-modules-drbd8-std-pae i386
kernel-modules-drbd8-std-srv i386
kernel-modules-dst-std-def i386
kernel-modules-dst-std-ll i386
kernel-modules-dst-std-pae i386
kernel-modules-dst-std-srv i386
kernel-modules-eeepc-std-def i386
kernel-modules-eeepc-std-ll i386
kernel-modules-eeepc-std-pae i386
kernel-modules-eeepc-std-srv i386
kernel-modules-fglrx-led-tc i586
kernel-modules-fglrx-ovz-smp i386
kernel-modules-fglrx-std-def i386
kernel-modules-fglrx-std-ll i386
kernel-modules-fglrx-std-pae i386
kernel-modules-fglrx-std-srv i386
kernel-modules-gfs-std-def i386
kernel-modules-gfs-std-ll i386
kernel-modules-gfs-std-pae i386
kernel-modules-gfs-std-srv i386
kernel-modules-gnbd-std-def i386
kernel-modules-gnbd-std-ll i386
kernel-modules-gnbd-std-pae i386
kernel-modules-gnbd-std-srv i386
kernel-modules-heci-std-def i386
kernel-modules-heci-std-ll i386
kernel-modules-heci-std-pae i386
kernel-modules-heci-std-srv i386
kernel-modules-igb-std-def i386
kernel-modules-igb-std-ll i386
kernel-modules-igb-std-pae i386
kernel-modules-igb-std-srv i386
kernel-modules-kqemu-ovz-smp i386
kernel-modules-kqemu-std-def i386
kernel-modules-kqemu-std-ll i386
kernel-modules-kqemu-std-pae i386
kernel-modules-kqemu-std-srv i386
kernel-modules-kvm-ovz-smp i386
kernel-modules-kvm-std-def i386
kernel-modules-kvm-std-ll i386
kernel-modules-kvm-std-pae i386
kernel-modules-kvm-std-srv i386
kernel-modules-lirc-ovz-smp i386
kernel-modules-lirc-std-def i386
kernel-modules-lirc-std-ll i386
kernel-modules-lirc-std-pae i386
kernel-modules-lirc-std-srv i386
kernel-modules-madwifi-ar5007-std-def i386
kernel-modules-madwifi-ar5007-std-ll i386
kernel-modules-madwifi-ar5007-std-pae i386
kernel-modules-madwifi-ar5007-std-srv i386
kernel-modules-madwifi-dfs-ovz-smp i386
kernel-modules-madwifi-dfs-std-def i386
kernel-modules-madwifi-dfs-std-ll i386
kernel-modules-madwifi-dfs-std-pae i386
kernel-modules-madwifi-dfs-std-srv i386
kernel-modules-madwifi-ovz-smp i386
kernel-modules-madwifi-std-def i386
kernel-modules-madwifi-std-ll i386
kernel-modules-madwifi-std-pae i386
kernel-modules-madwifi-std-srv i386
kernel-modules-ndiswrapper-ovz-smp i386
kernel-modules-ndiswrapper-std-def i386
kernel-modules-ndiswrapper-std-ll i386
kernel-modules-ndiswrapper-std-pae i386
kernel-modules-ndiswrapper-std-srv i386
kernel-modules-nvidia-led-tc i386
kernel-modules-nvidia-ovz-smp i386
kernel-modules-nvidia-std-def i386
kernel-modules-nvidia-std-ll i386
kernel-modules-nvidia-std-pae i386
kernel-modules-nvidia-std-srv i386
kernel-modules-omnibook-std-def i386
kernel-modules-omnibook-std-ll i386
kernel-modules-omnibook-std-pae i386
kernel-modules-omnibook-std-srv i386
kernel-modules-rt2860-std-def i386
kernel-modules-rt2860-std-ll i386
kernel-modules-rt2860-std-pae i386
kernel-modules-rt2860-std-srv i386
kernel-modules-rtl8187se-ovz-smp i386
kernel-modules-rtl8187se-std-def i386
kernel-modules-svgalib_helper-ovz-smp i386
kernel-modules-svgalib_helper-std-def i386
kernel-modules-svgalib_helper-std-ll i386
kernel-modules-svgalib_helper-std-pae i386
kernel-modules-svgalib_helper-std-srv i386
kernel-modules-thinkpad-std-pae i386
kernel-modules-tp_smapi-ovz-smp i386
kernel-modules-tp_smapi-std-def i386
kernel-modules-tp_smapi-std-ll i386
kernel-modules-tp_smapi-std-pae i386
kernel-modules-tp_smapi-std-srv i386
kernel-modules-virtualbox-addition-std-def i386
kernel-modules-virtualbox-addition-std-ll i386
kernel-modules-virtualbox-addition-std-pae i386
kernel-modules-virtualbox-addition-std-srv i386
kernel-modules-virtualbox-std-def i386
kernel-modules-virtualbox-std-ll i386
kernel-modules-virtualbox-std-pae i386
kernel-modules-virtualbox-std-srv i386
kernel-modules-virtualbox-vfs-std-def i386
kernel-modules-virtualbox-vfs-std-ll i386
kernel-modules-virtualbox-vfs-std-pae i386
kernel-modules-virtualbox-vfs-std-srv i386
kpowersave i386
kvm i386
libaio i386
libsmbios i386
libvirt i386
lilo i386
lphdisk i386
lrmi i386
lsb i386
ltsp i386
ltsp-client-full i386
matroxdriver_glx i386
mbrola i386
mcelog x86_64
memtest86+ i386
memtest86 i386
module-init-tools i386
mozilla-plugin-adobe-flash i386
mpg123 i386
nvidia_glx_src_169.12 i386
nvidia_glx_src_173.14.05 i386
nvidia_glx_src_173.14.09 i386
nvidia_glx_src_173.14.12 i386
nvidia_glx_src_173.14.15 i386
nvidia_glx_src_177.80 i386
nvidia_glx_src_177.82 i386
nvidia_glx_src_71.86.04 i386
nvidia_glx_src_71.86.06 i386
nvidia_glx_src_71.86.07 i386
nvidia_glx_src_96.43.05 i386
nvidia_glx_src_96.43.07 i386
nvidia_glx_src_96.43.09 i386
nvidia_glx_x8664_1.0.7182 x86_64
nvidia_glx_x8664_1.0.8178 x86_64
nvidia_glx_x8664_1.0.8756 x86_64
nvidia_glx_x8664_1.0.8762 x86_64
nvidia_glx_x8664_1.0.8774 x86_64
nvidia_glx_x8664_1.0.8776 x86_64
nvidia_glx_x8664_1.0.9629 x86_64
nvidia_glx_x8664_1.0.9746 x86_64
phun i386
powersave i386
prelink i386
preload i386
rovclock i386
ruby-doc-extra i386
sp-sc i586
squeak-vm-sugar i386
sugar-etoys-activity i386
svgalib i386
tcc i386
tpctl i386
trafshow-linux i386
tuxvsclippy i386
vaio-tools i386
virtualbox i386
voiceman-config-mbrola-ru_tts i386
wine i386
wine-vanilla i386
x86info i386
xorg-drv-apm i386
xorg-drv-ark i386
xorg-drv-ast i386
xorg-drv-chips i386
xorg-drv-geode i386
xorg-drv-i128 i386
xorg-drv-i740 i386
xorg-drv-neomagic i386
xorg-drv-rendition i386
xorg-drv-siliconmotion i386
xorg-drv-tseng i386
xorg-x11-drv-matrox i386
-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] girar-builder

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]

On Wed, Dec 10, 2008 at 02:36:36PM +0200, Kirill A. Shutemov wrote:
> On Wed, Dec 10, 2008 at 12:59:11PM +0200, Michael Shigorin wrote:
> > On Wed, Dec 10, 2008 at 02:40:45AM +0300, Alexey Tourbin wrote:
> > > Специальная обработка ExclusiveArch пока не реализована.
> > 
> > А много у нас такого эксклюзива?
> 
> $ rpm -qp --qf '%{NAME} %{EXCLUSIVEARCH}\n' * | grep -v '(none)$'
> apmd i386
> appliance-fake-cedega i386
> appliance-fake-utm i386
> appliance-fake-vzmc i386
> atlas i386

В atlas написано 'ExclusiveArch: %ix86 amd64 x86_64', то есть этот пакет
собирается на двух основных архитектурах, что также дает возможность
проверить идентичность noarch подпакетов.  Фактически atlas не относится
к ExclusiveArch (в рамках нашей задачи, как она сейчас стоит).

Запрос надо было написать так:

$ rpm -qp --qf '[%{=NAME}\t%{EXCLUSIVEARCH}\n]' /ALT/Sisyphus/files/SRPMS/atlas-3.7.11-alt6.src.rpm
atlas   i386
atlas   i486
atlas   i586
atlas   i686
atlas   i786
atlas   i886
atlas   i986
atlas   pentium2
atlas   pentium3
atlas   pentium4
atlas   k6
atlas   athlon
atlas   athlon_xp
atlas   amd64
atlas   x86_64
$

И, соответственно, отбирать по более хитрому условию.
Сначала соединить i586 и x86_64 по второй колонке (и получить список
пакетов, которые собираются на двух основных архитектурах), затем
вычесть по первой колонке (то есть из общего списка пакетов вычесть
список пакетов, которые поддерживают основные архитектуры).

И есть другие таги, напр. BuildArch (если значение BuildArch не равно
noarch).  Я с ходу точно не знаю, как учесть все эти разные возможности.

Короче, для тестового запуска я считаю проблему ExclusiveArch
не принципиально важной.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] girar-builder

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

Alexey Tourbin пишет:
> Я подготовил предварительный вариант системы сборки из girar.
...
> 
> Я предлагаю уже в ближайшее время запустить girar-builder в тестовом
> режиме, параллельно с incoming.  Это значит, что incoming будет, как
> и раньше, принимать на сборку src.rpm пакеты, а girar-builder будет
> принимать на сборку gear-репозитарии.

   Оно уже работает?

PS: Отправил вчера на сборку rpm-macros-apache2-2.1-alt1 (task 
1228943261), но похоже что в Сизиф пакет ещё не попал...

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] girar-builder

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

On Wed, Dec 10, 2008 at 02:40:45AM +0300, Alexey Tourbin wrote:
> Я подготовил предварительный вариант системы сборки из girar.
А оно уже работает на git.alt?

$ ssh git.alt task new
cat: .max-task-id: Permission denied
$ ssh git.alt build ruby-rcairo.git 1.8.0-alt2
cat: .max-task-id: Permission denied

help похоже не успевает за паравозом:
$ ssh git.alt help |grep task
task {list|new|show|drop|add|run} ...
$ ssh git.alt task           
girar-task: Not enough arguments.
usage: girar-task {new|add|ls|show|run|share|rm} ...

Эх.. Придёться заливать по-старинке.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] girar-builder

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

On Fri, Dec 12, 2008 at 11:57:09PM +0200, Kirill A. Shutemov wrote:
> On Wed, Dec 10, 2008 at 02:40:45AM +0300, Alexey Tourbin wrote:
> > Я подготовил предварительный вариант системы сборки из girar.
> А оно уже работает на git.alt?
> 
> $ ssh git.alt task new
> cat: .max-task-id: Permission denied

Нет, я его заблокировал, чтобы не мешали тестировать. ;)

Когда станет доступно, я напишу.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]