[devel] git.alt build

[devel] git.alt build

[Alexey Tourbin]

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

А есть какие-нибудь наброски не тему реализации build?

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

Re: [devel] git.alt build

[Dmitry V. Levin]

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

On Tue, Apr 17, 2007 at 05:29:39AM +0400, Alexey Tourbin wrote:
> А есть какие-нибудь наброски не тему реализации build?

Все наброски, которые у меня есть, находятся в
git.alt:/people/ldv/packages/girar.git

Но там по поводу сборки почти ничего нет.

У тебя есть идеи?


-- 
ldv

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

Re: [devel] git.alt build

[Alexey Tourbin]

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

On Tue, Apr 17, 2007 at 05:31:45PM +0400, Dmitry V. Levin wrote:
> On Tue, Apr 17, 2007 at 05:29:39AM +0400, Alexey Tourbin wrote:
> > А есть какие-нибудь наброски не тему реализации build?
> 
> Все наброски, которые у меня есть, находятся в
> git.alt:/people/ldv/packages/girar.git
> 
> Но там по поводу сборки почти ничего нет.
> 
> У тебя есть идеи?

Мы обсуждали с AMorozov на канале, как организовать полную regression
пересборку сизифа при прохождении каждого отдельного пакета.
Естественно, пересобирать нужно не всё, а только те пакеты, которые
как-либо зависят он вновь пришедшего пакета.

Точнее алгоритм regression переcборки такой:

1) учитываем все подпакеты вновь пришедшего пакета;
2) инициализируем query-buildroot с учетом поступивших подпакетов;
3) если какой-либо подпакет входит в basesystem+rpm-build, т.е. встал
в query-buildroot, тогда организуется низкоприоритетная очередь
"пересобрать весь сизиф"; дальше это не рассматривается; точнее,
содержимое query-билдрута не учитвается;
4) query-buildroot в который встал basesystem+rpm-build я далее называю
query-песочницей, или просто песочницей.  Теперь нужно *каждый* src.rpm
пакет пробить по песочнице в смысле print_uris, чтобы посмотреть, не
встанет ли в buildroot при его сборке какой-либо вновь учтенный пакет;
5) если обнаруживается, что для сборки очередного src.rpm пакета в
buildroot нужно поставить некоторые из только что учтенных пакетов,
тогда src.rpm пакет является предметом regression пересборки.

В итоге должны пересобираться все src.rpm пакеты, такие что в buildroot
у них встает один из вновь прибывших подпакетов.

Здесь есть две проблемы:

1) query песочницы обходится порядка одной секунды.  Если пробивать по
песочнице порядка 6000 src.rpm пакетов, то на каждый входящий пакет
придётся квирить песочницу порядка двух часов.

Мы обсудили с AMorozov что алгоритм замыкания зависимостей находится в
apt-get.cc; и что этот алгоритм, вообще говоря, не реентерабельный,
поскольку модифицирует глобальную структуру данных Cache.  Т.е. не
существует простого способа (в цикле) существенно снизить время запроса
к песочнице.

2) Ещё хуже.  На самом деле нет готовых src.rpm пакетов, по которым
можно квирить песочницу.  Есть только git репозитарии.  Запуск gear и
создание pkg.tar, который можно будет полноценно проквирить, обойдется
ещё в какое-то время.  Хуже того, полноценный квиринг pkg.tar
подразумевает постепенной наращивание билдрута (различие между
BuildRequires и BuildRequires(pre)).  То есть, грубо говоря, нужно
"начать собирать" пакет, чтобы понять, нужны ему какие-либо из вновь
учтенных пакетов или нет.

То есть вопрос который мы обсуждали на канале стоит так: в сизиф прошел
новый пакет (в виде подпакетов).  Какие теперь пакеты подлежат
пересборке в тестовых целях (с новым пактом, в виде подпакетов)?

Как я уже писал, существует более простая модель.  Можно просто
сохранять билдлог предыдущей сборки и проверять по этому логу что
становится в билдрут.  Но это не разрешает проблемы Provides+Obsolets.
Например пришел пакет libstdc++4.2, а в старых логах libstdc++4.1, тогда
нет хорошего способа сказать, что вместо libstdc++4.1 теперь apt
поставит libstdc++4.2, и результат может кардинально измениться.

В общем, трудная проблема.

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

Re: [devel] git.alt build

[Sergey Vlasov]

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

