[devel] git.alt build architecture

[devel] git.alt build architecture

[Kirill A. Shutemov]

Насколько я понимаю, архитектура сборки с использованием git.alt уже более-менее
устоялась. К сожалению, никакой документации описывающую эту архитектуру я не
нашёл. Может ли кто-либо из разработчиков, сделать обзор архитектуры сборочницы.
В частности, интересует какие компоненты вовлечены в процесс и как они
взаимодействуют между собой.

Спасибо.

Re: [devel] git.alt build architecture

[Alexey Tourbin]

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

On Mon, May 18, 2009 at 03:11:59AM +0300, Kirill A. Shutemov wrote:
> Насколько я понимаю, архитектура сборки с использованием git.alt уже более-менее
> устоялась. К сожалению, никакой документации описывающую эту архитектуру я не
> нашёл. Может ли кто-либо из разработчиков, сделать обзор архитектуры сборочницы.
> В частности, интересует какие компоненты вовлечены в процесс и как они
> взаимодействуют между собой.

Есть два главных компонента системы: girar и girar-builder.
girar это то что обслуживает ssh доступ к git.altlinux.org.
girar формирует задания для сборки.  Далее эти задания
забирает на сборку girar-builder.

Задание -- это каталог со специальной структурой (ближайшая аналогия --
каталог /proc/$pid).  Структура каталога описана в файле
girar-builder/TASK.  Описание может быть неполным или неточным,
но оно дает правильное первоначальное представление.

Процедура сборки задания находится girar-builder/gb-run-task.
Задание состоит из нескольких стадий, которые выполняются в режиме
'sh -e' (то есть, когда одна из стадий завершается с ошибкой, остальные
стадии не выполняются).  Последние стадии задания -- это копирование
собранных пакетов в репозитарий и перегенерация репозитария.

У girar-builder нету своего хешера.  Хешер существует на ноде, которая
называется $remote_host.  В каталоге girar-builder/remote/ лежат
программы, которые выполняются на $remote_host.  В частности, для сборки
пакетов на ноде выполняется программа girar-builder/remote/gb-remote-build.

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

Re: [devel] git.alt build architecture

[Kirill A. Shutemov]

2009/5/18 Alexey Tourbin <at@altlinux.ru>:
> On Mon, May 18, 2009 at 03:11:59AM +0300, Kirill A. Shutemov wrote:
>> Насколько я понимаю, архитектура сборки с использованием git.alt уже более-менее
>> устоялась. К сожалению, никакой документации описывающую эту архитектуру я не
>> нашёл. Может ли кто-либо из разработчиков, сделать обзор архитектуры сборочницы.
>> В частности, интересует какие компоненты вовлечены в процесс и как они
>> взаимодействуют между собой.
>
> Есть два главных компонента системы: girar и girar-builder.
> girar это то что обслуживает ssh доступ к git.altlinux.org.
> girar формирует задания для сборки.  Далее эти задания
> забирает на сборку girar-builder.
>
> Задание -- это каталог со специальной структурой (ближайшая аналогия --
> каталог /proc/$pid).  Структура каталога описана в файле
> girar-builder/TASK.  Описание может быть неполным или неточным,
> но оно дает правильное первоначальное представление.
>
> Процедура сборки задания находится girar-builder/gb-run-task.
> Задание состоит из нескольких стадий, которые выполняются в режиме
> 'sh -e' (то есть, когда одна из стадий завершается с ошибкой, остальные
> стадии не выполняются).  Последние стадии задания -- это копирование
> собранных пакетов в репозитарий и перегенерация репозитария.

Я так понимаю, что сборка на разных архитектурах сейчас сильно связана
по времени. Т.е. имея одну медленную архитектуру(ARM, например), мы
будем тормозить сборку в целом. Даже отключение отдельных ресурсоёмких
проверок на медленной архитектуре не поможет, если время сборки rpm-ок
будет существенно отличаться.

Возможно ли с этим что-нибудь сделать? Т.е возможно ли сделать
распараллеливание по архитектурам на болле высоком уровне, чем это
происходит сейчас, что бы сделать архитектуры менее синхронными.

Re: [devel] git.alt build architecture

[Alexey Tourbin]

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

