[devel] Re: Incoming rebuilds

[devel] Re: Incoming rebuilds

[Илья Евсеев]

> From: Michael Shigorin <mike@osdn.org.ua>

>> On Sat, Aug 28, 2004 at 01:50:29PM +0400, Илья Евсеев  wrote:
>> Идеальный вариант: пересборка в течение часа после заливки,
>> отчёт о пересборке с заголовком "Принято"/"Не принято"
>> отправляется мне в обязательном порядке.

> Не проще ли поднять локально или найти доступ
> к удаленному hasher на свежем сизифе?
Я так и сделал: собрал в хэшере на свежем Сизифе,
после чего залил в Инкоминг. В ответ - гордое безмолвие, едри их..

С уважением,
Илья Евсеев

[devel] [JT] Re: Incoming rebuilds

[Michael Shigorin]

On Sat, Aug 28, 2004 at 08:10:12PM +0400, Илья Евсеев  wrote:
> Я так и сделал: собрал в хэшере на свежем Сизифе, после чего
> залил в Инкоминг. В ответ - гордое безмолвие, [skip]

А, вот как.

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

Денис Смирнов с шашкой насчет понаписать скриптов для incoming
тоже ышшез :(

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

Re: [devel] [JT] Re: Incoming rebuilds

[Денис Смирнов]

On Sat, Aug 28, 2004 at 07:14:08PM +0300, Michael Shigorin wrote:

 MS> Ну, я свои соображения по поводу путей решения высказывал, но
 MS> пока их (или другие) нет времени внедрять, видимо.
 MS> Денис Смирнов с шашкой насчет понаписать скриптов для incoming
 MS> тоже ышшез :(

Тута я, тута.
Просто моя идея не получила хотя бы одобрения со стороны inger@ и ldv@, а
как я понимаю, это от них зависит пойдёт ли мой скрипт в /dev/null.

Кроме того технология в том виде, в котором её представлял я -- _требует_
выделеной машины, которая будет практически непрерывно пытаться собрать
полученые пакеты.

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

Я так и не понял, на каком этапе вмешивается конкретно сейчас (после
переделок) сам incominger@ в процесс. В моём представлении он вмешивается
исключительно после того, как пакет уже проверен на пересобираемость
и.т.д, и только в том случае, если сменился мантейнер или список бинарных
пакетов, генерируемых из этого, ну или если это совсем новый пакет.

-- 
С уважением, Денис

http://freesource.info

Re: [devel] [JT] Re: Incoming rebuilds

[Dmitry V. Levin]

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

Hi,

On Tue, Aug 31, 2004 at 11:14:18PM +0400, Денис Смирнов wrote:
> On Sat, Aug 28, 2004 at 07:14:08PM +0300, Michael Shigorin wrote:
>  MS> Ну, я свои соображения по поводу путей решения высказывал, но
>  MS> пока их (или другие) нет времени внедрять, видимо.
>  MS> Денис Смирнов с шашкой насчет понаписать скриптов для incoming
>  MS> тоже ышшез :(
> 
> Тута я, тута.
> Просто моя идея не получила хотя бы одобрения со стороны inger@ и ldv@, а
> как я понимаю, это от них зависит пойдёт ли мой скрипт в /dev/null.

Напомните ссылку на всякий случай, может кто-то пропустил.

> Кроме того технология в том виде, в котором её представлял я -- _требует_
> выделеной машины, которая будет практически непрерывно пытаться собрать
> полученые пакеты.

Непрерывно? :)

> Судя по тому, что я прочитал в тезисах конференции на Протве (увы, туда я
> доехать не смог) основную предлагаемую мной функциональность как раз уже
> реализовали.
> 
> Я так и не понял, на каком этапе вмешивается конкретно сейчас (после
> переделок) сам incominger@ в процесс. В моём представлении он вмешивается
> исключительно после того, как пакет уже проверен на пересобираемость
> и.т.д, и только в том случае, если сменился мантейнер или список бинарных
> пакетов, генерируемых из этого, ну или если это совсем новый пакет.

Цикл пересборки сейчас активируется вручную и выглядит (должен выглядеть)
примерно следующим образом:

1. Проверяются пакеты, подлежащие пересборке:
  - пакеты, не прошедшие sisyphus_check, отбраковываются, а сделавшие их
    maintainerы (если их удалось установить) уведомляются;
  - новые пакеты, а также пакеты, сделанные не теми maintainerами, которые
    зарегистрированы для соответствующих пакетов, отправляются incomingerу
    на approval;
  - все остальные пакеты отправляются на сборку.

2. Пакеты пересобираются:
  - пакеты, подлежащие пересборке, разбиваются на группы: каждую группу
    составляют все пакеты, собранные одним и тем же maintainerом;
  - пакеты в каждой из групп пересобираются отдельно, в порядке увеличения
    даты сборки в режиме --with-stuff;
  - непересобравшиеся пакеты в каждой группе отправляются на повторную
    пересборку;  процесс пересборки группы пакетов заканчивается, когда либо
    не остается непересобравшихся пакетов, либо их число не уменьшается.
  - логи сборки непересобравшихся пакетов (точнее говоря, хвосты логов)
    отправляются maintainerам соответствующих пакетов.

3. Пересобранные пакеты проверяются:
  - пакеты, комплектация (набор подпакетов) которых изменилась,
    отправляются incomingerу на approval;
  - остальные пакеты отправляются в репозитарий, заменяя предыдущие сборки
    этих пакетов.

4. В конце дня incominger делает заключительную проверку:
  - пересобирается пакет altlinux-release; неудача пересборки
    свидетельствует о непригодности репозитария; виновные в этом
    безобразии обычно быстро вычисляются, дальнейшие действия по
    обстоятельствам;
  - сравнивается вывод "aptbox/apt-cache unmet" с предыдущим днём;
    при появлении новых unmetов репозитарий может быть признан непригодным;
    заинтересованные в информации о новых unmetах уведомляются.


-- 
ldv

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

Re: [devel] [JT] Re: Incoming rebuilds

[Ivan Fedorov]

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

Dmitry V. Levin пишет:
> Цикл пересборки сейчас активируется вручную и выглядит (должен выглядеть)
> примерно следующим образом:
> 
> 1. Проверяются пакеты, подлежащие пересборке:
>   - пакеты, не прошедшие sisyphus_check, отбраковываются, а сделавшие их
>     maintainerы (если их удалось установить) уведомляются;
>   - новые пакеты, а также пакеты, сделанные не теми maintainerами, которые
>     зарегистрированы для соответствующих пакетов, отправляются incomingerу
>     на approval;
У меня кстати вопрос на почти эту тему. Новый sisyphus_check не
пропускает пакеты в которых gpg подпись не совпадает с последней записью
в changelog. А как мне теперь собирать модули для моего ядра? в
changelog всегда vsu. Packager: kernel@p.a.o
>   - все остальные пакеты отправляются на сборку.
> 
> 4. В конце дня incominger делает заключительную проверку:
>   - пересобирается пакет altlinux-release; неудача пересборки
>     свидетельствует о непригодности репозитария; виновные в этом
>     безобразии обычно быстро вычисляются, дальнейшие действия по
>     обстоятельствам;
И часто такое случается?..
>   - сравнивается вывод "aptbox/apt-cache unmet" с предыдущим днём;
>     при появлении новых unmetов репозитарий может быть признан непригодным;
>     заинтересованные в информации о новых unmetах уведомляются.

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

Re: [devel] Re: Incoming rebuilds

[Dmitry V. Levin]

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

On Wed, Sep 01, 2004 at 01:27:43PM +0900, Ivan Fedorov wrote:
> Dmitry V. Levin пишет:
[...]
> > 1. Проверяются пакеты, подлежащие пересборке:
> >   - пакеты, не прошедшие sisyphus_check, отбраковываются, а сделавшие их
> >     maintainerы (если их удалось установить) уведомляются;
> >   - новые пакеты, а также пакеты, сделанные не теми maintainerами, которые
> >     зарегистрированы для соответствующих пакетов, отправляются incomingerу
> >     на approval;
> У меня кстати вопрос на почти эту тему. Новый sisyphus_check не
> пропускает пакеты в которых gpg подпись не совпадает с последней записью
> в changelog. А как мне теперь собирать модули для моего ядра? в
> changelog всегда vsu. Packager: kernel@p.a.o

Если вы собираете srpm-пакет с модулем, то как там в lastchange
оказывается vsu?

> > 4. В конце дня incominger делает заключительную проверку:
> >   - пересобирается пакет altlinux-release; неудача пересборки
> >     свидетельствует о непригодности репозитария; виновные в этом
> >     безобразии обычно быстро вычисляются, дальнейшие действия по
> >     обстоятельствам;
> И часто такое случается?..

Редко.


-- 
ldv

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

Re: [devel] Re: Incoming rebuilds

[Ivan Fedorov]

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

Dmitry V. Levin пишет:
>>>1. Проверяются пакеты, подлежащие пересборке:
>>>  - пакеты, не прошедшие sisyphus_check, отбраковываются, а сделавшие их
>>>    maintainerы (если их удалось установить) уведомляются;
>>>  - новые пакеты, а также пакеты, сделанные не теми maintainerами, которые
>>>    зарегистрированы для соответствующих пакетов, отправляются incomingerу
>>>    на approval;
>>
>>У меня кстати вопрос на почти эту тему. Новый sisyphus_check не
>>пропускает пакеты в которых gpg подпись не совпадает с последней записью
>>в changelog. А как мне теперь собирать модули для моего ядра? в
>>changelog всегда vsu. Packager: kernel@p.a.o
> 
> 
> Если вы собираете srpm-пакет с модулем, то как там в lastchange
> оказывается vsu?
Тем, что спеки для модулей пишет и заливает в CVS vsu. А они потом
скриптом правятся для конкретного ядра... но changelog всегда остается
от vsu. И это нормальная ситуация... Надо это исправлять... devel-kernel
уже QA Robot ругается...

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

Re: [devel] [JT] Re: Incoming rebuilds

[Денис Смирнов]

On Wed, Sep 01, 2004 at 01:33:03AM +0400, Dmitry V. Levin wrote:

 >> Просто моя идея не получила хотя бы одобрения со стороны inger@ и ldv@, а
 >> как я понимаю, это от них зависит пойдёт ли мой скрипт в /dev/null.
 DVL> Напомните ссылку на всякий случай, может кто-то пропустил.

Сейчас не найду (я не тонком диалапе сейчас). Это был дли-и-и-и-инный
тред, в котором основными "зачинщиками" были мы с Михаилом Шигориным. Там
засветились все, в том числе inger@ и ты.

 >> Кроме того технология в том виде, в котором её представлял я -- _требует_
 >> выделеной машины, которая будет практически непрерывно пытаться собрать
 >> полученые пакеты.
 DVL> Непрерывно? :)

После каждого добавления нового пакета он будет немедленно пытаться
собраться. Если собрался -- будет попытка пересборки всего что валяется в
очереди.

>> Судя по тому, что я прочитал в тезисах конференции на Протве (увы, туда я
>> доехать не смог) основную предлагаемую мной функциональность как раз уже
>> реализовали.
>> 
>> Я так и не понял, на каком этапе вмешивается конкретно сейчас (после
>> переделок) сам incominger@ в процесс. В моём представлении он вмешивается
>> исключительно после того, как пакет уже проверен на пересобираемость
>> и.т.д, и только в том случае, если сменился мантейнер или список бинарных
>> пакетов, генерируемых из этого, ну или если это совсем новый пакет.
 DVL> Цикл пересборки сейчас активируется вручную и выглядит (должен выглядеть)
 DVL> примерно следующим образом:
 DVL> 1. Проверяются пакеты, подлежащие пересборке:
 DVL>   - пакеты, не прошедшие sisyphus_check, отбраковываются, а сделавшие их
 DVL>     maintainerы (если их удалось установить) уведомляются;

А зачем для допуска к этому этапу ручная активация процесса?
 
 DVL>   - новые пакеты, а также пакеты, сделанные не теми maintainerами, которые
 DVL>     зарегистрированы для соответствующих пакетов, отправляются incomingerу
 DVL>     на approval;

Сие должно быть вручную.
 
 DVL>   - все остальные пакеты отправляются на сборку.

Опять же, а здесь почему не автоматика?

 DVL> 2. Пакеты пересобираются:
 DVL>   - пакеты, подлежащие пересборке, разбиваются на группы: каждую группу
 DVL>     составляют все пакеты, собранные одним и тем же maintainerом;
 DVL>   - пакеты в каждой из групп пересобираются отдельно, в порядке увеличения
 DVL>     даты сборки в режиме --with-stuff;

Ага.

 DVL>   - непересобравшиеся пакеты в каждой группе отправляются на повторную
 DVL>     пересборку;  процесс пересборки группы пакетов заканчивается, когда либо
 DVL>     не остается непересобравшихся пакетов, либо их число не уменьшается.

Логично.

 DVL>   - логи сборки непересобравшихся пакетов (точнее говоря, хвосты логов)
 DVL>     отправляются maintainerам соответствующих пакетов.

Угумс. Хотя насчёт только хвостов -- зря. Хорошо бы и сами логи
выкладывать куда-нибудь в rsync'о доступное место (чтобы был виден,
например, вывод configure).

 DVL> 3. Пересобранные пакеты проверяются:
 DVL>   - пакеты, комплектация (набор подпакетов) которых изменилась,
 DVL>     отправляются incomingerу на approval;

