[devel] girar-builder FR: Выводить время в проверке на устанавливаемость.

[devel] girar-builder FR: Выводить время в проверке на устанавливаемость.

[Anton Farygin]

Есть такое маленькое пожелание, которое навеяло страшной KDE Task.

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

http://git.altlinux.org/tasks/6437/task/log

А то сборка закончилась в 16:43, а KDE ещё не в сизифе - всё проверки 
гоняются...

По ощущению, проверки занимают немногим больше времени, чем сборка.. или 
не так ?

Re: [devel] girar-builder FR: Выводить время в проверке на устанавливаемость.

[Sergey V Turchin]

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

On Thursday 14 May 2009, Anton Farygin wrote:

[...]
> По ощущению, проверки занимают немногим больше времени, чем
> сборка.. или не так ?
Для kde примерно так
Сборка началась примерно    14-May-2009 07:48
http://git.altlinux.org/tasks/6437/build/
Сборка закончилась примерно 14-May-2009 16:23
http://git.altlinux.org/tasks/6437/build/26/
task закончился примерно    15-May-2009 08:46
http://git.altlinux.org/tasks/6437/task/

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08


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

Re: [devel] girar-builder FR: Выводить время в проверке на устанавливаемость.

[Andrey Rahmatullin]

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

On Fri, May 15, 2009 at 01:25:33PM +0000, Sergey V Turchin wrote:
> Сборка закончилась примерно 14-May-2009 16:23
> task закончился примерно    15-May-2009 08:46
И чо оно так долго делало?

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

<mouse> raorn: hi, я тут quakeforge на Zaurus'е запустил, правда после
        ряда оптимизаций я смог получить прирост всего в 2 fps - теперь
        у меня их 3 fps ;) а вот обычный sdlquake не завёлся :((

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

Re: [devel] girar-builder FR: Выводить время в проверке на устанавливаемость.

[Dmitry V. Levin]

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

On Fri, May 15, 2009 at 09:26:27PM +0600, Andrey Rahmatullin wrote:
> On Fri, May 15, 2009 at 01:25:33PM +0000, Sergey V Turchin wrote:
> > Сборка закончилась примерно 14-May-2009 16:23
> > task закончился примерно    15-May-2009 08:46
> И чо оно так долго делало?

Тестировало установку 804 бинарных пакетов (15 часов 47 минут 03 секунды),
в среднем около 70 секунд на 1 пакет (установка базового чрута, установка
в него пакета со всеми его зависимостями, удаление чрута).


-- 
ldv

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

Re: [devel] girar-builder FR: Выводить время в проверке на устанавливаемость.

[Michael Shigorin]

On Fri, May 15, 2009 at 07:45:43PM +0400, Dmitry V. Levin wrote:
> > > Сборка закончилась примерно 14-May-2009 16:23
> > > task закончился примерно    15-May-2009 08:46
> > И чо оно так долго делало?
> Тестировало установку 804 бинарных пакетов (15 часов 47 минут
> 03 секунды), в среднем около 70 секунд на 1 пакет (установка
> базового чрута, установка в него пакета со всеми его
> зависимостями, удаление чрута).

Может, эта реализация подождёт более светлого будущего?

Мои-то пакеты не спешат, но всё-таки сборка IMHO приоритетней,
а проверку установкой здорово было бы делать асинхронно в
свободное время (if any), если на всё времени не хватает.

Ну или ограничитель по размеру/количеству вкрутить.

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

Re: [devel] girar-builder FR: Выводить время в проверке на устанавливаемость.

[Alexey Tourbin]

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

On Fri, May 15, 2009 at 07:45:43PM +0400, Dmitry V. Levin wrote:
> On Fri, May 15, 2009 at 09:26:27PM +0600, Andrey Rahmatullin wrote:
> > On Fri, May 15, 2009 at 01:25:33PM +0000, Sergey V Turchin wrote:
> > > Сборка закончилась примерно 14-May-2009 16:23
> > > task закончился примерно    15-May-2009 08:46
> > И чо оно так долго делало?
> 
> Тестировало установку 804 бинарных пакетов (15 часов 47 минут 03 секунды),
> в среднем около 70 секунд на 1 пакет (установка базового чрута, установка
> в него пакета со всеми его зависимостями, удаление чрута).

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

$ hsh --init --no-stuff
...
$ hsh-run --rooter find / >$TMPDIR/out
find: /.out: Permission denied
find: /.host: Permission denied
$ time xargs --delimiter='\n' <$TMPDIR/out hsh-run --rooter -- rpmquery --whatprovides >/dev/null
warning: no package provides /
warning: no package provides /usr/share/info/autoconf.info.gz
warning: no package provides /usr/share/info/automake.info.gz
warning: no package provides /usr/share/man/man1/autoconf.1.gz
warning: no package provides /usr/share/man/man1/autoheader.1.gz
warning: no package provides /usr/share/man/man1/autom4te.1.gz
warning: no package provides /usr/share/man/man1/autoreconf.1.gz
warning: no package provides /usr/share/man/man1/autoscan.1.gz
warning: no package provides /usr/share/man/man1/autoupdate.1.gz
warning: no package provides /usr/share/man/man1/config.guess.1.gz
warning: no package provides /usr/share/man/man1/config.sub.1.gz
warning: no package provides /usr/share/man/man1/ifnames.1.gz
warning: no package provides /usr/bin/pydoc
warning: no package provides /usr/src/RPM
warning: no package provides /usr/src/RPM/RPMS
warning: no package provides /usr/src/RPM/RPMS/noarch
warning: no package provides /usr/src/RPM/SRPMS
warning: no package provides /usr/src/RPM/SPECS
warning: no package provides /usr/src/RPM/SOURCES
warning: no package provides /usr/src/RPM/BUILD
warning: no package provides /usr/src/.xsession.d
warning: no package provides /usr/src/.rpmmacros
...
warning: no package provides /dev
warning: no package provides /dev/log
warning: no package provides /dev/random
warning: no package provides /dev/urandom
warning: no package provides /dev/full
warning: no package provides /dev/zero
warning: no package provides /dev/null
error: file /dev/stderr: No such file or directory
error: file /dev/stdout: No such file or directory
error: file /dev/stdin: No such file or directory
error: file /dev/fd: No such file or directory
warning: no package provides /dev/pts
warning: no package provides /.in
warning: no package provides /.host
Command exited with non-zero status 123
95.34user 110.46system 4:21.10elapsed 78%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+12376937minor)pagefaults 0swaps
$

Одна из проблем со скоростью здесь в том, что rpmquery для каждого
аргумента всегда вынимает хедер из базы Packages, и для многих файлов
этот хедер, естественно, одинаковый.  То есть в цикле тупо вынимает один
и тот же хедер.

Я написал программу на Си, которая отличается от --whatprovides тем,
что работает чисто на индексе, а хедер не вынимает вообще.
Соответственно, это программа не умеет показывает, к чему файл
относится, но всё ещё умеет показывать, если файл никуда не относится.

Но оказывается, что эта программа не намного быстрее, даже не в два
раза.

$ time xargs --delimiter='\n' <$TMPDIR/out hsh-run --rooter -- ./qf-or-whatprovides-check
...
warning: file /.in is not owned by any package
warning: file /.host is not owned by any package
Command exited with non-zero status 123
76.30user 72.44system 3:31.91elapsed 70%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+7156556minor)pagefaults 0swaps
$ 

Значит, вынимание хедеров не является главным узким местом, как
я сначала думал.  Где-то ещё время утекает, надо будет профилировать.

[-- Attachment #1.2: qf-or-whatprovides-check.c --]
[-- Type: text/plain, Size: 935 bytes --]

#include <stdio.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <assert.h>
#include <rpmlib.h>
#include <rpmdb.h>

int check_index(rpmdb db, rpmTag tag, const char *str)
{
	rpmdbMatchIterator mi = rpmdbInitIterator(db, tag, str, 0);
	int count = rpmdbGetIteratorCount(mi);
	rpmdbFreeIterator(mi);
	return (count > 0) ? 0 : 1;
}

int qf_or_provides(rpmdb db, const char *path)
{
	if (check_index(db, RPMTAG_BASENAMES, path) == 0)
		return 0;
	if (check_index(db, RPMTAG_PROVIDENAME, path) == 0)
		return 0;
	struct stat st;
	if (lstat(path, &st) == 0)
		fprintf(stderr, "warning: file %s is not owned by any package\n", path);
	else
		fprintf(stderr, "error: file %s: %m\n", path);
	return 1;
}

int main(int argc, char *argv[])
{
	rpmdb db = NULL;
	rpmReadConfigFiles(NULL, NULL);
	rpmdbOpen(NULL, &db, O_RDONLY, 0644);
	assert(db);

	int i, rc = 0;
	for (i = 1; i < argc; i++)
		rc |= qf_or_provides(db, argv[i]);

	return rc;
}

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Dmitry V. Levin]

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

On Fri, May 15, 2009 at 07:18:52PM +0300, Michael Shigorin wrote:
> On Fri, May 15, 2009 at 07:45:43PM +0400, Dmitry V. Levin wrote:
> > > > Сборка закончилась примерно 14-May-2009 16:23
> > > > task закончился примерно    15-May-2009 08:46
> > > И чо оно так долго делало?
> > Тестировало установку 804 бинарных пакетов (15 часов 47 минут
> > 03 секунды), в среднем около 70 секунд на 1 пакет (установка
> > базового чрута, установка в него пакета со всеми его
> > зависимостями, удаление чрута).
> 
> Может, эта реализация подождёт более светлого будущего?

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

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

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


-- 
ldv

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Anton Farygin]

Dmitry V. Levin пишет:
> On Fri, May 15, 2009 at 07:18:52PM +0300, Michael Shigorin wrote:
>> On Fri, May 15, 2009 at 07:45:43PM +0400, Dmitry V. Levin wrote:
>>>>> Сборка закончилась примерно 14-May-2009 16:23
>>>>> task закончился примерно    15-May-2009 08:46
>>>> И чо оно так долго делало?
>>> Тестировало установку 804 бинарных пакетов (15 часов 47 минут
>>> 03 секунды), в среднем около 70 секунд на 1 пакет (установка
>>> базового чрута, установка в него пакета со всеми его
>>> зависимостями, удаление чрута).
>> Может, эта реализация подождёт более светлого будущего?
> 
> Мне кажется, что среднее время тестирования установки бинарного пакета
> меньше, чем среднее время сборки исходного пакета.
> Поэтому я полагаю, что время этой проверки уже настало.
> 
> Кроме того, я считаю принципиально неправильным отказываться от проверок
> из-за того, что на них не хватает ресурсов.  Вместо этого лучше добывать
> недостающие ресурсы.
> 
> Кстати, если у кого-то есть много вычислительных ресурсов, которые можно
> использовать для нужд Сизифа на долгосрочной основе, напишите мне.


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

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

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey Tourbin]

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

On Fri, May 15, 2009 at 09:23:23PM +0400, Anton Farygin wrote:
> Дим, а отчего бы не попробовать сделать 
> запуск проверок в параллель сборке ? 
> Прямо после сборки каждого бинарного 
> пакета...

Нет, так делать нельзя.  Нужно полностью генерировать новый
RPMS.classic.  Установка на новом RPMS.classic может отличаться
от установки на старом RPMS.classic + RPMS.hasher.

В целом, нельзя отказаться от семантики сборки задания и выполнения
проверок.  Эта семантика состоит в следущем: сначала все пакеты
собираются на старом репозитарии RPMS.classic + RPMS.hasher (то есть с
локальным оверлеем в режиме --wiht-stuff).  Если сборка прошла успешно,
то генерируется новый репозитарий RPMS.classic и уже на новом
репозитарии выполняются проверки.  Этот подход продуман достаточно
хоршо, его очень сложно улучшить и очень легко ухудшить.

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

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Anton Farygin]

Alexey Tourbin пишет:
> On Fri, May 15, 2009 at 09:23:23PM +0400, Anton Farygin wrote:
>> Дим, а отчего бы не попробовать сделать 
>> запуск проверок в параллель сборке ? 
>> Прямо после сборки каждого бинарного 
>> пакета...
> 
> Нет, так делать нельзя.  Нужно полностью генерировать новый
> RPMS.classic.  Установка на новом RPMS.classic может отличаться
> от установки на старом RPMS.classic + RPMS.hasher.
> 
> В целом, нельзя отказаться от семантики сборки задания и выполнения
> проверок.  Эта семантика состоит в следущем: сначала все пакеты
> собираются на старом репозитарии RPMS.classic + RPMS.hasher (то есть с
> локальным оверлеем в режиме --wiht-stuff).  Если сборка прошла успешно,
> то генерируется новый репозитарий RPMS.classic и уже на новом
> репозитарии выполняются проверки.  Этот подход продуман достаточно
> хоршо, его очень сложно улучшить и очень легко ухудшить.
> 

