[devel] Получение версии из spec-файла

[devel] Получение версии из spec-файла

[Dmitriy M. Maslennikov]

В ходе решения своих задач я натолкнулся на проблему, решить которую
оказалось очень не просто (я пока не смог).
Мне необходимо из спек-файла получать версию и релиз пакета.
Желательно делать это программно.
Сначала я попытался сделать это вызовом
rpm -q --qf "%{serial}:%{version}-%{release}" --specfile "<spec-file-name>"
с дальнейшим парсингом первой строки вывода. Кроме того, что это не
удобно, эта операция завершается с ошибкой, если встречается макрос
поставляемый пакетом, не стоящим в системе (но указанным как
"BuildRequires(pre)").
Может кто знает способ получения необходимой мне информации? Особенно
интересуют идеи по обходу проблемы с недостающими макросами.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Получение версии из spec-файла

[Dmitry V. Levin]

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

On Thu, May 08, 2008 at 05:32:11PM +0400, Dmitriy M. Maslennikov wrote:
> В ходе решения своих задач я натолкнулся на проблему, решить которую
> оказалось очень не просто (я пока не смог).
> Мне необходимо из спек-файла получать версию и релиз пакета.

Исходного или бинарных?

> Желательно делать это программно.
> Сначала я попытался сделать это вызовом
> rpm -q --qf "%{serial}:%{version}-%{release}" --specfile "<spec-file-name>"
> с дальнейшим парсингом первой строки вывода. Кроме того, что это не
> удобно, эта операция завершается с ошибкой, если встречается макрос
> поставляемый пакетом, не стоящим в системе (но указанным как
> "BuildRequires(pre)").
> Может кто знает способ получения необходимой мне информации? Особенно
> интересуют идеи по обходу проблемы с недостающими макросами.

Самый простой и надёжный способ -- собрать srpm-пакет в hasher'е и дальше
извлечь из его заголовка необходимую информацию.


-- 
ldv

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

Re: [devel] Получение версии из spec-файла

[Dmitriy M. Maslennikov]

08.05.08, Dmitry V. Levin<ldv@altlinux.org> написал(а):
> Самый простой и надёжный способ -- собрать srpm-пакет в hasher'е и дальше
>  извлечь из его заголовка необходимую информацию.

Мне эта информация нужна как раз перед сборкой в hasher.
Чтобы было понятнее. поясню, что я занимаюсь задачей автоматической
сборки пакетов из gear. Задача состоит в том, чтобы убедиться, что
человек не забыл поменять версию/релиз перед сборкой. Сборка дело не
быстрое, а в hasher еще дольше и узнать об этом после нее -- слишком
дорогое удовольствие. Ну и есть еще задачи, для которых это
необходимо.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Получение версии из spec-файла

[Dmitry V. Levin]

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

On Thu, May 08, 2008 at 06:00:42PM +0400, Dmitriy M. Maslennikov wrote:
> 08.05.08, Dmitry V. Levin<ldv@altlinux.org> написал(а):
> > Самый простой и надёжный способ -- собрать srpm-пакет в hasher'е и дальше
> >  извлечь из его заголовка необходимую информацию.
> 
> Мне эта информация нужна как раз перед сборкой в hasher.
> Чтобы было понятнее. поясню, что я занимаюсь задачей автоматической
> сборки пакетов из gear. Задача состоит в том, чтобы убедиться, что
> человек не забыл поменять версию/релиз перед сборкой. Сборка дело не
> быстрое, а в hasher еще дольше и узнать об этом после нее -- слишком
> дорогое удовольствие. Ну и есть еще задачи, для которых это
> необходимо.

В такой постановке задача в общем случае решения не имеет.


-- 
ldv

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

Re: [devel] Получение версии из spec-файла

[Igor Vlasenko]

> > Мне эта информация нужна как раз перед сборкой в hasher.
> > Чтобы было понятнее. поясню, что я занимаюсь задачей автоматической
> > сборки пакетов из gear. Задача состоит в том, чтобы убедиться, что
> > человек не забыл поменять версию/релиз перед сборкой. Сборка дело не

Есть ленивый хак c rpm -bE | grep '^Version:',

а для трудолюбивого человека у меня есть перловая библиотека
RPM::Source::Editor.


-- 

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

Re: [devel] Получение версии из spec-файла

[Dmitry V. Levin]

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

