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

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

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` чем-то хуже?