Re: [devel] [Sisyphus-cybertalk] I: Sisyphus-20070119 packages: +11! +13 (5661)

Re: [devel] [Sisyphus-cybertalk] I: Sisyphus-20070119 packages: +11! +13 (5661)

[Konstantin A. Lepikhov]

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

Hi QA!

Friday 19, at 12:07:10 AM you wrote:

> kernel-modules-rt61-std-smp - Kernel module for wireless 802.11b and 802.11g cards that are based on the Ralink rt2561/rt61 chip
> * Thu Jan 18 2007 Vitaly Lipatov <lav@altlinux> 1.1.0-alt0.3
> - initial build for ALT Linux Sisyphus
прошу выкладывать в kernel cvs тимплейты .spec для модулей. Иначе такие
пакеты быстро протухают.

-- 
WBR et al.

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

Re: [devel] [Sisyphus-cybertalk] I: Sisyphus-20070119 packages: +11! +13 (5661)

[Vitaly Lipatov]

On Friday 19 January 2007 00:41, Konstantin A. Lepikhov wrote:
> Hi QA!
>
> Friday 19, at 12:07:10 AM you wrote:
> > kernel-modules-rt61-std-smp - Kernel module for wireless
> > 802.11b and 802.11g cards that are based on the Ralink
> > rt2561/rt61 chip * Thu Jan 18 2007 Vitaly Lipatov
> > <lav@altlinux> 1.1.0-alt0.3 - initial build for ALT Linux
> > Sisyphus
>
> прошу выкладывать в kernel cvs тимплейты .spec для модулей.
> Иначе такие пакеты быстро протухают.
а) честно говоря не разу этого ещё не делал,
б) жду когда эта система переедет на git
в) при использовании шаблонов в спеке как я понимаю теряется 
способность собирать эти пакеты вручную (из исходного спека)
г) мне вообще в спеках больше нравятся не шаблоны, а подстановка 
(обновление) нужных полей


-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] [Sisyphus-cybertalk] I: Sisyphus-20070119 packages: +11! +13 (5661)

[Konstantin A. Lepikhov]

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

Hi Vitaly!

Friday 19, at 11:34:30 PM you wrote:

> On Friday 19 January 2007 00:41, Konstantin A. Lepikhov wrote:
> > Hi QA!
> >
> > Friday 19, at 12:07:10 AM you wrote:
> > > kernel-modules-rt61-std-smp - Kernel module for wireless
> > > 802.11b and 802.11g cards that are based on the Ralink
> > > rt2561/rt61 chip * Thu Jan 18 2007 Vitaly Lipatov
> > > <lav@altlinux> 1.1.0-alt0.3 - initial build for ALT Linux
> > > Sisyphus
> >
> > прошу выкладывать в kernel cvs тимплейты .spec для модулей.
> > Иначе такие пакеты быстро протухают.
> а) честно говоря не разу этого ещё не делал,
> б) жду когда эта система переедет на git
если ждать, то система так никогда и не переедет. И что этот git изменит?

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

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


-- 
WBR et al.

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

Re: [devel] [Sisyphus-cybertalk] I: Sisyphus-20070119 packages: +11! +13 (5661)

[Vitaly Lipatov]

On Saturday 20 January 2007 00:14, Konstantin A. Lepikhov wrote:
...
> > б) жду когда эта система переедет на git
>
> если ждать, то система так никогда и не переедет. И что этот
> git изменит?
А перевозить я не собираюсь. git изменит то, что изучать надо 
будет его, а не систему на cvs.

> > в) при использовании шаблонов в спеке как я понимаю теряется
> > способность собирать эти пакеты вручную (из исходного спека)
>
> что значит теряется "способность собирать вручную"? А так их
> кто собирает, робот? На выходе все равно получается нормальный
> .spec под нужное ядро.
У меня уже был пару раз негативный опыт по взаимодействию с 
системой сборки модулей ядра. Готов попробовать ещё раз.
Как получить доступ к cvs?

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

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] [Sisyphus-cybertalk] I: Sisyphus-20070119 packages: +11! +13 (5661)

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

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

On Fri, Jan 19, 2007 at 11:34:30PM +0300, Vitaly Lipatov wrote:

>> прошу выкладывать в kernel cvs тимплейты .spec для модулей.
>> Иначе такие пакеты быстро протухают.
VL> а) честно говоря не разу этого ещё не делал,

Это совсем просто.

VL> б) жду когда эта система переедет на git