On Thu, May 08, 2008 at 05:41:05PM +0300, Igor Vlasenko wrote:
> > > Мне эта информация нужна как раз перед сборкой в hasher.
> > > Чтобы было понятнее. поясню, что я занимаюсь задачей автоматической
> > > сборки пакетов из gear. Задача состоит в том, чтобы убедиться, что
> > > человек не забыл поменять версию/релиз перед сборкой. Сборка дело не
> 
> Есть ленивый хак c rpm -bE | grep '^Version:',
> 
> а для трудолюбивого человека у меня есть перловая библиотека
> RPM::Source::Editor.

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


-- 
ldv

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

Re: [devel] Получение версии из spec-файла

[Igor Vlasenko]

On Thu, May 08, 2008 at 07:18:52PM +0400, Dmitry V. Levin wrote:
> On Thu, May 08, 2008 at 05:41:05PM +0300, Igor Vlasenko wrote:
> > > > Мне эта информация нужна как раз перед сборкой в hasher.
> > > > Чтобы было понятнее. поясню, что я занимаюсь задачей автоматической
> > > > сборки пакетов из gear. Задача состоит в том, чтобы убедиться, что
> > > > человек не забыл поменять версию/релиз перед сборкой. Сборка дело не
> > 
> > Есть ленивый хак c rpm -bE | grep '^Version:',
> > 
> > а для трудолюбивого человека у меня есть перловая библиотека
> > RPM::Source::Editor.
> 
> Этот подход не решает задачу вычисления версии без установки сборочных
> зависимостей и запуска произвольного кода в привилегированном контексте.

Теоретически да, конечно,
но разве в Сизифе есть примеры с патологиями?

-- 

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

Re: [devel] Получение версии из spec-файла

[Dmitry V. Levin]

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

On Thu, May 08, 2008 at 06:30:17PM +0300, Igor Vlasenko wrote:
> On Thu, May 08, 2008 at 07:18:52PM +0400, Dmitry V. Levin wrote:
> > On Thu, May 08, 2008 at 05:41:05PM +0300, Igor Vlasenko wrote:
> > > > > Мне эта информация нужна как раз перед сборкой в hasher.
> > > > > Чтобы было понятнее. поясню, что я занимаюсь задачей автоматической
> > > > > сборки пакетов из gear. Задача состоит в том, чтобы убедиться, что
> > > > > человек не забыл поменять версию/релиз перед сборкой. Сборка дело не
> > > 
> > > Есть ленивый хак c rpm -bE | grep '^Version:',
> > > 
> > > а для трудолюбивого человека у меня есть перловая библиотека
> > > RPM::Source::Editor.
> > 
> > Этот подход не решает задачу вычисления версии без установки сборочных
> > зависимостей и запуска произвольного кода в привилегированном контексте.
> 
> Теоретически да, конечно,
> но разве в Сизифе есть примеры с патологиями?

А разве их там нет?
Чем %get_version не паталогия?


-- 
ldv

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

Re: [devel] Получение версии из spec-файла

[Igor Vlasenko]

On Thu, May 08, 2008 at 07:41:22PM +0400, Dmitry V. Levin wrote:
> > Теоретически да, конечно,
> > но разве в Сизифе есть примеры с патологиями?
> А разве их там нет?
> Чем %get_version не паталогия?

%get_version не используется в 'Version:' нигде,
т.е. он мешает сделать rpmbuild -bs --nodeps, но не получить версию.

Патологиями в этом смысле выступают
%php_version
%php5_version

Есть ли другие?

Т.е. действительно, одного спека не достаточно 
и нужен еще Сизиф. 

если есть полный список патологий,
то можно следующий алгоритм:
1) узнать из Сизифа
текущие значения
%php_version
%php5_version
(прямо опросить соотв. пакеты)
и добавить эти значения в список макросов.

2) далее действовать как обычно.

-- 

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

Re: [devel] Получение версии из spec-файла

[Dmitriy M. Maslennikov]

У меня другая идея.
gear и hasher в сумме способны определить из spec-файла, что требуется
для сборки rpm и поставить все это в chroot. Далее уже возможно
раскрывать версию и все, что необходимо прямо спрашивая об этом rpm.
Теперь интересно узнать, а как работает сборка в hasher из gear? Пока
я нашел, что gear создает tar-архив с исходниками и spec-файлом. Далее
этот архив передается hasher вместо src-rpm. Можно ли заставить hasher
поставить все необходимое для пакета, но не собирать его? Если нет, то
очень интересно узнать алгоритм поиска зависимостей buildrequire(pre).
Правильно ли я понимаю, что мне необходимы только они?

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Получение версии из spec-файла

