[devel] girar-builder [censored]

[devel] girar-builder [censored]

[REAL]

привет!

смотрю сюда:
http://git.altlinux.org/tasks/42561/task/log.3.2

вот скажите мне, если задание блокирует сборку всех остальных заданий, 
то нафига тогда вот это:
2011-Apr-16 08:27:45 :: task #42561 for sisyphus TESTED
task rebuild is necessary before commit, iteration #3.3 queued
?

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

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] girar-builder [censored]

[Michael Shigorin]

On Sat, Apr 16, 2011 at 04:55:53PM +0700, REAL wrote:
> какой смысл делать ещё одну итерацию, если ничего не изменилось?

Описывалось, ищи в районе анонса включения параллельной сборки.
(надо бы на вики, конечно...)

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

Re: [devel] girar-builder [censored]

[Dmitry V. Levin]

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

On Sat, Apr 16, 2011 at 04:55:53PM +0700, REAL wrote:
> привет!
> 
> смотрю сюда:
> http://git.altlinux.org/tasks/42561/task/log.3.2
> 
> вот скажите мне, если задание блокирует 
> сборку всех остальных заданий, то нафига 
> тогда вот это:
> 2011-Apr-16 08:27:45 :: task #42561 for sisyphus TESTED
> task rebuild is necessary before commit, iteration #3.3 queued
> ?
> 
> какой смысл делать ещё одну итерацию, 
> если ничего не изменилось? а так пошли на 
> 3 круг. воруя время у всех остальных.

Ну как же еще можно поступить, если за время тестирования задания
Сизиф успел измениться?


-- 
ldv

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

Re: [devel] girar-builder [censored]

[Yuri N. Sedunov]

В Вск, 17/04/2011 в 02:15 +0400, Dmitry V. Levin пишет:
> On Sat, Apr 16, 2011 at 04:55:53PM +0700, REAL wrote:
> > привет!
> > 
> > смотрю сюда:
> > http://git.altlinux.org/tasks/42561/task/log.3.2
> > 
> > вот скажите мне, если задание блокирует 
> > сборку всех остальных заданий, то нафига 
> > тогда вот это:
> > 2011-Apr-16 08:27:45 :: task #42561 for sisyphus TESTED
> > task rebuild is necessary before commit, iteration #3.3 queued
> > ?
> > 
> > какой смысл делать ещё одну итерацию, 
> > если ничего не изменилось? а так пошли на 
> > 3 круг. воруя время у всех остальных.
> 
> Ну как же еще можно поступить, если за время тестирования задания
> Сизиф успел измениться?

А на кой libgtk+3 должен ждать когда соберется KDE?

-- 
Yuri N. Sedunov

Re: [devel] girar-builder [censored]

[REAL]

17.04.2011 02:35, Michael Shigorin пишет:
>> какой смысл делать ещё одну итерацию, если ничего не изменилось?
>
> Описывалось, ищи в районе анонса включения параллельной сборки.
> (надо бы на вики, конечно...)

я знаю, но здесь-то параллельная сборка отсутствует. здесь собирается 
один KDE4, а остальные задания ждут своей очереди. что же могло 
измениться в репозитории, если туда ничего не поступало?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] girar-builder [censored]

[REAL]

17.04.2011 05:15, Dmitry V. Levin пишет:
>> какой смысл делать ещё одну итерацию,
>> если ничего не изменилось? а так пошли на
>> 3 круг. воруя время у всех остальных.
>
> Ну как же еще можно поступить, если за время тестирования задания
> Сизиф успел измениться?

мне думается, что когда собирался python2.6, подход был более 
осмыслен: не пропускались только те задания, которые могли сделать 
такие изменения, что сборка начиналась бы заново, а здесь, несмотря на 
то, что остановлены были _все_ задания, второй итерации оказалось 
недостаточно.

я не требую чего-то сделать _сейчас_, я просто прошу учесть на 
будущее, чтобы таких казусов больше не повторялось. а то ведь придётся 
ещё не раз с этим столкнуться: новая сборка KDE4, кому-то взбредёт в 
голову собрать python2.7, или даже мне летом придёт в голову всё же 
добить python3 до собираемого состояния...

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] girar-builder [censored]

[Dmitry V. Levin]

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