Вопрос не в том, улучшить ли его или ухудшить. Вопрос в том - как его 
ускорить.

Ведь, в идеале - нужно максимально быстро получить либо новый 
RPMS.classic, либо отлуп по ошибке. При чём, если есть ошибка, то чем 
раньше будет отлуп - тем лучше.

А тестовая установка пакетов идёт в один или в несколько потоков ?

Можем ли мы предоставить любому желающему подключиться к процессу 
разработки Sisyphus, просто задействовав его вычислительный ресурс ?

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Afanasov Dmitry]

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

On Fri, May 15, 2009 at 08:35:44PM +0400, Dmitry V. Levin wrote:
> Кстати, если у кого-то есть много вычислительных ресурсов, которые можно
> использовать для нужд Сизифа на долгосрочной основе, напишите мне.
как разберусь с kvm (или xen получится реанимировать), так смогу
заделиться ядрышком-двумя :)

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

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Anton Farygin]

Afanasov Dmitry пишет:
> On Fri, May 15, 2009 at 08:35:44PM +0400, Dmitry V. Levin wrote:
>> Кстати, если у кого-то есть много вычислительных ресурсов, которые можно
>> использовать для нужд Сизифа на долгосрочной основе, напишите мне.
> как разберусь с kvm (или xen получится реанимировать), так смогу
> заделиться ядрышком-двумя :)

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

рекомендую, подключайтесь к тестированию.

Re: [devel] ресурсоёмкое тестирование пакетов

[Michael Shigorin]

On Fri, May 15, 2009 at 10:32:18PM +0400, Afanasov Dmitry wrote:
> > Кстати, если у кого-то есть много вычислительных ресурсов,
> > которые можно использовать для нужд Сизифа на долгосрочной
> > основе, напишите мне.
> как разберусь с kvm (или xen получится реанимировать), так
> смогу заделиться ядрышком-двумя :)

Боюсь, Дима сказал "_много_" и забыл добавить "плюс канал".

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Afanasov Dmitry]

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

On Fri, May 15, 2009 at 09:34:17PM +0300, Michael Shigorin wrote:
> On Fri, May 15, 2009 at 10:32:18PM +0400, Afanasov Dmitry wrote:
> > > Кстати, если у кого-то есть много вычислительных ресурсов,
> > > которые можно использовать для нужд Сизифа на долгосрочной
> > > основе, напишите мне.
> > как разберусь с kvm (или xen получится реанимировать), так
> > смогу заделиться ядрышком-двумя :)
> 
> Боюсь, Дима сказал "_много_" и забыл добавить "плюс канал".
ну тады до осени ждать придется, 10ку только тогда выбить получится.
-- 
 С уважением
 Афанасов Дмитрий

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Anton Farygin]

Afanasov Dmitry пишет:
> On Fri, May 15, 2009 at 09:34:17PM +0300, Michael Shigorin wrote:
>> On Fri, May 15, 2009 at 10:32:18PM +0400, Afanasov Dmitry wrote:
>>>> Кстати, если у кого-то есть много вычислительных ресурсов,
>>>> которые можно использовать для нужд Сизифа на долгосрочной
>>>> основе, напишите мне.
>>> как разберусь с kvm (или xen получится реанимировать), так
>>> смогу заделиться ядрышком-двумя :)
>> Боюсь, Дима сказал "_много_" и забыл добавить "плюс канал".
> ну тады до осени ждать придется, 10ку только тогда выбить получится.

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Afanasov Dmitry]

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

On Fri, May 15, 2009 at 10:33:05PM +0400, Anton Farygin wrote:
> Afanasov Dmitry пишет:
> > On Fri, May 15, 2009 at 08:35:44PM +0400, Dmitry V. Levin wrote:
> >> Кстати, если у кого-то есть много вычислительных ресурсов, которые можно
> >> использовать для нужд Сизифа на долгосрочной основе, напишите мне.
> > как разберусь с kvm (или xen получится реанимировать), так смогу
> > заделиться ядрышком-двумя :)
> 
> mkve уже почти готов к использованию. По крайней мере - сегодня он мне 
> выдал что нет загрузчика на диске, это уже большой прогресс.
> 
> рекомендую, подключайтесь к тестированию.
дока, надеюсь, будет поподробнее, чем в hasher/spt/mkimage? :)
-- 
 С уважением
 Афанасов Дмитрий

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey Tourbin]

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

On Fri, May 15, 2009 at 10:15:18PM +0400, Anton Farygin wrote:
> Alexey Tourbin пишет:
> >On Fri, May 15, 2009 at 09:23:23PM +0400, Anton Farygin wrote:
> >>Дим, а отчего бы не попробовать сделать 
> >>запуск проверок в параллель сборке ? 
> >>Прямо после сборки каждого бинарного 
> >>пакета...
> >
> >Нет, так делать нельзя.  Нужно полностью 
> >генерировать новый
> >RPMS.classic.  Установка на новом RPMS.classic может 
> >отличаться
> >от установки на старом RPMS.classic + RPMS.hasher.
> >
> >В целом, нельзя отказаться от семантики 
> >сборки задания и выполнения
> >проверок.  Эта семантика состоит в 
> >следущем: сначала все пакеты
> >собираются на старом репозитарии RPMS.classic 
> >+ RPMS.hasher (то есть с
> >локальным оверлеем в режиме --wiht-stuff).  
> >Если сборка прошла успешно,
> >то генерируется новый репозитарий 
> >RPMS.classic и уже на новом
> >репозитарии выполняются проверки.  Этот 
> >подход продуман достаточно
> >хоршо, его очень сложно улучшить и очень 
> >легко ухудшить.
> 
> Вопрос не в том, улучшить ли его или 
> ухудшить. Вопрос в том - как его ускорить.

Ускорить никак нельзя.  Сейчас структура расходов времени в girar-builder
близка к оптимальной, за исключением проверки, которая использует
--whatprovides.  Эту проверку нужно будет переделать.  Она выводит много
всякой лабуды, но иногда выводит и кое-что интересное.  Я пока не решил,
что именно нам от неё нужно.  Изначально это была проверка на ничейные
каталоги, но проблема ничейных каталогов никогда не была простой.

> Ведь, в идеале - нужно максимально быстро 
> получить либо новый RPMS.classic, либо отлуп по 
> ошибке. При чём, если есть ошибка, то чем 
> раньше будет отлуп - тем лучше.

Да ты прямо теоритик какой-то ускорения сборки!

> А тестовая установка пакетов идёт в один 
> или в несколько потоков ?

Как ты понимаешь установку в несколько потоков?  У нас же есть только
один хешеровский чрут.  А если разворачивать скажем два чрута то второй
чрут будет вовсе не бесплатным.  Считай что на каждый чрут нужно полгига
памяти.  А этих полгигов лишних не бывает.  Они в свою очередь будут
вымывать буферный кеш.  Нельзя просто так что-то взять и совершенно
бесплатно распараллелить.

> Можем ли мы предоставить любому 
> желающему подключиться к процессу 
> разработки Sisyphus, просто задействовав его 
> вычислительный ресурс ?
> 
> Дима, не мог бы ты подробнее объяснить, 
> какого рода вычислительные ресурсы тебе 
> нужны и в каком качестве ?

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Anton Farygin]

Afanasov Dmitry пишет:
> On Fri, May 15, 2009 at 10:33:05PM +0400, Anton Farygin wrote:
>> Afanasov Dmitry пишет:
>>> On Fri, May 15, 2009 at 08:35:44PM +0400, Dmitry V. Levin wrote:
>>>> Кстати, если у кого-то есть много вычислительных ресурсов, которые можно
>>>> использовать для нужд Сизифа на долгосрочной основе, напишите мне.
>>> как разберусь с kvm (или xen получится реанимировать), так смогу
>>> заделиться ядрышком-двумя :)
>> mkve уже почти готов к использованию. По крайней мере - сегодня он мне 
>> выдал что нет загрузчика на диске, это уже большой прогресс.
>>
>> рекомендую, подключайтесь к тестированию.
> дока, надеюсь, будет поподробнее, чем в hasher/spt/mkimage? :)

Мне для запуска :) хватило man и --help

да, там лучше либо дождаться из сизифа, либо собрать самому из git'а:
libvirt
mkve

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

поддерживает openvz и kvm.. по идее вообще всё подряд, но наверное mkve 
не умеет делать остальные типы контейнеров.

Re: [devel] ресурсоёмкое тестирование пакетов

[Anton Farygin]

Alexey Tourbin пишет:

> Ускорить никак нельзя.  Сейчас структура расходов времени в girar-builder
> близка к оптимальной, за исключением проверки, которая использует
> --whatprovides.  Эту проверку нужно будет переделать.  Она выводит много
> всякой лабуды, но иногда выводит и кое-что интересное.  Я пока не решил,
> что именно нам от неё нужно.  Изначально это была проверка на ничейные
> каталоги, но проблема ничейных каталогов никогда не была простой.

Т.е. - ускорение возможно только увеличением быстродействия каждого из 
процессорных ядер и добавлением ОЗУ ?

И почему бы не включить сборку в несколько потоков ?

> Как ты понимаешь установку в несколько потоков?  У нас же есть только
> один хешеровский чрут.  А если разворачивать скажем два чрута то второй
> чрут будет вовсе не бесплатным.  Считай что на каждый чрут нужно полгига
> памяти.  А этих полгигов лишних не бывает.  Они в свою очередь будут
> вымывать буферный кеш.  Нельзя просто так что-то взять и совершенно
> бесплатно распараллелить.

Имея под рукой простаивающее железо (например, соседний сервер) ?

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

Как я понял из твоих слов - добавление железа не решает проблему ?

Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey Tourbin]

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

On Fri, May 15, 2009 at 10:53:53PM +0400, Anton Farygin wrote:
> >Ускорить никак нельзя.  Сейчас структура 
> >расходов времени в girar-builder
> >близка к оптимальной, за исключением 
> >проверки, которая использует
> >--whatprovides.  Эту проверку нужно будет 
> >переделать.  Она выводит много
> >всякой лабуды, но иногда выводит и 
> >кое-что интересное.  Я пока не решил,
> >что именно нам от неё нужно.  Изначально 
> >это была проверка на ничейные
> >каталоги, но проблема ничейных 
> >каталогов никогда не была простой.
> 
> Т.е. - ускорение возможно только 
> увеличением быстродействия каждого из 
> процессорных ядер и добавлением ОЗУ ?

Есть ещё L2/L3 кеш и контроллер памяти.  В дрепперовской статье про
память на с.16 дана такая оценка: доступ к L2/L3 hit стоит 14 циклов
процессора, а L2/L3 miss -- 240 циклов.  Теперь представь что происходит
если ты хочешь параллельно разворачивать несколько чрутов на tmpfs и
выполнять в них интенсивные операции с доступом к памяти.  Они же
толкаются между собой.  То есть линейного распараллеливания на таких
"полгиговых" задачах никогда не будет.  В первом приближении, при
распараллеливании в два потока можно рассчитывать на эффект лишь раза
в полтора.

> И почему бы не включить сборку в 
> несколько потоков ?

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

> >вымывать буферный кеш.  Нельзя просто 
> >так что-то взять и совершенно
> >бесплатно распараллелить.
> 
> Имея под рукой простаивающее железо 
> (например, соседний сервер) ?

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

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

Да, часами ждать -- это самое неприятное. :(

> Как я понял из твоих слов - добавление 
> железа не решает проблему ?

Железо железу рознь.  Железо на процессорах класса Nehalem Xeon,
к каждому процессору 24 гига памяти, может решить довольно много.

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Mikhail Gusarov]

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


Twas brillig at 23:26:30 15.05.2009 UTC+04 when at@altlinux.ru did gyre and gimble:

 AT> Не всякий сервер ликвидной мощностью обладает по современным
 AT> меркам.  Для быстрой сборки, тем более с распараллеливанием, нужны
 AT> очень концентрированные мощности.

Ресурсоёмкую проверку устанавливаемости можно распараллеливать и на
относительно слабом железе, если его много, и latency сообщения с ним
невысокая. Собирать, понятное дело, лучше на основном сервере.

-- 

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey Tourbin]

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

On Sat, May 16, 2009 at 02:30:23AM +0700, Mikhail Gusarov wrote:
> 
> Twas brillig at 23:26:30 15.05.2009 UTC+04 when at@altlinux.ru did gyre and gimble:
> 
>  AT> Не всякий сервер ликвидной мощностью обладает по современным
>  AT> меркам.  Для быстрой сборки, тем более с распараллеливанием, нужны
>  AT> очень концентрированные мощности.
> 
> Ресурсоёмкую проверку устанавливаемости можно распараллеливать и на
> относительно слабом железе, если его много, и latency сообщения с ним
> невысокая. Собирать, понятное дело, лучше на основном сервере.