Логично.
 
 DVL>   - остальные пакеты отправляются в репозитарий, заменяя предыдущие сборки
 DVL>     этих пакетов.
 DVL> 4. В конце дня incominger делает заключительную проверку:
 DVL>   - пересобирается пакет altlinux-release; неудача пересборки
 DVL>     свидетельствует о непригодности репозитария; виновные в этом
 DVL>     безобразии обычно быстро вычисляются, дальнейшие действия по
 DVL>     обстоятельствам;

Что значит "непригодность репозитария"?
 
 DVL>   - сравнивается вывод "aptbox/apt-cache unmet" с предыдущим днём;
 DVL>     при появлении новых unmetов репозитарий может быть признан непригодным;
 DVL>     заинтересованные в информации о новых unmetах уведомляются.

Ясно.

Спасибо за подробное разъяснение.

-- 
С уважением, Денис

http://freesource.info

Re: [devel] [JT] Re: Incoming rebuilds

[Dmitry V. Levin]

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

On Thu, Sep 02, 2004 at 03:06:55PM +0400, Денис Смирнов wrote:
> А зачем для допуска к этому этапу ручная активация процесса?

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

> Что значит "непригодность репозитария"?

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


-- 
ldv

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

Re: [devel] [JT] Re: Incoming rebuilds

