[devel] Новая схема ведения исходников ядра

[devel] Новая схема ведения исходников ядра

[Evgeny Sinelnikov]

Доброй ночи,

хочу сообщить, что asheplyakov@ по мотивам наших с ним обсуждений о
разработке ядра подготовил новую сборку на основе текущей в сизифе.
http://git.altlinux.org/gears/k/kernel-image-un-def.git

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

- все наши патчи складываются "ребейзом" или "черипиком" поверх
последнего релиза, который заявлен в версии пакета
kernel-image-FLAVOUR:
 + https://github.com/altlinux/linux-arm/commits/altlinux-5.15.y

- схема сборки остаётся прежней за следующими дополнениями:
 + ветка sisyphus содержит только gear-rules и spec (ну, пока и не
надо больше - вряд ли потребуется, хотя я бы предложил ещё README по
сборке);
 + исходники включают в себя только продуктивные патчи и ветка с ними
перед сборкой "мёрджится" с git merge -s ours;
 + для удобной работы над исходниками можно воспользоваться командой
git worktree, позволяющей получить отдельную ветку в соседнем каталоге
на одном и том же git-репозитории;
 + перед сборкой необходимо обновить commitid в .gear/tags/list
https://github.com/altlinux/linux-arm/commits/sisyphus-un-def

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

Я бы ещё предложил делать два патча:
- linux-x.y.0-x.y.z.patch
- linux- x.y.z-alt.patch
тогда патч в нашем SRCRPM-пакете ядра будет не столь бесполезен, чем сейчас.

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

Тестовая сборка упала из-за ограничений на подпись.
#291228 FAILED #2 [test-only] sisyphus
linux.git=kernel-image-un-def-5.15.6-alt2 [...]
http://git.altlinux.org/tasks/291228/logs/events.2.1.log
...
 - Verifying /boot/vmlinuz-5.15.6-un-def-alt2
 Signature verification failed
 = PESIGN verification failures 1, successes 0.
 /usr/lib/rpm/check-pesign.filetrigger failed
 error: posttrans filetriggers scriptlet failed, exit status 1
...
То есть её можно пробовать.
Это, по сути, та же сборка, что и alt1, но по новой схеме.


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Новая схема ведения исходников ядра

[Andrey Savchenko]

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

On Fri, 3 Dec 2021 23:41:56 +0400 Evgeny Sinelnikov wrote:
> Суть: для того, чтобы вести не только поддержку сборки, но разработку
> ядра, нацеленную на продвижение наших патчей в апстрим, предлагается
> рассмотреть новую схему ведения исходников.
> 
> - все наши патчи складываются "ребейзом" или "черипиком" поверх
> последнего релиза, который заявлен в версии пакета
> kernel-image-FLAVOUR:
>  + https://github.com/altlinux/linux-arm/commits/altlinux-5.15.y

cherry-pick не осилит merge коммиты (максимум, что можно от него
получить, это всю ветку одним коммитом, с потерей истории). Ну
а rebase — на любителя и не всегда годится, например, когда часть
патчей нужно выбросить по тем или иным причинам.

> - схема сборки остаётся прежней за следующими дополнениями:
>  + ветка sisyphus содержит только gear-rules и spec (ну, пока и не
> надо больше - вряд ли потребуется, хотя я бы предложил ещё README по
> сборке);
>  + исходники включают в себя только продуктивные патчи и ветка с ними
> перед сборкой "мёрджится" с git merge -s ours;
>  + для удобной работы над исходниками можно воспользоваться командой
> git worktree, позволяющей получить отдельную ветку в соседнем каталоге
> на одном и том же git-репозитории;

Так себе удобство, честно скажу; я пользуюсь этим когда
приходится, но именно как вынужденной мерой. Хотя бы потому, что
в git крайне не рекомендуется конкурентно коммитить из двух разных
worktree.

>  + перед сборкой необходимо обновить commitid в .gear/tags/list
> https://github.com/altlinux/linux-arm/commits/sisyphus-un-def

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

> В целом, этот подход ничего не ломает, но очень много позволяет:
> - чётко отслеживать пачти;
> - всегда знать чем наше ядро отличается от апстримного не на уровне
> одного большого "дифа", доступного только git в консоли, но и на
> уровне полного списка патчей, доступного также через web-интерфейс в
> соответствующей ветке;

А вы точно работали с нашим ядром? Я регулярно переношу все наши
патчи на e2k ядро (кроме патчей для других архитектур). Для этого
используются ветка нужной версии из
git.alt:/people/kernelbot/packages/kernel-image.git

В общем-то, там все наши патчи легко видно по --first-parent;
cherry-pick работает, но не с merge коммитами, которых там хватает
из всяких небольших тематических веток вроде kernelbot/fix-strlcpy.
Вот с ними засада, приходится повторять merge коммиты, git rerere
облегчает работу, но его кеш локален нельзя запушить в то же
дерево, чтоб поделиться с другими или просто перетащить на другую
машину.