Сейчас усилиями ldv реализована архитектура girar-builder + nodes.
girar-builder находится на одной машине и выполняет всякие
централизованные действия.  Характерной особенностью girar-builder
является то, что у него нету своего хешера.  Хешеры находятся на remote
nodes.  Когда нужно что-то от хешера, например сборка или проверка
установки, то girar-builder стучится на remote nodes и там всё делает.
Зато girar-builder умеет генерировать репозитарии, а remote nodes могут
работать только с готовыми репозитарями.  Существует строго ограниченное
количество remote nodes, по имени репозитария и по архитектуре.

То есть существуют ноды типа
build_sisyphus_i586
build_sisyphus_x86_64
build_50_i586
build_50_x86_64

Как распределены ноды между физическим железом это никто не знает.
Предполагается что они каким-то образом балансируют нагрузку.

Как уже должно быть понятно, добавлять новые ноды в такую архитектуру
довольно сложно.  А городить ещё какую-то архитектуру это ещё сложнее. :)

Есть ещё одна проблема: на ноды приходится целиком копировать временный
репозитарий.  Сейчас этот репозитарий делается симлинками.  Это
накладывает дополнительное условие: репозитарий на girar-builder и
репозитарий на нодах должен иметь одинаковый путь.  Потому что симлинки
туда смотрят.

В общем приткнуть сюда какое-то дополнительной железо средней и низкой
ликвидности это как мертвому припарка.

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Mikhail Gusarov]

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


Twas brillig at 23:55:50 15.05.2009 UTC+04 when at@altlinux.ru did gyre
and gimble

 AT> Как уже должно быть понятно, добавлять новые ноды в такую
 AT> архитектуру довольно сложно.  А городить ещё какую-то архитектуру
 AT> это ещё сложнее. :)

Это называется rigid и viscose дизайн. Увы.

 AT> В общем приткнуть сюда какое-то дополнительной железо средней и
 AT> низкой ликвидности это как мертвому припарка.

Гм. *сюда* - да.

-- 

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/15 Alexey Tourbin <at@altlinux.ru>:
>> И почему бы не включить сборку в
>> несколько потоков ?
>
> Потому что такова семантика сборки заданий: они обладают семантикой
> транзакции.  Если задание собрано успешно, то оно переводит репозитарий
> в новое состояние, и сборка следующего задания начинается уже на новом
> репозитарии.  Нельзя начинать собирать несколько заданий на старом
> репозитарии и потом "сводить" несколько результатов сборки в один новый
> репозитарий.  Это может закончиться очень плохо.

Алексей, существует ли относительно недорогой способ выяснить влияют ли
задания друг на друга после, собственно, сборки?

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

Это возможно?

На ARM есть возможность сделать сборочную ферму из большого количества
недорогого железа. Но вот без параллелизма всё грустно.

Re: [devel] ресурсоёмкое тестирование пакетов

[Dmitry V. Levin]

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

On Sat, May 16, 2009 at 02:58:43AM +0700, Mikhail Gusarov wrote:
> Twas brillig at 23:55:50 15.05.2009 UTC+04 when at@altlinux.ru did gyre and gimble
> 
>  AT> Как уже должно быть понятно, добавлять новые ноды в такую
>  AT> архитектуру довольно сложно.  А городить ещё какую-то архитектуру
>  AT> это ещё сложнее. :)
> 
> Это называется rigid и viscose дизайн. Увы.

Попробуй предъявить что-нибудь получше, а мы покритикуем. :)


-- 
ldv

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey Tourbin]

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

On Sat, May 16, 2009 at 02:58:43AM +0700, Mikhail Gusarov wrote:
>  AT> Как уже должно быть понятно, добавлять новые ноды в такую
>  AT> архитектуру довольно сложно.  А городить ещё какую-то архитектуру
>  AT> это ещё сложнее. :)
> 
> Это называется rigid и viscose дизайн. Увы.

Я не значю, что это значит.  На самом деле дизайн не настолько плохой,
и в нём реализовано распараллеливание -- там, где оно естественным
образом возникает.  Сборка пакетов на i586 и x86_64 идёт параллельно.
На нодах i586 и x86_64.  Тестирование тоже идет параллельно, на этих
же самых нодах.  Сборка под разные бранчи идет параллельно.  Это очень
неплохое распараллеливание.

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

>  AT> В общем приткнуть сюда какое-то дополнительной железо средней и
>  AT> низкой ликвидности это как мертвому припарка.
> 
> Гм. *сюда* - да.

Ну и потом это же на шелле написано, а не на эрланге каком-нибудь.
На шелле кое-что делать очень просто а кое-что лушче не делать. :)

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey Tourbin]

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

On Fri, May 15, 2009 at 11:05:35PM +0300, Kirill A. Shutemov wrote:
> 2009/5/15 Alexey Tourbin <at@altlinux.ru>:
> >> И почему бы не включить сборку в
> >> несколько потоков ?
> >
> > Потому что такова семантика сборки заданий: они обладают семантикой
> > транзакции.  Если задание собрано успешно, то оно переводит репозитарий
> > в новое состояние, и сборка следующего задания начинается уже на новом
> > репозитарии.  Нельзя начинать собирать несколько заданий на старом
> > репозитарии и потом "сводить" несколько результатов сборки в один новый
> > репозитарий.  Это может закончиться очень плохо.
> 
> Алексей, существует ли относительно недорогой способ выяснить влияют ли
> задания друг на друга после, собственно, сборки?

Нет такого способа, конечно же.

Грубо говоря, у нас есть
task1=(1/.git 2/.git) и
task2=(1/.git 2/.git).

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

> Идея в том, что бы запускать задания параллельно, если, по результатам
> предыдущих сборок пакетов входящих в задания, есть большая вероятность,

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

> На ARM есть возможность сделать сборочную ферму из большого количества
> недорогого железа. Но вот без параллелизма всё грустно.

Сумма неликвидного желаза не равна единице ликвидного железа: сумма хуже.

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/15 Alexey Tourbin <at@altlinux.ru>:
> On Fri, May 15, 2009 at 11:05:35PM +0300, Kirill A. Shutemov wrote:
>> 2009/5/15 Alexey Tourbin <at@altlinux.ru>:
>> >> И почему бы не включить сборку в
>> >> несколько потоков ?
>> >
>> > Потому что такова семантика сборки заданий: они обладают семантикой
>> > транзакции.  Если задание собрано успешно, то оно переводит репозитарий
>> > в новое состояние, и сборка следующего задания начинается уже на новом
>> > репозитарии.  Нельзя начинать собирать несколько заданий на старом
>> > репозитарии и потом "сводить" несколько результатов сборки в один новый
>> > репозитарий.  Это может закончиться очень плохо.
>>
>> Алексей, существует ли относительно недорогой способ выяснить влияют ли
>> задания друг на друга после, собственно, сборки?
>
> Нет такого способа, конечно же.
>
> Грубо говоря, у нас есть
> task1=(1/.git 2/.git) и
> task2=(1/.git 2/.git).
>
> Выяснить, влияют ли эти два задания друга на друга, -- значит научиться
> предсказывать будущее.  То есть предсказывать результат сборки.

Я ж написал "после".

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

Насколько сложно реализовать этот алгоритм и есть ли он в TODO?

>> На ARM есть возможность сделать сборочную ферму из большого количества
>> недорогого железа. Но вот без параллелизма всё грустно.
>
> Сумма неликвидного желаза не равна единице ликвидного железа: сумма хуже.

Это понятно :(

В случае ARM, самое производительное, из того, что есть в свободном доступе --
SheevaPlug: 1.2GHz, 512Mb RAM. Я себе купил две штуки. Буду пробовать собирать.

Кстати, а от много ядерного железа при текущей архитектуре прок есть?

Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey Tourbin]

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

On Fri, May 15, 2009 at 11:36:14PM +0300, Kirill A. Shutemov wrote:
> >> Алексей, существует ли относительно недорогой способ выяснить влияют ли
> >> задания друг на друга после, собственно, сборки?
> >
> > Нет такого способа, конечно же.
> >
> > Грубо говоря, у нас есть
> > task1=(1/.git 2/.git) и
> > task2=(1/.git 2/.git).
> >
> > Выяснить, влияют ли эти два задания друга на друга, -- значит научиться
> > предсказывать будущее.  То есть предсказывать результат сборки.
> 
> Я ж написал "после".

А.  А что тогда такое "влияет"?  Единственный рациональный ответ -- что
пакеты из одного задания попадают в сборочный чрут при сборке пакетов
другого задания.  Но что такое "пакеты из задания" "попадают"?  Это
жаргон для маскировки сути дела.  А суть дела в том, что надо
сформировать новый репозитарий с пакетами из первого задания и начать
собирать второе задание.  Это в принципе возвращает нас к сериализации
заданий, как оно сейчас реализовано.

> >> Идея в том, что бы запускать задания параллельно, если, по результатам
> >> предыдущих сборок пакетов входящих в задания, есть большая вероятность,
> >
> > С точки зрения такой вероятности можно только предпринимать опережающие
> > спекулятивные сборки.  Но это имеет смысл только при избытке ликвидного
> > железа.
> Насколько сложно реализовать этот алгоритм и есть ли он в TODO?

Это отчасти реализовано.  Когда часть пакетов собралось, а часть не
собралось, то при возобновлении задания для первой части будет
диагностика "no need to rebuild".  См. girar-builder/remote/gb-remote-build.
Но это не реализовано в виде, пригодном для спекулятивной сборки.

Для спекулятивной сборки нужно несколько нодов.  И нужно перделывать
task/seq потому что не ясно в каком же статусе эта спекулятивная сборка
будет идти.  И как поддерживать очередь этих спекулятивных сборок с ходу
трудно сказать.  В общем, идея гниловатая. :)

> В случае ARM, самое производительное, из того, что есть в свободном доступе --
> SheevaPlug: 1.2GHz, 512Mb RAM. Я себе купил две штуки. Буду пробовать собирать.

Насколько быстро эта штука будет openoffice собирать?  Я боюсь что на
таких нативных корытах мы никуда не уедем.  В плане придания арму
статуса более поддерживаемой архитектуры.

> Кстати, а от много ядерного железа при текущей архитектуре прок есть?

Нет.

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Afanasov Dmitry]

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

On Fri, May 15, 2009 at 11:55:50PM +0400, Alexey Tourbin wrote:
> On Sat, May 16, 2009 at 02:30:23AM +0700, Mikhail Gusarov wrote:
> Сейчас усилиями ldv реализована архитектура girar-builder + nodes.
> ...
господа, а ведь это очень интересно, спасибо, не знал.

куда это на wiki можно оформить, интересно?
-- 
 С уважением
 Афанасов Дмитрий

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

Re: [devel] ресурсоёмкое тестирование пакетов

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

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

On Fri, May 15, 2009 at 10:44:25PM +0400, Алексей Турбин wrote:

AT> Как ты понимаешь установку в несколько потоков?  У нас же есть только
AT> один хешеровский чрут.  А если разворачивать скажем два чрута то второй
AT> чрут будет вовсе не бесплатным.  Считай что на каждый чрут нужно полгига
AT> памяти.  А этих полгигов лишних не бывает.  Они в свою очередь будут
AT> вымывать буферный кеш.  Нельзя просто так что-то взять и совершенно
AT> бесплатно распараллелить.

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

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Anton Farygin]

Alexey Tourbin пишет:

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

Я в курсе. В данном контексте имелась в виду компиляция в несколько 
потоков у одной задачи.

Сейчас компиляция идёт на одном ядре, соответственно сколько не добавляй 
ядер процессора - скорость не вырастет. Можно только увеличивать 
мощность каждого процессорного ядра в отдельности.

Стоят ли логи того, что мы теряем при ожидании завершения задачи ?

Re: [devel] girar-builder FR: Выводить время в проверке на устанавливаемость.

[Timur Batyrshin]

В Fri, 15 May 2009 19:45:43 +0400
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> > > Сборка закончилась примерно 14-May-2009 16:23
> > > task закончился примерно    15-May-2009 08:46
> > И чо оно так долго делало?
> Тестировало установку 804 бинарных пакетов (15 часов 47 минут 03
> секунды), в среднем около 70 секунд на 1 пакет (установка базового
> чрута, установка в него пакета со всеми его зависимостями, удаление
> чрута).

А если базовый чрут устанавливать только один раз перед тестированием, а
потом только копировать на каждой итерации -- выигрыша в скорости не
будет? Или что мешает так делать?