[Dmitriy M. Maslennikov]

Если кому интересно, то задача поднятая выше может быть решена
следующим образом.
Сначала создаем hasher:
$mkaptbox --apt-conf=<apt-conf-file> <path_to_hasher>
$hsh-mkchroot <path_to_hasher>
$hsh-initroot <path_to_hasher>
Затем пробегаем по спеку в поисках BuildRequires(pre): и устанавливаем
в наш hasher все эти зависимости. В одной строке они может быть
перечислено несколько через запятую, а так же может быть указание на
версию. По запятым я режу их сам, а вот версию hsh-install понимает.
Так что вызываем что-то вроде
$hsh-install <path_to_hasher> <package> [=|<=|>= <version>]
необходимое число раз.
Теперь у нас в hasher есть все для получения версии. Копируем спек в
<path_to_hasher>/chroot/.in и запускаем
$hsh-run -- rpm -bE *.spec
В выводе последней команды имеем искомые Name, Version, Release,
Serial. Полученный hasher я использую в дальнейшем и для сборки:
$gear --hasher -- hsh-rebuild <path_to_hasher>
Пока везде описанная процедура работала.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] [JT] Получение версии из spec-файла

[Ildar Mulyukov]

On 30.05.2008 14:26:59, Dmitriy M. Maslennikov wrote:
> Пока везде описанная процедура работала.
Если бы она не работала, то в хэшере бы ничего не собиралось.
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] [JT] Получение версии из spec-файла

[Dmitriy M. Maslennikov]

30.05.08, Ildar Mulyukov<ildar@altlinux.ru> написал(а):
>  Если бы она не работала, то в хэшере бы ничего не собиралось.
Есть в нем некоторая логика, которая отметает некоторые из
BuildRequires(pre) Я с ней не разбирался. Возможно еще что-то
пропущено. В общем я просто несколько неуверен, что установил именно
абсолютно правильную последовательность действий. Хотя это скорее
всего так.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

[devel] [JT] tmpfs и прочее преходящее

[Michael Shigorin]

On Thu, May 08, 2008 at 06:00:42PM +0400, Dmitriy M. Maslennikov wrote:
> Сборка дело не быстрое, а в hasher еще дольше

На всякий: Вы точно собираетесь в tmpfs -- или ещё на диске?

2 ldv: зимой наконец понял твоё упорное желание делать своп
побольше и /tmp на tmpfs, но всё-таки сборочные серверы --
весьма частный случай, всяко требующий понимания делаемого,
поэтому старые контрдоводы на будущее оставляю в силе :)

http://lists.altlinux.org/pipermail/sisyphus/2007-March/198626.html

PS: это только мне одному кажется или продукт
"ALT Linux DevServer" мог бы быть довольно интересным,
если делать его не только для себя?..

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Kirill A. Shutemov]

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

On Sun, May 11, 2008 at 09:40:20PM +0300, Michael Shigorin wrote:
> PS: это только мне одному кажется или продукт
> "ALT Linux DevServer" мог бы быть довольно интересным,
> если делать его не только для себя?..

Не одному.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Dmitry V. Levin]

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

On Sun, May 11, 2008 at 09:55:13PM +0300, Kirill A. Shutemov wrote:
> On Sun, May 11, 2008 at 09:40:20PM +0300, Michael Shigorin wrote:
> > PS: это только мне одному кажется или продукт
> > "ALT Linux DevServer" мог бы быть довольно интересным,
> > если делать его не только для себя?..
> 
> Не одному.

А что вы понимаете под этим названием?
git.alt из коробки? ;)


-- 
ldv

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Kirill A. Shutemov]

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

On Sun, May 11, 2008 at 10:56:38PM +0400, Dmitry V. Levin wrote:
> On Sun, May 11, 2008 at 09:55:13PM +0300, Kirill A. Shutemov wrote:
> > On Sun, May 11, 2008 at 09:40:20PM +0300, Michael Shigorin wrote:
> > > PS: это только мне одному кажется или продукт
> > > "ALT Linux DevServer" мог бы быть довольно интересным,
> > > если делать его не только для себя?..
> > 
> > Не одному.
> 
> А что вы понимаете под этим названием?
> git.alt из коробки? ;)