On Wed, Apr 18, 2007 at 08:05:58AM +0400, Alexey Tourbin wrote:
> 1) query песочницы обходится порядка одной секунды.  Если пробивать по
> песочнице порядка 6000 src.rpm пакетов, то на каждый входящий пакет
> придётся квирить песочницу порядка двух часов.
> 
> Мы обсудили с AMorozov что алгоритм замыкания зависимостей находится в
> apt-get.cc; и что этот алгоритм, вообще говоря, не реентерабельный,
> поскольку модифицирует глобальную структуру данных Cache.  Т.е. не
> существует простого способа (в цикле) существенно снизить время запроса
> к песочнице.

fork()?  Или там ещё и shared mmap модифицируется?

> 2) Ещё хуже.  На самом деле нет готовых src.rpm пакетов, по которым
> можно квирить песочницу.  Есть только git репозитарии.

Если даже отказаться от хранения src.rpm, можно хотя бы сохранять их
заголовки.

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

Re: [devel] git.alt build

[Dmitry V. Levin]

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

On Wed, Apr 18, 2007 at 08:05:58AM +0400, Alexey Tourbin wrote:
> On Tue, Apr 17, 2007 at 05:31:45PM +0400, Dmitry V. Levin wrote:
> > On Tue, Apr 17, 2007 at 05:29:39AM +0400, Alexey Tourbin wrote:
> > > А есть какие-нибудь наброски не тему реализации build?
> > 
> > Все наброски, которые у меня есть, находятся в
> > git.alt:/people/ldv/packages/girar.git
> > 
> > Но там по поводу сборки почти ничего нет.
> > 
> > У тебя есть идеи?
> 
> Мы обсуждали с AMorozov на канале, как организовать полную regression
> пересборку сизифа при прохождении каждого отдельного пакета.

Если целью является сборочная система, функционирующая без участия
человека (с минимально возможным участием человека), то к ней лучше
приближаться постепенно.

Мне кажется, что тестирование на предмет build regression более
ресурсоёмкое, чем тестирование на предмет install regression.

Впрочем, и последнее выглядит более ресурсоёмким, чем (в среднем) сборка
одного пакета.  Единственный метод, который у нас есть, базируется на
"apt-cache unmet" и является очень ресурсоёмким в части формирования
индексов временного репозитория.

Кроме того, добро от "apt-cache unmet" ещё не даёт гарантии того, что
устанавливаемость не сломана.

Поэтому оптимизация install regression testing сейчас более актуальна.


-- 
ldv

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

Re: [devel] git.alt build

[Alexey Tourbin]

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

On Sat, Apr 21, 2007 at 01:44:06AM +0400, Dmitry V. Levin wrote:
> > Мы обсуждали с AMorozov на канале, как организовать полную regression
> > пересборку сизифа при прохождении каждого отдельного пакета.
> 
> Если целью является сборочная система, функционирующая без участия
> человека (с минимально возможным участием человека), то к ней лучше
> приближаться постепенно.

Без человека это функционировать не может.  Я это понимаю так, что нужно
уведомить maintainer'а, что входящий пакет ломает некоторые другие
пакеты (и, может быть, потребуется исправить пакет, прежде чем он
попадет в сизиф).

То есть, как бы философски, это разница между знанием и невежеством.
Я отправил в сизиф новую сборку перла и я не знаю, сломает она
что-нибудь или нет.  Нужно ждать неделю или две, когда пройдет очередная
пересборка, тогда станет ясно.  С другой стороны, если бы я заранее
знал, что будут некоторые проблемы, то я, быть может, и не отправил бы
такую сборку в сизиф.

> Мне кажется, что тестирование на предмет build regression более
> ресурсоёмкое, чем тестирование на предмет install regression.

По крайней мере новая схема сборки пакетов должна быть достаточно
гибкой, чтобы при достаточном количестве ресурсов такую regression
пересборку можно было делать.

> Впрочем, и последнее выглядит более ресурсоёмким, чем (в среднем) сборка
> одного пакета.

Что ты понимаешь под install regression?  Какие комбинации пакетов надо
тестировать на установку?

> Единственный метод, который у нас есть, базируется на
> "apt-cache unmet" и является очень ресурсоёмким в части формирования
> индексов временного репозитория.

По поводу unmet'ов тоже есть некоторые мысли.  Не все unmet'ы одинаково
критичны.  Их нужно взвешивать по количеству пакетов, которые с
появлением данного анмета становится невозможным установить.

Например, если unmet появился в пакете perl-base, то это очень-очень
плохой unmet; а если unmet появился в пакете perl-devel, то это просто
очень плохой unmet.  А бывают unmet'ы практически безобидные. :)