А зачем? Тем более когда она будет переезжать лучше чтобы все было как раз
в cvs. Тогда переезд пройдет гладко, и vsu@ не придется собирать по частям
куски модулий из разных мест.

VL> в) при использовании шаблонов в спеке как я понимаю теряется 
VL> способность собирать эти пакеты вручную (из исходного спека)

Из исходного -- теряется, потому как исходный в /dev/null. Остается
шаблон. А вот из шаблона одним простым скриптом генерируется самый что ни
на есть обычный srpm с обычным spec'ом, который можно скормить обычному
hasher'у или обычному rpmbuild.

В сизифе для всех kernel modules вполне себе есть srpm пакеты с
нормальными spec'ами.

VL> г) мне вообще в спеках больше нравятся не шаблоны, а подстановка 
VL> (обновление) нужных полей

Вам нравятся не шаблоны, а шаблоны? ;) Шаблон ведь это и есть то, в чем
подставляются некоторые поля и получают результат.

kernel cvs простая система, в неё врубиться оказалось очень просто.

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

http://freesource.info
----------------------------------------------------------------------------
> fixed a long time ago...
Дык надо было его и зарезолвить "the long time ago..." :-)
		-- zerg in #480

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

Re: [devel] сборка модулей ядра

[Vitaly Lipatov]

On Saturday 20 January 2007 13:34, Денис Смирнов wrote:
...
> kernel cvs простая система, в неё врубиться оказалось очень
> просто.
А какие модули для ядра вы собираете?

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] [Sisyphus-cybertalk] I: Sisyphus-20070119 packages: +11! +13 (5661)

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

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

On Sat, Jan 20, 2007 at 11:33:28AM +0300, Vitaly Lipatov wrote:

>>> б) жду когда эта система переедет на git
>> если ждать, то система так никогда и не переедет. И что этот
>> git изменит?
VL> А перевозить я не собираюсь. git изменит то, что изучать надо 
VL> будет его, а не систему на cvs.

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

> >> в) при использовании шаблонов в спеке как я понимаю теряется
> >> способность собирать эти пакеты вручную (из исходного спека)
>> что значит теряется "способность собирать вручную"? А так их
>> кто собирает, робот? На выходе все равно получается нормальный
>> .spec под нужное ядро.
VL> У меня уже был пару раз негативный опыт по взаимодействию с 
VL> системой сборки модулей ядра. Готов попробовать ещё раз.
VL> Как получить доступ к cvs?

Хороший вопрос :( Я уже даже не помню кто его мне дал. Думаю это делает
либо vsu@, либо rider@

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

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

Подстановка полей не поможет, ибо менять надо там далеко не только
Version.

А вот по поводу доступности kernel cvs -- ау всем кто занимается
документацией, у нас где-нибудь документирована процедура получения
read-write доступа к kernel cvs? И документировано ли где лежит read-only
репозиторий?

У меня есть подозрение что ответ на первый вопрос я почерпнул в свое время
из kernel policy.

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

http://freesource.info
----------------------------------------------------------------------------
БРИТВА ХЕЛЛОНА
 Не усматривайте злого умысла в том, что вполне объяснимо глупостью.


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

Re: [devel] [Sisyphus-cybertalk] I: Sisyphus-20070119 packages: +11! +13 (5661)

[Kirill Maslinsky]

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

On Mon, Jan 22, 2007 at 12:22:27PM +0300, Денис Смирнов wrote:

[...]

> А вот по поводу доступности kernel cvs -- ау всем кто занимается
> документацией, у нас где-нибудь документирована процедура получения
> read-write доступа к kernel cvs? И документировано ли где лежит read-only
> репозиторий?

http://wiki.sisyphus.ru/devel/KernelCVS?v=chw

Видимо, это актуальная информация?

> У меня есть подозрение что ответ на первый вопрос я почерпнул в свое время
> из kernel policy.

Коего на wiki.sisyphus и freesource.info найти не получается.

-- 
Kirill Maslinsky
ALT Linux Documentation Team
http://heap.altlinux.ru

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

Re: [devel] [Sisyphus-cybertalk] I: Sisyphus-20070119 packages: +11! +13 (5661)

[Sergey Vlasov]

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

On Mon, Jan 22, 2007 at 12:22:27PM +0300, Денис Смирнов wrote:
> On Sat, Jan 20, 2007 at 11:33:28AM +0300, Vitaly Lipatov wrote:
> 
> >>> б) жду когда эта система переедет на git
> >> если ждать, то система так никогда и не переедет. И что этот
> >> git изменит?
> VL> А перевозить я не собираюсь. git изменит то, что изучать надо 
> VL> будет его, а не систему на cvs.
> 
> Есть ненулевая вероятность что именно это останется на cvs даже после
> ухода всего остального в git. В cvs хранятся шаблоны spec'ов всего лишь,
> от их переноса куда бы то ни было польза лично мне неочевидна, и я не
> думаю что для кого бы то ни было этот перенос будет приоритетной задачей.

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

