[devel] Build from gear

[devel] Build from gear

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

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

Когда на git.altlinux.ru ожидать работающей сборки в incoming из gear?

Чем дальше, тем больше я счастлив от использования git.

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

http://freesource.info
----------------------------------------------------------------------------
<raorn> наш jpegtran не корёжит exif, родной (или таки бсдшный?) - корёжит
<gvy> raorn, вешай багу :)


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

Re: [devel] Build from gear

[Dmitry V. Levin]

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

On Sat, Oct 14, 2006 at 11:34:05PM +0400, Денис Смирнов wrote:
> Когда на git.altlinux.ru ожидать работающей сборки в incoming из gear?

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


-- 
ldv

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

Re: [devel] Build from gear

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

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

On Sat, Oct 14, 2006 at 11:40:02PM +0400, Dmitry V. Levin wrote:

>> Когда на git.altlinux.ru ожидать работающей сборки в incoming из gear?
DVL> По плану в начале ноября, когда сервер приедет.

Ясно, спасибо.

Первое время она будет работать параллельно старому incoming/, или переход
будет резким?

И что будем делать с той инфраструктурой что сложилась сейчас в kernel
cvs?

Ну и последнее -- как будет выглядеть работа с апдейтами к веткам? Будет
просто группа мантейнеров, которая будет иметь право выкладывать в
апдейты, или как. Мне кажется схема "любой может выложить в updates любой
чужой пакет" себя не оправдывает, в отличии от выкладывания в Сизиф.

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

http://freesource.info
----------------------------------------------------------------------------
ПОСТУЛАТ ХАРРИСОНА
 На каждое действие есть равная ему противодействующая критика.

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

Re: [devel] Build from gear

[Konstantin A. Lepikhov]

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

Hi Денис!

Saturday 14, at 11:56:02 PM you wrote:

<skip>
> И что будем делать с той инфраструктурой что сложилась сейчас в kernel
> cvs?
имхо надо потихоньку ее переносить в git. Собственно, скрипты там
независимы от scm.

-- 
WBR et al.

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

Re: [devel] Build from gear

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

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

On Sun, Oct 15, 2006 at 12:19:36AM +0400, Konstantin A. Lepikhov wrote:

>> И что будем делать с той инфраструктурой что сложилась сейчас в kernel
>> cvs?
KAL> имхо надо потихоньку ее переносить в git. Собственно, скрипты там
KAL> независимы от scm.

Я не представляю как это сделать потихоньку, к сожалению.
Плюс git подразумевает что у репозитория один владелец, а у нас с этим cvs
много кто работает.

Ну и самое главное -- это один репозиторий будет, или несколько?

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

http://freesource.info
----------------------------------------------------------------------------
Кто багу обедает, тот ее и танцует.
		-- mike in devel@

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

Re: [devel] Build from gear

[Konstantin A. Lepikhov]

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

Hi Денис!

Sunday 15, at 01:49:41 AM you wrote:

> On Sun, Oct 15, 2006 at 12:19:36AM +0400, Konstantin A. Lepikhov wrote:
> 
> >> И что будем делать с той инфраструктурой что сложилась сейчас в kernel
> >> cvs?
> KAL> имхо надо потихоньку ее переносить в git. Собственно, скрипты там
> KAL> независимы от scm.
> 
> Я не представляю как это сделать потихоньку, к сожалению.
> Плюс git подразумевает что у репозитория один владелец, а у нас с этим cvs
> много кто работает.
ну будет группа "смотрящих" над репозиториями :) Зато проблемы "дайте мне
r/w доступ в kernel cvs" больше не будет.

> 
> Ну и самое главное -- это один репозиторий будет, или несколько?
а это уже как все развиваться будет. Лично мне нужно будет как минимум 3 -
для 3.0-branch, для stable релизов и для unstable игр.

-- 
WBR et al.

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

Re: [devel] Build from gear

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

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

On Sun, Oct 15, 2006 at 02:14:47AM +0400, Konstantin A. Lepikhov wrote:

>> Я не представляю как это сделать потихоньку, к сожалению.
>> Плюс git подразумевает что у репозитория один владелец, а у нас с этим cvs
>> много кто работает.
KAL> ну будет группа "смотрящих" над репозиториями :) Зато проблемы "дайте мне
KAL> r/w доступ в kernel cvs" больше не будет.

Насколько я понимаю сейчас git.altlinux.ru не поддерживает возможность
доступа нескольких людей к одному репозиторию.

>> Ну и самое главное -- это один репозиторий будет, или несколько?
KAL> а это уже как все развиваться будет. Лично мне нужно будет как минимум 3 -
KAL> для 3.0-branch, для stable релизов и для unstable игр.

А это-то зачем? Это-ж ветки.

Я имел в виду совсем другое.

Скажем все feat и т.д. можно просто положить в виде обычных отдельных
пакетов ныне стандартным методом.

Скрипты также можно оформить в виде отдельного пакета.

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

Разве что сделать совсем хитро -- в post-commit на git.alt можно из
kernel-module-* пакетов автоматически собирать параллельно несколько
пакетов с модулями, как это делается сейчас.

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

А идея делать "kernel cvs поверх git" приводит к тому, что мы наследуем
все проблемы kernel cvs, добавляя к ним ещё несколько. Что мне
категорически не нравится.

Вон у меня сейчас сборка астериска (из-за его развесистости) постепенно
начинает напоминать сборку ядра (уже два flavour, хотя в общем-то мне их 4
штуки нужно, да ещё и под каждый из них модули...). Проблемы абсолютно
аналогичны. Что теперь, под него тоже такого же монстра как нынешний
kernel cvs городить?

Или те же монстрики firefox/thunderbird. Те же самые проблемы
(необходимость держать отдельно модули, пересобирая их автоматом для
каждой новой версии). При этом если модули портабельные, то с учетом
последней инициативы по форку огнелиса мы получим практически ту же самую
проблему с несколькими flavour.

Хорошо бы найти общее решение для такого рода задач.

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

http://freesource.info
----------------------------------------------------------------------------
Правильно, xmtr под рутом работать перестал. Это будем считать feature.
		-- ldv in sisyphus@


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

Re: [devel] Build from gear

[Konstantin A. Lepikhov]

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

Hi Денис!

Sunday 15, at 02:47:12 AM you wrote:

> On Sun, Oct 15, 2006 at 02:14:47AM +0400, Konstantin A. Lepikhov wrote:
> 
> >> Я не представляю как это сделать потихоньку, к сожалению.
> >> Плюс git подразумевает что у репозитория один владелец, а у нас с этим cvs
> >> много кто работает.
> KAL> ну будет группа "смотрящих" над репозиториями :) Зато проблемы "дайте мне
> KAL> r/w доступ в kernel cvs" больше не будет.
> 
> Насколько я понимаю сейчас git.altlinux.ru не поддерживает возможность
> доступа нескольких людей к одному репозиторию.
а там не нужно несколько, достаточно одного, который будет несколько refs
объединять.

> 
> >> Ну и самое главное -- это один репозиторий будет, или несколько?
> KAL> а это уже как все развиваться будет. Лично мне нужно будет как минимум 3 -
> KAL> для 3.0-branch, для stable релизов и для unstable игр.
> 
> А это-то зачем? Это-ж ветки.
> 
> Я имел в виду совсем другое.
> 
> Скажем все feat и т.д. можно просто положить в виде обычных отдельных
> пакетов ныне стандартным методом.
> 
> Скрипты также можно оформить в виде отдельного пакета.
зачем? они бесполезны друг без друга.