[Денис Смирнов]

On Fri, Sep 03, 2004 at 01:44:02PM +0400, Dmitry V. Levin wrote:

 >> А зачем для допуска к этому этапу ручная активация процесса?
 DVL> Я имел в виду, что сам цикл пересборки активируется вручную, а не
 DVL> автоматически по факту поступления пакета в incoming.

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

 >> Что значит "непригодность репозитария"?
 DVL> Это значит, что он не будет синхронизирован наружу, и на его основе не
 DVL> будет предприниматься попыток сборки чего-либо.  Это такая штатная
 DVL> аварийная ситуация.

Это я понял, не понимаю лишь какого рода "непригодность" имеется в виду?

-- 
С уважением, Денис

http://freesource.info

Re: [devel] [JT] Re: Incoming rebuilds

[Dmitry V. Levin]

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

On Fri, Sep 03, 2004 at 03:43:23PM +0400, Денис Смирнов wrote:
> On Fri, Sep 03, 2004 at 01:44:02PM +0400, Dmitry V. Levin wrote:
>  >> А зачем для допуска к этому этапу ручная активация процесса?
>  DVL> Я имел в виду, что сам цикл пересборки активируется вручную, а не
>  DVL> автоматически по факту поступления пакета в incoming.
> 
> Интересно, чем это обосновано? Почему не активировать его каждые
> полчаса/час в автоматическом режиме?

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