Re: [devel] girar-builder FR: Выводить время в проверке на устанавливаемость.

[Dmitry V. Levin]

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

On Sat, May 16, 2009 at 07:17:36PM +0400, Timur Batyrshin wrote:
> В Fri, 15 May 2009 19:45:43 +0400, "Dmitry V. Levin" <ldv@altlinux.org> пишет:
> 
> > > > Сборка закончилась примерно 14-May-2009 16:23
> > > > task закончился примерно    15-May-2009 08:46
> > > И чо оно так долго делало?
> > Тестировало установку 804 бинарных пакетов (15 часов 47 минут 03
> > секунды), в среднем около 70 секунд на 1 пакет (установка базового
> > чрута, установка в него пакета со всеми его зависимостями, удаление
> > чрута).
> 
> А если базовый чрут устанавливать только один раз перед тестированием, а
> потом только копировать на каждой итерации -- выигрыша в скорости не
> будет? Или что мешает так делать?

Обычно так и происходит.


-- 
ldv

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Victor B. Wagner]

On 2009.05.15 at 23:26:30 +0400, Alexey Tourbin wrote:

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

1. Будет ли это "очень плохо" своевременно диагностировано?
2. С насколько высокой вероятностью это "очень плохо" может случиться?

А то может быть ждать десять раз по два часа плюс один раз - семнадцать
(когда "очень плохо - случилось, и пришлось откатываться и строить все
последовательно) будет несколько эффективнее, чем 11 раз по 15 часов?

Вообще, с очевидность МОЖНО собирать несколько заданий на старом
репозитарии и потом их сводить, при условии что эти задания от
результатов друг друга абсолютно независимы.

Понятно, что есть такие пакеты, от которых зависит практически все -
filesystem, toolchain, базовые библиотеки. С ними почти ничего не
запараллелишь. Но что мешает запараллелить, например, сборку
какой-нибудь гномовской фигни со сборкой аналогичной kde-шной фигни?
Или там сборку двух mail transfer agent-ов которые с точки зрения
некоторых дистрибутивов принципиально не могут использоваться
одновременно?

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/18 Victor B. Wagner <vitus@altlinux.org>:
> On 2009.05.15 at 23:26:30 +0400, Alexey Tourbin wrote:
>
>> Потому что такова семантика сборки заданий: они обладают семантикой
>> транзакции.  Если задание собрано успешно, то оно переводит репозитарий
>> в новое состояние, и сборка следующего задания начинается уже на новом
>> репозитарии.  Нельзя начинать собирать несколько заданий на старом
>> репозитарии и потом "сводить" несколько результатов сборки в один новый
>> репозитарий.  Это может закончиться очень плохо.
>
> 1. Будет ли это "очень плохо" своевременно диагностировано?
> 2. С насколько высокой вероятностью это "очень плохо" может случиться?
>
> А то может быть ждать десять раз по два часа плюс один раз - семнадцать
> (когда "очень плохо - случилось, и пришлось откатываться и строить все
> последовательно) будет несколько эффективнее, чем 11 раз по 15 часов?
>
> Вообще, с очевидность МОЖНО собирать несколько заданий на старом
> репозитарии и потом их сводить, при условии что эти задания от
> результатов друг друга абсолютно независимы.
>
> Понятно, что есть такие пакеты, от которых зависит практически все -
> filesystem, toolchain, базовые библиотеки. С ними почти ничего не
> запараллелишь. Но что мешает запараллелить, например, сборку
> какой-нибудь гномовской фигни со сборкой аналогичной kde-шной фигни?
> Или там сборку двух mail transfer agent-ов которые с точки зрения
> некоторых дистрибутивов принципиально не могут использоваться
> одновременно?

В общем случае нельзя понять как задания повлияют друг на друга до того как
они будут собраны, поскольку нельзя заранее знать какие бинарные пакеты
будут собраны из данного исходного и какие requires/provides будут у этих
пакетов. Однако, можно стороить пердположения на основе предыдущих сборок
пакетов входящих в задание. Мне видиться, что эти предположения могут быть
достаточно релевантны.

Re: [devel] ресурсоёмкое тестирование пакетов

[Victor B. Wagner]

On 2009.05.18 at 13:43:29 +0300, Kirill A. Shutemov wrote:

> 
> В общем случае нельзя понять как задания повлияют друг на друга до того как
> они будут собраны, поскольку нельзя заранее знать какие бинарные пакеты
> будут собраны из данного исходного и какие requires/provides будут у этих

Э, как это нельзя? А grep ^%package filename.spec?

С requires/provides действительно сложнее. Потому что 2/3 их ни разу в
спеке явным образом не прописаны. 

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

> пакетов. Однако, можно стороить пердположения на основе предыдущих сборок
> пакетов входящих в задание. Мне видиться, что эти предположения могут быть
> достаточно релевантны.

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

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

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



> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/18 Victor B. Wagner <vitus@altlinux.org>:
> On 2009.05.18 at 13:43:29 +0300, Kirill A. Shutemov wrote:
>
>>
>> В общем случае нельзя понять как задания повлияют друг на друга до того как
>> они будут собраны, поскольку нельзя заранее знать какие бинарные пакеты
>> будут собраны из данного исходного и какие requires/provides будут у этих
>
> Э, как это нельзя? А grep ^%package filename.spec?

Они (точнее секции %files) могут быть обёрнуты во всякие %if, т.о. этот grep ни
о чём не скажет. :(

> С requires/provides действительно сложнее. Потому что 2/3 их ни разу в
> спеке явным образом не прописаны.
>
> Но вообще, насколько я помню, все Build-Requires выявляются на весьма
> раннем этапе сборки пакета. Выполнить prep-стадию ради того, чтобы
> собрать эту информацию, может оказаться оправданной затратой ресурсов.

Разворачивание сборочной среды и установка Build-Requires, если я правильно
всё понял, должна помочь получить список подподпакетов. Но requires/provides
всё равно будут не доступны пока пакет не будет полностью собран. Так что это
тоже бессмысленно. :(

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

Согласен.

Re: [devel] ресурсоёмкое тестирование пакетов

[Victor B. Wagner]

> > Э, как это нельзя? А grep ^%package filename.spec?
> 
> Они (точнее секции %files) могут быть обёрнуты во всякие %if, т.о. этот grep ни
> о чём не скажет. :(
> 

Ну почему "ни о чем"? - это даст оценку сверху - такие-то и такие-то
пакеты ПРИНЦИПИАЛЬНО МОГУТ БЫТЬ построены из этого исходника.

Это уже дает существенную помощь при задаче распараллеливания.
Причем безопасную. Любая ошибка будет on safe side - мы можем
предположить что зависимость есть, а на самом деле её нет - она под %if,
условие которого в данном случае не выполняется.


> > С requires/provides действительно сложнее. Потому что 2/3 их ни разу в
> > спеке явным образом не прописаны.
> >
> > Но вообще, насколько я помню, все Build-Requires выявляются на весьма
> > раннем этапе сборки пакета. Выполнить prep-стадию ради того, чтобы
> > собрать эту информацию, может оказаться оправданной затратой ресурсов.
> 
> Разворачивание сборочной среды и установка Build-Requires, если я правильно
> всё понял, должна помочь получить список подподпакетов. Но requires/provides
> всё равно будут не доступны пока пакет не будет полностью собран. Так что это
> тоже бессмысленно. :(

Это опять же отнюдь не бессмыслено. Стопроцентной гарантии не дает, но
существенные хинты дает.

Если мы что-то Build-Requires, то
скорее всего мы потом будем Requires либо его, либо что-то, собираемое
из того же исходника. Случаи, когда пакет requires что-либо, что нафиг
не нужно в процессе его сборки, не столь уж часты, и, главное, если он
этого не Build-Requires, то смена версии этого в процессе параллельной
пересборки вряд ли чего-нибудь сломает (а если сломает, то этого не
выяснится и при последовательной пересборке - только при вдумчивом
тестировании).

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/18 Victor B. Wagner <vitus@altlinux.org>:
>> > Э, как это нельзя? А grep ^%package filename.spec?
>>
>> Они (точнее секции %files) могут быть обёрнуты во всякие %if, т.о. этот grep ни
>> о чём не скажет. :(
>>
>
> Ну почему "ни о чем"? - это даст оценку сверху - такие-то и такие-то
> пакеты ПРИНЦИПИАЛЬНО МОГУТ БЫТЬ построены из этого исходника.
>
> Это уже дает существенную помощь при задаче распараллеливания.
> Причем безопасную. Любая ошибка будет on safe side - мы можем
> предположить что зависимость есть, а на самом деле её нет - она под %if,
> условие которого в данном случае не выполняется.
>
>
>> > С requires/provides действительно сложнее. Потому что 2/3 их ни разу в
>> > спеке явным образом не прописаны.
>> >
>> > Но вообще, насколько я помню, все Build-Requires выявляются на весьма
>> > раннем этапе сборки пакета. Выполнить prep-стадию ради того, чтобы
>> > собрать эту информацию, может оказаться оправданной затратой ресурсов.
>>
>> Разворачивание сборочной среды и установка Build-Requires, если я правильно
>> всё понял, должна помочь получить список подподпакетов. Но requires/provides
>> всё равно будут не доступны пока пакет не будет полностью собран. Так что это
>> тоже бессмысленно. :(
>
> Это опять же отнюдь не бессмыслено. Стопроцентной гарантии не дает, но
> существенные хинты дает.
>
> Если мы что-то Build-Requires, то
> скорее всего мы потом будем Requires либо его, либо что-то, собираемое
> из того же исходника. Случаи, когда пакет requires что-либо, что нафиг
> не нужно в процессе его сборки, не столь уж часты, и, главное, если он
> этого не Build-Requires, то смена версии этого в процессе параллельной
> пересборки вряд ли чего-нибудь сломает (а если сломает, то этого не
> выяснится и при последовательной пересборке - только при вдумчивом
> тестировании).

ИМХО, результаты предыдущей сборки должны лучшее приближение, чем
подобный анализ.

Re: [devel] ресурсоёмкое тестирование пакетов

[Victor B. Wagner]

On 2009.05.18 at 15:29:50 +0300, Kirill A. Shutemov wrote:

> 
> ИМХО, результаты предыдущей сборки должны лучшее приближение, чем
> подобный анализ.

Результаты предыдущей сборки в сочетании с подобным анализом дают еще
лучшее приближение.

Если результаты анализа spec-файла совпадают с результатами анализа
spec-файла предыдущей версии, то результаты предыдущей сборки можно
считать достоверными практически на 100%. 

Хотя я легко могу себе представить как в результате сборки новой
upstream-версии или добавления нового патча появляется парочка
дополнительных *.so, которых в предыдущей сборке не было, а в секции
files ничего про них не написано, потому что они попадают под имеющийся
шаблон.

Если не совпадают, то можно принимать какие-то дополнительные меры.

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Max Ivanov]

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/18 Max Ivanov <ivanov.maxim@gmail.com>:
> Почему бы просто не заглянуть в BuildRequires , и если один другому не
> нужен, то оба можно собирать паралельно. хотя бы это уже даст
> возможность мне спокойно собрать какой-нибудь малюсенький python
> модуль, пока рядом собирается kde4 монстр

Ещё раз: нельзя знать что получиться на выходе сборки пакета a.srpm, т.о.
нельзя знать что попадёт в сборочную среду пакета b.srpm. Можно только
об этом догадываться.

Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey Tourbin]

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

On Mon, May 18, 2009 at 02:24:47PM +0400, Victor B. Wagner wrote:
> On 2009.05.15 at 23:26:30 +0400, Alexey Tourbin wrote:
> 
> > Потому что такова семантика сборки заданий: они обладают семантикой
> > транзакции.  Если задание собрано успешно, то оно переводит репозитарий
> > в новое состояние, и сборка следующего задания начинается уже на новом
> > репозитарии.  Нельзя начинать собирать несколько заданий на старом
> > репозитарии и потом "сводить" несколько результатов сборки в один новый
> > репозитарий.  Это может закончиться очень плохо.
> 
> 1. Будет ли это "очень плохо" своевременно диагностировано?
> 2. С насколько высокой вероятностью это "очень плохо" может случиться?
> 
> А то может быть ждать десять раз по два часа плюс один раз - семнадцать
> (когда "очень плохо - случилось, и пришлось откатываться и строить все
> последовательно) будет несколько эффективнее, чем 11 раз по 15 часов?

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

"Сводить" несколько заданий на логическом уровне нельзя в любом случае.
Условия замещения пакетов могут быть слишком нетривиальными.  Мы ведь
допускаем произвольную перетасовку подпакетов между пакетами, а равно
и полное замещение пакетов по подпакету, и при этом ещё нужно уметь
проверять ACL (потому что существуют shared tasks, которые могут
формироваться разными людьми).  Корректно реализовать все эти процедуры
нам пока удалось только для схемы A->B, где A - старое/текущее состояние
репозитария, B - новое состояние репозитария.  Эта схема предполагает
явную сериализацию заданий.

> Вообще, с очевидность МОЖНО собирать несколько заданий на старом
> репозитарии и потом их сводить, при условии что эти задания от
> результатов друг друга абсолютно независимы.

Собирать можно, сводить нельзя. :)

> Понятно, что есть такие пакеты, от которых зависит практически все -
> filesystem, toolchain, базовые библиотеки. С ними почти ничего не
> запараллелишь. Но что мешает запараллелить, например, сборку
> какой-нибудь гномовской фигни со сборкой аналогичной kde-шной фигни?
> Или там сборку двух mail transfer agent-ов которые с точки зрения
> некоторых дистрибутивов принципиально не могут использоваться
> одновременно?

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

Когда мы начинаем собирать задание, мы исходим из того, что о пакетах
в этом задании нам ничего неизвестно.  Это моя принципиальная позиация,
если хотите.  У ldv на этот счет другая, но не принципиальная позиция.

Существует модель данных, которая в принципе делает возможным
опережающую спекулятивную сборку пакетов.  Эта модель данных описывается
формулой

B(S,C)->P

где
B -- процедура сборки пакета (build, hasher),
S -- исходный код пакета (src.rpm),
C -- содержимое сборочной среды (chroot),
P -- собранные пакеты.

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

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

Вот в каком виде эта информация представлена.
Рассмотрим задание 6670 с пакетом perl-Class-Accessor.

$ rsync -vaP git.altlinux.org::tasks/6670 $TMPDIR/tasks/
$ cd $TMPDIR/tasks/6670
$ find -name 'chroot_*'
./build/1/x86_64/chroot_base
./build/1/x86_64/chroot_BR
./build/1/i586/chroot_base
./build/1/i586/chroot_BR
$ head ./build/1/x86_64/chroot_base
SysVinit        2.86-alt2       x86_64  SysVinit-2.86-alt2.src.rpm      920f28e5ee12b122331eb5732964f0871a629eb7
alt-gpgkeys     0.7-alt2        x86_64  alt-gpgkeys-0.7-alt2.src.rpm    9f26e3268aabb7dad4d0860d663d66aa62171000
alternatives    0.4.1-alt2      noarch  alternatives-0.4.1-alt2.src.rpm 7d06d5c571995c00b4fa499c2636ab3868778266
autoconf-common 0.2-alt1        noarch  autoconf-common-0.2-alt1.src.rpm        bfe73e65a4471aae6c5be95520953502bc60d69f
autoconf_2.60   2:2.63-alt4     noarch  autoconf_2.60-2.63-alt4.src.rpm 4f4f3fc50d82a617e2cf184f4279622ec372bff8
automake-common 0.2-alt1        noarch  automake-common-0.2-alt1.src.rpm        1fb582eed4ecfd8a4d2db6ebd41ac7f2e4775c5e
automake_1.11   1.11-alt1       noarch  automake_1.11-1.11-alt1.src.rpm 73d43cb1b422e030bd6e08bd20a4997e788a0765
basesystem      1:sisyphus-alt17        noarch  basesystem-sisyphus-alt17.src.rpm       71126abe4f8918d6e34bc7a47cbf606e0420dae8
bash    3.2.39-alt2     x86_64  bash-3.2.39-alt2.src.rpm        b04ff27110379e289ba89e8213e9bbe2eeaaf3b9
binutils        1:2.19.51.0.2-alt1      x86_64  binutils-2.19.51.0.2-alt1.src.rpm       ced2379c393a4380f8088ff37e98aa28d48c1dcc
$ head ./build/1/x86_64/chroot_BR  
perl-devel      1:5.8.9-alt2    x86_64  perl-5.8.9-alt2.src.rpm 5b75802744adf0d9674451d251ee8125fc35b9b8
$ 

Здесь явно фиксируется среда C сборки пакета -- базовая часть сборочного
чрута (одинаковая для всех пакетов) плюс дополнительные пакеты, которые
являются замыканием BuildRequires.

В общем, модель есть, но реализовать на основе этой модели параллельную
сборку с сериализацией при сведЕнии -- это отдельная и достаточно
сложная задача.

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Victor B. Wagner]

On 2009.05.18 at 16:00:21 +0300, Kirill A. Shutemov wrote:

> 2009/5/18 Max Ivanov <ivanov.maxim@gmail.com>:
> > Почему бы просто не заглянуть в BuildRequires , и если один другому не
> > нужен, то оба можно собирать паралельно. хотя бы это уже даст
> > возможность мне спокойно собрать какой-нибудь малюсенький python
> > модуль, пока рядом собирается kde4 монстр
> 
> Ещё раз: нельзя знать что получиться на выходе сборки пакета a.srpm, т.о.
> нельзя знать что попадёт в сборочную среду пакета b.srpm. Можно только
> об этом догадываться.

Так о том и речь, что действовать надо на основании этих догадок. Если
вдруг какая догадка не оправдается, придется этот пакет пересобрать еще
раз. В общем и целом получится быстрее, чем собирать все
последовательно. Особенно если распараллеливать сборку хостов на 10-20.

Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey Tourbin]

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

On Mon, May 18, 2009 at 04:49:03PM +0400, Max Ivanov wrote:
> Почему бы просто не заглянуть в BuildRequires , и если один другому не

Потому что BuildRequires -- это не то же самое, что замыкание
BuildRequires.  Например, для "BuildRequires: libgtk+2-devel"
очень наивно было бы считать, что можно "заглянуть" в BuildRequires
и сделать какие-то выводы.

> нужен, то оба можно собирать паралельно. хотя бы это уже даст
> возможность мне спокойно собрать какой-нибудь малюсенький python
> модуль, пока рядом собирается kde4 монстр

А если этот маленький модуль попадает в сборочную среду kde4,
то монстра придётся собирать заново.  Легко просчитаться.

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Max Ivanov]