> 
> А отдельный разговор со спеками для ядер и модулей. Притом что ядра, в
> общем-то, точно также можно класть не в аналог нынешнего kernel cvs, а
> опять же обычным образом, с модулями уже этот фокус не пройдет.
> 
> Разве что сделать совсем хитро -- в post-commit на git.alt можно из
> kernel-module-* пакетов автоматически собирать параллельно несколько
> пакетов с модулями, как это делается сейчас.
сложно и опасно - поскольку все равно сборку модулей надо контролировать.

> 
> В любом случае при всех подобных изменениях придется сильно переделывать
> эти самые скрипты.
> 
> А идея делать "kernel cvs поверх git" приводит к тому, что мы наследуем
> все проблемы kernel cvs, добавляя к ним ещё несколько. Что мне
> категорически не нравится.
какие у нас проблемы в kernel cvs?

> 
> Вон у меня сейчас сборка астериска (из-за его развесистости) постепенно
> начинает напоминать сборку ядра (уже два flavour, хотя в общем-то мне их 4
> штуки нужно, да ещё и под каждый из них модули...). Проблемы абсолютно
> аналогичны. Что теперь, под него тоже такого же монстра как нынешний
> kernel cvs городить?
ну вот вам и нужно придумывать решение, а тут зачем изгаляться?

> 
> Или те же монстрики firefox/thunderbird. Те же самые проблемы
> (необходимость держать отдельно модули, пересобирая их автоматом для
> каждой новой версии). При этом если модули портабельные, то с учетом
> последней инициативы по форку огнелиса мы получим практически ту же самую
> проблему с несколькими flavour.
форки фтопку. Я уже приводил пример другого монстра, на которого почему-то
никто внимания не обращает и принимает as is - это php.

-- 
WBR et al.

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

Re: [devel] Build from gear

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

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

On Sun, Oct 15, 2006 at 12:52:58PM +0400, Konstantin A. Lepikhov wrote:

>> Насколько я понимаю сейчас git.altlinux.ru не поддерживает возможность
>> доступа нескольких людей к одному репозиторию.
KAL> а там не нужно несколько, достаточно одного, который будет несколько refs
KAL> объединять.

Кто будет этим ключевым звеном, уход которого в отпуск блокирует всю
работу? vsu@ прямой доступ нужен, насколько я понимаю. Но также мне
кажется сомнительным что Сергей обрадуется _необходимости_ делать git
pull/push, на каждое _твое_ изменение.

Напоминаю что скоро сборка пакета в Сизиф кроме как через git будет невозможна.

Как минимум ты и vsu@ получается должны иметь доступ на запись.

>> Скажем все feat и т.д. можно просто положить в виде обычных отдельных
>> пакетов ныне стандартным методом.
>> Скрипты также можно оформить в виде отдельного пакета.
KAL> зачем? они бесполезны друг без друга.

feat/fix/... это совершенно самостоятельные пакеты. Которые, насколько я
понимаю, уходят в Сизиф в неизменном виде. Чем и отличаются от модулей.

>> А отдельный разговор со спеками для ядер и модулей. Притом что ядра, в
>> общем-то, точно также можно класть не в аналог нынешнего kernel cvs, а
>> опять же обычным образом, с модулями уже этот фокус не пройдет.
>> Разве что сделать совсем хитро -- в post-commit на git.alt можно из
>> kernel-module-* пакетов автоматически собирать параллельно несколько
>> пакетов с модулями, как это делается сейчас.
KAL> сложно и опасно - поскольку все равно сборку модулей надо контролировать.

Кто контролировать будет? Ты готов лично проверять корректность каждой
моей сборки zaptel (особенно с учетом того что из меня ядерщик такой же
как балерина -- то бишь на редкость хреновый)? Видимость контроля хуже
отсутствия такового.

Насколько я помню мы рассчитываем на сознательность мантейнера. Если он не
сознательный -- он идет лесом (в смысле ему перекрывают доступ к заливанию
ядреных пакетов). Если совсем несознательный... но на моей памяти
прецедентов с совсем несознательными не было.

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

>> В любом случае при всех подобных изменениях придется сильно переделывать
>> эти самые скрипты.
>> А идея делать "kernel cvs поверх git" приводит к тому, что мы наследуем
>> все проблемы kernel cvs, добавляя к ним ещё несколько. Что мне
>> категорически не нравится.
KAL> какие у нас проблемы в kernel cvs?

Вася Пупкин не имеет доступа в kernel cvs, но ему нужно собрать для себя
ядрышко с модулями. Ядрышко его сборки нужно ещё и Василисе Пупкиной, а
также нескольким их коллегам.

Что делать бум? Пущай варяться в своих песочницах, али как?

У нас есть сейчас три "типа официальных" flavour -- std, wks, ovz. Но я не
понимаю почему следует _запрещать_ альтернативные сборки, если они кому-то
нужны.

radlinux тому хороший пример -- автор варится в собственном соку.

Плюс совсем нелогично что в _одном_ репозитории у нас лежит все
околоядерное. Это нелогично.

Плюс нет разграничения зон ответственности. Вот я сейчас каааак возьму, и
кааааак сделаю коммит в wks26-*. Не, ну понятно что ты увидишь в почте cvs
log, дашь мне в лоб больно и откатишь изменение. А ежели не заметишь? ;)

Ну и самое главное что ты полностью проигнорировал. У нас нет SRPM. Вернее
через месяц не будет. Вообще не будет. И сделаный из kernel cvs/git/что
угодно ещё srpm ты сможешь только собрать локально и любоваться.

Поэтому подразумевается что из spec'а rpm генерируется исключительно на
git.altlinux.ru (кроме периода локального тестирования). И сделать всю
систему стоило бы так, чтобы это было удобно.

>> Вон у меня сейчас сборка астериска (из-за его развесистости) постепенно
>> начинает напоминать сборку ядра (уже два flavour, хотя в общем-то мне их 4
>> штуки нужно, да ещё и под каждый из них модули...). Проблемы абсолютно
>> аналогичны. Что теперь, под него тоже такого же монстра как нынешний
>> kernel cvs городить?
KAL> ну вот вам и нужно придумывать решение, а тут зачем изгаляться?

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

С firefox проблемы есть уже сейчас.

С php, который ты ниже упомянул, вообще не проблемы а вилы. Перманентно
существенная часть модулей не собрана, и обновить php попросту невозможно.
О нем и не говорят даже, потому что без мата о нем говорить трудно, а мы
все-таки в приличном обществе. Однако факт есть факт -- он нужен. И мне,
который его ненавидит всей душлой -- тоже.

И, кстати, php уже напрашивается как минимум на 2 flavour -- обычный и
hardened (в связи с тем что zend optimizer с hardened, AFAIR, не
совместим, а вот люди его хотят из-за кривых поделий с закрытыми
исходниками).

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

http://freesource.info
----------------------------------------------------------------------------
Путь к мозгу программиста лежит через его геморрой.

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

Re: [devel] Build from gear

[Konstantin A. Lepikhov]

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

Hi Денис!

Sunday 15, at 02:08:17 PM you wrote:

> On Sun, Oct 15, 2006 at 12:52:58PM +0400, Konstantin A. Lepikhov wrote:
> 
> >> Насколько я понимаю сейчас git.altlinux.ru не поддерживает возможность
> >> доступа нескольких людей к одному репозиторию.
> KAL> а там не нужно несколько, достаточно одного, который будет несколько refs
> KAL> объединять.
> 
> Кто будет этим ключевым звеном, уход которого в отпуск блокирует всю
> работу? vsu@ прямой доступ нужен, насколько я понимаю. Но также мне
> кажется сомнительным что Сергей обрадуется _необходимости_ делать git
> pull/push, на каждое _твое_ изменение.
> 
> Напоминаю что скоро сборка пакета в Сизиф кроме как через git будет невозможна.
> 
> Как минимум ты и vsu@ получается должны иметь доступ на запись.
это организационный вопрос, а не технический.

