[devel] RFC: тестирование входящих пакетов полной пересборкой сизифа

[devel] RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey Tourbin]

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

Я заметил, что branch 4.0 перед выкладыванием проходит тестирование
пересборкой.  Всё это делается вручную.  У меня есть предложение
внедрить аналогичную схему _автоматической_ пересборки для сизифа.

Я систематизирую идеи, которые обсуждал на конференции с ldv.
К сожалению, мне не удалось обсудить это с legion'ом.

Предыдущее обсуждение этой же темы здесь:
http://lists.altlinux.org/pipermail/devel/2007-April/045149.html
http://lists.altlinux.org/pipermail/devel/2007-April/045288.html
(и вообще все письма в этом треде -- "git.alt build")

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

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

Поясню некоторые выражения в кавычках.

"Полную пересборку сизифа" следует трактовать не буквально, а вот как:
пересобрать все пакеты, у которых при сборке в билдрут ставится один из
новых пакетов.  Это означает, что, с учетом поступивших пакетов, для
каждого src.rpm пакета формируется список пакетов для билдрута.  Если в
списке пакетов для билдрута оказывается новый пакет, то этот src.rpm
пакет подлежит пересборке.

"Успешная пересборка" сизифа подразумевает сравнение с предыдущим
статусом "полной пересборки сизифа".  Если по сравнению с предыдущей
полной пересборкой какой-либо пакет перестал собираться, значит,
пересборка не является успешной.

"Подтверждение" означает осознанное действие со стороны maintainer'а
пакета и/или "формирующего очередной релиз сизифа" по отношению к
пакету, который что-то сломал.  То есть можно вручную подтвердить,
что новый пакет всё же не настолько плох, чтобы не пускать его в сизиф
(например, виноваты другие пакеты, или же ожидается их скорое
исправление).

Вижу две проблемы: теоретическую (сериализация) и ресурсы.

Сериализация.  В идеале таким образом пакеты должны идти в очередь один
за другим, и очередь не должна двигаться, пока не будет принято решение
по каждому очередному "неидеальному" пакету.  К сожалению, полная
сериализация будет упираться в человеческий фактор (подтверждение
вручную) и поэтому нетехнологична.  То есть проблема в том, что
параллельно протестированные пакеты могут по отдельности ничего не
ломать, а комбинация двух новых пакетов может дать уже другой исход.
Пример.  Прошел пакет libxml2 и успешно протестировался пересборкой
старой версии perl-XML-LibXML.  Параллельно прошел новый пакет
perl-XML-LibXML и успешно протестировался на старой версии libxml2.
Но, может статься, новый perl-XML-LibXML уже не будет собираться
на новой версии libxml2.

На самом деле такого рода "конкурентные изменения" рассматриваются
в теории RDBMS.  Там есть разные уровни изоляции транзакций и т.д.
Может кто знает.

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

Конечно, если пакет ставится в базовую сборочную среду, тогда
возможность уменьшения списка пакетов исчезает.  Но, может быть,
кто-нибудь помнит историю с битым cpio ("cpio обновился, и hasher
сломался").  Так что ресурсы на полную пересборку сизифа при прохождении
базовых пакетов не стоит считать потраченными напрасно.

Впрочем, последнее мнение не отменяет вопроса о наличии ресурсов как
таковых.

Техническая проблема на подступах к определению списка пакетов, подлежащих
пересборке, было в том, что нужно научиться очень быстро строить список
пакетов в билдруте при сборке каждого src.rpm пакета.  Стандартный
способ (который используется в hasher, через --print-uris) занимает
порядка одной секунды на src.rpm пакет.  Это связано с тем, что apt всё
время перечитывает свой кеш.  В сизифе около 6000 src.rpm пакетов, значит,
определять, какие из них нужно пересобрать, можно около 2 часов.  Это
даже больше, чем может занять последующая пересборка обнаруженным таким
образом src.rpm пакетов.  У меня сейчас зреет решение, как немного
захачить апт и написать к нему скрипт на lua, чтобы построение списка
пакетов для пересборки по времени сводилось к чтению хедеров src.rpm
пакетов.

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

Re: [devel] RFC: тестирование входящих пакетов полной пересборкой сизифа

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

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

On Wed, Aug 22, 2007 at 01:43:21AM +0400, Алексей Турбин wrote:

Я уже тысячу раз выдвигал идею с формированием некоего pocket перед
Сизифом. Вся сборка входящих пакетов ведется в этом pocket. После сборки
если пакет ничего не ломает, то он переносится в Сизиф. Если что-то ломает
-- остается в pocket. Необходимость оставлять в pocket нужна для пакетов,
которые необходимо переносить в Сизиф _группой_, тогда эти пакеты будут из
pocket в Сизиф переноситься уже группой.

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

http://freesource.info
----------------------------------------------------------------------------
Я не улавливаю, зачем про каждый новый пакет спрашивать incoming@?
		-- ldv in devel@

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

Re: [devel] RFC: тестирование входящих пакетов полной пересборкой сизифа

[Хихин Руслан]

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

Здравствуйте Денис Смирнов
  В сообщении от 22 августа 2007 Денис Смирнов написал(a):
 > Я уже тысячу раз выдвигал идею с формированием некоего pocket перед
 > Сизифом. Вся сборка входящих пакетов ведется в этом pocket. После
 > сборки
 > если пакет ничего не ломает, то он переносится в Сизиф. Если что-то
 > ломает
 > -- остается в pocket. Необходимость оставлять в pocket нужна для
 > пакетов,
 > которые необходимо переносить в Сизиф _группой_, тогда эти пакеты
 > будут из
 > pocket в Сизиф переноситься уже группой.
Я за :)

-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey Tourbin]

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

On Wed, Aug 22, 2007 at 01:43:21AM +0400, Alexey Tourbin wrote:
> "Полную пересборку сизифа" следует трактовать не буквально, а вот как:
> пересобрать все пакеты, у которых при сборке в билдрут ставится один из
> новых пакетов.  Это означает, что, с учетом поступивших пакетов, для
> каждого src.rpm пакета формируется список пакетов для билдрута.  Если в
> списке пакетов для билдрута оказывается новый пакет, то этот src.rpm
> пакет подлежит пересборке.

[...]

> Техническая проблема на подступах к определению списка пакетов, подлежащих
> пересборке, было в том, что нужно научиться очень быстро строить список
> пакетов в билдруте при сборке каждого src.rpm пакета.  Стандартный
> способ (который используется в hasher, через --print-uris) занимает
> порядка одной секунды на src.rpm пакет.  Это связано с тем, что apt всё
> время перечитывает свой кеш.  В сизифе около 6000 src.rpm пакетов, значит,
> определять, какие из них нужно пересобрать, можно около 2 часов.  Это
> даже больше, чем может занять последующая пересборка обнаруженным таким
> образом src.rpm пакетов.  У меня сейчас зреет решение, как немного
> захачить апт и написать к нему скрипт на lua, чтобы построение списка
> пакетов для пересборки по времени сводилось к чтению хедеров src.rpm
> пакетов.

Я придумал решение (захачил апт, чтобы он не перечитывал кеш, написал
скрипт на lua и кое-что ещё), при котором скорость --print-uris на моей
машине сейчас около 5 src.rpm пакетов в секунду.  Получается всё равно
достаточно много -- выяснять, какие из 6000 src.rpm пакетов нужно
пересобирать, придётся минут 20.  Боюсь, что намного быстрее уже не
получится.

Опубликую и напишу в ближайшее время.

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

Re: [devel] RFC: тестирование входящих пакетов полной пересборкой сизифа

[Michael Shigorin]

On Thu, Aug 23, 2007 at 02:19:45PM +0400, Alexey Tourbin wrote:
> Я придумал решение (захачил апт, чтобы он не перечитывал кеш,
> написал скрипт на lua и кое-что ещё), при котором скорость
> --print-uris на моей машине сейчас около 5 src.rpm пакетов в
> секунду.  Получается всё равно достаточно много -- выяснять,
> какие из 6000 src.rpm пакетов нужно пересобирать, придётся
> минут 20.  Боюсь, что намного быстрее уже не получится.
> Опубликую и напишу в ближайшее время.

Мож покатит 80% решение -- делать выводы из списков пакетов 
по последней производившейся сборке?  (помнишь, я предлагал
и время следующей оценивать по времени предыдущей как-то)

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

Re: [devel] RFC: тестирование входящих пакетов полной пересборкой сизифа

[Mykola S. Grechukh]

> On Thu, Aug 23, 2007 at 02:19:45PM +0400, Alexey Tourbin wrote:
> > Я придумал решение (захачил апт, чтобы он не перечитывал кеш,
> > написал скрипт на lua и кое-что ещё), при котором скорость
> > --print-uris на моей машине сейчас около 5 src.rpm пакетов в
> > секунду.  Получается всё равно достаточно много -- выяснять,
> > какие из 6000 src.rpm пакетов нужно пересобирать, придётся
> > минут 20.  Боюсь, что намного быстрее уже не получится.
> > Опубликую и напишу в ближайшее время.
>
> Мож покатит 80% решение -- делать выводы из списков пакетов
> по последней производившейся сборке?

как я понял, смысл именно в генерации списка с учетом вновь
поступившего пакета..

Re: [devel] RFC: тестирование входящих пакетов полной пересборкой сизифа

[Mykola S. Grechukh]

простейший пример - если пакетов qnetwalk поставить
Provides: kdelibs
Obsoletes: kdelibs

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

[devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Michael Shigorin]

On Thu, Aug 23, 2007 at 02:18:40PM +0300, Mykola S. Grechukh wrote:
> простейший пример - если пакетов qnetwalk поставить
> Provides: kdelibs
> Obsoletes: kdelibs
> 
> .. то старые списки покажут, что его никто не использует.
> А на самом деле разломается сборка всего кдешного.

Я же написал -- "80%".  Инженер по качеству и полицейский с
дубинкой -- немного разные роли, даже если и пересекающиеся.

С такими аргументами... от rm -rf в %post тоже никаких страховок
нет, и по существу быть не может.

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

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Mykola S. Grechukh]

> On Thu, Aug 23, 2007 at 02:18:40PM +0300, Mykola S. Grechukh wrote:
> > простейший пример - если пакетов qnetwalk поставить
> > Provides: kdelibs
> > Obsoletes: kdelibs
> >
> > .. то старые списки покажут, что его никто не использует.
> > А на самом деле разломается сборка всего кдешного.
>
> Я же написал -- "80%".  Инженер по качеству и полицейский с
> дубинкой -- немного разные роли, даже если и пересекающиеся.
>
> С такими аргументами... от rm -rf в %post тоже никаких страховок
> нет, и по существу быть не может.

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

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Michael Shigorin]

On Thu, Aug 23, 2007 at 03:10:00PM +0300, Mykola S. Grechukh wrote:
> ну это вырожденный случай. Но смысл имхо в проверке влияния
> нового пакета на сборку, *включая* изменение списка
> устанавливаемых. Более реалистичных примеров есть, хотя сейчас
> не соображу.

Дорого очень получается, а поскольку это ПРОВЕРКА, а не mission
critical чегонитьтам -- то и предложил применение принципа
"сделай заранее".

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

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey Tourbin]

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

On Thu, Aug 23, 2007 at 03:11:22PM +0300, Michael Shigorin wrote:
> On Thu, Aug 23, 2007 at 03:10:00PM +0300, Mykola S. Grechukh wrote:
> > ну это вырожденный случай. Но смысл имхо в проверке влияния
> > нового пакета на сборку, *включая* изменение списка
> > устанавливаемых. Более реалистичных примеров есть, хотя сейчас
> > не соображу.
> 
> Дорого очень получается, а поскольку это ПРОВЕРКА, а не mission
> critical чегонитьтам -- то и предложил применение принципа
> "сделай заранее".

Очень дорого это сколько, в новых деньгах? :)

Я и это обсуждал с ldv на конференции.  Порешили на том,
что нужно поточнее прикинуть статистику.  Какая пропускная
способность сизифа и средняя загрузка сборочных серверов
нам нужна, и сколько, исходя из этого, нужно сборочных серверов?

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

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