+ сборочница под ключ ;)

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Michael Shigorin]

On Sun, May 11, 2008 at 10:56:38PM +0400, Dmitry V. Levin wrote:
> > > PS: это только мне одному кажется или продукт
> > > "ALT Linux DevServer" мог бы быть довольно интересным,
> > > если делать его не только для себя?..
> > Не одному.
> А что вы понимаете под этим названием?
> git.alt из коробки? ;)

Почти :)  В alterator-devserver (/devserver/blonde, ага :)
-- синяя таблетка с надписью "git" (и приложением gear, hasher
и прочего, что нам всем тут так дорого) и красная -- с надписью
"svn" (и приложением trac и прочего, что так дорого потенциальным
попадантам).

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

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

Re: [devel] [JT] tmpfs и прочее преходящее

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

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

On Sun, May 11, 2008 at 10:56:38PM +0400, Dmitry V. Levin wrote:

DVL> А что вы понимаете под этим названием?
DVL> git.alt из коробки? ;)

Да. И не только его.
Кстати этот продукт больше имеет смысл в качестве openvz-образа, наверное.

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

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

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Dmitriy M. Maslennikov]

11.05.08, Michael Shigorin<mike@osdn.org.ua> написал(а):
>  На всякий: Вы точно собираетесь в tmpfs -- или ещё на диске?

На рабочей машине -- точно на диске. Сборочный сервер -- точно в
tmpfs. Но в первом случае слишком долго для отладки, во втором все
равно долго для сборки, скажем OpenOffice :)

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] [JT] tmpfs и прочее преходящее

[Michael Shigorin]

On Mon, May 12, 2008 at 09:01:57AM +0400, Dmitriy M. Maslennikov wrote:
> >  На всякий: Вы точно собираетесь в tmpfs -- или ещё на диске?
> На рабочей машине -- точно на диске.

Рекомендую тоже в tmpfs.

-- 
Миша,
вчера добавив домой ещё гиг

Re: [devel] [JT] tmpfs и прочее преходящее

[Dmitriy M. Maslennikov]

12.05.08, Michael Shigorin<mike@osdn.org.ua> написал(а):
> Рекомендую тоже в tmpfs.
С такими рекомендациями надо денег на оперативку каждому разработчику давать

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] [JT] tmpfs и прочее преходящее

[Michael Shigorin]

On Mon, May 12, 2008 at 11:05:15AM +0400, Dmitriy M. Maslennikov wrote:
> > Рекомендую тоже в tmpfs.
> С такими рекомендациями надо денег на оперативку каждому
> разработчику давать

hint1: сборка идёт достаточно заметно быстрее, чтобы вопрос
       ставить "сколько времени/денег мне это *экономит*";
hint2: tmpfs неплохо (уже) живёт и в свопе, причём всё равно
       быстрее (особенно если своп на отдельном от пакетной
       базы шпинделе -- например, если пакеты с NFS брать);
hint3: диски тоже стоят денег, причём внезапное отключение
       питания при активном свопе далеко не так страшно,
       как при активной сборке в /home -- да и помирают они
       от более активной работы (см. hint2) быстрее.

А память нынче дешёвая (рефрен уже двенадцать лет)... ;-)

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Evgeny Sinelnikov]

2008/5/12 Michael Shigorin <mike@osdn.org.ua>:
> On Mon, May 12, 2008 at 11:05:15AM +0400, Dmitriy M. Maslennikov wrote:
>> > Рекомендую тоже в tmpfs.
>> С такими рекомендациями надо денег на оперативку каждому
>> разработчику давать
>
> hint1: сборка идёт достаточно заметно быстрее, чтобы вопрос
>       ставить "сколько времени/денег мне это *экономит*";
> hint2: tmpfs неплохо (уже) живёт и в свопе, причём всё равно
>       быстрее (особенно если своп на отдельном от пакетной
>       базы шпинделе -- например, если пакеты с NFS брать);
> hint3: диски тоже стоят денег, причём внезапное отключение
>       питания при активном свопе далеко не так страшно,
>       как при активной сборке в /home -- да и помирают они
>       от более активной работы (см. hint2) быстрее.
>
> А память нынче дешёвая (рефрен уже двенадцать лет)... ;-)
>