> 
> >> Скажем все feat и т.д. можно просто положить в виде обычных отдельных
> >> пакетов ныне стандартным методом.
> >> Скрипты также можно оформить в виде отдельного пакета.
> KAL> зачем? они бесполезны друг без друга.
> 
> feat/fix/... это совершенно самостоятельные пакеты. Которые, насколько я
> понимаю, уходят в Сизиф в неизменном виде. Чем и отличаются от модулей.
возможно, но они бесполезны без ядер.

<skip>
> KAL> сложно и опасно - поскольку все равно сборку модулей надо контролировать.
> 
> Кто контролировать будет? Ты готов лично проверять корректность каждой
> моей сборки zaptel (особенно с учетом того что из меня ядерщик такой же
> как балерина -- то бишь на редкость хреновый)? Видимость контроля хуже
> отсутствия такового.
мне ее приходится проверять, как и сборки других модулей. Но как ты
правильно заметил, это поверхностная оценка.

> 
> Насколько я помню мы рассчитываем на сознательность мантейнера. Если он не
> сознательный -- он идет лесом (в смысле ему перекрывают доступ к заливанию
> ядреных пакетов). Если совсем несознательный... но на моей памяти
> прецедентов с совсем несознательными не было.
> 
> Да, я понимаю что любой имеющий права на сборку модулей может подсунуть
> руткит. Но я сомневаюсь что кто-то проводит вычитку кода всех
> kernel-source-*.
vsu@ читает :)

> Вася Пупкин не имеет доступа в kernel cvs, но ему нужно собрать для себя
> ядрышко с модулями. Ядрышко его сборки нужно ещё и Василисе Пупкиной, а
> также нескольким их коллегам.
> 
> Что делать бум? Пущай варяться в своих песочницах, али как?
а чем васю не устраивает свой cvs репозиторий?

> 
> У нас есть сейчас три "типа официальных" flavour -- std, wks, ovz. Но я не
> понимаю почему следует _запрещать_ альтернативные сборки, если они кому-то
> нужны.
а их никто не запрещает - если ты посмотришь повнимательнее в kernel cvs, там
много "заброшенных" сборок вроде rt26, которая вообще является чьим-то
выкидышем, т.к. у нее -headers непригодны для сборки -modules. Т.е.
препятствий нет, есть лень и отсутствие времени/людей.

> 
> radlinux тому хороший пример -- автор варится в собственном соку.
и автора это устраивает.

> 
> Плюс совсем нелогично что в _одном_ репозитории у нас лежит все
> околоядерное. Это нелогично.
можно сделать _один_ околоядерный репозиторий, как в ovz.

> 
> Плюс нет разграничения зон ответственности. Вот я сейчас каааак возьму, и
> кааааак сделаю коммит в wks26-*. Не, ну понятно что ты увидишь в почте cvs
> log, дашь мне в лоб больно и откатишь изменение. А ежели не заметишь? ;)
замечу ;)

> 
> Ну и самое главное что ты полностью проигнорировал. У нас нет SRPM. Вернее
> через месяц не будет. Вообще не будет. И сделаный из kernel cvs/git/что
> угодно ещё srpm ты сможешь только собрать локально и любоваться.
> 
> Поэтому подразумевается что из spec'а rpm генерируется исключительно на
> git.altlinux.ru (кроме периода локального тестирования). И сделать всю
> систему стоило бы так, чтобы это было удобно.
скрипты в kernel cvs не сильно завязаны на srpms. Точнее, вообще на них не
завязаны. Они завязаны на _сборочную среду_.

<skip>
> Это я к слову. Себе я велосипед из стайки скриптов изобрел, он работает,
> это все страшно до жути но мне пофиг. И будет пофиг пока
> asterisk*/seirospbx* означает что мантейнер я. Как только появится хотя бы
> один модуль, который кому-то нужен, а мне нафиг не нужен, собирать его
> геморройно, и я пошлю его мантейнера разбираться самого -- у него будут
> проблемы.
потому что либо нет документации по сборке, либо система сборки
непрозрачна.

> 
> С firefox проблемы есть уже сейчас.
они временные до выхода fx-3.0.

> 
> С php, который ты ниже упомянул, вообще не проблемы а вилы. Перманентно
> существенная часть модулей не собрана, и обновить php попросту невозможно.
> О нем и не говорят даже, потому что без мата о нем говорить трудно, а мы
> все-таки в приличном обществе. Однако факт есть факт -- он нужен. И мне,
> который его ненавидит всей душлой -- тоже.
какие нужные модули не собраны в данный момент?

> 
> И, кстати, php уже напрашивается как минимум на 2 flavour -- обычный и
> hardened (в связи с тем что zend optimizer с hardened, AFAIR, не
> совместим, а вот люди его хотят из-за кривых поделий с закрытыми
> исходниками).
там все хуже: zend API сменился при переходе с 4.3.10 на 4.4.0, поэтому
старые блобы и так уже давно в пролете.

-- 
WBR et al.

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

Re: [devel] Build from gear

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

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

On Sun, Oct 15, 2006 at 04:04:31PM +0400, Konstantin A. Lepikhov wrote:

>> Кто будет этим ключевым звеном, уход которого в отпуск блокирует всю
>> работу? vsu@ прямой доступ нужен, насколько я понимаю. Но также мне
>> кажется сомнительным что Сергей обрадуется _необходимости_ делать git
>> pull/push, на каждое _твое_ изменение.
>> Напоминаю что скоро сборка пакета в Сизиф кроме как через git будет невозможна.
>> Как минимум ты и vsu@ получается должны иметь доступ на запись.
KAL> это организационный вопрос, а не технический.

Из этого организационного вопроса следуют технические следствия, на
разрешения которых, если прогноз ldv@ сбудется, у нас чуть больше 2-х
недель.

>> feat/fix/... это совершенно самостоятельные пакеты. Которые, насколько я
>> понимаю, уходят в Сизиф в неизменном виде. Чем и отличаются от модулей.
KAL> возможно, но они бесполезны без ядер.

Я понимаю.

Но это не повод городить лишнюю сущность. Напоминаю -- kernel cvs через
две недели мертв, создается нечто новое. Будет ли это kernel cvs поверх
git, или мы будем на максимум использовать особенности вновь создаваемой
системы?

>> Кто контролировать будет? Ты готов лично проверять корректность каждой
>> моей сборки zaptel (особенно с учетом того что из меня ядерщик такой же
>> как балерина -- то бишь на редкость хреновый)? Видимость контроля хуже
>> отсутствия такового.
KAL> мне ее приходится проверять, как и сборки других модулей. Но как ты
KAL> правильно заметил, это поверхностная оценка.

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

Мало того, если ты сможешь это формализовать, я даже возьмусь за это.

>> Насколько я помню мы рассчитываем на сознательность мантейнера. Если он не
>> сознательный -- он идет лесом (в смысле ему перекрывают доступ к заливанию
>> ядреных пакетов). Если совсем несознательный... но на моей памяти
>> прецедентов с совсем несознательными не было.
>> Да, я понимаю что любой имеющий права на сборку модулей может подсунуть
>> руткит. Но я сомневаюсь что кто-то проводит вычитку кода всех
>> kernel-source-*.
KAL> vsu@ читает :)

Увы, думаю далеко не все :)