>  >> Что значит "непригодность репозитария"?
>  DVL> Это значит, что он не будет синхронизирован наружу, и на его основе не
>  DVL> будет предприниматься попыток сборки чего-либо.  Это такая штатная
>  DVL> аварийная ситуация.
> 
> Это я понял, не понимаю лишь какого рода "непригодность" имеется в виду?

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


-- 
ldv

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

Re: [devel] Re: Incoming rebuilds

[Dmitry V. Levin]

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

Hi,

On Sat, Aug 28, 2004 at 08:10:12PM +0400, Илья Евсеев  wrote:
> > From: Michael Shigorin <mike@>
> 
> >> On Sat, Aug 28, 2004 at 01:50:29PM +0400, Илья Евсеев  wrote:
> >> Идеальный вариант: пересборка в течение часа после заливки,
> >> отчёт о пересборке с заголовком "Принято"/"Не принято"
> >> отправляется мне в обязательном порядке.
> 
> > Не проще ли поднять локально или найти доступ
> > к удаленному hasher на свежем сизифе?
> Я так и сделал: собрал в хэшере на свежем Сизифе,
> после чего залил в Инкоминг. В ответ - гордое безмолвие, едри их..

Не кипятитесь под высоким давлением,
см. http://lists.altlinux.ru/pipermail/devel/2004-August/013317.html

Перебои были, есть и будут до тех пор, пока всё не утрясётся.


-- 
ldv

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

[devel] [JT] Re: Incoming rebuilds

[Michael Shigorin]

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

On Mon, Aug 30, 2004 at 11:13:25AM +0400, Dmitry V. Levin wrote:
> Перебои были, есть и будут до тех пор, пока всё не утрясётся.

А после этого настанет тишина...

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

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