[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] Новая схема ведения исходников ядра

[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] Новая схема ведения исходников ядра

[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] Новая схема ведения исходников ядра

[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 12:09:20 +0400
Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:

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

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

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

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 log --author altlinux позволяет решить эту задачу относительно
> > удобно.  
> 
> Неверно. 

Тогда git log --no-merges std-def-5.10 ^remotes/stable/linux-5.10.y

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

Не факт. Часть этих патчей будет уходить с переходом на 5.15 и далее по
лонгтермам.

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

[Anton V. Boyarshinov]

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

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

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

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

[Anton V. Boyarshinov]

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

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

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

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

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

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

[Alexey Sheplyakov]

On 06.12.2021 14:53, Anton V. Boyarshinov wrote:

>>>> - чётко отслеживать пачти;  
>>> git log --author altlinux позволяет решить эту задачу относительно
>>> удобно.  
>>
>> Неверно. 
> 
> Тогда git log --no-merges std-def-5.10 ^remotes/stable/linux-5.10.y

Нет.

1) Потому что в merge коммитах разрешены конфликты, что очень существенно.

2) Некий логически монолитный кусок кода (например, LSM модуль AltHa, или 
   драйвер dwmac-baikal) оказывается размазанным тонким слоем по N коммитам.
   При переносе на более свежее ядро из этих N коммитов всё равно надо сделать
   один патч (а затем доработать его вслед за изменившимися API).
   Например, путём rebase к последнему -next. Вы же сами так и делаете с AltHa.
   Так почему бы и не хранить патчи в таком виде?

И по мелочи:

3) Будет показано всё, что сначала появилось у нас, а потом - в stable.
4) Тьма неинтересных коммитов "1:5.10.NN-alt1"

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

[Anton V. Boyarshinov]

В Mon, 6 Dec 2021 15:27:11 +0400
Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:

> 2) Некий логически монолитный кусок кода (например, LSM модуль AltHa, или 
>    драйвер dwmac-baikal) оказывается размазанным тонким слоем по N коммитам.
>    При переносе на более свежее ядро из этих N коммитов всё равно надо сделать
>    один патч (а затем доработать его вслед за изменившимися API).

Да, эти "стабильные" патчи живут в отдельных ветках feat-* и fix-*

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

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

[Alexey Sheplyakov]

On 06.12.2021 14:53, Anton V. Boyarshinov wrote:

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

Факт. Новые устройства пока что появляются гораздо быстрее, чем их поддержка в mainline ядре.

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

[Anton Farygin]

On 06.12.2021 14:41, Anton V. Boyarshinov wrote:
> В Mon, 6 Dec 2021 15:27:11 +0400
> Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:
>
>> 2) Некий логически монолитный кусок кода (например, LSM модуль AltHa, или
>>     драйвер dwmac-baikal) оказывается размазанным тонким слоем по N коммитам.
>>     При переносе на более свежее ядро из этих N коммитов всё равно надо сделать
>>     один патч (а затем доработать его вслед за изменившимися API).
> Да, эти "стабильные" патчи живут в отдельных ветках feat-* и fix-*
>
> И, если я правильно понимаю, упоминаемым партнёрам они не очень
> интересны. Зачем их при каждой сборке вытаскивать наверх ценой
> испорченной истории мне не ясно.

Если мне гит при каждом merge ядра будет ругаться на unrelated history, 
то я буду громко и сильно ругаться на тех людей, которые так делают.

Давайте ещё раз подумаем и придумаем удобное решение.

А как ведёт ядро та же убунта ? Почему у них нет этой проблемы ?
https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-oem/+git/focal?h=oem-5.10

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

[Alexey Sheplyakov]

Добрый день!

On 06.12.2021 16:12, Anton Farygin wrote:
 
> Если мне гит при каждом merge ядра будет ругаться на unrelated history, то я буду громко и сильно ругаться на тех людей, которые так делают.

Stephen Rothwell <sfr@canb.auug.org.au>
Ругайтесь, сколько влезет.

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

[Dmitry V. Levin]

On Fri, Dec 03, 2021 at 11:41:56PM +0400, Evgeny Sinelnikov wrote:
> Доброй ночи,
> 
> хочу сообщить, что 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, но по новой схеме.

Я не понял, вы что, предлагаете внутри одной ветки ядра 5.15 делать rebase
для каждого обновления из апстримного 5.15?


-- 
ldv

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

[Dmitry V. Levin]

On Mon, Dec 06, 2021 at 01:40:39PM +0300, Aleksey Novodvorsky wrote:
[...]
> Вопросы, поставленные Алексеем по взаимодействию с партнёрами, важные.

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


-- 
ldv

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

[Evgeny Sinelnikov]

пн, 6 дек. 2021 г. в 16:35, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Fri, Dec 03, 2021 at 11:41:56PM +0400, Evgeny Sinelnikov wrote:
> > Доброй ночи,
> >
> > хочу сообщить, что 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, но по новой схеме.
>
> Я не понял, вы что, предлагаете внутри одной ветки ядра 5.15 делать rebase
> для каждого обновления из апстримного 5.15?

В целом, да. Так и есть.

Даже если они разбросаны по отдельным веткам -fix и -feat, их всё
равно время от времени нужно ребейзить. Если код сильно не менялся, то
он и ребейзится просто и мерджится просто. Если менялся сильнее, чем
этого хочется, то мы получаем от "мерджа" немного больше удобства,
которое картины, по сути не меняет.

Если делать не "ребейз", а "мердж", то хотелось бы понять:
- как с этим работать сторонним разработчикам, от какого ядра отталкиваться?
- какой подход к разработке ядра мы предлагаем другим участникам процесса?
- где и как можно найти исходники нашего ядра только с продуктивными патчами?
- готовы ли вы выковыривать патчи размазанные мердж-коммитами в ветках
других участников разработки?

В последнем я уверен, что ответ - нет.

Сценарий "внутри одной ветки ядра 5.15 делать rebase для каждого
обновления из апстримного 5.15" - это понятный вариант. Другие требуют
пояснений относительно текущего подхода.



-- 
Sin (Sinelnikov Evgeny)

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

[Evgeny Sinelnikov]

пн, 6 дек. 2021 г. в 17:25, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Mon, Dec 06, 2021 at 01:40:39PM +0300, Aleksey Novodvorsky wrote:
> [...]
> > Вопросы, поставленные Алексеем по взаимодействию с партнёрами, важные.
>
> Что касается взаимодействия с партнёрами, то я бы предложил для начала
> продать им курс обучения использования git.

Хорошо, давайте начнём с себя. я вовсе не уверен, что это будет бесполезно.

Я серьёзно, мы готовы сделать такой курс на русском?

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


-- 
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] Новая схема ведения исходников ядра

[Anton V. Boyarshinov]

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

Я пока не увидел необходимости получать ядро со всем нашими патчами,
только со всеми патчами специфичными для одной-двух платформ.

> - Как получить ядро в таком виде, как мы его получаем от апстрима для
> наших партнеров?

Мы получаем от апстрима вполне очевидные релизные тэги, я не вижу тут
вопроса.

> - Как его предоставить в таком виде, чтобы и нам, и им вместе было
> удобно передавать друг другу патчи?

Проблема в том, что в "нам" тут смешаны 2 совершенно различные
сущности: платформо-специфичная разработка и поддержка дистрибутивных
ядер. Для меня совершенно неочевидно, что у этих сущностей должно быть
одно workflow.

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

[Dmitry V. Levin]

On Mon, Dec 06, 2021 at 05:35:01PM +0400, Evgeny Sinelnikov wrote:
> пн, 6 дек. 2021 г. в 17:25, Dmitry V. Levin <ldv@altlinux.org>:
> > On Mon, Dec 06, 2021 at 01:40:39PM +0300, Aleksey Novodvorsky wrote:
> > [...]
> > > Вопросы, поставленные Алексеем по взаимодействию с партнёрами, важные.
> >
> > Что касается взаимодействия с партнёрами, то я бы предложил для начала
> > продать им курс обучения использования git.
> 
> Хорошо, давайте начнём с себя. я вовсе не уверен, что это будет бесполезно.
> 
> Я серьёзно, мы готовы сделать такой курс на русском?

На русском, конечно, сложнее - придётся как-то переводить git merge
и git rebase.

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

Я не понимаю такой постановки задачи.  В тот бранч, из которого собираются
ядра, должны быть смержены все бранчи с "продуктивными патчами".  Кому-то
мешают коммиты, которые меняют спек-файлы?  У Линуса есть аналогичные
коммиты, которые меняют только EXTRAVERSION в Makefile.

> - Как получить ядро в таком виде, как мы его получаем от апстрима для
> наших партнеров?

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

> - Как его предоставить в таком виде, чтобы и нам, и им вместе было
> удобно передавать друг другу патчи?

Удобство workflow субъективно.  Одни отправляют патчи по почте, другие
открывают PR в браузере, кто-то отправляет PR по почте, есть много
вариантов, как вы договоритесь, так и будет.


-- 
ldv

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

[Evgeny Sinelnikov]

пн, 6 дек. 2021 г. в 17:41, Anton V. Boyarshinov <boyarsh@altlinux.org>:
>
>
> > Но это не отменяет технических деталей:
> > - Как получить исходники нашего текущего, актуального ядра без наших
> > релизных коммитов? Только с продуктивными патчами.
>
> Я пока не увидел необходимости получать ядро со всем нашими патчами,
> только со всеми патчами специфичными для одной-двух платформ.
>
> > - Как получить ядро в таком виде, как мы его получаем от апстрима для
> > наших партнеров?
>
> Мы получаем от апстрима вполне очевидные релизные тэги, я не вижу тут
> вопроса.

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

> > - Как его предоставить в таком виде, чтобы и нам, и им вместе было
> > удобно передавать друг другу патчи?
>
> Проблема в том, что в "нам" тут смешаны 2 совершенно различные
> сущности: платформо-специфичная разработка и поддержка дистрибутивных
> ядер. Для меня совершенно неочевидно, что у этих сущностей должно быть
> одно workflow.

Вот это самый верный момент. Этот workflow и не должен быть одним и тем же.

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


-- 
Sin (Sinelnikov Evgeny)

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

[Anton V. Boyarshinov]

В Mon, 6 Dec 2021 17:29:06 +0400
Evgeny Sinelnikov <sin@altlinux.org> пишет:

> - как с этим работать сторонним разработчикам, от какого ядра отталкиваться?

В первую очередь -- от mainline linux kernel. Разработка на базе старых
longterm веток, да ещё и дистрибутивоспецифичных это тупик.

В данном случае, есть ещё один апстрим: asheplyakov@. Он является
апстримом для меня и точно также может являться им для этих неуказанных
партнёров. 

> - какой подход к разработке ядра мы предлагаем другим участникам процесса?
Это сильно зависит от того, что это за участники процесса, что им надо
и далее везде.

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

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

[Anton V. Boyarshinov]

В Mon, 6 Dec 2021 17:48:01 +0400
Evgeny Sinelnikov <sin@altlinux.org> пишет:

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

Пакеты в дистрибутиве не ориентированы на то, чтобы быть апстримом для
 кого бы то ни было. Насколько я могу судить, это утверждение относится ко всем пакетам и всем дистрибутивам GNU/Linux.

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

[Evgeny Sinelnikov]

пн, 6 дек. 2021 г. в 17:47, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Mon, Dec 06, 2021 at 05:35:01PM +0400, Evgeny Sinelnikov wrote:
> > пн, 6 дек. 2021 г. в 17:25, Dmitry V. Levin <ldv@altlinux.org>:
> > > On Mon, Dec 06, 2021 at 01:40:39PM +0300, Aleksey Novodvorsky wrote:
> > > [...]
> > > > Вопросы, поставленные Алексеем по взаимодействию с партнёрами, важные.
> > >
> > > Что касается взаимодействия с партнёрами, то я бы предложил для начала
> > > продать им курс обучения использования git.
> >
> > Хорошо, давайте начнём с себя. я вовсе не уверен, что это будет бесполезно.
> >
> > Я серьёзно, мы готовы сделать такой курс на русском?
>
> На русском, конечно, сложнее - придётся как-то переводить git merge
> и git rebase.
>
> > Но это не отменяет технических деталей:
> > - Как получить исходники нашего текущего, актуального ядра без наших
> > релизных коммитов? Только с продуктивными патчами.
>
> Я не понимаю такой постановки задачи.  В тот бранч, из которого собираются
> ядра, должны быть смержены все бранчи с "продуктивными патчами".  Кому-то
> мешают коммиты, которые меняют спек-файлы?  У Линуса есть аналогичные
> коммиты, которые меняют только EXTRAVERSION в Makefile.
>
> > - Как получить ядро в таком виде, как мы его получаем от апстрима для
> > наших партнеров?
>
> Мы же публикуем наши ядра, их можно получить.  Или я не понял вопрос.
>
> > - Как его предоставить в таком виде, чтобы и нам, и им вместе было
> > удобно передавать друг другу патчи?
>
> Удобство workflow субъективно.  Одни отправляют патчи по почте, другие
> открывают PR в браузере, кто-то отправляет PR по почте, есть много
> вариантов, как вы договоритесь, так и будет.

PR по почте для какого релиза нашего ядра? Для последнего?

Я вот не понимаю как с кем-то можно при таком подходе хоть о чём-то
договориться. Вот с ребейзом понятно. А тут тогда вопрос: "Как
предлагается вести разработку?"

Задачу тут поставить нужно точнее. Ну, раз переписка идёт в таком
оживлённом режиме, то это уже сложнее. Мне казалось это очевидным из
контекста. Пожалуй напишу подробнее все сценарии тогда. Но чуть позже.



-- 
Sin (Sinelnikov Evgeny)

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

[Dmitry V. Levin]