>> Вася Пупкин не имеет доступа в kernel cvs, но ему нужно собрать для себя
>> ядрышко с модулями. Ядрышко его сборки нужно ещё и Василисе Пупкиной, а
>> также нескольким их коллегам.
>> Что делать бум? Пущай варяться в своих песочницах, али как?
KAL> а чем васю не устраивает свой cvs репозиторий?

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

Скажем по другому -- сильно мой via26 кому-то помешал? Был он мне нужен --
жил. Потом тихонько сдох, потому что никому больше нужен не оказался.
Оказался бы -- жил бы дальше. Чем это плохо?

Да, я понимаю что в дистрибутив такие левые ядра класть нельзя. Но и ll26
твой загнулся, во многом из-за того что многие кто могли бы по чуть-чуть
помочь просто не имели доступа к kernel cvs.

>> У нас есть сейчас три "типа официальных" flavour -- std, wks, ovz. Но я не
>> понимаю почему следует _запрещать_ альтернативные сборки, если они кому-то
>> нужны.
KAL> а их никто не запрещает - если ты посмотришь повнимательнее в kernel cvs, там
KAL> много "заброшенных" сборок вроде rt26, которая вообще является чьим-то
KAL> выкидышем, т.к. у нее -headers непригодны для сборки -modules. Т.е.
KAL> препятствий нет, есть лень и отсутствие времени/людей.

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

>> radlinux тому хороший пример -- автор варится в собственном соку.
KAL> и автора это устраивает.

Автора -- да. Его пользователей -- нет. Точно тебе говорю.

>> Плюс совсем нелогично что в _одном_ репозитории у нас лежит все
>> околоядерное. Это нелогично.
KAL> можно сделать _один_ околоядерный репозиторий, как в ovz.

Смысл?

>> Плюс нет разграничения зон ответственности. Вот я сейчас каааак возьму, и
>> кааааак сделаю коммит в wks26-*. Не, ну понятно что ты увидишь в почте cvs
>> log, дашь мне в лоб больно и откатишь изменение. А ежели не заметишь? ;)
KAL> замечу ;)

:)

>> Ну и самое главное что ты полностью проигнорировал. У нас нет SRPM. Вернее
>> через месяц не будет. Вообще не будет. И сделаный из kernel cvs/git/что
>> угодно ещё srpm ты сможешь только собрать локально и любоваться.
>> Поэтому подразумевается что из spec'а rpm генерируется исключительно на
>> git.altlinux.ru (кроме периода локального тестирования). И сделать всю
>> систему стоило бы так, чтобы это было удобно.
KAL> скрипты в kernel cvs не сильно завязаны на srpms. Точнее, вообще на них не
KAL> завязаны. Они завязаны на _сборочную среду_.

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

>> Это я к слову. Себе я велосипед из стайки скриптов изобрел, он работает,
>> это все страшно до жути но мне пофиг. И будет пофиг пока
>> asterisk*/seirospbx* означает что мантейнер я. Как только появится хотя бы
>> один модуль, который кому-то нужен, а мне нафиг не нужен, собирать его
>> геморройно, и я пошлю его мантейнера разбираться самого -- у него будут
>> проблемы.
KAL> потому что либо нет документации по сборке, либо система сборки
KAL> непрозрачна.

Нет. Это потому что как только я обновляю minor версию он должен обновлять
свой пакет. 

>> С firefox проблемы есть уже сейчас.
KAL> они временные до выхода fx-3.0.

До этого ещё дожить надо.

>> С php, который ты ниже упомянул, вообще не проблемы а вилы. Перманентно
>> существенная часть модулей не собрана, и обновить php попросту невозможно.
>> О нем и не говорят даже, потому что без мата о нем говорить трудно, а мы
>> все-таки в приличном обществе. Однако факт есть факт -- он нужен. И мне,
>> который его ненавидит всей душлой -- тоже.
KAL> какие нужные модули не собраны в данный момент?

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

>> И, кстати, php уже напрашивается как минимум на 2 flavour -- обычный и
>> hardened (в связи с тем что zend optimizer с hardened, AFAIR, не
>> совместим, а вот люди его хотят из-за кривых поделий с закрытыми
>> исходниками).
KAL> там все хуже: zend API сменился при переходе с 4.3.10 на 4.4.0, поэтому
KAL> старые блобы и так уже давно в пролете.

Это отдельная тема. Факт необходимости двух сборок php со всем окружением
никак не отменяющая.

Собственно о чем мы флеймим сейчас?

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

Также мне кажется что можно на максимум использовать преимущества git.

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

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

http://freesource.info
----------------------------------------------------------------------------
<ab> AMike: мы боты! мы боты! мы боты не купили!


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

Re: [devel] Build from gear

[Konstantin A. Lepikhov]

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

Hi Денис!

Sunday 15, at 04:23:07 PM you wrote:

> On Sun, Oct 15, 2006 at 04:04:31PM +0400, Konstantin A. Lepikhov wrote:
> 
> >> Кто будет этим ключевым звеном, уход которого в отпуск блокирует всю
> >> работу? vsu@ прямой доступ нужен, насколько я понимаю. Но также мне
> >> кажется сомнительным что Сергей обрадуется _необходимости_ делать git
> >> pull/push, на каждое _твое_ изменение.
> >> Напоминаю что скоро сборка пакета в Сизиф кроме как через git будет невозможна.
> >> Как минимум ты и vsu@ получается должны иметь доступ на запись.
> KAL> это организационный вопрос, а не технический.
> 
> Из этого организационного вопроса следуют технические следствия, на
> разрешения которых, если прогноз ldv@ сбудется, у нас чуть больше 2-х
> недель.
это если сбудется.

..
> Я понимаю.
> 
> Но это не повод городить лишнюю сущность. Напоминаю -- kernel cvs через
> две недели мертв, создается нечто новое. Будет ли это kernel cvs поверх
> git, или мы будем на максимум использовать особенности вновь создаваемой
> системы?
Денис, давай без нагнетания напряженности ;) я не слышал про закрытие i/S
через 2 недели, и думаю, никто не пойдет на такое. Просто i/S станет еще
одной подготовительной стадией к сборке, вот и все.

..
> >> Кто контролировать будет? Ты готов лично проверять корректность каждой
> >> моей сборки zaptel (особенно с учетом того что из меня ядерщик такой же
> >> как балерина -- то бишь на редкость хреновый)? Видимость контроля хуже
> >> отсутствия такового.
> KAL> мне ее приходится проверять, как и сборки других модулей. Но как ты
> KAL> правильно заметил, это поверхностная оценка.
> 
> И, если я правильно понимаю, при желании такую поверхностную оценку
> правильно написаный скрипт будет производить по крайней мере быстрее тебя.
> Так как я сомневаюсь что ты при этой проверке смотришь исходники, написать
> такой робот вполне реально.
> 
> Мало того, если ты сможешь это формализовать, я даже возьмусь за это.
отслеживать изменение структур и макросов в headers? Помойму это задача
все-таки для human-like.

> KAL> а чем васю не устраивает свой cvs репозиторий?
> 
> Васю не устраивает это исключительно тем, что пользователи этого ядра
> почему-то могут оказаться вполне себе другими пользователями Сизифа.
> 
> Скажем по другому -- сильно мой via26 кому-то помешал? Был он мне нужен --
> жил. Потом тихонько сдох, потому что никому больше нужен не оказался.
> Оказался бы -- жил бы дальше. Чем это плохо?
плохо замусориванием cvs, где нельзя каталоги удалить ;)