On Sun, Apr 17, 2011 at 12:19:11PM +0700, REAL wrote:
> 17.04.2011 02:35, Michael Shigorin пишет:
> >>какой смысл делать ещё одну итерацию, 
> >>если ничего не изменилось?
> >
> >Описывалось, ищи в районе анонса 
> >включения параллельной сборки.
> >(надо бы на вики, конечно...)
> 
> я знаю, но здесь-то параллельная сборка 
> отсутствует. здесь собирается один KDE4, а 
> остальные задания ждут своей очереди. 
> что же могло измениться в репозитории, 
> если туда ничего не поступало?

Оно поступило за время предыдущей итерации.


-- 
ldv

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

Re: [devel] girar-builder [censored]

[Dmitry V. Levin]

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

On Sun, Apr 17, 2011 at 03:28:56AM +0400, Yuri N. Sedunov wrote:
> В Вск, 17/04/2011 в 02:15 +0400, Dmitry V. Levin пишет:
> > On Sat, Apr 16, 2011 at 04:55:53PM +0700, REAL wrote:
> > > привет!
> > > 
> > > смотрю сюда:
> > > http://git.altlinux.org/tasks/42561/task/log.3.2
> > > 
> > > вот скажите мне, если задание блокирует 
> > > сборку всех остальных заданий, то нафига 
> > > тогда вот это:
> > > 2011-Apr-16 08:27:45 :: task #42561 for sisyphus TESTED
> > > task rebuild is necessary before commit, iteration #3.3 queued
> > > ?
> > > 
> > > какой смысл делать ещё одну итерацию, 
> > > если ничего не изменилось? а так пошли на 
> > > 3 круг. воруя время у всех остальных.
> > 
> > Ну как же еще можно поступить, если за время тестирования задания
> > Сизиф успел измениться?
> 
> А на кой libgtk+3 должен ждать когда соберется KDE?

Если бы пакет пропустили бы в Сизиф, не дожидаясь, пока 3-я итерация сборки
задания с kde4 завершится, то kde4 пришлось бы отправить на 4-ю итерацию.
Для таких больших заданий как kde4 это неизбежно привело бы к нескончаемым
итерациям практически без шансов довести задание до Сизифа.


-- 
ldv

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

Re: [devel] girar-builder [censored]

[Dmitry V. Levin]

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

On Sun, Apr 17, 2011 at 12:29:49PM +0700, REAL wrote:
> 17.04.2011 05:15, Dmitry V. Levin пишет:
> >>какой смысл делать ещё одну итерацию,
> >>если ничего не изменилось? а так пошли на
> >>3 круг. воруя время у всех остальных.
> >
> >Ну как же еще можно поступить, если за 
> >время тестирования задания
> >Сизиф успел измениться?
> 
> мне думается, что когда собирался python2.6, 
> подход был более осмыслен: не 
> пропускались только те задания, которые 
> могли сделать такие изменения, что 
> сборка начиналась бы заново, а здесь, 
> несмотря на то, что остановлены были _все_ 
> задания, второй итерации оказалось 
> недостаточно.

Задание python2.6 обрабатывал тот же самый алгоритм, с одной лишь
поправкой, что третью итерацию сборки python2.6 я сократил вручную.


-- 
ldv

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

Re: [devel] girar-builder [censored]

[Yuri N. Sedunov]

В Вск, 17/04/2011 в 12:20 +0400, Dmitry V. Levin пишет:
> On Sun, Apr 17, 2011 at 03:28:56AM +0400, Yuri N. Sedunov wrote:
> > В Вск, 17/04/2011 в 02:15 +0400, Dmitry V. Levin пишет:
> > > On Sat, Apr 16, 2011 at 04:55:53PM +0700, REAL wrote:
> > > > привет!
> > > > 
> > > > смотрю сюда:
> > > > http://git.altlinux.org/tasks/42561/task/log.3.2
> > > > 
> > > > вот скажите мне, если задание блокирует 
> > > > сборку всех остальных заданий, то нафига 
> > > > тогда вот это:
> > > > 2011-Apr-16 08:27:45 :: task #42561 for sisyphus TESTED
> > > > task rebuild is necessary before commit, iteration #3.3 queued
> > > > ?
> > > > 
> > > > какой смысл делать ещё одну итерацию, 
> > > > если ничего не изменилось? а так пошли на 
> > > > 3 круг. воруя время у всех остальных.
> > > 
> > > Ну как же еще можно поступить, если за время тестирования задания
> > > Сизиф успел измениться?
> > 
> > А на кой libgtk+3 должен ждать когда соберется KDE?
> 
> Если бы пакет пропустили бы в Сизиф, не дожидаясь, пока 3-я итерация сборки
> задания с kde4 завершится, то kde4 пришлось бы отправить на 4-ю итерацию.
> Для таких больших заданий как kde4 это неизбежно привело бы к нескончаемым
> итерациям практически без шансов довести задание до Сизифа.