On Mon, Dec 06, 2021 at 04:51:20PM +0300, Anton V. Boyarshinov wrote:
> В Mon, 6 Dec 2021 17:48:01 +0400, Evgeny Sinelnikov пишет:
> 
> > > Мы получаем от апстрима вполне очевидные релизные тэги, я не вижу тут
> > > вопроса.  
> > 
> > А я вижу. Мы либо похожи на апстрим,либо сами апстрим. Но наши
> > релизные ядра даже не ориентированы на то, чтобы быть апстримом для
> > кого бы то ни было.
> 
> Пакеты в дистрибутиве не ориентированы на то, чтобы быть апстримом для
>  кого бы то ни было. Насколько я могу судить, это утверждение относится ко всем пакетам и всем дистрибутивам GNU/Linux.

Мне известно ровно одно исключение: libutempter.


-- 
ldv

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

[Evgeny Sinelnikov]

пн, 6 дек. 2021 г. в 17:51, Anton V. Boyarshinov <boyarsh@altlinux.org>:
>
> В Mon, 6 Dec 2021 17:48:01 +0400
> Evgeny Sinelnikov <sin@altlinux.org> пишет:
>
> > > Мы получаем от апстрима вполне очевидные релизные тэги, я не вижу тут
> > > вопроса.
> >
> > А я вижу. Мы либо похожи на апстрим,либо сами апстрим. Но наши
> > релизные ядра даже не ориентированы на то, чтобы быть апстримом для
> > кого бы то ни было.
>
> Пакеты в дистрибутиве не ориентированы на то, чтобы быть апстримом для
>  кого бы то ни было. Насколько я могу судить, это утверждение относится ко всем пакетам и всем дистрибутивам GNU/Linux.

Супер! Вот именно. Да. Но... ядро сейчас мы ведём совместно с разными
разработчиками и вот эту коллизию я и предлагаю разрешить.

Всё правильно. Поскольку "пакеты в дистрибутиве не ориентированы на
то, чтобы быть апстримом для  кого бы то ни было", заметьте, не я это
сказал. Но это, как раз, и очевидно из контекста. Поэтому совершенно
не важно какая история получится после git rebase -s ours. Она, всё
равно, никому кроме нас не нужна.

Да, мы не можем вести исходники, как апстрим, и как дистрибутивеные
одновременно без специальных усилий.

Разработка нового железа с нами и под нас, если мы хотим этого
предполагает определённый компромисс с обеих сторон. Если мы на него
не идём, то под нас сложнее разрабатывать. И, в дальнейшем,
рассчитывать на поддержку со стороны разработчиков железа. Это же тоже
должно быть очевидно. Или нет?


-- 
Sin (Sinelnikov Evgeny)

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

[Dmitry V. Levin]

On Mon, Dec 06, 2021 at 06:04:06PM +0400, Evgeny Sinelnikov wrote:
> пн, 6 дек. 2021 г. в 17:51, Anton V. Boyarshinov <boyarsh@altlinux.org>:
> >
> > В Mon, 6 Dec 2021 17:48:01 +0400
> > Evgeny Sinelnikov <sin@altlinux.org> пишет:
> >
> > > > Мы получаем от апстрима вполне очевидные релизные тэги, я не вижу тут
> > > > вопроса.
> > >
> > > А я вижу. Мы либо похожи на апстрим,либо сами апстрим. Но наши
> > > релизные ядра даже не ориентированы на то, чтобы быть апстримом для
> > > кого бы то ни было.
> >
> > Пакеты в дистрибутиве не ориентированы на то, чтобы быть апстримом для
> >  кого бы то ни было. Насколько я могу судить, это утверждение относится ко всем пакетам и всем дистрибутивам GNU/Linux.
> 
> Супер! Вот именно. Да. Но... ядро сейчас мы ведём совместно с разными
> разработчиками и вот эту коллизию я и предлагаю разрешить.
> 
> Всё правильно. Поскольку "пакеты в дистрибутиве не ориентированы на
> то, чтобы быть апстримом для  кого бы то ни было", заметьте, не я это
> сказал. Но это, как раз, и очевидно из контекста. Поэтому совершенно
> не важно какая история получится после git rebase -s ours. Она, всё
> равно, никому кроме нас не нужна.
> 
> Да, мы не можем вести исходники, как апстрим, и как дистрибутивеные
> одновременно без специальных усилий.
> 
> Разработка нового железа с нами и под нас, если мы хотим этого
> предполагает определённый компромисс с обеих сторон. Если мы на него
> не идём, то под нас сложнее разрабатывать. И, в дальнейшем,
> рассчитывать на поддержку со стороны разработчиков железа. Это же тоже
> должно быть очевидно. Или нет?

Нет, ни капли не очевидно.


-- 
ldv

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

[Dmitry V. Levin]

On Mon, Dec 06, 2021 at 05:29:06PM +0400, Evgeny Sinelnikov wrote:
> пн, 6 дек. 2021 г. в 16:35, Dmitry V. Levin <ldv@altlinux.org>:
[...]
> > Я не понял, вы что, предлагаете внутри одной ветки ядра 5.15 делать rebase
> > для каждого обновления из апстримного 5.15?
> 
> В целом, да. Так и есть.
> 
> Даже если они разбросаны по отдельным веткам -fix и -feat, их всё
> равно время от времени нужно ребейзить.

Зачем?  Просто потому что можем?
Почти все -fix и -feat в пределах одной ветки ядра не нуждаются в изменении.

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

Что значит "отталкиваться"?  Есть наше ядро, в котором написано, на каком
апстримном ядре оно основано и какие дополнительные ветки туда смержены.
Что ещё им надо знать?

> - какой подход к разработке ядра мы предлагаем другим участникам процесса?

А чем занимаются другие участники процесса?

> - где и как можно найти исходники нашего ядра только с продуктивными патчами?

Изменения в spec-файле по определению никому не мешают.

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

А зачем?

Мне кажется, тут есть какая-то недосказанность, которая рождает непонимание.


-- 
ldv

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

[Anton V. Boyarshinov]

В Mon, 6 Dec 2021 18:04:06 +0400
Evgeny Sinelnikov <sin@altlinux.org> пишет:

>  Поэтому совершенно
> не важно какая история получится после git rebase -s ours. Она, всё
> равно, никому кроме нас не нужна.

Только вот она нужна НАМ.

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

[Anton Farygin]

On 06.12.2021 15:30, Alexey Sheplyakov wrote:
> Добрый день!
>
> On 06.12.2021 16:12, Anton Farygin wrote:
>   
>> Если мне гит при каждом merge ядра будет ругаться на unrelated history, то я буду громко и сильно ругаться на тех людей, которые так делают.
> Stephen Rothwell <sfr@canb.auug.org.au>
> Ругайтесь, сколько влезет.
>
У меня ещё не было прецендентов с нашим ядром. Зачем мне ругаться на 
Stephen Rothwell ?

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

[Anton V. Boyarshinov]

В Mon, 6 Dec 2021 18:04:06 +0400
Evgeny Sinelnikov <sin@altlinux.org> пишет:

> Да, мы не можем вести исходники, как апстрим, и как дистрибутивеные
> одновременно без специальных усилий.

На мой взгляд, эти специальные услилия должны состоять в то, что должен
быть upstream каждой alt-специфичной части ядра. А в пакет с ядром
должны вливаться эти изменения.

А использование пакетов в качестве upstream... У нас сейчас
поддерживаются 3 разных ветки ядра 5.10 в разных репозиториях. У них
как минимум разные конфигурации (и это правильно) и местами разные
исходники (и это тоже правильно по крайней мере в части случаев). Какое
из этих ядер считать "апстримом"? Мой ответ -- никакое.

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

[Anton Farygin]

On 06.12.2021 17:31, Dmitry V. Levin wrote:
>> - готовы ли вы выковыривать патчи размазанные мердж-коммитами в ветках
>> других участников разработки?
> А зачем?

А какие с этим проблемы ? Я точно знаю что можно, при очень большом 
желании, конвертнуть одну схему в другую не очень сложным скриптом.

Вопрос А зачем ? - очень правильный.

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

[Dmitry V. Levin]

On Mon, Dec 06, 2021 at 05:54:49PM +0300, Anton V. Boyarshinov wrote:
> В Mon, 6 Dec 2021 18:04:06 +0400
> Evgeny Sinelnikov <sin@altlinux.org> пишет:
> 
> > Да, мы не можем вести исходники, как апстрим, и как дистрибутивеные
> > одновременно без специальных усилий.
> 
> На мой взгляд, эти специальные услилия должны состоять в то, что должен
> быть upstream каждой alt-специфичной части ядра. А в пакет с ядром
> должны вливаться эти изменения.

Да, конечно.  А разве это сейчас не так?


-- 
ldv

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

[Anton V. Boyarshinov]

В Mon, 6 Dec 2021 18:02:15 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> > > Да, мы не можем вести исходники, как апстрим, и как дистрибутивеные
> > > одновременно без специальных усилий.  
> > 
> > На мой взгляд, эти специальные услилия должны состоять в то, что должен
> > быть upstream каждой alt-специфичной части ядра. А в пакет с ядром
> > должны вливаться эти изменения.  
> 
> Да, конечно.  А разве это сейчас не так?

На мой взгляд, это именно так

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

[Dmitry V. Levin]

On Mon, Dec 06, 2021 at 06:26:08PM +0300, Anton V. Boyarshinov wrote:
> В Mon, 6 Dec 2021 18:02:15 +0300, Dmitry V. Levin пишет:
> 
> > > > Да, мы не можем вести исходники, как апстрим, и как дистрибутивеные
> > > > одновременно без специальных усилий.  
> > > 
> > > На мой взгляд, эти специальные услилия должны состоять в то, что должен
> > > быть upstream каждой alt-специфичной части ядра. А в пакет с ядром
> > > должны вливаться эти изменения.  
> > 
> > Да, конечно.  А разве это сейчас не так?
> 
> На мой взгляд, это именно так

Тогда в чём, собственно, проблема?


-- 
ldv

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] Новая схема ведения исходников ядра

[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] Новая схема ведения исходников ядра

[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] Новая схема ведения исходников ядра

[Evgeny Sinelnikov]

пн, 6 дек. 2021 г. в 19:53, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Mon, Dec 06, 2021 at 06:26:08PM +0300, Anton V. Boyarshinov wrote:
> > В Mon, 6 Dec 2021 18:02:15 +0300, Dmitry V. Levin пишет:
> >
> > > > > Да, мы не можем вести исходники, как апстрим, и как дистрибутивеные
> > > > > одновременно без специальных усилий.
> > > >
> > > > На мой взгляд, эти специальные услилия должны состоять в то, что должен
> > > > быть upstream каждой alt-специфичной части ядра. А в пакет с ядром
> > > > должны вливаться эти изменения.
> > >
> > > Да, конечно.  А разве это сейчас не так?
> >
> > На мой взгляд, это именно так
>
> Тогда в чём, собственно, проблема?

Проблема в том, как минимум, что это не документировано и неочевидно.

Если у нас есть upstream каждой alt-специфичной части ядра, то как его найти?
А если merge-commit'ы размазаны по репозиторию после первого merge с
минорным релизом, то как их потом искать?
Может быть тогда сделать соответствующие gear-rules с этими merge-commit'ами?
Как отслеживать какие fix'ы и features, которые приложены?

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




--
Sin (Sinelnikov Evgeny)

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] Новая схема ведения исходников ядра

[Anton V. Boyarshinov]

В Tue, 7 Dec 2021 02:58:42 +0400
Evgeny Sinelnikov <sin@altlinux.org> пишет:

> пн, 6 дек. 2021 г. в 19:53, Dmitry V. Levin <ldv@altlinux.org>:
> >
> > On Mon, Dec 06, 2021 at 06:26:08PM +0300, Anton V. Boyarshinov wrote:  
> > > В Mon, 6 Dec 2021 18:02:15 +0300, Dmitry V. Levin пишет:
> > >  
> > > > > > Да, мы не можем вести исходники, как апстрим, и как дистрибутивеные
> > > > > > одновременно без специальных усилий.  
> > > > >
> > > > > На мой взгляд, эти специальные услилия должны состоять в то, что должен
> > > > > быть upstream каждой alt-специфичной части ядра. А в пакет с ядром
> > > > > должны вливаться эти изменения.  
> > > >
> > > > Да, конечно.  А разве это сейчас не так?  
> > >
> > > На мой взгляд, это именно так  
> >
> > Тогда в чём, собственно, проблема?  
> 
> Проблема в том, как минимум, что это не документировано и неочевидно.

Я пока так и не понял зачем разработчикам железа все наши feat- и fix-
если им надо взаимодействовать с одной единственной веткой --
железно-специфичной.

> 
> Если у нас есть upstream каждой alt-специфичной части ядра, то как его найти?
> Может быть тогда сделать соответствующие gear-rules с этими merge-commit'ами?
Кому надо? Зачем надо?


> Как отслеживать какие fix'ы и features, которые приложены?

git log --merges --grep=fix- --grep=feat- --author=altlinux

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

Проблема в том, что дистрибутивное ядро рассматривается как upstream. А
это не так.

> - это работа была взаимно удобна;
> - позволяла в таком режиме вести разработку, чтобы схема сборки была прозрачна;
> - позволяла при накатывании патчей сторонними разработчиками (в том
> числе и нам самим в какой-то момент времени) не сталкиваться с
> неопределенностью о том, поверх какого когда наиболее близкого к
> нашему ядру стоит вести разработку;
> - не отворачивала от нас разработчиков за счёт степени компетенции в
> git, которую мы сами от себя почему-то не требуем для сборки
> собственных ядер, и делаем как нам удобно.
> 
> 
> 
> 
> --
> Sin (Sinelnikov Evgeny)
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Andrey Savchenko]

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

On Tue, 7 Dec 2021 02:58:42 +0400 Evgeny Sinelnikov wrote:
> - не отворачивала от нас разработчиков за счёт степени компетенции в
> git, которую мы сами от себя почему-то не требуем для сборки
> собственных ядер, и делаем как нам удобно.

А в чём проблема с git? Ну сделайте вы на вики страничку с FAQ как
сделать те или иные вещи, которые сложны для наших партнёров. На
все практические вопросы «а как сделать то-то в git» в рамках
данного обсуждения уже ответили конкретными командами.