> 
> Да, я понимаю что в дистрибутив такие левые ядра класть нельзя. Но и ll26
> твой загнулся, во многом из-за того что многие кто могли бы по чуть-чуть
> помочь просто не имели доступа к kernel cvs.
и даже если бы имели, что изменилось? Кстати, он не загнулся, у него
вялотекущая кома :)

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

> >> radlinux тому хороший пример -- автор варится в собственном соку.
> KAL> и автора это устраивает.
> 
> Автора -- да. Его пользователей -- нет. Точно тебе говорю.
тогда это list mismatch. Пинайте автора.

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

<skip>
> KAL> скрипты в kernel cvs не сильно завязаны на srpms. Точнее, вообще на них не
> KAL> завязаны. Они завязаны на _сборочную среду_.
> 
> Ты это скажи тем скриптам которые при сборке модулей на версии ядер
> смотрят... Они, собаки такие, не верят. И мне их патчить пришлось чтобы у
> меня они то что нужно подхватывали. Это так, к примеру.
так при чем тут srpms? они завязаны на _сборочную среду_, где используется
rpm. Не будет rpm, придумаем что-нить другое.


<тут надо начинать новый тред>
> KAL> какие нужные модули не собраны в данный момент?
> 
> Вот сию секунду собрано все мне нужное. Однако за последние пол года более
> половины времени php был неюзабелен в том числе по причине не собранности
> модулей. И у меня есть подозрение что как только будет обновлен php, цирк
> продолжится.
не будет. У legion@ теперь есть тестеры и заинтересованность.

-- 
WBR et al.

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

Re: [devel] Build from gear

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

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

On Sun, Oct 15, 2006 at 05:13:20PM +0400, Konstantin A. Lepikhov wrote:

KAL> Денис, давай без нагнетания напряженности ;) я не слышал про закрытие i/S
KAL> через 2 недели, и думаю, никто не пойдет на такое. Просто i/S станет еще
KAL> одной подготовительной стадией к сборке, вот и все.

То есть ты предлагаешь вообще проблему проигнорировать, и продолжать
пользоваться kernel cvs как раньше, правильно я тебя понимаю?

> KAL>> а чем васю не устраивает свой cvs репозиторий?
>> Васю не устраивает это исключительно тем, что пользователи этого ядра
>> почему-то могут оказаться вполне себе другими пользователями Сизифа.
>> Скажем по другому -- сильно мой via26 кому-то помешал? Был он мне нужен --
>> жил. Потом тихонько сдох, потому что никому больше нужен не оказался.
>> Оказался бы -- жил бы дальше. Чем это плохо?
KAL> плохо замусориванием cvs, где нельзя каталоги удалить ;)

man cvs :-P
я при апдейте из cvs всегда прошу его прибивать пустые каталоги.

>> Да, я понимаю что в дистрибутив такие левые ядра класть нельзя. Но и ll26
>> твой загнулся, во многом из-за того что многие кто могли бы по чуть-чуть
>> помочь просто не имели доступа к kernel cvs.
KAL> и даже если бы имели, что изменилось? Кстати, он не загнулся, у него
KAL> вялотекущая кома :)

Могли бы чуток помочь :)

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

В нынешнем git.altlinux.ru нет понятия team.

> >>> radlinux тому хороший пример -- автор варится в собственном соку.
> KAL>> и автора это устраивает.
>> Автора -- да. Его пользователей -- нет. Точно тебе говорю.
KAL> тогда это list mismatch. Пинайте автора.

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

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

Для этого не требуется мешать мух с котлетами.

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

То бишь сейчас у нас как минимум три _разных_ сущности:
 - модули
 - feat/fix/...
 - ядра

>> Вот сию секунду собрано все мне нужное. Однако за последние пол года более
>> половины времени php был неюзабелен в том числе по причине не собранности
>> модулей. И у меня есть подозрение что как только будет обновлен php, цирк
>> продолжится.
KAL> не будет. У legion@ теперь есть тестеры и заинтересованность.

rpm -qi утверждает что не все php-* мантейнит legion@. Он мне нагло врет?

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

http://freesource.info
----------------------------------------------------------------------------
<ab> AMike: мы боты! мы боты! мы боты не купили!

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

Re: [devel] Build from gear

[Konstantin A. Lepikhov]

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

Hi Денис!

Sunday 15, at 06:19:29 PM you wrote:

> On Sun, Oct 15, 2006 at 05:13:20PM +0400, Konstantin A. Lepikhov wrote:
> 
> KAL> Денис, давай без нагнетания напряженности ;) я не слышал про закрытие i/S
> KAL> через 2 недели, и думаю, никто не пойдет на такое. Просто i/S станет еще
> KAL> одной подготовительной стадией к сборке, вот и все.
> 
> То есть ты предлагаешь вообще проблему проигнорировать, и продолжать
> пользоваться kernel cvs как раньше, правильно я тебя понимаю?
нет, я предлагаю не переписывать kernel-build-policy. И система с
тимплейтами модулей и с прозрачной сборкой ядра мне пока нравится.

<skip>
> KAL> плохо замусориванием cvs, где нельзя каталоги удалить ;)
> 
> man cvs :-P
> я при апдейте из cvs всегда прошу его прибивать пустые каталоги.
к сожалению, на сервере они все равно остаются.

> 
> >> Да, я понимаю что в дистрибутив такие левые ядра класть нельзя. Но и ll26
> >> твой загнулся, во многом из-за того что многие кто могли бы по чуть-чуть
> >> помочь просто не имели доступа к kernel cvs.
> KAL> и даже если бы имели, что изменилось? Кстати, он не загнулся, у него
> KAL> вялотекущая кома :)
> 
> Могли бы чуток помочь :)
Только вот чем? Из заинтересованных я видел только тебя и greycat@, у
обоих своих дел по горло.

> 
> >> Если мы это разрешаем, то на того человека который будет работать прокси
> >> падает большая нагрузка. Проксей людей быть не должно.
> KAL> люди должны сбиваться в team@ и проксировать сообща.
> 
> В нынешнем git.altlinux.ru нет понятия team.
бага? :)

<skip>
> Увы, проблемы не у автора а у нас. И ему свою задачу оказалось проще
> решить своими велосипедами, потому что штатные с квадратными колесами.
боюсь что автра не заинтересует и то, что предлагается сейчас.

> > >>> Плюс совсем нелогично что в _одном_ репозитории у нас лежит все
> > >>> околоядерное. Это нелогично.
> > KAL>> можно сделать _один_ околоядерный репозиторий, как в ovz.
> >> Смысл?
> KAL> дабы при сборке цеплять его и делать возможными ядра, использующие что-то
> KAL> не сизиф-специфичное.
> 
> Для этого не требуется мешать мух с котлетами.
> 
> Благо эти скрипты умеют смотреть в локальный репозиторий, и брать
> зависимости оттуда.
> 
> То бишь сейчас у нас как минимум три _разных_ сущности:
>  - модули
>  - feat/fix/...
>  - ядра
я совсем запутался - что из вышеперечисленного тебя не устраивает? :)

<skip>
> rpm -qi утверждает что не все php-* мантейнит legion@. Он мне нагло врет?
> 
не все firefox-* манейнит legion@. Зато он делает build среду. В php была
проблема другого плана - его просто не проверяли после сборки.

-- 
WBR et al.

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

Re: [devel] Build from gear

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

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

On Sun, Oct 15, 2006 at 06:39:28PM +0400, Konstantin A. Lepikhov wrote:

>> То есть ты предлагаешь вообще проблему проигнорировать, и продолжать
>> пользоваться kernel cvs как раньше, правильно я тебя понимаю?
KAL> нет, я предлагаю не переписывать kernel-build-policy. И система с
KAL> тимплейтами модулей и с прозрачной сборкой ядра мне пока нравится.