Может быть меня кто-нибудь поправит...
Но, по-моему, Desktop у нас i586... А о больших объёмах памяти на
рабочих станциях стоит говорить либо на PAE-ядрах, либо на x86_64.
Последнее, в свою очередь, требует сначала поставить x86_64-desktop,
обновив если требуется железо...

Видится мне, что стоит либо ставить x86_64-систему, с большим объёмом
памяти, либо довольствоваться обычным дисковым хешером... Поскольку
первую рабочей назвать можно не всегда, у нас она пока даже не
планируется (или планируется x86_64 desktop?), а вторая, ну, может
конечно быть сборочной машиной... Но это опять-таки не рабочая
станция, а сборочный сервер на i586 с PAE-ядром или очень маленьким
хешером - у кого-то хватает 1,5 гига, у кого-то не хватает...

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] [JT] tmpfs и прочее преходящее

[Michael Shigorin]

On Mon, May 12, 2008 at 01:54:10PM +0400, Evgeny Sinelnikov wrote:
> Но, по-моему, Desktop у нас i586...

Если кому пригодится, то есть installed/dvd x86_64:
ftp://ftp.linux.kiev.ua/pub/Linux/ALT/beta/desktop/x86_64/

> А о больших объёмах памяти на рабочих станциях стоит говорить
> либо на PAE-ядрах, либо на x86_64.  Последнее, в свою очередь,
> требует сначала поставить x86_64-desktop, обновив если
> требуется железо...

IMHO всё-таки лучше сборку на сервер, если всё равно
инфраструктура нужна (не дома).

> Видится мне, что стоит либо ставить x86_64-систему, с большим
> объёмом памяти, либо довольствоваться обычным дисковым
> хешером...

Жень, у меня дома тоже i586.  С гигом-двумя RAM и 6--7 гигами
свопа собирать те же образы на tmpfs по факту веселей, чем на
диске.  Ещё раз: tmpfs живёт _в VM_, а не только в RAM.  Хотя
если обходится без диска -- конечно, ещё веселей.

Впрочем, тема скорее уже исчерпана.  Если хочешь, пиши в jabber
:)

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Mikhail Gusarov]

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

Twas brillig at 11:05:15 12.05.2008 UTC+04 when Dmitriy M. Maslennikov did gyre and gimble:

 DMM> С такими рекомендациями надо денег на оперативку каждому разработчику
 DMM> давать

А вы что, их на 256m держите, или на тонких клиентах? :)

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Dmitriy M. Maslennikov]

12.05.08, Mikhail Gusarov<dottedmag@altlinux.org> написал(а):
>  А вы что, их на 256m держите, или на тонких клиентах? :)
А что 1Gb хватит, чтобы OpenOffice в hasher собрать?

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] [JT] tmpfs и прочее преходящее

[Led]

Monday, 12 May 2008 11:52:10 Dmitriy M. Maslennikov написав:
> 12.05.08, Mikhail Gusarov<dottedmag@altlinux.org> написал(а):
> >  А вы что, их на 256m держите, или на тонких клиентах? :)
>
> А что 1Gb хватит, чтобы OpenOffice в hasher собрать?

Вам именно OOo нужно пересобирать? Даже для ядра 1,5Gb хватает.
Даже для OOo-подобного (на перспективу) можно один раз виделить 16Г свопа и не 
задумываться: "хватит-нехватит".

А про "тонкие клиенты" так и не понял: какое отношение их "тонкость" имеет к 
количеству доступной памяти?

-- 
Led

Re: [devel] [JT] tmpfs и прочее преходящее

[Konstantin A. Lepikhov]

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

Hi Led!

Monday 12, at 12:07:51 PM you wrote:

> Monday, 12 May 2008 11:52:10 Dmitriy M. Maslennikov написав:
> > 12.05.08, Mikhail Gusarov<dottedmag@altlinux.org> написал(а):
> > >  А вы что, их на 256m держите, или на тонких клиентах? :)
> >
> > А что 1Gb хватит, чтобы OpenOffice в hasher собрать?
> 
> Вам именно OOo нужно пересобирать? Даже для ядра 1,5Gb хватает.
> Даже для OOo-подобного (на перспективу) можно один раз виделить 16Г свопа и не 
> задумываться: "хватит-нехватит".
для ядра 1.5Gb не хватит. Проверено.