[devel] статистика

[Alexey Tourbin]

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

On Thu, Aug 23, 2007 at 04:32:18PM +0400, Alexey Tourbin wrote:
> Очень дорого это сколько, в новых деньгах? :)
> 
> Я и это обсуждал с ldv на конференции.  Порешили на том,
> что нужно поточнее прикинуть статистику.  Какая пропускная
> способность сизифа и средняя загрузка сборочных серверов
> нам нужна, и сколько, исходя из этого, нужно сборочных серверов?
> 
> Думаю, что в ближайшее время ответ на эти вопросы будет получен.
> Тогда можно ставить вопрос ребром.  А заранее вопить "очень дорого",
> впрочем как и "даёшь серверы" с пустыми руками и без понятия, это
> по-моему не стоит так делать.

Я грепнул логи /raid/beehive/old-logs/i586/2007/0812/success/,
выложил сюда: ftp://ftp.altlinux.org/pub/people/at/buildtime

У меня получилась следующая первичная статистика:
среднее время сборки 74 секунды, медиана распределения 27 секунд,
сигма которая СКО она же стандартная девиация 189 секунд,
максимальное время сборки 3273 секунды (у пакета kdebase).

Гистограмма по смыслу похожа на распределение Максвелла. :)
ftp://ftp.altlinux.org/pub/people/at/buildtime.png

Теперь, если кто понимает в мат. статистике, я вопрошаю:
что можно извлечь из этих данных?

Начнем с простого вопроса: что дает среднее время сборки пакета?
Ведь может попасться "неудачный" пакет, и рассчитывать, что он соберётся
за минуту, нельзя (kdebase собирается целый час).  Из статистики
известно "правило трёх сигм" (правда, оно касается распределений,
близких к нормальному).  Это правило сводится к тому, что с надёжностью
больше 99% случайная величина (время сборки) принимает значение
(среднее)плюс-минус(3*сигма), и с надежностью около 95%
(среднее)плюс-минус(2*сигма).

Значит, чтобы нас не "прокатили" на "оптимистичном" среднем значении,
нужно закладывать время сборки пакета 74+2*сигма=74+2*189=452 секунды.

С другой стороны, "время сборки" одного пакета по отношению к нашей
задаче вообще имеет мало смысла.  Мы ведь будем пересобирать серию из
N пакетов подряд.  Из статистики также известно (если чорт меня не
попутал), что с увеличением размеров выборки сигма падает
пропорционально 1/sqrt(N) -- то есть, на пальцах, "размах" отклонения
суммарного времени падает за счет нивелирования выбросов.
Это даёт следующую формулу:

(ВРЕМЯ СБОРКИ СЛУЧАЙНО ВЫБРАННЫХ N src.rpm ПАКЕТОВ) <=
	N * (среднее + 2*сигма/sqrt(N))
где
	среднее = 74 секунды
	сигма = 189 секунда
неравенство выполняется с вероятностью около 90%.

Прошу подписчиков листа обдумать это соображение. :)

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

Re: [devel] статистика

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 1055 bytes --]

On Thu, Aug 23, 2007 at 11:05:29PM +0400, Alexey Tourbin wrote:
> (ВРЕМЯ СБОРКИ СЛУЧАЙНО ВЫБРАННЫХ N src.rpm ПАКЕТОВ) <=
> 	N * (среднее + 2*сигма/sqrt(N))
> где
> 	среднее = 74 секунды
> 	сигма = 189 секунда
> неравенство выполняется с вероятностью около 90%.

Численный эксперимент показывает, что надежность формулы около 95%.

$ perl test-buildtime.pl <buildtime
mean=74.3942971025606
devi=189.240149227661
   5 packages:  955/1000 = 95.5%
  10 packages:  948/1000 = 94.8%
  50 packages:  959/1000 = 95.9%
 100 packages:  952/1000 = 95.2%
 500 packages:  972/1000 = 97.2%
1000 packages:  973/1000 = 97.3%
5000 packages: 1000/1000 = 100.0%
$ perl test-buildtime.pl <buildtime
mean=74.3942971025606
devi=189.240149227661
   5 packages:  950/1000 = 95.0%
  10 packages:  943/1000 = 94.3%
  50 packages:  954/1000 = 95.4%
 100 packages:  957/1000 = 95.7%
 500 packages:  970/1000 = 97.0%
1000 packages:  983/1000 = 98.3%
5000 packages: 1000/1000 = 100.0%
$ wc -l buildtime
6523 buildtime
$

(test-buildtime.pl приложен)

[-- Attachment #1.2: test-buildtime.pl --]
[-- Type: text/plain, Size: 704 bytes --]

#!/usr/bin/perl
use strict;
use Statistics::Descriptive;
my $stats = Statistics::Descriptive::Full->new();
while (<>) {
	my @v = split;
	$stats->add_data(0+$v[-1]);
}

my $mean = $stats->mean();
my $devi = $stats->standard_deviation();
print "mean=$mean\n";
print "devi=$devi\n";

my @times = $stats->get_data();

sub calc_90_time ($) {
	my $N = shift;
	return $N * ($mean + 2*$devi/sqrt($N));
}

use List::Util qw(shuffle sum);
for my $N (5, 10, 50, 100, 500, 1000, 5000) {
	my $time = calc_90_time($N);
	my $n_ok = 0;
	for (1 .. 1000) {
		@times = shuffle(@times);
		my $sum = sum @times[1 .. $N];
		$n_ok++ if $sum <= $time;
	}
	printf "%4d packages: %4d/1000 = %.1f%\n", $N, $n_ok, 100*$n_ok/1000;
}

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

Re: [devel] статистика

[Vadim V. Zhytnikov]

Alexey Tourbin пишет:
> On Thu, Aug 23, 2007 at 04:32:18PM +0400, Alexey Tourbin wrote:
>> Очень дорого это сколько, в новых деньгах? :)
>>
>> Я и это обсуждал с ldv на конференции.  Порешили на том,
>> что нужно поточнее прикинуть статистику.  Какая пропускная
>> способность сизифа и средняя загрузка сборочных серверов
>> нам нужна, и сколько, исходя из этого, нужно сборочных серверов?
>>
>> Думаю, что в ближайшее время ответ на эти вопросы будет получен.
>> Тогда можно ставить вопрос ребром.  А заранее вопить "очень дорого",
>> впрочем как и "даёшь серверы" с пустыми руками и без понятия, это
>> по-моему не стоит так делать.
> 
> Я грепнул логи /raid/beehive/old-logs/i586/2007/0812/success/,
> выложил сюда: ftp://ftp.altlinux.org/pub/people/at/buildtime
> 
> У меня получилась следующая первичная статистика:
> среднее время сборки 74 секунды, медиана распределения 27 секунд,
> сигма которая СКО она же стандартная девиация 189 секунд,
> максимальное время сборки 3273 секунды (у пакета kdebase).
> 
> Гистограмма по смыслу похожа на распределение Максвелла. :)
> ftp://ftp.altlinux.org/pub/people/at/buildtime.png
> 

Какова температура репозитория?

-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

Re: [devel] статистика

[Alexey Tourbin]

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

On Thu, Aug 23, 2007 at 11:37:21PM +0300, Vadim V. Zhytnikov wrote:
> Alexey Tourbin пишет:
> > On Thu, Aug 23, 2007 at 04:32:18PM +0400, Alexey Tourbin wrote:
> >> Очень дорого это сколько, в новых деньгах? :)
> >>
> >> Я и это обсуждал с ldv на конференции.  Порешили на том,
> >> что нужно поточнее прикинуть статистику.  Какая пропускная
> >> способность сизифа и средняя загрузка сборочных серверов
> >> нам нужна, и сколько, исходя из этого, нужно сборочных серверов?
> >>
> >> Думаю, что в ближайшее время ответ на эти вопросы будет получен.
> >> Тогда можно ставить вопрос ребром.  А заранее вопить "очень дорого",
> >> впрочем как и "даёшь серверы" с пустыми руками и без понятия, это
> >> по-моему не стоит так делать.
> > 
> > Я грепнул логи /raid/beehive/old-logs/i586/2007/0812/success/,
> > выложил сюда: ftp://ftp.altlinux.org/pub/people/at/buildtime
> > 
> > У меня получилась следующая первичная статистика:
> > среднее время сборки 74 секунды, медиана распределения 27 секунд,
> > сигма которая СКО она же стандартная девиация 189 секунд,
> > максимальное время сборки 3273 секунды (у пакета kdebase).
> > 
> > Гистограмма по смыслу похожа на распределение Максвелла. :)
> > ftp://ftp.altlinux.org/pub/people/at/buildtime.png
> > 
> 
> Какова температура репозитория?

Это гистограмма.  Каждый столбец означает сколько пакетов собирается
в интервале [n..n+10) секунд.  Зелёная кривая это распределение
Максвелла, его параметры я, очевидно,  не вычислял методом
правдоподобия а подобрал с третьего раза, just for fun. :)

Я не понял суть вопроса.  Постановка задачи типа "за какое время
соберётся N случайно выбранных src.rpm пакетов с заданной надежностью
на превышение времени" кажется Вам бессмысленной?

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

Re: [devel] статистика

[Alexey Tourbin]

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

On Thu, Aug 23, 2007 at 11:37:21PM +0300, Vadim V. Zhytnikov wrote:
> > Гистограмма по смыслу похожа на распределение Максвелла. :)
> > ftp://ftp.altlinux.org/pub/people/at/buildtime.png
> 
> Какова температура репозитория?

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

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

Re: [devel] статистика

[Хихин Руслан]

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

Здравствуйте Alexey Tourbin
  В сообщении от 23 августа 2007 Alexey Tourbin написал(a):
 > On Thu, Aug 23, 2007 at 04:32:18PM +0400, Alexey Tourbin wrote:
 > > Очень дорого это сколько, в новых деньгах? :)
 > >
 > >
 > >
 > > Я и это обсуждал с ldv на конференции.  Порешили на том,
 > >
 > > что нужно поточнее прикинуть статистику.  Какая пропускная
 > >
 > > способность сизифа и средняя загрузка сборочных серверов
 > >
 > > нам нужна, и сколько, исходя из этого, нужно сборочных серверов?
 > >
 > >
 > >
 > > Думаю, что в ближайшее время ответ на эти вопросы будет получен.
 > >
 > > Тогда можно ставить вопрос ребром.  А заранее вопить "очень
 > > дорого",
 > >
 > > впрочем как и "даёшь серверы" с пустыми руками и без понятия, это
 > >
 > > по-моему не стоит так делать.
 >
 > Я грепнул логи /raid/beehive/old-logs/i586/2007/0812/success/,
 >
 > выложил сюда: ftp://ftp.altlinux.org/pub/people/at/buildtime
 >
 >
 >
 > У меня получилась следующая первичная статистика:
 >
 > среднее время сборки 74 секунды, медиана распределения 27 секунд,
 >
 > сигма которая СКО она же стандартная девиация 189 секунд,
 >
 > максимальное время сборки 3273 секунды (у пакета kdebase).
 >
 >
 >
 > Гистограмма по смыслу похожа на распределение Максвелла. :)
 >
 > ftp://ftp.altlinux.org/pub/people/at/buildtime.png
 >
 >
 >
 > Теперь, если кто понимает в мат. статистике, я вопрошаю:
 >
 > что можно извлечь из этих данных?
 >
 >
 >
 > Начнем с простого вопроса: что дает среднее время сборки пакета?
 >
 > Ведь может попасться "неудачный" пакет, и рассчитывать, что он
 > соберётся
 >
 > за минуту, нельзя (kdebase собирается целый час).  Из статистики
 >
 > известно "правило трёх сигм" (правда, оно касается распределений,
 >
 > близких к нормальному).  Это правило сводится к тому, что с
 > надёжностью
 >
 > больше 99% случайная величина (время сборки) принимает значение
 >
 > (среднее)плюс-минус(3*сигма), и с надежностью около 95%
 >
 > (среднее)плюс-минус(2*сигма).
 >
 >
 >
 > Значит, чтобы нас не "прокатили" на "оптимистичном" среднем
 > значении,
 >
 > нужно закладывать время сборки пакета 74+2*сигма=74+2*189=452
 > секунды.
 >
 >
 >
 > С другой стороны, "время сборки" одного пакета по отношению к нашей
 >
 > задаче вообще имеет мало смысла.  Мы ведь будем пересобирать серию
 > из
 >
 > N пакетов подряд.  Из статистики также известно (если чорт меня не
 >
 > попутал), что с увеличением размеров выборки сигма падает
 >
 > пропорционально 1/sqrt(N) -- то есть, на пальцах, "размах"
 > отклонения
 >
 > суммарного времени падает за счет нивелирования выбросов.
 >
 > Это даёт следующую формулу:
 >
 >
 >
 > (ВРЕМЯ СБОРКИ СЛУЧАЙНО ВЫБРАННЫХ N src.rpm ПАКЕТОВ) <=
 >
 > 	N * (среднее + 2*сигма/sqrt(N))
 >
 > где
 >
 > 	среднее = 74 секунды
 >
 > 	сигма = 189 секунда
 >
 > неравенство выполняется с вероятностью около 90%.
 >
 >
 >
 > Прошу подписчиков листа обдумать это соображение. :)