> - всегда иметь подготовленный набор патчей для текущего ядра.
> 
> Я бы ещё предложил делать два патча:
> - linux-x.y.0-x.y.z.patch
> - linux- x.y.z-alt.patch
> тогда патч в нашем SRCRPM-пакете ядра будет не столь бесполезен, чем сейчас.

Я бы вообще от них отказался (в общем, у меня так и сделано).
В гите же вся работа, вот из него и нужно собирать. Просто git
тяжёлый и хорошо бы сборочнице shallow clone делать, хотя бы по
запросу. Но это уже хотелка вне ядра.

Best regards,
Andrew Savchenko

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

Re: [devel] Новая схема ведения исходников ядра

[Evgeny Sinelnikov]

сб, 4 дек. 2021 г. в 03:45, Andrey Savchenko <bircoph@altlinux.org>:
>
> On Fri, 3 Dec 2021 23:41:56 +0400 Evgeny Sinelnikov wrote:
> > Суть: для того, чтобы вести не только поддержку сборки, но разработку
> > ядра, нацеленную на продвижение наших патчей в апстрим, предлагается
> > рассмотреть новую схему ведения исходников.
> >
> > - все наши патчи складываются "ребейзом" или "черипиком" поверх
> > последнего релиза, который заявлен в версии пакета
> > kernel-image-FLAVOUR:
> >  + https://github.com/altlinux/linux-arm/commits/altlinux-5.15.y
>
> cherry-pick не осилит merge коммиты (максимум, что можно от него
> получить, это всю ветку одним коммитом, с потерей истории). Ну
> а rebase — на любителя и не всегда годится, например, когда часть
> патчей нужно выбросить по тем или иным причинам.

Вопрос в том, что у нас нет сейчас возможности вести разработку ядра
на тех же исходниках, что и для сборки. Разработчикам же, так или
иначе, приходится проводить rebase или cherry-pick. Это не вопрос
предпочтений - это вопрос возможности вести разработку со сторонними
разработчиками, которым нужны наши исходники без множества
merge-коммитов. Взаимодействуя с ними, мы сами просим от них того же,
чтобы не искать по их исходникам нужные нам патчи, чтобы забрать себе.

>
> > - схема сборки остаётся прежней за следующими дополнениями:
> >  + ветка sisyphus содержит только gear-rules и spec (ну, пока и не
> > надо больше - вряд ли потребуется, хотя я бы предложил ещё README по
> > сборке);
> >  + исходники включают в себя только продуктивные патчи и ветка с ними
> > перед сборкой "мёрджится" с git merge -s ours;
> >  + для удобной работы над исходниками можно воспользоваться командой
> > git worktree, позволяющей получить отдельную ветку в соседнем каталоге
> > на одном и том же git-репозитории;
>
> Так себе удобство, честно скажу; я пользуюсь этим когда
> приходится, но именно как вынужденной мерой. Хотя бы потому, что
> в git крайне не рекомендуется конкурентно коммитить из двух разных
> worktree.

Опять. Это не вопрос удобства. Кому-то так даже удобнее, может быть.
Но тут важнее другое возможность увидеть исходники с теми патчами,
которые у нас есть, а не искать их кусками размазанными по истории
после очередного merge-коммита.

> >  + перед сборкой необходимо обновить commitid в .gear/tags/list
> > https://github.com/altlinux/linux-arm/commits/sisyphus-un-def
>
> Вот эта головная боль тоже нежелательна. Потому что при отладке
> где-нибудь на другой железке или в инсталляторе пакет приходится
> часто пересобирать. Да, скриптуется, но сборка и так сложна из-за
> specsubst и разных kflavour.

А разработка, в ином случае, вообще невозможна. Как взаимодействовать
с апстримом? Как взаимодействовать с теми, кто берёт апстримные
исходники? Ответ: "Пока никак". Вести две параллельных истории. Не
хотелось бы.

> > В целом, этот подход ничего не ломает, но очень много позволяет:
> > - чётко отслеживать пачти;
> > - всегда знать чем наше ядро отличается от апстримного не на уровне
> > одного большого "дифа", доступного только git в консоли, но и на
> > уровне полного списка патчей, доступного также через web-интерфейс в
> > соответствующей ветке;
>
> А вы точно работали с нашим ядром? Я регулярно переношу все наши
> патчи на e2k ядро (кроме патчей для других архитектур). Для этого
> используются ветка нужной версии из
> git.alt:/people/kernelbot/packages/kernel-image.git

Конечно, работали. Давайте посмотрим на ветку ядра, которую удалось получить:
https://github.com/altlinux/linux-arm/commits/altlinux-5.15.y