> Потому что BuildRequires -- это не то же самое, что замыкание
> BuildRequires.  Например, для "BuildRequires: libgtk+2-devel"
> очень наивно было бы считать, что можно "заглянуть" в BuildRequires
> и сделать какие-то выводы
.
Я может чего-то не понимаю, имя на руках BuildRequires обоих пакетов,
из %package и работающий apt, можно получить список всего что надо для
сборки каждого из пакетов и если результат одного пакета не попадает в
список требований другого, то сборки могут быть параллельны.

Что может произойти такого, что один такой "паралельный" пакет вдруг
после пересборки попадет в дерево BuildRequres другого?

Re: [devel] ресурсоёмкое тестирование пакетов

[Andrey Rahmatullin]

On Mon, May 18, 2009 at 05:43:09PM +0400, Max Ivanov wrote:
> если результат одного пакета не попадает в список требований другого
То это не значит, что не попадёт после своей сборки.

> Что может произойти такого, что один такой "паралельный" пакет вдруг
> после пересборки попадет в дерево BuildRequres другого?
Изменение Provides/Requires.

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/18 Max Ivanov <ivanov.maxim@gmail.com>:
>> Потому что BuildRequires -- это не то же самое, что замыкание
>> BuildRequires.  Например, для "BuildRequires: libgtk+2-devel"
>> очень наивно было бы считать, что можно "заглянуть" в BuildRequires
>> и сделать какие-то выводы
> .
> Я может чего-то не понимаю, имя на руках BuildRequires обоих пакетов,
> из %package и работающий apt, можно получить список всего что надо для
> сборки каждого из пакетов и если результат одного пакета не попадает в
> список требований другого, то сборки могут быть параллельны.
>
> Что может произойти такого, что один такой "паралельный" пакет вдруг
> после пересборки попадет в дерево BuildRequres другого?

"параллельный" пакет может сделать Provides: coreutils = 10.0 (это для примера,
я так понимаю, такого наша сборочница не допустит, верно?) и он, если так
решит apt, попадёт в сборочную среду.

Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey Tourbin]

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

On Mon, May 18, 2009 at 05:43:09PM +0400, Max Ivanov wrote:
> > Потому что BuildRequires -- это не то же самое, что замыкание
> > BuildRequires.  Например, для "BuildRequires: libgtk+2-devel"
> > очень наивно было бы считать, что можно "заглянуть" в BuildRequires
> > и сделать какие-то выводы
> .
> Я может чего-то не понимаю, имя на руках BuildRequires обоих пакетов,
> из %package и работающий apt, можно получить список всего что надо для
> сборки каждого из пакетов и если результат одного пакета не попадает в
> список требований другого, то сборки могут быть параллельны.

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

> Что может произойти такого, что один такой "паралельный" пакет вдруг
> после пересборки попадет в дерево BuildRequres другого?

Какой-то прямо флешмоб образовался из специалистов по распараллеливанию
сборки.  Нельзя её распараллелить, грубо говоря.

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey Rusakov]

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

В Пнд, 18/05/2009 в 16:48 +0400, Victor B. Wagner пишет:
> On 2009.05.18 at 15:29:50 +0300, Kirill A. Shutemov wrote:
> 
> > 
> > ИМХО, результаты предыдущей сборки должны лучшее приближение, чем
> > подобный анализ.
> 
> Результаты предыдущей сборки в сочетании с подобным анализом дают еще
> лучшее приближение.
> 
> Если результаты анализа spec-файла совпадают с результатами анализа
> spec-файла предыдущей версии, то результаты предыдущей сборки можно
> считать достоверными практически на 100%. 
Это не так. Есть ещё одна переменная, она называется окружение сборки. Я
возьму грубый пример, но могу привести и более аккуратные. Так вот,
грубо говоря, если у нас меняются предпочтения apt'а по вытягиванию
компилятора с gcc4.3 на gcc4.4, то у нас меняются зависимости пакета.

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

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Victor B. Wagner]

On 2009.05.19 at 12:57:01 +0400, Alexey Rusakov wrote:

> Это не так. Есть ещё одна переменная, она называется окружение сборки. Я
> возьму грубый пример, но могу привести и более аккуратные. Так вот,
> грубо говоря, если у нас меняются предпочтения apt'а по вытягиванию
> компилятора с gcc4.3 на gcc4.4, то у нас меняются зависимости пакета.

Окружение сборки учитывается вышеописанной процедурой анализа
spec-файла. Потому что эта процедура включает в себя запуск buildreq.

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

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

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



> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] ресурсоёмкое тестирование пакетов

[Anton Farygin]

Alexey Rusakov пишет:
> В Пнд, 18/05/2009 в 16:48 +0400, Victor B. Wagner пишет:
>> On 2009.05.18 at 15:29:50 +0300, Kirill A. Shutemov wrote:
>>
>>> ИМХО, результаты предыдущей сборки должны лучшее приближение, чем
>>> подобный анализ.
>> Результаты предыдущей сборки в сочетании с подобным анализом дают еще
>> лучшее приближение.
>>
>> Если результаты анализа spec-файла совпадают с результатами анализа
>> spec-файла предыдущей версии, то результаты предыдущей сборки можно
>> считать достоверными практически на 100%. 
> Это не так. Есть ещё одна переменная, она называется окружение сборки. Я
> возьму грубый пример, но могу привести и более аккуратные. Так вот,
> грубо говоря, если у нас меняются предпочтения apt'а по вытягиванию
> компилятора с gcc4.3 на gcc4.4, то у нас меняются зависимости пакета.

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Victor B. Wagner]

On 2009.05.19 at 14:32:54 +0400, Anton Farygin wrote:

> Это фактически означает, что будет Сизиф собираться последовательно или 
> параллельно - не имеет никакого значения, ибо пакеты в текущей задачи 
> могут уже после выполнения следующей task потерять как и собираемость, 
> так и зависимости...

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

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Afanasov Dmitry]

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

On Mon, May 18, 2009 at 01:43:29PM +0300, Kirill A. Shutemov wrote:
> 2009/5/18 Victor B. Wagner <vitus@altlinux.org>:
> В общем случае нельзя понять как задания повлияют друг на друга до того как
> они будут собраны
не пнайте больно :) но вот читаю я и думаю: а как в make сделана
многопоточная работа? хотя ограничения меньше, это я понимаю.

-- 
С любовью,
Дима

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Damir Shayhutdinov]

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

Там все зависимости между собирающимися файлами заботливо прописаны вручную.

Re: [devel] ресурсоёмкое тестирование пакетов

[Afanasov Dmitry]

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