Система с темплейтами модулей рулез, и она должна остаться.
Меня другое волнует.

Я правильно понимаю что ты предпчитаешь оставить пока все как есть? Идея
переносить kernel cvs в нынешнем виде прямо в git, боюсь, будет иметь
недостатков больше чем преимуществ.

>> man cvs :-P
>> я при апдейте из cvs всегда прошу его прибивать пустые каталоги.
KAL> к сожалению, на сервере они все равно остаются.

На сервере они не пустые, а историю хранят. Согласен что
"неаккуратненько", а что делать.

>> Могли бы чуток помочь :)
KAL> Только вот чем? Из заинтересованных я видел только тебя и greycat@, у
KAL> обоих своих дел по горло.

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

Интересен он как минимум всем, для кого IP-телефония не роскошь, а
вынужденая необходимость.

> >>> Если мы это разрешаем, то на того человека который будет работать прокси
> >>> падает большая нагрузка. Проксей людей быть не должно.
> KAL>> люди должны сбиваться в team@ и проксировать сообща.
>> В нынешнем git.altlinux.ru нет понятия team.
 KAL> бага? :)

 Вешай на Диму :)

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

Пока ничего не предлагается в плане ядер. В плане остальных компонентов --
по крайней мере текущая схема облегчает создание своих велосипедов. У меня
вон уже сейчас cpio и libtiff свои. Спасибо git poll, что при обновлении
мне понадобятся считаные моменты чтобы обновиться и у себя.

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

Это удобно.

>> То бишь сейчас у нас как минимум три _разных_ сущности:
>>  - модули
>>  - feat/fix/...
>>  - ядра
KAL> я совсем запутался - что из вышеперечисленного тебя не устраивает? :)

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

Вопрос -- если я захочу завтра отправить feat с patch'o'matic, и собрать с
ним ядро (ну вот нужно оно под какую-либо задачу), и при этом не имею
доступа в kernel cvs мне что, повеситься? А обычно на такие маньячные
пожелания много кого есть.

Кроме того скажу ещё одну страшную штуку. Только не матюкайся,

В kernel git всякие fix/feat вообще нафиг не нужны. Ветки это. И
базироваться он должен на kernel git (нынешний процесс с экспортом из git
исходников мне очень напоминает закат солнца вручную). И сейчас у нас
сборка ядер невоспроизводима по ходу утекания Сизифа. 

>> rpm -qi утверждает что не все php-* мантейнит legion@. Он мне нагло врет?
KAL> не все firefox-* манейнит legion@. Зато он делает build среду. В php была
KAL> проблема другого плана - его просто не проверяли после сборки.

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

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

Ну и в завершение: в любом случае по поводу kernel cvs самое главное это
мнение одного человека -- Сергея. Потому что он знает git, и его
применение при сборке ядер лучше чем мы с тобой вместе взятые.

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

http://freesource.info
----------------------------------------------------------------------------
> На ftp.altlinux.ru в Sisyphus находится пакет Eterm с правами 775!!!
Ничего, пройдет :)
		-- ldv in devel@

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

Re: [devel] Build from gear

[Konstantin A. Lepikhov]

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

Hi Денис!

Sunday 15, at 08:23:08 PM you wrote:

<skip>
> Система с темплейтами модулей рулез, и она должна остаться.
> Меня другое волнует.
> 
> Я правильно понимаю что ты предпчитаешь оставить пока все как есть? Идея
> переносить kernel cvs в нынешнем виде прямо в git, боюсь, будет иметь
> недостатков больше чем преимуществ.
я предлагаю спокойно все обдумать и предложить варианты. Вариант с
горячкой "через-2-недели-всем-трындец" меня напрягает (тут еще гоша за
спиной стоит).

> >> Могли бы чуток помочь :)
> KAL> Только вот чем? Из заинтересованных я видел только тебя и greycat@, у
> KAL> обоих своих дел по горло.
> 
> Иногда вплоть до поработать роботом (то бишь пересобрать новый,
> попытавшись приложить то что прикладывается). Например тот факт что ты не
> выкладываешь сборки в Сизиф сильно сужает количество тестирующих.
если я их не выкладываю, значит они меня не устраивают. Например,
последнее, что сейчас лежит в cvs, просто не собирается.

> 
> Интересен он как минимум всем, для кого IP-телефония не роскошь, а
> вынужденая необходимость.
да, но только в случае готового решения, которого пока нет. Либо мне надо
серъезно вкуривать в RT- preemptive, либо бросать это нафиг.

> KAL> я совсем запутался - что из вышеперечисленного тебя не устраивает? :)
> 
> Меня не устраивает что разные сущности в одной корзине, и ограничены
> возможностью этой корзины.
> 
> Вопрос -- если я захочу завтра отправить feat с patch'o'matic, и собрать с
> ним ядро (ну вот нужно оно под какую-либо задачу), и при этом не имею
> доступа в kernel cvs мне что, повеситься? А обычно на такие маньячные
> пожелания много кого есть.
я вот собрал wks26 с альтернативным dvb-v4l и не повесился. С git оно
конечно еще проще - сделал бранч и забыл.

> 
> Кроме того скажу ещё одну страшную штуку. Только не матюкайся,
> 
> В kernel git всякие fix/feat вообще нафиг не нужны. Ветки это. И
> базироваться он должен на kernel git (нынешний процесс с экспортом из git
> исходников мне очень напоминает закат солнца вручную). И сейчас у нас
> сборка ядер невоспроизводима по ходу утекания Сизифа. 
это да, но собственно, тут мы с тобой едины во мнениях. Собственно, git
тут как раз и рулит.

> >> rpm -qi утверждает что не все php-* мантейнит legion@. Он мне нагло врет?
> KAL> не все firefox-* манейнит legion@. Зато он делает build среду. В php была
> KAL> проблема другого плана - его просто не проверяли после сборки.
> 
> На эту проблему мне будет почти пофиг после введения gear -- мне надо, я
> протестирую и залью сам же фикс.
> 
> А вот проблема что после очередной сборки php все модули, кроме
> собирающихся из исходников php ещё могут хрен знает сколько не
> обновляться, это проблема.
?? А чем эта ситуация будет отличаться от вышеприведенного решения :)

> 
> Ну и в завершение: в любом случае по поводу kernel cvs самое главное это
> мнение одного человека -- Сергея. Потому что он знает git, и его
> применение при сборке ядер лучше чем мы с тобой вместе взятые.
разные точки зрения всегда хороши.

-- 
WBR et al.

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

Re: [devel] Build from gear

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

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

On Sun, Oct 15, 2006 at 08:52:01PM +0400, Konstantin A. Lepikhov wrote:

>> Система с темплейтами модулей рулез, и она должна остаться.
>> Меня другое волнует.
>> Я правильно понимаю что ты предпчитаешь оставить пока все как есть? Идея
>> переносить kernel cvs в нынешнем виде прямо в git, боюсь, будет иметь
>> недостатков больше чем преимуществ.
KAL> я предлагаю спокойно все обдумать и предложить варианты. Вариант с
KAL> горячкой "через-2-недели-всем-трындец" меня напрягает (тут еще гоша за
KAL> спиной стоит).

Идея принимается. Сожалею что мои письма были расценены как паника.

>> Вопрос -- если я захочу завтра отправить feat с patch'o'matic, и собрать с
>> ним ядро (ну вот нужно оно под какую-либо задачу), и при этом не имею
>> доступа в kernel cvs мне что, повеситься? А обычно на такие маньячные
>> пожелания много кого есть.
KAL> я вот собрал wks26 с альтернативным dvb-v4l и не повесился. С git оно
KAL> конечно еще проще - сделал бранч и забыл.