Где иначе и как ещё можно найти и увидеть полный список наших патчей
по-отдельности по сравнению с апстримом?

> В общем-то, там все наши патчи легко видно по --first-parent;

Давайте посмотрим как. Вот есть коллеги из компании разработчика
железа. Они хотя собрать ядро, как у нас, но они планируют апстримить
свои патчи. Куда из прикладывать с нашим ядром? В ветку, где куча
наших релизных коммитов? Зачем им это?

> cherry-pick работает, но не с merge коммитами, которых там хватает
> из всяких небольших тематических веток вроде kernelbot/fix-strlcpy.
> Вот с ними засада, приходится повторять merge коммиты, git rerere
> облегчает работу, но его кеш локален нельзя запушить в то же
> дерево, чтоб поделиться с другими или просто перетащить на другую
> машину.

Это ещё одна потенциальная проблема. Но и без этого хватает проблем.

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

> > - всегда иметь подготовленный набор патчей для текущего ядра.
> >
> > Я бы ещё предложил делать два патча:
> > - linux-x.y.0-x.y.z.patch
> > - linux- x.y.z-alt.patch
> > тогда патч в нашем SRCRPM-пакете ядра будет не столь бесполезен, чем сейчас.
>
> Я бы вообще от них отказался (в общем, у меня так и сделано).
> В гите же вся работа, вот из него и нужно собирать. Просто git
> тяжёлый и хорошо бы сборочнице shallow clone делать, хотя бы по
> запросу. Но это уже хотелка вне ядра.

Ну, может быть.


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Новая схема ведения исходников ядра

[Dmitry V. Levin]

On Mon, Dec 06, 2021 at 03:22:24AM +0400, Evgeny Sinelnikov wrote:
[...]
> Вопрос в том, что у нас нет сейчас возможности вести разработку ядра
> на тех же исходниках, что и для сборки. Разработчикам же, так или
> иначе, приходится проводить rebase или cherry-pick. Это не вопрос
> предпочтений - это вопрос возможности вести разработку со сторонними
> разработчиками, которым нужны наши исходники без множества
> merge-коммитов. Взаимодействуя с ними, мы сами просим от них того же,
> чтобы не искать по их исходникам нужные нам патчи, чтобы забрать себе.

Извините, но такое можно рассказывать людям, которые не в курсе, как
разрабатываются ядра.  Мантейнеры подсистем, как правило,  ребейзятся
не чаще, чем между версиями ядра 5.X и 5.X+1, да и Linus не делает
git merge -s ours.
Почему вы не хотите вести каждую ветку ваших изменений (feat-*, fix-*) и
мержить её в ядро?  Зачем вам ребейзить каждую ветку ваших изменений на
каждое обновление внутри одной ветки stable?  Почему вам недостаточно
ребейзить максимум при переходе с 5.X на 5.X+1?


-- 
ldv

Re: [devel] Новая схема ведения исходников ядра

[Andrey Savchenko]

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

On Mon, 6 Dec 2021 03:22:24 +0400 Evgeny Sinelnikov wrote:
> сб, 4 дек. 2021 г. в 03:45, Andrey Savchenko <bircoph@altlinux.org>:
> > On Fri, 3 Dec 2021 23:41:56 +0400 Evgeny Sinelnikov wrote:
> > >  + перед сборкой необходимо обновить commitid в .gear/tags/list
> > > https://github.com/altlinux/linux-arm/commits/sisyphus-un-def
> >
> > Вот эта головная боль тоже нежелательна. Потому что при отладке
> > где-нибудь на другой железке или в инсталляторе пакет приходится
> > часто пересобирать. Да, скриптуется, но сборка и так сложна из-за
> > specsubst и разных kflavour.
> 
> А разработка, в ином случае, вообще невозможна. Как взаимодействовать
> с апстримом? Как взаимодействовать с теми, кто берёт апстримные
> исходники? Ответ: "Пока никак". Вести две параллельных истории. Не
> хотелось бы.

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

> > > В целом, этот подход ничего не ломает, но очень много позволяет:
> > > - чётко отслеживать пачти;
> > > - всегда знать чем наше ядро отличается от апстримного не на уровне
> > > одного большого "дифа", доступного только git в консоли, но и на
> > > уровне полного списка патчей, доступного также через web-интерфейс в
> > > соответствующей ветке;
> >
> > А вы точно работали с нашим ядром? Я регулярно переношу все наши
> > патчи на e2k ядро (кроме патчей для других архитектур). Для этого
> > используются ветка нужной версии из
> > git.alt:/people/kernelbot/packages/kernel-image.git
> 
> Конечно, работали. Давайте посмотрим на ветку ядра, которую удалось получить:
> https://github.com/altlinux/linux-arm/commits/altlinux-5.15.y
> 
> Где иначе и как ещё можно найти и увидеть полный список наших патчей
> по-отдельности по сравнению с апстримом?