-- 
WBR et al.

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Led]

Monday, 12 May 2008 12:15:06 Konstantin A. Lepikhov написав:
> Hi Led!
>
> Monday 12, at 12:07:51 PM you wrote:
> > Monday, 12 May 2008 11:52:10 Dmitriy M. Maslennikov написав:
> > > 12.05.08, Mikhail Gusarov<dottedmag@altlinux.org> написал(а):
> > > >  А вы что, их на 256m держите, или на тонких клиентах? :)
> > >
> > > А что 1Gb хватит, чтобы OpenOffice в hasher собрать?
> >
> > Вам именно OOo нужно пересобирать? Даже для ядра 1,5Gb хватает.
> > Даже для OOo-подобного (на перспективу) можно один раз виделить 16Г свопа
> > и не задумываться: "хватит-нехватит".
>
> для ядра 1.5Gb не хватит. Проверено.

для ядра 1.5Gb хватит. Проверено.

-- 
Led

Re: [devel] [JT] tmpfs и прочее преходящее

[Konstantin A. Lepikhov]

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

Hi Led!

Monday 12, at 12:18:19 PM you wrote:

> Monday, 12 May 2008 12:15:06 Konstantin A. Lepikhov написав:
> > Hi Led!
> >
> > Monday 12, at 12:07:51 PM you wrote:
> > > Monday, 12 May 2008 11:52:10 Dmitriy M. Maslennikov написав:
> > > > 12.05.08, Mikhail Gusarov<dottedmag@altlinux.org> написал(а):
> > > > >  А вы что, их на 256m держите, или на тонких клиентах? :)
> > > >
> > > > А что 1Gb хватит, чтобы OpenOffice в hasher собрать?
> > >
> > > Вам именно OOo нужно пересобирать? Даже для ядра 1,5Gb хватает.
> > > Даже для OOo-подобного (на перспективу) можно один раз виделить 16Г свопа
> > > и не задумываться: "хватит-нехватит".
> >
> > для ядра 1.5Gb не хватит. Проверено.
> 
> для ядра 1.5Gb хватит. Проверено.
Спорим? %)

-- 
WBR et al.

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Led]

В сообщении от Monday 12 May 2008 12:56:29 Konstantin A. Lepikhov написал(а):
> Hi Led!
>
> Monday 12, at 12:18:19 PM you wrote:
> > Monday, 12 May 2008 12:15:06 Konstantin A. Lepikhov написав:
> > > Hi Led!
> > >
> > > Monday 12, at 12:07:51 PM you wrote:
> > > > Monday, 12 May 2008 11:52:10 Dmitriy M. Maslennikov написав:
> > > > > 12.05.08, Mikhail Gusarov<dottedmag@altlinux.org> написал(а):
> > > > > >  А вы что, их на 256m держите, или на тонких клиентах? :)
> > > > >
> > > > > А что 1Gb хватит, чтобы OpenOffice в hasher собрать?
> > > >
> > > > Вам именно OOo нужно пересобирать? Даже для ядра 1,5Gb хватает.
> > > > Даже для OOo-подобного (на перспективу) можно один раз виделить 16Г
> > > > свопа и не задумываться: "хватит-нехватит".
> > >
> > > для ядра 1.5Gb не хватит. Проверено.
> >
> > для ядра 1.5Gb хватит. Проверено.
>
> Спорим? %)

Нет. Я всё равно проиграю: ты докажешь, что я просто неправильно собираю, 
потому мне 1,5Г и хватает:)
Всё, "завязываем" оффтопик:)

-- 
Led

Re: [devel] [JT] tmpfs и прочее преходящее

[Mikhail Gusarov]

Twas brillig at 12:07:51 12.05.2008 UTC+03 when Led did gyre and gimble:

 L> А про "тонкие клиенты" так и не понял: какое отношение их "тонкость" имеет к
 L> количеству доступной памяти?

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

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

Re: [devel] [JT] tmpfs и прочее преходящее

[Michael Shigorin]

On Mon, May 12, 2008 at 04:31:57PM +0700, Mikhail Gusarov wrote:
> > А про "тонкие клиенты" так и не понял: какое отношение их
> > "тонкость" имеет к количеству доступной памяти?
> Поставить по 4 гига двум десяткам разработчиков, как мне
> кажется, проще, чем 80 гиг на терминальный сервер.