On Tue, May 19, 2009 at 06:51:27PM +0400, Damir Shayhutdinov wrote:
> >> В общем случае нельзя понять как задания повлияют друг на друга до того как
> >> они будут собраны
> > не пнайте больно :) но вот читаю я и думаю: а как в make сделана
> > многопоточная работа? хотя ограничения меньше, это я понимаю.
> 
> Там все зависимости между собирающимися файлами заботливо прописаны вручную.
аха, спасибо.

получается, облегчив и автоматизировав написание spec'ов, ограничили
информацию для оптимизации сборки. интересно.

но это уже JT :)
-- 
С любовью,
Дима

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey Tourbin]

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

On Tue, May 19, 2009 at 02:32:54PM +0400, Anton Farygin wrote:
> Alexey Rusakov пишет:
> >>Если результаты анализа spec-файла 
> >>совпадают с результатами анализа
> >>spec-файла предыдущей версии, то 
> >>результаты предыдущей сборки можно
> >>считать достоверными практически на 100%. 
> >Это не так. Есть ещё одна переменная, она 
> >называется окружение сборки. Я
> >возьму грубый пример, но могу привести и 
> >более аккуратные. Так вот,
> >грубо говоря, если у нас меняются 
> >предпочтения apt'а по вытягиванию
> >компилятора с gcc4.3 на gcc4.4, то у нас 
> >меняются зависимости пакета.
> 
> Это фактически означает, что будет Сизиф 
> собираться последовательно или 
> параллельно - не имеет никакого значения, 
> ибо пакеты в текущей задачи могут уже 
> после выполнения следующей task потерять 
> как и собираемость, так и зависимости...

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

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

Тестовая пересборка сизифа для каждого задания -- это очень круто (то
есть, это challenge).  Дольно сложно будет реализовать её оптимально.
С другой стороны, тестовая пересборка дает наиболее полное представление
о целостности репозитария (то есть, дает комплексную оценку пригодности
пакетов).  Мы же не в крестики-нолики играем, а хотим поддерживать
целостный репозитарий.  Это дорогое развлечение.

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Anton Farygin]

Alexey Tourbin пишет:
> А также ясно, что основная проблема с ресурсами и с распараллеливанием
> лежит в другой плоскости.  Она связана не со сборкой самих заданий, а с
> тестовой пересборкой репозитария для каждого задания.
> 
> Тестовая пересборка сизифа для каждого задания -- это очень круто (то
> есть, это challenge).  Дольно сложно будет реализовать её оптимально.
> С другой стороны, тестовая пересборка дает наиболее полное представление
> о целостности репозитария (то есть, дает комплексную оценку пригодности
> пакетов).  Мы же не в крестики-нолики играем, а хотим поддерживать
> целостный репозитарий.  Это дорогое развлечение.

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

Например, после появления glibc, каждый пересобранный пакет уже не равен 
существующему пакету в репозитории (по зависимостям).

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

Тогда можно и параллелить (аккуратно, естественно).

Да, а железа для этого нужно, судя по всему - раз в 50 больше, чем 
сейчас. С учётом того, что сейчас пересборка сизифа занимает порядка 
трёх суток (72 часа), а мы не можем допустить, что бы у нас пакет 
собирался более чем разумное время (в данном контексте, думаю, один час 
- вполне разумно), то текущее количество сборочных серверов нужно 
умножить на 72 (на самом деле - больше, нужно считать overhead на 
постановку задач/сеть).

С учётом того, что в данный момент (по словам ldv) задействовано 4 
сервера, для полной автоматизации этого процесса необходимо порядка 288 
серверов.

Это чуть меньше половины кластера СКИФ Т-60, который считается одним из 
самых мощных в России и стоил порядка 10 миллионов долларов. И 
потребляет порядка 0.5 мегаватта энергии в час.

Без оптимизации или без спонсора, явно - не обойтись ;) Ни у кого нет 
подруги - дочери нефтяного магната ?

Re: [devel] ресурсоёмкое тестирование пакетов

[Victor B. Wagner]

On 2009.05.19 at 19:01:11 +0400, Afanasov Dmitry wrote:

> > Там все зависимости между собирающимися файлами заботливо прописаны вручную.
> аха, спасибо.
> 
> получается, облегчив и автоматизировав написание spec'ов, ограничили
> информацию для оптимизации сборки. интересно.

Нет, тут дело в том, что вообще используются спеки и формат rpm.
В deb с этим намного проще. Там зависимости куда более формализованы.

Re: [devel] ресурсоёмкое тестирование пакетов

[Damir Shayhutdinov]

>> получается, облегчив и автоматизировав написание spec'ов, ограничили
>> информацию для оптимизации сборки. интересно.
>
> Нет, тут дело в том, что вообще используются спеки и формат rpm.
> В deb с этим намного проще. Там зависимости куда более формализованы.

В каком смысле? Чем отличаются зависимости в .deb от .rpm, с точки
зрения распараллеливания процесса сборки пакетов?

Re: [devel] ресурсоёмкое тестирование пакетов

[Mikhail Gusarov]

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


Twas brillig at 12:23:04 20.05.2009 UTC+04 when damir@altlinux.org did gyre and gimble:

 >> Нет, тут дело в том, что вообще используются спеки и формат rpm.  В
 >> deb с этим намного проще. Там зависимости куда более формализованы.

 DS> В каком смысле? Чем отличаются зависимости в .deb от .rpm, с точки
 DS> зрения распараллеливания процесса сборки пакетов?

Для их определения не нужно ничего собирать.

-- 

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Max Ivanov]

>
> Для их определения не нужно ничего собирать.

Ого, а как это устроено?

Re: [devel] ресурсоёмкое тестирование пакетов

[Mikhail Gusarov]

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


Twas brillig at 13:07:01 20.05.2009 UTC+04 when ivanov.maxim@gmail.com did gyre and gimble:

 >> Для их определения не нужно ничего собирать.
 MI> Ого, а как это устроено?

Отсутствием макросов в debian/control

Из-за этого билд-зависимости не плывут в зависимости от окружения.

-- 

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/20 Mikhail Gusarov <dottedmag@altlinux.org>:
>
> Twas brillig at 13:07:01 20.05.2009 UTC+04 when ivanov.maxim@gmail.com did gyre and gimble:
>
>  >> Для их определения не нужно ничего собирать.
>  MI> Ого, а как это устроено?
>
> Отсутствием макросов в debian/control
>
> Из-за этого билд-зависимости не плывут в зависимости от окружения.

Ээ.. Не совсем понимаю, как этого можно добиться.

Допустим, что в BuildRequires прописываются все без сокращения билд-зависимости.
Что случится, если у одного из пакета входящего в этот список после обновления
появилась новая зависимость? Билд-зависимости поплыли? Или вы вкладываете
другое значение в это понятие?

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Mikhail Gusarov]

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


Twas brillig at 12:22:50 20.05.2009 UTC+03 when kirill@shutemov.name did gyre and gimble:

 KAS> Допустим, что в BuildRequires прописываются все без сокращения
 KAS> билд-зависимости.  Что случится, если у одного из пакета входящего
 KAS> в этот список после обновления появилась новая зависимость?

Разъясни, что такое "после обновление" и "появилась".

 KAS> Мне кажется, что в Дебиане, просто, по тем или иным причинам,
 KAS> менее ответственно подходят к воспроизводимости сборки.

Это пример т.н. "навета".

-- 

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Aleksey Novodvorsky]

20 мая 2009 г. 13:24 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
>
> Twas brillig at 12:22:50 20.05.2009 UTC+03 when kirill@shutemov.name did gyre and gimble:
>
>  KAS> Допустим, что в BuildRequires прописываются все без сокращения
>  KAS> билд-зависимости.  Что случится, если у одного из пакета входящего
>  KAS> в этот список после обновления появилась новая зависимость?
>
> Разъясни, что такое "после обновление" и "появилась".
>
>  KAS> Мне кажется, что в Дебиане, просто, по тем или иным причинам,
>  KAS> менее ответственно подходят к воспроизводимости сборки.
>
> Это пример т.н. "навета".

1. Это предположение, а не утверждение.
2. Флейм начинаете Вы, привнося в корректную дисуссию этические оценки.
3. Несколько странно именно Вам говорить про "наветы".


Давайте спокойно разберемся, без обвинений.

Rgrds, Алексей

Re: [devel] ресурсоёмкое тестирование пакетов

[Mikhail Gusarov]

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


Twas brillig at 13:32:01 20.05.2009 UTC+04 when aen@altlinux.ru did gyre and gimble:

 AN> 2. Флейм начинаете Вы, привнося в корректную дисуссию этические оценки.

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

-- 

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill Maslinsky]

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

On Wed, May 20, 2009 at 12:22:50PM +0300, Kirill A. Shutemov wrote:
> 2009/5/20 Mikhail Gusarov <dottedmag@altlinux.org>:
> >
> > Twas brillig at 13:07:01 20.05.2009 UTC+04 when ivanov.maxim@gmail.com did gyre and gimble:
> >
> >  >> Для их определения не нужно ничего собирать.
> >  MI> Ого, а как это устроено?
> >
> > Отсутствием макросов в debian/control
> >
> > Из-за этого билд-зависимости не плывут в зависимости от окружения.
> 
> Ээ.. Не совсем понимаю, как этого можно добиться.

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

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

-- 
Kirill Maslinsky
ALT Linux Team

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/20 Mikhail Gusarov <dottedmag@altlinux.org>:
>
> Twas brillig at 12:22:50 20.05.2009 UTC+03 when kirill@shutemov.name did gyre and gimble:
>
>  KAS> Допустим, что в BuildRequires прописываются все без сокращения
>  KAS> билд-зависимости.  Что случится, если у одного из пакета входящего
>  KAS> в этот список после обновления появилась новая зависимость?
>
> Разъясни, что такое "после обновление" и "появилась".

Есть пакет p. У него замыкание сборочных зависимостей состоит из
пакетов a, b, c.
Все они прописаны в сборочных зависимостях пакета p. В репозиторий собирается
новая версия пакета a, которая после сборки стала зависить от пакета a1. Таким
образом, замыкание сборочных зависимостей пакета p теперь состоит из пакетов
 a, b, c, a1, хоть это и не прописано в сборочных зависимостях пакета p.

Это называется "поплыли" или нет?

Re: [devel] ресурсоёмкое тестирование пакетов

[Afanasov Dmitry]

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

On Wed, May 20, 2009 at 12:22:50PM +0300, Kirill A. Shutemov wrote:
> 2009/5/20 Mikhail Gusarov <dottedmag@altlinux.org>:
> >
> > Twas brillig at 13:07:01 20.05.2009 UTC+04 when ivanov.maxim@gmail.com did gyre and gimble:
> >
> >  >> Для их определения не нужно ничего собирать.
> >  MI> Ого, а как это устроено?
> >
> > Отсутствием макросов в debian/control
> >
> > Из-за этого билд-зависимости не плывут в зависимости от окружения.
> 
> Ээ.. Не совсем понимаю, как этого можно добиться.
легко:
%{_with_tls:BuildRequires: libssl-devel}
и это ещё простая конструкция и только на примере BuildRequires. окромя
этого есть ещё нигде в спеке не прописанные и автогенерируемые Provides.