Ну например вот так:
$ git log --oneline --no-merges \
v5.4.163..kernel-image-std-def-5.4.163-alt1 -- \
. ':!/kernel-image.spec'

Правки конфига тут тоже будут (и обычно это важно), если не нужны,
то можно добавить ':!/config*'.

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

> > В общем-то, там все наши патчи легко видно по --first-parent;
> 
> Давайте посмотрим как. Вот есть коллеги из компании разработчика
> железа. Они хотя собрать ядро, как у нас, но они планируют апстримить
> свои патчи. Куда из прикладывать с нашим ядром? В ветку, где куча
> наших релизных коммитов? Зачем им это?

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

Best regards,
Andrew Savchenko

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

Re: [devel] Новая схема ведения исходников ядра

[Evgeny Sinelnikov]

пн, 6 дек. 2021 г. в 22:28, Andrey Savchenko <bircoph@altlinux.org>:
>
> On Mon, 6 Dec 2021 03:22:24 +0400 Evgeny Sinelnikov wrote:
> > сб, 4 дек. 2021 г. в 03:45, Andrey Savchenko <bircoph@altlinux.org>:
> > > On Fri, 3 Dec 2021 23:41:56 +0400 Evgeny Sinelnikov wrote:
> > > >  + перед сборкой необходимо обновить commitid в .gear/tags/list
> > > > https://github.com/altlinux/linux-arm/commits/sisyphus-un-def
> > >
> > > Вот эта головная боль тоже нежелательна. Потому что при отладке
> > > где-нибудь на другой железке или в инсталляторе пакет приходится
> > > часто пересобирать. Да, скриптуется, но сборка и так сложна из-за
> > > specsubst и разных kflavour.
> >
> > А разработка, в ином случае, вообще невозможна. Как взаимодействовать
> > с апстримом? Как взаимодействовать с теми, кто берёт апстримные
> > исходники? Ответ: "Пока никак". Вести две параллельных истории. Не
> > хотелось бы.
>
> Так держите своей веткой (или ветками) нужные патчи и применяйте их
> как к апстримному ядру, так и к нашим. Если патчи не зависят от
> остальных альтовых изменений, то накладывать будут на оба варианта
> без проблем, а если зависят, то придётся держать две версии — здесь
> как ни крути, но по другому не получится.

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

> > > > В целом, этот подход ничего не ломает, но очень много позволяет:
> > > > - чётко отслеживать пачти;
> > > > - всегда знать чем наше ядро отличается от апстримного не на уровне
> > > > одного большого "дифа", доступного только git в консоли, но и на
> > > > уровне полного списка патчей, доступного также через web-интерфейс в
> > > > соответствующей ветке;
> > >
> > > А вы точно работали с нашим ядром? Я регулярно переношу все наши
> > > патчи на e2k ядро (кроме патчей для других архитектур). Для этого
> > > используются ветка нужной версии из
> > > git.alt:/people/kernelbot/packages/kernel-image.git
> >
> > Конечно, работали. Давайте посмотрим на ветку ядра, которую удалось получить:
> > https://github.com/altlinux/linux-arm/commits/altlinux-5.15.y
> >
> > Где иначе и как ещё можно найти и увидеть полный список наших патчей
> > по-отдельности по сравнению с апстримом?
>
> Ну например вот так:
> $ git log --oneline --no-merges \
> v5.4.163..kernel-image-std-def-5.4.163-alt1 -- \
> . ':!/kernel-image.spec'
>
> Правки конфига тут тоже будут (и обычно это важно), если не нужны,
> то можно добавить ':!/config*'.
>
> Как показывает опыт, требование держать всю историю коммитов в git
> линейно в одной ветке обычно следует из недостаточности навыков
> работы с git.
>
> > > В общем-то, там все наши патчи легко видно по --first-parent;
> >
> > Давайте посмотрим как. Вот есть коллеги из компании разработчика
> > железа. Они хотя собрать ядро, как у нас, но они планируют апстримить
> > свои патчи. Куда из прикладывать с нашим ядром? В ветку, где куча
> > наших релизных коммитов? Зачем им это?
>
> Либо их патч не зависит от наших изменений и тогда без разницы куда
> прикладывать, либо зависит, и тогда им нужно будет два разных
> варианта держать: для ванильного ядра и для нашего. Метод ведения
> дерева git на это никак не влияет.
>
> Best regards,
> Andrew Savchenko
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Новая схема ведения исходников ядра

[Anton V. Boyarshinov]

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

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

> > Либо их патч не зависит от наших изменений и тогда без разницы куда
> > прикладывать, либо зависит, и тогда им нужно будет два разных
> > варианта держать: для ванильного ядра и для нашего. Метод ведения
> > дерева git на это никак не влияет.