On Mon, May 18, 2009 at 11:37:37AM +0300, Kirill A. Shutemov wrote:
> 2009/5/18 Alexey Tourbin <at@altlinux.ru>:
> > On Mon, May 18, 2009 at 03:11:59AM +0300, Kirill A. Shutemov wrote:
> >> Насколько я понимаю, архитектура сборки с использованием git.alt уже более-менее
> >> устоялась. К сожалению, никакой документации описывающую эту архитектуру я не
> >> нашёл. Может ли кто-либо из разработчиков, сделать обзор архитектуры сборочницы.
> >> В частности, интересует какие компоненты вовлечены в процесс и как они
> >> взаимодействуют между собой.
> >
> > Есть два главных компонента системы: girar и girar-builder.
> > girar это то что обслуживает ssh доступ к git.altlinux.org.
> > girar формирует задания для сборки.  Далее эти задания
> > забирает на сборку girar-builder.
> >
> > Задание -- это каталог со специальной структурой (ближайшая аналогия --
> > каталог /proc/$pid).  Структура каталога описана в файле
> > girar-builder/TASK.  Описание может быть неполным или неточным,
> > но оно дает правильное первоначальное представление.
> >
> > Процедура сборки задания находится girar-builder/gb-run-task.
> > Задание состоит из нескольких стадий, которые выполняются в режиме
> > 'sh -e' (то есть, когда одна из стадий завершается с ошибкой, остальные
> > стадии не выполняются).  Последние стадии задания -- это копирование
> > собранных пакетов в репозитарий и перегенерация репозитария.
> 
> Я так понимаю, что сборка на разных архитектурах сейчас сильно связана
> по времени. Т.е. имея одну медленную архитектуру(ARM, например), мы
> будем тормозить сборку в целом. Даже отключение отдельных ресурсоёмких
> проверок на медленной архитектуре не поможет, если время сборки rpm-ок
> будет существенно отличаться.

Да.  Самым ресурсоемким следует считать сборку пакетов, а girar-builder
дает почти что константный оверхед (в районе пяти минут на задание).
Сейчас неконстантно много ресурсов жрёт проверка с --whatprovides,
но она будет переделана.

> Возможно ли с этим что-нибудь сделать? Т.е возможно ли сделать
> распараллеливание по архитектурам на болле высоком уровне, чем это
> происходит сейчас, что бы сделать архитектуры менее синхронными.

Я не вижу такой возможности.  Мы реализуем жесткую синхронизацию
архитектур, и в некоторых случаях она объективно необходима (например,
для пакетов с noarch подпакетами).  Одной из первых стадий задания
является сборка пакетов на всех архитектурах.  Значит, пока все пакеты
не соберутся, ничего предпринимать нельзя.

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

Re: [devel] git.alt build architecture

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [090518 13:12]:
> Я не вижу такой возможности.  Мы реализуем жесткую синхронизацию
> архитектур, и в некоторых случаях она объективно необходима (например,
> для пакетов с noarch подпакетами).  Одной из первых стадий задания
> является сборка пакетов на всех архитектурах.  Значит, пока все пакеты
> не соберутся, ничего предпринимать нельзя.
Может тогда можно на армоферме использовать NPROCS > 1 и
какой-ньдь distcc?

P.S. qemu-arm совсем умерло?

-- 
Regards,
Sir Raorn.

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

Re: [devel] git.alt build architecture

[Kirill A. Shutemov]

2009/5/18 Alexey I. Froloff <raorn@altlinux.org>:
> * Alexey Tourbin <at@> [090518 13:12]:
>> Я не вижу такой возможности.  Мы реализуем жесткую синхронизацию
>> архитектур, и в некоторых случаях она объективно необходима (например,
>> для пакетов с noarch подпакетами).  Одной из первых стадий задания
>> является сборка пакетов на всех архитектурах.  Значит, пока все пакеты
>> не соберутся, ничего предпринимать нельзя.
> Может тогда можно на армоферме использовать NPROCS > 1 и
> какой-ньдь distcc?

distcc, может нарушить воспроизводимость сборки. Да и возможности
распараллеливания ограничены.

>
> P.S. qemu-arm совсем умерло?

Нет. Я изучаю возможность сборки на реальном железе. Даже если удастся
наладить сборку на железе, qemu никуда не денется -- это хороший инструмент
для мэйнтэйнера, позволяющий разбираться в сборке пакета при отсутствии
железа.

Re: [devel] git.alt build architecture

[Kirill A. Shutemov]