Каким образом libgtk+3 влияет на сборку и установку kde4?

-- 
Yuri N. Sedunov

Re: [devel] girar-builder [censored]

[Slava Dubrovskiy]

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

17.04.2011 11:17, Dmitry V. Levin пишет:
> Оно поступило за время предыдущей итерации.

В свете сложившийся дискуссии, хочу спросить.
Есть пакет, который собирается около 3 суток (http://itk.org).
Такое можно посылать на сборку?

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5525 bytes --]

Re: [devel] girar-builder [censored]

[REAL]

17.04.2011 18:43, Slava Dubrovskiy пишет:
> Есть пакет, который собирается около 3 суток (http://itk.org).
> Такое можно посылать на сборку?

лучше разбить на части. например, вот здесь:
http://www.itk.org/Wiki/ITK/Git
видно, что там несколько подпроектов.

потом можно посмотреть в ThirdParty и увидеть, что там много такого, 
что уже есть в сизифе, и отключить их сборку изнутри ITK.

отключить Testing.

Wrapping собирать из отдельного репозитория...

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

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] girar-builder [censored]

[Slava Dubrovskiy]

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

17.04.2011 15:13, REAL пишет:
> 17.04.2011 18:43, Slava Dubrovskiy пишет:
>> Есть пакет, который собирается около 3 суток (http://itk.org).
>> Такое можно посылать на сборку?
>
> лучше разбить на части. например, вот здесь:
> http://www.itk.org/Wiki/ITK/Git
> видно, что там несколько подпроектов.
Ну я веду речь только про InsightToolkit. То что дается скачать по
ссылке
http://voxel.dl.sourceforge.net/sourceforge/itk/InsightToolkit-3.20.0.tar.gz
>
> потом можно посмотреть в ThirdParty и увидеть, что там много такого,
> что уже есть в сизифе, и отключить их сборку изнутри ITK.
Это сделано
>
> отключить Testing.
Это тоже отключено
>
> Wrapping собирать из отдельного репозитория...
Как раз тут вся и задержка, т.к. без wrapping достаточно быстро собирается.
>
> короче, есть над чем заморочиться. я как-то думал приступить (когда в
> первый раз собрал VTK), но понял, что на всё этого у меня не хватит ни
> времени, ни терпения.
Но мне кажется не очень хорошо, когда из-за технических ограничений
приходится извращаться (по другому назвать не могу)

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5525 bytes --]

Re: [devel] girar-builder [censored]

[Aleksey Novodvorsky]

17 апреля 2011 г. 16:28 пользователь Slava Dubrovskiy
<slava@tangramltd.com> написал:
> Но мне кажется не очень хорошо, когда из-за технических ограничений
> приходится извращаться (по другому назвать не могу)

Формально этих ограничений нет, но лучше оговорить порядок такой сборки с ldv@.

Rgrds, Алексей

Re: [devel] girar-builder [censored]

[Aleksey Novodvorsky]

17 апреля 2011 г. 16:51 пользователь REAL <root@mmedia2.kemsu.ru> написал:
> 17.04.2011 19:28, Slava Dubrovskiy пишет:
>>
>> Но мне кажется не очень хорошо, когда из-за технических ограничений
>> приходится извращаться (по другому назвать не могу)
>
> да, не очень, но тут вряд ли что можно поделать (мы ведь не одни в сизифе
> мейнтейнеры). мне вот пришлось при сборке OpenCASCADE поменять оптимизацию с
> -O2 на -O1, иначе не влезало в положенные 6 часов. это тоже не очень хорошо,
> но другого решения у меня не было.

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