Re: [devel] Новая схема ведения исходников ядра

[Alexey Sheplyakov]

Здравствуйте!

On 04.12.2021 03:44, Andrey Savchenko wrote:

>>  + для удобной работы над исходниками можно воспользоваться командой
>> git worktree, позволяющей получить отдельную ветку в соседнем каталоге
>> на одном и том же git-репозитории;
> 
> Так себе удобство, честно скажу; я пользуюсь этим когда
> приходится, но именно как вынужденной мерой. Хотя бы потому, что
> в git крайне не рекомендуется конкурентно коммитить из двух разных
> worktree.

А можно подробнее - где, кем не рекомендуется?
Прочитал man git-workspace - ничего такого не нашёл.
Каждый день так делаю (уже года 2 как минимум), по 100 раз в день (считая rebase/amend).
Конечно, может мне просто везёт.

>>  + перед сборкой необходимо обновить commitid в .gear/tags/list
>> https://github.com/altlinux/linux-arm/commits/sisyphus-un-def
> 
> Вот эта головная боль тоже нежелательна. Потому что при отладке
> где-нибудь на другой железке или в инсталляторе пакет приходится
> часто пересобирать. Да, скриптуется, но сборка и так сложна из-за
> specsubst и разных kflavour. 

При отладке на железке (особенно если эта железка не x86) сборка пакета
(с ядром) - это всегда "так себе удобство". Городить $ARCH chroot и
запускать компилятор в qemu-user - это ... (затрудняюсь сказать, оставаясь
в рамках приличий).

> А вы точно работали с нашим ядром? Я регулярно переношу все наши
> патчи на e2k ядро (кроме патчей для других архитектур).

Архитектурно независимых патчей у нас мало (AltHa, kiosk,
argv+env limit for AT_SECURE, root-only /proc/interrupts,
crippled user namespaces, modprobe -b by default), новые появляются редко.
Но и они периодически теряются.
Патчей для поддержки аппаратуры (процессоров, плат) больше, меняются они часто.

> Для этого используются ветка нужной версии из
> git.alt:/people/kernelbot/packages/kernel-image.git

А где мне взять ветку для 5.16-rc3 и linux-next?

Re: [devel] Новая схема ведения исходников ядра

[Andrey Savchenko]

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

On Mon, 6 Dec 2021 12:29:01 +0400 Alexey Sheplyakov wrote:
> Здравствуйте!
> 
> On 04.12.2021 03:44, Andrey Savchenko wrote:
> 
> >>  + для удобной работы над исходниками можно воспользоваться командой
> >> git worktree, позволяющей получить отдельную ветку в соседнем каталоге
> >> на одном и том же git-репозитории;
> > 
> > Так себе удобство, честно скажу; я пользуюсь этим когда
> > приходится, но именно как вынужденной мерой. Хотя бы потому, что
> > в git крайне не рекомендуется конкурентно коммитить из двух разных
> > worktree.
> 
> А можно подробнее - где, кем не рекомендуется?
> Прочитал man git-workspace - ничего такого не нашёл.

А где вы такой man нашли? Если man git-worktree, вот его и советую
почитать, хотя бы конец:

BUGS
	Multiple checkout in general is still experimental, and the
	support for submodules is incomplete. It is NOT recommended
	to make multiple checkouts of a superproject.

> Каждый день так делаю (уже года 2 как минимум), по 100 раз в день (считая rebase/amend).
> Конечно, может мне просто везёт.

Давайте уточню, во избежание недоразумения: вы делаете git commit
параллельно из разных worktree? Ну тогда я рад везучести ваших ног,
но не следует рекомендовать для критически важного компонента
системы рабочий процесс, который явно не рекомендуется апстримом. 

> >>  + перед сборкой необходимо обновить commitid в .gear/tags/list
> >> https://github.com/altlinux/linux-arm/commits/sisyphus-un-def
> > 
> > Вот эта головная боль тоже нежелательна. Потому что при отладке
> > где-нибудь на другой железке или в инсталляторе пакет приходится
> > часто пересобирать. Да, скриптуется, но сборка и так сложна из-за
> > specsubst и разных kflavour. 
> 
> При отладке на железке (особенно если эта железка не x86) сборка пакета
> (с ядром) - это всегда "так себе удобство". Городить $ARCH chroot и
> запускать компилятор в qemu-user - это ... (затрудняюсь сказать, оставаясь
> в рамках приличий).

Для моих задач qemu не нужен (да и нет его), просто собирается на
железке одной архитектуры, а запускается на другой. Кросс-сборка,
если так угодно.

> > Для этого используются ветка нужной версии из
> > git.alt:/people/kernelbot/packages/kernel-image.git
> 
> А где мне взять ветку для 5.16-rc3 и linux-next?