> Кроме того, добро от "apt-cache unmet" ещё не даёт гарантии того, что
> устанавливаемость не сломана.

Конечно.  А устанавливаемость не гарантирует работоспособности.
Пересборка в большей степени дает проверку работоспособности.

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

Re: [devel] git.alt build

[Dmitry V. Levin]

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

On Sat, Apr 21, 2007 at 02:00:38AM +0400, Alexey Tourbin wrote:
> On Sat, Apr 21, 2007 at 01:44:06AM +0400, Dmitry V. Levin wrote:
> > > Мы обсуждали с AMorozov на канале, как организовать полную regression
> > > пересборку сизифа при прохождении каждого отдельного пакета.
> > 
> > Если целью является сборочная система, функционирующая без участия
> > человека (с минимально возможным участием человека), то к ней лучше
> > приближаться постепенно.
> 
> Без человека это функционировать не может.

Я имею в виду систему, которая в идеале функционирует без
человека-смотрителя, а на практике вмешательство человека-смотрителя
минимально.

> То есть, как бы философски, это разница между знанием и невежеством.
> Я отправил в сизиф новую сборку перла и я не знаю, сломает она
> что-нибудь или нет.  Нужно ждать неделю или две, когда пройдет очередная
> пересборка, тогда станет ясно.  С другой стороны, если бы я заранее
> знал, что будут некоторые проблемы, то я, быть может, и не отправил бы
> такую сборку в сизиф.

И как ты предлагаешь этот вопрос решать?  Автоматически тестировать
пересборку всего, чтобы определить, пропускать ли новую сборку перла в
Сизиф, конечно, было бы здорово, если бы это тестирование не было столь
ресурсоёмким.

> > Мне кажется, что тестирование на предмет build regression более
> > ресурсоёмкое, чем тестирование на предмет install regression.
> 
> По крайней мере новая схема сборки пакетов должна быть достаточно
> гибкой, чтобы при достаточном количестве ресурсов такую regression
> пересборку можно было делать.

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

> > Впрочем, и последнее выглядит более ресурсоёмким, чем (в среднем) сборка
> > одного пакета.
> 
> Что ты понимаешь под install regression?  Какие комбинации пакетов надо
> тестировать на установку?

install regression -- это такая ситуация: пакет A раньше устанавливался,
а теперь перестал устанавливаться.  Например, если у пакета A появился
unmet, то это install regression.

> > Единственный метод, который у нас есть, базируется на
> > "apt-cache unmet" и является очень ресурсоёмким в части формирования
> > индексов временного репозитория.
> 
> По поводу unmet'ов тоже есть некоторые мысли.  Не все unmet'ы одинаково
> критичны.  Их нужно взвешивать по количеству пакетов, которые с
> появлением данного анмета становится невозможным установить.

Это значит, что часть unmet'ов можно обрабатывать автоматически, без
привлечения человека-смотрителя.

> Например, если unmet появился в пакете perl-base, то это очень-очень
> плохой unmet; а если unmet появился в пакете perl-devel, то это просто
> очень плохой unmet.  А бывают unmet'ы практически безобидные. :)

Ну да, имеет место своеобразная транзитивность: если пакет A зависит
от пакета B, который получил unmet на пакет C, то пакет A тем самым
получил косвенный unmet на пакет C.

> > Кроме того, добро от "apt-cache unmet" ещё не даёт гарантии того, что
> > устанавливаемость не сломана.
> 
> Конечно.  А устанавливаемость не гарантирует работоспособности.

Конечно.  Но зато устанавливаемость, видимо, поддаётся автоматизированному
тестированию.

> Пересборка в большей степени дает проверку работоспособности.

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


-- 
ldv

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

Re: [devel] git.alt build

[Alexey Tourbin]

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

On Sat, Apr 21, 2007 at 02:25:47AM +0400, Dmitry V. Levin wrote:
> > То есть, как бы философски, это разница между знанием и невежеством.
> > Я отправил в сизиф новую сборку перла и я не знаю, сломает она
> > что-нибудь или нет.  Нужно ждать неделю или две, когда пройдет очередная
> > пересборка, тогда станет ясно.  С другой стороны, если бы я заранее
> > знал, что будут некоторые проблемы, то я, быть может, и не отправил бы
> > такую сборку в сизиф.
> 
> И как ты предлагаешь этот вопрос решать?  Автоматически тестировать
> пересборку всего, чтобы определить, пропускать ли новую сборку перла в
> Сизиф, конечно, было бы здорово, если бы это тестирование не было столь
> ресурсоёмким.