Вот-вот.

>> Кроме того скажу ещё одну страшную штуку. Только не матюкайся,
>> В kernel git всякие fix/feat вообще нафиг не нужны. Ветки это. И
>> базироваться он должен на kernel git (нынешний процесс с экспортом из git
>> исходников мне очень напоминает закат солнца вручную). И сейчас у нас
>> сборка ядер невоспроизводима по ходу утекания Сизифа. 
KAL> это да, но собственно, тут мы с тобой едины во мнениях. Собственно, git
KAL> тут как раз и рулит.

Отлично :)

Соответственно я о чем и говорю -- как максимально эффективно можно
использовать новую платформу для этой задачи?

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

>> На эту проблему мне будет почти пофиг после введения gear -- мне надо, я
>> протестирую и залью сам же фикс.
>> А вот проблема что после очередной сборки php все модули, кроме
>> собирающихся из исходников php ещё могут хрен знает сколько не
>> обновляться, это проблема.
KAL> ?? А чем эта ситуация будет отличаться от вышеприведенного решения :)

Объясняю кратко.

В случае если у нас один единственный php я выкручиваюсь одним скриптом.
Которые залезет в git, сделает снапшоты, проапдейтит spec (добавив .1 в
release и добавит строчку в changelog), а потом выполнит gear-release на
результат. Скриптик пишется, ясное дело, элементарно. Все, серия пакетов
улетела на автоматическую пересборку.

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

Хотя бы потому что для первых инфраструктура git.alt бует блокировать
потерю изменений, в случае же генерирования spec'ов у нас нет никакой
формализованой связи между оригинальным спеком и сгенерированым. Поэтому
история может (а значит и будет) теряться. Вот это не просто плохо, а
очень плохо. И конкретно эту проблему я не понимаю с какой стороны решать.

>> Ну и в завершение: в любом случае по поводу kernel cvs самое главное это
>> мнение одного человека -- Сергея. Потому что он знает git, и его
>> применение при сборке ядер лучше чем мы с тобой вместе взятые.
KAL> разные точки зрения всегда хороши.

Безусловно.

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

http://freesource.info
----------------------------------------------------------------------------
Если я не вернyсь - считайте меня программистом.

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

Re: [devel] Build from gear

[Igor Zubkov]

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

В сообщении от 15 октября 2006 16:13 Konstantin A. Lepikhov написал(a):
> > KAL> какие нужные модули не собраны в данный момент?
> >
> > Вот сию секунду собрано все мне нужное. Однако за последние пол года
> > более половины времени php был неюзабелен в том числе по причине не
> > собранности модулей. И у меня есть подозрение что как только будет
> > обновлен php, цирк продолжится.
>
> не будет. У legion@ теперь есть тестеры и заинтересованность.

Сильно надеюсь...

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

Re: [devel] Build from gear

[Michael Shigorin]

On Sun, Oct 15, 2006 at 02:08:17PM +0400, Денис Смирнов wrote:
> >> Насколько я понимаю сейчас git.altlinux.ru не поддерживает
> >> возможность доступа нескольких людей к одному репозиторию.
> > а там не нужно несколько, достаточно одного, который будет
> > несколько refs объединять.
> Кто будет этим ключевым звеном, уход которого в отпуск
> блокирует всю работу? vsu@ прямой доступ нужен, насколько я
> понимаю. Но также мне кажется сомнительным что Сергей
> обрадуется _необходимости_ делать git pull/push, на каждое
> _твое_ изменение.

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

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

> Напоминаю что скоро сборка пакета в Сизиф кроме как через git
> будет невозможна.

Это ещё что за новости?

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

От любого желающего просто не надо делать pull.

> radlinux тому хороший пример -- автор варится в собственном соку.

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

> >> Вон у меня сейчас сборка астериска (из-за его развесистости)
> >> постепенно начинает напоминать сборку ядра (уже два flavour,
> KAL> ну вот вам и нужно придумывать решение, а тут зачем изгаляться?
> Это я к слову. Себе я велосипед из стайки скриптов изобрел, он
> работает, это все страшно до жути но мне пофиг. И будет пофиг
> С firefox проблемы есть уже сейчас.
> С php, который ты ниже упомянул, вообще не проблемы а вилы.

А ещё есть seamonkey.

Только опять же -- даже не почитав скрипты kernel cvs и не
соображая, чем отличается тот же git{,.alt} по части возможности
навешивания хуков, весьма смутно представляю себе, как и что там
можно пытаться обобщить.  Хотя есть подозрение, что с git.alt
подготовка к пересборке будет сводиться к выделению множества
зависимых по сборке и автопростановки им Правильного Тега (TM).

-- 
Миша,
взяв себе немного iputils

Re: [devel] Build from gear

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

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

On Sun, Oct 15, 2006 at 04:28:37PM +0300, Michael Shigorin wrote:

>> Кто будет этим ключевым звеном, уход которого в отпуск
>> блокирует всю работу? vsu@ прямой доступ нужен, насколько я
>> понимаю. Но также мне кажется сомнительным что Сергей
>> обрадуется _необходимости_ делать git pull/push, на каждое
>> _твое_ изменение.
 MS> Слушай, а ты уверен, что грокнул git и не считаешь его таким
 MS> себе cvs?  Он же весь из себя про деревья и бранчи, а не про 
 MS> центральный репо и доступ к нему.

Фигня в том, что эти вкусности использует разработчик. Сам для себя.
А в момент когда мы отправляем в Сизиф у нас есть один единственный объект
со своей историей, который и уйдет на сборку.

Плюс флейм шел о том чтобы переносить kernel cvs в git без изменений (то
бишь использовать git как cvs), что мне категорически не нравится.

А бранчами полноценно я пользоваться пока не научился, да. То что я
научился будет заметно по исчезновению патчей из моих пакетов :)

MS> Бишь есть нечто вроде vALTnilla, и если кому надо -- клонят
MS> и ведут свои деревья, при необходимости дёргая народ насчёт
MS> слить наработки.  В этой как раз точке и место для review,
MS> причём необязательно именно одним и тем же человеком.

Это будет возможно только в том случае, если мы разобьем kernel cvs на
разные репозитории. Потому как у одного репозитория один хозяин, это
аксиома. И это как раз и нужно чтобы было "необязательно именно одним и
тем же человеком".

>> Напоминаю что скоро сборка пакета в Сизиф кроме как через git
>> будет невозможна.
MS> Это ещё что за новости?

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

>> Да, я понимаю что любой имеющий права на сборку модулей может
>> подсунуть руткит. Но я сомневаюсь что кто-то проводит вычитку
>> кода всех kernel-source-*.
MS> От любого желающего просто не надо делать pull.

Тебе напомнить про apanel, который ты не мог себе собрать из-за того что
не имел доступ к kernel cvs? И про то как я про него забыл, из-за чего ты
ой как долго его дожидался? AFAIR я его все-таки собрал, но нынешний его
статус не знаю.

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

А я посмотрел. Ему пришлось слишком много несовместимых велосипедов
изобретать. Будь разработка более открытой этих велосипедов не было. Вот
ему, например, нужны ядра с другим патчем на mppe/mppc, другой pppd,
cramfs в ядре и т.д. Он был со своими предолжениями просто молча
проигнорирован, и потому пошел делать свои велосипеды.