Best regards,
Andrew Savchenko

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

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

[Alexey Sheplyakov]

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

On 06.12.2021 17:48, Anton V. Boyarshinov wrote:

>> - как с этим работать сторонним разработчикам, от какого ядра отталкиваться?
> 
> В первую очередь -- от mainline linux kernel. Разработка на базе старых
> longterm веток, да ещё и дистрибутивоспецифичных это тупик.

Ответ неправильный и бесполезный по нескольким причинам.

1) Разрабатывать поддержку СнК/платы на основе mainline невозможно.
   Потому что столько граблей не выдержит ни один лоб.
   Даже те (немногие) производители устройств, кто шлёт код в mainline,
   сначала "поднимают железо" на LTS, а потом уж портируют на более свежие ветки.
   (Поэтому Ваш ответ бесполезный)

2) Если цель - добавить поддержку аппаратуры в mainline, то надо глядеть в MAINTANERS,
   там написано - какой репозиторий/ветку брать за основу, и куда слать патчи.
   Как правило это не mainline. (Поэтому Ваш ответ неправильный).
   
3) Самое главное. Цель у разработчиков аппаратуры другая: добиться поддержки
   такой-то СнК/платы в нашем *дистрибутиве*, например p10 (и сертифицированном
   дистрибутиве на его основе). Ещё вчера. Рассказывать этой публике "шлите патчи
   в mainline" бесполезно. Они вежливо помашут нам рукой и найдут другой дистрибутив.

> В данном случае, есть ещё один апстрим: asheplyakov@. Он является
> апстримом для меня и точно также может являться им для этих неуказанных
> партнёров.

Отличный подход, мне очень нравится (без тени иронии). Но он не работает.
Например, в текущем un-def (5.15):

$ git diff altlinux-5.15.y..baikalm-5.15.y | diffstat -p1 | grep -E '\b(arm64)|(drivers)'

 arch/arm64/boot/dts/baikal/bm1000.dtsi                     |   65 
 drivers/clocksource/dw_apb_timer_of.c                      |    2 
 drivers/hwmon/bt1-pvt.c                                    |    2 
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c          |    4 
 drivers/usb/dwc3/Kconfig                                   |    9 
 drivers/usb/dwc3/Makefile                                  |    1 
 drivers/usb/dwc3/dwc3-baikal.c                             |  126 
 drivers/usb/dwc3/dwc3-of-simple.c                          |    1 

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

[Anton V. Boyarshinov]

В Wed, 8 Dec 2021 12:07:27 +0400
Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:

> > В данном случае, есть ещё один апстрим: asheplyakov@. Он является
> > апстримом для меня и точно также может являться им для этих неуказанных
> > партнёров.  
> 
> Отличный подход, мне очень нравится (без тени иронии). Но он не работает.
> Например, в текущем un-def (5.15):

Тут я вижу как минимум 3 решения:
1) писать мне, когда в этой ветке появляется готовое для включения в
репозиторий (не в тестовом состоянии). Вчера такое письмо было и я про
него помню и собираюсь сегодня смержить эти изменения.
2) публиковать репозиторий со "стабильными" патчами на git.alt и я бы
подписался на уведомления об изменениях в них.
3) собрать ядро с этими изменениями (тут важно не столкнуться лбами, но
это решаемая проблема)

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

[Alexey Sheplyakov]

On 08.12.2021 12:54, Anton V. Boyarshinov wrote:
> В Wed, 8 Dec 2021 12:07:27 +0400
> Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:
> 
>>> В данном случае, есть ещё один апстрим: asheplyakov@. Он является
>>> апстримом для меня и точно также может являться им для этих неуказанных
>>> партнёров.  
>>
>> Отличный подход, мне очень нравится (без тени иронии). Но он не работает.
>> Например, в текущем un-def (5.15):
> 
> Тут я вижу как минимум 3 решения:
> 1) писать мне, когда в этой ветке появляется готовое для включения в
> репозиторий (не в тестовом состоянии). Вчера такое письмо было и я про
> него помню и собираюсь сегодня смержить эти изменения.> 2) публиковать репозиторий со "стабильными" патчами на git.alt и я бы
> подписался на уведомления об изменениях в них.> 3) собрать ядро с этими изменениями (тут важно не столкнуться лбами, но
> это решаемая проблема)
При отсутствии линейной истории я буду глядеть в diff altlinux-5.N.y..baikalm-5.N.y
и сортировать, что из этого - отличия между "нашим" ядром и upstream,
а что - изменения для поддержки "байкалов". И либо тратить на это уйму времени,
либо ошибаться.
diffstat -p1 | grep -E '\b(arm64)|(drivers)' - в общем случае не работает
(например, в нашем 5.10 есть патчи для Intel Gen 11).
Скоро (уже сейчас) надо будет поддерживать больше процессоров/плат.
И вероятность ошибок/затраты времени сильно возрастут.

Замечу, перекладывание проблемы на Вас ничего по сути не изменит (кроме того,
что тратить уйму времени и ошибаться будете Вы).

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

[Mikhail Novosyolov]

06.12.2021 17:31, Dmitry V. Levin пишет:
> Что значит "отталкиваться"?  Есть наше ядро, в котором написано, на каком
> апстримном ядре оно основано и какие дополнительные ветки туда смержены.
> Что ещё им надо знать?
> <...>
> Мне кажется, тут есть какая-то недосказанность, которая рождает непонимание.

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

Пример:

Сначала было внесено изменение в ядро 5.10.x:
[1] https://git.altlinux.org/gears/k/kernel-image-std-def.git?p=kernel-image-std-def.git;a=commitdiff;h=480c33fd3f9fd3c46e9e605be117d49be98986df

Затем в каком-то релизе 5.10.(x+n), если правильно помню, это изменение продолжало накладываться на код, мержи, соответственно, проходили без конфликтов, но код перестал собираться/работать. Потребовалось его поправить:
[2] https://git.altlinux.org/gears/k/kernel-image-std-def.git?p=kernel-image-std-def.git;a=commitdiff;h=61a50e6f47fabdea107f9e94c43104347359e7d8

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

Поправьте, если не прав или что-то напутал.

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

[Mikhail Novosyolov]

06.12.2021 15:12, Anton Farygin пишет:
> On 06.12.2021 14:41, Anton V. Boyarshinov wrote:
>> В Mon, 6 Dec 2021 15:27:11 +0400
>> Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:
>>
>>> 2) Некий логически монолитный кусок кода (например, LSM модуль AltHa, или
>>>     драйвер dwmac-baikal) оказывается размазанным тонким слоем по N коммитам.
>>>     При переносе на более свежее ядро из этих N коммитов всё равно надо сделать
>>>     один патч (а затем доработать его вслед за изменившимися API).
>> Да, эти "стабильные" патчи живут в отдельных ветках feat-* и fix-*
>>
>> И, если я правильно понимаю, упоминаемым партнёрам они не очень
>> интересны. Зачем их при каждой сборке вытаскивать наверх ценой
>> испорченной истории мне не ясно.
>
> Если мне гит при каждом merge ядра будет ругаться на unrelated history, то я буду громко и сильно ругаться на тех людей, которые так делают.
>
> Давайте ещё раз подумаем и придумаем удобное решение.
>
> А как ведёт ядро та же убунта ? Почему у них нет этой проблемы ?
> https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-oem/+git/focal?h=oem-5.10
>
По моим наблюдениям примерно годичной давности, убунта регулярно форс-пушит в свой гит, который часто не соответствует ушедшим в репозиторий исходникам. С таким гитом работать невозможно. Точно не пример для подражания.

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

[Andrey Savchenko]

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

On Thu, 23 Dec 2021 06:28:34 +0300 Mikhail Novosyolov wrote:
> 
> 06.12.2021 15:12, Anton Farygin пишет:
> > On 06.12.2021 14:41, Anton V. Boyarshinov wrote:
> >> В Mon, 6 Dec 2021 15:27:11 +0400
> >> Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:
> >>
> >>> 2) Некий логически монолитный кусок кода (например, LSM модуль AltHa, или
> >>>     драйвер dwmac-baikal) оказывается размазанным тонким слоем по N коммитам.
> >>>     При переносе на более свежее ядро из этих N коммитов всё равно надо сделать
> >>>     один патч (а затем доработать его вслед за изменившимися API).
> >> Да, эти "стабильные" патчи живут в отдельных ветках feat-* и fix-*
> >>
> >> И, если я правильно понимаю, упоминаемым партнёрам они не очень
> >> интересны. Зачем их при каждой сборке вытаскивать наверх ценой
> >> испорченной истории мне не ясно.
> >
> > Если мне гит при каждом merge ядра будет ругаться на unrelated history, то я буду громко и сильно ругаться на тех людей, которые так делают.
> >
> > Давайте ещё раз подумаем и придумаем удобное решение.
> >
> > А как ведёт ядро та же убунта ? Почему у них нет этой проблемы ?
> > https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-oem/+git/focal?h=oem-5.10
> >
> По моим наблюдениям примерно годичной давности, убунта регулярно форс-пушит в свой гит, который часто не соответствует ушедшим в репозиторий исходникам. С таким гитом работать невозможно. Точно не пример для подражания.

Согласен. За push --force в репозитории, которые в разработке
используются другими людьми, нужно руки отрывать.

Best regards,
Andrew Savchenko

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

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

[Evgeny Sinelnikov]

С новым годом!

чт, 23 дек. 2021 г. в 10:08, Andrey Savchenko <bircoph@altlinux.org>:
>
> On Thu, 23 Dec 2021 06:28:34 +0300 Mikhail Novosyolov wrote:
> >
> > 06.12.2021 15:12, Anton Farygin пишет:
> > > On 06.12.2021 14:41, Anton V. Boyarshinov wrote:
> > >> В Mon, 6 Dec 2021 15:27:11 +0400
> > >> Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:
> > >>
> > >>> 2) Некий логически монолитный кусок кода (например, LSM модуль AltHa, или
> > >>>     драйвер dwmac-baikal) оказывается размазанным тонким слоем по N коммитам.
> > >>>     При переносе на более свежее ядро из этих N коммитов всё равно надо сделать
> > >>>     один патч (а затем доработать его вслед за изменившимися API).
> > >> Да, эти "стабильные" патчи живут в отдельных ветках feat-* и fix-*

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

Здесь я их не наблюдаю:
- http://git.altlinux.org/gears/k/kernel-image-std-def.git
- http://git.altlinux.org/gears/k/kernel-image-un-def.git

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


> > >> И, если я правильно понимаю, упоминаемым партнёрам они не очень
> > >> интересны. Зачем их при каждой сборке вытаскивать наверх ценой
> > >> испорченной истории мне не ясно.
> > >
> > > Если мне гит при каждом merge ядра будет ругаться на unrelated history, то я буду громко и сильно ругаться на тех людей, которые так делают.
> > >
> > > Давайте ещё раз подумаем и придумаем удобное решение.
> > >
> > > А как ведёт ядро та же убунта ? Почему у них нет этой проблемы ?
> > > https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-oem/+git/focal?h=oem-5.10
> > >
> > По моим наблюдениям примерно годичной давности, убунта регулярно форс-пушит в свой гит, который часто не соответствует ушедшим в репозиторий исходникам. С таким гитом работать невозможно. Точно не пример для подражания.

Ну, наверное, убунта это делает из каких-то соображений. Не из прихоти
же? Субъективные предпочтения тоже бывают, но тут не тот случай, когда
всё к этому сводится.


> Согласен. За push --force в репозитории, которые в разработке
> используются другими людьми, нужно руки отрывать.

Не согласен. Смотря в каком контексте идёт речь о разработке. Пачка
запутанных merge-коммитов - это интересная история для пакета, но не
для разработки того исходного кода, который собирается в этом пакете.

О какой, вообще, разработке идёт речь? Что вы называете разработкой,
если отсутствует плановый сценарий передачи исходников в апстрим и не
заложен подход взаимодействия с другими разработчиками, которые тоже
взаимодействуют с апстримом и этот апстрим не мы?

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

При работе с апстримом и попытках передать астриму исходники
приходится делать регулярный git rebase и git push --force. Это же
очевидно. Вариант - передать патч в электронном сообщении только
скрывает отсутствие этого --force, который, фактически, всё равно,
имеет место быть, поскольку этот патч равносилен цепочке git
cherry-pick && git rebase, после которой неизбежен --force или
параллельная история с кучей merge-коммитов, которая никому не
интересна для разработки, даже нам самим.

Не стоит называть любую сборку пакета в репозиторий участием в
разработке. Это иногда так, но очень и очень редко. Во многих случаях
авторы даже не в курсе, что мы их проект собираем. И разница тут
именно в том, что для передачи исходников и для совместного ведения
исходного кода приходится чем-то платить. В нашем случае, одним из
удачных вариантов является вариант с разделением веток:
- master - апстрим;
- altlinux - наши патчи;
- sisyphus/p10/p9/... - ветки с gear-правилами и нашим spec-файлом.

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

Всё это актуально только в том случае, если:
- мы рассматриваем не личный репозиторий, а репозиторий формата
git.altlinux.org/gears/p/package-name.git, как источник для
взаимодействия с другими разработчиками, включая нас самих;
- мы исходим из того, что у нас имеется общий апстрим (ветка master),
который, как первоисточник, используется всеми разработчиками;
- задача, которую мы совместно решаем, состоит в том, чтобы
максимально быстро передавать наши наработки, при необходимости, в
апстрим или друг другу;
- а длительная поддержка наших наработок предполагает, чтобы эта
возможность не утрачивалась в угоду мнимому или объективному, но
весьма условному, удобству.

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

PS: Кстати, у федоры тоже есть git-репы для своих пакетов:
- https://src.fedoraproject.org/rpms/kernel/
Пример, ядра не очень показателен, но даже в нём сразу понятно чем
отличается их ядро от апстримного. А про наше нужно ещё догадаться,
изучив и разобрав gear-правила, которые для каждого пакета свои. Стоит
отметить, что gear на другие дистрибутивы не портирован, хотя у меня
есть свой порт на centos.

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


