Псевдоним : 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 не кажется мне хорошим источником для конфига под конкретную плату; к теме именно пакетирования это, конечно, не относится, но всё-таки я бы предложил пересмотреть состав конфига этого ядра.
Обновил пакеты - 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 с ним не собирается.
> 356656 если это ядро ещё актуально, то пусть будет
> 356734 200:python3-module-srt.git=3.5.3-alt1 Почему часть сборочных зависимостей в BuildRequires(pre), а часть просто в BuildRequires?
> 356734 > 1100:openfst.git=1.8.0-alt1 Как я писал выше, я не очень понял схему с импортом тарбола, можешь пояснить подробнее: - как это будет обновляться - чем такая схема хороша, по сравнению с "обычной" (с импортом тарбола в подкаталог a-la gear-srpmimport) Мне также не нравиться, что тег v1.8.0 на первый взгляд похож на апстримный, но таковым не является. А ещё я не смог собрать пакет, чтобы посмотреть на практике, как там разложены файлы.
> 356734 > 1500:vosk-api.git=0.3.45-alt1 Я бы всё-таки не держал запакованные исходники в гите. Можно распактовать тарбол прямо туда, где он будет лежать при сборке, и обратно запаковвывать его gear'ом; можно сделать каталог kaldi-vosk в .gear.
Я решил, что лучше всё-таки выложить какой-то промежуточный результат, а не выгружать сразу всё. Достаточно тривиальные пакеты: - #385470, https://git.altlinux.org/people/guschin/packages/?p=bore.git&a=summary - #385473, https://git.altlinux.org/people/guschin/packages/?p=fdm.git&a=summary - #385472, https://git.altlinux.org/people/guschin/packages/?p=oils-for-unix.git&a=summary - #385556, https://git.altlinux.org/people/guschin/packages/?p=openfst.git&a=summary - #385542, https://git.altlinux.org/people/guschin/packages/?p=tectonic.git&a=summary - #385543, https://git.altlinux.org/people/guschin/packages/?p=tuigreet.git&a=summary Некоторые пакеты даже успел обновить до новых версий. По поводу openfst: > Как я писал выше, я не очень понял схему с импортом тарбола, можешь пояснить подробнее: > - как это будет обновляться С помощью gear-import > Мне также не нравиться, что тег v1.8.0 на первый взгляд похож на апстримный, но таковым не является. Такой тег создаёт gear-import NMU: - https://git.altlinux.org/people/guschin/packages/?p=lact.git&a=summary - https://git.altlinux.org/people/guschin/packages/?p=linux-tools.git&a=summary Более нетривиальные пакеты в процессе допиливания до собирающегося и работающего состояния. vosk-api и python3-module-srt уже кто-то собрал в сизиф. Сам виноват, что так долго тянул. По поводу kernel-image-mcom03-5.10: > если это ядро ещё актуально, то пусть будет Уже не актуально, у скифа появилось 6.6.y. Может быть, когда-то его соберу. Но ему на замену я сейчас пакетирую немного другое ядро.
(Ответ для Ivan A. Melnikov на комментарий #48) > > 356734 > > > 1500:vosk-api.git=0.3.45-alt1 > > Я бы всё-таки не держал запакованные исходники в гите. Можно распактовать > тарбол прямо туда, где он будет лежать при сборке, и обратно запаковвывать > его gear'ом; можно сделать каталог kaldi-vosk в .gear. Да более того, kaldi-vosk это же библиотека kaldi, которая используется при сборке и подключается через find_package(kaldi REQUIRED) нужно просто собрать её в отдельный пакет и использовать при сборке. Если вдруг kaldi-vosk содержит какие-то специальные патчи именно для vosk, то можно собрать kaldi как libkaldi-vosk.
(In reply to Vitaly Lipatov from comment #50) > Если вдруг kaldi-vosk содержит какие-то специальные патчи именно для vosk, > то можно собрать kaldi как libkaldi-vosk. Именно так оно и есть. И не очень хотелось добавлять в репозиторий разделяемую библиотеку для ровно одного пакета и поэтому собирал её статически для vosk-api. При этом не очень понятно как может работать текущий собранный python3-module-vosk без подобного патча [1]. Прямо сейчас он и не работает... > >>> import vosk > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "/usr/lib/python3/site-packages/vosk/__init__.py", line 37, in <module> > _c = open_dll() > ^^^^^^^^^^ > File "/usr/lib/python3/site-packages/vosk/__init__.py", line 31, in open_dll > return _ffi.dlopen(os.path.join(dlldir, "libvosk.so")) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > OSError: cannot load library '/usr/lib/python3/site-packages/vosk/libvosk.so': /usr/lib/python3/site-packages/vosk/libvosk.so: cannot open shared object file: No such file or directory Я думаю, что в noarch пакете .so файлам не место. А libvosk.so нигде и не собран. И никаких SONAME и SOVERSION у него сейчас и не предполагается при сборке из апстрима. kaldi и openfst используются какие-то свои [2] и пытаться сопровождать это не вендоря их kaldi и openfst мне просто кажется бессмысленным. openfst я держал на более старой версии как раз для того, чтобы подружить vosk с апстримным openfst. Сделать я этого так и не смог. Возможно, стоит передать наработки ментейнеру python3-module-vosk и уже просто статически завендорить vosk-версии kaldi и openfst, чтобы этот пакет заработал. С этим я бы тогда наверное обратился к более опытным членам team, потому что историю с vosk-api я сейчас вижу для себя только так. Я (зря) потратил очень мого времени, чтобы подружить этот проект с апстримными разделяемыми библиотеками и у меня не получилось. openfst я сейчас обновил до последней версии с которой vosk-api не собирается. [1]: https://git.altlinux.org/people/guschin/packages/?p=vosk-api.git&a=blob&f=.gear/vosk-api-0.3.45-alt-linux-ffi.patch&h=616b42183931dd97f4de9d8eab4f1130e54e117e&hb=58460849fe6b3e7b799f9cc073e81be3cda48049 [2]: https://github.com/alphacep/vosk-api/blob/master/travis/Dockerfile.manylinux
(Ответ для Andrew Guschin на комментарий #51) > (In reply to Vitaly Lipatov from comment #50) > > Если вдруг kaldi-vosk содержит какие-то специальные патчи именно для vosk, > > то можно собрать kaldi как libkaldi-vosk. > Именно так оно и есть. И не очень хотелось добавлять в репозиторий > разделяемую библиотеку для ровно одного пакета и поэтому собирал её > статически для vosk-api. ничего нет страшного в добавлении библиотеки для одного пакета, если это позволяет всё это красиво сопровождать и не выглядеть недотёпой, укладывая zip с исходниками в git. > Я думаю, что в noarch пакете .so файлам не место. А libvosk.so нигде и не Это точно. > собран. И никаких SONAME и SOVERSION у него сейчас и не предполагается при > сборке из апстрима. > kaldi и openfst используются какие-то свои [2] и пытаться сопровождать это > не вендоря их kaldi и openfst мне просто кажется бессмысленным. openfst я Тогда можно вендорить, но более красиво. > держал на более старой версии как раз для того, чтобы подружить vosk с > апстримным openfst. Сделать я этого так и не смог. Возможно, стоит передать > наработки ментейнеру python3-module-vosk и уже просто статически завендорить > vosk-версии kaldi и openfst, чтобы этот пакет заработал. > > С этим я бы тогда наверное обратился к более опытным членам team, потому что > историю с vosk-api я сейчас вижу для себя только так. Я (зря) потратил очень > мого времени, чтобы подружить этот проект с апстримными разделяемыми > библиотеками и у меня не получилось. Это было не обязательно.
Ещё прошу заменить почту для пересылки на ayguschin@yandex.ru. Отправлять почту от своего имени @altlinux.org я не смог. Похоже, что гугл открутил возможность использования таких алиасов (и даже достаточно давно: [1]). Если есть ещё возможность использовать smtp gmail, то менять, наверное, не нужно. Но я такой возможности не нашёл. Очень не хочу заниматься поддержкой почты со своим доменом, поэтому хотел бы попробовать хотя бы яндекс.
Следующая пачка несколько более интересных пакетов: - #385102, https://git.altlinux.org/people/guschin/packages/?p=randomx.git&a=summary - #385102, https://git.altlinux.org/people/guschin/packages/?p=monero.git&a=summary - #390021, https://git.altlinux.org/people/guschin/packages/?p=linux.git&a=shortlog&h=refs/heads/spec-xenomai - #390021, https://git.altlinux.org/people/guschin/packages/?p=libevl.git&a=summary Ещё tuigreet нужно привести к тому, как остальные greetd гритеры пакетятся, но пока руки не дошли.
(In reply to Andrew Guschin from comment #49) > Я решил, что лучше всё-таки выложить какой-то промежуточный результат, а не > выгружать сразу всё. > > Достаточно тривиальные пакеты: > - #385470, > https://git.altlinux.org/people/guschin/packages/?p=bore.git&a=summary В целом ок, rust как rust, две просьбы: - у апстрима уже достаточно давно есть 0.6.0, обновитесь пожалуйста. - группа Terminals всё-таки для эмуляторов терминалов и подобных устройств[1], этот пакет больше похож на Networking/Other [1] в случае сомнений текущий состав группы удобно посмотреть на https://packages.altlinux.org/en/sisyphus/packages/Terminals/ .
(In reply to Andrew Guschin from comment #49) > Достаточно тривиальные пакеты: > - #385473, https://git.altlinux.org/people/guschin/packages/?p=fdm.git&a=summary lgtm, approved.
(In reply to Andrew Guschin from comment #49) > - #385472, https://git.altlinux.org/people/guschin/packages/?p=oils-for-unix.git&a=summary - `Summary: tmp`; - при живом (кажется) гите пакет собран из тарбола. Зачем? - последняя версия у апстрима 0.34.0.
> - `Summary: tmp`; Действительно, забыл. Не ожидал что соберётся с первого раза. > при живом (кажется) гите пакет собран из тарбола. Зачем? Апстрим разрабатывается на питоне, после чего с помощью своих инструментов транслируется в c++. Реальный релизный код распространяется только в тарболах.
(In reply to Andrew Guschin from comment #58) > Апстрим разрабатывается на питоне, после чего с помощью своих инструментов > транслируется в c++. omg > Реальный релизный код распространяется только в тарболах. Аругмент. Сóит упомянуть это в спеке, вместе с ссылкой на страницу загрузки релизных тарболов.
> #385543, https://git.altlinux.org/people/guschin/packages/?p=tuigreet.git&a=summary Увидел одну явную ошибку: > %attr(775,_greeter,_greeter) %dir %_cachedir/%name Значит, пользователь и группа должны существовать на момент распаковки пакета. То есть, на greetd должа быть зависимость вида `Requires(pre)`. Ну и какие-то мелочи: scdoc лучше вызвать в %build, положив результат рядом с исходниками. > %_altdir/greetd-tuigreet rpm-macros-alternatives лучше требовать явно, и через `BuildRequires(pre)`.
> #385542, https://git.altlinux.org/people/guschin/packages/?p=tectonic.git&a=summary Здесь лучше сохранить оригинальный апстримный тег. Например команда gear-store-tags v0.15.0 tectonic@0.15.0 создаст gear-tag v0.15.0, которым можно пользоваться, и файл 2ee60d7758f3554e2d6a590014ab33ac7bd14ac8 с содержимым оригинального апстримного тега. При этом в rules стоит написать какой-то комментарий, поясняющий, что поскольку у апстрима вот такой вот формат имён тегов, а "@" в gear нельзя, мы ими пользуемся вот так. По спеку в целом всё ок, кроме группы "Terminals", которая явно не про это. И что там с %check?
> - #385556, https://git.altlinux.org/people/guschin/packages/?p=openfst.git&a=summary Зачем делать теги от своего имени и потом сохранять их в .gear? `gear-update-tag <name> <commit sha> работает. Чем вообще в данном контексте `tar: v@version@:openfst` лучше чем `tar: openfst`? На остальное пока внимательно не смотрел, но вопросы ещё будут.
> #385102, https://git.altlinux.org/people/guschin/packages/?p=randomx.git&a=summary В целом ок. Единственное что, не вижу никаких причин не последовать за shared libs policy и не назвать пакет с библиотекой, например, `librandomx0`. > #385102, https://git.altlinux.org/people/guschin/packages/?p=monero.git&a=summary Интересный подход к сабмодулям. Но так ли это нужно? Чем не устроил minupnpc из репозитория например? Как используются остальные "завендоренные" сабмодули? Ну и по мелочам: > %package -n %name-devel-static Зачем тут -n? > %setup -D -q > %setup -D -a1 -a2 -a3 -a4 У певого %setup'а -D лучше убрать. А в один %setup оно не влазиет? -b0 -a[всё остальное]? > %_libdir/* > %ifarch %ix86 > %exclude %_libdir/debug/ > %endif Я понимаю, что у нас осталось мало 32-битных архитектур, но всё-таки лучше сделть то же самое аккуратнее. Просто `%libdir/lib*.a` чем-то хуже?