т.е. для 1000 пакетов (область статисики) имеем ~ 74011 секунд или 20 
часов 33 минуты ? а для 6685 пакетов, находящихся в Сизифе около 5 
суток ? Ошибки  в расчётах нет ? 



-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] статистика

[Alexey Tourbin]

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

On Fri, Aug 24, 2007 at 01:08:26AM +0400, Хихин Руслан wrote:
>  > Прошу подписчиков листа обдумать это соображение. :)
> т.е. для 1000 пакетов (область статисики) имеем ~ 74011 секунд или 20 
> часов 33 минуты ? а для 6685 пакетов, находящихся в Сизифе около 5 
> суток ? Ошибки  в расчётах нет ? 

Это оценка сверху (с достаточно высокой надежностью на превышение).
Она справедлива для числа пакетов около 10-100, и для примерно такого
числа пакетов и предназначена.  Думаю, что это типичное число пакетов,
которые подлежат пересборке при прохождении в сизиф пакета, который
не входит в basesystem + rpm-build.  Впрочем, это следующая мини-задача,
которую предстоит решить.

При числе пакетов порядка 1000 формула уже дает надежность 97-98
процентов, то есть для прежней надежности в 95% время получается
немного завышенным.  Всё таки у нас далеко не нормальное распределение,
поэтому применимость "формулы трёх сигм" может быть ограниченной.

Впрочем, посмотрим на это вот как.  Среднее время сборки пакета
67 секунд.  Без заклада на надёжность получается 1000*67 секунд
т.е. 18-19 часов.  С закладом на надёжность вычисляем:
1000*(67+2*189/33) = 1000*(67+11.5) = 78500 = 22 часа.

Нетрудно видеть, что при увеличении числа пакетов "заклад на надёжность"
(по превышению времени) становится всё меньше.  Так, для 1000 пакетов
к 67 секундам на пакет сверх того добавляется всего 11.5 секунд.
То есть, конечно же, это формула асимптотически верна: при
большом числе пакетов "заклад на надёжность" падает и формула
сводится к значению (число_пакетов)*(среднее_время_сборки_пакета).

Увы, чудес не бывает.  Полная пересборка сизифа требует

$ cut -f2 buildtime |perl -MList::Util=sum -le 'print sum(<>)'
485274
$

секунд машинного времени, т.е. около

$ cut -f2 buildtime |perl -MList::Util=sum -le 'print sum(<>)/3600'
134.798333333333
$

135 часов.

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

Re: [devel] статистика

[Alexey Tourbin]

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

On Fri, Aug 24, 2007 at 01:47:42AM +0400, Alexey Tourbin wrote:
> При числе пакетов порядка 1000 формула уже дает надежность 97-98
> процентов, то есть для прежней надежности в 95% время получается
> немного завышенным.  Всё таки у нас далеко не нормальное распределение,
> поэтому применимость "формулы трёх сигм" может быть ограниченной.

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

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

Re: [devel] статистика

[Alexey Tourbin]

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

On Fri, Aug 24, 2007 at 01:47:42AM +0400, Alexey Tourbin wrote:
> Впрочем, посмотрим на это вот как.  Среднее время сборки пакета
> 67 секунд.  Без заклада на надёжность получается 1000*67 секунд

74 секунды.  Это я вспоминаю свой вчерашний результат который был
немного ошибочным из-за f-ing бага в одном скрипте.

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

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey Tourbin]

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

On Thu, Aug 23, 2007 at 02:52:25PM +0300, Michael Shigorin wrote:
> On Thu, Aug 23, 2007 at 02:18:40PM +0300, Mykola S. Grechukh wrote:
> > простейший пример - если пакетов qnetwalk поставить
> > Provides: kdelibs
> > Obsoletes: kdelibs
> > 
> > .. то старые списки покажут, что его никто не использует.
> > А на самом деле разломается сборка всего кдешного.
> 
> Я же написал -- "80%".  Инженер по качеству и полицейский с
> дубинкой -- немного разные роли, даже если и пересекающиеся.
> 
> С такими аргументами... от rm -rf в %post тоже никаких страховок
> нет, и по существу быть не может.

Это другая проблема.  Я сделал постановку задачи для своей пробемы.
Она примерно такая.  В сизиф собрался новый бинарный пакет (или
несколько пакетов из одного src.rpm пакета).  Теперь для каждого
src.rpm пакета нужно КАК БЫ инициализировать сборочный билдрут
и посмотреть, не встал ли в какой из этих билдрутов один из вновь
пришедших пакетов.  Если в билдрут для сборки src.rpm пакета встаёт
один из пришедших пакетов, то этот src.rpm пакет нужно тестировать
пересборкой.

(Соответственно, я играю в "игру" в рамках этой постновки задачи.
В других задачах будут другие подходы.  Они тоже есть.  legion
когда-то пытался сделать установку+удаление пакета и последующую
проверку чрута через osec.  Это надо будет со временем возродить,
или хотя бы понять, что там не склеилось.)

Всё дело, конечно, в том, что означает "КАК БЫ".  Реально
инициализировать билдрут для каждого src.rpm пакета это никаких
ресурсов не хватит.  Просто делать apt-get --print-uris, не доходя
до установки пакетов в билдрут, это порядка одной секунды на src.rpm
пакет.  Я сейчас утверждаю, что есть способ получить аутентичный
результат в 5 раз быстрее.

То что ты предлагаешь я делал 2 года назад.  Для каждого src.rpm пакета
хранится список пакетов билдрута от предыдущей его сборки.  То есть
таблица <pkg-name> <rpm-file-basename>.  (На самом деле достаточно
хранить только rpm-file-basename, потому что отрезанием
-version-release-*.rpm получается pkg-name).  Теперь достаточно
"гнепнуть" (join'ом) старые списки на предмет совпадения pkg-name
относительно прибывших пакетов.

Это не только не решает Provides+Obsolets, это не решает даже
виртуальных зависимостей.  Например пришёл пакет libstdc++4.2-devel.
Его в предыдущих списках нигде нет.  Значит, наша система "не
догадается" пересобрать приплюснутые пакеты.  Такое простое
опровержение <...>

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

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Michael Shigorin]

On Thu, Aug 23, 2007 at 04:19:40PM +0400, Alexey Tourbin wrote:
> То что ты предлагаешь я делал 2 года назад.  Для каждого
> src.rpm пакета хранится список пакетов билдрута от предыдущей
> его сборки.  То есть таблица <pkg-name> <rpm-file-basename>.
> (На самом деле достаточно хранить только rpm-file-basename,
> потому что отрезанием -version-release-*.rpm получается
> pkg-name).  Теперь достаточно "гнепнуть" (join'ом) старые
> списки на предмет совпадения pkg-name относительно прибывших
> пакетов.  Это не только не решает Provides+Obsolets, это не
> решает даже виртуальных зависимостей.

Хорошо, а инвалидировать такой кэш на основании сравнения
выдранных из пакета BR?

> Например пришёл пакет libstdc++4.2-devel.  Его в предыдущих
> списках нигде нет.  Значит, наша система "не догадается"
> пересобрать приплюснутые пакеты.  Такое простое опровержение

Согласен; хотя на такие варианты можно попробовать тоже найти
эвристику подешевле, чем --print-uris -- например,
^([a-zA-Z_+-]+)[0-9]+(\.[0-9]+)-devel или около того сводится 
к более общей сущности \1-devel, которая и проверяется на наличие 
в BR (или по /etc/buildreqs/packages/substitute.d/ -- хотя для
новой сборки записи ещё нет).

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

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

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey Tourbin]

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

On Thu, Aug 23, 2007 at 04:12:53PM +0300, Michael Shigorin wrote:
> On Thu, Aug 23, 2007 at 04:19:40PM +0400, Alexey Tourbin wrote:
> > То что ты предлагаешь я делал 2 года назад.  Для каждого
> > src.rpm пакета хранится список пакетов билдрута от предыдущей
> > его сборки.  То есть таблица <pkg-name> <rpm-file-basename>.
> > (На самом деле достаточно хранить только rpm-file-basename,
> > потому что отрезанием -version-release-*.rpm получается
> > pkg-name).  Теперь достаточно "гнепнуть" (join'ом) старые
> > списки на предмет совпадения pkg-name относительно прибывших
> > пакетов.  Это не только не решает Provides+Obsolets, это не
> > решает даже виртуальных зависимостей.
> 
> Хорошо, а инвалидировать такой кэш на основании сравнения
> выдранных из пакета BR?

Список BR оптимизируется, в этом есть свой смысл.
То есть то, реализовано в /usr/share/buildreqs/optimize_package_list
является не просто оптимизацией, но и "кристализующей" оптимизацией,
проясняющей "смысл понятия".  Например, библиотека lib1 может быть
собрана сначала с backend1, а позднее пересобрана с backend1.
Отсутствие backend1|backend2 в BR при наличии lib1 является БЛАГОМ.

К сожалению, в каких-то эзотерических терминах объяснение получается. :)

> > Например пришёл пакет libstdc++4.2-devel.  Его в предыдущих
> > списках нигде нет.  Значит, наша система "не догадается"
> > пересобрать приплюснутые пакеты.  Такое простое опровержение
> 
> Согласен; хотя на такие варианты можно попробовать тоже найти
> эвристику подешевле, чем --print-uris -- например,
> ^([a-zA-Z_+-]+)[0-9]+(\.[0-9]+)-devel или около того сводится 
> к более общей сущности \1-devel, которая и проверяется на наличие 
> в BR (или по /etc/buildreqs/packages/substitute.d/ -- хотя для
> новой сборки записи ещё нет).
> 
> Я к тому, что если решение задачи "в лоб" оказывается слишком
> дорогим, может иметь смысл разбавить решаемую задачу до 
> "в большинстве практических случаев".

Это не только тестирование для практических случаев.  У меня есть идея,
боюсь что я сейчас не смогу ее четко сформулировать без привлечения
эзотерики.  Смысл идеи в том, что каждый входящий пакет переводит
репозиторий из состояния1 в состояние2.  Переход является
транзакционным, то есть в момент перехода разница между состоянием1
и состоянием2 должна быть четко определена (а сам переход "фиксирует"
эту разницу).  Состояние, в частности, включает в себя статус
пересборки всех пакетов.  То, что мы сейчас обсуждаем, это "как
подешевле выяснить состояние2 в той его части, которая касается
пересобираемости пакетов".  То есть это мини-проблема при bottom-up
подходе.  Но решение ее должно быть надежным, иначе неопределенность
будет наслаиваться, и уже ничего нельзя будет утверждать наверняка.
Так, при переходе состояниеN->состояние(N+1) может выясниться, что
очередной пакет очень много всего сломал, тогда как поломка могла
случиться намного раньше, просто наши регулярные выражения дали сбой.

Другая часть фиксации состояния -- это, например, изменение количества
анметов.