2009/5/18 Alexey Tourbin <at@altlinux.ru>:
> On Mon, May 18, 2009 at 11:37:37AM +0300, Kirill A. Shutemov wrote:
>> 2009/5/18 Alexey Tourbin <at@altlinux.ru>:
>> > On Mon, May 18, 2009 at 03:11:59AM +0300, Kirill A. Shutemov wrote:
>> >> Насколько я понимаю, архитектура сборки с использованием git.alt уже более-менее
>> >> устоялась. К сожалению, никакой документации описывающую эту архитектуру я не
>> >> нашёл. Может ли кто-либо из разработчиков, сделать обзор архитектуры сборочницы.
>> >> В частности, интересует какие компоненты вовлечены в процесс и как они
>> >> взаимодействуют между собой.
>> >
>> > Есть два главных компонента системы: girar и girar-builder.
>> > girar это то что обслуживает ssh доступ к git.altlinux.org.
>> > girar формирует задания для сборки.  Далее эти задания
>> > забирает на сборку girar-builder.
>> >
>> > Задание -- это каталог со специальной структурой (ближайшая аналогия --
>> > каталог /proc/$pid).  Структура каталога описана в файле
>> > girar-builder/TASK.  Описание может быть неполным или неточным,
>> > но оно дает правильное первоначальное представление.
>> >
>> > Процедура сборки задания находится girar-builder/gb-run-task.
>> > Задание состоит из нескольких стадий, которые выполняются в режиме
>> > 'sh -e' (то есть, когда одна из стадий завершается с ошибкой, остальные
>> > стадии не выполняются).  Последние стадии задания -- это копирование
>> > собранных пакетов в репозитарий и перегенерация репозитария.
>>
>> Я так понимаю, что сборка на разных архитектурах сейчас сильно связана
>> по времени. Т.е. имея одну медленную архитектуру(ARM, например), мы
>> будем тормозить сборку в целом. Даже отключение отдельных ресурсоёмких
>> проверок на медленной архитектуре не поможет, если время сборки rpm-ок
>> будет существенно отличаться.
>
> Да.  Самым ресурсоемким следует считать сборку пакетов, а girar-builder
> дает почти что константный оверхед (в районе пяти минут на задание).
> Сейчас неконстантно много ресурсов жрёт проверка с --whatprovides,
> но она будет переделана.
>
>> Возможно ли с этим что-нибудь сделать? Т.е возможно ли сделать
>> распараллеливание по архитектурам на болле высоком уровне, чем это
>> происходит сейчас, что бы сделать архитектуры менее синхронными.
>
> Я не вижу такой возможности.  Мы реализуем жесткую синхронизацию
> архитектур, и в некоторых случаях она объективно необходима (например,
> для пакетов с noarch подпакетами).  Одной из первых стадий задания
> является сборка пакетов на всех архитектурах.  Значит, пока все пакеты
> не соберутся, ничего предпринимать нельзя.

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

Re: [devel] git.alt build architecture

[Victor B. Wagner]

On 2009.05.18 at 13:11:23 +0400, Alexey Tourbin wrote:

> > Я так понимаю, что сборка на разных архитектурах сейчас сильно связана
> > по времени. Т.е. имея одну медленную архитектуру(ARM, например), мы
> > будем тормозить сборку в целом. Даже отключение отдельных ресурсоёмких
> > проверок на медленной архитектуре не поможет, если время сборки rpm-ок
> > будет существенно отличаться.
> 
> Да.  Самым ресурсоемким следует считать сборку пакетов, а girar-builder

А зачем вообще на ARM что-либо собирать? По-моему, такие архитектуры
должны обслуживаться исключительно кросс-компиляцией. Возможно в
сочетании с эмулятором, как делает Nokia в среде разработки для maemo.
(что они сделали исключительно из-за того, что несознательные
upstream-разработчики пишут такие configure.in, которые не поддерживают
--target)

Re: [devel] git.alt build architecture

[Mikhail Gusarov]

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


Twas brillig at 16:36:34 18.05.2009 UTC+04 when vitus@altlinux.org did gyre and gimble:

 VBW> А зачем вообще на ARM что-либо собирать? По-моему, такие
 VBW> архитектуры должны обслуживаться исключительно кросс-компиляцией.
 VBW> Возможно в сочетании с эмулятором, как делает Nokia в среде
 VBW> разработки для maemo.  (что они сделали исключительно из-за того,
 VBW> что несознательные upstream-разработчики пишут такие configure.in,
 VBW> которые не поддерживают --target)

--host

-- 

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

Re: [devel] git.alt build architecture

[Kirill A. Shutemov]