Ресурсы дело наживное.  Для начало нужно научиться быстро определять,
какие пакеты подлежат пересборке.  За вычетом perl-base получится
несколько сотен пакетов.  Среднее время сборки пакета, очень грубо,
около одной минуты.  Без распараллеливания получается несколько часов.
Туговато.

$ grep '^perl-[^b].*-5.8.8-alt10$' -l -r success error |wc -l
1341
$

Даже если управляться с каждым входящим пакетом за час, то получается
пропускная способность около 24 пакетов в сутки.  Нужно бы поточнее
статистику прикинуть.

И, конечно, не понятно, что делать, если обнаружено, что входящий пакет
что-либо ломает.  Очередь встаёт, пока человек не ответит да/нет.

С другой стороны, полная regression пересборка у нас всё равно проходит,
так что затраты по ресурсам сопоставимы.  Просто при полной regeression
пересборке "схлопываются" зависимости, то есть нельзя определить, какой
именно пакет сломал сборку данного пакета (если в билдруте поменялось
более одного пакета).

> > > Впрочем, и последнее выглядит более ресурсоёмким, чем (в среднем) сборка
> > > одного пакета.
> > 
> > Что ты понимаешь под install regression?  Какие комбинации пакетов надо
> > тестировать на установку?
> 
> install regression -- это такая ситуация: пакет A раньше устанавливался,
> а теперь перестал устанавливаться.  Например, если у пакета A появился
> unmet, то это install regression.

То просто попробовать установить все пакеты сизифа после прохождения
очередного пакета?

Или же просто попробовать установить сами собранные пакеты, и если они
устанавливаются, тогда нет причин думать, что и другие пакеты, которые
их требуют, не будут устанавливаться?

Последнее реализовать довольно просто.  Можно прямо в сборочный
buildroot попробовать поставить свежесобранные пакеты через rpm -Uv.
Мне пока не приходят в голову "легальные" случаи, когда такая установка
может не пройти.  То есть сборочные зависимости пакета я вижу как
надмножество установочных зависимостей.  Ну или аптом ставить, если
выяснится, что в ряде случаев это предположение неверно.  Прямо в hasher
бы такую штуку вделать.

> Есть множество пакетов, для которых пересборочный тест является основной
> характеристикой работоспособности.  Но в это множество попадает не так
> много пакетов.

Но это лучшее, что у нас есть для "раннего" автоматеческого
тестирования, без привлечения квалифицированных тестеров.

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

Re: [devel] git.alt build

[Alexey Tourbin]

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

On Sat, Apr 21, 2007 at 03:09:09AM +0400, Alexey Tourbin wrote:
> Или же просто попробовать установить сами собранные пакеты, и если они
> устанавливаются, тогда нет причин думать, что и другие пакеты, которые
> их требуют, не будут устанавливаться?
> 
> Последнее реализовать довольно просто.  Можно прямо в сборочный
> buildroot попробовать поставить свежесобранные пакеты через rpm -Uv.
> Мне пока не приходят в голову "легальные" случаи, когда такая установка
> может не пройти.  То есть сборочные зависимости пакета я вижу как
> надмножество установочных зависимостей.  Ну или аптом ставить, если
> выяснится, что в ряде случаев это предположение неверно.  Прямо в hasher
> бы такую штуку вделать.

Нет, бывают случаи, когда из одного пакета собирается несколько
конфликтующих backend'ов.

В общем, если "устанавливаемость" приравнять к "устанавливаемости по
зависимостям", то эту задачу лучше всего решать на уровне апта, который
предварительно нужно захачить, чтобы алгоритм замыкания зависимостей
работал в цикле.

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

Re: [devel] git.alt build

[Alexey Tourbin]

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