Подключить upstream remote и сделать git-checkout v5.16-rc3.

Best regards,
Andrew Savchenko

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

Re: [devel] Новая схема ведения исходников ядра

[Vladimir D. Seleznev]

On Mon, Dec 06, 2021 at 08:32:22PM +0300, Andrey Savchenko wrote:
> On Mon, 6 Dec 2021 12:29:01 +0400 Alexey Sheplyakov wrote:
> > Здравствуйте!
> > 
> > On 04.12.2021 03:44, Andrey Savchenko wrote:
> > 
> > >>  + для удобной работы над исходниками можно воспользоваться командой
> > >> git worktree, позволяющей получить отдельную ветку в соседнем каталоге
> > >> на одном и том же git-репозитории;
> > > 
> > > Так себе удобство, честно скажу; я пользуюсь этим когда
> > > приходится, но именно как вынужденной мерой. Хотя бы потому, что
> > > в git крайне не рекомендуется конкурентно коммитить из двух разных
> > > worktree.
> > 
> > А можно подробнее - где, кем не рекомендуется?
> > Прочитал man git-workspace - ничего такого не нашёл.
> 
> А где вы такой man нашли? Если man git-worktree, вот его и советую
> почитать, хотя бы конец:
> 
> BUGS
> 	Multiple checkout in general is still experimental, and the
> 	support for submodules is incomplete. It is NOT recommended
> 	to make multiple checkouts of a superproject.

Это относится только с проектам с сабмодулями, что не является случаем
любого gear-репозитория: там явно написано of a superproject, что
является термином для головного репозитория с субмодулями.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Новая схема ведения исходников ядра

[Anton V. Boyarshinov]

Добрый день

> В целом, этот подход ничего не ломает, но очень много позволяет:

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

> - чётко отслеживать пачти;
git log --author altlinux позволяет решить эту задачу относительно
удобно.

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

> - всегда знать чем наше ядро отличается от апстримного не на уровне
> одного большого "дифа", доступного только git в консоли, но и на
> уровне полного списка патчей, доступного также через web-интерфейс в
> соответствующей ветке;
> - всегда иметь подготовленный набор патчей для текущего ядра.
> 
> Я бы ещё предложил делать два патча:
> - linux-x.y.0-x.y.z.patch
> - linux- x.y.z-alt.patch
> тогда патч в нашем SRCRPM-пакете ядра будет не столь бесполезен, чем сейчас.
> 
> Такой подход позволит всегда знать какие патчи есть в нашем ядре, а
> также даст возможность передать наши ядра для совместной разработки
> коллегам из компаний, занимающихся разработкой аппаратных средств -
> процессоров и новых устройств.
> 
> Тестовая сборка упала из-за ограничений на подпись.
> #291228 FAILED #2 [test-only] sisyphus
> linux.git=kernel-image-un-def-5.15.6-alt2 [...]
> http://git.altlinux.org/tasks/291228/logs/events.2.1.log
> ...
>  - Verifying /boot/vmlinuz-5.15.6-un-def-alt2
>  Signature verification failed
>  = PESIGN verification failures 1, successes 0.
>  /usr/lib/rpm/check-pesign.filetrigger failed
>  error: posttrans filetriggers scriptlet failed, exit status 1
> ...
> То есть её можно пробовать.
> Это, по сути, та же сборка, что и alt1, но по новой схеме.
> 
> 

Re: [devel] Новая схема ведения исходников ядра

[Alexey Sheplyakov]

Здравствуйте!

On 06.12.2021 11:42, Anton V. Boyarshinov wrote:

>> В целом, этот подход ничего не ломает, но очень много позволяет:
> 
> Этот подход ломает историю git. Заскриптовать отмену проверки истории,
> конечно, несложно, но в результате работать с этой историей будет очень
> сложно.

Что именно сложного в

https://github.com/altlinux/linux-arm/commits/altlinux-5.15.y
https://github.com/altlinux/linux-arm/tree/sisyphus-un-def


> Ядро собирается гораздо чаще, чем в нём появляются или меняются наши
> патчи. 

Утверждение неверное. Патчи появляются/меняются довольно часто. Их в силу
целого ряда причин непросто протолкнуть в un-def, потому они появляются
(меняются) в других местах. Но это не значит, что их (патчей) нет.
А по мере добавления поддержки процессоров (MCom-03, например) и плат 
патчей будет ещё больше.

> Апстримные изменения, на мой взгляд, не настолько не важны,
> чтоб "топить" их в истории под нашими патчами.

Вопрос не в том, что важнее. А в том, что 

1) Почему-то время от времени часть патчей теряется.
   Например, недавно так потерялся патч на тему отключения user namespaces.
   Регулярно пропадают/искажаются патчи для поддержки BE-M1000.
   Это при том, что сейчас патчей сравнительно немного.