-- 
Sin (Sinelnikov Evgeny)

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

[Evgeny Sinelnikov]

пн, 3 янв. 2022 г. в 09:07, Evgeny Sinelnikov <sin@altlinux.org>:
>
> С новым годом!
>
> чт, 23 дек. 2021 г. в 10:08, Andrey Savchenko <bircoph@altlinux.org>:
> >
> > On Thu, 23 Dec 2021 06:28:34 +0300 Mikhail Novosyolov wrote:
> > >
> > > 06.12.2021 15:12, Anton Farygin пишет:
> > > > On 06.12.2021 14:41, Anton V. Boyarshinov wrote:
> > > >> В Mon, 6 Dec 2021 15:27:11 +0400
> > > >> Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:
> > > >>
> > > >>> 2) Некий логически монолитный кусок кода (например, LSM модуль AltHa, или
> > > >>>     драйвер dwmac-baikal) оказывается размазанным тонким слоем по N коммитам.
> > > >>>     При переносе на более свежее ядро из этих N коммитов всё равно надо сделать
> > > >>>     один патч (а затем доработать его вслед за изменившимися API).
> > > >> Да, эти "стабильные" патчи живут в отдельных ветках feat-* и fix-*
>
> Где их искать?
> Под какие мажорные релизы они поддерживаются?
> Можно ли рассчитывать, что патчи из этих веток лягут без конфликтов на
> более старшие минорые версии тех мажорных, под которые они ведутся?
>
> Здесь я их не наблюдаю:
> - http://git.altlinux.org/gears/k/kernel-image-std-def.git
> - http://git.altlinux.org/gears/k/kernel-image-un-def.git
>
> Наверное, это вычисляется. Но для этого потребуется:
> - вытянуть гигабайт исходников;
> - выяснить какой командой это вычисляется;
> - то есть потратить кучу времени без гарантии, что не ошибся и всё
> правильно сделал;
> - без возможности быстро посмотреть через веб-интерфейс ту часть
> истории, которая (казалось бы) должна быть доступна.
>

Я нашёл вот такой репозиторий:
http://git.altlinux.org/people/kernelbot/packages/kernel-image.git

Какие-то ветки там точно имеются.
Но вот какие, для какого ядра, в каком порядке нужно применять
совершенно непонятно.

Как это выяснить?

Я так полагаю, что предлагается такой вариант:
git log --merges --grep=fix- --grep=feat- --author=altlinux

Плохо и неудобно, что это не наглядно. Допустим.

Но как, взяв эти ветки, можно рассчитывать, что они лягут на то или
иное мажорное ядро.

Хорошо, что хоть эти ветки обновляются с --force, но тогда как найти
предыдущие варианты, которые "вмержены" в более старые, всем
интересные, актуальные LTS-ядра? И как потом можно рассчитывать, что
получившиеся исходники будут ровно теми, которые мы собираем? Мы ведь
и "начерипикать" можем (и делаем это регулярно)?

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

Именно эту проблему и предложено решить новой схемой ведения
исходников ядра. Может быть эту проблему можно решить и иначе. Для
начала, хотелось бы зафиксировать, что такая проблема есть (иначе
зачем её решать?)


[...]



-- 
Sin (Sinelnikov Evgeny)

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

[Evgeny Sinelnikov]

пн, 3 янв. 2022 г. в 09:41, Aleksey Novodvorsky <aen@basealt.ru>:
>
>
>
>
>
> пн, 3 янв. 2022 г., 08:08 Evgeny Sinelnikov <sin@altlinux.org>:
>>
>> С новым годом!
>
>
> И вас!
>>
>>
>> чт, 23 дек. 2021 г. в 10:08, Andrey Savchenko <bircoph@altlinux.org>:
>> >
>> > On Thu, 23 Dec 2021 06:28:34 +0300 Mikhail Novosyolov wrote:
>> > >
>> > > 06.12.2021 15:12, Anton Farygin пишет:
>> > > > On 06.12.2021 14:41, Anton V. Boyarshinov wrote:
>> > > >> В Mon, 6 Dec 2021 15:27:11 +0400
>> > > >> Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:
>> > > >>
>> > > >>> 2) Некий логически монолитный кусок кода (например, LSM модуль AltHa, или
>> > > >>>     драйвер dwmac-baikal) оказывается размазанным тонким слоем по N коммитам.
>> > > >>>     При переносе на более свежее ядро из этих N коммитов всё равно надо сделать
>> > > >>>     один патч (а затем доработать его вслед за изменившимися API).
>> > > >> Да, эти "стабильные" патчи живут в отдельных ветках feat-* и fix-*
>>
>> Где их искать?
>> Под какие мажорные релизы они поддерживаются?
>> Можно ли рассчитывать, что патчи из этих веток лягут без конфликтов на
>> более старшие минорые версии тех мажорных, под которые они ведутся?
>>
>> Здесь я их не наблюдаю:
>> - http://git.altlinux.org/gears/k/kernel-image-std-def.git
>> - http://git.altlinux.org/gears/k/kernel-image-un-def.git
>>
>> Наверное, это вычисляется. Но для этого потребуется:
>> - вытянуть гигабайт исходников;
>> - выяснить какой командой это вычисляется;
>> - то есть потратить кучу времени без гарантии, что не ошибся и всё
>> правильно сделал;
>> - без возможности быстро посмотреть через веб-интерфейс ту часть
>> истории, которая (казалось бы) должна быть доступна.
>>
>>
>> > > >> И, если я правильно понимаю, упоминаемым партнёрам они не очень
>> > > >> интересны. Зачем их при каждой сборке вытаскивать наверх ценой
>> > > >> испорченной истории мне не ясно.
>> > > >
>> > > > Если мне гит при каждом merge ядра будет ругаться на unrelated history, то я буду громко и сильно ругаться на тех людей, которые так делают.
>> > > >
>> > > > Давайте ещё раз подумаем и придумаем удобное решение.
>> > > >
>> > > > А как ведёт ядро та же убунта ? Почему у них нет этой проблемы ?
>> > > > https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-oem/+git/focal?h=oem-5.10
>> > > >
>> > > По моим наблюдениям примерно годичной давности, убунта регулярно форс-пушит в свой гит, который часто не соответствует ушедшим в репозиторий исходникам. С таким гитом работать невозможно. Точно не пример для подражания.
>>
>> Ну, наверное, убунта это делает из каких-то соображений. Не из прихоти
>> же? Субъективные предпочтения тоже бывают, но тут не тот случай, когда
>> всё к этому сводится.
>>
>>
>> > Согласен. За push --force в репозитории, которые в разработке
>> > используются другими людьми, нужно руки отрывать.
>>
>> Не согласен. Смотря в каком контексте идёт речь о разработке. Пачка
>> запутанных merge-коммитов - это интересная история для пакета, но не
>> для разработки того исходного кода, который собирается в этом пакете.
>>
>> О какой, вообще, разработке идёт речь? Что вы называете разработкой,
>> если отсутствует плановый сценарий передачи исходников в апстрим и не
>> заложен подход взаимодействия с другими разработчиками, которые тоже
>> взаимодействуют с апстримом и этот апстрим не мы?
>>
>> "Плановый сценарий передачи исходников в апстрим" отсутствует, в
>> данном случае, потому, что "выковыривать" размазанные по истории патчи
>> - это антипродуктивный, нерабочий сценарий для любого разработчика,
>> кроме автора пакета, да и для него тоже неудобная;
>> "Подход взаимодействия с другими разработчиками, которые тоже
>> взаимодействуют с апстримом" не заложен, в данном случае, потому, что
>> сторонним разработчикам не менее нужны наши патчи в доступном виде,
>> чем апстриму, если мы хотим этой самой совместной разработки.
>>
>> При работе с апстримом и попытках передать астриму исходники
>> приходится делать регулярный git rebase и git push --force. Это же
>> очевидно. Вариант - передать патч в электронном сообщении только
>> скрывает отсутствие этого --force, который, фактически, всё равно,
>> имеет место быть, поскольку этот патч равносилен цепочке git
>> cherry-pick && git rebase, после которой неизбежен --force или
>> параллельная история с кучей merge-коммитов, которая никому не
>> интересна для разработки, даже нам самим.
>>
>> Не стоит называть любую сборку пакета в репозиторий участием в
>> разработке. Это иногда так, но очень и очень редко. Во многих случаях
>> авторы даже не в курсе, что мы их проект собираем. И разница тут
>> именно в том, что для передачи исходников и для совместного ведения
>> исходного кода приходится чем-то платить. В нашем случае, одним из
>> удачных вариантов является вариант с разделением веток:
>> - master - апстрим;
>> - altlinux - наши патчи;
>> - sisyphus/p10/p9/... - ветки с gear-правилами и нашим spec-файлом.
>>
>> Если патчи не нужно отдавать и наш сборочный репозиторий никому не
>> нужен, то, всё равно, такая схема для разработки удобна, поскольку в
>> историю изменений исходников не входит ещё и история изменений нашего
>> spec-файла.
>>
>> Всё это актуально только в том случае, если:
>> - мы рассматриваем не личный репозиторий, а репозиторий формата
>> git.altlinux.org/gears/p/package-name.git, как источник для
>> взаимодействия с другими разработчиками, включая нас самих;
>> - мы исходим из того, что у нас имеется общий апстрим (ветка master),
>> который, как первоисточник, используется всеми разработчиками;
>> - задача, которую мы совместно решаем, состоит в том, чтобы
>> максимально быстро передавать наши наработки, при необходимости, в
>> апстрим или друг другу;
>> - а длительная поддержка наших наработок предполагает, чтобы эта
>> возможность не утрачивалась в угоду мнимому или объективному, но
>> весьма условному, удобству.
>>
>> Длительная поддержка наших изменений в апстримных проектах тоже, в
>> каком-то смысле - разработка. Но совершенно другая задача, если
>> взаимодействие планируется налаживать на регулярной основе. Если мы
>> ведём все исходники в git-репах, то неплохо бы его и использовать (ну,
>> хотелось бы). В том виде, в котором мы ведём сборку сейчас, во многих
>> случаях, нашими наработками воспользоваться, мягко говоря, довольно
>> затруднительно. Если мы не ставим себе такой задачи, то у меня нет
>> больше никаких вопросов.
>
>
> У нас есть по крайней мере две разные задачи: регулярная сборка ядра из единых исходников для основных платформ и разработка для апстрима и партнёров. И это две разные сферы ответственности.
> То есть задача не только техническая, но управленческая и кадровая. Тянуть одеяло на себя -- самое плохое дело в этой ситуации. Решение нужно комплексное и согласованное, простым оно не будет. Но сейчас есть время и, возможно, ресурсы, подумать над ней.

Именно с целью подумать и что-то придумать я и начал эту переписку.

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

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



> Rgrds, Алексей
>>
>>
>> PS: Кстати, у федоры тоже есть git-репы для своих пакетов:
>> - https://src.fedoraproject.org/rpms/kernel/
>> Пример, ядра не очень показателен, но даже в нём сразу понятно чем
>> отличается их ядро от апстримного. А про наше нужно ещё догадаться,
>> изучив и разобрав gear-правила, которые для каждого пакета свои. Стоит
>> отметить, что gear на другие дистрибутивы не портирован, хотя у меня
>> есть свой порт на centos.
>>
>> PPS: Понятно, что предложенная схема имеет свои издержки. Но "отрывать
>> руки" - это уже как-то за гранью. Я если отрывать руки за то, что
>> сборка есть, а патчей нет? Ну, то есть они как бы есть, но передать их
>> в апстрим требует нетривиальной работы?
>>
>>
>> --
>> Sin (Sinelnikov Evgeny)
>> _______________________________________________
>> Devel mailing list
>> Devel@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 
Sin (Sinelnikov Evgeny)

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

[Aleksey Novodvorsky]

