On Mon, Mar 16, 2020 at 04:21:52PM +0300, Sergey Bolshakov wrote: > Между тем %{size} пакета перевалил за полгига и уменьшится врядли. > Дорогой cronbuild, ответь пожалуйста, как нам быть в этой ситуации ? > Может быть, стоит распилить наконец этот пакет Ой да. Вместе с ядром размер firmware-linux стал определяющим рост размера исошек некоторых регулярок/стартеркитов ещё на p8, когда я ими занимался. > или хотя бы сжать содержимое, предполагая наличие > FW_LOADER_COMPRESS во всех наших ядрах ? А вот этого в 4.9 на e2k пока не наблюдается, так что хорошо бы ручкой приделывать. Но явно стоит (вслед за модулями). -- ---- WBR, Michael Shigorin / http://altlinux.org ------ http://opennet.ru / http://anna-news.info
On Mon, Mar 16, 2020 at 03:15:10PM +0100, Konstantin Lepikhov wrote: > 140M firmware/netronome > 524M firmware > - выкинуть netronome и liquidio (не знаю что это такое) Судя по `git log --oneline netronome`, > - запаковать сетевые дрова отдельно сюда же, но ещё более отдельно -- не лень кому-то столько прошивок генерить вместо сопровождения одной на линейку... -- ---- WBR, Michael Shigorin / http://altlinux.org ------ http://opennet.ru / http://anna-news.info
On Tue, Mar 17, 2020 at 09:47:45AM +0300, Michael Shigorin wrote:
> On Mon, Mar 16, 2020 at 04:21:52PM +0300, Sergey Bolshakov wrote:
> > Между тем %{size} пакета перевалил за полгига и уменьшится врядли.
> > Дорогой cronbuild, ответь пожалуйста, как нам быть в этой ситуации ?
> > Может быть, стоит распилить наконец этот пакет
>
> Ой да. Вместе с ядром размер firmware-linux стал определяющим
> рост размера исошек некоторых регулярок/стартеркитов ещё на p8,
> когда я ими занимался.
>
> > или хотя бы сжать содержимое, предполагая наличие
> > FW_LOADER_COMPRESS во всех наших ядрах ?
>
> А вот этого в 4.9 на e2k пока не наблюдается,
> так что хорошо бы ручкой приделывать.
> Но явно стоит (вслед за модулями).
А на mipsel ещё долго будут 4.4, так что +1.
--
wbr,
iv m.
Michael Shigorin писал 17.3.20 9:47:
> On Mon, Mar 16, 2020 at 04:21:52PM +0300, Sergey Bolshakov wrote:
>> Между тем %{size} пакета перевалил за полгига и уменьшится врядли.
>> Дорогой cronbuild, ответь пожалуйста, как нам быть в этой ситуации ?
>> Может быть, стоит распилить наконец этот пакет
>
> Ой да. Вместе с ядром размер firmware-linux стал определяющим
> рост размера исошек некоторых регулярок/стартеркитов ещё на p8,
> когда я ими занимался.
>
>> или хотя бы сжать содержимое, предполагая наличие
>> FW_LOADER_COMPRESS во всех наших ядрах ?
>
> А вот этого в 4.9 на e2k пока не наблюдается,
> так что хорошо бы ручкой приделывать.
> Но явно стоит (вслед за модулями).
В пакете много одинаковых по содержимому файлов с разными названиями
(особенно в intel). Хорошо бы какой-то dedup применить, чтобы если не
симлинки, то хоть жёсткие ссылки сделать.
Статистика zpaq:
Исходный -> дедуплицированный -> сжатый (Мб)
539 -> 419 -> 107
--
С уважением,
Виталий Липатов,
ALT Linux Team
[-- Attachment #1: Type: text/plain, Size: 1923 bytes --] On Wed, 18 Mar 2020 02:42:54 +0300 Vitaly Lipatov wrote: > Michael Shigorin писал 17.3.20 9:47: > > On Mon, Mar 16, 2020 at 04:21:52PM +0300, Sergey Bolshakov wrote: > >> Между тем %{size} пакета перевалил за полгига и уменьшится врядли. > >> Дорогой cronbuild, ответь пожалуйста, как нам быть в этой ситуации ? > >> Может быть, стоит распилить наконец этот пакет > > > > Ой да. Вместе с ядром размер firmware-linux стал определяющим > > рост размера исошек некоторых регулярок/стартеркитов ещё на p8, > > когда я ими занимался. > > > >> или хотя бы сжать содержимое, предполагая наличие > >> FW_LOADER_COMPRESS во всех наших ядрах ? > > > > А вот этого в 4.9 на e2k пока не наблюдается, > > так что хорошо бы ручкой приделывать. > > Но явно стоит (вслед за модулями). > В пакете много одинаковых по содержимому файлов с разными названиями > (особенно в intel). Хорошо бы какой-то dedup применить, чтобы если не > симлинки, то хоть жёсткие ссылки сделать. > > Статистика zpaq: > Исходный -> дедуплицированный -> сжатый (Мб) > 539 -> 419 -> 107 Вы забыли указать время на сжатие и распаковку и потребление памяти. И это с каким-нибудь -m6, да? Тогда уже и paq8l -9 можно вспомнить. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
> > Вы забыли указать время на сжатие и распаковку и потребление памяти. > И это с каким-нибудь -m6, да? Время сжатия, в общем, не интересно, так как сжатие делается один раз при сборке пакета, а место они занимают -- у всех. > Тогда уже и paq8l -9 можно вспомнить. > > Best regards, > Andrew Savchenko
[-- Attachment #1: Type: text/plain, Size: 1659 bytes --] On Wed, 18 Mar 2020 10:34:13 +0300 Anton V. Boyarshinov wrote: > > > > > Вы забыли указать время на сжатие и распаковку и потребление памяти. > > И это с каким-нибудь -m6, да? > > Время сжатия, в общем, не интересно, так как сжатие делается один раз > при сборке пакета, а место они занимают -- у всех. Семейство алгоритмов PAQ отличается тем, что ресурсы для распаковки и сжатия там нужны примерно одни и те же, что по времени, что по памяти. Само сжатие при подходящих настройках на неспециальных данных может быть близко к пределу энтропии, но вот время… Не хотел бы я ждать, пока оно распакуется где-нибудь на слабом оборудовании (mips, riscv). На самом деле всё зависит от метода сжатия, если там -m 1, то жить можно, но сжатие будет хуже bzip2; с -m 5 придётся ждать долго: http://mattmahoney.net/dc/10gb.png (шкала по оси ординат логарифмическая, в то время как по оси абсцисс линейная) С -m 6 ждать придётся столько, что они даже показывать не стали. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
On Wed, Mar 18, 2020 at 02:42:54AM +0300, Vitaly Lipatov wrote: > Michael Shigorin писал 17.3.20 9:47: > > On Mon, Mar 16, 2020 at 04:21:52PM +0300, Sergey Bolshakov wrote: > > > Между тем %{size} пакета перевалил за полгига и уменьшится врядли. > > > Дорогой cronbuild, ответь пожалуйста, как нам быть в этой ситуации ? > > > Может быть, стоит распилить наконец этот пакет > > > > Ой да. Вместе с ядром размер firmware-linux стал определяющим > > рост размера исошек некоторых регулярок/стартеркитов ещё на p8, > > когда я ими занимался. > > > > > или хотя бы сжать содержимое, предполагая наличие > > > FW_LOADER_COMPRESS во всех наших ядрах ? > > > > А вот этого в 4.9 на e2k пока не наблюдается, > > так что хорошо бы ручкой приделывать. > > Но явно стоит (вслед за модулями). > В пакете много одинаковых по содержимому файлов с разными названиями > (особенно в intel). Хорошо бы какой-то dedup применить, чтобы если не > симлинки, то хоть жёсткие ссылки сделать. Кстати да. > Статистика zpaq: > Исходный -> дедуплицированный -> сжатый (Мб) > 539 -> 419 -> 107 У меня получилось поменьше, но всё равно стоит того: $ hardlink -nv /lib/firmware/ Directories 238 Objects 2541 IFREG 2179 Comparisons 401 Would link 282 Would save 26116096 -- wbr, iv m.
Andrey Savchenko писал 18.3.20 3:09:
...
>> Статистика zpaq:
>> Исходный -> дедуплицированный -> сжатый (Мб)
>> 539 -> 419 -> 107
>
> Вы забыли указать время на сжатие и распаковку и потребление памяти.
> И это с каким-нибудь -m6, да?
>
> Тогда уже и paq8l -9 можно вспомнить.
На всякий случай:
firmware-linux-20200302-alt1.src.rpm (md5:
746358dad84bd2c178a5bb2c48f04ab3) 93,6 МБ
firmware-linux-20200302-alt1.noarch.rpm (md5:
e466d74f46e8be6c6f09b99b18a58fa4) 96,6 МБ
--
С уважением,
Виталий Липатов,
ALT Linux Team
Здравствуйте. При проверке очередного задания для p9_e2k: Следующие пакеты будут ОБНОВЛЕНЫ: firmware-linux libnautilus libtbb make-initrd tbb-devel 5 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 0 не будет обновлено. Необходимо получить 0B/172MB архивов. После распаковки потребуется дополнительно 144MB дискового пространства. Кроме firmware-linux, остальное всё мелкое; понятно, что фирмварей много, но непонятно, откуда такая разница в занятом пространстве (это практически размер самого пакета firmware-linux, который давно уж худобою не отличается). Отсюда вопрос: кто-нибудь уже изучал возможность разумной порубки нынешней подборки фирмварей как минимум на "десктоп/сервер/сеть/встройка"? -- ---- WBR, Michael Shigorin / http://altlinux.org ------ http://opennet.ru / http://anna-news.info
On 2021-04-16 16:30:33 +0300, Michael Shigorin wrote: > Необходимо получить 0B/172MB архивов. > После распаковки потребуется дополнительно 144MB дискового > пространства. > [...] > Отсюда вопрос: кто-нибудь уже изучал возможность разумной > порубки нынешней подборки фирмварей Да. > как минимум на "десктоп/сервер/сеть/встройка"? А также по вендорам и архитектурам. Уже есть смысл делать эти наработки достоянием общественнности? -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
[-- Attachment #1: Type: text/plain, Size: 1861 bytes --] On Fri, Apr 16, 2021 at 04:30:33PM +0300, Michael Shigorin wrote: > Здравствуйте. > При проверке очередного задания для p9_e2k: > > Следующие пакеты будут ОБНОВЛЕНЫ: > firmware-linux libnautilus libtbb make-initrd tbb-devel > 5 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 0 не будет обновлено. > Необходимо получить 0B/172MB архивов. > После распаковки потребуется дополнительно 144MB дискового пространства. > > Кроме firmware-linux, остальное всё мелкое; понятно, что фирмварей > много, но непонятно, откуда такая разница в занятом пространстве > (это практически размер самого пакета firmware-linux, который > давно уж худобою не отличается). > > Отсюда вопрос: кто-нибудь уже изучал возможность разумной > порубки нынешней подборки фирмварей как минимум на > "десктоп/сервер/сеть/встройка"? Так себе классификация, потому что устройства по этим классам невозможно однозначно распределить — ну, кроме "сеть", и тут зуб давать не могу. Что для одного десктоп, то для другого сервер, а для третьего встройка. Лучше, наверное, разбить по вендорам (или просто крупных отселить)... [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
On 16.04.2021 16:41, Arseny Maslennikov wrote:
> On Fri, Apr 16, 2021 at 04:30:33PM +0300, Michael Shigorin wrote:
>> Здравствуйте.
>> При проверке очередного задания для p9_e2k:
>>
>> Следующие пакеты будут ОБНОВЛЕНЫ:
>> firmware-linux libnautilus libtbb make-initrd tbb-devel
>> 5 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 0 не будет обновлено.
>> Необходимо получить 0B/172MB архивов.
>> После распаковки потребуется дополнительно 144MB дискового пространства.
>>
>> Кроме firmware-linux, остальное всё мелкое; понятно, что фирмварей
>> много, но непонятно, откуда такая разница в занятом пространстве
>> (это практически размер самого пакета firmware-linux, который
>> давно уж худобою не отличается).
>>
>> Отсюда вопрос: кто-нибудь уже изучал возможность разумной
>> порубки нынешней подборки фирмварей как минимум на
>> "десктоп/сервер/сеть/встройка"?
> Так себе классификация, потому что устройства по этим классам невозможно
> однозначно распределить — ну, кроме "сеть", и тут зуб давать не могу.
> Что для одного десктоп, то для другого сервер, а для третьего встройка.
>
> Лучше, наверное, разбить по вендорам (или просто крупных отселить)...
А потом выяснится, что, например один вендор использует чипы другого.
Не занимайтесь ерундой.
On 2021-04-16 17:59:43 +0300, Anton Farygin wrote: >>> Необходимо получить 0B/172MB архивов. >>> После распаковки потребуется дополнительно 144MB дискового >>> пространства. >>> Отсюда вопрос: кто-нибудь уже изучал возможность разумной >>> порубки нынешней подборки фирмварей как минимум на >>> "десктоп/сервер/сеть/встройка"? >> Лучше, наверное, разбить по вендорам (или просто крупных >> отселить)... > А потом выяснится, что, например один вендор использует чипы > другого. Сходу вспоминаются только RALink и MediaTek. И это всего лишь повод объединить их в одном пакете. > Не занимайтесь ерундой. Других возражений нет? -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
On Fri, Apr 16, 2021 at 04:39:08PM +0300, Alexey V. Vissarionov wrote: > > Необходимо получить 0B/172MB архивов. После распаковки > > потребуется дополнительно 144MB дискового пространства. > > [...] > > Отсюда вопрос: кто-нибудь уже изучал возможность разумной > > порубки нынешней подборки фирмварей > Да. > > как минимум на "десктоп/сервер/сеть/встройка"? > А также по вендорам и архитектурам. > Уже есть смысл делать эти наработки достоянием общественнности? Ну как минимум покажи-то. :-) PS: "сеть" -- это в смысле фирмварей для мелланоксовских свичей, например, которые вряд ли понадобятся на малинке. -- ---- WBR, Michael Shigorin / http://altlinux.org ------ http://opennet.ru / http://anna-news.info
On 16.04.2021 18:15, Alexey V. Vissarionov wrote:
> On 2021-04-16 17:59:43 +0300, Anton Farygin wrote:
> >>> Необходимо получить 0B/172MB архивов.
> >>> После распаковки потребуется дополнительно 144MB дискового
> >>> пространства.
> >>> Отсюда вопрос: кто-нибудь уже изучал возможность разумной
> >>> порубки нынешней подборки фирмварей как минимум на
> >>> "десктоп/сервер/сеть/встройка"?
> >> Лучше, наверное, разбить по вендорам (или просто крупных
> >> отселить)...
> > А потом выяснится, что, например один вендор использует чипы
> > другого.
>
> Сходу вспоминаются только RALink и MediaTek. И это всего лишь
> повод объединить их в одном пакете.
>
То, что сложность сопровождения растёт на порядок - никого не беспокоит ?
Например, нужна будет утилита, которая для используемого железа
установит нужные firmware.
On Sat, Apr 17, 2021 at 10:05:07AM +0300, Anton Farygin wrote: > То, что сложность сопровождения растёт на порядок - никого не беспокоит ? О том и спрашивал, по сути. > Например, нужна будет утилита, которая для используемого железа > установит нужные firmware. Ну не настолько всё-таки -- предполагается, что в десктопный дистрибутив не надо пихать всякие qla* и тому подобное, а в серверный -- amdgpu* со товарищи. -- ---- WBR, Michael Shigorin / http://altlinux.org ------ http://opennet.ru / http://anna-news.info
On 17.04.2021 10:14, Michael Shigorin wrote:
> On Sat, Apr 17, 2021 at 10:05:07AM +0300, Anton Farygin wrote:
>> То, что сложность сопровождения растёт на порядок - никого не беспокоит ?
> О том и спрашивал, по сути.
>
>> Например, нужна будет утилита, которая для используемого железа
>> установит нужные firmware.
> Ну не настолько всё-таки -- предполагается, что в десктопный
> дистрибутив не надо пихать всякие qla* и тому подобное,
> а в серверный -- amdgpu* со товарищи.
>
Ну почему-же ? Сейчас сервера с GPU это нормальное и даже полезное
явление, если хватило денег на их приобретение.
А qla в десктопе тоже запросто могут оказаться, кто же запретит их
поставить ?
16.04.2021 16:30, Michael Shigorin пишет:
> Здравствуйте.
> При проверке очередного задания для p9_e2k:
>
> Следующие пакеты будут ОБНОВЛЕНЫ:
> firmware-linux libnautilus libtbb make-initrd tbb-devel
> 5 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 0 не будет обновлено.
> Необходимо получить 0B/172MB архивов.
> После распаковки потребуется дополнительно 144MB дискового пространства.
>
> Кроме firmware-linux, остальное всё мелкое; понятно, что фирмварей
> много, но непонятно, откуда такая разница в занятом пространстве
> (это практически размер самого пакета firmware-linux, который
> давно уж худобою не отличается).
>
> Отсюда вопрос: кто-нибудь уже изучал возможность разумной
> порубки нынешней подборки фирмварей как минимум на
> "десктоп/сервер/сеть/встройка"?
Когда в пакете linux-firmware применяется разбивка на подпакеты и внезапнго появляется НЕЧТО от, допустим, Intel, но непонятно, для каких именно устройств, а у тебя оно появилось раньше, чем, например, а Fedora и позаимствовать готовое решение неоткуда, приходится потратить время впустую на обдумывание и все равно почти на обум засунуть в какой-нибудь подпакет, а потом один фиг мета-пакет тащит все подпакеты на большинство установо.
Озвученная Арсением идея разбивать просто по вендорам мне кажется весьма здравой: разделение в целом не имеет смысла, но позволяет при необходимости уменьшить суммарный вес фирмварей. Однако вендоров там многовато разных...
On Sat, Apr 17, 2021 at 10:05:07AM +0300, Anton Farygin wrote:
> On 16.04.2021 18:15, Alexey V. Vissarionov wrote:
> > On 2021-04-16 17:59:43 +0300, Anton Farygin wrote:
> > >>> Необходимо получить 0B/172MB архивов.
> > >>> После распаковки потребуется дополнительно 144MB дискового
> > >>> пространства.
> > >>> Отсюда вопрос: кто-нибудь уже изучал возможность разумной
> > >>> порубки нынешней подборки фирмварей как минимум на
> > >>> "десктоп/сервер/сеть/встройка"?
> > >> Лучше, наверное, разбить по вендорам (или просто крупных
> > >> отселить)...
> > > А потом выяснится, что, например один вендор использует чипы
> > > другого.
> >
> > Сходу вспоминаются только RALink и MediaTek. И это всего лишь
> > повод объединить их в одном пакете.
> >
> То, что сложность сопровождения растёт на порядок - никого не беспокоит ?
>
> Например, нужна будет утилита, которая для используемого железа установит
> нужные firmware.
Это не так сложно сделать.
12 лет назад я делал hardware-search. Это был PoC решения, которое
определяло какие пакеты с модулями ядра нужно _поставить_ для поддержки
локального железа.
В модулях ядра есть информация и о firmware. Её можно также искать.
--
Rgrds, legion
On 17.04.2021 13:13, Alexey Gladkov wrote:
> On Sat, Apr 17, 2021 at 10:05:07AM +0300, Anton Farygin wrote:
>> On 16.04.2021 18:15, Alexey V. Vissarionov wrote:
>>> On 2021-04-16 17:59:43 +0300, Anton Farygin wrote:
>>> >>> Необходимо получить 0B/172MB архивов.
>>> >>> После распаковки потребуется дополнительно 144MB дискового
>>> >>> пространства.
>>> >>> Отсюда вопрос: кто-нибудь уже изучал возможность разумной
>>> >>> порубки нынешней подборки фирмварей как минимум на
>>> >>> "десктоп/сервер/сеть/встройка"?
>>> >> Лучше, наверное, разбить по вендорам (или просто крупных
>>> >> отселить)...
>>> > А потом выяснится, что, например один вендор использует чипы
>>> > другого.
>>>
>>> Сходу вспоминаются только RALink и MediaTek. И это всего лишь
>>> повод объединить их в одном пакете.
>>>
>> То, что сложность сопровождения растёт на порядок - никого не беспокоит ?
>>
>> Например, нужна будет утилита, которая для используемого железа установит
>> нужные firmware.
> Это не так сложно сделать.
>
> 12 лет назад я делал hardware-search. Это был PoC решения, которое
> определяло какие пакеты с модулями ядра нужно _поставить_ для поддержки
> локального железа.
>
> В модулях ядра есть информация и о firmware. Её можно также искать.
Можно, но проблема в том, что если у тебя на диске нет модулей, а они
нужны для того, что бы поставить систему (получить доступ к диску) или
получить графику или получить сеть, то есть вероятность что придётся
качать с сети и копировать на флешке с помощью отдельной машины.
А выигрываем мы всего-лишь 170 мегабайт.
[-- Attachment #1: Type: text/plain, Size: 3892 bytes --] On Sat, 17 Apr 2021 22:56:09 +0300 Anton Farygin wrote: > On 17.04.2021 13:13, Alexey Gladkov wrote: > > On Sat, Apr 17, 2021 at 10:05:07AM +0300, Anton Farygin wrote: > >> On 16.04.2021 18:15, Alexey V. Vissarionov wrote: > >>> On 2021-04-16 17:59:43 +0300, Anton Farygin wrote: > >>> >>> Необходимо получить 0B/172MB архивов. > >>> >>> После распаковки потребуется дополнительно 144MB дискового > >>> >>> пространства. > >>> >>> Отсюда вопрос: кто-нибудь уже изучал возможность разумной > >>> >>> порубки нынешней подборки фирмварей как минимум на > >>> >>> "десктоп/сервер/сеть/встройка"? > >>> >> Лучше, наверное, разбить по вендорам (или просто крупных > >>> >> отселить)... > >>> > А потом выяснится, что, например один вендор использует чипы > >>> > другого. > >>> > >>> Сходу вспоминаются только RALink и MediaTek. И это всего лишь > >>> повод объединить их в одном пакете. > >>> > >> То, что сложность сопровождения растёт на порядок - никого не беспокоит ? > >> > >> Например, нужна будет утилита, которая для используемого железа установит > >> нужные firmware. > > Это не так сложно сделать. > > > > 12 лет назад я делал hardware-search. Это был PoC решения, которое > > определяло какие пакеты с модулями ядра нужно _поставить_ для поддержки > > локального железа. > > > > В модулях ядра есть информация и о firmware. Её можно также искать. > > Можно, но проблема в том, что если у тебя на диске нет модулей, а они > нужны для того, что бы поставить систему (получить доступ к диску) или > получить графику или получить сеть, то есть вероятность что придётся > качать с сети и копировать на флешке с помощью отдельной машины. > > А выигрываем мы всего-лишь 170 мегабайт. Согласен. Здесь овчинка выделки не стоит. У нас дистрибутивы и так *не* позиционируются на минимализм в потреблении ресурсов, особенно места на диске. Напомнило мне историю с terminfo, где мне приходилось страдать и на всех новых хостах ставить terminfo-extra (что не всегда возможно, т.к. нужен root), пока не уговорил мейнтенеров пакета переместить нужные мне screen-256color-* из extra в основной пакет. Здесь у отдельных пользователей будет аналогично, только намного хуже, если что необычное, или просто не предусмотренное мейнтенером пакета не попадёт в нужный набор firmware*. Хуже потому, что не заведутся диски или сеть, или графика, или ещё что важное. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
On Sat, Apr 17, 2021 at 10:56:09PM +0300, Anton Farygin wrote:
> > > Например, нужна будет утилита, которая для используемого железа установит
> > > нужные firmware.
> > Это не так сложно сделать.
> >
> > 12 лет назад я делал hardware-search. Это был PoC решения, которое
> > определяло какие пакеты с модулями ядра нужно _поставить_ для поддержки
> > локального железа.
> >
> > В модулях ядра есть информация и о firmware. Её можно также искать.
>
> Можно, но проблема в том, что если у тебя на диске нет модулей, а они нужны
> для того, что бы поставить систему (получить доступ к диску) или получить
> графику или получить сеть, то есть вероятность что придётся качать с сети и
> копировать на флешке с помощью отдельной машины.
>
>
> А выигрываем мы всего-лишь 170 мегабайт.
С этим безусловно согласен. Я лишь указал на техническую возможность.
Распиливание firmware это больше экономия на спичках.
--
Rgrds, legion
Добрый день! On 16.04.2021 17:30, Michael Shigorin wrote: > Отсюда вопрос: кто-нибудь уже изучал возможность разумной > порубки нынешней подборки фирмварей как минимум на > "десктоп/сервер/сеть/встройка"? В Debian "порубили" на free/non-free. И решили не включать в установочные образы "несвободное". То есть чуть менее, чем всё. В результате во время установки нужно по черному экрану догадаться, какого именно firmware не хватило. Больше подробностей можно найти здесь: https://lwn.net/Articles/843172 Давайте не будем повторять чужие ошибки. Тем более, что предложенная классификация очень расплывчатая. BFK 3.1 -- это "сервер" или "встройка"? А если в PCI-e слот вставить raid контроллер? А udoo x86 ii -- это "сервер", "встройка", или "десктоп"? А USB ethernet/WiFi/bluetooth адаптеры? А для экономии места предлагаю распотрошить locales: $ du -sh /usr/share/locale/ 404M /usr/share/locale/ $ du -sh /lib/firmware/ 336M /lib/firmware/ И модули ядра пожать (СONFIG_MODULE_COMPRESS=Y, CONFIG_MODULE_COMPRESS_XZ=Y) $ du -sh /lib/modules/5.10.29-un-def-alt2 256M /lib/modules/5.10.29-un-def-alt2
On Sun, 18 Apr 2021 13:41:24 +0400 Alexey Sheplyakov <asheplyakov@basealt.ru> wrote: > Добрый день! > > On 16.04.2021 17:30, Michael Shigorin wrote: > > > Отсюда вопрос: кто-нибудь уже изучал возможность разумной > > порубки нынешней подборки фирмварей как минимум на > > "десктоп/сервер/сеть/встройка"? > > В Debian "порубили" на free/non-free. И решили не включать в > установочные образы "несвободное". То есть чуть менее, чем всё. В > результате во время установки нужно по черному экрану догадаться, > какого именно firmware не хватило. Больше подробностей можно найти > здесь: > > https://lwn.net/Articles/843172 > > Давайте не будем повторять чужие ошибки. > > Тем более, что предложенная классификация очень расплывчатая. BFK 3.1 > -- это "сервер" или "встройка"? А если в PCI-e слот вставить raid > контроллер? А udoo x86 ii -- это "сервер", "встройка", или "десктоп"? > > А USB ethernet/WiFi/bluetooth адаптеры? > > > А для экономии места предлагаю распотрошить locales: > > $ du -sh /usr/share/locale/ > 404M /usr/share/locale/ > $ du -sh /lib/firmware/ > 336M /lib/firmware/ > > И модули ядра пожать (СONFIG_MODULE_COMPRESS=Y, > CONFIG_MODULE_COMPRESS_XZ=Y) $ du -sh /lib/modules/5.10.29-un-def-alt2 > 256M /lib/modules/5.10.29-un-def-alt2 НЕТ. этого по умолчанию не надо. > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel
On 18.04.2021 14:20, Denis Medvedev wrote: > On Sun, 18 Apr 2021 13:41:24 +0400 >> И модули ядра пожать (СONFIG_MODULE_COMPRESS=Y, >> CONFIG_MODULE_COMPRESS_XZ=Y) $ du -sh /lib/modules/5.10.29-un-def-alt2 >> 256M /lib/modules/5.10.29-un-def-alt2 > НЕТ. этого по умолчанию не надо. А почему?
On Sun, Apr 18, 2021 at 01:41:24PM +0400, Alexey Sheplyakov wrote: > On 16.04.2021 17:30, Michael Shigorin wrote: > > > Отсюда вопрос: кто-нибудь уже изучал возможность разумной > > порубки нынешней подборки фирмварей как минимум на > > "десктоп/сервер/сеть/встройка"? > > В Debian "порубили" на free/non-free. В Debian, для начала, все пакеты давно разделили на free/non-free. [...] > А для экономии места предлагаю распотрошить locales: > > $ du -sh /usr/share/locale/ > 404M /usr/share/locale/ $ du -sh /usr/share/locale/ 0 /usr/share/locale/ Дальше, кажется, потрошить уже некуда. -- ldv
On 18.04.2021 15:44, Dmitry V. Levin wrote: >> А для экономии места предлагаю распотрошить locales: >> >> $ du -sh /usr/share/locale/ >> 404M /usr/share/locale/ > > $ du -sh /usr/share/locale/ > 0 /usr/share/locale/ Так останется только С. А хочется еще оставить и ru_RU.UTF-8. > Дальше, кажется, потрошить уже некуда. Есть: glibc-locale-с, glibc-locale-ru, и т.п. А ответ на вопрос "на каком языке программы должны выводить сообщения" не вызывает никаких затруднений.
On Sun, Apr 18, 2021 at 04:59:29PM +0400, Alexey Sheplyakov wrote: > On 18.04.2021 15:44, Dmitry V. Levin wrote: > > >> А для экономии места предлагаю распотрошить locales: > >> > >> $ du -sh /usr/share/locale/ > >> 404M /usr/share/locale/ > > > > $ du -sh /usr/share/locale/ > > 0 /usr/share/locale/ > > Так останется только С. А хочется еще оставить и ru_RU.UTF-8. Можно установить другое значение %_install_langs. > > Дальше, кажется, потрошить уже некуда. > > Есть: glibc-locale-с, glibc-locale-ru, и т.п. Это /usr/lib/locale/, а не /usr/share/locale/. %_install_langs распространяется и на /usr/lib/locale/. -- ldv
On 16.04.2021 16:30, Michael Shigorin wrote:
> Здравствуйте.
> При проверке очередного задания для p9_e2k:
>
> Следующие пакеты будут ОБНОВЛЕНЫ:
> firmware-linux libnautilus libtbb make-initrd tbb-devel
> 5 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 0 не будет обновлено.
> Необходимо получить 0B/172MB архивов.
> После распаковки потребуется дополнительно 144MB дискового пространства.
>
> Кроме firmware-linux, остальное всё мелкое; понятно, что фирмварей
> много, но непонятно, откуда такая разница в занятом пространстве
> (это практически размер самого пакета firmware-linux, который
> давно уж худобою не отличается).
>
> Отсюда вопрос: кто-нибудь уже изучал возможность разумной
> порубки нынешней подборки фирмварей как минимум на
> "десктоп/сервер/сеть/встройка"?
>
По итогам обсуждения, мне кажется что разумно было бы не рубить пакет, а
написать скрипт, который будет вычислять и удалять неиспользуемое.
Если это кому-то надо.
> > Кроме firmware-linux, остальное всё мелкое; понятно, что фирмварей
> > много, но непонятно, откуда такая разница в занятом пространстве
> > (это практически размер самого пакета firmware-linux, который
> > давно уж худобою не отличается).
> >
> > Отсюда вопрос: кто-нибудь уже изучал возможность разумной
> > порубки нынешней подборки фирмварей как минимум на
> > "десктоп/сервер/сеть/встройка"?
> >
> По итогам обсуждения, мне кажется что разумно было бы не рубить пакет, а
> написать скрипт, который будет вычислять и удалять неиспользуемое.
>
> Если это кому-то надо.
Это мало поможет в ситуации "не могу поставить, потому что мало места"
On 19.04.2021 10:50, Anton V. Boyarshinov wrote:
>>> Кроме firmware-linux, остальное всё мелкое; понятно, что фирмварей
>>> много, но непонятно, откуда такая разница в занятом пространстве
>>> (это практически размер самого пакета firmware-linux, который
>>> давно уж худобою не отличается).
>>>
>>> Отсюда вопрос: кто-нибудь уже изучал возможность разумной
>>> порубки нынешней подборки фирмварей как минимум на
>>> "десктоп/сервер/сеть/встройка"?
>>>
>> По итогам обсуждения, мне кажется что разумно было бы не рубить пакет, а
>> написать скрипт, который будет вычислять и удалять неиспользуемое.
>>
>> Если это кому-то надо.
> Это мало поможет в ситуации "не могу поставить, потому что мало места"
Если не может поставить, потому что мало места, то и не надо ставить
(т.е. - врятли там где нужен firmware места будет действительно
настолько мало).
On Mon, Apr 19, 2021 at 11:50:55AM +0300, Anton Farygin wrote: > > Это мало поможет в ситуации "не могу поставить, потому что мало места" > Если не может поставить, потому что мало места, то и не надо > ставить (т.е. - врятли там где нужен firmware места будет > действительно настолько мало). Собственно, хотел обратить внимание на то, что firmware-linux в развёрнутом виде занимает уже почти полгигабайта, обновление -- сейчас 137М. Понятно, что отдельно вроде не беда, но множится на кол-во выпускаемых нами образов, загружаемых пользователями обновлений и т.д. -- ---- WBR, Michael Shigorin / http://altlinux.org ------ http://opennet.ru / http://anna-news.info
[-- Attachment #1.1: Type: text/plain, Size: 1451 bytes --] 19.04.2021 12:39, Michael Shigorin пишет: > On Mon, Apr 19, 2021 at 11:50:55AM +0300, Anton Farygin wrote: >>> Это мало поможет в ситуации "не могу поставить, потому что мало места" >> Если не может поставить, потому что мало места, то и не надо >> ставить (т.е. - врятли там где нужен firmware места будет >> действительно настолько мало). > > Собственно, хотел обратить внимание на то, что firmware-linux > в развёрнутом виде занимает уже почти полгигабайта, обновление > -- сейчас 137М. Понятно, что отдельно вроде не беда, но множится > на кол-во выпускаемых нами образов, загружаемых пользователями > обновлений и т.д. > Миша, хватит высасывать проблемы из пальца. Не хватает места, купи диск побольше; мало интернета, поменяй тариф и не занимайся фигней. То же самое касается kernel-image, один такой молодой горячий попилил, теперь все страдают -- Valery V. Inozemtsev [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --]
On Mon, Apr 19, 2021 at 12:54:43PM +0300, Валерий Иноземцев wrote: > Миша, хватит высасывать проблемы из пальца. Не хватает места, > купи диск побольше; мало интернета, поменяй тариф и не > занимайся фигней. То же самое касается kernel-image, один > такой молодой горячий попилил, теперь все страдают Ты сейчас озвучил подход редхата двадцатилетней давности, от которого уже отказался даже сам редхат. -- ---- WBR, Michael Shigorin / http://altlinux.org ------ http://opennet.ru / http://anna-news.info
[-- Attachment #1.1: Type: text/plain, Size: 1288 bytes --] 19.04.2021 13:07, Michael Shigorin пишет: > On Mon, Apr 19, 2021 at 12:54:43PM +0300, Валерий Иноземцев wrote: >> Миша, хватит высасывать проблемы из пальца. Не хватает места, >> купи диск побольше; мало интернета, поменяй тариф и не >> занимайся фигней. То же самое касается kernel-image, один >> такой молодой горячий попилил, теперь все страдают > > Ты сейчас озвучил подход редхата двадцатилетней давности, > от которого уже отказался даже сам редхат. > ну значит редхат давно обмайкросовился, а я просто озвучил свою непоколебимую позицию по данному вопросу. по мне лучше воткнул железку и она работает, а не сидеть и ждать "обновление программного обеспечения для коврика мыши" (в нашем случае эта железка превращается в тыкву) -- Valery V. Inozemtsev [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --]
Добрый день!
On 19.04.2021 13:39, Michael Shigorin wrote:
> Собственно, хотел обратить внимание на то, что firmware-linux
> в развёрнутом виде занимает уже почти полгигабайта, обновление
> -- сейчас 137М. Понятно, что отдельно вроде не беда, но множится
> на кол-во выпускаемых нами образов, загружаемых пользователями
> обновлений и т.д.
Жирный стал firmware, никто не спорит (но это даже радует - значит,
всё больше оборудования, которое в Linux работает "из коробки").
Но в образы [1] даже после гипотетического разбиения придется включать
все firmware пакеты (невозможно заранее угадать, на каком оборудовании
будет работать ОС).
Для пользовтеля проблема - когда после обновления черный экран, или сеть
отвалилась (а сейчас полно Ethernet адаптеров, которым нужен firmware).
А скачать 100/200 МБ из интернета - вообще никто не заметит.
[1] предназначенные для запуска на реальном оборудовании, а не
в контейнерах или виртуальных машинах
>>>>> "Denis" == Denis Medvedev <nbr-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes: > On Sun, 18 Apr 2021 13:41:24 +0400 > Alexey Sheplyakov <asheplyakov@basealt.ru> wrote: >> Добрый день! >> >> On 16.04.2021 17:30, Michael Shigorin wrote: >> >> > Отсюда вопрос: кто-нибудь уже изучал возможность разумной >> > порубки нынешней подборки фирмварей как минимум на >> > "десктоп/сервер/сеть/встройка"? >> >> В Debian "порубили" на free/non-free. И решили не включать в >> установочные образы "несвободное". То есть чуть менее, чем всё. В >> результате во время установки нужно по черному экрану догадаться, >> какого именно firmware не хватило. Больше подробностей можно найти >> здесь: >> >> https://lwn.net/Articles/843172 >> >> Давайте не будем повторять чужие ошибки. >> >> Тем более, что предложенная классификация очень расплывчатая. BFK 3.1 >> -- это "сервер" или "встройка"? А если в PCI-e слот вставить raid >> контроллер? А udoo x86 ii -- это "сервер", "встройка", или "десктоп"? >> >> А USB ethernet/WiFi/bluetooth адаптеры? >> >> >> А для экономии места предлагаю распотрошить locales: >> >> $ du -sh /usr/share/locale/ >> 404M /usr/share/locale/ >> $ du -sh /lib/firmware/ >> 336M /lib/firmware/ >> >> И модули ядра пожать (СONFIG_MODULE_COMPRESS=Y, >> CONFIG_MODULE_COMPRESS_XZ=Y) $ du -sh /lib/modules/5.10.29-un-def-alt2 >> 256M /lib/modules/5.10.29-un-def-alt2 > НЕТ. этого по умолчанию не надо. Напомню, что точно так же можно пожать и firmware. --
[-- Attachment #1.1: Type: text/plain, Size: 677 bytes --] > >> И модули ядра пожать (СONFIG_MODULE_COMPRESS=Y, > >> CONFIG_MODULE_COMPRESS_XZ=Y) $ du -sh /lib/modules/5.10.29-un-def-alt2 > >> 256M /lib/modules/5.10.29-un-def-alt2 > > НЕТ. этого по умолчанию не надо. > > Напомню, что точно так же можно пожать и firmware. любой старьёвщик скажет что так делать не надо ибо грузиться оно будет ну очень медленно, а в непожатом виде оно занимает космические 473Mb и тут только резать -- Valery V. Inozemtsev [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --]
>>>>> "Валерий" == Валерий Иноземцев <shrek-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
>> >> И модули ядра пожать (СONFIG_MODULE_COMPRESS=Y,
>> >> CONFIG_MODULE_COMPRESS_XZ=Y) $ du -sh /lib/modules/5.10.29-un-def-alt2
>> >> 256M /lib/modules/5.10.29-un-def-alt2
>> > НЕТ. этого по умолчанию не надо.
>>
>> Напомню, что точно так же можно пожать и firmware.
> любой старьёвщик скажет что так делать не надо ибо грузиться оно будет
> ну очень медленно, а в непожатом виде оно занимает космические 473Mb и
> тут только резать
Можно завести дополнительно firmware-linux-compressed, например.
--
[-- Attachment #1.1: Type: text/plain, Size: 1166 bytes --] 19.04.2021 13:47, Sergey Bolshakov пишет: >>>>>> "Валерий" == Валерий Иноземцев <shrek-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes: > > >> >> И модули ядра пожать (СONFIG_MODULE_COMPRESS=Y, > >> >> CONFIG_MODULE_COMPRESS_XZ=Y) $ du -sh /lib/modules/5.10.29-un-def-alt2 > >> >> 256M /lib/modules/5.10.29-un-def-alt2 > >> > НЕТ. этого по умолчанию не надо. > >> > >> Напомню, что точно так же можно пожать и firmware. > > > любой старьёвщик скажет что так делать не надо ибо грузиться оно будет > > ну очень медленно, а в непожатом виде оно занимает космические 473Mb и > > тут только резать > > Можно завести дополнительно firmware-linux-compressed, например. > это была эрония :-) а про firmware-linux-compressed ты зря сказал. эти резатели так дойдут и до kernel-image-compressed -- Valery V. Inozemtsev [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --]
On 19.04.2021 14:44, Валерий Иноземцев wrote: >> >> И модули ядра пожать (СONFIG_MODULE_COMPRESS=Y, >> >> CONFIG_MODULE_COMPRESS_XZ=Y) $ du -sh /lib/modules/5.10.29-un-def-alt2 >> >> 256M /lib/modules/5.10.29-un-def-alt2 >> > НЕТ. этого по умолчанию не надо. >> >> Напомню, что точно так же можно пожать и firmware. Можно, но многие блобы и так сжатые. > любой старьёвщик скажет что так делать не надо ибо грузиться оно будет > ну очень медленно, А bzImage зачем придумали? А зачем у u-boot есть stage2 (который обычно в сжатом виде на устройство прошивается)? А зачем OpenWRT rootfs в sqaushfs пакует? Может, быстрее прочитать сжатый файл с медленного устройства (SPI, MMC, жесткого диска) в DRAM, и там его распаковать и запустить? Да не, не может быть! Это мировой заговор, чтоб всё медленно работало! (На всякий случай замечу, что это сарказм).
19.04.2021 13:07, Michael Shigorin пишет:
> On Mon, Apr 19, 2021 at 12:54:43PM +0300, Валерий Иноземцев wrote:
>> Миша, хватит высасывать проблемы из пальца. Не хватает места,
>> купи диск побольше; мало интернета, поменяй тариф и не
>> занимайся фигней. То же самое касается kernel-image, один
>> такой молодой горячий попилил, теперь все страдают
> Ты сейчас озвучил подход редхата двадцатилетней давности,
> от которого уже отказался даже сам редхат.
Можно же и попилить, и сделать мета-пакет firmware-linux с зависимостями
на все остальные firmware-linux-*. Но остаётся вопрос: по какому
принципу распиливать? Ни один из озвученных вариантов не показался мне
достаточно обоснованным. Я бы предложил два уровня мета-пакетов с
мелкозернистым распиливанием по сериям с общими прошивками, посредине --
мета-пакеты, которые будут объединять все типовые классы:
firmware-linux-fc, firmware-linux-amdgpu, firmware-linux-wireless, ...
--
Best regards,
Leonid Krivoshein.
[-- Attachment #1: Type: text/plain, Size: 2398 bytes --] On Wed, 21 Apr 2021 00:20:52 +0300 Leonid Krivoshein wrote: > > 19.04.2021 13:07, Michael Shigorin пишет: > > On Mon, Apr 19, 2021 at 12:54:43PM +0300, Валерий Иноземцев wrote: > >> Миша, хватит высасывать проблемы из пальца. Не хватает места, > >> купи диск побольше; мало интернета, поменяй тариф и не > >> занимайся фигней. То же самое касается kernel-image, один > >> такой молодой горячий попилил, теперь все страдают > > Ты сейчас озвучил подход редхата двадцатилетней давности, > > от которого уже отказался даже сам редхат. > > Можно же и попилить, и сделать мета-пакет firmware-linux с зависимостями > на все остальные firmware-linux-*. Но остаётся вопрос: по какому > принципу распиливать? Ни один из озвученных вариантов не показался мне > достаточно обоснованным. Я бы предложил два уровня мета-пакетов с > мелкозернистым распиливанием по сериям с общими прошивками, посредине -- > мета-пакеты, которые будут объединять все типовые классы: > firmware-linux-fc, firmware-linux-amdgpu, firmware-linux-wireless, ... Главный вопрос в том, не как можно разделить, а как это будет сделано на системе конечного пользователя, в первую очередь при установке и обновлениях. Если у пользователя не заработает или перестанет работать оборудование, потому что кто-то решил 100 MB сэкономить — то это не дело. А если сохранять весь firmware в установочных образах и при обновлениях, то не вижу смысла разделения на подпакеты. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
21.04.2021 10:12, Andrey Savchenko пишет:
> On Wed, 21 Apr 2021 00:20:52 +0300 Leonid Krivoshein wrote:
>> 19.04.2021 13:07, Michael Shigorin пишет:
>>> On Mon, Apr 19, 2021 at 12:54:43PM +0300, Валерий Иноземцев wrote:
>>>> Миша, хватит высасывать проблемы из пальца. Не хватает места,
>>>> купи диск побольше; мало интернета, поменяй тариф и не
>>>> занимайся фигней. То же самое касается kernel-image, один
>>>> такой молодой горячий попилил, теперь все страдают
>>> Ты сейчас озвучил подход редхата двадцатилетней давности,
>>> от которого уже отказался даже сам редхат.
>> Можно же и попилить, и сделать мета-пакет firmware-linux с зависимостями
>> на все остальные firmware-linux-*. Но остаётся вопрос: по какому
>> принципу распиливать? Ни один из озвученных вариантов не показался мне
>> достаточно обоснованным. Я бы предложил два уровня мета-пакетов с
>> мелкозернистым распиливанием по сериям с общими прошивками, посредине --
>> мета-пакеты, которые будут объединять все типовые классы:
>> firmware-linux-fc, firmware-linux-amdgpu, firmware-linux-wireless, ...
> Главный вопрос в том, не как можно разделить, а как это будет
> сделано на системе конечного пользователя, в первую очередь при
> установке и обновлениях. Если у пользователя не заработает или
> перестанет работать оборудование, потому что кто-то решил 100 MB
> сэкономить — то это не дело. А если сохранять весь firmware
> в установочных образах и при обновлениях, то не вижу смысла
> разделения на подпакеты.
Смысл есть, но не на под-пакеты, а на отдельные пакеты.
Возьмём установочный образ LiveCD, где прошивки попадают в образ initrd
для загрузки системы локально с ISO-образа. В этом случае мало какие
прошивки требуются. Для специализированных сборок это возможность
положить только нужное.
В конечную систему в общем случае должен попадать firmware-linux со
всеми зависимостями. На ВиКи можно описать способ "зачистки" -- apt-get
mark <нужное> && apt-get remove firmware-linux && apt-get autoremove.
Классы (подборки или второй уровень мета-пакетов) может быть полезен при
создании универсальных загрузочных образов под конкретные цели, когда мы
точно знаем, что нужно, а что нет по классам (например, когда точно не
требуется поддержка DVB), при этом не можем заранее знать, какое именно
железо там окажется.
Все мета-пакеты (1-й и 2-й уровни) можно держать в одном исходном SRPM
вместе со скриптами, предназначенными для автоматизации сборки
мета-пакетов 2-го уровня и остальных пакетов с конкретными прошивками и
видимо персональной нумерацией по git-тагам. В противном случае распил
не будет иметь большого смысла, если при обновлении чего-то одного, у
конечного пользователя будут обновляться все firmware-linux-*.
--
Best regards,
Leonid Krivoshein.
On 21.04.2021 11:03, Leonid Krivoshein wrote:
>
> Возьмём установочный образ LiveCD, где прошивки попадают в образ
> initrd для загрузки системы локально с ISO-образа. В этом случае мало
> какие прошивки требуются. Для специализированных сборок это
> возможность положить только нужное.
Почему мало какие ?
21.04.2021 11:20, Anton Farygin пишет:
> On 21.04.2021 11:03, Leonid Krivoshein wrote:
>>
>> Возьмём установочный образ LiveCD, где прошивки попадают в образ
>> initrd для загрузки системы локально с ISO-образа. В этом случае мало
>> какие прошивки требуются. Для специализированных сборок это
>> возможность положить только нужное.
>
> Почему мало какие ?
Вообще, не очень хороший пример привёл. Я имел ввиду специализированные
сборки установщика или LiveCD под определённые задачи, а не
универсальные загрузочные носители. В универсальных мы и так складываем
максимум и фильтруем необходимое, просто на другом уровне. Для
специализированных же просто появляется другой способ складывать в
initrd необходимое. Например, для чисто локальной загрузки сеть не
требуется, не нужны Wi-Fi, всякие DVB, поддержка FC, итд, а если
загрузка без плимута и графики, то не нужны GPU. Вообще мало что нужно,
а на выходе получается более компактный initrd. Вот я что имел ввиду.
--
Best regards,
Leonid Krivoshein.
22.04.2021 02:06, Leonid Krivoshein пишет:
>
> 21.04.2021 11:20, Anton Farygin пишет:
>> On 21.04.2021 11:03, Leonid Krivoshein wrote:
>>>
>>> Возьмём установочный образ LiveCD, где прошивки попадают в образ initrd для загрузки системы локально с ISO-образа. В этом случае мало какие прошивки требуются. Для специализированных сборок это возможность положить только нужное.
>>
>> Почему мало какие ?
>
> Вообще, не очень хороший пример привёл. Я имел ввиду специализированные сборки установщика или LiveCD под определённые задачи, а не универсальные загрузочные носители. В универсальных мы и так складываем максимум и фильтруем необходимое, просто на другом уровне. Для специализированных же просто появляется другой способ складывать в initrd необходимое. Например, для чисто локальной загрузки сеть не требуется, не нужны Wi-Fi, всякие DVB, поддержка FC, итд, а если загрузка без плимута и графики, то не нужны GPU. Вообще мало что нужно, а на выходе получается более компактный initrd. Вот я что имел ввиду.
>
Так это всё можно подчистить для специальной сборки.
--
С уважением, Антон Мидюков <antohami@altlinux.org>
21.04.2021 22:10, Антон Мидюков пишет:
> 22.04.2021 02:06, Leonid Krivoshein пишет:
>> 21.04.2021 11:20, Anton Farygin пишет:
>>> On 21.04.2021 11:03, Leonid Krivoshein wrote:
>>>> Возьмём установочный образ LiveCD, где прошивки попадают в образ initrd для загрузки системы локально с ISO-образа. В этом случае мало какие прошивки требуются. Для специализированных сборок это возможность положить только нужное.
>>> Почему мало какие ?
>> Вообще, не очень хороший пример привёл. Я имел ввиду специализированные сборки установщика или LiveCD под определённые задачи, а не универсальные загрузочные носители. В универсальных мы и так складываем максимум и фильтруем необходимое, просто на другом уровне. Для специализированных же просто появляется другой способ складывать в initrd необходимое. Например, для чисто локальной загрузки сеть не требуется, не нужны Wi-Fi, всякие DVB, поддержка FC, итд, а если загрузка без плимута и графики, то не нужны GPU. Вообще мало что нужно, а на выходе получается более компактный initrd. Вот я что имел ввиду.
>>
> Так это всё можно подчистить для специальной сборки.
Можно, но проще и логичнее выбирать только нужное из готового.
--
Best regards,
Leonid Krivoshein.
On 21.04.2021 23:00, Leonid Krivoshein wrote:
>
> 21.04.2021 22:10, Антон Мидюков пишет:
>> 22.04.2021 02:06, Leonid Krivoshein пишет:
>>> 21.04.2021 11:20, Anton Farygin пишет:
>>>> On 21.04.2021 11:03, Leonid Krivoshein wrote:
>>>>> Возьмём установочный образ LiveCD, где прошивки попадают в образ
>>>>> initrd для загрузки системы локально с ISO-образа. В этом случае
>>>>> мало какие прошивки требуются. Для специализированных сборок это
>>>>> возможность положить только нужное.
>>>> Почему мало какие ?
>>> Вообще, не очень хороший пример привёл. Я имел ввиду
>>> специализированные сборки установщика или LiveCD под определённые
>>> задачи, а не универсальные загрузочные носители. В универсальных мы
>>> и так складываем максимум и фильтруем необходимое, просто на другом
>>> уровне. Для специализированных же просто появляется другой способ
>>> складывать в initrd необходимое. Например, для чисто локальной
>>> загрузки сеть не требуется, не нужны Wi-Fi, всякие DVB, поддержка
>>> FC, итд, а если загрузка без плимута и графики, то не нужны GPU.
>>> Вообще мало что нужно, а на выходе получается более компактный
>>> initrd. Вот я что имел ввиду.
>>>
>> Так это всё можно подчистить для специальной сборки.
>
> Можно, но проще и логичнее выбирать только нужное из готового.
>
>
Для начала начать выбирать при сборке, заодно и проясниться возможность
разбивки на пакеты.
Здравствуйте! Пока мы обсуждаем порубку firmware-linux из него вырубили нечто нужное. Проблема: https://bugzilla.altlinux.org/show_bug.cgi?id=39539 https://bugzilla.altlinux.org/show_bug.cgi?id=39962 Это блокирует сборку Simply и ALT Education для RPi4, поскольку с неработающим WiFi выпускать релиз как-то странно. Предлагаю такой обход данной проблемы: Взять самое свежее firmware от Сypress Свежее этого не нашел. https://community.cypress.com/gfawx74859/attachments/gfawx74859/resourcelibrary/1030/1/cypress-fmac-v5.4.18-2020_0925.zip Можно предположить, что Сypress выпустила новые версии firmware с исправленной уязвимостью CVE-2019-15126. Собрать пакет пакет с этим firmware. Собрал пакет firmware-cypress в тестовой задаче 270467. Добавить данный пакет в профили сборки Simply и ALT Education для RPi4. Вот только вместе с данным firmware идёт файлик с интересным содержанием: README * This LICENCE is different from the LICENCE.Cypress on linux-firmware.git. * The files under this licence are not intended for linux-firmware.git upstreaming. В пакете он тоже есть. В связи с этим у меня возникло непонимание - а в праве ли мы собрать такой пакет с такой лицензией в наш репозиторий? Коллеги, помогите, пожалуйста, его разрешить. С уважением Дмитрий Терёхин
On Thu, Apr 22, 2021 at 03:19:08PM +0300, Дмитрий Терехин wrote: > Здравствуйте! > > Пока мы обсуждаем порубку firmware-linux из него вырубили нечто нужное. > > Проблема: > https://bugzilla.altlinux.org/show_bug.cgi?id=39539 > https://bugzilla.altlinux.org/show_bug.cgi?id=39962 > > Это блокирует сборку Simply и ALT Education для RPi4, поскольку с неработающим WiFi > выпускать релиз как-то странно. > > Предлагаю такой обход данной проблемы: > > Взять самое свежее firmware от Сypress > Свежее этого не нашел. > https://community.cypress.com/gfawx74859/attachments/gfawx74859/resourcelibrary/1030/1/cypress-fmac-v5.4.18-2020_0925.zip > Можно предположить, что Сypress выпустила новые версии firmware с исправленной уязвимостью CVE-2019-15126. > > Собрать пакет пакет с этим firmware. > Собрал пакет firmware-cypress в тестовой задаче 270467. > > Добавить данный пакет в профили сборки Simply и ALT Education для RPi4. > > Вот только вместе с данным firmware идёт файлик с интересным содержанием: > README > * This LICENCE is different from the LICENCE.Cypress on linux-firmware.git. > * The files under this licence are not intended for linux-firmware.git upstreaming. > > В пакете он тоже есть. > > В связи с этим у меня возникло непонимание - а в праве ли мы собрать такой пакет > с такой лицензией в наш репозиторий? > > Коллеги, помогите, пожалуйста, его разрешить. Ссылка на лицензию: http://git.altlinux.org/people/jqt4/packages/?p=firmware-cypress.git;a=blob;f=LICENCE;h=b320f275aea9457dee278591641c707d9dc7f7c1 Сам пока не читал. -- wbr, iv m.
22.04.2021, 15:26, "Aleksey Novodvorsky" <aen@basealt.ru>: > Посмотрите, что с этим firmware у raspberry OS. > > Rgrds, Алексей Посмотрел. В RaspiOS подобное firmware лежит в отдельном пакете: dpkg-query -S /lib/firmware/brcm/brcmfmac43455-sdio.bin firmware-brcm80211: /lib/firmware/brcm/brcmfmac43455-sdio.bin После обновления RaspiOS получил: dpkg-query -l firmware-brcm80211 ||/ Имя Версия Архитектура Описание ii firmware-brcm80211 1:20190114-1+rpt11 all Binary firmware for Broadcom/Cypress 802.11 wireless cards Судя по версии, в этом файле проблема CVE-2019-15126 не устранена. С уважением Дмитрий Терёхин > > чт, 22 апр. 2021 г., 15:19 Дмитрий Терехин <jqt4@basealt.ru>: >> Здравствуйте! >> >> Пока мы обсуждаем порубку firmware-linux из него вырубили нечто нужное. >> >> Проблема: >> https://bugzilla.altlinux.org/show_bug.cgi?id=39539 >> https://bugzilla.altlinux.org/show_bug.cgi?id=39962 >> >> Это блокирует сборку Simply и ALT Education для RPi4, поскольку с неработающим WiFi >> выпускать релиз как-то странно. >> >> Предлагаю такой обход данной проблемы: >> >> Взять самое свежее firmware от Сypress >> Свежее этого не нашел. >> https://community.cypress.com/gfawx74859/attachments/gfawx74859/resourcelibrary/1030/1/cypress-fmac-v5.4.18-2020_0925.zip >> Можно предположить, что Сypress выпустила новые версии firmware с исправленной уязвимостью CVE-2019-15126. >> >> Собрать пакет пакет с этим firmware. >> Собрал пакет firmware-cypress в тестовой задаче 270467. >> >> Добавить данный пакет в профили сборки Simply и ALT Education для RPi4. >> >> Вот только вместе с данным firmware идёт файлик с интересным содержанием: >> README >> * This LICENCE is different from the LICENCE.Cypress on linux-firmware.git. >> * The files under this licence are not intended for linux-firmware.git upstreaming. >> >> В пакете он тоже есть. >> >> В связи с этим у меня возникло непонимание - а в праве ли мы собрать такой пакет >> с такой лицензией в наш репозиторий? >> >> Коллеги, помогите, пожалуйста, его разрешить. >> >> С уважением >> Дмитрий Терёхин >> >> _______________________________________________ >> 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
Hi Leonid!
On 04/21/2021, at 10:06:09 PM you wrote:
>
> 21.04.2021 11:20, Anton Farygin пишет:
> > On 21.04.2021 11:03, Leonid Krivoshein wrote:
> >>
> >> Возьмём установочный образ LiveCD, где прошивки попадают в образ
> >> initrd для загрузки системы локально с ISO-образа. В этом случае мало
> >> какие прошивки требуются. Для специализированных сборок это
> >> возможность положить только нужное.
> >
> > Почему мало какие ?
>
> Вообще, не очень хороший пример привёл. Я имел ввиду специализированные
> сборки установщика или LiveCD под определённые задачи, а не
> универсальные загрузочные носители. В универсальных мы и так складываем
> максимум и фильтруем необходимое, просто на другом уровне. Для
> специализированных же просто появляется другой способ складывать в
> initrd необходимое. Например, для чисто локальной загрузки сеть не
> требуется, не нужны Wi-Fi, всякие DVB, поддержка FC, итд, а если
> загрузка без плимута и графики, то не нужны GPU. Вообще мало что нужно,
> а на выходе получается более компактный initrd. Вот я что имел ввиду.
Мне кажется вы все тут зажрались - я автоматизировал сборку firmware в
текущем виде именно из-за всяких "вышиваний крестиком" в package
management, где пакет собирался вручную по велению левой ноги упаковщика и
фазы луны. А сейчас firmware у нас всегда свежий и не надо думать что
где-то каких-то дров не хватает или они устарели.
Насчет места - в спец. сборках никто не мешает перепаковать firmware как
нужно и собирать с ним а то вообще собрать все нужные спец. firmware
отдельно и ставить только их.
--
WBR et al.
On Thu, 22 Apr 2021 16:25:31 +0400 Ivan A. Melnikov wrote: > On Thu, Apr 22, 2021 at 03:19:08PM +0300, Дмитрий Терехин wrote: > > Здравствуйте! > > > > Пока мы обсуждаем порубку firmware-linux из него вырубили нечто > > нужное. > > > > Проблема: > > https://bugzilla.altlinux.org/show_bug.cgi?id=39539 > > https://bugzilla.altlinux.org/show_bug.cgi?id=39962 > > > > Это блокирует сборку Simply и ALT Education для RPi4, поскольку с > > неработающим WiFi выпускать релиз как-то странно. > > > > Предлагаю такой обход данной проблемы: > > > > Взять самое свежее firmware от Сypress > > Свежее этого не нашел. > > https://community.cypress.com/gfawx74859/attachments/gfawx74859/resourcelibrary/1030/1/cypress-fmac-v5.4.18-2020_0925.zip > > Можно предположить, что Сypress выпустила новые версии firmware с > > исправленной уязвимостью CVE-2019-15126. > > > > Собрать пакет пакет с этим firmware. > > Собрал пакет firmware-cypress в тестовой задаче 270467. > > > > Добавить данный пакет в профили сборки Simply и ALT Education для > > RPi4. Согласен, лучший вариант, похоже. Только не понятно, действительно ли там закрыто CVE. > > Вот только вместе с данным firmware идёт файлик с интересным > > содержанием: README > > * This LICENCE is different from the LICENCE.Cypress on > > linux-firmware.git. > > * The files under this licence are not intended for > > linux-firmware.git upstreaming. > > > > В пакете он тоже есть. > > > > В связи с этим у меня возникло непонимание - а в праве ли мы > > собрать такой пакет с такой лицензией в наш репозиторий? > > > > Коллеги, помогите, пожалуйста, его разрешить. > > Ссылка на лицензию: > > http://git.altlinux.org/people/jqt4/packages/?p=firmware-cypress.git;a=blob;f=LICENCE;h=b320f275aea9457dee278591641c707d9dc7f7c1 > > Сам пока не читал. Я прочитал, в данном случае, думаю, наиболее интересен абзац про Binary Code Form: Software Provided in Binary Code Form. This paragraph applies to any Software provided in binary code form. Subject to the terms and conditions of this Agreement, Cypress Semiconductor Corporation ("Cypress") grants you a non-exclusive, non-transferable license under its copyright rights in the Software to reproduce and distribute the Software in object code form only, solely for use in connection with Cypress integrated circuit products ("Purpose"). Мне кажется, что можно собирать и использовать в дистрибутивах. Впрочем, я не считаю себя большим спецом в лицензиях, может кто еще посмотрит. -- WBR, Mikhail Efremov
On 2021-04-22 16:42:14 +0300, Mikhail Efremov wrote: >>> В связи с этим у меня возникло непонимание - а в праве ли >>> мы собрать такой пакет с такой лицензией в наш репозиторий? >>> Коллеги, помогите, пожалуйста, его разрешить. >> Ссылка на лицензию: >> http://git.altlinux.org/people/jqt4/packages/?p=firmware-cypress.git;a=blob;f=LICENCE;h=b320f275aea9457dee278591641c707d9dc7f7c1 >> Сам пока не читал. > Я прочитал, в данном случае, думаю, наиболее интересен абзац > про Binary Code Form: > Software Provided in Binary Code Form. This paragraph applies > to any Software provided in binary code form. Subject to the > terms and conditions of this Agreement, Cypress Semiconductor > Corporation ("Cypress") grants you a non-exclusive, > non-transferable license under its copyright rights in the > Software to reproduce and distribute the Software in object > code form only, solely for use in connection with Cypress > integrated circuit products ("Purpose"). Именно он нам и интересен. Точнее, вот этот фрагмент: "to reproduce and distribute [...] solely for use in connection with Cypress integrated circuit products" > Мне кажется, что можно собирать и использовать в > дистрибутивах. Впрочем, я не считаю себя большим спецом в > лицензиях, может кто еще посмотрит. Я увидел в тексте мелкую неоднозначность, которую предлагаю трактовать в нашу пользу - во всяком случае, по своему духу (раз уж с буквой есть варианты) оно ближе всего к обычному fair use. В общем, самый простой вариант - License: Distributable -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
Добрый день, Константин!
22.04.2021 15:52, Konstantin Lepikhov пишет:
> Hi Leonid!
>
> On 04/21/2021, at 10:06:09 PM you wrote:
>
>> 21.04.2021 11:20, Anton Farygin пишет:
>>> On 21.04.2021 11:03, Leonid Krivoshein wrote:
>>>> Возьмём установочный образ LiveCD, где прошивки попадают в образ
>>>> initrd для загрузки системы локально с ISO-образа. В этом случае мало
>>>> какие прошивки требуются. Для специализированных сборок это
>>>> возможность положить только нужное.
>>> Почему мало какие ?
>> Вообще, не очень хороший пример привёл. Я имел ввиду специализированные
>> сборки установщика или LiveCD под определённые задачи, а не
>> универсальные загрузочные носители. В универсальных мы и так складываем
>> максимум и фильтруем необходимое, просто на другом уровне. Для
>> специализированных же просто появляется другой способ складывать в
>> initrd необходимое. Например, для чисто локальной загрузки сеть не
>> требуется, не нужны Wi-Fi, всякие DVB, поддержка FC, итд, а если
>> загрузка без плимута и графики, то не нужны GPU. Вообще мало что нужно,
>> а на выходе получается более компактный initrd. Вот я что имел ввиду.
> Мне кажется вы все тут зажрались - я автоматизировал сборку firmware в
> текущем виде именно из-за всяких "вышиваний крестиком" в package
> management, где пакет собирался вручную по велению левой ноги упаковщика и
> фазы луны. А сейчас firmware у нас всегда свежий и не надо думать что
> где-то каких-то дров не хватает или они устарели.
>
> Насчет места - в спец. сборках никто не мешает перепаковать firmware как
> нужно и собирать с ним а то вообще собрать все нужные спец. firmware
> отдельно и ставить только их.
Прежде всего речь о том, чтобы пользователи могли устанавливать только
необходимые им прошивки и чтобы обновлялись только те прошивки, которые
действительно по факту изменились. Это фича для опытных пользователей,
понимающих, что им нужно.
Классификация тут -- дополнительный бонус, упрощающий работу тем, кто
будет делать подборку пакетов для образов под конкретные узкие задачи.
Иначе каждому, кто хочет сделать такой диск, загружаемый только с
определённой поддержкой железа, нужно самому погружаться в то, чем
владеет только маинтейнер пакета, либо использовать полный набор прошивок.
Полезность классификации -- вопрос безусловно дискуссионный, но запрос
на "распил" по первой причине сомнений не вызывает. Никто же не говорит,
что это надо сделать именно Вам и прямо сейчас. Тут просто обмен
мнениями, как можно сделать лучше хотя бы в теории.
P.S.: У нас даже ядро на части распилено, никого же это не смущает.
--
Best regards,
Leonid Krivoshein.
On 22.04.2021 17:50, Leonid Krivoshein wrote:
> P.S.: У нас даже ядро на части распилено, никого же это не смущает.
"не распилено"
22.04.2021 17:52, Anton Farygin пишет:
> On 22.04.2021 17:50, Leonid Krivoshein wrote:
>> P.S.: У нас даже ядро на части распилено, никого же это не смущает.
>
> "не распилено"
>
По крайней мере, модули в отдельные пакеты собираются, и никто не
говорит, что мы "слишком много кушать". ))
--
Best regards,
Leonid Krivoshein.
On 22.04.2021 18:00, Leonid Krivoshein wrote:
>
> 22.04.2021 17:52, Anton Farygin пишет:
>> On 22.04.2021 17:50, Leonid Krivoshein wrote:
>>> P.S.: У нас даже ядро на части распилено, никого же это не смущает.
>>
>> "не распилено"
>>
>
> По крайней мере, модули в отдельные пакеты собираются, и никто не
> говорит, что мы "слишком много кушать". ))
>
>
они собираются скорее потому что их нет в основном ядре, а не потому,
что у нас цель распилить его на подпакеты.
22.04.2021 19:19, Дмитрий Терехин пишет: > Здравствуйте! > > Пока мы обсуждаем порубку firmware-linux из него вырубили нечто нужное. > > Проблема: > https://bugzilla.altlinux.org/show_bug.cgi?id=39539 > https://bugzilla.altlinux.org/show_bug.cgi?id=39962 > > Это блокирует сборку Simply и ALT Education для RPi4, поскольку с неработающим WiFi > выпускать релиз как-то странно. > > Предлагаю такой обход данной проблемы: > > Взять самое свежее firmware от Сypress > Свежее этого не нашел. > https://community.cypress.com/gfawx74859/attachments/gfawx74859/resourcelibrary/1030/1/cypress-fmac-v5.4.18-2020_0925.zip > Можно предположить, что Сypress выпустила новые версии firmware с исправленной уязвимостью CVE-2019-15126. Не просто выпустила, а закоммитила в апстрим firmware-linux. Именно поэтому бинари от Broadcom и удалили. Вместо них были созданы симлинки, но в нашем git симлинков нет. Кто-нибудь может объяснить этот феномЕн? Смотреть коммит: http://git.altlinux.org/gears/f/firmware-linux.git?p=firmware-linux.git;a=commitdiff;h=a28a5905b0fb6d84e02e45ae77cc450dea1494d1 И дерево для этого коммита: http://git.altlinux.org/gears/f/firmware-linux.git?p=firmware-linux.git;a=tree;f=brcm;h=7d74bd5ae0ce5a463e0274378612efd789ee78e3;hb=a28a5905b0fb6d84e02e45ae77cc450dea1494d1 -- С уважением, Антон Мидюков <antohami@altlinux.org>
[-- Attachment #1: Type: text/plain, Size: 3626 bytes --] On Thu, 22 Apr 2021 17:10:11 +0300 Alexey V. Vissarionov wrote: > On 2021-04-22 16:42:14 +0300, Mikhail Efremov wrote: > > >>> В связи с этим у меня возникло непонимание - а в праве ли > >>> мы собрать такой пакет с такой лицензией в наш репозиторий? > >>> Коллеги, помогите, пожалуйста, его разрешить. > >> Ссылка на лицензию: > >> http://git.altlinux.org/people/jqt4/packages/?p=firmware-cypress.git;a=blob;f=LICENCE;h=b320f275aea9457dee278591641c707d9dc7f7c1 > >> Сам пока не читал. > > Я прочитал, в данном случае, думаю, наиболее интересен абзац > > про Binary Code Form: > > Software Provided in Binary Code Form. This paragraph applies > > to any Software provided in binary code form. Subject to the > > terms and conditions of this Agreement, Cypress Semiconductor > > Corporation ("Cypress") grants you a non-exclusive, > > non-transferable license under its copyright rights in the > > Software to reproduce and distribute the Software in object > > code form only, solely for use in connection with Cypress > > integrated circuit products ("Purpose"). > > Именно он нам и интересен. Точнее, вот этот фрагмент: > > "to reproduce and distribute [...] solely for use in connection > with Cypress integrated circuit products" > > > Мне кажется, что можно собирать и использовать в > > дистрибутивах. Впрочем, я не считаю себя большим спецом в > > лицензиях, может кто еще посмотрит. > > Я увидел в тексте мелкую неоднозначность, которую предлагаю > трактовать в нашу пользу - во всяком случае, по своему духу > (раз уж с буквой есть варианты) оно ближе всего к обычному > fair use. > > В общем, самый простой вариант - License: Distributable Поскольку мы предполагаем возможность использования этой фирмвари для соответствующего оборудования — и, мало того, тестируем этот wifi на rpi4 — то, на мой взгляд, мы попадаем в обозначенные условия распространения прошивки. Однако: 1) Мы просто берём поставляем блобы от производителя или это компилируемая фирмваря? Предполагаю первое, но второе в природе тоже встречается. 2) Меня в лицензии смущает вот это: > ("Cypress") grants you a non-exclusive, non-transferable license > under its copyright rights in the Software to reproduce and > distribute the Software in object code form only А именно: > a non-exclusive, non-transferable license Не будет ли проблем у наших дистрибьюторов? Насколько я понимаю, лицензиях не распространяется на них автоматически, без их явного согласия с условиями и принятия этой лицензии. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1265 bytes --] On Thu, 22 Apr 2021 18:04:42 +0300 Anton Farygin wrote: > On 22.04.2021 18:00, Leonid Krivoshein wrote: > > > > 22.04.2021 17:52, Anton Farygin пишет: > >> On 22.04.2021 17:50, Leonid Krivoshein wrote: > >>> P.S.: У нас даже ядро на части распилено, никого же это не смущает. > >> > >> "не распилено" > >> > > > > По крайней мере, модули в отдельные пакеты собираются, и никто не > > говорит, что мы "слишком много кушать". )) > > > > > они собираются скорее потому что их нет в основном ядре, а не потому, > что у нас цель распилить его на подпакеты. Или потому, что конфликтуют с другими модулями и в ряде случаев нужен вынос в отдельный пакет, чтоб упростить жизнь пользователям. В любом случае согласен, что в ядре модули отдельными пакетами только в исключительных случаях. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
On Thu, 22 Apr 2021 18:49:22 +0300 Andrey Savchenko wrote: > On Thu, 22 Apr 2021 17:10:11 +0300 Alexey V. Vissarionov wrote: > > On 2021-04-22 16:42:14 +0300, Mikhail Efremov wrote: > > > > >>> В связи с этим у меня возникло непонимание - а в праве ли > > >>> мы собрать такой пакет с такой лицензией в наш репозиторий? > > >>> Коллеги, помогите, пожалуйста, его разрешить. > > >> Ссылка на лицензию: > > >> http://git.altlinux.org/people/jqt4/packages/?p=firmware-cypress.git;a=blob;f=LICENCE;h=b320f275aea9457dee278591641c707d9dc7f7c1 > > >> Сам пока не читал. > > > Я прочитал, в данном случае, думаю, наиболее интересен абзац > > > про Binary Code Form: > > > Software Provided in Binary Code Form. This paragraph applies > > > to any Software provided in binary code form. Subject to the > > > terms and conditions of this Agreement, Cypress Semiconductor > > > Corporation ("Cypress") grants you a non-exclusive, > > > non-transferable license under its copyright rights in the > > > Software to reproduce and distribute the Software in object > > > code form only, solely for use in connection with Cypress > > > integrated circuit products ("Purpose"). > > > > Именно он нам и интересен. Точнее, вот этот фрагмент: > > > > "to reproduce and distribute [...] solely for use in connection > > with Cypress integrated circuit products" > > > > > Мне кажется, что можно собирать и использовать в > > > дистрибутивах. Впрочем, я не считаю себя большим спецом в > > > лицензиях, может кто еще посмотрит. > > > > Я увидел в тексте мелкую неоднозначность, которую предлагаю > > трактовать в нашу пользу - во всяком случае, по своему духу > > (раз уж с буквой есть варианты) оно ближе всего к обычному > > fair use. > > > > В общем, самый простой вариант - License: Distributable > > Поскольку мы предполагаем возможность использования этой фирмвари > для соответствующего оборудования — и, мало того, тестируем этот > wifi на rpi4 — то, на мой взгляд, мы попадаем в обозначенные условия > распространения прошивки. Однако: > > 1) Мы просто берём поставляем блобы от производителя или это > компилируемая фирмваря? Предполагаю первое, но второе в природе > тоже встречается. В git пакета блобы, во всяком случае. > 2) Меня в лицензии смущает вот это: > > ("Cypress") grants you a non-exclusive, non-transferable license > > under its copyright rights in the Software to reproduce and > > distribute the Software in object code form only > > А именно: > > a non-exclusive, non-transferable license > > Не будет ли проблем у наших дистрибьюторов? Насколько я понимаю, > лицензиях не распространяется на них автоматически, без их явного > согласия с условиями и принятия этой лицензии. Насколько я понимаю, это означает лишь то, что Cypress может предоставлять такие же или другие права кому-то еще. -- WBR, Mikhail Efremov
On 2021-04-22 18:49:22 +0300, Andrey Savchenko wrote: >>>>> В связи с этим у меня возникло непонимание - а в праве ли >>>>> мы собрать такой пакет с такой лицензией в наш репозиторий? >>>> Сам пока не читал. >>> Я прочитал, в данном случае, думаю, наиболее интересен абзац >>> про Binary Code Form >> Именно он нам и интересен. Точнее, вот этот фрагмент: >> "to reproduce and distribute [...] solely for use in connection >> with Cypress integrated circuit products" >>> Мне кажется, что можно собирать и использовать в >>> дистрибутивах. Впрочем, я не считаю себя большим спецом в >>> лицензиях, может кто еще посмотрит. >> Я увидел в тексте мелкую неоднозначность, которую предлагаю >> трактовать в нашу пользу - во всяком случае, по своему духу >> (раз уж с буквой есть варианты) оно ближе всего к обычному >> fair use. >> В общем, самый простой вариант - License: Distributable > Поскольку мы предполагаем возможность использования этой > фирмвари для соответствующего оборудования — и, мало того, > тестируем этот wifi на rpi4 — то, на мой взгляд, мы попадаем > в обозначенные условия распространения прошивки. Однако: > 1) Мы просто берём поставляем блобы от производителя или > это компилируемая фирмваря? Предполагаю первое, но второе в > природе тоже встречается. Блобятина обыкновенная. > 2) Меня в лицензии смущает вот это: >> ("Cypress") grants you a non-exclusive, non-transferable license >> under its copyright rights in the Software to reproduce and >> distribute the Software in object code form only > А именно: >> a non-exclusive, non-transferable license > Не будет ли проблем у наших дистрибьюторов? Насколько я > понимаю, лицензиях не распространяется на них автоматически, > без их явного согласия с условиями и принятия этой лицензии. Не будет: они распространяют не блобятину от Cypress, а наше ПО как составное произведение. Кому нужны подробности - идут читать ГК РФ: часть 4, статья 1235 и далее по разделу. Упрощенно говоря, наши отношения с авторами софта, входящего в дистрибутивы, являются исключительно нашим делом и не трогают ни наших пользователей, ни дистрибьюторов, ни кого-либо еще. -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
On 2021-04-22 17:52:18 +0300, Anton Farygin wrote: >> P.S.: У нас даже ядро на части распилено, никого же это >> не смущает. > "не распилено" Распилено, причем коряво - с потерей функциональности. -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
On Sunday, 18 April 2021 15:59:29 MSK Alexey Sheplyakov wrote:
> On 18.04.2021 15:44, Dmitry V. Levin wrote:
> >> А для экономии места предлагаю распотрошить locales:
> >>
> >> $ du -sh /usr/share/locale/
> >> 404M /usr/share/locale/
> >
> > $ du -sh /usr/share/locale/
> > 0 /usr/share/locale/
>
> Так останется только С. А хочется еще оставить и ru_RU.UTF-8.
$ cat /etc/rpm/macros
%_install_langs en:ru
$ du -sh /usr/share/locale/
44M /usr/share/locale/
[...]
--
Regards, Sergey.
On Monday, 19 April 2021 13:44:37 MSK Валерий Иноземцев wrote:
> > >> И модули ядра пожать (СONFIG_MODULE_COMPRESS=Y,
> > >> CONFIG_MODULE_COMPRESS_XZ=Y) $ du -sh /lib/modules/5.10.29-un-def-alt2
> > >> 256M /lib/modules/5.10.29-un-def-alt2
> > >
> > > НЕТ. этого по умолчанию не надо.
> >
> > Напомню, что точно так же можно пожать и firmware.
>
> любой старьёвщик скажет что так делать не надо ибо грузиться оно будет
> ну очень медленно, а в непожатом виде оно занимает космические 473Mb и
> тут только резать
А кто должен по-твоему выиграть? Диск или процессор?
--
Regards, Sergey.
Denis Medvedev писал 18.4.21 13:20: ... >> И модули ядра пожать (СONFIG_MODULE_COMPRESS=Y, >> CONFIG_MODULE_COMPRESS_XZ=Y) $ du -sh /lib/modules/5.10.29-un-def-alt2 >> 256M /lib/modules/5.10.29-un-def-alt2 > НЕТ. этого по умолчанию не надо. И всё-таки, почему бы не пожать модули ядра и firmware? В zstd. И хорошо бы при этом перейти на zstd для сжатия initrd. https://www.phoronix.com/scan.php?page=news_item&px=Zstd-V8-For-Linux-Kernel-Comp -- С уважением, Виталий Липатов, ALT Linux Team
>>>>> "Vitaly" == Vitaly Lipatov <lav-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes: > Denis Medvedev писал 18.4.21 13:20: > ... >>> И модули ядра пожать (СONFIG_MODULE_COMPRESS=Y, >>> CONFIG_MODULE_COMPRESS_XZ=Y) $ du -sh /lib/modules/5.10.29-un-def-alt2 >>> 256M /lib/modules/5.10.29-un-def-alt2 >> НЕТ. этого по умолчанию не надо. > И всё-таки, почему бы не пожать модули ядра и firmware? В zstd. Модули: """ GZIP (default) and XZ are supported. """ firmware: """ Currently only XZ-compressed files are supported, and they have to be compressed with either none or crc32 integrity check type (pass "-C crc32" option to xz command. """ > И хорошо бы при этом перейти на zstd для сжатия initrd. > https://www.phoronix.com/scan.php?page=news_item&px=Zstd-V8-For-Linux-Kernel-Comp > -- > С уважением, > Виталий Липатов, > ALT Linux Team > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel
On Mon, 26 Apr 2021 22:01:40 +0300
Vitaly Lipatov <lav@altlinux.ru> wrote:
> Denis Medvedev писал 18.4.21 13:20:
> ...
> >> И модули ядра пожать (СONFIG_MODULE_COMPRESS=Y,
> >> CONFIG_MODULE_COMPRESS_XZ=Y) $ du -sh
> >> /lib/modules/5.10.29-un-def-alt2 256M
> >> /lib/modules/5.10.29-un-def-alt2
> > НЕТ. этого по умолчанию не надо.
>
> И всё-таки, почему бы не пожать модули ядра и firmware? В zstd.
>
> И хорошо бы при этом перейти на zstd для сжатия initrd.
>
> https://www.phoronix.com/scan.php?page=news_item&px=Zstd-V8-For-Linux-Kernel-Comp
>
Потому что не будет работать подписывание модулей ядра для целостности.
>>>>> "Denis" == Denis Medvedev <nbr-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes: > On Mon, 26 Apr 2021 22:01:40 +0300 > Vitaly Lipatov <lav@altlinux.ru> wrote: >> Denis Medvedev писал 18.4.21 13:20: >> ... >> >> И модули ядра пожать (СONFIG_MODULE_COMPRESS=Y, >> >> CONFIG_MODULE_COMPRESS_XZ=Y) $ du -sh >> >> /lib/modules/5.10.29-un-def-alt2 256M >> >> /lib/modules/5.10.29-un-def-alt2 >> > НЕТ. этого по умолчанию не надо. >> >> И всё-таки, почему бы не пожать модули ядра и firmware? В zstd. >> >> И хорошо бы при этом перейти на zstd для сжатия initrd. >> >> https://www.phoronix.com/scan.php?page=news_item&px=Zstd-V8-For-Linux-Kernel-Comp >> > Потому что не будет работать подписывание модулей ядра для целостности. Будет, если не жать врукопашную, как это было у нас, а использовать инфраструктуру сборки ядра. --
> >> И всё-таки, почему бы не пожать модули ядра и firmware? В zstd.
> >>
> >> И хорошо бы при этом перейти на zstd для сжатия initrd.
> >>
> >> https://www.phoronix.com/scan.php?page=news_item&px=Zstd-V8-For-Linux-Kernel-Comp
> >>
>
> > Потому что не будет работать подписывание модулей ядра для целостности.
>
> Будет, если не жать врукопашную, как это было у нас, а использовать
> инфраструктуру сборки ядра.
Денис, если я правильно понимаю, имеет в виду другое подписывание:
IMA/EVM
Добрый день!
On 16.04.2021 17:30, Michael Shigorin wrote:
> Здравствуйте.
> При проверке очередного задания для p9_e2k:
>
> Следующие пакеты будут ОБНОВЛЕНЫ:
> firmware-linux libnautilus libtbb make-initrd tbb-devel
> 5 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 0 не будет обновлено.
> Необходимо получить 0B/172MB архивов.
> После распаковки потребуется дополнительно 144MB дискового пространства.
>
> Кроме firmware-linux, остальное всё мелкое; понятно, что фирмварей
> много, но непонятно, откуда такая разница в занятом пространстве
> (это практически размер самого пакета firmware-linux, который
> давно уж худобою не отличается).
>
> Отсюда вопрос: кто-нибудь уже изучал возможность разумной
> порубки нынешней подборки фирмварей как минимум на
> "десктоп/сервер/сеть/встройка"?
#270850 TESTED #3 [test-only] sisyphus firmware-linux.git=20210403-alt3 make-initrd.git=2.17.0-alt1 propagator.git=20210428-alt1
Поддержка сжатых firmware файлов. Требуется ядро >= 5.3 с CONFIG_FW_LOADER_COMPRESS=y.
$ du -sh /lib/firmware
206M /lib/firmware
28.04.2021 20:19, Alexey Sheplyakov пишет:
> Добрый день!
>
> On 16.04.2021 17:30, Michael Shigorin wrote:
>> Здравствуйте.
>> При проверке очередного задания для p9_e2k:
>>
>> Следующие пакеты будут ОБНОВЛЕНЫ:
>> firmware-linux libnautilus libtbb make-initrd tbb-devel
>> 5 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 0 не будет обновлено.
>> Необходимо получить 0B/172MB архивов.
>> После распаковки потребуется дополнительно 144MB дискового пространства.
>>
>> Кроме firmware-linux, остальное всё мелкое; понятно, что фирмварей
>> много, но непонятно, откуда такая разница в занятом пространстве
>> (это практически размер самого пакета firmware-linux, который
>> давно уж худобою не отличается).
>>
>> Отсюда вопрос: кто-нибудь уже изучал возможность разумной
>> порубки нынешней подборки фирмварей как минимум на
>> "десктоп/сервер/сеть/встройка"?
>
>
> #270850 TESTED #3 [test-only] sisyphus firmware-linux.git=20210403-alt3 make-initrd.git=2.17.0-alt1 propagator.git=20210428-alt1
>
> Поддержка сжатых firmware файлов. Требуется ядро >= 5.3 с CONFIG_FW_LOADER_COMPRESS=y.
> $ du -sh /lib/firmware
> 206M /lib/firmware
А что с ядрами 4.x прикажете делать?
--
С уважением, Антон Мидюков <antohami@altlinux.org>
On 28.04.2021 17:25, Антон Мидюков wrote:
>> #270850 TESTED #3 [test-only] sisyphus firmware-linux.git=20210403-alt3 make-initrd.git=2.17.0-alt1 propagator.git=20210428-alt1
>>
>> Поддержка сжатых firmware файлов. Требуется ядро >= 5.3 с CONFIG_FW_LOADER_COMPRESS=y.
>> $ du -sh /lib/firmware
>> 206M /lib/firmware
>
> А что с ядрами 4.x прикажете делать?
Выставить на мороз.
On 28.04.2021 17:39, Alexey Sheplyakov wrote: >> А что с ядрами 4.x прикажете делать? > > Выставить на мороз. Тот, кому очень надо древние ядра, может 1. Доработать и использовать userspace loader [1] 2. Сделать backport коммитов 5342e7093ff298d9cbd40f9342b607adb02b2dd0 и 82fd7a8142a10b8eb41313074b3859d82c0857dc [1] https://github.com/teg/firmwared
On 23.04.2021 17:53, Sergey V Turchin wrote: > On Monday, 19 April 2021 13:44:37 MSK Валерий Иноземцев wrote: >>> >> И модули ядра пожать (СONFIG_MODULE_COMPRESS=Y, >>> >> CONFIG_MODULE_COMPRESS_XZ=Y) $ du -sh /lib/modules/5.10.29-un-def-alt2 >>> >> 256M /lib/modules/5.10.29-un-def-alt2 >>> > >>> > НЕТ. этого по умолчанию не надо. >>> >>> Напомню, что точно так же можно пожать и firmware. >> >> любой старьёвщик скажет что так делать не надо ибо грузиться оно будет >> ну очень медленно, Пускай возьмет секундомер и попробует вместо bzImage грузить vmlinux. > А кто должен по-твоему выиграть? Диск или процессор? Диск -- не очень точный термин (потому что и NVME - "диск", и SSD - "диск", и старорежимный с металлическими блинами - тоже "диск"). Из них с процессором может посоревноваться разве что nvme. А кроме дисков бывают еще флешки, sd-карты, spi... вот они однозначно настолько тупые и медленные, что лучше сжимать все, что можно (т.е. что в основном читают, и очень редко пишут).
Добрый день! On 27.04.2021 14:36, Anton V. Boyarshinov wrote: > >> >> И всё-таки, почему бы не пожать модули ядра и firmware? В zstd. >> >> >> >> И хорошо бы при этом перейти на zstd для сжатия initrd. >> >> >> >> https://www.phoronix.com/scan.php?page=news_item&px=Zstd-V8-For-Linux-Kernel-Comp >> >> >> >> > Потому что не будет работать подписывание модулей ядра для целостности. >> >> Будет, если не жать врукопашную, как это было у нас, а использовать >> инфраструктуру сборки ядра. > > Денис, если я правильно понимаю, имеет в виду другое подписывание: > IMA/EVM Не очень понятно, почему ради какой-то сомнительной ерунды, которую используют 0 человек, нужно отключать что-то полезное и нужное (например сжатые модули)? Может, лучше собрать отдельное ядро с этими SELinux, IMA, и прочими НЕНУЖНО, и не мучить нормальных людей? https://www.altlinux.org/IMA_EVM > Запустить инициализацию системы контроля целостности: > /usr/bin/integrity-applier > Необходимо дождаться завершения работы команды (система будет перезагружена четыре раза) > Выполнение этой команды может занять довольно продолжительное время (подписываются все файлы системы). За это время можно не только напиться и протрезветь, но и состариться.
>>>>> "Anton" == Anton V Boyarshinov <boyarsh-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes: >> >> И всё-таки, почему бы не пожать модули ядра и firmware? В zstd. >> >> >> >> И хорошо бы при этом перейти на zstd для сжатия initrd. >> >> >> >> https://www.phoronix.com/scan.php?page=news_item&px=Zstd-V8-For-Linux-Kernel-Comp >> >> >> >> > Потому что не будет работать подписывание модулей ядра для целостности. >> >> Будет, если не жать врукопашную, как это было у нас, а использовать >> инфраструктуру сборки ядра. > Денис, если я правильно понимаю, имеет в виду другое подписывание: > IMA/EVM Возможно, Денис найдёт время и сообщит в нескольких предложениях сам, что же именно в IMA/EVM несовместимо с обсуждаемыми изменениями. Из изложенного в https://www.altlinux.org/IMA_EVM вывод о такой несовместимости сделать никак не получается. --
Здравствуйте Повспоминал обсуждения о сжатии firmware-linux и решил тему опять поднять. Зачем это нужно? Уменьшить размер установленного пакета с 500+ МБ до 100+ МБ. https://lists.altlinux.org/pipermail/devel/2020-March/210137.html Что нужно сделать? Требуется ядро >= 5.3 с CONFIG_FW_LOADER_COMPRESS=y. https://lists.altlinux.org/pipermail/devel/2021-April/214271.html Что мешает? Наличие ядер в p10: kernel-image-mcom02 4.4.189.9-alt8 kernel-image-tegra 4.9.140-alt2 Но ядра эти не используются в продуктах p10 и, если systemd в p10 обновится до 251, то они превратятся в тыкву. systemd 251 не поддерживает ядра < 4.15: https://lists.freedesktop.org/archives/systemd-devel/2022-May/047976.html Я так понимаю, что обновление systemd до >251 вполне вероятно, судя по тому, как обновлялось systemd в p9. Так что ими можно и пожертвовать в связи с таким обстоятельством. -- С уважением, Антон Мидюков <antohami@altlinux.org>
https://lists.altlinux.org/pipermail/devel/2021-April/214282.html 29.04.2021 16:20, Sergey Bolshakov пишет: >>>>>> "Anton" == Anton V Boyarshinov <boyarsh-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes: > > >> >> И всё-таки, почему бы не пожать модули ядра и firmware? В zstd. > >> >> > >> >> И хорошо бы при этом перейти на zstd для сжатия initrd. > >> >> > >> >> https://www.phoronix.com/scan.php?page=news_item&px=Zstd-V8-For-Linux-Kernel-Comp > >> >> > >> > >> > Потому что не будет работать подписывание модулей ядра для целостности. > >> > >> Будет, если не жать врукопашную, как это было у нас, а использовать > >> инфраструктуру сборки ядра. > > > Денис, если я правильно понимаю, имеет в виду другое подписывание: > > IMA/EVM > > Возможно, Денис найдёт время и сообщит в нескольких предложениях сам, > что же именно в IMA/EVM несовместимо с обсуждаемыми изменениями. > Из изложенного в https://www.altlinux.org/IMA_EVM вывод о такой > несовместимости сделать никак не получается. > Денис так и не ответил, а вопрос интересный. -- С уважением, Антон Мидюков <antohami@altlinux.org>
On Mon, May 23, 2022 at 01:21:13AM +0700, Антон Мидюков wrote:
> Здравствуйте
>
> Повспоминал обсуждения о сжатии firmware-linux и решил тему опять поднять.
>
> Зачем это нужно?
> Уменьшить размер установленного пакета с 500+ МБ до 100+ МБ.
> https://lists.altlinux.org/pipermail/devel/2020-March/210137.html
>
> Что нужно сделать?
> Требуется ядро >= 5.3 с CONFIG_FW_LOADER_COMPRESS=y.
> https://lists.altlinux.org/pipermail/devel/2021-April/214271.html
>
> Что мешает?
> Наличие ядер в p10:
> kernel-image-mcom02 4.4.189.9-alt8
> kernel-image-tegra 4.9.140-alt2
Ещё могут быть самособранные ядра у пользователей.
Я молчу про mipsel и некоторые экзотические платы. systemd это
конечно... сильный аргумент, но всё-таки не хотелось бы
увеличивать число сценариев при котором обычный казалось бы
dist-upgrade неминуемо превращает систему в тыкву.
Может, стоит придумать схему, при которой сжатый firmware
пакуется в отдельный пакет (firmware-linux-compressed),
и firmware-linux и firmware-linux-compressed какое-то
время существуют и обновляются параллельно?
Старые системы будут получать непожатый firmware-linux
(что админы смогут легко поправить одним apt-get install),
а в новые продукты можно сразу класть compressed-версию.
--
wbr,
iv m.
23.05.2022 15:57, Ivan A. Melnikov пишет: > On Mon, May 23, 2022 at 01:21:13AM +0700, Антон Мидюков wrote: >> Здравствуйте >> >> Повспоминал обсуждения о сжатии firmware-linux и решил тему опять поднять. >> >> Зачем это нужно? >> Уменьшить размер установленного пакета с 500+ МБ до 100+ МБ. >> https://lists.altlinux.org/pipermail/devel/2020-March/210137.html >> >> Что нужно сделать? >> Требуется ядро >= 5.3 с CONFIG_FW_LOADER_COMPRESS=y. >> https://lists.altlinux.org/pipermail/devel/2021-April/214271.html >> >> Что мешает? >> Наличие ядер в p10: >> kernel-image-mcom02 4.4.189.9-alt8 >> kernel-image-tegra 4.9.140-alt2 > > Ещё могут быть самособранные ядра у пользователей. > Я молчу про mipsel и некоторые экзотические платы. systemd это > конечно... сильный аргумент, но всё-таки не хотелось бы > увеличивать число сценариев при котором обычный казалось бы > dist-upgrade неминуемо превращает систему в тыкву. > У mipsel отдельный репозиторий, поэтому для него компрессию можно не включать. Разве не так? И systemd не обновлять. > Может, стоит придумать схему, при которой сжатый firmware > пакуется в отдельный пакет (firmware-linux-compressed), > и firmware-linux и firmware-linux-compressed какое-то > время существуют и обновляются параллельно? > > Старые системы будут получать непожатый firmware-linux > (что админы смогут легко поправить одним apt-get install), > а в новые продукты можно сразу класть compressed-версию. > А этого бы хотелось избежать. -- С уважением, Антон Мидюков <antohami@altlinux.org>
On 2022-05-23 16:10:15 +0700, Антон Мидюков wrote: >>> Зачем это нужно? >>> Уменьшить размер установленного пакета с 500+ МБ до 100+ МБ. >>> Что нужно сделать? >>> Требуется ядро >= 5.3 с CONFIG_FW_LOADER_COMPRESS=y. >>> Что мешает? >>> Наличие ядер в p10: >>> kernel-image-mcom02 4.4.189.9-alt8 Не критично: эта железяка - совсем вещь в себе, и firmware ей вообще не нужно. >>> kernel-image-tegra 4.9.140-alt2 А здесь можно обновиться. >> Ещё могут быть самособранные ядра у пользователей. Этих пользователей можно считать достаточно квалифицированными для того, чтобы они сами обновили собираемые ими ядра. >> Я молчу про mipsel и некоторые экзотические платы. systemd >> это конечно... сильный аргумент, Это не аргумент, а обычное приложение, работающее в userspace. >> но всё-таки не хотелось бы увеличивать число сценариев >> при котором обычный казалось бы dist-upgrade неминуемо >> превращает систему в тыкву. Избыток скриптовых костылей превращает систему в тыкву не то что после dist-upgrade, а и просто при установке очередного пакета из репы. Но это совершенно не мешает мейнтейнерам, наоборот, создавать все больше таких костылей. > У mipsel отдельный репозиторий, поэтому для него компрессию > можно не включать. Разве не так? И systemd не обновлять. В принципе, пакеты noarch лучше бы делать одинаковыми везде. >> Может, стоит придумать схему, при которой сжатый firmware >> пакуется в отдельный пакет (firmware-linux-compressed), >> и firmware-linux и firmware-linux-compressed какое-то >> время существуют и обновляются параллельно? Нужно. >> Старые системы будут получать непожатый firmware-linux >> (что админы смогут легко поправить одним apt-get install), >> а в новые продукты можно сразу класть compressed-версию. > А этого бы хотелось избежать. Чего именно избежать и зачем? Чем плох вариант %package compressed Provides: %name = %EVR ? -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
В Mon, 23 May 2022 16:10:15 +0700
Антон Мидюков <midyukov-anton@ya.ru> пишет:
> > Может, стоит придумать схему, при которой сжатый firmware
> > пакуется в отдельный пакет (firmware-linux-compressed),
> > и firmware-linux и firmware-linux-compressed какое-то
> > время существуют и обновляются параллельно?
> >
> > Старые системы будут получать непожатый firmware-linux
> > (что админы смогут легко поправить одним apt-get install),
> > а в новые продукты можно сразу класть compressed-версию.
> >
>
> А этого бы хотелось избежать.
А имена файлов у сжатой и не сжатой версии различны? Если они
одинаковы, то можно распаковывать firmware в %post пакета в зависимости
от местных условий.