На altlinux.org выложена статья по сборке пакетов с модулями для наших ядер. Конструктивная критика приветствуется. http://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9_%D1%8F%D0%B4%D1%80%D0%B0
[-- Attachment #1: Type: text/plain, Size: 2186 bytes --] Hi Михаил! Friday 05, at 02:43:02 PM you wrote: > На altlinux.org выложена статья по сборке пакетов с модулями для наших > ядер. > Конструктивная критика приветствуется. > http://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9_%D1%8F%D0%B4%D1%80%D0%B0 Сразу что бросилось в глаза: 1) Теперь о релизах пакетов с модулями. Поле release заполняется так: alt<module release>.<kernel version>.<kernel release>. - это придумано не просто так, а решает определенную проблему. Например использование magic number в kernel version позволяет избежать случайного вытеснения модуля собранного с более новым kernel-source но старым template модулем собранным со старым kernel-source но новой редакцией template. Прошу это учесть, а не просто принимать как данность или придурь авторов. 2) Как собрать модуль локально - имхо секция вообще ненужная и вредная (поскольку для понимания процесса сборки достаточно прочитать post-halloween документ про 2.6). Лучше расписать как собирать модули без использования hasher (см. старую документацию stanv@ на вики). 3) Сборка kernel-source-module - git знать совершенно необязательно :) Лучше прочитать README из kernel-build-scripts. А вот дать пример как собирать kernel-source на основе "следящего" бранча было бы здорово. 4) сборка модулей - пример для сборки i586 под x86_64 дан неправильно, поскольку нехватает i386 в начале вызова команды. Опять же, забыта -m32 в случае сборки без hasher. 5) Рекомендации. Мантейнер написан неправильно :) Взаимодействовать с ними можно, только вот неясно с кем - т.е. надо расписать задачи kernel mainteiners team, чем она занимается, для чего нужна и как с ней взаимодействовать. Поскольку текущий текст вреден - он провоцирует на неправильные действия (типа создать модуль, написать в Packager: KMT и потом KMT будет за это отдуваться). 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :) 7) Отсутствует история по сборке модуей, т.е. как мы дошли до жизни такой. Наличие истории позволяет проследить тот длинный путь проб и ошибок + заглянуть в будущее. -- WBR et al. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
Konstantin A. Lepikhov wrote: > Hi Михаил! > > Friday 05, at 02:43:02 PM you wrote: > >> На altlinux.org выложена статья по сборке пакетов с модулями для наших >> ядер. >> Конструктивная критика приветствуется. >> http://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9_%D1%8F%D0%B4%D1%80%D0%B0 > Сразу что бросилось в глаза: > > 1) Теперь о релизах пакетов с модулями. Поле release заполняется так: > alt<module release>.<kernel version>.<kernel release>. > > - это придумано не просто так, а решает определенную проблему. Например > использование magic number в kernel version позволяет избежать > случайного вытеснения модуля собранного с более новым kernel-source но > старым template модулем собранным со старым kernel-source но новой > редакцией template. Прошу это учесть, а не просто принимать как > данность или придурь авторов. Если не трудно, добавь пожалуйста. > 2) Как собрать модуль локально - имхо секция вообще ненужная и вредная > (поскольку для понимания процесса сборки достаточно прочитать > post-halloween документ про 2.6). Что она может быть вредна, согласен, долго сомневался стоит ли её писать. Лучше расписать как собирать модули без > использования hasher (см. старую документацию stanv@ на вики). А там про хешер ничего не сказано. > 3) Сборка kernel-source-module - git знать совершенно необязательно :) > Лучше прочитать README из kernel-build-scripts. А вот дать пример как > собирать kernel-source на основе "следящего" бранча было бы здорово. в смысле kernel-source большой? от ядра? > 4) сборка модулей - пример для сборки i586 под x86_64 дан неправильно, > поскольку нехватает i386 в начале вызова команды. В той версии buildmoudles которую я указал, setarch i586 прикручен внутрь. Это решает некоторые проблемы с некоторыми темплейтами. > Опять же, забыта -m32 в > случае сборки без hasher. не думаю что кто-то будет собирать модуль без хешера под другую архитектуру. > 5) Рекомендации. Мантейнер написан неправильно :) Взаимодействовать с ними > можно, только вот неясно с кем - т.е. надо расписать задачи kernel > mainteiners team, чем она занимается, для чего нужна и как с ней > взаимодействовать. Поскольку текущий текст вреден - он провоцирует на > неправильные действия (типа создать модуль, написать в Packager: KMT и > потом KMT будет за это отдуваться). Документировать ещё многое надо, я только начал. > 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :) А что там по твоему должно быть написано? > 7) Отсутствует история по сборке модуей, т.е. как мы дошли до жизни такой. > Наличие истории позволяет проследить тот длинный путь проб и ошибок + > заглянуть в будущее. Если не трудно, допиши.
[-- Attachment #1: Type: text/plain, Size: 3577 bytes --] Hi Михаил! Friday 05, at 03:58:37 PM you wrote: > Konstantin A. Lepikhov wrote: > > Hi Михаил! > > > > Friday 05, at 02:43:02 PM you wrote: > > > >> На altlinux.org выложена статья по сборке пакетов с модулями для наших > >> ядер. > >> Конструктивная критика приветствуется. > >> http://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9_%D1%8F%D0%B4%D1%80%D0%B0 > > Сразу что бросилось в глаза: > > > > 1) Теперь о релизах пакетов с модулями. Поле release заполняется так: > > alt<module release>.<kernel version>.<kernel release>. > > > > - это придумано не просто так, а решает определенную проблему. Например > > использование magic number в kernel version позволяет избежать > > случайного вытеснения модуля собранного с более новым kernel-source но > > старым template модулем собранным со старым kernel-source но новой > > редакцией template. Прошу это учесть, а не просто принимать как > > данность или придурь авторов. > Если не трудно, добавь пожалуйста. Я ничего не пишу на wiki, поскольку это ненадежный источник хранения информации. Комментировать в рассылку - могу. > > 2) Как собрать модуль локально - имхо секция вообще ненужная и вредная > > (поскольку для понимания процесса сборки достаточно прочитать > > post-halloween документ про 2.6). > Что она может быть вредна, согласен, долго сомневался стоит ли её писать. > Лучше расписать как собирать модули без > > использования hasher (см. старую документацию stanv@ на вики). > А там про хешер ничего не сказано. ./buildmodules --hasher это разве не хешер? > > 3) Сборка kernel-source-module - git знать совершенно необязательно :) > > Лучше прочитать README из kernel-build-scripts. А вот дать пример как > > собирать kernel-source на основе "следящего" бранча было бы здорово. > в смысле kernel-source большой? от ядра? Нет. Когда есть branch upstream, и бранч kernel-source. См. пример kernel-image или http://git.altlinux.org/people/lakostis/packages/?p=kernel-source-et131x.git;a=summary > > 4) сборка модулей - пример для сборки i586 под x86_64 дан неправильно, > > поскольку нехватает i386 в начале вызова команды. > В той версии buildmoudles которую я указал, setarch i586 прикручен > внутрь. Это решает некоторые проблемы с некоторыми темплейтами. Почему это изменение нигде не анонсировано? Более того, об этом даже не упомянуто в документации. > > Опять же, забыта -m32 в > > случае сборки без hasher. > не думаю что кто-то будет собирать модуль без хешера под другую архитектуру. а ты подумай ;) > > 5) Рекомендации. Мантейнер написан неправильно :) Взаимодействовать с ними > > можно, только вот неясно с кем - т.е. надо расписать задачи kernel > > mainteiners team, чем она занимается, для чего нужна и как с ней > > взаимодействовать. Поскольку текущий текст вреден - он провоцирует на > > неправильные действия (типа создать модуль, написать в Packager: KMT и > > потом KMT будет за это отдуваться). > Документировать ещё многое надо, я только начал. > > 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :) > А что там по твоему должно быть написано? как минимум kernel-build-scripts должны вести к vsu, хотя бы из-за уважения к чужой работе. > > 7) Отсутствует история по сборке модуей, т.е. как мы дошли до жизни такой. > > Наличие истории позволяет проследить тот длинный путь проб и ошибок + > > заглянуть в будущее. > Если не трудно, допиши. За меня это прекрасно расскажут архивы devel-kernel@. -- WBR et al. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 435 bytes --] On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote: > 3) Сборка kernel-source-module - git знать совершенно необязательно :) > Лучше прочитать README из kernel-build-scripts. А вот дать пример как > собирать kernel-source на основе "следящего" бранча было бы здорово. Пожалуйста, искорените слово kernel-build-scripts отовсюду. Есть пакет по имени kernel-build-tools, ссылаться лучше на него. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
Konstantin A. Lepikhov wrote: [skip] > Я ничего не пишу на wiki, поскольку это ненадежный источник хранения > информации. Комментировать в рассылку - могу. no comments >>> 2) Как собрать модуль локально - имхо секция вообще ненужная и вредная [skip] >> А там про хешер ничего не сказано. > ./buildmodules --hasher это разве не хешер? А ты имеешь ввиду buildmodules без хешера, а зачем это нужно, ни разу не пригодилось. >>> 3) Сборка kernel-source-module - git знать совершенно необязательно :) >>> Лучше прочитать README из kernel-build-scripts. А вот дать пример как >>> собирать kernel-source на основе "следящего" бранча было бы здорово. >> в смысле kernel-source большой? от ядра? > Нет. Когда есть branch upstream, и бранч kernel-source. См. пример > kernel-image или > http://git.altlinux.org/people/lakostis/packages/?p=kernel-source-et131x.git;a=summary а понял, да надо дописать. >>> 4) сборка модулей - пример для сборки i586 под x86_64 дан неправильно, >>> поскольку нехватает i386 в начале вызова команды. >> В той версии buildmoudles которую я указал, setarch i586 прикручен >> внутрь. Это решает некоторые проблемы с некоторыми темплейтами. > Почему это изменение нигде не анонсировано? Более того, об этом даже не > упомянуто в документации. Это изменение описано в log git. Пока нет нормального пакета( а стоит сделать) и анонсировать нечего. >>> 5) Рекомендации. Мантейнер написан неправильно :) Взаимодействовать с ними >>> можно, только вот неясно с кем - т.е. надо расписать задачи kernel >>> mainteiners team, чем она занимается, для чего нужна и как с ней >>> взаимодействовать. Поскольку текущий текст вреден - он провоцирует на >>> неправильные действия (типа создать модуль, написать в Packager: KMT и >>> потом KMT будет за это отдуваться). >> Документировать ещё многое надо, я только начал. >>> 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :) >> А что там по твоему должно быть написано? > как минимум kernel-build-scripts должны вести к vsu, хотя бы из-за > уважения к чужой работе. А почему не ldv? он там тоже приложил руку. kernel-build-scripts ведёт в мой git из за изменений описаных выше.
[-- Attachment #1: Type: text/plain, Size: 843 bytes --] On Fri, Sep 05, 2008 at 04:12:21PM +0400, Konstantin A. Lepikhov wrote: > > > 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :) > > А что там по твоему должно быть написано? > как минимум kernel-build-scripts должны вести к vsu, хотя бы из-за > уважения к чужой работе. Не все git'ы одинаково полезны. Общее правило для составителя документации: если есть нормальный пакет с инструментарием, не надо давать ссылку на его git-репозиторий пользователям, ибо очень редко пользователь инструмента является его разработчиком (в последнем случае ему не составит труда найти этот git-репозиторий). В данном случае пользователю нужен установленный пакет kernel-build-tools, а не его git-репозиторий. Вы же не даёте ссылки на hasher.git и gear.git для обычных пользователей hasher и gear, верно? -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
Dmitry V. Levin wrote:
> On Fri, Sep 05, 2008 at 04:12:21PM +0400, Konstantin A. Lepikhov wrote:
>>>> 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :)
>>> А что там по твоему должно быть написано?
>> как минимум kernel-build-scripts должны вести к vsu, хотя бы из-за
>> уважения к чужой работе.
>
> Не все git'ы одинаково полезны.
> Общее правило для составителя документации: если есть нормальный пакет с
> инструментарием, не надо давать ссылку на его git-репозиторий
> пользователям, ибо очень редко пользователь инструмента является его
> разработчиком (в последнем случае ему не составит труда найти этот
> git-репозиторий). В данном случае пользователю нужен установленный
> пакет kernel-build-tools, а не его git-репозиторий.
> Вы же не даёте ссылки на hasher.git и gear.git для обычных пользователей
> hasher и gear, верно?
Блин, я пропустил что есть такой пакет. Надо поправить.
[-- Attachment #1: Type: text/plain, Size: 593 bytes --] Hi Dmitry! Friday 05, at 04:18:34 PM you wrote: > On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote: > > 3) Сборка kernel-source-module - git знать совершенно необязательно :) > > Лучше прочитать README из kernel-build-scripts. А вот дать пример как > > собирать kernel-source на основе "следящего" бранча было бы здорово. > > Пожалуйста, искорените слово kernel-build-scripts отовсюду. > Есть пакет по имени kernel-build-tools, ссылаться лучше на него. Замечательно. Только там вызова setarch нет. Поэтому i386 пока придется добавлять. -- WBR et al. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 904 bytes --] On Fri, Sep 05, 2008 at 04:32:33PM +0400, Konstantin A. Lepikhov wrote: > Friday 05, at 04:18:34 PM you wrote: > > On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote: > > > 3) Сборка kernel-source-module - git знать совершенно необязательно :) > > > Лучше прочитать README из kernel-build-scripts. А вот дать пример как > > > собирать kernel-source на основе "следящего" бранча было бы здорово. > > > > Пожалуйста, искорените слово kernel-build-scripts отовсюду. > > Есть пакет по имени kernel-build-tools, ссылаться лучше на него. > Замечательно. Только там вызова setarch нет. Поэтому i386 пока придется > добавлять. kernel-build-tools паковал мантейнер бывшего kernel-build-scripts, как могло получиться, что setarch не доехал из kernel-build-scripts в kernel-build-tools? В любом случае, лучше поправить kernel-build-tools, поскольку он опакечен. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --] Hi Dmitry! Friday 05, at 04:36:25 PM you wrote: > On Fri, Sep 05, 2008 at 04:32:33PM +0400, Konstantin A. Lepikhov wrote: > > Friday 05, at 04:18:34 PM you wrote: > > > On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote: > > > > 3) Сборка kernel-source-module - git знать совершенно необязательно :) > > > > Лучше прочитать README из kernel-build-scripts. А вот дать пример как > > > > собирать kernel-source на основе "следящего" бранча было бы здорово. > > > > > > Пожалуйста, искорените слово kernel-build-scripts отовсюду. > > > Есть пакет по имени kernel-build-tools, ссылаться лучше на него. > > Замечательно. Только там вызова setarch нет. Поэтому i386 пока придется > > добавлять. > > kernel-build-tools паковал мантейнер бывшего kernel-build-scripts, как > могло получиться, что setarch не доехал из kernel-build-scripts в > kernel-build-tools? В любом случае, лучше поправить kernel-build-tools, > поскольку он опакечен. Насколько я понял - вызов с setarch это локальный хак который сделал silicium и никому об этом не сказал. Желающие проверить эту гипотезу могут порыться в git'ах самостоятельно :) -- WBR et al. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
Konstantin A. Lepikhov wrote:
> Hi Dmitry!
>
> Friday 05, at 04:36:25 PM you wrote:
>
>> On Fri, Sep 05, 2008 at 04:32:33PM +0400, Konstantin A. Lepikhov wrote:
>>> Friday 05, at 04:18:34 PM you wrote:
>>>> On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote:
>>>>> 3) Сборка kernel-source-module - git знать совершенно необязательно :)
>>>>> Лучше прочитать README из kernel-build-scripts. А вот дать пример как
>>>>> собирать kernel-source на основе "следящего" бранча было бы здорово.
>>>> Пожалуйста, искорените слово kernel-build-scripts отовсюду.
>>>> Есть пакет по имени kernel-build-tools, ссылаться лучше на него.
>>> Замечательно. Только там вызова setarch нет. Поэтому i386 пока придется
>>> добавлять.
>> kernel-build-tools паковал мантейнер бывшего kernel-build-scripts, как
>> могло получиться, что setarch не доехал из kernel-build-scripts в
>> kernel-build-tools? В любом случае, лучше поправить kernel-build-tools,
>> поскольку он опакечен.
> Насколько я понял - вызов с setarch это локальный хак который сделал
> silicium и никому об этом не сказал. Желающие проверить эту гипотезу могут
> порыться в git'ах самостоятельно :)
Да, так и было, исходя из вышесказаного имеет смысл обновить
kernel-build-tools c этим хаком.
Hi Михаил! Friday 05, at 04:24:37 PM you wrote: .... > >> А там про хешер ничего не сказано. > > ./buildmodules --hasher это разве не хешер? > А ты имеешь ввиду buildmodules без хешера, а зачем это нужно, ни разу не > пригодилось. Ну вот не надо думать, что раз это не пригодилось тебе, не пригодится и другим. Этот функционал есть в kernel-build-tools и он прекрасно реализован. Еще раз, прочти документацию stanv@ и убедись, что это работает. .... > >>> 5) Рекомендации. Мантейнер написан неправильно :) Взаимодействовать с ними > >>> можно, только вот неясно с кем - т.е. надо расписать задачи kernel > >>> mainteiners team, чем она занимается, для чего нужна и как с ней > >>> взаимодействовать. Поскольку текущий текст вреден - он провоцирует на > >>> неправильные действия (типа создать модуль, написать в Packager: KMT и > >>> потом KMT будет за это отдуваться). > >> Документировать ещё многое надо, я только начал. > >>> 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :) > >> А что там по твоему должно быть написано? > > как минимум kernel-build-scripts должны вести к vsu, хотя бы из-за > > уважения к чужой работе. > А почему не ldv? он там тоже приложил руку. > kernel-build-scripts ведёт в мой git из за изменений описаных выше. Нужен пример хорошого kernel-source и template. По-моему скромному мнению в /silicium/packages таких примеров нет. -- WBR et al.
[-- Attachment #1: Type: text/plain, Size: 1378 bytes --] On Fri, Sep 05, 2008 at 04:42:06PM +0400, Михаил Якушин wrote: > Konstantin A. Lepikhov wrote: > >Friday 05, at 04:36:25 PM you wrote: > >>On Fri, Sep 05, 2008 at 04:32:33PM +0400, Konstantin A. Lepikhov wrote: > >>>Friday 05, at 04:18:34 PM you wrote: > >>>>On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote: > >>>>>3) Сборка kernel-source-module - git знать совершенно необязательно :) > >>>>>Лучше прочитать README из kernel-build-scripts. А вот дать пример как > >>>>>собирать kernel-source на основе "следящего" бранча было бы здорово. > >>>>Пожалуйста, искорените слово kernel-build-scripts отовсюду. > >>>>Есть пакет по имени kernel-build-tools, ссылаться лучше на него. > >>>Замечательно. Только там вызова setarch нет. Поэтому i386 пока придется > >>>добавлять. > >>kernel-build-tools паковал мантейнер бывшего kernel-build-scripts, как > >>могло получиться, что setarch не доехал из kernel-build-scripts в > >>kernel-build-tools? В любом случае, лучше поправить kernel-build-tools, > >>поскольку он опакечен. > >Насколько я понял - вызов с setarch это локальный хак который сделал > >silicium и никому об этом не сказал. Желающие проверить эту гипотезу могут > >порыться в git'ах самостоятельно :) > Да, так и было, исходя из вышесказаного имеет смысл обновить > kernel-build-tools c этим хаком. Действуй! -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
Konstantin A. Lepikhov wrote:
[skip]
>>>>> 5) Рекомендации. Мантейнер написан неправильно :) Взаимодействовать с ними
>>>>> можно, только вот неясно с кем - т.е. надо расписать задачи kernel
>>>>> mainteiners team, чем она занимается, для чего нужна и как с ней
>>>>> взаимодействовать. Поскольку текущий текст вреден - он провоцирует на
>>>>> неправильные действия (типа создать модуль, написать в Packager: KMT и
>>>>> потом KMT будет за это отдуваться).
>>>> Документировать ещё многое надо, я только начал.
>>>>> 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :)
>>>> А что там по твоему должно быть написано?
>>> как минимум kernel-build-scripts должны вести к vsu, хотя бы из-за
>>> уважения к чужой работе.
>> А почему не ldv? он там тоже приложил руку.
>> kernel-build-scripts ведёт в мой git из за изменений описаных выше.
> Нужен пример хорошого kernel-source и template. По-моему скромному мнению
> в /silicium/packages таких примеров нет.
>
Можешь привести пример хорошего, и достаточно простого темплейта?.
Dmitry V. Levin wrote:
> On Fri, Sep 05, 2008 at 04:42:06PM +0400, Михаил Якушин wrote:
>> Konstantin A. Lepikhov wrote:
>>> Friday 05, at 04:36:25 PM you wrote:
>>>> On Fri, Sep 05, 2008 at 04:32:33PM +0400, Konstantin A. Lepikhov wrote:
>>>>> Friday 05, at 04:18:34 PM you wrote:
>>>>>> On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote:
>>>>>>> 3) Сборка kernel-source-module - git знать совершенно необязательно :)
>>>>>>> Лучше прочитать README из kernel-build-scripts. А вот дать пример как
>>>>>>> собирать kernel-source на основе "следящего" бранча было бы здорово.
>>>>>> Пожалуйста, искорените слово kernel-build-scripts отовсюду.
>>>>>> Есть пакет по имени kernel-build-tools, ссылаться лучше на него.
>>>>> Замечательно. Только там вызова setarch нет. Поэтому i386 пока придется
>>>>> добавлять.
>>>> kernel-build-tools паковал мантейнер бывшего kernel-build-scripts, как
>>>> могло получиться, что setarch не доехал из kernel-build-scripts в
>>>> kernel-build-tools? В любом случае, лучше поправить kernel-build-tools,
>>>> поскольку он опакечен.
>>> Насколько я понял - вызов с setarch это локальный хак который сделал
>>> silicium и никому об этом не сказал. Желающие проверить эту гипотезу могут
>>> порыться в git'ах самостоятельно :)
>> Да, так и было, исходя из вышесказаного имеет смысл обновить
>> kernel-build-tools c этим хаком.
>
> Действуй!
Я там ещё скриптов парочку сделал. Например для грамотного
menuconfig\oldconfig может их ещё доложить?
[-- Attachment #1: Type: text/plain, Size: 579 bytes --] On Fri, Sep 05, 2008 at 04:56:09PM +0400, Михаил Якушин wrote: > Dmitry V. Levin wrote: > >On Fri, Sep 05, 2008 at 04:42:06PM +0400, Михаил Якушин wrote: [...] > >>Да, так и было, исходя из вышесказаного имеет смысл обновить > >>kernel-build-tools c этим хаком. > > > >Действуй! > Я там ещё скриптов парочку сделал. Например для грамотного > menuconfig\oldconfig может их ещё доложить? Сейчас у всех скриптов пакета kernel-build-tools, лежащих в /usr/bin/, есть manpage. Если решишь паковать новые скрипты, не забудь запаковать и manpage для них. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
Hi Михаил!
Friday 05, at 04:56:09 PM you wrote:
> Dmitry V. Levin wrote:
> > On Fri, Sep 05, 2008 at 04:42:06PM +0400, Михаил Якушин wrote:
> >> Konstantin A. Lepikhov wrote:
> >>> Friday 05, at 04:36:25 PM you wrote:
> >>>> On Fri, Sep 05, 2008 at 04:32:33PM +0400, Konstantin A. Lepikhov wrote:
> >>>>> Friday 05, at 04:18:34 PM you wrote:
> >>>>>> On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote:
> >>>>>>> 3) Сборка kernel-source-module - git знать совершенно необязательно :)
> >>>>>>> Лучше прочитать README из kernel-build-scripts. А вот дать пример как
> >>>>>>> собирать kernel-source на основе "следящего" бранча было бы здорово.
> >>>>>> Пожалуйста, искорените слово kernel-build-scripts отовсюду.
> >>>>>> Есть пакет по имени kernel-build-tools, ссылаться лучше на него.
> >>>>> Замечательно. Только там вызова setarch нет. Поэтому i386 пока придется
> >>>>> добавлять.
> >>>> kernel-build-tools паковал мантейнер бывшего kernel-build-scripts, как
> >>>> могло получиться, что setarch не доехал из kernel-build-scripts в
> >>>> kernel-build-tools? В любом случае, лучше поправить kernel-build-tools,
> >>>> поскольку он опакечен.
> >>> Насколько я понял - вызов с setarch это локальный хак который сделал
> >>> silicium и никому об этом не сказал. Желающие проверить эту гипотезу могут
> >>> порыться в git'ах самостоятельно :)
> >> Да, так и было, исходя из вышесказаного имеет смысл обновить
> >> kernel-build-tools c этим хаком.
> >
> > Действуй!
> Я там ещё скриптов парочку сделал. Например для грамотного
> menuconfig\oldconfig может их ещё доложить?
И где эти скрипты?
--
WBR et al.
Konstantin A. Lepikhov wrote:
[skip]
>> Я там ещё скриптов парочку сделал. Например для грамотного
>> menuconfig\oldconfig может их ещё доложить?
> И где эти скрипты?
>
Пока у меня в хомнике только. Для нормального выкладывания их стоит
заметно переработать, так как там много гвоздей.
Hi Михаил!
Friday 05, at 04:53:46 PM you wrote:
> > Нужен пример хорошого kernel-source и template. По-моему скромному мнению
> > в /silicium/packages таких примеров нет.
> >
> Можешь привести пример хорошего, и достаточно простого темплейта?.
templates/atl2/sisyphus.
--
WBR et al.
On Fri, Sep 05, 2008 at 04:12:21PM +0400, Konstantin A. Lepikhov wrote: > > Если не трудно, добавь пожалуйста. > Я ничего не пишу на wiki, поскольку это ненадежный источник хранения > информации. Комментировать в рассылку - могу. Достаточно надёжный, там же все ходы записываются. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
Hi Michael!
Monday 08, at 05:49:37 PM you wrote:
> On Fri, Sep 05, 2008 at 04:12:21PM +0400, Konstantin A. Lepikhov wrote:
> > > Если не трудно, добавь пожалуйста.
> > Я ничего не пишу на wiki, поскольку это ненадежный источник хранения
> > информации. Комментировать в рассылку - могу.
>
> Достаточно надёжный, там же все ходы записываются.
С нулевым резервированием :( Нет, лучше рассылки с зеркалами на
mail-archive и gmane.
--
WBR et al.
[-- Attachment #1: Type: text/plain, Size: 558 bytes --] On Mon, Sep 08, 2008 at 07:29:44PM +0400, Konstantin A. Lepikhov wrote: > > > > Если не трудно, добавь пожалуйста. > > > Я ничего не пишу на wiki, поскольку это ненадежный источник > > > хранения информации. Комментировать в рассылку - могу. > > Достаточно надёжный, там же все ходы записываются. > С нулевым резервированием :( Нет, лучше рассылки с зеркалами на > mail-archive и gmane. Кстати, да: предоставлю место для бэкапа www.altlinux.org. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
5 сентября 2008 г. 13:43 Михаил Якушин написал: > На altlinux.org выложена статья по сборке пакетов с модулями для наших > ядер. > Конструктивная критика приветствуется. > http://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9_%D1%8F%D0%B4%D1%80%D0%B0 > Не очень понятно в пункте: http://www.altlinux.org/Сборка_модулей_ядра#.D0.9A.D0.B0.D0.BA_.D0.B2.D1.8B.D0.BB.D0.BE.D0.B6.D0.B8.D1.82.D1.8C_.D1.81.D0.B2.D0.BE.D0.B9_.D0.BC.D0.BE.D0.B4.D1.83.D0.BB.D1.8C_.D0.B2_.D1.80.D0.B5.D0.BF.D0.BE.D0.B7.D0.B8.D1.82.D0.BE.D1.80.D0.B8.D0.B9 "Осталось собрать пакеты через git.alt." Да и с этими templates тоже не всё ясно, почему они находятся в репозитории public? $ git remote add public git.alt:packages/kernel-modules.git $ git push --all public И почему kernel-source также в public? $ git remote add public git.alt:packages/kernel-source-module.git $ git push --all public -- С уважением, Ринат Биков.
04.02.2011 23:06, Rinat Bikov пишет:
> 5 сентября 2008 г. 13:43 Михаил Якушин написал:
>> На altlinux.org выложена статья по сборке пакетов с модулями для наших
>> ядер.
>> Конструктивная критика приветствуется.
>> http://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9_%D1%8F%D0%B4%D1%80%D0%B0
>>
> Не очень понятно в пункте:
> http://www.altlinux.org/Сборка_модулей_ядра#.D0.9A.D0.B0.D0.BA_.D0.B2.D1.8B.D0.BB.D0.BE.D0.B6.D0.B8.D1.82.D1.8C_.D1.81.D0.B2.D0.BE.D0.B9_.D0.BC.D0.BE.D0.B4.D1.83.D0.BB.D1.8C_.D0.B2_.D1.80.D0.B5.D0.BF.D0.BE.D0.B7.D0.B8.D1.82.D0.BE.D1.80.D0.B8.D0.B9
> "Осталось собрать пакеты через git.alt."
> Да и с этими templates тоже не всё ясно, почему они находятся в
> репозитории public?
> $ git remote add public git.alt:packages/kernel-modules.git
> $ git push --all public
> И почему kernel-source также в public?
> $ git remote add public git.alt:packages/kernel-source-module.git
> $ git push --all public
>
потому что у каждого репозитария public настроен на разные адреса.
в место public можно писать прямой URL к репозитарию на сервере
4 февраля 2011 г. 23:38 Michail Yakushin написал:
[...]
>> http://www.altlinux.org/Сборка_модулей_ядра#.D0.9A.D0.B0.D0.BA_.D0.B2.D1.8B.D0.BB.D0.BE.D0.B6.D0.B8.D1.82.D1.8C_.D1.81.D0.B2.D0.BE.D0.B9_.D0.BC.D0.BE.D0.B4.D1.83.D0.BB.D1.8C_.D0.B2_.D1.80.D0.B5.D0.BF.D0.BE.D0.B7.D0.B8.D1.82.D0.BE.D1.80.D0.B8.D0.B9
>> "Осталось собрать пакеты через git.alt."
Всё-таки в этом месте лучше бы по-подробнее.
Как я понял, стандартом де-факто здесь является локальная сборка в
hasher'e при помощи скрипта buildmodules и последующая заливка
src.rpm-пакета?
[...]
--
С уважением, Ринат Биков.
05.02.2011 02:06, Rinat Bikov пишет: > Не очень понятно в пункте: > http://www.altlinux.org/Сборка_модулей_ядра#.D0.9A.D0.B0.D0.BA_.D0.B2.D1.8B.D0.BB.D0.BE.D0.B6.D0.B8.D1.82.D1.8C_.D1.81.D0.B2.D0.BE.D0.B9_.D0.BC.D0.BE.D0.B4.D1.83.D0.BB.D1.8C_.D0.B2_.D1.80.D0.B5.D0.BF.D0.BE.D0.B7.D0.B8.D1.82.D0.BE.D1.80.D0.B8.D0.B9 > "Осталось собрать пакеты через git.alt." что именно непонятно? "собрать через git.alt"? это значит собрать в сизиф из gear (в противоположность srpm). > Да и с этими templates тоже не всё ясно, что именно неясно? > почему они находятся в > репозитории public? > $ git remote add public git.alt:packages/kernel-modules.git назовите по-другому, как удобней. всё равно, кроме вас, этого никто не заметит. и да, это не репозиторий называется public, а ваш локальный псевдоним для внешнего источника, который в данном случае - ваш собственный репозиторий на git.alt. обычно у нас эти псевдонимы - origin, но в случае ядер он отведён под ядро от silicium@ ;) -- REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
05.02.2011 13:06, Rinat Bikov пишет:
> 4 февраля 2011 г. 23:38 Michail Yakushin написал:
> [...]
>>> http://www.altlinux.org/Сборка_модулей_ядра#.D0.9A.D0.B0.D0.BA_.D0.B2.D1.8B.D0.BB.D0.BE.D0.B6.D0.B8.D1.82.D1.8C_.D1.81.D0.B2.D0.BE.D0.B9_.D0.BC.D0.BE.D0.B4.D1.83.D0.BB.D1.8C_.D0.B2_.D1.80.D0.B5.D0.BF.D0.BE.D0.B7.D0.B8.D1.82.D0.BE.D1.80.D0.B8.D0.B9
>>> "Осталось собрать пакеты через git.alt."
> Всё-таки в этом месте лучше бы по-подробнее.
> Как я понял, стандартом де-факто здесь является локальная сборка в
> hasher'e при помощи скрипта buildmodules и последующая заливка
> src.rpm-пакета?
> [...]
>
Нет. Создание им же правильного бранча и тега и сборка уже его.