пн, 3 янв. 2022 г. в 09:18, Evgeny Sinelnikov <sin@altlinux.org>:
>
> пн, 3 янв. 2022 г. в 09:41, Aleksey Novodvorsky <aen@basealt.ru>:
> >
> >
> >
> >
> >
> > пн, 3 янв. 2022 г., 08:08 Evgeny Sinelnikov <sin@altlinux.org>:
> >>
> >> С новым годом!
> >
> >
> > И вас!
> >>
> >>
> >> чт, 23 дек. 2021 г. в 10:08, Andrey Savchenko <bircoph@altlinux.org>:
> >> >
> >> > On Thu, 23 Dec 2021 06:28:34 +0300 Mikhail Novosyolov wrote:
> >> > >
> >> > > 06.12.2021 15:12, Anton Farygin пишет:
> >> > > > On 06.12.2021 14:41, Anton V. Boyarshinov wrote:
> >> > > >> В Mon, 6 Dec 2021 15:27:11 +0400
> >> > > >> Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:
> >> > > >>
> >> > > >>> 2) Некий логически монолитный кусок кода (например, LSM модуль AltHa, или
> >> > > >>>     драйвер dwmac-baikal) оказывается размазанным тонким слоем по N коммитам.
> >> > > >>>     При переносе на более свежее ядро из этих N коммитов всё равно надо сделать
> >> > > >>>     один патч (а затем доработать его вслед за изменившимися API).
> >> > > >> Да, эти "стабильные" патчи живут в отдельных ветках feat-* и fix-*
> >>
> >> Где их искать?
> >> Под какие мажорные релизы они поддерживаются?
> >> Можно ли рассчитывать, что патчи из этих веток лягут без конфликтов на
> >> более старшие минорые версии тех мажорных, под которые они ведутся?
> >>
> >> Здесь я их не наблюдаю:
> >> - http://git.altlinux.org/gears/k/kernel-image-std-def.git
> >> - http://git.altlinux.org/gears/k/kernel-image-un-def.git
> >>
> >> Наверное, это вычисляется. Но для этого потребуется:
> >> - вытянуть гигабайт исходников;
> >> - выяснить какой командой это вычисляется;
> >> - то есть потратить кучу времени без гарантии, что не ошибся и всё
> >> правильно сделал;
> >> - без возможности быстро посмотреть через веб-интерфейс ту часть
> >> истории, которая (казалось бы) должна быть доступна.
> >>
> >>
> >> > > >> И, если я правильно понимаю, упоминаемым партнёрам они не очень
> >> > > >> интересны. Зачем их при каждой сборке вытаскивать наверх ценой
> >> > > >> испорченной истории мне не ясно.
> >> > > >
> >> > > > Если мне гит при каждом merge ядра будет ругаться на unrelated history, то я буду громко и сильно ругаться на тех людей, которые так делают.
> >> > > >
> >> > > > Давайте ещё раз подумаем и придумаем удобное решение.
> >> > > >
> >> > > > А как ведёт ядро та же убунта ? Почему у них нет этой проблемы ?
> >> > > > https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-oem/+git/focal?h=oem-5.10
> >> > > >
> >> > > По моим наблюдениям примерно годичной давности, убунта регулярно форс-пушит в свой гит, который часто не соответствует ушедшим в репозиторий исходникам. С таким гитом работать невозможно. Точно не пример для подражания.
> >>
> >> Ну, наверное, убунта это делает из каких-то соображений. Не из прихоти
> >> же? Субъективные предпочтения тоже бывают, но тут не тот случай, когда
> >> всё к этому сводится.
> >>
> >>
> >> > Согласен. За push --force в репозитории, которые в разработке
> >> > используются другими людьми, нужно руки отрывать.
> >>
> >> Не согласен. Смотря в каком контексте идёт речь о разработке. Пачка
> >> запутанных merge-коммитов - это интересная история для пакета, но не
> >> для разработки того исходного кода, который собирается в этом пакете.
> >>
> >> О какой, вообще, разработке идёт речь? Что вы называете разработкой,
> >> если отсутствует плановый сценарий передачи исходников в апстрим и не
> >> заложен подход взаимодействия с другими разработчиками, которые тоже
> >> взаимодействуют с апстримом и этот апстрим не мы?
> >>
> >> "Плановый сценарий передачи исходников в апстрим" отсутствует, в
> >> данном случае, потому, что "выковыривать" размазанные по истории патчи
> >> - это антипродуктивный, нерабочий сценарий для любого разработчика,
> >> кроме автора пакета, да и для него тоже неудобная;
> >> "Подход взаимодействия с другими разработчиками, которые тоже
> >> взаимодействуют с апстримом" не заложен, в данном случае, потому, что
> >> сторонним разработчикам не менее нужны наши патчи в доступном виде,
> >> чем апстриму, если мы хотим этой самой совместной разработки.
> >>
> >> При работе с апстримом и попытках передать астриму исходники
> >> приходится делать регулярный git rebase и git push --force. Это же
> >> очевидно. Вариант - передать патч в электронном сообщении только
> >> скрывает отсутствие этого --force, который, фактически, всё равно,
> >> имеет место быть, поскольку этот патч равносилен цепочке git
> >> cherry-pick && git rebase, после которой неизбежен --force или
> >> параллельная история с кучей merge-коммитов, которая никому не
> >> интересна для разработки, даже нам самим.
> >>
> >> Не стоит называть любую сборку пакета в репозиторий участием в
> >> разработке. Это иногда так, но очень и очень редко. Во многих случаях
> >> авторы даже не в курсе, что мы их проект собираем. И разница тут
> >> именно в том, что для передачи исходников и для совместного ведения
> >> исходного кода приходится чем-то платить. В нашем случае, одним из
> >> удачных вариантов является вариант с разделением веток:
> >> - master - апстрим;
> >> - altlinux - наши патчи;
> >> - sisyphus/p10/p9/... - ветки с gear-правилами и нашим spec-файлом.
> >>
> >> Если патчи не нужно отдавать и наш сборочный репозиторий никому не
> >> нужен, то, всё равно, такая схема для разработки удобна, поскольку в
> >> историю изменений исходников не входит ещё и история изменений нашего
> >> spec-файла.
> >>
> >> Всё это актуально только в том случае, если:
> >> - мы рассматриваем не личный репозиторий, а репозиторий формата
> >> git.altlinux.org/gears/p/package-name.git, как источник для
> >> взаимодействия с другими разработчиками, включая нас самих;
> >> - мы исходим из того, что у нас имеется общий апстрим (ветка master),
> >> который, как первоисточник, используется всеми разработчиками;
> >> - задача, которую мы совместно решаем, состоит в том, чтобы
> >> максимально быстро передавать наши наработки, при необходимости, в
> >> апстрим или друг другу;
> >> - а длительная поддержка наших наработок предполагает, чтобы эта
> >> возможность не утрачивалась в угоду мнимому или объективному, но
> >> весьма условному, удобству.
> >>
> >> Длительная поддержка наших изменений в апстримных проектах тоже, в
> >> каком-то смысле - разработка. Но совершенно другая задача, если
> >> взаимодействие планируется налаживать на регулярной основе. Если мы
> >> ведём все исходники в git-репах, то неплохо бы его и использовать (ну,
> >> хотелось бы). В том виде, в котором мы ведём сборку сейчас, во многих
> >> случаях, нашими наработками воспользоваться, мягко говоря, довольно
> >> затруднительно. Если мы не ставим себе такой задачи, то у меня нет
> >> больше никаких вопросов.
> >
> >
> > У нас есть по крайней мере две разные задачи: регулярная сборка ядра из единых исходников для основных платформ и разработка для апстрима и партнёров. И это две разные сферы ответственности.
> > То есть задача не только техническая, но управленческая и кадровая. Тянуть одеяло на себя -- самое плохое дело в этой ситуации. Решение нужно комплексное и согласованное, простым оно не будет. Но сейчас есть время и, возможно, ресурсы, подумать над ней.
>
> Именно с целью подумать и что-то придумать я и начал эту переписку.
>
> Поскольку уже прошло некоторое время и были высказаны различные точки
> зрения, хочу обобщить некоторые тезисы:
> - в идеале нужен общий подход, подходящий для регулярной сборки ядра
> из единых исходников для основных платформ и для разработки для
> апстрима и партнёров;
> - если это по каким-то причинам невозможно, то требуется
> автоматизируемый сценарий получения исходников для разработки в
> точности совпадающий с исходниками для регулярной сборки.

Да. И что дальше?
Какой следующий шаг, пусть небольшой, но согласованный?
Доверенного эксперта мы пока не нашли.

Rgrds, Алексей
>
> Честно говоря, я не очень понимаю как, и можно ли вообще, добиться
> второго варианта. Кроме того, разработка для апстрима и партнёров в
> равной (если не в большей) требует выявления регрессий на всех
> основных платформах при разработке под какую-то одну.
>
>
>
> > Rgrds, Алексей
> >>
> >>
> >> PS: Кстати, у федоры тоже есть git-репы для своих пакетов:
> >> - https://src.fedoraproject.org/rpms/kernel/
> >> Пример, ядра не очень показателен, но даже в нём сразу понятно чем
> >> отличается их ядро от апстримного. А про наше нужно ещё догадаться,
> >> изучив и разобрав gear-правила, которые для каждого пакета свои. Стоит
> >> отметить, что gear на другие дистрибутивы не портирован, хотя у меня
> >> есть свой порт на centos.
> >>
> >> PPS: Понятно, что предложенная схема имеет свои издержки. Но "отрывать
> >> руки" - это уже как-то за гранью. Я если отрывать руки за то, что
> >> сборка есть, а патчей нет? Ну, то есть они как бы есть, но передать их
> >> в апстрим требует нетривиальной работы?
> >>
> >>
> >> --
> >> Sin (Sinelnikov Evgeny)
> >> _______________________________________________
> >> Devel mailing list
> >> Devel@lists.altlinux.org
> >> https://lists.altlinux.org/mailman/listinfo/devel
> >
> > _______________________________________________
> > Devel mailing list
> > Devel@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/devel
>
>
>
> --
> Sin (Sinelnikov Evgeny)
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Anton V. Boyarshinov]

Добрый день

> Но как, взяв эти ветки, можно рассчитывать, что они лягут на то или
> иное мажорное ядро.
> 
> Хорошо, что хоть эти ветки обновляются с --force,

Эти ветки как правило не обновляются с --force. За последнее время
такой случай был один и был связан с ошибкой при rebase.

> но тогда как найти
> предыдущие варианты, которые "вмержены" в более старые, всем
> интересные, актуальные LTS-ядра?

При возникновении значимых расхождений с новыми мажорными версиями
создаются новые ветки на основе более свежих ядер. Например:

feat-altha-kiosk
feat-altha-kiosk-5.8

В ядре 5.8 LSM сильно переделали и была создана такая новая ветка. Которая неизменной мержится во все ядра с 5.8 включительно (там возникают тривиальные конфликты в Makefile и Kconfig, но они действительно тривиальны)


> И как потом можно рассчитывать, что
> получившиеся исходники будут ровно теми, которые мы собираем? Мы ведь
> и "начерипикать" можем (и делаем это регулярно)?

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

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

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

> Именно эту проблему и предложено решить новой схемой ведения
> исходников ядра. Может быть эту проблему можно решить и иначе. Для
> начала, хотелось бы зафиксировать, что такая проблема есть (иначе
> зачем её решать?)

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

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

[Anton V. Boyarshinov]

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

Я полагаю, можно попробовать не мержить эти ветки в репозиторий ядра, а
описать их в правилах gear. Возможно, это будет нагляднее. Я попробую
сделать такую схему для ядра 5.16, посмотрим как оно будет.
 
> Именно эту проблему и предложено решить новой схемой ведения
> исходников ядра. Может быть эту проблему можно решить и иначе. Для
> начала, хотелось бы зафиксировать, что такая проблема есть (иначе
> зачем её решать?)
> 
> 
> [...]
> 
> 
> 

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

[Anton V. Boyarshinov]

В Tue, 11 Jan 2022 11:01:25 +0300
"Anton V. Boyarshinov" <boyarsh@altlinux.org> пишет:

> > Таким образом наличие веток не спасает. Понять какие патчи имеются в
> > наших ядрах, не прилагая значительных усилий, времени и нетривиальных
> > знаний по git'у, не представляется возможным.  
> 
> Я полагаю, можно попробовать не мержить эти ветки в репозиторий ядра, а
> описать их в правилах gear. Возможно, это будет нагляднее. Я попробую
> сделать такую схему для ядра 5.16, посмотрим как оно будет.

Пока не очень. Я как-то забыл, что для использования в .gear/rules
надо чтоб коммиты были смержены, хотя бы с -s ours. А это путаница в
истории, а история у репозитория ядра и так непростая.

> > Именно эту проблему и предложено решить новой схемой ведения
> > исходников ядра. Может быть эту проблему можно решить и иначе. Для
> > начала, хотелось бы зафиксировать, что такая проблема есть (иначе
> > зачем её решать?)
> > 
> > 
> > [...]
> > 
> > 
> >   
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Paul Wolneykien]

11 января 2022 г. 11:12:09 GMT+03:00, "Anton V. Boyarshinov" <boyarsh@altlinux.org> пишет:
>В Tue, 11 Jan 2022 11:01:25 +0300
>"Anton V. Boyarshinov" <boyarsh@altlinux.org> пишет:
>
>> > Таким образом наличие веток не спасает. Понять какие патчи имеются
>в
>> > наших ядрах, не прилагая значительных усилий, времени и
>нетривиальных
>> > знаний по git'у, не представляется возможным.  
>> 
>> Я полагаю, можно попробовать не мержить эти ветки в репозиторий ядра,
>а
>> описать их в правилах gear. Возможно, это будет нагляднее. Я попробую
>> сделать такую схему для ядра 5.16, посмотрим как оно будет.
>
>Пока не очень. Я как-то забыл, что для использования в .gear/rules
>надо чтоб коммиты были смержены, хотя бы с -s ours. А это путаница в
>истории, а история у репозитория ядра и так непростая.

Возможно, это повод для FR к gear: чтобы он поддерживал в rules ссылки на внешние репозитории или подмодули.


>> > Именно эту проблему и предложено решить новой схемой ведения
>> > исходников ядра. Может быть эту проблему можно решить и иначе. Для
>> > начала, хотелось бы зафиксировать, что такая проблема есть (иначе
>> > зачем её решать?)
>> > 
>> > 
>> > [...]
>> > 
>> > 
>> >   
>> 
>> _______________________________________________
>> Devel mailing list
>> Devel@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel
>_______________________________________________
>Devel mailing list
>Devel@lists.altlinux.org
>https://lists.altlinux.org/mailman/listinfo/devel

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

[Sergey V Turchin]

On Tuesday, 11 January 2022 11:55:20 MSK Paul Wolneykien wrote:

[...]
> Возможно, это повод для FR к gear: чтобы он поддерживал в rules ссылки на
> внешние репозитории или подмодули.
Возможно, с появлением gear все этого уже ждут. ;-)
https://bugs.altlinux.org/17914

[...]

-- 
Regards, Sergey.

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

[Anton Farygin]

On 11.01.2022 12:10, Sergey V Turchin wrote:
> On Tuesday, 11 January 2022 11:55:20 MSK Paul Wolneykien wrote:
>
> [...]
>> Возможно, это повод для FR к gear: чтобы он поддерживал в rules ссылки на
>> внешние репозитории или подмодули.
> Возможно, с появлением gear все этого уже ждут. ;-)
> https://bugs.altlinux.org/17914
>
Основной фичей gear является то, что всё необходимое для сборки можно 
взять из сборочного тэга. Если это и ломать, то надо хорошенько подумать 
о том, как это ломать так, что бы всё равно всё необходимое для сборки 
было доступного из одного места.

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

[Alexey V. Vissarionov]

On 2022-01-11 12:33:33 +0300, Anton Farygin wrote:

 >>> Возможно, это повод для FR к gear: чтобы он поддерживал
 >>> в rules ссылки на внешние репозитории или подмодули.
 >> Возможно, с появлением gear все этого уже ждут. ;-)
 >> https://bugs.altlinux.org/17914
 > Основной фичей gear является то, что всё необходимое для
 > сборки можно взять из сборочного тэга. Если это и ломать,
 > то надо хорошенько подумать о том, как это ломать так,
 > что бы всё равно всё необходимое для сборки было доступного
 > из одного места.

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