> >>> Вон у меня сейчас сборка астериска (из-за его развесистости)
> >>> постепенно начинает напоминать сборку ядра (уже два flavour,
> KAL>> ну вот вам и нужно придумывать решение, а тут зачем изгаляться?
>> Это я к слову. Себе я велосипед из стайки скриптов изобрел, он
>> работает, это все страшно до жути но мне пофиг. И будет пофиг
>> С firefox проблемы есть уже сейчас.
>> С php, который ты ниже упомянул, вообще не проблемы а вилы.
MS> А ещё есть seamonkey.
MS> Только опять же -- даже не почитав скрипты kernel cvs и не
MS> соображая, чем отличается тот же git{,.alt} по части возможности
MS> навешивания хуков, весьма смутно представляю себе, как и что там
MS> можно пытаться обобщить.  Хотя есть подозрение, что с git.alt
MS> подготовка к пересборке будет сводиться к выделению множества
MS> зависимых по сборке и автопростановки им Правильного Тега (TM).

Ну например :)

Я себе уже четко представляю как можно написать робота-пересборщика для
NMU в стиле QA-robot, которым сможет воспользоваться любой человек. Как
только заработает сборка через git (то бишь появятся первые записи в
кэше), я таки его напишу (если Дима не напишет раньше меня).

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

Хотя я бы предпочел чтобы и это было на стороне сервера. Списки пакетов,
которые требуется пересобрать при обновлении некоторого пакета.

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

Качество сборки безусловно вырастет, а вот выдержит ли такой кошмар
incoming?

Я вон и так DoS'ил incoming своими ежедневными снапшотами астериска в
период активного тестирования. Но у меня под это была целая хитрющая туча
скриптов. Поэтому психов вроде меня было мало. Теперь же для этого ужаса
достаточно скриптов из нескольких строк (обновить из svn, обновить
changelog, gear-release, git push).

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

http://freesource.info
----------------------------------------------------------------------------
ПЕРВЫЙ ЗАКОН ПРОТИВОДЕЙСТВИЯ ФУДДА
 Толкните что-нибудь тяжелое, и оно опрокинется.


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

Re: [devel] Build from gear

[Michael Shigorin]

On Sun, Oct 15, 2006 at 06:11:39PM +0400, Денис Смирнов wrote:
>  MS> Слушай, а ты уверен, что грокнул git и не считаешь его таким
>  MS> себе cvs?  Он же весь из себя про деревья и бранчи, а не про 
>  MS> центральный репо и доступ к нему.
> Фигня в том, что эти вкусности использует разработчик. Сам для
> себя.  А в момент когда мы отправляем в Сизиф у нас есть один
> единственный объект со своей историей, который и уйдет на
> сборку.

В рамках флавора -- примерно.

> >> Да, я понимаю что любой имеющий права на сборку модулей
> >> может подсунуть руткит. Но я сомневаюсь что кто-то проводит
> >> вычитку кода всех kernel-source-*.
> MS> От любого желающего просто не надо делать pull.
> Тебе напомнить про apanel, который ты не мог себе собрать из-за
> того что не имел доступ к kernel cvs? И про то как я про него
> забыл, из-за чего ты ой как долго его дожидался? AFAIR я его
> все-таки собрал, но нынешний его статус не знаю.

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

> А я посмотрел. Ему пришлось слишком много несовместимых
> велосипедов изобретать. Будь разработка более открытой этих
> велосипедов не было. Вот ему, например, нужны ядра с другим
> патчем на mppe/mppc, другой pppd, cramfs в ядре и т.д. Он был
> со своими предолжениями просто молча проигнорирован, и потому
> пошел делать свои велосипеды.

Скорее среди нас не нашлось толком тех, кому нужно то же 
или кто дозрел до того же, и только.

> Качество сборки безусловно вырастет, а вот выдержит ли такой
> кошмар incoming?

Есть некоторая надежда, что тут народ здравомыслящий и таки
сперва будет собираться у себя... ну или с неба свалится compile
farm прям на коло в стойку.

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

Re: [devel] Build from gear

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

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

On Sun, Oct 15, 2006 at 09:46:15PM +0300, Michael Shigorin wrote:

>> Фигня в том, что эти вкусности использует разработчик. Сам для
>> себя.  А в момент когда мы отправляем в Сизиф у нас есть один
>> единственный объект со своей историей, который и уйдет на
>> сборку.
MS> В рамках флавора -- примерно.

Ага. Так вот ядреные пакеты, как и php, firefox, asterisk, mozilla и
прочий геморрой имеет одну общую особенность -- полное отсутствие всякого
присутствия гарантии бинарной совместимости как между minor версиями, так
и между разными вариантами сборки. Что вынуждает собирать один и тот же
код в нескольких экземплярах.

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

Поэтому приходится изобретать велосипеды для формирования из одного spec'а
несколько srpm. 

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

В настоящий момент наша новая система на базе git.alt не позволяет сделать
это удобно. Ну да, я в курсе про то что можно генерировать srpm скриптами
из kernel cvs, а потом эти srpm скармливать gear-srpmimport, но у меня
есть более интересные занятия чем закат солнца вручную.

А говорю я в первую очередь о kernel cvs потому как это единственное где у
нас подобную технологию обкатали до вполне работоспособного состояния.

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

> >>> Да, я понимаю что любой имеющий права на сборку модулей
> >>> может подсунуть руткит. Но я сомневаюсь что кто-то проводит
> >>> вычитку кода всех kernel-source-*.
> MS>> От любого желающего просто не надо делать pull.
>> Тебе напомнить про apanel, который ты не мог себе собрать из-за
>> того что не имел доступ к kernel cvs? И про то как я про него
>> забыл, из-за чего ты ой как долго его дожидался? AFAIR я его
>> все-таки собрал, но нынешний его статус не знаю.
MS> Знаешь, если бы мне сильно горело -- я бы уж как-нить прочёл сам
MS> и закинул :-)  Просто ты успел предложить раньше, чем я дочитал.
MS> Соответственно как любой нормальный лодырь, взял и воспользовался.

:)

>> А я посмотрел. Ему пришлось слишком много несовместимых
>> велосипедов изобретать. Будь разработка более открытой этих
>> велосипедов не было. Вот ему, например, нужны ядра с другим
>> патчем на mppe/mppc, другой pppd, cramfs в ядре и т.д. Он был
>> со своими предолжениями просто молча проигнорирован, и потому
>> пошел делать свои велосипеды.
MS> Скорее среди нас не нашлось толком тех, кому нужно то же 
MS> или кто дозрел до того же, и только.

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

>> Качество сборки безусловно вырастет, а вот выдержит ли такой
>> кошмар incoming?
MS> Есть некоторая надежда, что тут народ здравомыслящий и таки
MS> сперва будет собираться у себя... ну или с неба свалится compile
MS> farm прям на коло в стойку.

Собственно, это была мысль вслух не по теме.

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

http://freesource.info
----------------------------------------------------------------------------
Предлагаю закончить меряться .... версиями и заняться
чем-нибудь полезным.
		-- voins in sisyphus@


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

Re: [devel] Build from gear

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [061014 23:46]:
> > Когда на git.altlinux.ru ожидать работающей сборки в incoming из gear?
> По плану в начале ноября, когда сервер приедет.
А gitweb будет?

-- 
Regards,
Sir Raorn.

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

Re: [devel] Build from gear

[Dmitry V. Levin]

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

On Sun, Oct 15, 2006 at 03:03:26PM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [061014 23:46]:
> > > Когда на git.altlinux.ru ожидать работающей сборки в incoming из gear?
> > По плану в начале ноября, когда сервер приедет.
> А gitweb будет?

Будет, наверное, но к сборочному серверу это отношения не имеет.


-- 
ldv

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