2) Надо взаимодействовать с партнёрами (Байкал Электроникс, ЭЛВИС, и прочие).
   Зачем им заниматься поисками наших патчей, размазанных по истории за N лет?

Re: [devel] Новая схема ведения исходников ядра

[Anton V. Boyarshinov]

В Mon, 6 Dec 2021 12:09:20 +0400
Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:

> Что именно сложного в
> 
> https://github.com/altlinux/linux-arm/commits/altlinux-5.15.y

А теперь представьте себе репозиторий в /gears который будет
возникать при сборке по предлагаемой вами схеме. Он будет выглядеть
совсем не так красиво (в нём будут ветки на каждую сборку).

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

Re: [devel] Новая схема ведения исходников ядра

[Alexey Sheplyakov]

On 06.12.2021 11:42, Anton V. Boyarshinov wrote:

>> В целом, этот подход ничего не ломает, но очень много позволяет:
> 
> Этот подход ломает историю git. Заскриптовать отмену проверки истории,
> конечно, несложно, но в результате работать с этой историей будет очень
> сложно.

Отменять проверку истории не нужно.
 
>> - чётко отслеживать пачти;
> git log --author altlinux позволяет решить эту задачу относительно
> удобно.

Неверно. 

1) В нашем 5.10 (ака std-def) есть "сторонние" патчи:

а) Поддержка графики для Intel Gen 11 (взято из master).
б) Поддержка GPU Midgard T6xx в драйвере panfrost (из edelweiss-tech/kernel)
в) Улучшения для panfrost (потянуто из master).

Это только то, что я сходу вспомнил. Со временем таких патчей будет (сильно) больше
(по мере улучшения поддержки процессоров/плат).

2) Ни разу не удобно.

Re: [devel] Новая схема ведения исходников ядра

[Anton V. Boyarshinov]

В Mon, 6 Dec 2021 14:26:51 +0400
Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:

> > Этот подход ломает историю git. Заскриптовать отмену проверки истории,
> > конечно, несложно, но в результате работать с этой историей будет очень
> > сложно.  
> 
> Отменять проверку истории не нужно.

Через git merge -s ours? На мой взгляд, то, что получится, можно
называть историей только очень условно.

Re: [devel] Новая схема ведения исходников ядра

[Evgeny Sinelnikov]

пн, 6 дек. 2021 г. в 14:31, Anton V. Boyarshinov <boyarsh@altlinux.org>:
>
> В Mon, 6 Dec 2021 14:26:51 +0400
> Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:
>
> > > Этот подход ломает историю git. Заскриптовать отмену проверки истории,
> > > конечно, несложно, но в результате работать с этой историей будет очень
> > > сложно.
> >
> > Отменять проверку истории не нужно.
>
> Через git merge -s ours? На мой взгляд, то, что получится, можно
> называть историей только очень условно.

Это не столь важно. Фактически так всегда видно будет реальную
апстримную ветку с набором наших патчей, каждый раз именно ту, которую
можно отдать. Это и для разработки полезно и для сборки всегда
понятно. Тут нужен внятный README и привязка к документации на
alltlinux.org, которую нужно будет обновить.

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



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Новая схема ведения исходников ядра

[Anton V. Boyarshinov]

> > > Отменять проверку истории не нужно.  
> >
> > Через git merge -s ours? На мой взгляд, то, что получится, можно
> > называть историей только очень условно.  
> 
> Это не столь важно.

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

> Фактически так всегда видно будет реальную
> апстримную ветку с набором наших патчей, каждый раз именно ту, которую
> можно отдать.
А кому-то нужно именно наше std-def ядро со всеми патчами для разработки
поверх него? Какая-то странная идея. Не говоря уж о том, что std-def
ядро это всегда longterm и, порой, не самый последний longterm, так что
рассматривать его как базу для разработки кажется мне не вполне
правильным.

Поскольку при разработке и поддержке дистрибутивного ядра workflow
существенно различается, я не вижу необходимости подгонять одно под
другое (в какую либо сторону). Благо не CVS какой используем, git
достаточно гибкий инструмент.

> Это и для разработки полезно и для сборки всегда
> понятно. Тут нужен внятный README и привязка к документации на
> alltlinux.org, которую нужно будет обновить.
> 
> С ядром мы именно эту историю и получаем. Каждый раз - новый срез с
> нашими старыми патчами. История именно это и будет тогда отражать. А в
> исходниках ядре не будет наших специфичных, сборочных файлов - только
> продуктивные.
> 
> 
> 

Re: [devel] Новая схема ведения исходников ядра

[Anton V. Boyarshinov]

В Mon, 6 Dec 2021 13:40:39 +0300
Aleksey Novodvorsky <aen@basealt.ru> пишет:

> > Через git merge -s ours? На мой взгляд, то, что получится, можно
> > называть историей только очень условно.
> >  
> 
> А есть ли предложения по решению?
> Вопросы, поставленные Алексеем по взаимодействию с партнёрами, важные.

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

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 13:25 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 13:35 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 13:41 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 13:48 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 13:51 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 13:57 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 14:04 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 14:08 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 14:40 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 14:54 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 15:02 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 15:26 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 15:53 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 22:58 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-07 7:47 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-07 16:54 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 13:47 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 13:54 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 10:53 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 11:27 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 11:41 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 12:12 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 12:30 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 14:53 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-23 3:28 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-23 6:07 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-03 5:07 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-03 5:33 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-10 8:53 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-11 8:01 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-11 8:12 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-11 8:55 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-11 9:10 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-11 9:33 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-11 9:37 UTC (permalink / raw)]

[devel] PoC: gear-submodule-update Ex: Новая схема ведения исходников ядра

[@ 2022-01-12 0:26 UTC (permalink / raw)]

Re: [devel] PoC: gear-submodule-update Ex: Новая схема ведения исходников ядра

[@ 2022-01-12 0:39 UTC (permalink / raw)]

Re: [devel] PoC: gear-submodule-update Ex: Новая схема ведения исходников ядра

[@ 2022-01-12 12:20 UTC (permalink / raw)]

Re: [devel] PoC: gear-submodule-update Ex: Новая схема ведения исходников ядра

[@ 2022-01-12 12:40 UTC (permalink / raw)]

Re: [devel] PoC: gear-submodule-update Ex: Новая схема ведения исходников ядра

[@ 2022-01-12 12:53 UTC (permalink / raw)]

Re: [devel] PoC: gear-submodule-update Ex: Новая схема ведения исходников ядра

[@ 2022-01-12 13:10 UTC (permalink / raw)]

Re: [devel] PoC: gear-submodule-update Ex: Новая схема ведения исходников ядра

[@ 2022-01-12 13:26 UTC (permalink / raw)]

Re: [devel] gear-store-submodules

[@ 2022-01-12 16:59 UTC (permalink / raw)]

Re: [devel] gear-store-submodules

[@ 2022-01-12 19:14 UTC (permalink / raw)]

Re: [devel] gear-store-submodules

[@ 2022-01-12 20:06 UTC (permalink / raw)]

Re: [devel] gear-store-submodules

[@ 2022-01-12 21:14 UTC (permalink / raw)]

Re: [devel] PoC: gear-submodule-update Ex: Новая схема ведения исходников ядра

[@ 2022-01-12 1:04 UTC (permalink / raw)]

Re: [devel] PoC: gear-submodule-update Ex: Новая схема ведения исходников ядра

[@ 2022-01-12 6:01 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-11 10:30 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-11 12:18 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-19 9:53 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-19 9:56 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-19 10:15 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-19 10:24 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-19 10:58 UTC (permalink / raw)]

[devel] Автодекларация патчей в спеках (Was: Новая схема ведения исходников ядра)

[@ 2022-01-19 10:31 UTC (permalink / raw)]

Re: [devel] Автодекларация патчей в спеках (Was: Новая схема ведения исходников ядра)

[@ 2022-01-19 10:32 UTC (permalink / raw)]

Re: [devel] Автодекларация патчей в спеках (Was: Новая схема ведения исходников ядра)

[@ 2022-01-19 10:48 UTC (permalink / raw)]

Re: [devel] Автодекларация патчей в спеках (Was: Новая схема ведения исходников ядра)

[@ 2022-01-19 11:10 UTC (permalink / raw)]

Re: [devel] Автодекларация патчей в спеках (Was: Новая схема ведения исходников ядра)

[@ 2022-01-19 10:57 UTC (permalink / raw)]

Re: [devel] Автодекларация патчей в спеках (Was: Новая схема ведения исходников ядра)

[@ 2022-01-19 11:09 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-19 10:52 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-03 6:17 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2022-01-03 6:25 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 11:54 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 12:35 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 13:29 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 13:48 UTC (permalink / raw)]

[devel] Отделяя котлеты от мух (было Re: Новая схема ведения исходников ядра)

[@ 2021-12-08 8:07 UTC (permalink / raw)]

Re: [devel] Отделяя котлеты от мух (было Re: Новая схема ведения исходников ядра)

[@ 2021-12-08 8:54 UTC (permalink / raw)]

Re: [devel] Отделяя котлеты от мух (было Re: Новая схема ведения исходников ядра)

[@ 2021-12-08 10:32 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 14:31 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-06 14:55 UTC (permalink / raw)]

Re: [devel] Новая схема ведения исходников ядра

[@ 2021-12-23 3:14 UTC (permalink / raw)]