Rgrds, Алексей

Re: [devel] girar-builder [censored]

[REAL]

17.04.2011 19:28, Slava Dubrovskiy пишет:
> Но мне кажется не очень хорошо, когда из-за технических ограничений
> приходится извращаться (по другому назвать не могу)

да, не очень, но тут вряд ли что можно поделать (мы ведь не одни в 
сизифе мейнтейнеры). мне вот пришлось при сборке OpenCASCADE поменять 
оптимизацию с -O2 на -O1, иначе не влезало в положенные 6 часов. это 
тоже не очень хорошо, но другого решения у меня не было.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] girar-builder [censored]

[Dmitry V. Levin]

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

On Sun, Apr 17, 2011 at 04:48:43PM +0400, Aleksey Novodvorsky wrote:
> 17 апреля 2011 г. 16:28 пользователь Slava Dubrovskiy написал:
> > Но мне кажется не очень хорошо, когда из-за технических ограничений
> > приходится извращаться (по другому назвать не могу)
> 
> Формально этих ограничений нет, но лучше оговорить порядок такой сборки с ldv@.

Пакет, который собирается более 6 часов, считается DoS-атакой.


-- 
ldv

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

Re: [devel] girar-builder [censored]

[Dmitry V. Levin]

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

On Sun, Apr 17, 2011 at 12:38:00PM +0400, Yuri N. Sedunov wrote:
> В Вск, 17/04/2011 в 12:20 +0400, Dmitry V. Levin пишет:
> > On Sun, Apr 17, 2011 at 03:28:56AM +0400, Yuri N. Sedunov wrote:
> > > В Вск, 17/04/2011 в 02:15 +0400, Dmitry V. Levin пишет:
> > > > On Sat, Apr 16, 2011 at 04:55:53PM +0700, REAL wrote:
> > > > > привет!
> > > > > 
> > > > > смотрю сюда:
> > > > > http://git.altlinux.org/tasks/42561/task/log.3.2
> > > > > 
> > > > > вот скажите мне, если задание блокирует 
> > > > > сборку всех остальных заданий, то нафига 
> > > > > тогда вот это:
> > > > > 2011-Apr-16 08:27:45 :: task #42561 for sisyphus TESTED
> > > > > task rebuild is necessary before commit, iteration #3.3 queued
> > > > > ?
> > > > > 
> > > > > какой смысл делать ещё одну итерацию, 
> > > > > если ничего не изменилось? а так пошли на 
> > > > > 3 круг. воруя время у всех остальных.
> > > > 
> > > > Ну как же еще можно поступить, если за время тестирования задания
> > > > Сизиф успел измениться?
> > > 
> > > А на кой libgtk+3 должен ждать когда соберется KDE?
> > 
> > Если бы пакет пропустили бы в Сизиф, не дожидаясь, пока 3-я итерация сборки
> > задания с kde4 завершится, то kde4 пришлось бы отправить на 4-ю итерацию.
> > Для таких больших заданий как kde4 это неизбежно привело бы к нескончаемым
> > итерациям практически без шансов довести задание до Сизифа.
> 
> Каким образом libgtk+3 влияет на сборку и установку kde4?