простой пример:
- вот спрятали за %if'ом BuildRequires: либа
- ./configure библиотеку не нашел и не собрал бинарник
- все нормально упаковалось по %_bindir/*
- /usr/lib/rpm/*.prov бинарник не нашел и не прописал его в Provides
- пакетина, у которого в BuildRequires нарисованы Provides "от того" бинарника не собралась.

как я понимаю, вся проблема в этих самых неизвестных связках
[Build]Requires/Provides. подставили макрос в одном пакете, в другого
изменился BuildRequires, у третьего сломался Provides. брр :)
-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill Maslinsky]

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

On Wed, May 20, 2009 at 04:08:40PM +0700, Mikhail Gusarov wrote:
> 
> Twas brillig at 13:07:01 20.05.2009 UTC+04 when ivanov.maxim@gmail.com did gyre and gimble:
> 
>  >> Для их определения не нужно ничего собирать.
>  MI> Ого, а как это устроено? 

> Отсутствием макросов в debian/control
Дело тут не в макросах,

> Из-за этого билд-зависимости не плывут в зависимости от окружения.
а принципиальной (не)зависимости от сборочного окружения, см.
http://lists.altlinux.org/pipermail/devel/2009-May/170894.html

-- 
Kirill Maslinsky
ALT Linux Team

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Mikhail Gusarov]

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


Twas brillig at 12:38:15 20.05.2009 UTC+03 when kirill@shutemov.name did gyre and gimble:

 KAS> Это называется "поплыли" или нет?

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

Поплыли - это когда python2.4 меняется на python2.5 непосредственно в
source-пакете из-за обновления rpm-build-python.

-- 

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Victor B. Wagner]

On 2009.05.20 at 16:08:40 +0700, Mikhail Gusarov wrote:

> 
> Twas brillig at 13:07:01 20.05.2009 UTC+04 when ivanov.maxim@gmail.com did gyre and gimble:
> 
>  >> Для их определения не нужно ничего собирать.
>  MI> Ого, а как это устроено?
> 
> Отсутствием макросов в debian/control

Мне тут недавно попадался по крайней мере один debian-пакет, у которого
debian/control был препроцессируемым. То есть отсутствовал control, но
был control.in. 

Re: [devel] ресурсоёмкое тестирование пакетов

[Dmitry V. Levin]

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

On Wed, May 20, 2009 at 03:24:20PM +0700, Mikhail Gusarov wrote:
> Twas brillig at 12:23:04 20.05.2009 UTC+04 when damir@altlinux.org did gyre and gimble:
> 
>  >> Нет, тут дело в том, что вообще используются спеки и формат rpm.  В
>  >> deb с этим намного проще. Там зависимости куда более формализованы.
> 
>  DS> В каком смысле? Чем отличаются зависимости в .deb от .rpm, с точки
>  DS> зрения распараллеливания процесса сборки пакетов?
> 
> Для их определения не нужно ничего собирать.

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


-- 
ldv

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Dmitry V. Levin]

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

On Wed, May 20, 2009 at 09:41:55AM +0400, Anton Farygin wrote:
> Alexey Tourbin пишет:
[...]
> >Тестовая пересборка сизифа для каждого 
> >задания -- это очень круто (то
> >есть, это challenge).  Дольно сложно будет 
> >реализовать её оптимально.
> >С другой стороны, тестовая пересборка 
> >дает наиболее полное представление
> >о целостности репозитария (то есть, дает 
> >комплексную оценку пригодности
> >пакетов).  Мы же не в крестики-нолики 
> >играем, а хотим поддерживать
> >целостный репозитарий.  Это дорогое 
> >развлечение.
[...]
> Да, а железа для этого нужно, судя по 
> всему - раз в 50 больше, чем сейчас. С 
> учётом того, что сейчас пересборка 
> сизифа занимает порядка трёх суток (72 
> часа), а мы не можем допустить, что бы у 
> нас пакет собирался более чем разумное 
> время (в данном контексте, думаю, один час 
> - вполне разумно), то текущее количество 
> сборочных серверов нужно умножить на 72 
> (на самом деле - больше, нужно считать 
> overhead на постановку задач/сеть).

По моим расчётам, для того, чтобы пересобирать Сизиф со скоростью сборки
пакета, собирающегося дольше всех (т.е. чтобы параллельно со сборкой этого
пакета была проведена сборка остальных пакетов), требуется около 64
современных ядер с 1G (лучше 2G) памяти на каждое ядро.  Это не так много.
Если бы не кидняк со стороны одного вполне осязаемого человека, то требуемая
техника уже давно бы работала на Сизиф.  Ну а сейчас, вместо этого,
техника пылится на складе, а мы тратим время на легковесные обсуждения.


-- 
ldv

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Aleksey Novodvorsky]

20.05.09, Mikhail Gusarov<dottedmag@altlinux.org> написал(а):
>
>  Twas brillig at 13:32:01 20.05.2009 UTC+04 when aen@altlinux.ru did gyre and gimble:
>
>   AN> 2. Флейм начинаете Вы, привнося в корректную дисуссию этические оценки.
>
>  В *этом* сообществе после любых плохих слов о Debian любое обсуждение
>  сворачивается с диагнозом "у них всё плохо, а мы все в белом", вне
>  зависимости от темы обсуждения. Следовательно, *здесь* такой отпор
>  необходим.

1. Не припомню такого.
2. В любом случае, сейчас не было сказано ни одного дурного слова о
Debian, был задан вопрос и высказано личное предположение. На вопрос
Вы ответили вопросом, а предположение сочли за навет. Не думаю, что
это правильно.

Rgrds, Алексей

Re: [devel] ресурсоёмкое тестирование пакетов

[Dmitry V. Levin]

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

On Wed, May 20, 2009 at 02:40:10PM +0400, Aleksey Novodvorsky wrote:
> 20.05.09, Mikhail Gusarov<dottedmag@altlinux.org> написал(а):
> >  Twas brillig at 13:32:01 20.05.2009 UTC+04 when aen@altlinux.ru did gyre and gimble:
> >
> >   AN> 2. Флейм начинаете Вы, привнося в корректную дисуссию этические оценки.
> >
> >  В *этом* сообществе после любых плохих слов о Debian любое обсуждение
> >  сворачивается с диагнозом "у них всё плохо, а мы все в белом", вне
> >  зависимости от темы обсуждения. Следовательно, *здесь* такой отпор
> >  необходим.
> 
> 1. Не припомню такого.
> 2. В любом случае, сейчас не было сказано ни одного дурного слова о
> Debian, был задан вопрос и высказано личное предположение. На вопрос
> Вы ответили вопросом, а предположение сочли за навет. Не думаю, что
> это правильно.

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


-- 
ldv

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Mikhail Gusarov]

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


Twas brillig at 14:02:26 20.05.2009 UTC+04 when vitus@altlinux.org did gyre and gimble:

 VBW> Мне тут недавно попадался по крайней мере один debian-пакет, у
 VBW> которого debian/control был препроцессируемым. То есть
 VBW> отсутствовал control, но был control.in.

Главное, что в source-пакете есть debian/control. А как он обновляется
из развёрнутого дерева исходников - руками, или автоматом - это дело
десятое

-- 

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Damir Shayhutdinov]

>  VBW> Мне тут недавно попадался по крайней мере один debian-пакет, у
>  VBW> которого debian/control был препроцессируемым. То есть
>  VBW> отсутствовал control, но был control.in.
>
> Главное, что в source-пакете есть debian/control. А как он обновляется
> из развёрнутого дерева исходников - руками, или автоматом - это дело
> десятое

Тогда build-зависимости .src.rpm в этом полностью идентичны debian/control.
ибо rpm -qRp <пакет.src.rpm> не меняется от окружения.

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/20 Damir Shayhutdinov <damir@altlinux.org>:
>>  VBW> Мне тут недавно попадался по крайней мере один debian-пакет, у
>>  VBW> которого debian/control был препроцессируемым. То есть
>>  VBW> отсутствовал control, но был control.in.
>>
>> Главное, что в source-пакете есть debian/control. А как он обновляется
>> из развёрнутого дерева исходников - руками, или автоматом - это дело
>> десятое
>
> Тогда build-зависимости .src.rpm в этом полностью идентичны debian/control.
> ибо rpm -qRp <пакет.src.rpm> не меняется от окружения.

К сожалению, синтаксис билд-зависимостей в (alt-?)rpm не позволяет
записывать архитектурно-зависимые BuildRequires, не оборачивая их
в %ifarch. Для таких случаев мне приходится собирать с --query-repackage
на ARM, что не есть хорошо.

Давайте выкинем srpm'ы, а? ;)

Re: [devel] ресурсоёмкое тестирование пакетов

[Andrey Rahmatullin]

On Wed, May 20, 2009 at 03:20:22PM +0300, Kirill A. Shutemov wrote:
> Давайте выкинем srpm'ы, а? ;)
А ещё не?

Re: [devel] ресурсоёмкое тестирование пакетов

[Damir Shayhutdinov]

>> Тогда build-зависимости .src.rpm в этом полностью идентичны debian/control.
>> ибо rpm -qRp <пакет.src.rpm> не меняется от окружения.
>
> К сожалению, синтаксис билд-зависимостей в (alt-?)rpm не позволяет
> записывать архитектурно-зависимые BuildRequires, не оборачивая их
> в %ifarch. Для таких случаев мне приходится собирать с --query-repackage
> на ARM, что не есть хорошо.
>
> Давайте выкинем srpm'ы, а? ;)

Дык а что вместо него? Выяснили же, что .deb - те же грабли. .tar
генерируемый .gear?
А как его на диски класть, и на ftp?

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/20 Damir Shayhutdinov <damir@altlinux.org>:
>>> Тогда build-зависимости .src.rpm в этом полностью идентичны debian/control.
>>> ибо rpm -qRp <пакет.src.rpm> не меняется от окружения.
>>
>> К сожалению, синтаксис билд-зависимостей в (alt-?)rpm не позволяет
>> записывать архитектурно-зависимые BuildRequires, не оборачивая их
>> в %ifarch. Для таких случаев мне приходится собирать с --query-repackage
>> на ARM, что не есть хорошо.
>>
>> Давайте выкинем srpm'ы, а? ;)
>
> Дык а что вместо него? Выяснили же, что .deb - те же грабли. .tar
> генерируемый .gear?
> А как его на диски класть, и на ftp?

Пока это лишь юмор.

Пока srpm'ы можно отправлять на сборку, от них никуда не деться.
Потом всё будет в http://git.altlinux.org/gears/.

Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey Tourbin]

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

On Wed, May 20, 2009 at 09:41:55AM +0400, Anton Farygin wrote:
> Alexey Tourbin пишет:
> >А также ясно, что основная проблема с 
> >ресурсами и с распараллеливанием
> >лежит в другой плоскости.  Она связана не 
> >со сборкой самих заданий, а с
> >тестовой пересборкой репозитария для 
> >каждого задания.
> >
> >Тестовая пересборка сизифа для каждого 
> >задания -- это очень круто (то
> >есть, это challenge).  Дольно сложно будет 
> >реализовать её оптимально.
> >С другой стороны, тестовая пересборка 
> >дает наиболее полное представление
> >о целостности репозитария (то есть, дает 
> >комплексную оценку пригодности
> >пакетов).  Мы же не в крестики-нолики 
> >играем, а хотим поддерживать
> >целостный репозитарий.  Это дорогое 
> >развлечение.
> 
> Кстати, тогда уж целью стоит объявлять 
> выявление и устранение изменений в 
> результатах пересборки после каждого 
> нового пакета.
> 
> Например, после появления glibc, каждый 
> пересобранный пакет уже не равен 
> существующему пакету в репозитории (по 
> зависимостям).

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

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

С философской точки зрения, метарепозитарий позволяет частично
предсказывать будущее; точнее, делать наиболее обоснованные
предсказания.  Эти предсказания полностью никогда сбываться не будут,
но у них будет правильное направление.  Я не буду подробнее
останавливаться на философских аспектах.

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

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

> Тогда можно и параллелить (аккуратно, 
> естественно).

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

> Да, а железа для этого нужно, судя по 
> всему - раз в 50 больше, чем сейчас. С 
> учётом того, что сейчас пересборка 
> сизифа занимает порядка трёх суток (72 
> часа), а мы не можем допустить, что бы у 
> нас пакет собирался более чем разумное 
> время (в данном контексте, думаю, один час 
> - вполне разумно), то текущее количество 
> сборочных серверов нужно умножить на 72 
> (на самом деле - больше, нужно считать 
> overhead на постановку задач/сеть).

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

Для одной архитектуры получается оценка 57 процессорных ядер (в
предположении, что ядра дают линейное распараллеливание).

> С учётом того, что в данный момент (по 
> словам ldv) задействовано 4 сервера, для 
> полной автоматизации этого процесса 
> необходимо порядка 288 серверов.

Для полной пересборки сизифа на двух архитектурах требуется 57*2=114
ядер, в большую сторону это округляются до 128.  Следовательно требуется
32 четырехядерных процессора.  Я беру процессоры класса Nehalem Xeon,
потому что другие процессоры брать нет смысла.  Это получается 16
двухпроцессорных лезвий.  Теперь можно округлить в меньшую сторону.
Сейчас выпускаются корпуса высотой 7U, в которые входит 10 лезвий.
Это примерно то, что нам нужно.

Впрочем, я не специалист по железу.

> Это чуть меньше половины кластера СКИФ 
> Т-60, который считается одним из самых 
> мощных в России и стоил порядка 10 
> миллионов долларов. И потребляет порядка 
> 0.5 мегаватта энергии в час.

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

Посмотрим, сколько это _минимум_ может стоить.  Процессор Xeon E5520
стоит $457, к нему нужно минимум 12G памяти.  12G DDR-III kit стоит $265.
Всего нужно 32 таких комплекта.  Получается 32*(457+265)=$23k на
микросхемы.  Цена всего вместе может быть где-то в районе $50k.
Дорого это или очень дорого?  Я не знаю.  Автомобиль, могущий
производить впечатление на красивых женщин, стоит примерно столько же.

> Без оптимизации или без спонсора, явно - 
> не обойтись ;) Ни у кого нет подруги - 
> дочери нефтяного магната ?

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey I. Froloff]

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

* Damir Shayhutdinov <damir@> [090520 16:35]:
> > Давайте выкинем srpm'ы, а? ;)
> Дык а что вместо него? Выяснили же, что .deb - те же грабли. .tar
> генерируемый .gear?
> А как его на диски класть, и на ftp?
Как %name-%version-%release.gear ;-)

-- 
Regards,
Sir Raorn.

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Afanasov Dmitry]

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

On Wed, May 20, 2009 at 04:48:12PM +0400, Alexey I. Froloff wrote:
> * Damir Shayhutdinov <damir@> [090520 16:35]:
> > > Давайте выкинем srpm'ы, а? ;)
> > Дык а что вместо него? Выяснили же, что .deb - те же грабли. .tar
> > генерируемый .gear?
> > А как его на диски класть, и на ftp?
> Как %name-%version-%release.gear ;-)
и в apt'е прописывать
gear fpt://ftp.altlinux.org/... i586 classic :)

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

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Victor B. Wagner]

On 2009.05.20 at 15:20:22 +0300, Kirill A. Shutemov wrote:

> 2009/5/20 Damir Shayhutdinov <damir@altlinux.org>:
> > Тогда build-зависимости .src.rpm в этом полностью идентичны debian/control.
> > ибо rpm -qRp <пакет.src.rpm> не меняется от окружения.
> 
> К сожалению, синтаксис билд-зависимостей в (alt-?)rpm не позволяет
> записывать архитектурно-зависимые BuildRequires, не оборачивая их
> в %ifarch. Для таких случаев мне приходится собирать с --query-repackage
> на ARM, что не есть хорошо.
> 
> Давайте выкинем srpm'ы, а? ;)

Может лучше написать парсилку спеков, которая будет реализовывать
подмножество языка rpm, достаточное для корректного определения
build-зависимостей?

Re: [devel] ресурсоёмкое тестирование пакетов

[Mikhail Gusarov]

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


Twas brillig at 18:56:49 20.05.2009 UTC+04 when vitus@altlinux.org did gyre and gimble:

 VBW> Может лучше написать парсилку спеков, которая будет реализовывать
 VBW> подмножество языка rpm, достаточное для корректного определения
 VBW> build-зависимостей?

Для начала эта парсилка будет обязана обрабатывать макросы.

-- 

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Afanasov Dmitry]

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

On Wed, May 20, 2009 at 06:56:49PM +0400, Victor B. Wagner wrote:
> On 2009.05.20 at 15:20:22 +0300, Kirill A. Shutemov wrote:
> 
> > 2009/5/20 Damir Shayhutdinov <damir@altlinux.org>:
> > > Тогда build-зависимости .src.rpm в этом полностью идентичны debian/control.
> > > ибо rpm -qRp <пакет.src.rpm> не меняется от окружения.
> > 
> > К сожалению, синтаксис билд-зависимостей в (alt-?)rpm не позволяет
> > записывать архитектурно-зависимые BuildRequires, не оборачивая их
> > в %ifarch. Для таких случаев мне приходится собирать с --query-repackage
> > на ARM, что не есть хорошо.
> 
> Может лучше написать парсилку спеков, которая будет реализовывать
> подмножество языка rpm, достаточное для корректного определения
> build-зависимостей?
что самое интересное, эта парсилка очень бы пригодилась для указания rpm
макросов в .gear/rules. не всегда достаточно @name@, @version@ и @release@
:)
-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/20 Mikhail Gusarov <dottedmag@altlinux.org>:
>
> Twas brillig at 18:56:49 20.05.2009 UTC+04 when vitus@altlinux.org did gyre and gimble:
>
>  VBW> Может лучше написать парсилку спеков, которая будет реализовывать
>  VBW> подмножество языка rpm, достаточное для корректного определения
>  VBW> build-зависимостей?
>
> Для начала эта парсилка будет обязана обрабатывать макросы.

Да, и эта парсилка будет называться rpm. И запускать на написаных не мно

Re: [devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/20 Mikhail Gusarov <dottedmag@altlinux.org>:
>
> Twas brillig at 18:56:49 20.05.2009 UTC+04 when vitus@altlinux.org did gyre and gimble:
>
>  VBW> Может лучше написать парсилку спеков, которая будет реализовывать
>  VBW> подмножество языка rpm, достаточное для корректного определения
>  VBW> build-зависимостей?
>
> Для начала эта парсилка будет обязана обрабатывать макросы.

Да, и эта парсилка будет называться rpm. И запускать её на спеках не из
доверенного источника на своём хосте я не рискну.

Re: [devel] ресурсоёмкое тестирование пакетов

[Igor Vlasenko]

On Wed, May 20, 2009 at 07:04:36PM +0400, Afanasov Dmitry wrote:
> > Может лучше написать парсилку спеков, которая будет реализовывать
> > подмножество языка rpm, достаточное для корректного определения
> > build-зависимостей?
> что самое интересное, эта парсилка очень бы пригодилась для указания rpm
> макросов в .gear/rules. не всегда достаточно @name@, @version@ и @release@

например,
RPM::Source::Editor умеет вычитывать из спека макросы.

-- 

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Igor Vlasenko]

On Wed, May 20, 2009 at 03:38:03PM +0300, Kirill A. Shutemov wrote:
> Пока srpm'ы можно отправлять на сборку, от них никуда не деться.
> Потом всё будет в http://git.altlinux.org/gears/.

gears штука хорошая, но не уверен, что нужно стремиться пихать туда все.
например, я сейчас собираю через gear менее 50 своих пакетов, 
до 100 своих пакетов буду собирать через gear в перспективе,
а остальные пока будут только через srpm.

-- 

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Afanasov Dmitry]

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

On Thu, May 21, 2009 at 06:02:05PM +0300, Igor Vlasenko wrote:
> On Wed, May 20, 2009 at 07:04:36PM +0400, Afanasov Dmitry wrote:
> > > Может лучше написать парсилку спеков, которая будет реализовывать
> > > подмножество языка rpm, достаточное для корректного определения
> > > build-зависимостей?
> > что самое интересное, эта парсилка очень бы пригодилась для указания rpm
> > макросов в .gear/rules. не всегда достаточно @name@, @version@ и @release@
> 
> например,
> RPM::Source::Editor умеет вычитывать из спека макросы.
спасибо, даже не догадывался.

обязательно посмотрю.
-- 
С уважением
Афанасов Дмитрий

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

[devel] [JT] BR drift (was: ресурсоёмкое тестирование пакетов)

[Michael Shigorin]

On Wed, May 20, 2009 at 04:41:55PM +0700, Mikhail Gusarov wrote:
> Поплыли - это когда python2.4 меняется на python2.5
> непосредственно в source-пакете из-за обновления
> rpm-build-python.

Здрасьте, это как раз фича, которой можно и не пользоваться.
Прибиваешь себе гвоздиком -- и никаких гвоздей.  Если надо.

PS: а ещё есть слакваристы, любящие ругать зависимости.
Как если бы ими тоже обязательно было пользоваться. :)

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

Re: [devel] [JT] BR drift

[Mikhail Gusarov]

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


Twas brillig at 20:16:43 24.05.2009 UTC+03 when mike@osdn.org.ua did gyre and gimble:

 >> Поплыли - это когда python2.4 меняется на python2.5
 >> непосредственно в source-пакете из-за обновления
 >> rpm-build-python.

 MS> Здрасьте, это как раз фича, которой можно и не пользоваться.

Я не высказывал никаких оценок, и не говорил, фича это или баг.

-- 

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

Re: [devel] [JT] BR drift

[Michael Shigorin]

On Mon, May 25, 2009 at 12:18:47AM +0700, Mikhail Gusarov wrote:
>  >> Поплыли - это когда python2.4 меняется на python2.5
>  >> непосредственно в source-пакете из-за обновления
>  >> rpm-build-python.
>  MS> Здрасьте, это как раз фича, которой можно и не пользоваться.
> Я не высказывал никаких оценок

Аналогично :)

> и не говорил, фича это или баг.

Ну для меня "поплыли" -- это в сторону багов, потому и уточнил.

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

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

Re: [devel] ресурсоёмкое тестирование пакетов

[Michael Shigorin]

ой, забыл в postponed

On Mon, May 18, 2009 at 04:24:18PM +0400, Victor B. Wagner wrote:
> Это опять же отнюдь не бессмыслено. Стопроцентной гарантии не
> дает, но существенные хинты дает.

2 at: тебе может быть интересно почитать про ТРИЗ -- теорию
решения изобретательских задач.  Моя бумажная книжка, если
не ошибаюсь -- у week@, даже древний ISBN не скажу.

В частности, там были сформулированы такие полезные приёмы:

- сделай заранее
- сделай не полностью

И ещё помогает сформулировать противоречие в явном виде.

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

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

Повторю старое заклинание: перфекционизм нередко вреден. :)

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

Re: [devel] [jt] ресурсоёмкое тестирование пакетов

[Dmitry V. Levin]

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

On Tue, May 26, 2009 at 11:34:10PM +0300, Michael Shigorin wrote:
[...]
> Повторю старое заклинание: перфекционизм нередко вреден. :)

Что вреднее, перфекционизм или misdesign?  Только без сказок про
промежуточные состояния, пожалуйста. ;)


-- 
ldv

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

Re: [devel] [jt] ресурсоёмкое тестирование пакетов

[Mikhail Gusarov]

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


Twas brillig at 01:53:49 27.05.2009 UTC+04 when ldv@altlinux.org did gyre and gimble:

 >> Повторю старое заклинание: перфекционизм нередко вреден. :)

 DVL> Что вреднее, перфекционизм или misdesign?  Только без сказок про
 DVL> промежуточные состояния, пожалуйста. ;)

Т.е. утверждается, что промежуточных состояний не существует? Это как
минимум на премию Тьюринга тянет. Ты уже подал документы? :)

-- 

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

Re: [devel] [jt] ресурсоёмкое тестирование пакетов

[George V. Kouryachy]

On Wed, May 27, 2009 at 05:02:15AM +0700, Mikhail Gusarov wrote:
> 
> Twas brillig at 01:53:49 27.05.2009 UTC+04 when ldv@altlinux.org did gyre and gimble:
> 
 >>> Повторю старое заклинание: перфекционизм нередко вреден. :)
> 
 DVL>> Что вреднее, перфекционизм или misdesign?  Только без сказок про
 DVL>> промежуточные состояния, пожалуйста. ;)
> 
> Т.е. утверждается, что промежуточных состояний не существует? Это как
> минимум на премию Тьюринга тянет. Ты уже подал документы? :)
Не существует промежуточных состояний. Как нет их между правильным и
неправильным решением уравнения. Что существует -- это разделение работ
на ядро, требующее жёсткого перфекционизма, и приложения, касательно
которых перфекционизм будет каждый раз свой. Только вот алгоритма такого
разделения тоже не существует :(.

-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_org

Re: [devel] [jt] ресурсоёмкое тестирование пакетов

[Mikhail Gusarov]

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


Twas brillig at 21:28:04 01.06.2009 UTC+04 when george@altlinux.org did gyre and gimble:

 >> Т.е. утверждается, что промежуточных состояний не существует? Это как
 >> минимум на премию Тьюринга тянет. Ты уже подал документы? :)
 GVK> Не существует промежуточных состояний. Как нет их между правильным и
 GVK> неправильным решением уравнения.

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

-- 

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

Re: [devel] [jt] ресурсоёмкое тестирование пакетов

[George V. Kouryachy]

On Tue, Jun 02, 2009 at 12:32:00AM +0700, Mikhail Gusarov wrote:
 >>> Т.е. утверждается, что промежуточных состояний не существует? Это как
 >>> минимум на премию Тьюринга тянет. Ты уже подал документы? :)
 GVK>> Не существует промежуточных состояний. Как нет их между правильным и
 GVK>> неправильным решением уравнения.
> 
> Ты забыл, что здесь уравнение не задано, и перфекционизм - это решение
> не того уравнения, которое нужно для достижения каких-то (желательно
> явно выписанных) целей, а другого, значительно более сложного.
Наоборот, если есть явно выписанные цели, можно составить 100%
тестовое покрытие.

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

-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_org

Re: [devel] ресурсоёмкое тестирование пакетов

[Michael Shigorin]

On Tue, May 26, 2009 at 11:34:10PM +0300, I wrote:
> Повторю старое заклинание: перфекционизм нередко вреден. :)

(копая архивы)

И вот ещё, чтоб меня одного не обвиняли в неперфекционизме :)

---
Perfection is the enemy of progress and of success. We risk
moving back to the case we got into in 2.4 when merging got
so hard that most vendors shipped kernels bearing no relationship
to the "upstream" tree.
---

Это сказал Alan Cox, а я процитировал в том же обсуждении:
http://lists.altlinux.org/pipermail/devel/2006-June/127453.html

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