[Vladimir D. Seleznev]

On Tue, Jan 11, 2022 at 11:55:20AM +0300, Paul Wolneykien wrote:
> 11 января 2022 г. 11:12:09 GMT+03:00, "Anton V. Boyarshinov" <boyarsh@altlinux.org> пишет:
> >В Tue, 11 Jan 2022 11:01:25 +0300
> >"Anton V. Boyarshinov" <boyarsh@altlinux.org> пишет:
> >
> >> > Таким образом наличие веток не спасает. Понять какие патчи имеются
> >в
> >> > наших ядрах, не прилагая значительных усилий, времени и
> >нетривиальных
> >> > знаний по git'у, не представляется возможным.  
> >> 
> >> Я полагаю, можно попробовать не мержить эти ветки в репозиторий ядра,
> >а
> >> описать их в правилах gear. Возможно, это будет нагляднее. Я попробую
> >> сделать такую схему для ядра 5.16, посмотрим как оно будет.
> >
> >Пока не очень. Я как-то забыл, что для использования в .gear/rules
> >надо чтоб коммиты были смержены, хотя бы с -s ours. А это путаница в
> >истории, а история у репозитория ядра и так непростая.
> 
> Возможно, это повод для FR к gear: чтобы он поддерживал в rules ссылки на внешние репозитории или подмодули.

Мне кажется, это противоречит основной концепции gear.

-- 
   WBR,
   Vladimir D. Seleznev

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

[Anton V. Boyarshinov]

В Tue, 11 Jan 2022 11:01:25 +0300
"Anton V. Boyarshinov" <boyarsh@altlinux.org> пишет:

> > Таким образом наличие веток не спасает. Понять какие патчи имеются в
> > наших ядрах, не прилагая значительных усилий, времени и нетривиальных
> > знаний по git'у, не представляется возможным.  
> 
> Я полагаю, можно попробовать не мержить эти ветки в репозиторий ядра, а
> описать их в правилах gear. Возможно, это будет нагляднее. Я попробую
> сделать такую схему для ядра 5.16, посмотрим как оно будет.

Ну, концептуально как-то так:
https://git.altlinux.org/tasks/293279/

И конкретно:
https://git.altlinux.org/tasks/293279/gears/100/git?p=git;a=blob;f=.gear/rules;h=e1ca2a1812b6998b561d9f108ae2b2e9ebf92233;hb=66ba93e78db964ba5c1947b8866c709d8d4c253c

Для восстановления бранчей и тэгов, если я правильно помню, надо выполнить в репозитории команду gear-restore-tags

С одной стороны, такая схема ощутимо более трудоёмка при сборке новой мажорной версии, но можно попробовать многое заскриптовать.
С другой стороны, есть и определённые удобства в плане поддержки ядер в разных репозиториях.
С третьей стороны, когда stable разъезжается с патчами, в старой схеме это видно на этапе мержа, а в новой -- на этапе сборки. Впрочем, тут есть и недостатки и достоинства.

В общем, надо посмотреть.

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

[Vitaly Chikunov]

Hi,

On Tue, Jan 11, 2022 at 12:10:52PM +0300, Sergey V Turchin wrote:
> On Tuesday, 11 January 2022 11:55:20 MSK Paul Wolneykien wrote:
> 
> [...]
> > Возможно, это повод для FR к gear: чтобы он поддерживал в rules ссылки на
> > внешние репозитории или подмодули.
> Возможно, с появлением gear все этого уже ждут. ;-)
> https://bugs.altlinux.org/17914

Возможны разные попытки решения этой проблемы.
Вот Proof of Concept code
  gitery:/people/vt/private/gear-submodule-update.git
который делает фиктивный merge всем submodules и меняет rules и spec
так чтоб они разтаривались при сборке.

Это решение чисто экспериментальное (as in no warranty), но, возможно,
оно вдохновит кого-то на более правильное решение.

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

[Dmitry V. Levin]

Hi,

On Wed, Jan 12, 2022 at 03:26:55AM +0300, Vitaly Chikunov wrote:
> On Tue, Jan 11, 2022 at 12:10:52PM +0300, Sergey V Turchin wrote:
> > On Tuesday, 11 January 2022 11:55:20 MSK Paul Wolneykien wrote:
> > 
> > [...]
> > > Возможно, это повод для FR к gear: чтобы он поддерживал в rules ссылки на
> > > внешние репозитории или подмодули.
> > Возможно, с появлением gear все этого уже ждут. ;-)
> > https://bugs.altlinux.org/17914
> 
> Возможны разные попытки решения этой проблемы.
> Вот Proof of Concept code
>   gitery:/people/vt/private/gear-submodule-update.git
> который делает фиктивный merge всем submodules и меняет rules и spec
> так чтоб они разтаривались при сборке.
> 
> Это решение чисто экспериментальное (as in no warranty), но, возможно,
> оно вдохновит кого-то на более правильное решение.

Есть ещё
https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=refs/heads/legion/patchset/submodule-support/v5
но я его не смог дочитать.


-- 
ldv

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

[Vladislav Zavjalov]

On Wed, Jan 12, 2022 at 03:26:55AM +0300, Vitaly Chikunov wrote:
> > https://bugs.altlinux.org/17914
> 
> Возможны разные попытки решения этой проблемы.

Я для себя это решал так:
У меня есть репозиторий, который я хочу подключать как submodule
к разным пакетам. В него я кладу минимальный spec и
минимальный gear-rules ("tar: . name=modules").
В основные репозитории кладу скрипт с "cd modules; gear --export-dir .."
При сборке новой версии запускаю скрипт и в коммит
добавляю обновленный tar (а в секции %build у меня стоит "tar -xvf modules.tar").

Получается вполне понятно и удобно. Победа над gear с помощью gear!

Наверное, можно сделать какой-то gear-update-submodules, который будет
делать то же самое, но без отдельного скрипта и без конфигурации в
submodule-репозитории.

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

[Anton Farygin]

On 12.01.2022 03:26, Vitaly Chikunov wrote:
> Hi,
>
> On Tue, Jan 11, 2022 at 12:10:52PM +0300, Sergey V Turchin wrote:
>> On Tuesday, 11 January 2022 11:55:20 MSK Paul Wolneykien wrote:
>>
>> [...]
>>> Возможно, это повод для FR к gear: чтобы он поддерживал в rules ссылки на
>>> внешние репозитории или подмодули.
>> Возможно, с появлением gear все этого уже ждут. ;-)
>> https://bugs.altlinux.org/17914
> Возможны разные попытки решения этой проблемы.
> Вот Proof of Concept code
>    gitery:/people/vt/private/gear-submodule-update.git
> который делает фиктивный merge всем submodules и меняет rules и spec
> так чтоб они разтаривались при сборке.
>
> Это решение чисто экспериментальное (as in no warranty), но, возможно,
> оно вдохновит кого-то на более правильное решение.
>
https://git.altlinux.org/gears/c/clickhouse.git?p=clickhouse.git;a=blob;f=.gear/update-submodules.sh;h=b17b42524a9d2a6b32632f13b6708972a66a3ca6;hb=77fb07c30b1550fb2f3fd87ea1536f068ec8fd5f

Вот тоже что-то вроде этого.

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

[Dmitry V. Levin]

On Wed, Jan 12, 2022 at 03:39:20AM +0300, Dmitry V. Levin wrote:
> On Wed, Jan 12, 2022 at 03:26:55AM +0300, Vitaly Chikunov wrote:
> > On Tue, Jan 11, 2022 at 12:10:52PM +0300, Sergey V Turchin wrote:
> > > On Tuesday, 11 January 2022 11:55:20 MSK Paul Wolneykien wrote:
> > > 
> > > [...]
> > > > Возможно, это повод для FR к gear: чтобы он поддерживал в rules ссылки на
> > > > внешние репозитории или подмодули.
> > > Возможно, с появлением gear все этого уже ждут. ;-)
> > > https://bugs.altlinux.org/17914
> > 
> > Возможны разные попытки решения этой проблемы.
> > Вот Proof of Concept code
> >   gitery:/people/vt/private/gear-submodule-update.git
> > который делает фиктивный merge всем submodules и меняет rules и spec
> > так чтоб они разтаривались при сборке.
> > 
> > Это решение чисто экспериментальное (as in no warranty), но, возможно,
> > оно вдохновит кого-то на более правильное решение.
> 
> Есть ещё
> https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=refs/heads/legion/patchset/submodule-support/v5
> но я его не смог дочитать.

Вроде бы дочитал, отредактировал, запушил в
https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=submodules
но всё равно у меня нет полной уверенности, что предпоследний коммит,
который обрабатывает .gear/submodules/list в gear, делает это совершенно
безопасно.


-- 
ldv

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

[Alexey Gladkov]

On Wed, Jan 12, 2022 at 03:20:51PM +0300, Dmitry V. Levin wrote:
> On Wed, Jan 12, 2022 at 03:39:20AM +0300, Dmitry V. Levin wrote:
> > On Wed, Jan 12, 2022 at 03:26:55AM +0300, Vitaly Chikunov wrote:
> > > On Tue, Jan 11, 2022 at 12:10:52PM +0300, Sergey V Turchin wrote:
> > > > On Tuesday, 11 January 2022 11:55:20 MSK Paul Wolneykien wrote:
> > > > 
> > > > [...]
> > > > > Возможно, это повод для FR к gear: чтобы он поддерживал в rules ссылки на
> > > > > внешние репозитории или подмодули.
> > > > Возможно, с появлением gear все этого уже ждут. ;-)
> > > > https://bugs.altlinux.org/17914
> > > 
> > > Возможны разные попытки решения этой проблемы.
> > > Вот Proof of Concept code
> > >   gitery:/people/vt/private/gear-submodule-update.git
> > > который делает фиктивный merge всем submodules и меняет rules и spec
> > > так чтоб они разтаривались при сборке.
> > > 
> > > Это решение чисто экспериментальное (as in no warranty), но, возможно,
> > > оно вдохновит кого-то на более правильное решение.
> > 
> > Есть ещё
> > https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=refs/heads/legion/patchset/submodule-support/v5
> > но я его не смог дочитать.
> 
> Вроде бы дочитал, отредактировал, запушил в
> https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=submodules

+       if [ -s "$workdir/listed_bundles" ]; then
+               sort -u -o "$workdir/listed_bundles"{,}
+               >> "$workdir/appended_bundles"

Кажется что-то пошло не так при редактировании.
Разве не должно быть 

sort -u -o "$workdir/listed_bundles"{,} \
 >> "$workdir/appended_bundles"

?

Отредактированные коммиты точно тесты проходят ? )))

+               sort -u -o "$workdir/appended_bundles"{,}
+               comm -23 "$workdir/listed_bundles" \
+                        "$workdir/appended_bundles" \
+                       > "$workdir/unused_submodules"
+               if [ -s "$workdir/unused_submodules" ]; then
+                       lineno=0
+                       local rules='.gear/submodules/list'
+                       local bundle sm_hash sm_path dummy
+                       while read -r bundle sm_hash sm_path dummy; do {
+                               lineno=$(($lineno + 1))
+                               grep -Fxqse "$lineno" "$workdir/unused_submodules" ||
+                                       continue
+                               rules_info "unused bundle: $sm_path"
+                       } < /dev/null; done < "$workdir/submodules_list"

Может лучше 

 grep -Fxqse "$lineno" "$workdir/unused_submodules" < /dev/null

а не этот ужасный блок ?

+               fi
+       fi

> но всё равно у меня нет полной уверенности, что предпоследний коммит,
> который обрабатывает .gear/submodules/list в gear, делает это совершенно
> безопасно.
> 
> 
> -- 
> ldv
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
Rgrds, legion

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

[Alexey Gladkov]

On Wed, Jan 12, 2022 at 01:40:03PM +0100, Alexey Gladkov wrote:
> On Wed, Jan 12, 2022 at 03:20:51PM +0300, Dmitry V. Levin wrote:
> > On Wed, Jan 12, 2022 at 03:39:20AM +0300, Dmitry V. Levin wrote:
> > > On Wed, Jan 12, 2022 at 03:26:55AM +0300, Vitaly Chikunov wrote:
> > > > On Tue, Jan 11, 2022 at 12:10:52PM +0300, Sergey V Turchin wrote:
> > > > > On Tuesday, 11 January 2022 11:55:20 MSK Paul Wolneykien wrote:
> > > > > 
> > > > > [...]
> > > > > > Возможно, это повод для FR к gear: чтобы он поддерживал в rules ссылки на
> > > > > > внешние репозитории или подмодули.
> > > > > Возможно, с появлением gear все этого уже ждут. ;-)
> > > > > https://bugs.altlinux.org/17914
> > > > 
> > > > Возможны разные попытки решения этой проблемы.
> > > > Вот Proof of Concept code
> > > >   gitery:/people/vt/private/gear-submodule-update.git
> > > > который делает фиктивный merge всем submodules и меняет rules и spec
> > > > так чтоб они разтаривались при сборке.
> > > > 
> > > > Это решение чисто экспериментальное (as in no warranty), но, возможно,
> > > > оно вдохновит кого-то на более правильное решение.
> > > 
> > > Есть ещё
> > > https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=refs/heads/legion/patchset/submodule-support/v5
> > > но я его не смог дочитать.
> > 
> > Вроде бы дочитал, отредактировал, запушил в
> > https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=submodules
> 
> +       if [ -s "$workdir/listed_bundles" ]; then
> +               sort -u -o "$workdir/listed_bundles"{,}
> +               >> "$workdir/appended_bundles"
> 
> Кажется что-то пошло не так при редактировании.
> Разве не должно быть 
> 
> sort -u -o "$workdir/listed_bundles"{,} \
>  >> "$workdir/appended_bundles"
> 
> ?
> 
> Отредактированные коммиты точно тесты проходят ? )))
> 
> +               sort -u -o "$workdir/appended_bundles"{,}
> +               comm -23 "$workdir/listed_bundles" \
> +                        "$workdir/appended_bundles" \
> +                       > "$workdir/unused_submodules"
> +               if [ -s "$workdir/unused_submodules" ]; then
> +                       lineno=0
> +                       local rules='.gear/submodules/list'
> +                       local bundle sm_hash sm_path dummy
> +                       while read -r bundle sm_hash sm_path dummy; do {
> +                               lineno=$(($lineno + 1))
> +                               grep -Fxqse "$lineno" "$workdir/unused_submodules" ||
> +                                       continue
> +                               rules_info "unused bundle: $sm_path"
> +                       } < /dev/null; done < "$workdir/submodules_list"
> 
> Может лучше 
> 
>  grep -Fxqse "$lineno" "$workdir/unused_submodules" < /dev/null
> 
> а не этот ужасный блок ?

