Bug 45886

Игорь, подтвердите, пожалуйста, что вы согласны на менторство.

Эта заявка недооформлена.
Можете переоткрыть баг когда решите её оформить.

Created attachment 13071 [details]
GPG ключ

Created attachment 13072 [details]
SSH ключ

Прикрепил свои SSH и GPG ключи.

Добрый день.

Подтверждаю согласие на менторство.

(Ответ для Vitaly Lipatov на комментарий #1)
> Игорь, подтвердите, пожалуйста, что вы согласны на менторство.

Было вынесено предложение собрать Digital Speech Decoder:

https://github.com/szechyjs/dsd

Коллеги сообщили, что DSD уже есть в Sisyphus, потому есть предложение рассмотреть vosk-api:

https://github.com/alphacep/vosk-api

В рамках работы над опакечиванием vosk-api понадобилось также опакетить библиотеки kaldi и openfst. Опакечивание openfst сейчас ведётся в https://github.com/vasthecat/openfst/tree/alt-package. Сам пакет пока не собирается, пытаюсь выяснить причины проблем. Остальные две библиотеки будут добавлены когда получится опакетить openfst.

Добавлены spec-файлы для vosk-api и kaldi
- https://github.com/vasthecat/vosk-api/tree/alt-package
- https://github.com/vasthecat/libkaldi-vosk/tree/alt-package

(In reply to Andrew Guschin from comment #3)
> Created attachment 13071 [details]
> GPG ключ
Ok.

(In reply to Andrew Guschin from comment #4)
> Created attachment 13072 [details]
> SSH ключ
Ok.

Добрый день.

Закончил работу над пакетированием:
- https://github.com/vasthecat/openfst
- https://github.com/vasthecat/libkaldi-vosk
- https://github.com/vasthecat/vosk-api

Ключи посмотрел, вопросов не вызвало. Прошу создать почтовый псевдоним и зарегистрировать кандидата на соответствующих ресурсах.

ssh ключ на gitery.alt зарегистрирован.
Адрес для пересылки создан.     

T/J/S -> 2.3.

Переработал пакеты по совету прошлого ментора. Пакет libkaldi-vosk убран, так как не имеет особого смысла добавлять его в сизиф (для vosk-api нужен вариант из их форка с определённой ветки, upstream не подходит). В самом vosk-api добавлена сборка биндинга для python, для этого понадобился новый пакет python3-module-srt. libkaldi лежит исходниками в архиве внутри репозитория.

- https://git.altlinux.org/people/guschin/packages/?p=vosk-api.git;a=summary
- https://git.altlinux.org/people/guschin/packages/?p=openfst.git;a=summary
- https://git.altlinux.org/people/guschin/packages/?p=python3-module-srt.git;a=summary

Также хотел бы добавить пакет kernel-image-mcom03-def, но сейчас не хватает квоты.

Хотел бы добавить также пакет с новым flavour ядра mcom03-def. Лежит в репозитории [1] в соответствующей ветке.

Как я понимаю, ментору на этом этапе нужно дать какие-то комментарии по собранным пакетам. nir@, вы всё ещё можете посмотреть это или мне лучше сменить ментора?

[1]: https://git.altlinux.org/people/guschin/packages/?p=kernel-image-std-def.git;a=shortlog;h=mcom03-def

Добрый день. Хотел бы изменить ментора на Ивана Мельникова iv@.

(In reply to Andrew Guschin from comment #17)
> Добрый день. Хотел бы изменить ментора на Ивана Мельникова iv@.
Тут нет никакой проблемы, но новый ментор должен явно на это согласиться.

(In reply to Andrew Guschin from comment #17)
> Добрый день. Хотел бы изменить ментора на Ивана Мельникова iv@.

Я не против, я просто медленный. Андрей, извини.

Да, я согласен быть ментором Андрея, мы об этом договаривались.

(In reply to Andrew Guschin from comment #16)
> https://git.altlinux.org/people/guschin/packages/?p=kernel-image-std-def.git;
> a=shortlog;h=mcom03-def

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

Также я бы всё-таки почистил некотороые мелочи, даже если они "унаследованны"
- epoch с маленькой буквы это нехорошо
- есть мусор вроде kernel_base_version или def_disable oss, который, мне кажется, не стоит сохранять.

> https://git.altlinux.org/people/guschin/packages/?p=python3-module-srt.git;a=summary

Я бы всё-таки сделал gear-tag и собирал из него.

Также рекомендуется summary покороче и description поразвёрнутее.

> https://git.altlinux.org/people/guschin/packages/?p=vosk-api.git;a=summary

Я бы всё-таки сделал gear-tag и собирал из него.

Summary, опять же, можно и покороче.

К патчам, если они хранятся отдельно, стоит относится как к коммитам: делать одним патчем одно, давать им нормальное описание, следовать рекомендациям по их именованию
(https://www.altlinux.org/ALT_Packaging_HOWTO#Наименование_патчей).

> +BuildRequires: libclapack-devel

Правда что ли?

> +Requires: libfst
> +Requires: liblapack
> +Requires: libopenblas
> +Requires: libxblas

Если эти зависимости находятся автоматически, такие Requires не нужны.

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

А ешё -- openblas и xblas в одном флаконе. Зачем?

> Requires: %name python3(srt) python3(websockets) python3(tqdm)

То же самое. Почему AutoReq этого не находит?

> https://git.altlinux.org/people/guschin/packages/?p=openfst.git;a=summary

Я не против сборки из тарбола (я пока не смотрел, есть ли у апстрима публичная VCS, но даже если есть, "мне так удобнее" это достойный аргумент).

Однако при этом есть определённые конвенции: тарбол кладётся в подкаталог, чтобы потом можно было использовать gear-update  при обновлении. Спек и патчи тогда можно класть в корень репозитория, а не прятать в .gear.

> +%files -n %lname
> +%_libdir/libfst*
> +%_libdir/fst/*.la
> +%_libdir/fst/*.so

*.la нужны для работы, или это всё-таки в -devel?

%_libdir/libfst* все нужны для работы, или что-то их можно положить в -devel?


> +%files -n %lname-devel
Почему не запакован каталог %_includedir/fst? Зачем перечислять все файлы?

> https://git.altlinux.org/people/guschin/packages/?p=openfst.git;a=summary
> %set_verify_elf_method rpath=relaxed

Может это всё-таки можно нормально починить?

Исправил указанные проблемы со спеками:
- https://git.altlinux.org/people/guschin/packages/?p=kernel-image-std-def.git;a=tree;h=refs/heads/mcom03-def;hb=mcom03-def
- https://git.altlinux.org/people/guschin/packages/?p=openfst.git;a=summary
- https://git.altlinux.org/people/guschin/packages/?p=python3-module-srt.git;a=summary
- https://git.altlinux.org/people/guschin/packages/?p=vosk-api.git;a=summary

> https://git.altlinux.org/people/guschin/packages/?p=vosk-api.git;a=summary

Я наконец рассмотрел, что происходит с тарболом kadi. Паковать его в общий тарбол а потом брать из .gear -- это нехорошо. Всё-таки лучше бы

- не класть .gear в тарбол vosk-api (exclude=.gear/**, а лучше собирать из gear-тега)
- сделать для kadi отдельный Source.

По мелочам:
- URL нужен, можно такой же или вместо VCS
- я не увидел, зачем нужен patchelf. он правда нужен?
- не думаю, что править .gitignore -- хорошая идея; если всё-таки править, то отдельным коммитом, так как это изменение не относится к сборке пакета.

> https://git.altlinux.org/people/guschin/packages/?p=python3-module-srt.git;a=summary

Можно подробнее, что там не так с gear-тегом и pytest'ом?

(Ответ для Ivan A. Melnikov на комментарий #27)
> > https://git.altlinux.org/people/guschin/packages/?p=python3-module-srt.git;a=summary
> 
> Можно подробнее, что там не так с gear-тегом и pytest'ом?

Кандидат видимо не осилил:
sed -i 's/ -n auto//' tox.ini
Ну а если без издёвки, то не обязательно пользоваться токсовым макросом, можно было бы запустить тесты например через %pyproject_run_pytest ну или даже просто через py.test-3. Хочу так же обратить внимание, что pytest является далеко не единственным способом тестировать питоновские модули. Разные апстримы могут это делать по-разному. Но как бы то ни было, такая мелочь не является основанием для отключения тестов.

>  https://git.altlinux.org/people/guschin/packages/?p=openfst.git;a=summary

Очень странно распределены файлы между libfst и libfst-devel. Андрей, давай разбираться, что это за файлы и зачем они нужны.

> - https://git.altlinux.org/people/guschin/packages/?p=kernel-image-std-def.git;a=tree;h=refs/heads/mcom03-def;hb=mcom03-def

В целом нормально скопированный спек. Я не против сборки ядер из коммита безо всяких kernel-source-x.y, хотя и рекомендовал бы организовать генерацию diff'ов 5.10..5.10.y и 5.10.y..HEAD например.

Непонятно, зачем нужны закомментированные строки в .gear/rules.

arch/arm64/configs/defconfig не кажется мне хорошим источником для конфига под конкретную плату;  к теме именно пакетирования это, конечно, не относится, но всё-таки я бы предложил пересмотреть состав конфига этого ядра.

Обновил пакеты
- https://git.altlinux.org/people/guschin/packages/?p=openfst.git;a=summary
- https://git.altlinux.org/people/guschin/packages/?p=vosk-api.git;a=summary
- https://git.altlinux.org/people/guschin/packages/?p=python3-module-srt.git;a=summary
- https://git.altlinux.org/people/guschin/packages/?p=linux.git;a=summary

Репозиторий kernel-image-std-def переименовал в linux, потому что, всё-таки, в нём не только kernel-image и не только std-def. Конкретно в flavour mcom03-def, конфиг мерджится из defconfig и mcom03_defconfig.

> https://git.altlinux.org/people/guschin/packages/?p=openfst.git;a=summary

Мне казалось, что в %_libdir/fst находятся файлы, нужные в процессе работы, а не сборки зависимостей. Что там находится? Зачем нужны эти файлы?

Почему на все мои вопросы ты отвечаешь только коммитами?)))

> https://git.altlinux.org/people/guschin/packages/?p=vosk-api.git;a=summary

Стало хорошо.

Единственный вопрос -- не нужно ли вынести заголовочный файл в отдельный devel подпакет?

>  https://git.altlinux.org/people/guschin/packages/?p=python3-module-srt.git;a=summary

Тут тоже нужен URL. Во всех пакетах нужен URL. В остальном ок.

> https://git.altlinux.org/people/guschin/packages/?p=linux.git;a=summary

(In reply to Ivan A. Melnikov from comment #30)
> В целом нормально скопированный спек. Я не против сборки ядер из коммита
> безо всяких kernel-source-x.y, хотя и рекомендовал бы организовать генерацию
> diff'ов 5.10..5.10.y и 5.10.y..HEAD например.

М?

> Непонятно, зачем нужны закомментированные строки в .gear/rules.

Всё ещё непонятно.

> arch/arm64/configs/defconfig не кажется мне хорошим источником для конфига
> под конкретную плату;  к теме именно пакетирования это, конечно, не
> относится, но всё-таки я бы предложил пересмотреть состав конфига этого ядра.

Не вижу в истории этого defconfig ничего специфичного для платы:

$ git diff 353757066776e78d9796fba25231a5797264a844 v5.10.160 -- arch/arm64/configs/defconfig
$

Так что он по прежнему не кажется мне хорошим источником для конфига под конкретную плату.

> Мне казалось, что в %_libdir/fst находятся файлы, нужные в процессе работы, а не сборки зависимостей. Что там находится? Зачем нужны эти файлы?

Насколько я понял, .la (и .so) файлы - это файлы, которые используются libtool. Каким образом они могут быть использованы при работе мне не известно. Никакие из остальных библиотек не линкуются с ними, как и libvosk.so

> Тут тоже нужен URL

Исправил спеку. В остальных пакетах URL есть. У меня было ощущение, что когда у проекта есть только страница на хостинге репозиториев, точнее будет указать только VCS.

> Единственный вопрос -- не нужно ли вынести заголовочный файл в отдельный devel подпакет?

Мне казалось странным выделять один хедер в отдельный пакет, но, наверное, имеет смысл. Исправил спеку.


С пакетом ядра буду разбираться.

Обновил ветку с ядром
- https://git.altlinux.org/people/guschin/packages/?p=linux.git;a=shortlog;h=refs/heads/spec-mcom03-5.10

Убрал defconfig и оставил только mcom03_defconfig. Размер директории с модулями уменьшился почти в два раза, но плата всё ещё запустилась и даже продолжила работать.

Также я решил переименовать flavour в mcom03-5.10, так как ожидается, что появится ядро mcom03 версии 6.6. Хотелось бы сохранить обе версии параллельно.

(In reply to Andrew Guschin from comment #36)
> > Тут тоже нужен URL
> 
> Исправил спеку. В остальных пакетах URL есть. У меня было ощущение, что
> когда у проекта есть только страница на хостинге репозиториев, точнее будет
> указать только VCS.
> 
> > Единственный вопрос -- не нужно ли вынести заголовочный файл в отдельный devel подпакет?
> 
> Мне казалось странным выделять один хедер в отдельный пакет, но, наверное,
> имеет смысл. Исправил спеку.

Я как-то пропустил тот факт, что эти изменения уже выложены и на них надо посмотреть. Меня можно пинговать активнее в таких ситуациях.

Эти пакеты выглядят готовыми. Пора переходить к следующему пункту Join.

Глеб, мы ждём тебя, или это я чего-то недоделал по процессу?

Изменил два других пакета
- http://git.altlinux.org/people/guschin/packages/openfst.git
- https://git.altlinux.org/people/guschin/packages/?p=linux.git;a=tree;h=refs/heads/spec-mcom03-5.10;hb=spec-mcom03-5.10

В openfst директория /usr/lib64/fst, похоже, действительно расширения, которые могут использоваться в рантайме. Добавил отдельные пакеты с расширениями и devel с хедерами расширений. Не уверен стоит ли делать по подпакету на каждое расширение.

В ядре всё же разобрался со сборкой из kernel-source-* и diff. Спеку и rules исправил.

ssh ключ на gyle.alt зарегистрирован.
Пакет alt-gpgkeys обновлён.
Адрес подписан на devel@.

T/J/S -> 3.6.

Поправил пакеты, чтобы собирались на всех сизифных архитектурах. Всё в тасках 356656 и 356734. Также разобрался с итерациями пакетов, больше не буду создавать лишних задач.

> Всё в тасках 356656 и 356734

По 356734: не очень понял схему с тегированным импортом тарбола. Зачем?

vosk-api использует не апстримную версию kaldi, а свой форк. Я не вижу смысла пакетировать его для одного приложения. Если опакетить, то апстрим, но vosk с ним не собирается.