В общем, после того, как пакет собрался в хешере, нужно для него
вычислить новое состояние, на основе целого ряда проверок, как минимум
пересборка и анметы.  Если новое состояние не хуже старого, тогда
фиксация проходит автоматически.  Если же оно является в чем-то хуже
старого, тогда требуется подтверждение или retract вручную, со стороны
maintainer'а пакета и/или со стороны "ответственного товарища".

То что "слишком дорого" это в конечно счете надо смотреть во сколько
это выльется по деньгам.  Прибедняться тоже не надо, кашу из топора
не сваришь, значит нужно обстоятельно прикинуть, чево и сколько хотелось
бы иметь.  И что это дает.  Я считаю что предварительное вычисление
состояния2 дает очень много -- по сути это разница между знанием и
невежеством, между высокой определенностью и высокой неопределенностью.

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

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [070824 15:18]:
> В общем, после того, как пакет собрался в хешере, нужно для него
> вычислить новое состояние, на основе целого ряда проверок, как минимум
> пересборка и анметы.  Если новое состояние не хуже старого, тогда
> фиксация проходит автоматически.  Если же оно является в чем-то хуже
> старого, тогда требуется подтверждение или retract вручную, со стороны
> maintainer'а пакета и/или со стороны "ответственного товарища".
Я так понимаю, пакеты будут собираться по одному, а не "пачками"
как раньше?  Поэтому ситуацию "libfoo с новым SONAME и несколько
зависимых от неё пакетов с исправлением совместимости" придётся
разруливать вручную "ответственному товарищу".  Ему не поплохеет?

Насколько сложнее проверять и пересобирать пакеты "пачками"?

-- 
Regards,
Sir Raorn.

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

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey Tourbin]

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

On Sat, Aug 25, 2007 at 01:15:39PM +0400, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [070824 15:18]:
> > В общем, после того, как пакет собрался в хешере, нужно для него
> > вычислить новое состояние, на основе целого ряда проверок, как минимум
> > пересборка и анметы.  Если новое состояние не хуже старого, тогда
> > фиксация проходит автоматически.  Если же оно является в чем-то хуже
> > старого, тогда требуется подтверждение или retract вручную, со стороны
> > maintainer'а пакета и/или со стороны "ответственного товарища".
> Я так понимаю, пакеты будут собираться по одному, а не "пачками"
> как раньше?  Поэтому ситуацию "libfoo с новым SONAME и несколько
> зависимых от неё пакетов с исправлением совместимости" придётся
> разруливать вручную "ответственному товарищу".  Ему не поплохеет?

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

Разруливать, по-моему, должен не столько товарищ, сколько maintainer.
То есть ему через несколько часов приходит письмо: "ой-ой-ой, вы
ДЕЙСТВИТЕЛЬНО хотите отправить это дело в сизиф"?  И maintainer
отвечает: "да-да-да, я знаю, исправленные пакеты почти готовы".

В принципе, наверное, ответственного товарища надо наделить правом вето,
если maintainer проголосует неправильно. :)  Но это уже политика...

> Насколько сложнее проверять и пересобирать пакеты "пачками"?

Наверное, если нужно провести сразу несколько пакетов в виде транзакции,
то наверное нужно предусмотреть специальную операцию "отправить на вход
группу пакетов".

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

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [070825 13:40]:
> Разруливать, по-моему, должен не столько товарищ, сколько maintainer.
> То есть ему через несколько часов приходит письмо: "ой-ой-ой, вы
> ДЕЙСТВИТЕЛЬНО хотите отправить это дело в сизиф"?  И maintainer
> отвечает: "да-да-да, я знаю, исправленные пакеты почти готовы".
Это АЦЦКИ медленно.  Вот, например, thresh@ залил новый FLAC со
сменой API и одновременно NMU на несколько зависимых пакетов.
Или либа с новым SONAME и compat пакет.  Если их перемещать по
одному, то будут новые unmet'ы в репозитарии и сломанная сборка.
Ждать ещё по несколько часов для каждого пакета?

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

-- 
Regards,
Sir Raorn.

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

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Igor Vlasenko]

On Sat, Aug 25, 2007 at 02:16:46PM +0400, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [070825 13:40]:
> > Разруливать, по-моему, должен не столько товарищ, сколько maintainer.
> > То есть ему через несколько часов приходит письмо: "ой-ой-ой, вы
> > ДЕЙСТВИТЕЛЬНО хотите отправить это дело в сизиф"?  И maintainer
> > отвечает: "да-да-да, я знаю, исправленные пакеты почти готовы".
> Это АЦЦКИ медленно.  Вот, например, thresh@ залил новый FLAC со
> сменой API и одновременно NMU на несколько зависимых пакетов.
> Или либа с новым SONAME и compat пакет.  Если их перемещать по
> одному, то будут новые unmet'ы в репозитарии и сломанная сборка.
> Ждать ещё по несколько часов для каждого пакета?

А у меня, как правило, типичными были транзакции из 15-30 java пакетов.
Они, кстати, часто не вписывались в окошко incoming --- 
напрашивается явное управление транзакциями.
что-то вроде 

$ touch begin_ldv
rsync begin_ldv incoming://
$ touch *.src.rpm
rsync *.src.rpm incoming://
$ touch commit_ldv
rsync commit_ldv incoming://
 

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Igor Vlasenko]

On Sat, Aug 25, 2007 at 02:25:20PM +0300, Igor Vlasenko wrote:
> On Sat, Aug 25, 2007 at 02:16:46PM +0400, Alexey I. Froloff wrote:
> > * Alexey Tourbin <at@> [070825 13:40]:
> > > Разруливать, по-моему, должен не столько товарищ, сколько maintainer.
> > > То есть ему через несколько часов приходит письмо: "ой-ой-ой, вы
> > > ДЕЙСТВИТЕЛЬНО хотите отправить это дело в сизиф"?  И maintainer
> > > отвечает: "да-да-да, я знаю, исправленные пакеты почти готовы".
> > Это АЦЦКИ медленно.  Вот, например, thresh@ залил новый FLAC со
> > сменой API и одновременно NMU на несколько зависимых пакетов.
> > Или либа с новым SONAME и compat пакет.  Если их перемещать по
> > одному, то будут новые unmet'ы в репозитарии и сломанная сборка.
> > Ждать ещё по несколько часов для каждого пакета?

> А у меня, как правило, типичными были транзакции из 15-30 java пакетов.
Т. е. что если первый пакет цепочки сборку пакета А ломает, а последний чинит (например, это новая версия А), 
то я эту цепочку едва за месяц залью.
Это если я каждый день для этого буду находить время :(

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

Можно, например, сделать так, для advanced случаев:
заливать при желании вместе с srpm-ами 
файлы со списками пакетов в каждой транзакции.
Заодно хинт incoming -- 
не трогать указанные пакеты, пока заливка не окончится.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Michael Shigorin]

On Sat, Aug 25, 2007 at 02:36:58PM +0300, Igor Vlasenko wrote:
> Можно, например, сделать так, для advanced случаев: заливать
> при желании вместе с srpm-ами файлы со списками пакетов в
> каждой транзакции.  Заодно хинт incoming -- не трогать
> указанные пакеты, пока заливка не окончится.

Игорь, это как раз решается сборкой из git.alt -- можно
понавливать изменений в репозитории хоть за неделю,
а потом пачкой запушить теги на сборку.

BTW обсуждалось в Обнинске, жаль, что тебя там не было.

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

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Mykola S. Grechukh]

2007/8/25, Michael Shigorin <mike@osdn.org.ua>:
> On Sat, Aug 25, 2007 at 02:36:58PM +0300, Igor Vlasenko wrote:
> > Можно, например, сделать так, для advanced случаев: заливать
> > при желании вместе с srpm-ами файлы со списками пакетов в
> > каждой транзакции.  Заодно хинт incoming -- не трогать
> > указанные пакеты, пока заливка не окончится.
>
> Игорь, это как раз решается сборкой из git.alt -- можно
> понавливать изменений в репозитории хоть за неделю,
> а потом пачкой запушить теги на сборку.

это только  "не трогать пока заливается". Но incominger все еще не
знает, что тестовая пересборка осмыслена только для всей пачки. Не по
timestamp же объединять в транзакции ?

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Igor Vlasenko]

On Sat, Aug 25, 2007 at 02:53:51PM +0300, Mykola S. Grechukh wrote:
> 2007/8/25, Michael Shigorin <mike@osdn.org.ua>:
> > On Sat, Aug 25, 2007 at 02:36:58PM +0300, Igor Vlasenko wrote:
> > > Можно, например, сделать так, для advanced случаев: заливать
> > > при желании вместе с srpm-ами файлы со списками пакетов в
> > > каждой транзакции.  Заодно хинт incoming -- не трогать
> > > указанные пакеты, пока заливка не окончится.
> >
> > Игорь, это как раз решается сборкой из git.alt -- можно
> > понавливать изменений в репозитории хоть за неделю,
> > а потом пачкой запушить теги на сборку.
> 
> это только  "не трогать пока заливается". Но incominger все еще не
> знает, что тестовая пересборка осмыслена только для всей пачки. Не по
> timestamp же объединять в транзакции ?

+1.

Кроме того, вспоминается классика.

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

У меня на 400 пакетов 25 git репозиториев,
Мясо на кости долго нарастает...
Если же найдутся люди с установкой
"Железной рукой загоним человечество к счастью",
боюсь, и та что есть скотина передохнет...


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey Tourbin]

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

On Sun, Aug 26, 2007 at 12:58:34AM +0300, Igor Vlasenko wrote:
> У меня на 400 пакетов 25 git репозиториев,
> Мясо на кости долго нарастает...
> Если же найдутся люди с установкой
> "Железной рукой загоним человечество к счастью",
> боюсь, и та что есть скотина передохнет...

Во-первых, не страдайте раньше времени.

Во-вторых, хочу спросить: как желание собирать пакеты пачкой связано
с последующей возможностью частичного ("точечного") обновления?
Влияет ли собираемость пакетов "пачкой" на их последующую
работоспособность пачкой/не пачкой?  Отражено ли это влияние в
зависимостях собранных пакетов?

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

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

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Igor Vlasenko]