В других местах я вижу ты тоже такую конструкцию добавил.

Я бы сделал:

exec 4</etc/passwd
while read -r line <&4; do
	echo "# $line"
done
exec 4<&-

хоть и придётся обрабатывать закрытие декриптора в некоторых случаях. Зато
выглядит более читабильно.

-- 
Rgrds, legion

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

[Alexey Gladkov]

On Wed, Jan 12, 2022 at 01:40:03PM +0100, Alexey Gladkov wrote:
> On Wed, Jan 12, 2022 at 03:20:51PM +0300, Dmitry V. Levin wrote:
> > On Wed, Jan 12, 2022 at 03:39:20AM +0300, Dmitry V. Levin wrote:
> > > On Wed, Jan 12, 2022 at 03:26:55AM +0300, Vitaly Chikunov wrote:
> > > > On Tue, Jan 11, 2022 at 12:10:52PM +0300, Sergey V Turchin wrote:
> > > > > On Tuesday, 11 January 2022 11:55:20 MSK Paul Wolneykien wrote:
> > > > > 
> > > > > [...]
> > > > > > Возможно, это повод для FR к gear: чтобы он поддерживал в rules ссылки на
> > > > > > внешние репозитории или подмодули.
> > > > > Возможно, с появлением gear все этого уже ждут. ;-)
> > > > > https://bugs.altlinux.org/17914
> > > > 
> > > > Возможны разные попытки решения этой проблемы.
> > > > Вот Proof of Concept code
> > > >   gitery:/people/vt/private/gear-submodule-update.git
> > > > который делает фиктивный merge всем submodules и меняет rules и spec
> > > > так чтоб они разтаривались при сборке.
> > > > 
> > > > Это решение чисто экспериментальное (as in no warranty), но, возможно,
> > > > оно вдохновит кого-то на более правильное решение.
> > > 
> > > Есть ещё
> > > https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=refs/heads/legion/patchset/submodule-support/v5
> > > но я его не смог дочитать.
> > 
> > Вроде бы дочитал, отредактировал, запушил в
> > https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=submodules
> 
> +       if [ -s "$workdir/listed_bundles" ]; then
> +               sort -u -o "$workdir/listed_bundles"{,}
> +               >> "$workdir/appended_bundles"
> 
> Кажется что-то пошло не так при редактировании.
> Разве не должно быть 
> 
> sort -u -o "$workdir/listed_bundles"{,} \
>  >> "$workdir/appended_bundles"
> 
> ?

Отвечу сам себе. Не должно. Тут всё верно.

-- 
Rgrds, legion

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

[Dmitry V. Levin]

On Wed, Jan 12, 2022 at 02:10:15PM +0100, Alexey Gladkov wrote:
> On Wed, Jan 12, 2022 at 01:40:03PM +0100, Alexey Gladkov wrote:
> > On Wed, Jan 12, 2022 at 03:20:51PM +0300, Dmitry V. Levin wrote:
> > > On Wed, Jan 12, 2022 at 03:39:20AM +0300, Dmitry V. Levin wrote:
> > > > On Wed, Jan 12, 2022 at 03:26:55AM +0300, Vitaly Chikunov wrote:
> > > > > On Tue, Jan 11, 2022 at 12:10:52PM +0300, Sergey V Turchin wrote:
> > > > > > On Tuesday, 11 January 2022 11:55:20 MSK Paul Wolneykien wrote:
> > > > > > 
> > > > > > [...]
> > > > > > > Возможно, это повод для FR к gear: чтобы он поддерживал в rules ссылки на
> > > > > > > внешние репозитории или подмодули.
> > > > > > Возможно, с появлением gear все этого уже ждут. ;-)
> > > > > > https://bugs.altlinux.org/17914
> > > > > 
> > > > > Возможны разные попытки решения этой проблемы.
> > > > > Вот Proof of Concept code
> > > > >   gitery:/people/vt/private/gear-submodule-update.git
> > > > > который делает фиктивный merge всем submodules и меняет rules и spec
> > > > > так чтоб они разтаривались при сборке.
> > > > > 
> > > > > Это решение чисто экспериментальное (as in no warranty), но, возможно,
> > > > > оно вдохновит кого-то на более правильное решение.
> > > > 
> > > > Есть ещё
> > > > https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=refs/heads/legion/patchset/submodule-support/v5
> > > > но я его не смог дочитать.
> > > 
> > > Вроде бы дочитал, отредактировал, запушил в
> > > https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=submodules
> > 
> > +       if [ -s "$workdir/listed_bundles" ]; then
> > +               sort -u -o "$workdir/listed_bundles"{,}
> > +               >> "$workdir/appended_bundles"
> > 
> > Кажется что-то пошло не так при редактировании.
> > Разве не должно быть 
> > 
> > sort -u -o "$workdir/listed_bundles"{,} \
> >  >> "$workdir/appended_bundles"
> > 
> > ?
> 
> Отвечу сам себе. Не должно. Тут всё верно.

Но я на всякий случай переписал эту часть попроще.


-- 
ldv

Re: [devel] gear-store-submodules

[Dmitry V. Levin]

On Wed, Jan 12, 2022 at 03:20:51PM +0300, Dmitry V. Levin wrote:
> On Wed, Jan 12, 2022 at 03:39:20AM +0300, Dmitry V. Levin wrote:
> > On Wed, Jan 12, 2022 at 03:26:55AM +0300, Vitaly Chikunov wrote:
> > > On Tue, Jan 11, 2022 at 12:10:52PM +0300, Sergey V Turchin wrote:
> > > > On Tuesday, 11 January 2022 11:55:20 MSK Paul Wolneykien wrote:
> > > > 
> > > > [...]
> > > > > Возможно, это повод для FR к gear: чтобы он поддерживал в rules ссылки на
> > > > > внешние репозитории или подмодули.
> > > > Возможно, с появлением gear все этого уже ждут. ;-)
> > > > https://bugs.altlinux.org/17914
> > > 
> > > Возможны разные попытки решения этой проблемы.
> > > Вот Proof of Concept code
> > >   gitery:/people/vt/private/gear-submodule-update.git
> > > который делает фиктивный merge всем submodules и меняет rules и spec
> > > так чтоб они разтаривались при сборке.
> > > 
> > > Это решение чисто экспериментальное (as in no warranty), но, возможно,
> > > оно вдохновит кого-то на более правильное решение.
> > 
> > Есть ещё
> > https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=refs/heads/legion/patchset/submodule-support/v5
> > но я его не смог дочитать.
> 
> Вроде бы дочитал, отредактировал, запушил в
> https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=submodules
> но всё равно у меня нет полной уверенности, что предпоследний коммит,
> который обрабатывает .gear/submodules/list в gear, делает это совершенно
> безопасно.

Этот подход работает, но он подойдёт не всем.

Постановка задачи была, насколько я помню, примерно следующая:
- в некотором проекте используются submodules для сравнительно небольших
  внешних подпроектов;
- требуется собирать пакеты из этого проекта в Сизиф;
- требуется не засорять историю этого проекта историями внешних подпроектов;
- пользоваться этим должно быть не сложнее, чем gear-store-tags;
- за всё это удобство можно заплатить увеличением размера git-репозитория
  проекта.

В общих чертах реализация построена та том, что
- есть новый инструмент gear-store-submodules, похожий на gear-store-tags,
  который превращает submodules в бандлы с помощью git-bundle(1),
  а эти бандлы, в свою очередь, добавляются в репозиторий как обычные файлы;
- gear умеет автоматически конвертировать такие бандлы в архивы
  и добавлять такие архивы к основным архивам.


-- 
ldv

Re: [devel] gear-store-submodules

[Alexey Gladkov]

On Wed, Jan 12, 2022 at 07:59:07PM +0300, Dmitry V. Levin wrote:
> > Вроде бы дочитал, отредактировал, запушил в
> > https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=submodules
> > но всё равно у меня нет полной уверенности, что предпоследний коммит,
> > который обрабатывает .gear/submodules/list в gear, делает это совершенно
> > безопасно.
> 
> Этот подход работает, но он подойдёт не всем.
> 
> Постановка задачи была, насколько я помню, примерно следующая:
> - в некотором проекте используются submodules для сравнительно небольших
>   внешних подпроектов;
> - требуется собирать пакеты из этого проекта в Сизиф;
> - требуется не засорять историю этого проекта историями внешних подпроектов;
> - пользоваться этим должно быть не сложнее, чем gear-store-tags;
> - за всё это удобство можно заплатить увеличением размера git-репозитория
>   проекта.
> 
> В общих чертах реализация построена та том, что
> - есть новый инструмент gear-store-submodules, похожий на gear-store-tags,
>   который превращает submodules в бандлы с помощью git-bundle(1),
>   а эти бандлы, в свою очередь, добавляются в репозиторий как обычные файлы;
> - gear умеет автоматически конвертировать такие бандлы в архивы
>   и добавлять такие архивы к основным архивам.

Эта реализация сделана с учётом основного критерия gear - все необходимые
объекты должны быть доступны по хэшу. При этом истории не должны
смешиваться иначе это уже не submodule, а subtree. Такую реализацию
поддержки submodules для gear я тоже делал, но это было совсем не то что
хотелось.

-- 
Rgrds, legion

Re: [devel] gear-store-submodules

[Dmitry V. Levin]

On Wed, Jan 12, 2022 at 08:14:34PM +0100, Alexey Gladkov wrote:
> On Wed, Jan 12, 2022 at 07:59:07PM +0300, Dmitry V. Levin wrote:
> > > Вроде бы дочитал, отредактировал, запушил в
> > > https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=submodules
> > > но всё равно у меня нет полной уверенности, что предпоследний коммит,
> > > который обрабатывает .gear/submodules/list в gear, делает это совершенно
> > > безопасно.
> > 
> > Этот подход работает, но он подойдёт не всем.
> > 
> > Постановка задачи была, насколько я помню, примерно следующая:
> > - в некотором проекте используются submodules для сравнительно небольших
> >   внешних подпроектов;
> > - требуется собирать пакеты из этого проекта в Сизиф;
> > - требуется не засорять историю этого проекта историями внешних подпроектов;
> > - пользоваться этим должно быть не сложнее, чем gear-store-tags;
> > - за всё это удобство можно заплатить увеличением размера git-репозитория
> >   проекта.
> > 
> > В общих чертах реализация построена та том, что
> > - есть новый инструмент gear-store-submodules, похожий на gear-store-tags,
> >   который превращает submodules в бандлы с помощью git-bundle(1),
> >   а эти бандлы, в свою очередь, добавляются в репозиторий как обычные файлы;
> > - gear умеет автоматически конвертировать такие бандлы в архивы
> >   и добавлять такие архивы к основным архивам.
> 
> Эта реализация сделана с учётом основного критерия gear - все необходимые
> объекты должны быть доступны по хэшу. При этом истории не должны
> смешиваться иначе это уже не submodule, а subtree. Такую реализацию
> поддержки submodules для gear я тоже делал, но это было совсем не то что
> хотелось.

Может быть, кому-то конвертирование submodule в subtree подошло бы лучше,
чем конвертирование submodule в bundle.


-- 
ldv

Re: [devel] gear-store-submodules

[Alexey Gladkov]

On Wed, Jan 12, 2022 at 11:06:23PM +0300, Dmitry V. Levin wrote:
> > Эта реализация сделана с учётом основного критерия gear - все необходимые
> > объекты должны быть доступны по хэшу. При этом истории не должны
> > смешиваться иначе это уже не submodule, а subtree. Такую реализацию
> > поддержки submodules для gear я тоже делал, но это было совсем не то что
> > хотелось.
> 
> Может быть, кому-то конвертирование submodule в subtree подошло бы лучше,
> чем конвертирование submodule в bundle.

В том-то и дело, что для этого не нужны дополнительные утилиты. Это
делается средствами git. Кому это нужно легко это могут сделать и
пользоваться gear.

-- 
Rgrds, legion

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

[Vladimir D. Seleznev]

On Tue, Jan 11, 2022 at 03:18:21PM +0300, Anton V. Boyarshinov wrote:
> В Tue, 11 Jan 2022 11:01:25 +0300
> "Anton V. Boyarshinov" <boyarsh@altlinux.org> пишет:
> 
> > > Таким образом наличие веток не спасает. Понять какие патчи имеются в
> > > наших ядрах, не прилагая значительных усилий, времени и нетривиальных
> > > знаний по git'у, не представляется возможным.  
> > 
> > Я полагаю, можно попробовать не мержить эти ветки в репозиторий ядра, а
> > описать их в правилах gear. Возможно, это будет нагляднее. Я попробую
> > сделать такую схему для ядра 5.16, посмотрим как оно будет.
> 
> Ну, концептуально как-то так:
> https://git.altlinux.org/tasks/293279/
> 
> И конкретно:
> https://git.altlinux.org/tasks/293279/gears/100/git?p=git;a=blob;f=.gear/rules;h=e1ca2a1812b6998b561d9f108ae2b2e9ebf92233;hb=66ba93e78db964ba5c1947b8866c709d8d4c253c
> 
> Для восстановления бранчей и тэгов, если я правильно помню, надо выполнить в репозитории команду gear-restore-tags
> 
> С одной стороны, такая схема ощутимо более трудоёмка при сборке новой мажорной версии, но можно попробовать многое заскриптовать.
> С другой стороны, есть и определённые удобства в плане поддержки ядер в разных репозиториях.
> С третьей стороны, когда stable разъезжается с патчами, в старой схеме это видно на этапе мержа, а в новой -- на этапе сборки. Впрочем, тут есть и недостатки и достоинства.
> 
> В общем, надо посмотреть.

