[devel] [cronbuild@altlinux.org: FAILED: firmware-linux cronbuild 20200316]

[devel] [cronbuild@altlinux.org: FAILED: firmware-linux cronbuild 20200316]

[Konstantin Lepikhov]

Привет!

А может стоит уже обновить policy и sisyphus_check, чтобы он пропускал
changelog с unicode записями?

Вроде как же 21ый век на дворе.

----- Forwarded message from cronbuild@altlinux -----

Subject: FAILED: firmware-linux cronbuild 20200316

FAILED: firmware-linux cronbuild 20200316
built from git commits (git log -2):
commit 9b209a9e72f1d4b7fb107d728f93945e19dc64e5
Author: Cronbuild Service <cronbuild@altlinux>
Date:   Sun Mar 15 23:12:14 2020 +0000

    20200306-alt1
    
    - upstream changes (GIT 3b3dd5a):
      + amdgpu: update vega20 firmware from 19.50 (thx Alex Deucher)
      + amdgpu: update vega12 firmware from 19.50 (thx Alex Deucher)
      + amdgpu: update vega10 firmware from 19.50 (thx Alex Deucher)
      + rtl_bt: Add firmware and configuration files for RTL8822C BT
        UART chip (thx Hilda Wu)
      + i915: Add DMC firmware v2.06 for TGL (thx José Roberto de Souza)
      + i915: add HuC firmware v7.0.12 for TGL (thx Daniele Ceraolo Spurio)

commit 82b987cd6c6da9c2f48bac077f57343fa440a
...
Wrote: /usr/src/in/srpm/firmware-linux-20200306-alt1.src.rpm
/usr/src/in/srpm/firmware-linux-20200306-alt1.src.rpm: bad symbols in the license tag: ,
/usr/src/in/srpm/firmware-linux-20200306-alt1.src.rpm: unprintable package information: é
sisyphus_check: check-printable ERROR: package information violation
hsh-rebuild: pkg.tar: sisyphus_check failed.


----- End forwarded message -----

-- 
WBR et al.

Re: [devel] [cronbuild@altlinux.org: FAILED: firmware-linux cronbuild 20200316]

[Alexey V. Vissarionov]

On 2020-03-16 10:32:37 +0100, Konstantin Lepikhov wrote:

 > А может стоит уже обновить policy и sisyphus_check, чтобы он пропускал
 > changelog с unicode записями? Вроде как же 21ый век на дворе.  v2.06 for TGL
 > (thx José Roberto de Souza) unprintable package information: é

И то верно... хороший символ. А если написать 灰鸟 будет еще лучше.


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

Re: [devel] [cronbuild@altlinux.org: FAILED: firmware-linux cronbuild 20200316]

[Dmitry V. Levin]

On Mon, Mar 16, 2020 at 12:37:51PM +0300, Alexey V. Vissarionov wrote:
> On 2020-03-16 10:32:37 +0100, Konstantin Lepikhov wrote:
> 
>  > А может стоит уже обновить policy и sisyphus_check, чтобы он пропускал
>  > changelog с unicode записями? Вроде как же 21ый век на дворе.  v2.06 for TGL
>  > (thx José Roberto de Souza) unprintable package information: é
> 
> И то верно... хороший символ. А если написать 灰鸟 будет еще лучше.

$ echo é |iconv -futf8 -tascii//translit
e
$ echo 灰鸟 |iconv -futf8 -tascii//translit
??


-- 
ldv

Re: [devel] [cronbuild@altlinux.org: FAILED: firmware-linux cronbuild 20200316]

[Alexey V. Vissarionov]

On 2020-03-16 13:00:50 +0300, Dmitry V. Levin wrote:

 >>> А может стоит уже обновить policy и sisyphus_check, чтобы он пропускал
 >>> changelog с unicode записями? Вроде как же 21ый век на дворе.
 >>> v2.06 for TGL (thx José Roberto de Souza)
 >>> unprintable package information: é
 >> И то верно... хороший символ. А если написать 灰鸟 будет еще
 >> лучше.
 > $ echo é |iconv -futf8 -tascii//translit
 > e
 > $ echo 灰鸟 |iconv -futf8 -tascii//translit
 > ??

Аштойта оно пиньинь не умеет? Недоработка... отправляй багу в апстрим.

Если серьезно - либо действительно пропускать (каждому латиносу по
ушам не настучишь), либо транслитерировать. Лучше транслитерировать:
будет хотя бы примерно понятно, как это читать (да, в данном случае
понятно, что свиньора де Суза зовут Хосе, но встречаются куда менее
очевидные варианты).


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

Re: [devel] [cronbuild@altlinux.org: FAILED: firmware-linux cronbuild 20200316]

[Vladimir D. Seleznev]

On Mon, Mar 16, 2020 at 01:10:56PM +0300, Alexey V. Vissarionov wrote:
> On 2020-03-16 13:00:50 +0300, Dmitry V. Levin wrote:
> 
>  >>> А может стоит уже обновить policy и sisyphus_check, чтобы он пропускал
>  >>> changelog с unicode записями? Вроде как же 21ый век на дворе.
>  >>> v2.06 for TGL (thx José Roberto de Souza)
>  >>> unprintable package information: é
>  >> И то верно... хороший символ. А если написать 灰鸟 будет еще
>  >> лучше.
>  > $ echo é |iconv -futf8 -tascii//translit
>  > e
>  > $ echo 灰鸟 |iconv -futf8 -tascii//translit
>  > ??
> 
> Аштойта оно пиньинь не умеет? Недоработка... отправляй багу в апстрим.