On Sun, Aug 26, 2007 at 02:43:50AM +0400, Alexey Tourbin wrote:
> On Sun, Aug 26, 2007 at 12:58:34AM +0300, Igor Vlasenko wrote:
> > У меня на 400 пакетов 25 git репозиториев,
> > Мясо на кости долго нарастает...
> > Если же найдутся люди с установкой
> > "Железной рукой загоним человечество к счастью",
> > боюсь, и та что есть скотина передохнет...
> 
> Во-первых, не страдайте раньше времени.
Да я и в`о время страдать не хочу.
И призываю не заставлять других страдать.
 
> Во-вторых, хочу спросить: как желание собирать пакеты пачкой связано
> с последующей возможностью частичного ("точечного") обновления?

Здесь более общая проблема теории баз данных,
а именно транзакции против глобальных блокировок.

Если пакеты связаны цепочкой зависимостей, получается ступор.
Пример из жизни. 
Есть 2 цепочки зависящих друг от друга пакетов.
пакеты 1й цепочки 15 шт. -- новые версии, порождают unmets и зависят друг от друга.
пакеты 2й цепочки 15 шт. -- закрывают свои unmets, 
с патчами на новые API или исправленными Requires.

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

Основная проблема в 1й цепочке -- 
пусть на каждый 3-й пакет из 1й цепочки робот будет накладывать
блокировку и ее надо будет снимать вручную.

Итого пять раз придется вручную и в разные дни снимать блокировку, 
поскольку времени не хватает и возможность не всегда есть,
то это 5-7 дней бессмысленного простоя и бессмысленной работы :(

> Влияет ли собираемость пакетов "пачкой" на их последующую
> работоспособность пачкой/не пачкой?  Отражено ли это влияние в
> зависимостях собранных пакетов?

да. они связаны цепочкой зависимостей.

> это всё дело довольно подозрительное.

Это примеры не выдуманные, а скорее наболевшие и 
уже в печенках сидящие.
Например у меня что-то подобное происходит 
каждый раз, когда я меняю пакет java c altquirks на 
стандартный совместимый.

И без этих проверок incoming не успевает обрабатывать,
а тут вообще будет.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [070826 02:49]:
> Влияет ли собираемость пакетов "пачкой" на их последующую
> работоспособность пачкой/не пачкой?  Отражено ли это влияние в
> зависимостях собранных пакетов?
Самый распространённый случай - зависимость на SONAME некоей
библиотеки.

-- 
Regards,
Sir Raorn.

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

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey Tourbin]

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

On Sat, Aug 25, 2007 at 02:16:46PM +0400, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [070825 13:40]:
> > Разруливать, по-моему, должен не столько товарищ, сколько maintainer.
> > То есть ему через несколько часов приходит письмо: "ой-ой-ой, вы
> > ДЕЙСТВИТЕЛЬНО хотите отправить это дело в сизиф"?  И maintainer
> > отвечает: "да-да-да, я знаю, исправленные пакеты почти готовы".
> Это АЦЦКИ медленно.  Вот, например, thresh@ залил новый FLAC со
> сменой API и одновременно NMU на несколько зависимых пакетов.
> Или либа с новым SONAME и compat пакет.  Если их перемещать по
> одному, то будут новые unmet'ы в репозитарии и сломанная сборка.
> Ждать ещё по несколько часов для каждого пакета?

Я рассматриваю более пессимистическую ситуацию: maintainer направляет
новый пакет и НЕ ЗНАЕТ, как изменятся характеристики сизифа на этом
пакете.  Ответственный maintainer, который заранее подготовил NMU,
это хорошо, но технологичность должна подразумевать защиту от сбоев
по пессимистическому сценарию.

Опять же, я не против транзакции из нескольких пакетов, если все они
проводятся одним человеком.  Однако NMU настораживает.  Техника
получения NMU до конца не отработана.

Насчет "будет медленно" не очень согласен.  Входящий flac-*.src.rpm
сейчас "задевает" 161 пакет, включая те приложения в которых FLAC для
сборки по сути и не используется (а ставится только одна только
библиотека libflac).

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

Дело в том, что нужно уметь ответить на вопрос: КТО именно и ЗА СЧЕТ
ЧЕГО именно сломал ЭТОТ пакет (который перестал собираться).  Чем меньше
будет неопределенности, тем лучше (будет понятно, что нужно откатывать,
или хотя бы кого трясти).

С другой стороны, хотелось бы, конечно, обеспечивать атомарную смену
soname'ов в репозитарии.  Но при числе вовлеченных maintainer'ов больше
2-3 это становится проблемно...

Кстати смену soname'ов можно обнаруживать автоматически.  Просто нужно
сравнивать зависимости у пакетов, свежепротестированных пересборкой,
и уже собранных пакетов.

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

К сожалению, работа управдома для меня достаточно непрозрачна, и,
насколько я знаю, нигде на git.altlinux.org управдомовские скрипты
не публикуются.

Плюс есть ещё параллельные транзакции.  От них ЗЕЛО голова болит, я их
пока даже не обсуждал.  Грубо говоря, начиная говорить о транзакциях,
есть два подхода.  Первый подход -- каждый пакет собирается и
тестируется на логически "приватной копии" Сизифа.  То есть каждый
входящий src.rpm пакет берёт "длинный" read-lock на текущий сизиф, а
"сводильщик" будет работать в режиме writer starvation.  Другой крайний
вариант -- один большой общий отстойник для всех, который может
полностью или частично перемещаться в сизиф.  Кстати это не настолько
глупо, как может показаться с первого взгляда.  Промежуточный вариант --
изоляция на уровне maintainer'а.  Ну и что будет если при сведении
"сводильщик" обнаруживает пересечения, тоже непонятно.  Ладно, это уже
вопросы на более отдалённое будущее, когда основные проблемы будут
решены.

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

[devel] incominger

[Michael Shigorin]

On Sat, Aug 25, 2007 at 10:33:50PM +0400, Alexey Tourbin wrote:
> К сожалению, работа управдома для меня достаточно непрозрачна,
> и, насколько я знаю, нигде на git.altlinux.org управдомовские
> скрипты не публикуются.

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

Мне бы что-то для разгребания backports в (полу)автоматическом
режиме...

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

Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

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

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

On Sat, Aug 25, 2007 at 10:33:50PM +0400, Алексей Турбин wrote:

AT> Плюс есть ещё параллельные транзакции.  От них ЗЕЛО голова болит, я их
AT> пока даже не обсуждал.  Грубо говоря, начиная говорить о транзакциях,
AT> есть два подхода.  Первый подход -- каждый пакет собирается и
AT> тестируется на логически "приватной копии" Сизифа.  То есть каждый
AT> входящий src.rpm пакет берёт "длинный" read-lock на текущий сизиф, а
AT> "сводильщик" будет работать в режиме writer starvation.  Другой крайний
AT> вариант -- один большой общий отстойник для всех, который может
AT> полностью или частично перемещаться в сизиф.  Кстати это не настолько
AT> глупо, как может показаться с первого взгляда.  Промежуточный вариант --
AT> изоляция на уровне maintainer'а.  Ну и что будет если при сведении
AT> "сводильщик" обнаруживает пересечения, тоже непонятно.  Ладно, это уже
AT> вопросы на более отдалённое будущее, когда основные проблемы будут
AT> решены.

Между прочим я именно такой вариант (с общей предсизифовской сборочной
помойкой) и предлагал.

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

http://freesource.info
----------------------------------------------------------------------------
Миш, не нужно меня добавлять в СС ... мне хватит копии как QA :)
		-- legion in #8530

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

Re: [devel] RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey Tourbin]

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

On Thu, Aug 23, 2007 at 02:19:45PM +0400, Alexey Tourbin wrote:
> On Wed, Aug 22, 2007 at 01:43:21AM +0400, Alexey Tourbin wrote:
> > "Полную пересборку сизифа" следует трактовать не буквально, а вот как:
> > пересобрать все пакеты, у которых при сборке в билдрут ставится один из
> > новых пакетов.  Это означает, что, с учетом поступивших пакетов, для
> > каждого src.rpm пакета формируется список пакетов для билдрута.  Если в
> > списке пакетов для билдрута оказывается новый пакет, то этот src.rpm
> > пакет подлежит пересборке.
> 
> [...]
> 
> > Техническая проблема на подступах к определению списка пакетов, подлежащих
> > пересборке, было в том, что нужно научиться очень быстро строить список
> > пакетов в билдруте при сборке каждого src.rpm пакета.  Стандартный
> > способ (который используется в hasher, через --print-uris) занимает
> > порядка одной секунды на src.rpm пакет.  Это связано с тем, что apt всё
> > время перечитывает свой кеш.  В сизифе около 6000 src.rpm пакетов, значит,
> > определять, какие из них нужно пересобрать, можно около 2 часов.  Это
> > даже больше, чем может занять последующая пересборка обнаруженным таким
> > образом src.rpm пакетов.  У меня сейчас зреет решение, как немного
> > захачить апт и написать к нему скрипт на lua, чтобы построение списка
> > пакетов для пересборки по времени сводилось к чтению хедеров src.rpm
> > пакетов.
> 
> Я придумал решение (захачил апт, чтобы он не перечитывал кеш, написал
> скрипт на lua и кое-что ещё), при котором скорость --print-uris на моей
> машине сейчас около 5 src.rpm пакетов в секунду.  Получается всё равно
> достаточно много -- выяснять, какие из 6000 src.rpm пакетов нужно
> пересобирать, придётся минут 20.  Боюсь, что намного быстрее уже не
> получится.
> 
> Опубликую и напишу в ближайшее время.

git.alt:/people/at/packages/query-rebuild.git

Суть дела в следующем.

apt-get.cc модифицируется в двух местах.

1) Пишем обёртку для DoInstall и добавляем DoInstall в число функций,
доступных из lua скриптов:
@@ -3173,6 +3219,7 @@ bool DoScript(CommandLine &CmdL)
       _config->Set("Scripts::AptGet::Script::", *I);
 
    _lua->SetGlobal("commit_ask", 1);
+   _lua->SetGlobal("DoInstall", lua_DoInstall);
    _lua->RunScripts("Scripts::AptGet::Script");
    double Ask = _lua->GetGlobalNum("commit_ask");
    _lua->ResetGlobals();

2) Делаем так, чтобы DoInstall не перечитывал свой кеш.
Для этого вводится статическая локальная переменная.
@@ -1967,10 +1967,22 @@ bool DoUpgrade(CommandLine &CmdL)
 /* Install named packages */
 bool DoInstall(CommandLine &CmdL)
 {
+#if 1
+   static CacheFile *GCache = 0;
+   if (!GCache) {
+      GCache = new CacheFile;
+      if (GCache->OpenForInstall() == false)
+	 return false;
+   }
+   CacheFile &Cache = *GCache;
+   if (Cache.CheckDeps(CmdL.FileSize() != 1) == false)
+      return false;
+#else
    CacheFile Cache;
    if (Cache.OpenForInstall() == false || 
        Cache.CheckDeps(CmdL.FileSize() != 1) == false)
       return false;
+#endif
    
    // Enter the special broken fixing mode if the user specified arguments
    bool BrokenFix = false;

3) Пишется вспомогательный скрипт, который очень быстро "опрашивает"
BuildRequires пакетов, примерно так же, как это делается в hasher.
Формат вывода скрипта:
<src-rpm-basename> <deps>+
Суть скрипта такая

	deps=$(rpmquery -pR "$f") ||
		{ echo >&2 "${0##*/}: failed to query $f"; return 1; }
	deps="$(printf %s "$deps" |grep -v '^rpmlib(' |LC_ALL=C tr -d [[:blank:]])"
	[ -z "$deps" ] || printf "%s %s\n" "${f##*/}" "$(printf %s "$deps" |tr -s '[:space:]' ' ')"

Я написал полностью аналогичный скрипт на перле, который работает в 100
раз быстрее шелловского.

$ time ./query-pR.pl /ALT/Sisyphus/files/SRPMS >.pR      
./query-pR.pl /ALT/Sisyphus/files/SRPMS > .pR  3.53s user 1.38s system 79% cpu 6.170 total
$ head -2 .pR
7colors-0.80-alt5.src.rpm ORBit-devel XFree86-devel XFree86-libs esound-devel glib-devel gnome-libs-devel gtk+-devel imlib-devel libaudiofile-devel libdb1-devel xpm-devel
a2ps-4.13-alt3.src.rpm ImageMagick flex ghostscript-common ghostscript-utils groff-base gv gzip-utils psutils tetex-core tetex-dvips tetex-latex xorg-x11-devel
$

4) Пишется скрипт print-uris.lua который будет вызывать DoInstall и
вычислять содержимое билдрута для каждого src.rpm пакета (из предыдущего
файла .pR, который будет подключен к stdin).  Суть скрипта в следущем:

	print_uris("basesystem", {"basesystem"}) -- initialize cache
	print_uris("rpm-build", {"rpm-build"})

Теперь в аптовском кеше сидит "установленный" basesystem+rpm-build.
На каждый src.rpm пакет lua будет форкаться (чтобы сохранить кеш).

	for line in io.lines() do
		...
		fork_print_uris(rpm, deps)
	end

В вывод print_uris добавлены строчки-маркеры BEGIN и END.
Вот как это работает.

$ hsh --init $TMPDIR/build
$ chmod -w $TMPDIR/build/aptbox/var/lib/rpm		# НУЖЕН ЧМОД
$ ls ./apt-get
./apt-get						# МОДИФИЦИРОВАННЫЙ
$ PATH=$PWD:$PATH $TMPDIR/build/aptbox/apt-get -qq -y script ./print-uris.lua <.pR
BEGIN basesystem
END basesystem true
BEGIN rpm-build
END rpm-build true
BEGIN 7colors-0.80-alt5.src.rpm
'file:/ALT/Sisyphus/i586/RPMS.classic/glib-1.2.10-alt12.i586.rpm' glib_1.2.10-alt12_i586.rpm 81314 6cb31aaa2875a1f0d0768d1435a4a435
'file:/ALT/Sisyphus/i586/RPMS.classic/libORBit-0.5.17-alt3.i586.rpm' libORBit_0.5.17-alt3_i586.rpm 169128 1097a7e5b1ccaa786e27271b7155be1a
'file:/ALT/Sisyphus/i586/RPMS.classic/ORBit-0.5.17-alt3.i586.rpm' ORBit_0.5.17-alt3_i586.rpm 127941 5f49b6b61338887fed13f2de967c00fe
'file:/ALT/Sisyphus/i586/RPMS.classic/libfontenc-1.0.4-alt1.i586.rpm' libfontenc_1.0.4-alt1_i586.rpm 13013 d5d031c9741e3de1e08b2dcd21dd26a5
'file:/ALT/Sisyphus/i586/RPMS.classic/libfreetype-2.3.5-alt2.i586.rpm' libfreetype_2.3.5-alt2_i586.rpm 315157 7447bc73a08199e18da1c49dad5fd21
...
END 7colors-0.80-alt5.src.rpm true
BEGIN a2ps-4.13-alt3.src.rpm
'file:/ALT/Sisyphus/i586/RPMS.classic/libfontenc-1.0.4-alt1.i586.rpm' libfontenc_1.0.4-alt1_i586.rpm 13013 d5d031c9741e3de1e08b2dcd21dd26a5
'file:/ALT/Sisyphus/i586/RPMS.classic/libfreetype-2.3.5-alt2.i586.rpm' libfreetype_2.3.5-alt2_i586.rpm 315157 7447bc73a08199e18da1c49dad5fd21
...
END a2ps-4.13-alt3.src.rpm true
BEGIN a52dec-0.7.4-alt5.src.rpm
END a52dec-0.7.4-alt5.src.rpm true
BEGIN aalib-1.4-alt2rc5.src.rpm
'file:/ALT/Sisyphus/i586/RPMS.classic/libX11-locales-1.1.3-alt3.i586.rpm' libX11-locales_3%3a1.1.3-alt3_i586.rpm 186817 19f61bc3fbf7c8248e43287d8ac653e1
'file:/ALT/Sisyphus/i586/RPMS.classic/libgpm-devel-1.20.1-alt8.i586.rpm' libgpm-devel_1.20.1-alt8_i586.rpm 11727 016186297ea138acd158f8ccd4b95347
...
END aalib-1.4-alt2rc5.src.rpm true
BEGIN abinit-4.6.5-alt1.src.rpm
...
$

То есть это обычный вывод apt-get install --print-uris, только сделанный
в цикле и дополненный маркерами 
	BEGIN <src-rpm-basename>
	END <src-rpm-basename> <true|false>

5) Теперь этот вывод несложно обработать скриптом print-uris-filter.awk,
чтобы на выходе получить таблицу
<src-rpm-basename> <inst-rpm-basename>
Эта таблица означает, что для src.rpm пакета <src-rpm-basename>
в билдрут будет ставиться собранный rpm пакет <inst-rpm-basename>.

$ head .pR >.pR1
$ PATH=$PWD:$PATH $TMPDIR/build/aptbox/apt-get -qq -y script ./print-uris.lua <.pR1 >.uris
$ awk -f ./print-uris-filter.awk .uris |head    
7colors-0.80-alt5.src.rpm       glib-1.2.10-alt12.i586.rpm
7colors-0.80-alt5.src.rpm       libORBit-0.5.17-alt3.i586.rpm
7colors-0.80-alt5.src.rpm       ORBit-0.5.17-alt3.i586.rpm
7colors-0.80-alt5.src.rpm       libfontenc-1.0.4-alt1.i586.rpm
7colors-0.80-alt5.src.rpm       libfreetype-2.3.5-alt2.i586.rpm
7colors-0.80-alt5.src.rpm       libXfont-1.2.8-alt2.i586.rpm
7colors-0.80-alt5.src.rpm       bdftopcf-1.0.1-alt1.i586.rpm
7colors-0.80-alt5.src.rpm       libdb1-1.85-alt5.i586.rpm
7colors-0.80-alt5.src.rpm       db1-utils-1.85-alt5.i586.rpm
7colors-0.80-alt5.src.rpm       libaudiofile-0.2.6-alt2.i586.rpm
$ awk -f ./print-uris-filter.awk .uris |sort -u -k1,1
7colors-0.80-alt5.src.rpm       glib-1.2.10-alt12.i586.rpm
a2ps-4.13-alt3.src.rpm  libfontenc-1.0.4-alt1.i586.rpm
aalib-1.4-alt2rc5.src.rpm       libX11-locales-1.1.3-alt3.i586.rpm
abinit-4.6.5-alt1.src.rpm       gcc-fortran-common-1.4.10-alt2.i586.rpm
abiword-2.4.6-alt2.src.rpm      libIDL-0.8.8-alt1.i586.rpm
abook-0.5.6-alt1.src.rpm        libtinfo-devel-5.6-alt3.i586.rpm
abuse_sdl-0.7.0-alt4.src.rpm    ca-certificates-2007.02.06-alt1.noarch.rpm
acidrip-0.14-alt1.src.rpm       ca-certificates-2007.02.06-alt1.noarch.rpm
acl-2.2.39-alt1.0.src.rpm       libattr-devel-2.4.32-alt1.0.i586.rpm
$

Теперь задача почти решена.  Мы имеем вновь пришедшие пакеты
<inst-rpm-basename>, и хотим узнать, какие <src-rpm-basename>
подлежат пересборке.  Это тривиальный join по этой таблице.

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

Re: [devel] RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey Tourbin]

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

On Thu, Aug 23, 2007 at 05:23:04PM +0400, Alexey Tourbin wrote:
> $ PATH=$PWD:$PATH $TMPDIR/build/aptbox/apt-get -qq -y script ./print-uris.lua <.pR
> BEGIN basesystem
> END basesystem true
> BEGIN rpm-build
> END rpm-build true
> BEGIN 7colors-0.80-alt5.src.rpm
> 'file:/ALT/Sisyphus/i586/RPMS.classic/glib-1.2.10-alt12.i586.rpm' glib_1.2.10-alt12_i586.rpm 81314 6cb31aaa2875a1f0d0768d1435a4a435
> 'file:/ALT/Sisyphus/i586/RPMS.classic/libORBit-0.5.17-alt3.i586.rpm' libORBit_0.5.17-alt3_i586.rpm 169128 1097a7e5b1ccaa786e27271b7155be1a
> 'file:/ALT/Sisyphus/i586/RPMS.classic/ORBit-0.5.17-alt3.i586.rpm' ORBit_0.5.17-alt3_i586.rpm 127941 5f49b6b61338887fed13f2de967c00fe
> 'file:/ALT/Sisyphus/i586/RPMS.classic/libfontenc-1.0.4-alt1.i586.rpm' libfontenc_1.0.4-alt1_i586.rpm 13013 d5d031c9741e3de1e08b2dcd21dd26a5
> 'file:/ALT/Sisyphus/i586/RPMS.classic/libfreetype-2.3.5-alt2.i586.rpm' libfreetype_2.3.5-alt2_i586.rpm 315157 7447bc73a08199e18da1c49dad5fd21
> ...
> END 7colors-0.80-alt5.src.rpm true
> BEGIN a2ps-4.13-alt3.src.rpm
> 'file:/ALT/Sisyphus/i586/RPMS.classic/libfontenc-1.0.4-alt1.i586.rpm' libfontenc_1.0.4-alt1_i586.rpm 13013 d5d031c9741e3de1e08b2dcd21dd26a5
> 'file:/ALT/Sisyphus/i586/RPMS.classic/libfreetype-2.3.5-alt2.i586.rpm' libfreetype_2.3.5-alt2_i586.rpm 315157 7447bc73a08199e18da1c49dad5fd21
> ...
> END a2ps-4.13-alt3.src.rpm true
> BEGIN a52dec-0.7.4-alt5.src.rpm
> END a52dec-0.7.4-alt5.src.rpm true
> BEGIN aalib-1.4-alt2rc5.src.rpm
> 'file:/ALT/Sisyphus/i586/RPMS.classic/libX11-locales-1.1.3-alt3.i586.rpm' libX11-locales_3%3a1.1.3-alt3_i586.rpm 186817 19f61bc3fbf7c8248e43287d8ac653e1
> 'file:/ALT/Sisyphus/i586/RPMS.classic/libgpm-devel-1.20.1-alt8.i586.rpm' libgpm-devel_1.20.1-alt8_i586.rpm 11727 016186297ea138acd158f8ccd4b95347
> ...
> END aalib-1.4-alt2rc5.src.rpm true
> BEGIN abinit-4.6.5-alt1.src.rpm
> ...
> $

На машине mash.office полное вычисление print-uris занимает 37 минут.

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

[devel] статистика [2]

[Alexey Tourbin]

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

On Thu, Aug 23, 2007 at 05:23:04PM +0400, Alexey Tourbin wrote:
> 5) Теперь этот вывод несложно обработать скриптом print-uris-filter.awk,
> чтобы на выходе получить таблицу
> <src-rpm-basename> <inst-rpm-basename>
> Эта таблица означает, что для src.rpm пакета <src-rpm-basename>
> в билдрут будет ставиться собранный rpm пакет <inst-rpm-basename>.
> 
> $ head .pR >.pR1
> $ PATH=$PWD:$PATH $TMPDIR/build/aptbox/apt-get -qq -y script ./print-uris.lua <.pR1 >.uris
> $ awk -f ./print-uris-filter.awk .uris |head    
> 7colors-0.80-alt5.src.rpm       glib-1.2.10-alt12.i586.rpm
> 7colors-0.80-alt5.src.rpm       libORBit-0.5.17-alt3.i586.rpm
> 7colors-0.80-alt5.src.rpm       ORBit-0.5.17-alt3.i586.rpm
> 7colors-0.80-alt5.src.rpm       libfontenc-1.0.4-alt1.i586.rpm
> 7colors-0.80-alt5.src.rpm       libfreetype-2.3.5-alt2.i586.rpm
> 7colors-0.80-alt5.src.rpm       libXfont-1.2.8-alt2.i586.rpm
> 7colors-0.80-alt5.src.rpm       bdftopcf-1.0.1-alt1.i586.rpm
> 7colors-0.80-alt5.src.rpm       libdb1-1.85-alt5.i586.rpm
> 7colors-0.80-alt5.src.rpm       db1-utils-1.85-alt5.i586.rpm
> 7colors-0.80-alt5.src.rpm       libaudiofile-0.2.6-alt2.i586.rpm
> $ awk -f ./print-uris-filter.awk .uris |sort -u -k1,1
> 7colors-0.80-alt5.src.rpm       glib-1.2.10-alt12.i586.rpm
> a2ps-4.13-alt3.src.rpm  libfontenc-1.0.4-alt1.i586.rpm
> aalib-1.4-alt2rc5.src.rpm       libX11-locales-1.1.3-alt3.i586.rpm
> abinit-4.6.5-alt1.src.rpm       gcc-fortran-common-1.4.10-alt2.i586.rpm
> abiword-2.4.6-alt2.src.rpm      libIDL-0.8.8-alt1.i586.rpm
> abook-0.5.6-alt1.src.rpm        libtinfo-devel-5.6-alt3.i586.rpm
> abuse_sdl-0.7.0-alt4.src.rpm    ca-certificates-2007.02.06-alt1.noarch.rpm
> acidrip-0.14-alt1.src.rpm       ca-certificates-2007.02.06-alt1.noarch.rpm
> acl-2.2.39-alt1.0.src.rpm       libattr-devel-2.4.32-alt1.0.i586.rpm
> $
> 
> Теперь задача почти решена.  Мы имеем вновь пришедшие пакеты
> <inst-rpm-basename>, и хотим узнать, какие <src-rpm-basename>
> подлежат пересборке.  Это тривиальный join по этой таблице.

Займемся теперь вопросом, сколько же сизифовских пакетов придётся
тестировать пересборкой на каждый входящий src.rpm пакет.  У меня
есть полная таблица, кусочек которой приведен выше.  Введу новое
обозначение для полей таблицы:
	<test-src-rpm-basename> <incoming-rpm-basename>
Это означает, что собравшийся в incoming'е пакет <incoming-rpm-basename>,
оказывается, встает в чрут для сборки <test-src-rpm-basename>.  Значит,
вследствие прохождения <incoming-rpm-basename> нужно протестировать
пересборкой <test-src-rpm-basename>.

Я дополнил эту таблицу ещё одним полем:
	<test-src-rpm-basename> <incoming-rpm-basename> <incoming-src-rpm-basename>

Последнее поле означает, какой src.rpm пакет собрался в incoming'е.
Это нужно для того, чтобы учитывать, что из одного src.rpm пакета
при сборке в среднем получается больше одного установочного пакета,
которые будут вставать в чрут.  Это не должно искажать статистики.

Я выложил эту таблицу сюда (952K):
ftp://ftp.altlinux.org/pub/people/at/rebuild-map.bz2

Вот несколько случайных строчек этой таблицы:

$ perl -MList::Util=shuffle -e 'print +(shuffle<>)[1..10]' <rebuild-map 
qmmp-0.1.3.1-alt1.src.rpm	libxkbfile-devel-1.0.4-alt1.i586.rpm	libxkbfile-1.0.4-alt1.src.rpm
emacs-apel-10.6-alt1.20050606.src.rpm	emacs-devel-0.0.1-alt3.noarch.rpm	emacs-devel-0.0.1-alt3.src.rpm
kde-styles-klearlook-0.9.9.2-alt1.1.src.rpm	libXmu-devel-1.0.3-alt1.i586.rpm	libXmu-1.0.3-alt1.src.rpm
k3b-i18n-full-1.0.3-alt3.src.rpm	gccmakedep-1.0.1-alt1.i586.rpm	gccmakedep-1.0.1-alt1.src.rpm
grip-3.1.3-alt5.src.rpm	libjpeg-6b-alt8.i586.rpm	libjpeg-6b-alt8.src.rpm
wmmemload-0.1.6-alt3.src.rpm	libXext-1.0.3-alt1.i586.rpm	libXext-1.0.3-alt1.src.rpm
xfce4-panel-4.4.1-alt2.src.rpm	libfreetype-devel-2.3.5-alt2.i586.rpm	libfreetype-2.3.5-alt2.src.rpm
mysql-gui-tools-5.0r12-alt1.src.rpm	libXp-1.0.0-alt3.0.i586.rpm	libXp-1.0.0-alt3.0.src.rpm
tracker-0.6.0-alt0.1.src.rpm	libpoppler-glib-devel-0.5.4-alt6.i586.rpm	poppler-0.5.4-alt6.src.rpm
showfont-1.0.1-alt1.src.rpm	libFS-1.0.0-alt2.i586.rpm	libFS-1.0.0-alt2.src.rpm
$

Замечу, что эту таблицу нужно читать в обратном порядке, справа налево:
"пришёл пакет libxkbfile-*.src.rpm, из него собрался пакет libxkbfile-devel-*.i586.rpm,
из-за чего придётся протестировать пересборкой qmmp-*.src.rpm" и т.д.

Среднее поле в таблице на самом деле оказывается не слишком нужным,
я его удалю:

$ cut -f1,3 rebuild-map |sort -u -k2,2 -k1,1 >.ss
$ perl -MList::Util=shuffle -e 'print +(shuffle<>)[1..10]' <.ss
lprof-1.11.4.1-alt1.src.rpm	libxml2-2.6.29-alt2.src.rpm
$

"Пришел пакет libxml2-*.src.rpm, требуется протестировать пересборкой lprof-*.src.rpm".

Теперь несложно для каждого входящего пакета в incoming (справа)
вычислить число src.rpm пакетов (слева), подлежащих пересборке.

$ uniq -c -f1 .ss |head -1
144 alt-docs-main-0.4-alt7.src.rpm  ALDConvert-0.05-alt8.src.rpm
$

Здесь alt-docs-main это просто первый пакет, который попался и поэтому
остался, суть в том, что пакет ALDConvert-*.src.rpm на входе, если он
конечно соберётся, потребует протестировать пересборкой 144 пакетов.

Я теперь сделаю совсем уж интуитивно понятную таблицу
	<incoming-src-rpm-basename> <rebuild-number-src-rpm>

$ uniq -c -f1 .ss |awk '{print$3"\t"$1}' |sort -k2,2n >.sz
$ head -2 .sz
GraphicsMagick-1.1.8-alt1.src.rpm       1
MySQL41-4.1.21-alt5.1.src.rpm   1
$ tail .sz   
libSM-1.0.3-alt1.src.rpm        1952
libICE-1.0.4-alt1.src.rpm       1962
fontconfig-2.4.2-alt3.src.rpm   2120
libXext-1.0.3-alt1.src.rpm      2196
libfreetype-2.3.5-alt2.src.rpm  2203
gcc4.1-4.1.1-alt11.src.rpm      2365
libXau-1.0.3-alt1.src.rpm       2388
libXdmcp-1.0.2-alt1.0.src.rpm   2389
libX11-1.1.3-alt3.src.rpm       2392
expat-2.0.1-alt0.1.src.rpm      2646
$

Видим, что GraphicsMagick на входе потребует пересборки всего одного
src.rpm пакета (кстати, это koffice), а expat на входе потребует
пересобрать уже 2646 src.rpm пакетов.  Всего сейчас в репозитарии 6687
src.rpm пакетов (с точки зрения этой статистики).

ЗДЕСЬ НЕ УЧИТЫВАЮТСЯ ИЗМЕНЕНИЯ В basesystem + rpm-build.
Любой пакет, который попадает в basesystem + rpm-build, потребует,
по идее, полной пересборки сизифа, и этот случай я сейчас специально
отсёк.  Никакой другой пакет, однако, не может зацепить для пересборки
даже и половину сизифа.

Я пока объявляю пакеты из basesystem + rpm-build частным случаем, который
в данной статистике не рассматривается.

Сколько же всего имеется "входных" src.rpm пакетов, которые могут
потребовать пересборку чего-либо?

$ wc -l <.sz
2261
$

Это означает, что ТОЛЬКО КАЖДЫЙ ТРЕТИЙ ПАКЕТ просит что-то пересобрать.
Большая половина пакетов являются "листьями" ("приложениями") и заведомо
не влияют на собираемость каких-либо других пакетов.

Значит, будем считать среднее количество пакетов на пересборку для
"каждого третьего" пакета, а на каком-то этапе результат просто поделим
результат на три.  С точки зрения мат. статистики это, наверное, не
совсем правильно, то для грубой оценки сойдет.

Итак, распределение числа пакетов, подлежащих пересборке.
Среднее значение значение 78 пакетов, медиана распределения
5 пакетов, сигма 253 пакета.  Как и со временем сборки пакетов,
получилось распределение с маленьким средним значением и большой
сигмой.  Значит, говорить об "единичном случае" не серьезно,
нужно считать значения для серии пакетов.

Прежде всего однако прикинем порядок среднего значения.
78 пакетов * 74 секунды это порядка 100 минут.

Рационально считать время сборки для серии из 25 входящих src.rpm
пакетов.  Это очень грубо означает, что мы закладываемся на "суточную
норму", и неудачные последовательности входящих пакетов с достаточно
высокой надежностью не должны выбрасывать нас за пределы суток.

Прежняя формула для "достаточно надёжного заклада" говорит:
	P( xi(N) <= N*(mu+2*sigma/sqrt(N) ) >= 0.95

В данном случае xi(N) -- суммарное число src.rpm пакетов, подлежащих
пересборке на серии из N входящих пакетов, N=25; mu=78 пакетов,
sigma=253 пакета.

Вычислим член mu+2*sigma/sqrt(N), он даёт "среднее по выборке из 25"
с надёжностью 95% на превышение суммарного времени.

$ perl -le 'print 78+2*253/5'
179.2
$

Значит, чтобы нас не шатало "по суточной норме", вместо среднего
значения 78 пакетов нужно брать с запасом 179 пакетов.

Сколько времени будут собираться 179 пакетов?  Из предыдущего письма
известно, что t(N) = N*(74+2*189/sqrt(N));
t(179) = 18303 секунды = 5 часов.

Итого, каждый третий входящий src.rpm пакет с вероятностью 95%
уложится на пересборочном тестировании в 5 часов; это усреднение
по 25 входящим пакетам.  То есть на самом деле утверждение состоит
в том, что 25 входящих src.rpm с вероятностью около 95% уложатся
в 25*5=125 часов.

Среднее же время без "суточной надёжности" составляет, как уже
посчитано, 78 пакетов на пересборку * 74 секунды = 100 минут.
ЭТО ОЗНАЧАЕТ, ЧТО СРЕДНЯЯ ЗАГРУЗКА СЕРВЕРОВ на большом промежутке
времени (допустим, месяц) составит 100 минут/25 часов = 7%.
(Имеется в виду загрузка только на пересборочном тестировании.)
Запас серверной мощности, нужен, по сути, для того, чтобы "неудачная
последовательность входящих пакетов" не заставляла нас слишком долго
ждать.

Настало время поделить на 3.  Подумаем, насколько это корректно.
Мы исходили из того, что все входящие пакеты подряд требуют что-то
пересобрать.  Теперь они будут "перемешиваться" с пакетами, которые
пересобрать ничего не требуют.  Значит, это не должно ухудшить
показателя за счёт каких-либо выбросов.

ИТОГО, 5 часов/3 = 100 минут.
ОТВЕТ: на серии из N пакетов, где N порядка 25, суммарное время
пересборочного тестирования с вероятностью 95% не превысит N*100 минут.

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

Теперь настало время понять, чем статистика отличается от наглой лжи.
Ведь если пришёл пакет expat, то придётся ждать 54 часа, что на порядок
больше 5 часов и, похоже, выбрасывает нас за суточную норму.  Просто
expat выбивается за пределы 95-процентной надёжности.  Но в этом году
пакет expat был собран всего один раз.  То есть при случайном
поступлении пакетов появление expat это очень редкое событие.
Придётся подождать.

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

[devel] Критерий значимости пакета (Was: статистика)

[Alexey Rusakov]

Я позволю себе заговорить независимо чуток на другую тему, которая,
благодаря at@, получила продолжение.

On Sat, 25 Aug 2007 01:23:57 +0400
Alexey Tourbin wrote:

> Займемся теперь вопросом, сколько же сизифовских пакетов придётся
> тестировать пересборкой на каждый входящий src.rpm пакет.  У меня
> есть полная таблица, кусочек которой приведен выше.  Введу новое
> обозначение для полей таблицы:
> 	<test-src-rpm-basename> <incoming-rpm-basename>
> Это означает, что собравшийся в incoming'е пакет <incoming-rpm-basename>,
> оказывается, встает в чрут для сборки <test-src-rpm-basename>.  Значит,
> вследствие прохождения <incoming-rpm-basename> нужно протестировать
> пересборкой <test-src-rpm-basename>.
> 
> Я дополнил эту таблицу ещё одним полем:
> 	<test-src-rpm-basename> <incoming-rpm-basename> <incoming-src-rpm-basename>
> 
> Последнее поле означает, какой src.rpm пакет собрался в incoming'е.
> Это нужно для того, чтобы учитывать, что из одного src.rpm пакета
> при сборке в среднем получается больше одного установочного пакета,
> которые будут вставать в чрут.  Это не должно искажать статистики.
> 
> Я выложил эту таблицу сюда (952K):
> ftp://ftp.altlinux.org/pub/people/at/rebuild-map.bz2
> 
[...]
> Я теперь сделаю совсем уж интуитивно понятную таблицу
> 	<incoming-src-rpm-basename> <rebuild-number-src-rpm>
> 
> $ uniq -c -f1 .ss |awk '{print$3"\t"$1}' |sort -k2,2n >.sz
> $ head -2 .sz
> GraphicsMagick-1.1.8-alt1.src.rpm       1
> MySQL41-4.1.21-alt5.1.src.rpm   1
> $ tail .sz   
> libSM-1.0.3-alt1.src.rpm        1952
> libICE-1.0.4-alt1.src.rpm       1962
> fontconfig-2.4.2-alt3.src.rpm   2120
> libXext-1.0.3-alt1.src.rpm      2196
> libfreetype-2.3.5-alt2.src.rpm  2203
> gcc4.1-4.1.1-alt11.src.rpm      2365
> libXau-1.0.3-alt1.src.rpm       2388
> libXdmcp-1.0.2-alt1.0.src.rpm   2389
> libX11-1.1.3-alt3.src.rpm       2392
> expat-2.0.1-alt0.1.src.rpm      2646
> $
> 
> Видим, что GraphicsMagick на входе потребует пересборки всего одного
> src.rpm пакета (кстати, это koffice), а expat на входе потребует
> пересобрать уже 2646 src.rpm пакетов.  Всего сейчас в репозитарии 6687
> src.rpm пакетов (с точки зрения этой статистики).
> 
> ЗДЕСЬ НЕ УЧИТЫВАЮТСЯ ИЗМЕНЕНИЯ В basesystem + rpm-build.
> Любой пакет, который попадает в basesystem + rpm-build, потребует,
> по идее, полной пересборки сизифа, и этот случай я сейчас специально
> отсёк.  Никакой другой пакет, однако, не может зацепить для пересборки
> даже и половину сизифа.
В своё время, ещё в конце прошлого года, обсуждалась тема критерия
заморозки Сизифа. Я и mithraen@ более-менее независимо толкнули идею о
том, что замораживать Сизиф можно с разной "глубиной", основываясь на том,
какие пакеты насколько "значимы" для репозитория. В первом приближении
в качестве критерия значимости предлагалось учитывать количество
зависимостей от этого пакета. В частности, говорилось следующее:

On Tue, 2 Jan 2007 15:54:24 +0300
Денис Смирнов wrote:

> On Sun, Dec 31, 2006 at 07:37:45PM +0300, Alexey Rusakov wrote:
> 
> AR> А возможно определить формальную величину "значимости" пакета через 
> AR> количество зависящих от него пакетов? Неоднозначные зависимости можно 
> AR> учитывать либо через коэффициент < 1, либо учитывать все возможноые 
> AR> варианты. Если мы сможем определить такую величину, то дальше можно 
> AR> устанавливать этапы, замораживая пакеты со "значимостью" больше, чем 
> AR> некоторая очередная величина. Подход, конечно, наивный, но в качестве 
> AR> первого приближения почему бы и нет.
> 
> Когда-то я ровно это и предлагал. Вопрос лишь в том как правильно
> отрабатывать нечеткие зависимости (с >= %version, например)?
> 
> Так как эта задача не требует абсолютно точного результата, то можно все
> нечеткие зависимости представлять себе как самые что ни на есть четкие.
> Тогда можно получить вполне осмысленный результат за разумное время.

Так вот, по-моему, приведённый at@ метод, в качестве побочного эффекта,
даёт такой критерий, причём в более удачной формулировке, чем высказанная раньше.

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

Re: [devel] Критерий значимости пакета (Was: статистика)

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

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

On Sat, Aug 25, 2007 at 06:57:28PM +0400, Alexey Rusakov wrote:

>> Когда-то я ровно это и предлагал. Вопрос лишь в том как правильно
>> отрабатывать нечеткие зависимости (с >= %version, например)?
>> Так как эта задача не требует абсолютно точного результата, то можно все
>> нечеткие зависимости представлять себе как самые что ни на есть четкие.
>> Тогда можно получить вполне осмысленный результат за разумное время.
AR> Так вот, по-моему, приведённый at@ метод, в качестве побочного эффекта,
AR> даёт такой критерий, причём в более удачной формулировке, чем высказанная раньше.

Метод разрабатываемый at@ позволяет решить _одну из_ проблем, которые я
перед собой ставил. Правда более эффективным способом.

Меня ещё волновала реальная устанавливаемость, а это отдельная тема.

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

http://freesource.info
----------------------------------------------------------------------------
С каких это пор запрещается желать странного?
		-- slava in devel@

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

Re: [devel] Критерий значимости пакета (Was: статистика)

[Alexey Tourbin]

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

On Sun, Aug 26, 2007 at 12:10:35AM +0400, Денис Смирнов wrote:
> >> Когда-то я ровно это и предлагал. Вопрос лишь в том как правильно
> >> отрабатывать нечеткие зависимости (с >= %version, например)?
> >> Так как эта задача не требует абсолютно точного результата, то можно все
> >> нечеткие зависимости представлять себе как самые что ни на есть четкие.
> >> Тогда можно получить вполне осмысленный результат за разумное время.
> AR> Так вот, по-моему, приведённый at@ метод, в качестве побочного эффекта,
> AR> даёт такой критерий, причём в более удачной формулировке, чем высказанная раньше.
> 
> Метод разрабатываемый at@ позволяет решить _одну из_ проблем, которые я
> перед собой ставил. Правда более эффективным способом.
> 
> Меня ещё волновала реальная устанавливаемость, а это отдельная тема.

Реальную устанавливаемость можно проверить этим же методом,
просто написать другой скрипт на lua.

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

Re: [devel] Критерий значимости пакета (Was: статистика)

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

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

On Sun, Aug 26, 2007 at 12:28:58AM +0400, Алексей Турбин wrote:

>> Метод разрабатываемый at@ позволяет решить _одну из_ проблем, которые я
>> перед собой ставил. Правда более эффективным способом.
>> Меня ещё волновала реальная устанавливаемость, а это отдельная тема.
AT> Реальную устанавливаемость можно проверить этим же методом,
AT> просто написать другой скрипт на lua.

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

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

http://freesource.info
----------------------------------------------------------------------------
Это в спеке притаился define.
		-- pilot in #7092

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

Re: [devel] Критерий значимости пакета (Was: статистика)

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 2866 bytes --]

On Sun, Aug 26, 2007 at 02:47:13AM +0400, Денис Смирнов wrote:
> On Sun, Aug 26, 2007 at 12:28:58AM +0400, Алексей Турбин wrote:
> 
> >> Метод разрабатываемый at@ позволяет решить _одну из_ проблем, которые я
> >> перед собой ставил. Правда более эффективным способом.
> >> Меня ещё волновала реальная устанавливаемость, а это отдельная тема.
> AT> Реальную устанавливаемость можно проверить этим же методом,
> AT> просто написать другой скрипт на lua.
> 
> Разумно.

Кстате вот скрипт.  Он тоже форкается, для работы нужен пакет lua5-posix
(или положить в текущий каталог posix.so).  Кроме того, НУЖЕН ЧМОД.

[at@hint1 ~]$ hsh --init
Components: hasher
Processing pkglists... hasher done
Processing srclists...  hasher done
Creating component releases... done
Updating global release file... done
Appending MD5Sum... hasher done
All your base are belong to us!!!
[at@hint1 ~]$ chmod -w /tmp/.private/at/build/aptbox/var/lib/rpm
[at@hint1 ~]$ /tmp/.private/at/build/aptbox/apt-get script -qq ./test.lua
cannot install: TORCS-data-cars
cannot install: Localizer
cannot install: GroupUserFolder
cannot install: pdns-devel
cannot install: pgpool-II-devel
cannot install: gnome-applets-common
cannot install: vegastrike
cannot install: kernel-modules-nvidia_legacy_96xx-ovz-smp
cannot install: libopensync-plugin-evolution2
cannot install: CMF-CMFCalendar
cannot install: xmms-in-xmp
cannot install: gnome-applets-cpufreq
cannot install: gnome-applets-mini-commander
cannot install: horde3
cannot install: CMFFormController
cannot install: gtuxnes
cannot install: python-module-twisted
cannot install: exUserFolder
cannot install: firefox-fxif
cannot install: balsa
cannot install: CMFQuickInstallerTool
cannot install: perl-Geo-IP
cannot install: gnome-sisyphus-minimal
cannot install: mod_geoip
cannot install: gnome-applets-drivemount
cannot install: kernel-modules-nvidia_legacy_71xx-std-smp
cannot install: gnome-sisyphus-default
cannot install: fuse-complete
cannot install: perl-MP3-Tag-utils
cannot install: CMF
cannot install: pyvnc2swf
cannot install: BTreeFolder2
cannot install: heartbeat-devel
cannot install: gnome-applets-gweather-devel
cannot install: libGeoIP-tools
cannot install: gnome-applets-mixer
cannot install: xmp-alsa
cannot install: gnome-applets-stickynotes
cannot install: thunderbird-quotecollapse
cannot install: xmp-arts
cannot install: abiword
...

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

> Правда есть ряд тонкостей которые так не решить.
> Например наличие файловых конфликтов при отсутствии реальных конфликтов.
> Это однако тоже бага, и она у нас вообще никак не тестируется.

Про это потом напишу.

[-- Attachment #1.2: test.lua --]
[-- Type: text/plain, Size: 647 bytes --]

posix = require "posix"
command_consume=1
for _,pkg in ipairs(pkglist()) do
  verlist = pkgverlist(pkg)
    installed = nil nver = 0
    for _,ver in ipairs(verlist) do
      if pkgvercur(pkg) == ver then
        -- print("already installed: " .. pkgname(pkg) .. "#" ..verstr(ver))
        installed = 1
      end
      nver = nver + 1
    end
    if not installed and nver > 0 then
      pid = posix.fork()
      assert(pid >= 0)
      if pid == 0 then
         markinstall(pkg)
         if statinstbroken(pkg) then
           print("cannot install: " .. pkgname(pkg))
	 end
	 os.exit(0)
      else
         posix.wait(pid)
      end
    end
end

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

Re: [devel] статистика [2]

[Dmitry V. Levin]

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

On Sat, Aug 25, 2007 at 01:23:57AM +0400, Alexey Tourbin wrote:
[...]
> Я теперь сделаю совсем уж интуитивно понятную таблицу
> 	<incoming-src-rpm-basename> <rebuild-number-src-rpm>
> 
> $ uniq -c -f1 .ss |awk '{print$3"\t"$1}' |sort -k2,2n >.sz
> $ head -2 .sz
> GraphicsMagick-1.1.8-alt1.src.rpm       1
> MySQL41-4.1.21-alt5.1.src.rpm   1
> $ tail .sz   
> libSM-1.0.3-alt1.src.rpm        1952
> libICE-1.0.4-alt1.src.rpm       1962
> fontconfig-2.4.2-alt3.src.rpm   2120
> libXext-1.0.3-alt1.src.rpm      2196
> libfreetype-2.3.5-alt2.src.rpm  2203
> gcc4.1-4.1.1-alt11.src.rpm      2365
> libXau-1.0.3-alt1.src.rpm       2388
> libXdmcp-1.0.2-alt1.0.src.rpm   2389
> libX11-1.1.3-alt3.src.rpm       2392
> expat-2.0.1-alt0.1.src.rpm      2646
> $
> 
> Видим, что GraphicsMagick на входе потребует пересборки всего одного
> src.rpm пакета (кстати, это koffice), а expat на входе потребует
> пересобрать уже 2646 src.rpm пакетов.  Всего сейчас в репозитарии 6687
> src.rpm пакетов (с точки зрения этой статистики).
> 
> ЗДЕСЬ НЕ УЧИТЫВАЮТСЯ ИЗМЕНЕНИЯ В basesystem + rpm-build.

Однако в списке присутствует gcc4.1-4.1.1-alt11.src.rpm (скорее всего,
посредством gcc-c++), который входит в [rpm-build].

> Любой пакет, который попадает в basesystem + rpm-build, потребует,
> по идее, полной пересборки сизифа, и этот случай я сейчас специально
> отсёк.

А если его тоже посчитать?  Взять статистику поступления этих пакетов в
Сизиф, и прикинуть хотя бы вероятность того, что пришедший в /i/S пакет
попадает в это множество.

[...]
> ИТОГО, 5 часов/3 = 100 минут.
> ОТВЕТ: на серии из N пакетов, где N порядка 25, суммарное время
> пересборочного тестирования с вероятностью 95% не превысит N*100 минут.

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

-- 
ldv

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