On Wed, Apr 18, 2007 at 08:05:58AM +0400, Alexey Tourbin wrote:
> Мы обсуждали с AMorozov на канале, как организовать полную regression
> пересборку сизифа при прохождении каждого отдельного пакета.
> Естественно, пересобирать нужно не всё, а только те пакеты, которые
> как-либо зависят он вновь пришедшего пакета.
> 
> Точнее алгоритм regression переcборки такой:
> 
> 1) учитываем все подпакеты вновь пришедшего пакета;
> 2) инициализируем query-buildroot с учетом поступивших подпакетов;
> 3) если какой-либо подпакет входит в basesystem+rpm-build, т.е. встал
> в query-buildroot, тогда организуется низкоприоритетная очередь
> "пересобрать весь сизиф"; дальше это не рассматривается; точнее,
> содержимое query-билдрута не учитвается;
> 4) query-buildroot в который встал basesystem+rpm-build я далее называю
> query-песочницей, или просто песочницей.  Теперь нужно *каждый* src.rpm
> пакет пробить по песочнице в смысле print_uris, чтобы посмотреть, не
> встанет ли в buildroot при его сборке какой-либо вновь учтенный пакет;
> 5) если обнаруживается, что для сборки очередного src.rpm пакета в
> buildroot нужно поставить некоторые из только что учтенных пакетов,
> тогда src.rpm пакет является предметом regression пересборки.
> 
> В итоге должны пересобираться все src.rpm пакеты, такие что в buildroot
> у них встает один из вновь прибывших подпакетов.
> 
> Здесь есть две проблемы:
> 
> 1) query песочницы обходится порядка одной секунды.  Если пробивать по
> песочнице порядка 6000 src.rpm пакетов, то на каждый входящий пакет
> придётся квирить песочницу порядка двух часов.
> 
> Мы обсудили с AMorozov что алгоритм замыкания зависимостей находится в
> apt-get.cc; и что этот алгоритм, вообще говоря, не реентерабельный,
> поскольку модифицирует глобальную структуру данных Cache.  Т.е. не
> существует простого способа (в цикле) существенно снизить время запроса
> к песочнице.
> 
> 2) Ещё хуже.  На самом деле нет готовых src.rpm пакетов, по которым
> можно квирить песочницу.  Есть только git репозитарии.  Запуск gear и
> создание pkg.tar, который можно будет полноценно проквирить, обойдется
> ещё в какое-то время.  Хуже того, полноценный квиринг pkg.tar
> подразумевает постепенной наращивание билдрута (различие между
> BuildRequires и BuildRequires(pre)).  То есть, грубо говоря, нужно
> "начать собирать" пакет, чтобы понять, нужны ему какие-либо из вновь
> учтенных пакетов или нет.
> 
> То есть вопрос который мы обсуждали на канале стоит так: в сизиф прошел
> новый пакет (в виде подпакетов).  Какие теперь пакеты подлежат
> пересборке в тестовых целях (с новым пактом, в виде подпакетов)?
> 
> Как я уже писал, существует более простая модель.  Можно просто
> сохранять билдлог предыдущей сборки и проверять по этому логу что
> становится в билдрут.  Но это не разрешает проблемы Provides+Obsolets.
> Например пришел пакет libstdc++4.2, а в старых логах libstdc++4.1, тогда
> нет хорошего способа сказать, что вместо libstdc++4.1 теперь apt
> поставит libstdc++4.2, и результат может кардинально измениться.

В query-rebuild.git есть вариант, как можно проквирить *.src.rpm и
отсеить те из них, которые нуждаются в тестовой пересборке.  Это всё
равно занимает достаточно много времени (несколько минут), но не
паталогически много времени.  И здесь всё ещё нельзя отказаться от
src.rpm.  Чтобы отказаться от src.rpm нужно "кешировать" BuildRequires.

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

Re: [devel] git.alt build

[Alexey Tourbin]

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

On Thu, Jun 19, 2008 at 06:17:14AM +0400, Alexey Tourbin wrote:
> В query-rebuild.git есть вариант, как можно проквирить *.src.rpm и
> отсеить те из них, которые нуждаются в тестовой пересборке.  Это всё
> равно занимает достаточно много времени (несколько минут), но не
> паталогически много времени.  И здесь всё ещё нельзя отказаться от
> src.rpm.  Чтобы отказаться от src.rpm нужно "кешировать" BuildRequires.

Please ignore this message. :)

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

Re: [devel] git.alt build

[Dmitry V. Levin]

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

On Tue, Apr 17, 2007 at 05:31:45PM +0400, Dmitry V. Levin wrote:
> On Tue, Apr 17, 2007 at 05:29:39AM +0400, Alexey Tourbin wrote:
> > А есть какие-нибудь наброски не тему реализации build?
> 
> Все наброски, которые у меня есть, находятся в
> git.alt:/people/ldv/packages/girar.git

У Legion'а тоже есть наброски, но они почему-то лежат в
непубличном каталоге /people/legion/private/.


-- 
ldv

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

Re: [devel] git.alt build

[Alexey Gladkov]

Dmitry V. Levin пишет:
> У Legion'а тоже есть наброски, но они почему-то лежат в
> непубличном каталоге /people/legion/private/.

Ну это неправда giter-factory.git лежал публично. :)

Переложил репозиторий из привата:
git,alt:/people/legion/packages/giter-factory.git

-- 
Rgrds, legion