krun - crun based OCI runtime using libkrun to run containerized programs in isolated KVM environments * https://github.com/libkrun/libkrun * https://github.com/containers/crun/blob/d2ae0aca4332721a9e52ceafe5b489e46e78769a/rpm/crun.spec#L15
Собрал тестовый таск https://packages.altlinux.org/ru/tasks/432170/ Если возражений не будет - отправлю в Сизиф через какое-то время.
libkrunfw.spec: %global kernel linux-6.12.91 ... Source1: %kernel.tar.xz А что будет после выхода нового ядра? Кстати, сейчас в Сизифе 6.12.108! И почему 6.12, а не 6.18, например? BuildRequires: gcc BuildRequires: make Не нужно, есть в сборочном окружении всегда. %description %summary Обычно ставится точка в конце, например, как 8 строчками ниже: %description devel %summary.
(Ответ для Andrew Vasilyev на комментарий #2) > libkrunfw.spec: > > %global kernel linux-6.12.91 > ... > Source1: %kernel.tar.xz > > А что будет после выхода нового ядра? Кстати, сейчас в Сизифе 6.12.108! > И почему 6.12, а не 6.18, например? > Версия ядра задается в апстриме: https://github.com/libkrun/libkrunfw/blob/4d5fc498b012424f92ccf791e625c62f3ea748f7/Makefile#L1
Остальное в libkrunfw поправил.
(Ответ для Maxim Slipenko на комментарий #3) > Версия ядра задается в апстриме: > https://github.com/libkrun/libkrunfw/blob/ > 4d5fc498b012424f92ccf791e625c62f3ea748f7/Makefile#L1 Тогда вопрос, как это будет работать с другими версиями ядра?
> libkrunfw.spec: > > %global kernel linux-6.12.91 > ... > Source1: %kernel.tar.xz > > А что будет после выхода нового ядра? Кстати, сейчас в Сизифе 6.12.108! > И почему 6.12, а не 6.18, например? Ничего. Как я понимаю, эти люди собирают собственное ядро с собственными патчами (из patches/) и собственными конфигами для запуска на нём krun-овых виртуалок. Какое при этом ядро испоьзуется на хосте не слишком важно. В то же время идея класть в git пожатый стосорокаметровый тарбол исходников ядра, безусловно, потрясает своей мощью. Я бы предложил всё-таки держать в гите распакованные исходники, и именно распакованными подсоввывать их Makefile'у. Хотя я не уверен, как сделать это достаточно элегантно. Схема, при которой ядро с известными уязвимостями собирается, заворачивается в библиотеку и в таком виде приезжает пользователю, даже не показывая свою версию, также вызывает некоторые вопросы. Однако в Федору такое пропустили[1], надо бы почитать почему. [1] https://lists.fedorahosted.org/archives/list/kernel@lists.fedoraproject.org/thread/2TMXPCE2VWF7USZA7OHQ3P2SBJAEGCSX/
(Ответ для Ivan A. Melnikov на комментарий #6) > > libkrunfw.spec: > > > > %global kernel linux-6.12.91 > > ... > > Source1: %kernel.tar.xz > > > > А что будет после выхода нового ядра? Кстати, сейчас в Сизифе 6.12.108! > > И почему 6.12, а не 6.18, например? > > Ничего. Как я понимаю, эти люди собирают собственное ядро с собственными > патчами (из patches/) и собственными конфигами для запуска на нём krun-овых > виртуалок. Какое при этом ядро испоьзуется на хосте не слишком важно. Да. В libkrunfw зашивается минимальное ядро, которое используется потом контейнерами. $ uname -rv 6.18.44-6.18-alt1 #1 SMP PREEMPT_DYNAMIC Sun Aug 9 21:09:46 UTC 2026 $ podman run --runtime=krun --rm -it alpine / # uname -rv 6.12.91 #1 SMP PREEMPT_DYNAMIC Mon Jun 1 16:28:39 CEST 2026 / # > В то же время идея класть в git пожатый стосорокаметровый тарбол исходников > ядра, безусловно, потрясает своей мощью. Я бы предложил всё-таки держать в > гите распакованные исходники, и именно распакованными подсоввывать их > Makefile'у. Хотя я не уверен, как сделать это достаточно элегантно. Может тогда просто через .gear/rules обратно запаковывать в tar.xz?
Собрал в Сизиф krunvm (вместе с libkrun и libkrunfw), в таске 432170 оставил только crun.