> VL> Как получить доступ к cvs?
> 
> Хороший вопрос :( Я уже даже не помню кто его мне дал. Думаю это делает
> либо vsu@, либо rider@

Я тоже не знаю, кто сейчас раздаёт доступ к этому cvs.

> А вот по поводу доступности kernel cvs -- ау всем кто занимается
> документацией, у нас где-нибудь документирована процедура получения
> read-write доступа к kernel cvs?

Разве что где-то в рассылках...

> И документировано ли где лежит read-only репозиторий?

http://wiki.sisyphus.ru/devel/KernelCVS

Для любителей ковыряться в потрохах:
http://lists.altlinux.org/pipermail/devel-kernel/2006-November/006230.html

> У меня есть подозрение что ответ на первый вопрос я почерпнул в свое
> время из kernel policy.

Там вообще нет ни одного слова про cvs.

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

Re: [devel] [Sisyphus-cybertalk] I: Sisyphus-20070119 packages: +11! +13 (5661)

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

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

On Mon, Jan 22, 2007 at 01:33:10PM +0300, Sergey Vlasov wrote:

>> Есть ненулевая вероятность что именно это останется на cvs даже после
>> ухода всего остального в git. В cvs хранятся шаблоны spec'ов всего лишь,
>> от их переноса куда бы то ни было польза лично мне неочевидна, и я не
>> думаю что для кого бы то ни было этот перенос будет приоритетной задачей.
SV> Мне тоже не совсем понятно, как эту часть переносить в git - при
SV> текущей организации git.alt это выльется в десятки репозиториев (как
SV> минимум по одному для каждого модуля), работать с которыми вряд ли
SV> будет удобно.

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

2. Непонятно какие преимущества дают атомарные коммиты для нескольких
файлов, при том что файл-то обычно все-таки один;

Таким образом даже subversion для этой задачи это что-то слишком крутое.

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

Возможно имеет смысл это сделать разве что для консистентности -- чтобы
избежать вопросов вроде "а кто доступ к kernel cvs дает?".

> VL>> Как получить доступ к cvs?
>> Хороший вопрос :( Я уже даже не помню кто его мне дал. Думаю это делает
>> либо vsu@, либо rider@
SV> Я тоже не знаю, кто сейчас раздаёт доступ к этому cvs.

Значит Антон :)

>> А вот по поводу доступности kernel cvs -- ау всем кто занимается
>> документацией, у нас где-нибудь документирована процедура получения
>> read-write доступа к kernel cvs?
SV> Разве что где-то в рассылках...
>> И документировано ли где лежит read-only репозиторий?
SV> http://wiki.sisyphus.ru/devel/KernelCVS
SV> Для любителей ковыряться в потрохах:
SV> http://lists.altlinux.org/pipermail/devel-kernel/2006-November/006230.html
>> У меня есть подозрение что ответ на первый вопрос я почерпнул в свое
>> время из kernel policy.
SV> Там вообще нет ни одного слова про cvs.

Просто великолепно :-(

Может действительно сделать структуру плоской, и выложить в один git
репозиторий все пакеты будет проще всего?

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

http://freesource.info
----------------------------------------------------------------------------
Некоторые, между прочим, и buildreq в hasher'е запускают. :)
		-- ldv in sisyphus@

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

Re: [devel] kernel cvs

[Dmitry V. Levin]

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

On Tue, Jan 23, 2007 at 02:49:05AM +0300, Денис Смирнов wrote:
> On Mon, Jan 22, 2007 at 01:33:10PM +0300, Sergey Vlasov wrote:
[...]
> > VL>> Как получить доступ к cvs?
> >> Хороший вопрос :( Я уже даже не помню кто его мне дал. Думаю это делает
> >> либо vsu@, либо rider@
> SV> Я тоже не знаю, кто сейчас раздаёт доступ к этому cvs.
> 
> Значит Антон :)

Доступ к kernel cvs даёт join@.

[...]
> Может действительно сделать структуру плоской, и выложить в один git
> репозиторий все пакеты будет проще всего?

Что будет проще и кому будет проще?


-- 
ldv

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

Re: [devel] сборка модулей ядра

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

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

On Sat, Jan 20, 2007 at 02:05:53PM +0300, Vitaly Lipatov wrote:

>> kernel cvs простая система, в неё врубиться оказалось очень
>> просто.
VL> А какие модули для ядра вы собираете?

Собирал areca, до тех пор как он не оказался в 2.6.18.
Сейчас собираю zaptel.

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

http://freesource.info
----------------------------------------------------------------------------
Следующий шаг после перерастания жизни в привычку - гроб.
		-- slava in devel@

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

Re: [devel] kernel cvs

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

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

On Tue, Jan 23, 2007 at 08:05:17AM +0300, Dmitry V. Levin wrote:

>> Значит Антон :)
DVL> Доступ к kernel cvs даёт join@.

Логично :)