Я напоминаю, что начиная с rpm-build-4.0.4-alt133 поддерживается
директива %autopatch. Её использование удобно тем, что нет необходимости
следить за соответствием декларации патча (PatchN: fix.patch) и наличием
его применением (%patchN -p1). Я думаю, она хорошо подходит к данной
схеме в т.ч..

-- 
   WBR,
   Vladimir D. Seleznev

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

[Anton V. Boyarshinov]

> > С одной стороны, такая схема ощутимо более трудоёмка при сборке новой мажорной версии, но можно попробовать многое заскриптовать.
> > С другой стороны, есть и определённые удобства в плане поддержки ядер в разных репозиториях.
> > С третьей стороны, когда stable разъезжается с патчами, в старой схеме это видно на этапе мержа, а в новой -- на этапе сборки. Впрочем, тут есть и недостатки и достоинства.
> > 
> > В общем, надо посмотреть.  
> 
> Я напоминаю, что начиная с rpm-build-4.0.4-alt133 поддерживается
> директива %autopatch. Её использование удобно тем, что нет необходимости
> следить за соответствием декларации патча (PatchN: fix.patch) и наличием
> его применением (%patchN -p1). Я думаю, она хорошо подходит к данной
> схеме в т.ч..
> 

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

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

[Anton V. Boyarshinov]

В Wed, 19 Jan 2022 12:56:52 +0300
"Anton V. Boyarshinov" <boyarsh@altlinux.org> пишет:

> > > С одной стороны, такая схема ощутимо более трудоёмка при сборке новой мажорной версии, но можно попробовать многое заскриптовать.
> > > С другой стороны, есть и определённые удобства в плане поддержки ядер в разных репозиториях.
> > > С третьей стороны, когда stable разъезжается с патчами, в старой схеме это видно на этапе мержа, а в новой -- на этапе сборки. Впрочем, тут есть и недостатки и достоинства.
> > > 
> > > В общем, надо посмотреть.    
> > 
> > Я напоминаю, что начиная с rpm-build-4.0.4-alt133 поддерживается
> > директива %autopatch. Её использование удобно тем, что нет необходимости
> > следить за соответствием декларации патча (PatchN: fix.patch) и наличием
> > его применением (%patchN -p1). Я думаю, она хорошо подходит к данной
> > схеме в т.ч..
> >   
> 
> Вот хорошо бы было, если бы она не только следила за соответствием
> декларации патча и его наложением, но могла бы также замечать, что
> патчи в виде файлов есть, а ни декларации,  ни наложения нет.

или хотя бы %unapplyed_patches_terminate_build

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

[Alexey V. Vissarionov]

On 2022-01-19 13:15:13 +0300, Anton V. Boyarshinov wrote:

 >>> Я напоминаю, что начиная с rpm-build-4.0.4-alt133 поддерживается
 >>> директива %autopatch. Её использование удобно тем, что нет
 >>> необходимости следить за соответствием декларации патча
 >>> (PatchN: fix.patch) и наличием его применением (%patchN -p1).
 >> Вот хорошо бы было, если бы она не только следила за
 >> соответствием декларации патча и его наложением, но могла бы
 >> также замечать, что патчи в виде файлов есть, а ни декларации,
 >> ни наложения нет.
 > или хотя бы %unapplyed_patches_terminate_build

0. [GN] unapplied

1. Накатывание патчей может быть условным - как правило %ifarch,
но может быть и вообще любой %if


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

[Vladimir D. Seleznev]

On Wed, Jan 19, 2022 at 12:56:52PM +0300, Anton V. Boyarshinov wrote:
> 
> > > С одной стороны, такая схема ощутимо более трудоёмка при сборке новой мажорной версии, но можно попробовать многое заскриптовать.
> > > С другой стороны, есть и определённые удобства в плане поддержки ядер в разных репозиториях.
> > > С третьей стороны, когда stable разъезжается с патчами, в старой схеме это видно на этапе мержа, а в новой -- на этапе сборки. Впрочем, тут есть и недостатки и достоинства.
> > > 
> > > В общем, надо посмотреть.  
> > 
> > Я напоминаю, что начиная с rpm-build-4.0.4-alt133 поддерживается
> > директива %autopatch. Её использование удобно тем, что нет необходимости
> > следить за соответствием декларации патча (PatchN: fix.patch) и наличием
> > его применением (%patchN -p1). Я думаю, она хорошо подходит к данной
> > схеме в т.ч..
> > 
> 
> Вот хорошо бы было, если бы она не только следила за соответствием
> декларации патча и его наложением, но могла бы также замечать, что
> патчи в виде файлов есть, а ни декларации,  ни наложения нет.

Может быть сделать соответствующую поддержку в gear?

Например, можно реализовать директиву gear-rules declare-patches: yes,
при наличие которой при сборке пакета патчи последовательно, в порядке
следования diff'ов в gear-rules, подставляются в spec-файл (в таком
случае spec в gear является не чистым, а шаблоном для настоящего спека).

-- 
   WBR,
   Vladimir D. Seleznev

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

[Anton Farygin]

On 19.01.2022 13:31, Vladimir D. Seleznev wrote:
> On Wed, Jan 19, 2022 at 12:56:52PM +0300, Anton V. Boyarshinov wrote:
>>>> С одной стороны, такая схема ощутимо более трудоёмка при сборке новой мажорной версии, но можно попробовать многое заскриптовать.
>>>> С другой стороны, есть и определённые удобства в плане поддержки ядер в разных репозиториях.
>>>> С третьей стороны, когда stable разъезжается с патчами, в старой схеме это видно на этапе мержа, а в новой -- на этапе сборки. Впрочем, тут есть и недостатки и достоинства.
>>>>
>>>> В общем, надо посмотреть.
>>> Я напоминаю, что начиная с rpm-build-4.0.4-alt133 поддерживается
>>> директива %autopatch. Её использование удобно тем, что нет необходимости
>>> следить за соответствием декларации патча (PatchN: fix.patch) и наличием
>>> его применением (%patchN -p1). Я думаю, она хорошо подходит к данной
>>> схеме в т.ч..
>>>
>> Вот хорошо бы было, если бы она не только следила за соответствием
>> декларации патча и его наложением, но могла бы также замечать, что
>> патчи в виде файлов есть, а ни декларации,  ни наложения нет.
> Может быть сделать соответствующую поддержку в gear?
>
> Например, можно реализовать директиву gear-rules declare-patches: yes,
> при наличие которой при сборке пакета патчи последовательно, в порядке
> следования diff'ов в gear-rules, подставляются в spec-файл (в таком
> случае spec в gear является не чистым, а шаблоном для настоящего спека).
>
вот только у нас ещё остался архитектурно-независимый src.rpm.

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

[Vladimir D. Seleznev]

On Wed, Jan 19, 2022 at 01:32:50PM +0300, Anton Farygin wrote:
> On 19.01.2022 13:31, Vladimir D. Seleznev wrote:
> > On Wed, Jan 19, 2022 at 12:56:52PM +0300, Anton V. Boyarshinov wrote:
> >>>> С одной стороны, такая схема ощутимо более трудоёмка при сборке новой мажорной версии, но можно попробовать многое заскриптовать.
> >>>> С другой стороны, есть и определённые удобства в плане поддержки ядер в разных репозиториях.
> >>>> С третьей стороны, когда stable разъезжается с патчами, в старой схеме это видно на этапе мержа, а в новой -- на этапе сборки. Впрочем, тут есть и недостатки и достоинства.
> >>>>
> >>>> В общем, надо посмотреть.
> >>> Я напоминаю, что начиная с rpm-build-4.0.4-alt133 поддерживается
> >>> директива %autopatch. Её использование удобно тем, что нет необходимости
> >>> следить за соответствием декларации патча (PatchN: fix.patch) и наличием
> >>> его применением (%patchN -p1). Я думаю, она хорошо подходит к данной
> >>> схеме в т.ч..
> >>>
> >> Вот хорошо бы было, если бы она не только следила за соответствием
> >> декларации патча и его наложением, но могла бы также замечать, что
> >> патчи в виде файлов есть, а ни декларации,  ни наложения нет.
> > Может быть сделать соответствующую поддержку в gear?
> >
> > Например, можно реализовать директиву gear-rules declare-patches: yes,
> > при наличие которой при сборке пакета патчи последовательно, в порядке
> > следования diff'ов в gear-rules, подставляются в spec-файл (в таком
> > случае spec в gear является не чистым, а шаблоном для настоящего спека).
> >
> вот только у нас ещё остался архитектурно-независимый src.rpm.

Для них это не будет работать, а при сборке из gear в спеках сгенерённых
sourcerpms будут указаны все патчи.

-- 
   WBR,
   Vladimir D. Seleznev

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

[Anton V. Boyarshinov]

> > Я напоминаю, что начиная с rpm-build-4.0.4-alt133 поддерживается
> > директива %autopatch. Её использование удобно тем, что нет необходимости
> > следить за соответствием декларации патча (PatchN: fix.patch) и наличием
> > его применением (%patchN -p1). Я думаю, она хорошо подходит к данной
> > схеме в т.ч..
> >   
> 
> Вот хорошо бы было, если бы она не только следила за соответствием
> декларации патча и его наложением, но могла бы также замечать, что
> патчи в виде файлов есть, а ни декларации,  ни наложения нет.

Впрочем...

https://git.altlinux.org/people/kernelbot/packages/kernel-image.git?p=kernel-image.git;a=commitdiff;h=8a296f0cd123e2e75a3e5eef7a35a4d7bf3de3e9

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

[Anton V. Boyarshinov]

В Wed, 19 Jan 2022 13:31:16 +0300
"Vladimir D. Seleznev" <vseleznv@altlinux.org> пишет:

> > Вот хорошо бы было, если бы она не только следила за соответствием
> > декларации патча и его наложением, но могла бы также замечать, что
> > патчи в виде файлов есть, а ни декларации,  ни наложения нет.  
> 
> Может быть сделать соответствующую поддержку в gear?
> 
> Например, можно реализовать директиву gear-rules declare-patches: yes,
> при наличие которой при сборке пакета патчи последовательно, в порядке
> следования diff'ов в gear-rules, подставляются в spec-файл (в таком
> случае spec в gear является не чистым, а шаблоном для настоящего спека).

Может быть, но как оказалось, это можно нахакать и без поддержки в gear.

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

[Anton V. Boyarshinov]

В Wed, 19 Jan 2022 13:24:48 +0300
"Alexey V. Vissarionov" <gremlin@altlinux.org> пишет:

> 1. Накатывание патчей может быть условным - как правило %ifarch,
> но может быть и вообще любой %if

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

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

[Alexey V. Vissarionov]

On 2022-01-19 13:31:16 +0300, Vladimir D. Seleznev wrote:

 >> Вот хорошо бы было, если бы она не только следила за
 >> соответствием декларации патча и его наложением, но
 >> могла бы также замечать, что патчи в виде файлов есть,
 >> а ни декларации, ни наложения нет.
 > Может быть сделать соответствующую поддержку в gear?
 > Например, можно реализовать директиву gear-rules
 > declare-patches: yes, при наличие которой при сборке
 > пакета патчи последовательно, в порядке следования
 > diff'ов в gear-rules, подставляются в spec-файл (в таком
 > случае spec в gear является не чистым, а шаблоном для
 > настоящего спека).

Это могло бы быть оправданным, когда количество патчей
измеряется десятками, но такое количество изменений проще
(и правильнее) держать просто в гите.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

[Anton Farygin]

On 19.01.2022 13:48, Vladimir D. Seleznev wrote:
> On Wed, Jan 19, 2022 at 01:32:50PM +0300, Anton Farygin wrote:
>> On 19.01.2022 13:31, Vladimir D. Seleznev wrote:
>>> On Wed, Jan 19, 2022 at 12:56:52PM +0300, Anton V. Boyarshinov wrote:
>>>>>> С одной стороны, такая схема ощутимо более трудоёмка при сборке новой мажорной версии, но можно попробовать многое заскриптовать.
>>>>>> С другой стороны, есть и определённые удобства в плане поддержки ядер в разных репозиториях.
>>>>>> С третьей стороны, когда stable разъезжается с патчами, в старой схеме это видно на этапе мержа, а в новой -- на этапе сборки. Впрочем, тут есть и недостатки и достоинства.
>>>>>>
>>>>>> В общем, надо посмотреть.
>>>>> Я напоминаю, что начиная с rpm-build-4.0.4-alt133 поддерживается
>>>>> директива %autopatch. Её использование удобно тем, что нет необходимости
>>>>> следить за соответствием декларации патча (PatchN: fix.patch) и наличием
>>>>> его применением (%patchN -p1). Я думаю, она хорошо подходит к данной
>>>>> схеме в т.ч..
>>>>>
>>>> Вот хорошо бы было, если бы она не только следила за соответствием
>>>> декларации патча и его наложением, но могла бы также замечать, что
>>>> патчи в виде файлов есть, а ни декларации,  ни наложения нет.
>>> Может быть сделать соответствующую поддержку в gear?
>>>
>>> Например, можно реализовать директиву gear-rules declare-patches: yes,
>>> при наличие которой при сборке пакета патчи последовательно, в порядке
>>> следования diff'ов в gear-rules, подставляются в spec-файл (в таком
>>> случае spec в gear является не чистым, а шаблоном для настоящего спека).
>>>
>> вот только у нас ещё остался архитектурно-независимый src.rpm.
> Для них это не будет работать, а при сборке из gear в спеках сгенерённых
> sourcerpms будут указаны все патчи.
>
А как это поможет сделать %ifarch для патчей ?