Заранее неизвестно, каким образом тот или иной пакет повлияет на сборку и
установку других пакетов. :(


-- 
ldv

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

Re: [devel] girar-builder [censored]

[Aleksey Novodvorsky]

17 апреля 2011 г. 23:45 пользователь Dmitry V. Levin <ldv@altlinux.org> написал:
> On Sun, Apr 17, 2011 at 04:48:43PM +0400, Aleksey Novodvorsky wrote:
>> 17 апреля 2011 г. 16:28 пользователь Slava Dubrovskiy написал:
>> > Но мне кажется не очень хорошо, когда из-за технических ограничений
>> > приходится извращаться (по другому назвать не могу)
>>
>> Формально этих ограничений нет, но лучше оговорить порядок такой сборки с ldv@.
>
> Пакет, который собирается более 6 часов, считается DoS-атакой.

А пакетное задание из нескольких пакетов, каждый из которых собирается
менее 6 часов, судя по KDE4, не считается.

Rgrds, Алексей

[devel] [JT] Re: girar-builder и итерации

[Michael Shigorin]

On Sun, Apr 17, 2011 at 11:47:59PM +0400, Dmitry V. Levin wrote:
> > Каким образом libgtk+3 влияет на сборку и установку kde4?
> Заранее неизвестно, каким образом тот или иной пакет повлияет
> на сборку и установку других пакетов. :(

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

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

Re: [devel] girar-builder [censored]

[Slava Dubrovskiy]

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

17.04.2011 22:45, Dmitry V. Levin пишет:
>
>>> Но мне кажется не очень хорошо, когда из-за технических ограничений
>>> приходится извращаться (по другому назвать не могу)
>> Формально этих ограничений нет, но лучше оговорить порядок такой сборки с ldv@.
> Пакет, который собирается более 6 часов, считается DoS-атакой.
Ну дос это когда с целью навредить.
Здесь же заведомо известно, что больше 6 часов собираются.
Исключения возможны?
Или как быть?

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5525 bytes --]

Re: [devel] [JT] Re: girar-builder и итерации

[Dmitry V. Levin]

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

On Mon, Apr 18, 2011 at 01:39:22PM +0300, Michael Shigorin wrote:
> On Sun, Apr 17, 2011 at 11:47:59PM +0400, Dmitry V. Levin wrote:
> > > Каким образом libgtk+3 влияет на сборку и установку kde4?
> > Заранее неизвестно, каким образом тот или иной пакет повлияет
> > на сборку и установку других пакетов. :(
> 
> Когда это обсуждалось -- предлагал кэшировать по данным
> предыдущей сборки (как и оценочное время самой сборки),
> чтобы иметь возможность сверить, входят ли порождаемые
> подпакеты в сборочные чруты параллельно выполняющихся
> задач.  И если входят -- переделывать как исключение.

Как этот алгоритм выявит следующую ситуацию:
раньше не входили, а после изменения будут входить?


-- 
ldv

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

Re: [devel] [JT] Re: girar-builder и итерации

[Yuri N. Sedunov]

В Пнд, 18/04/2011 в 16:49 +0400, Dmitry V. Levin пишет:
> On Mon, Apr 18, 2011 at 01:39:22PM +0300, Michael Shigorin wrote:
> > On Sun, Apr 17, 2011 at 11:47:59PM +0400, Dmitry V. Levin wrote:
> > > > Каким образом libgtk+3 влияет на сборку и установку kde4?
> > > Заранее неизвестно, каким образом тот или иной пакет повлияет
> > > на сборку и установку других пакетов. :(
> > 
> > Когда это обсуждалось -- предлагал кэшировать по данным
> > предыдущей сборки (как и оценочное время самой сборки),
> > чтобы иметь возможность сверить, входят ли порождаемые
> > подпакеты в сборочные чруты параллельно выполняющихся
> > задач.  И если входят -- переделывать как исключение.
> 
> Как этот алгоритм выявит следующую ситуацию:
> раньше не входили, а после изменения будут входить?

Неужели, даже когда задание с libgtk+3 уже собрано, невозможно решить
пропускать ли его вперед kde4?

-- 
Yuri N. Sedunov

Re: [devel] [JT] Re: girar-builder и итерации

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

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

On Mon, Apr 18, 2011 at 04:49:38PM +0400, Dmitry V. Levin wrote:

DVL> Как этот алгоритм выявит следующую ситуацию:
DVL> раньше не входили, а после изменения будут входить?

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

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

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

С тасками состоящими из множества пакетов, увы, это поможет только
во-первых собирать их за 2 (а не за 3) раза, а также блокировать
параллельную сборку только части пакетов -- а не всего Сизифа.

А когда будет возможность добавить ресурсов к сборочнице -- можно будет
делать спекулятивную сборку задач внутри task'а тем же способом. 

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

http://mithraen.ru/
----------------------------------------------------------------------------


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

Re: [devel] [JT] Re: girar-builder и итерации

[Michael Shigorin]

On Mon, Apr 18, 2011 at 04:49:38PM +0400, Dmitry V. Levin wrote:
> > > > Каким образом libgtk+3 влияет на сборку и установку kde4?
> > > Заранее неизвестно, каким образом тот или иной пакет повлияет
> > > на сборку и установку других пакетов. :(
> > Когда это обсуждалось -- предлагал кэшировать по данным
> > предыдущей сборки (как и оценочное время самой сборки),
> > чтобы иметь возможность сверить, входят ли порождаемые
> > подпакеты в сборочные чруты параллельно выполняющихся
> > задач.  И если входят -- переделывать как исключение.
> Как этот алгоритм выявит следующую ситуацию:
> раньше не входили, а после изменения будут входить?

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

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

Re: [devel] [JT] Re: girar-builder и итерации

[Dmitry V. Levin]

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

On Mon, Apr 18, 2011 at 05:17:54PM +0400, Yuri N. Sedunov wrote:
> В Пнд, 18/04/2011 в 16:49 +0400, Dmitry V. Levin пишет:
> > On Mon, Apr 18, 2011 at 01:39:22PM +0300, Michael Shigorin wrote:
> > > On Sun, Apr 17, 2011 at 11:47:59PM +0400, Dmitry V. Levin wrote:
> > > > > Каким образом libgtk+3 влияет на сборку и установку kde4?
> > > > Заранее неизвестно, каким образом тот или иной пакет повлияет
> > > > на сборку и установку других пакетов. :(
> > > 
> > > Когда это обсуждалось -- предлагал кэшировать по данным
> > > предыдущей сборки (как и оценочное время самой сборки),
> > > чтобы иметь возможность сверить, входят ли порождаемые
> > > подпакеты в сборочные чруты параллельно выполняющихся
> > > задач.  И если входят -- переделывать как исключение.
> > 
> > Как этот алгоритм выявит следующую ситуацию:
> > раньше не входили, а после изменения будут входить?
> 
> Неужели, даже когда задание с libgtk+3 уже собрано, невозможно решить
> пропускать ли его вперед kde4?

Для того, чтобы выяснить, влияет ли собранный libgtk+3 на результат сборки
kde4, нужно выполнить все те проверки, ради которых kde4 был отправлен на
третью итерацию.  Я не вижу, как это можно было бы этот процесс ускорить.


-- 
ldv

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

Re: [devel] [JT] Re: girar-builder и итерации

[Dmitry V. Levin]

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

On Mon, Apr 18, 2011 at 08:39:02PM +0300, Michael Shigorin wrote:
> On Mon, Apr 18, 2011 at 04:49:38PM +0400, Dmitry V. Levin wrote:
> > > > > Каким образом libgtk+3 влияет на сборку и установку kde4?
> > > > Заранее неизвестно, каким образом тот или иной пакет повлияет
> > > > на сборку и установку других пакетов. :(
> > > Когда это обсуждалось -- предлагал кэшировать по данным
> > > предыдущей сборки (как и оценочное время самой сборки),
> > > чтобы иметь возможность сверить, входят ли порождаемые
> > > подпакеты в сборочные чруты параллельно выполняющихся
> > > задач.  И если входят -- переделывать как исключение.
> > Как этот алгоритм выявит следующую ситуацию:
> > раньше не входили, а после изменения будут входить?
> 
> Точно такой же сверкой списков,

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

Кроме того, существуют глобальные проверки типа
gb-task-repo-unmets/gb-task-repo-elfsym, которые не закэшируешь.


-- 
ldv

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

Re: [devel] [JT] Re: girar-builder и итерации

[Michael Shigorin]

On Mon, Apr 18, 2011 at 09:48:21PM +0400, Dmitry V. Levin wrote:
> > > > Когда это обсуждалось -- предлагал кэшировать по данным
> > > > предыдущей сборки (как и оценочное время самой сборки),
> > > Как этот алгоритм выявит следующую ситуацию:
> > > раньше не входили, а после изменения будут входить?
> > Точно такой же сверкой списков,
> Только списки нужно каждый раз порождать заново с тем, чтобы
> убедиться в том, что закэшированное не устарело.

Конечно, и обновлять полученными данными кэш.

> Кроме того, существуют глобальные проверки типа
> gb-task-repo-unmets/gb-task-repo-elfsym, которые не закэшируешь.

Вопрос в том, чтобы снизить среднюю цену пересборок/проверок
в пересчёте на сборку прошедшего в сизиф пакета.

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