Это оно тут пиньин, а в общем случае как ты отличишь китайский от
японского, а в последнем случае онъёми от кунъёми?

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] [cronbuild-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org: FAILED: firmware-linux cronbuild 20200316]

[Sergey Bolshakov]

>>>>> "Vladimir" == Vladimir D Seleznev <vseleznv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:

 > On Mon, Mar 16, 2020 at 01:10:56PM +0300, Alexey V. Vissarionov wrote:
 >> On 2020-03-16 13:00:50 +0300, Dmitry V. Levin wrote:
 >> 
 >> >>> А может стоит уже обновить policy и sisyphus_check, чтобы он пропускал
 >> >>> changelog с unicode записями? Вроде как же 21ый век на дворе.
 >> >>> v2.06 for TGL (thx José Roberto de Souza)
 >> >>> unprintable package information: é
 >> >> И то верно... хороший символ. А если написать 灰鸟 будет еще
 >> >> лучше.
 >> > $ echo é |iconv -futf8 -tascii//translit
 >> > e
 >> > $ echo 灰鸟 |iconv -futf8 -tascii//translit
 >> > ??
 >> 
 >> Аштойта оно пиньинь не умеет? Недоработка... отправляй багу в апстрим.

 > Это оно тут пиньин, а в общем случае как ты отличишь китайский от
 > японского, а в последнем случае онъёми от кунъёми?

Между тем %{size} пакета перевалил за полгига и уменьшится врядли.
Дорогой cronbuild, ответь пожалуйста, как нам быть в этой ситуации ?
Может быть, стоит распилить наконец этот пакет или хотя бы сжать
содержимое, предполагая наличие FW_LOADER_COMPRESS во всех наших
ядрах ?

-- 

Re: [devel] [cronbuild-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org: FAILED: firmware-linux cronbuild 20200316]

[Konstantin Lepikhov]

Hi Sergey!

On 03/16/2020, at 04:21:52 PM you wrote:

> >>>>> "Vladimir" == Vladimir D Seleznev <vseleznv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:
> 
>  > On Mon, Mar 16, 2020 at 01:10:56PM +0300, Alexey V. Vissarionov wrote:
>  >> On 2020-03-16 13:00:50 +0300, Dmitry V. Levin wrote:
>  >> 
>  >> >>> А может стоит уже обновить policy и sisyphus_check, чтобы он пропускал
>  >> >>> changelog с unicode записями? Вроде как же 21ый век на дворе.
>  >> >>> v2.06 for TGL (thx José Roberto de Souza)
>  >> >>> unprintable package information: é
>  >> >> И то верно... хороший символ. А если написать 灰鸟 будет еще
>  >> >> лучше.
>  >> > $ echo é |iconv -futf8 -tascii//translit
>  >> > e
>  >> > $ echo 灰鸟 |iconv -futf8 -tascii//translit
>  >> > ??
>  >> 
>  >> Аштойта оно пиньинь не умеет? Недоработка... отправляй багу в апстрим.
> 
>  > Это оно тут пиньин, а в общем случае как ты отличишь китайский от
>  > японского, а в последнем случае онъёми от кунъёми?
> 
> Между тем %{size} пакета перевалил за полгига и уменьшится врядли.
> Дорогой cronbuild, ответь пожалуйста, как нам быть в этой ситуации ?
> Может быть, стоит распилить наконец этот пакет или хотя бы сжать
> содержимое, предполагая наличие FW_LOADER_COMPRESS во всех наших
> ядрах ?
# du -h -d1 firmware |sort -k1,2 -h|tail -n5
25M     firmware/liquidio
27M     firmware/qcom
31M     firmware/amdgpu
140M    firmware/netronome
524M    firmware

- выкинуть netronome и liquidio (не знаю что это такое)
- выкинуть qcom (предполагаю, это нужно для android)
- запаковать сетевые дрова отдельно
- запаковать графические firmware отдельно (amdgpu + i915).

Могли бы сами делать, а не обращаться к cronbuild.

-- 
WBR et al.

[devel] нарезка монолитного firmware-linux

[Michael Shigorin]

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

[devel] размер монолитного firmware-linux

[Michael Shigorin]

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

Re: [devel] размер монолитного firmware-linux

[Ivan A. Melnikov]

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.

Re: [devel] размер монолитного firmware-linux

[Vitaly Lipatov]

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

Re: [devel] размер монолитного firmware-linux

[Andrey Savchenko]

[-- 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 --]

Re: [devel] размер монолитного firmware-linux

[Anton V. Boyarshinov]

> 
> Вы забыли указать время на сжатие и распаковку и потребление памяти.
> И это с каким-нибудь -m6, да?

Время сжатия, в общем, не интересно, так как сжатие делается один раз
при сборке пакета, а место они занимают -- у всех.

 
> Тогда уже и paq8l -9 можно вспомнить.
> 
> Best regards,
> Andrew Savchenko

Re: [devel] размер монолитного firmware-linux

[Andrey 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 --]

Re: [devel] размер монолитного firmware-linux

[Vitaly Lipatov]

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

Re: [devel] размер монолитного firmware-linux

[Ivan A. Melnikov]

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.