Арифметика кривая, не учитывает shared memory и пиковое/среднее.

Поставить 32 гига на сборочный сервер даёт возможность решать
совсем другие задачи, чем поставить дюжине разработчиков по 4G
локально.

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

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Mikhail Gusarov]

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

Twas brillig at 14:24:39 12.05.2008 UTC+03 when Michael Shigorin did gyre and gimble:

 MS> Арифметика кривая, не учитывает shared memory и пиковое/среднее.

Разумеется, кривая. Но! shared у разработчиков будет разве что libc и libx11
(это ж не школьники и не операторы), и я считал, что в пике комфортность не
должна быть ниже, чем в standalone-решениях.

 MS> Поставить 32 гига на сборочный сервер даёт возможность решать совсем другие
 MS> задачи, чем поставить дюжине разработчиков по 4G локально.

Ещё бы. А конкретному разработчику от этого холодно или жарко?

 MS> Поставить 4 гига на терминальный сервер проще, чем поставить по гигу двум
 MS> десяткам разработчиков.

И потом слушать "Ну вот, опять всё тормозит. Кто OOo запустил собираться?
Выключи! Ночью запустишь." ;)

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Michael Shigorin]

On Mon, May 12, 2008 at 06:31:55PM +0700, Mikhail Gusarov wrote:
> > Арифметика кривая, не учитывает shared memory и пиковое/среднее.
> Разумеется, кривая.

И никаких "но".

> Но! shared у разработчиков будет разве что libc и libx11
> (это ж не школьники и не операторы)

Позволю себе и в этом усомниться.

> и я считал, что в пике комфортность не должна быть ниже,
> чем в standalone-решениях.

В пике комфортность на мощном сервере _выше_.
Каждому ты по мощному серверу обычно не дашь :)

> > Поставить 32 гига на сборочный сервер даёт возможность решать
> > совсем другие задачи, чем поставить дюжине разработчиков по
> > 4G локально.
> Ещё бы. А конкретному разработчику от этого холодно или жарко?

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

(я вот надеюсь со сборкой ISO перебраться полностью в RAM,
что может снизить время с 6--20 минут до десятков секунд
и сэкономить на отвлечениях

> > Поставить 4 гига на терминальный сервер проще, чем поставить
> > по гигу двум десяткам разработчиков.
> И потом слушать "Ну вот, опять всё тормозит. Кто OOo запустил
> собираться?  Выключи! Ночью запустишь." ;)

Тут говорилось уже про терминальный -- заметь, я их разделяю,
хотя у нас до сих пор и сборочницы, и терминальный живут в
соседних VPS, хоть и на совсем разных дисках.  Благодаря 
vzctl set --cpuunits --ioprio работа в терминалах сборку даже 
в трёх hasher одновременно "не чувствует" (вот при scp исошки
да, слегка заметно -- надо бы шейпер соорудить :).

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

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Andriy Khavryuchenko]

Michael Shigorin написал:
> Тут говорилось уже про терминальный -- заметь, я их разделяю,
> хотя у нас до сих пор и сборочницы, и терминальный живут в
> соседних VPS, хоть и на совсем разных дисках.  Благодаря 
> vzctl set --cpuunits --ioprio работа в терминалах сборку даже 
> в трёх hasher одновременно "не чувствует" (вот при scp исошки
> да, слегка заметно -- надо бы шейпер соорудить :).

А как именно ты разносишь по приоритетам? Какие именно cpuunits и ioprio 
выдаёшь?

-- 
libpython.so должна лежать рядом с libpython.so.
		-- raorn in #5281

Re: [devel] [JT] tmpfs и прочее преходящее

[Michael Shigorin]

On Wed, May 14, 2008 at 05:58:43PM +0300, Andriy Khavryuchenko wrote:
> >Тут говорилось уже про терминальный -- заметь, я их разделяю,
> >хотя у нас до сих пор и сборочницы, и терминальный живут в
> >соседних VPS, хоть и на совсем разных дисках.  Благодаря vzctl
> >set --cpuunits --ioprio работа в терминалах сборку даже в трёх
> >hasher одновременно "не чувствует" (вот при scp исошки да,
> >слегка заметно -- надо бы шейпер соорудить :).
> А как именно ты разносишь по приоритетам? Какие именно cpuunits
> и ioprio выдаёшь?