>> Может действительно сделать структуру плоской, и выложить в один git
>> репозиторий все пакеты будет проще всего?
DVL> Что будет проще и кому будет проще?

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

Недостаток -- возможная рассинхронизация.

С другой стороны не думаю что это важно. Насколько я вижу сейчас -- мне по
крайней мере, с моими модулями, в спеки собственно модулей а не исходников
вносить изменения требуется тогда, когда сборка сломана (из-за изменений в
sources/), и это видно сразу. Соответственно если не собралось -- git pull
из репозитория того, кто работает над этим модулем.

Ну и проще тем, чтобы лишних сущностей (как то cvs) было меньше. После
отказа от не-git incoming/ все будут точно знать, что все необходимое для
сборки чего угодно живет в git, и искать именно там.

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

http://freesource.info
----------------------------------------------------------------------------
РЕШЕНИЕ ХАЛГРЕНА
 Если вы попали впросак, напускайте туману.

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

Re: [devel] kernel cvs

[Konstantin A. Lepikhov]

<цитата от="Денис Смирнов">
<skip>
> С другой стороны не думаю что это важно. Насколько я вижу сейчас -- мне по
> крайней мере, с моими модулями, в спеки собственно модулей а не исходников
> вносить изменения требуется тогда, когда сборка сломана (из-за изменений в
> sources/), и это видно сразу. Соответственно если не собралось -- git pull
> из репозитория того, кто работает над этим модулем.
чем это неудобно - например я собрал ядро и я знаю, что модули у него
хранятся в _одном_ месте и что если я их поправлю, то double work не
будет. А если у каждого в git будет собственный колхоз, то придется бегать
по рассылкам/подписываться на commits, т.е. лишних действий будет еще
больше.

>
> Ну и проще тем, чтобы лишних сущностей (как то cvs) было меньше. После
> отказа от не-git incoming/ все будут точно знать, что все необходимое для
> сборки чего угодно живет в git, и искать именно там.
см. выше - git у каждого свой, долго искать придется.

-- 
WBR et al.

Re: [devel] kernel cvs

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

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

On Wed, Jan 24, 2007 at 07:04:53PM +0300, Konstantin A. Lepikhov wrote:

>> С другой стороны не думаю что это важно. Насколько я вижу сейчас -- мне по
>> крайней мере, с моими модулями, в спеки собственно модулей а не исходников
>> вносить изменения требуется тогда, когда сборка сломана (из-за изменений в
>> sources/), и это видно сразу. Соответственно если не собралось -- git pull
>> из репозитория того, кто работает над этим модулем.
KAL> чем это неудобно - например я собрал ядро и я знаю, что модули у него
KAL> хранятся в _одном_ месте и что если я их поправлю, то double work не
KAL> будет. А если у каждого в git будет собственный колхоз, то придется бегать
KAL> по рассылкам/подписываться на commits, т.е. лишних действий будет еще
KAL> больше.
>> Ну и проще тем, чтобы лишних сущностей (как то cvs) было меньше. После
>> отказа от не-git incoming/ все будут точно знать, что все необходимое для
>> сборки чего угодно живет в git, и искать именно там.
KAL> см. выше - git у каждого свой, долго искать придется.

Я  описал видимые мною преимущества и недостатки обоих подходов, решать
что с этим делать все равно не мне, и мне честно говоря все равно (я уже к
cvs привык :)

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

http://freesource.info
----------------------------------------------------------------------------
Тяжело в писании, легко в гугленьи :-)
		-- mike in devel@

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