Псевдоним : guschin Почта : Andrew Guschin <guschin@altlinux.org> Пересылка почты : guschin.drew@gmail.com Имя ментора : Игорь Чудов Почта ментора : nir@altlinux.org Моя цель : Научиться собирать пакеты
Игорь, подтвердите, пожалуйста, что вы согласны на менторство.
Эта заявка недооформлена. Можете переоткрыть баг когда решите её оформить.
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 не кажется мне хорошим источником для конфига под конкретную плату; к теме именно пакетирования это, конечно, не относится, но всё-таки я бы предложил пересмотреть состав конфига этого ядра.