Оказывается, ioprio здесь даже и не трогал, только

$HASHER32.conf:CPUUNITS="1000"
$HASHER32.conf:CPULIMIT="100"
$LTSP5.conf:CPUUNITS="20000"

(I/O разнесено по физически разным дискам, повторюсь)

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Ildar Mulyukov]

On 14.05.2008 20:58:43, Andriy Khavryuchenko wrote:
> Michael Shigorin написал:
> > Тут говорилось уже про терминальный -- заметь, я их разделяю,
> > хотя у нас до сих пор и сборочницы, и терминальный живут в
> > соседних VPS, хоть и на совсем разных дисках.  Благодаря
> > vzctl set --cpuunits --ioprio работа в терминалах сборку даже
> > в трёх hasher одновременно "не чувствует" (вот при scp исошки
> > да, слегка заметно -- надо бы шейпер соорудить :).
> 
> А как именно ты разносишь по приоритетам? Какие именно cpuunits и  
> ioprio
> выдаёшь?


Вам бы в sysadmins@, господа!
Искренне ваш, Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] [JT] tmpfs и прочее преходящее

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

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

Здравствуйте Michael Shigorin
  В сообщении от 14 мая 2008 Michael Shigorin написал(a):
> (я вот надеюсь со сборкой ISO перебраться полностью в RAM,
> что может снизить время с 6--20 минут до десятков секунд
> и сэкономить на отвлечениях

Ой, дайте рецепт ! :)

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

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Michael Shigorin]

On Fri, May 16, 2008 at 07:51:06AM +0400, Хихин Руслан wrote:
> > (я вот надеюсь со сборкой ISO перебраться полностью в RAM,
> > что может снизить время с 6--20 минут до десятков секунд
> > и сэкономить на отвлечениях
> Ой, дайте рецепт ! :)

Берётся нода с 16G RAM и 8 ядрами... :)

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Serge Ryabchun]

2008/5/14 Michael Shigorin <mike@osdn.org.ua>:
>
> (я вот надеюсь со сборкой ISO перебраться полностью в RAM,
> что может снизить время с 6--20 минут до десятков секунд
> и сэкономить на отвлечениях

Вот на такой вот ;-)

# cat /proc/cpuinfo|grep "model name"; echo; free -m; echo; stat -f
/tmp -c "%n %T %b blocks"; echo; stat -f / -c "%n %T"
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz

             total       used       free     shared    buffers     cached
Mem:         16056       2072      13983          0          0       1807
-/+ buffers/cache:        265      15791
Swap:        76319          0      76319

/tmp tmpfs 22020096 blocks

/ nfs

-- 
Рябчун Сергей

Re: [devel] [JT] tmpfs и прочее преходящее

[Dmitry V. Levin]

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

On Mon, May 12, 2008 at 12:52:10PM +0400, Dmitriy M. Maslennikov wrote:
> 12.05.08, Mikhail Gusarov<dottedmag@altlinux.org> написал(а):
> >  А вы что, их на 256m держите, или на тонких клиентах? :)
> А что 1Gb хватит, чтобы OpenOffice в hasher собрать?

Для сборки OOo требуется около 8Gb на tmpfs.
Собирать это на клиенте не стоит в любом случае.


-- 
ldv

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

Re: [devel] [JT] tmpfs и прочее преходящее

[Alexey Tourbin]

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

On Mon, May 12, 2008 at 11:05:15AM +0400, Dmitriy M. Maslennikov wrote:
> 12.05.08, Michael Shigorin<mike@osdn.org.ua> написал(а):
> > Рекомендую тоже в tmpfs.
> С такими рекомендациями надо денег на оперативку каждому разработчику давать

У меня оперативки 1G.  На tmpfs собирает ЗАМЕТНО НА ГЛАЗ И НА СЛУХ
быстрее, чем на ext3 (то есть быстрее раза в 2-3).  Это, может быть,
не столько заслуга tmpfs, сколько проигрыш ext3, однако...

Нужно сделать большой своп (несколько гигабайт) и правильно смонтировать
tmpfs, задав следующие опции (fstab):

tmpfs		/tmp			tmpfs	nosuid,nr_inodes=1M,size=16G	0 0

(Здесь нужно увеличить значение inodes, а size= указать примерно 2/3
от общего размера свопа.)

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