2009/5/18 Victor B. Wagner <vitus@altlinux.org>:
> On 2009.05.18 at 13:11:23 +0400, Alexey Tourbin wrote:
>
>> > Я так понимаю, что сборка на разных архитектурах сейчас сильно связана
>> > по времени. Т.е. имея одну медленную архитектуру(ARM, например), мы
>> > будем тормозить сборку в целом. Даже отключение отдельных ресурсоёмких
>> > проверок на медленной архитектуре не поможет, если время сборки rpm-ок
>> > будет существенно отличаться.
>>
>> Да.  Самым ресурсоемким следует считать сборку пакетов, а girar-builder
>
> А зачем вообще на ARM что-либо собирать? По-моему, такие архитектуры
> должны обслуживаться исключительно кросс-компиляцией. Возможно в
> сочетании с эмулятором, как делает Nokia в среде разработки для maemo.
> (что они сделали исключительно из-за того, что несознательные
> upstream-разработчики пишут такие configure.in, которые не поддерживают
> --target)

С кросс-компиляторами пока в Сизифе плохо. Может быть в будущем что-то
измениться.

До сих пор я портировал Сизиф на ARM с использованием только qemu. Т.е.
собирал в qemu нативным компилятором. Медленно, но с большего работает.
Вот сейчас пробую реальное железо. Посмотрим.

Re: [devel] git.alt build architecture

[Alexey I. Froloff]

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

* Victor B. Wagner <vitus@> [090518 16:37]:
> (что они сделали исключительно из-за того, что несознательные
> upstream-разработчики пишут такие configure.in, которые не поддерживают
> --target)
Кроме configure.in существует такое количество сборочных систем,
что про это даже смешно говорить.  Я уже молчу про AC_TRY_RUN, с
которыми надо разбираться отдельно в каждом случае.

-- 
Regards,
Sir Raorn.

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

Re: [devel] git.alt build architecture

[Victor B. Wagner]

On 2009.05.18 at 17:21:19 +0400, Alexey I. Froloff wrote:

> * Victor B. Wagner <vitus@> [090518 16:37]:
> > (что они сделали исключительно из-за того, что несознательные
> > upstream-разработчики пишут такие configure.in, которые не поддерживают
> > --target)
> Кроме configure.in существует такое количество сборочных систем,
> что про это даже смешно говорить.  Я уже молчу про AC_TRY_RUN, с
> которыми надо разбираться отдельно в каждом случае.

Проблема в том, что если об этом не будут говорить, оно никогда с места
и не сдвинется. 

Когда сборка для медленных архитектур осуществляется независимо, с этим
еще можно мириться. Но когда сборка для тостеров начинает тормозить
сборку для других архитектур, через некоторое время тут поднимется
громкий вой "а ну их нафиг эти ARM-ы". 

Поэтому лучше сразу начинать возиться с кроссборкой и пинать
всевозможные upstream-ы. 

AC_TRY_RUN, кстати, в большинстве случаев используется совершенно не по
делу.

Re: [devel] git.alt build architecture

[Afanasov Dmitry]

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

On Mon, May 18, 2009 at 03:11:59AM +0300, Kirill A. Shutemov wrote:
> Насколько я понимаю, архитектура сборки с использованием git.alt уже более-менее
> устоялась. К сожалению, никакой документации описывающую эту архитектуру я не
> нашёл. Может ли кто-либо из разработчиков, сделать обзор архитектуры сборочницы.
> В частности, интересует какие компоненты вовлечены в процесс и как они
> взаимодействуют между собой.
> 
> Спасибо.
скомпилировал недавние обяснения Алексея Турбина на http://www.altlinux.org/Girar/Internals,
за каковые ему огромное спасибо.

прошу проверить, причесать.

-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] git.alt build architecture

[Alexey Rusakov]

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

В Пнд, 18/05/2009 в 12:34 +0400, Afanasov Dmitry пишет:
> On Mon, May 18, 2009 at 03:11:59AM +0300, Kirill A. Shutemov wrote:
> > Насколько я понимаю, архитектура сборки с использованием git.alt уже более-менее
> > устоялась. К сожалению, никакой документации описывающую эту архитектуру я не
> > нашёл. Может ли кто-либо из разработчиков, сделать обзор архитектуры сборочницы.
> > В частности, интересует какие компоненты вовлечены в процесс и как они
> > взаимодействуют между собой.
> > 
> > Спасибо.
> скомпилировал недавние обяснения Алексея Турбина на http://www.altlinux.org/Girar/Internals,
> за каковые ему огромное спасибо.
> 
> прошу проверить, причесать.
И вам большое спасибо за компиляцию.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]