Created attachment 10137 [details]
gpg public key for homura@altlinux.org

(Ответ для makise-homura на комментарий #0)
> Имя ментора: mike
ack

(In reply to makise-homura from comment #0)
> Created attachment 10136 [details]

С одной стороны, ключ в смысле типа и размера в порядке, а с другой стороны у него в конце CRLF, которые вызвали совершенно неожиданные проблемы в утилитах.

Не могли бы вы приложить ключ без CR?

(In reply to makise-homura from comment #1)
> Created attachment 10137 [details]
> gpg public key for homura@altlinux.org

Ok.

Created attachment 10238 [details]
ssh public key for homura@altlinux.org with LF EOLs

(Ответ для Gleb F-Malinovskiy на комментарий #3)
> Не могли бы вы приложить ключ без CR?
Приложил.

(In reply to makise-homura from comment #4)
> Created attachment 10238 [details]
> ssh public key for homura@altlinux.org with LF EOLs
Ok.

> (Ответ для Gleb F-Malinovskiy на комментарий #3)
> > Не могли бы вы приложить ключ без CR?
> Приложил.
Спасибо!

Собственно, Игорь ещё до размещения этой заявки освоил альтовый инструментарий в достаточной степени, чтобы собрать пару пакетов, один из которых уже в сизифе -- libcglm.spec Игорь написал сам и прислал, я лишь добавил .gear/rules и чуть причесал полученный спек: http://git.altlinux.org/gears/l/libcglm.git?p=libcglm.git;a=commitdiff;h=a6efb3de1584e574c7dc8840cdc9f2bd8a93fda9 -- а taisei.spec предлагаю привесить к данной баге в качестве первого пакета.

Иными словами, считаю, что Игорь вполне готов начать вступление
(что касается ключей, тут видней Глебу).

Created attachment 10263 [details]
spec for Taisei Project v.1.3.2

Прикладываю spec-файл того проекта, который я планирую добавить в Sisyphus (Touhou-подобная игра (даммаку-шутер), Taisei Project, https://taisei-project.org/).

Можем двигаться к 3.0 -- с моей стороны "добро".

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

T/J/S -> 2.3.

Игорь, прошу выложить taisei.git на git.alt и провести пробную сборку;
с вопросами пиши лично (или в devel-newbies@).

(Ответ для Michael Shigorin на комментарий #10)
> Игорь, прошу выложить taisei.git на git.alt и провести пробную сборку;
> с вопросами пиши лично (или в devel-newbies@).

Готово: http://git.altlinux.org/people/homura/packages/?p=taisei.git;a=summary
Проверил сборку с gear, собранный пакет установил и попробовал - работает.

(Ответ для makise-homura на комментарий #11)
> http://git.altlinux.org/people/homura/packages/?p=taisei.git;a=summary

Собирать решил в итоге из тарбола, а не апстримного гита с добавлением альтовых файликов?

В .gear/rules и spec-файле лучше заменить tar.xz на tar: содержимое srpm и так будет сжато xz по умолчанию, дважды жать -- лишь увеличивать объём и время.

В спеке сам бы сделал (поскольку нет технической необходимости в обрамлении):

-%setup -n %{name}-v%{version}
+%setup -n %name-v%version

Но это всё вопросы/предложения по оформлению, в целом пакет должен быть уже рабочим (отличия от того спека на основе твоего, что собирал я -- дополнение сборочных зависимостей).

2 glebfm: предлагаю переходить к шагу 3.

(Ответ для Michael Shigorin на комментарий #12)
> Собирать решил в итоге из тарбола, а не апстримного гита с добавлением
> альтовых файликов?
Да, потому что у них иногда ломается мастер, вдобавок в релизном тарболе у них сразу все субмодули есть, а если собирать из гита - то их придётся ручками вытаскивать и подкладывать, мне кажется, это лишняя работа, когда её уже за тебя мэйнтейнер апстрима сделал.

> В .gear/rules и spec-файле лучше заменить tar.xz на tar
Как выяснилось, в таком случае получится, что ради экономии пары минут при сборке мы ломаем осмысленность строки Source в RPM: поскольку .spec попадает в SRPM, и пользователь, получивший этот SRPM из репы, может захотеть узнать точную ссылку на ванильные исходники, а тут нам придётся сломать её, тоже заменив на .tar, которого на гитхабе нет. Выглядит это как-то очень неудачно, как по мне.

> -%setup -n %{name}-v%{version}
> +%setup -n %name-v%version
Сделал.

Собрал, проверил, что работает, закоммитил, добавил тег 1.3.2-alt2, пушнул в репу (также параллельно сделал пару улучшений в сборке, относящихся к OpenGL ES - теперь можно гамать даже на видюхах, которые поддерживают только GLES, но не GL).

На всякий случай: собрал вчера из gear на e2k с помощью gear-hsh, сборка успешна (если не считать тонны warning-ов о депрекации разных вещей - но это норма даже для ванильной сборки taisei на e2k). Правда, у меня нет машины с альтом, на которую можно поставить видюху, так что проверить работоспособность с рендерером, отличным от null, не смог: VNC+LLVMPIPE из-за недоработанности LCCRT крашатся даже на glxgears, не говоря уже о чём-то более сложном. Но с другой стороны, при --renderer null музыка играет, звуки издаются, на ввод программа реагирует корректно, так что считаю, что всё ок.

(Ответ для Michael Shigorin на комментарий #12)
> 2 glebfm: предлагаю переходить к шагу 3.

ping :)

Так-то тут уже можно и на отсмотр другим участником команды приглашать:
http://git.altlinux.org/people/homura/packages/?p=taisei.git

(Ответ для Michael Shigorin на комментарий #15) 
> Так-то тут уже можно и на отсмотр другим участником команды приглашать:

Джойн по одному пакету? Или я что-то неправильно понял?

(Ответ для Grigory Ustinov на комментарий #16)
> Джойн по одному пакету? Или я что-то неправильно понял?
А есть лимит по минимальному количеству пакетов, которые я должен собрать, чтобы их начали принимать в сизиф, а меня - в команду?
Просто про это ничего не было написано на вики.

(Ответ для makise-homura на комментарий #17)
> (Ответ для Grigory Ustinov на комментарий #16)
> > Джойн по одному пакету? Или я что-то неправильно понял?
> А есть лимит по минимальному количеству пакетов, которые я должен собрать,
> чтобы их начали принимать в сизиф, а меня - в команду?
> Просто про это ничего не было написано на вики.

Там было написано, что вы должны убедить ментора в том, что умеете собирать пакеты. Но поскольку ментор в силу человеческого фактора может отнестись попустительски к доверенной ему роли, ввели роль независимого рецензента. И в общем-то его тоже надо убедить в том, что вы достойны быть в команде.

По одному пакету это сделать довольно сложно, хотя я бы на месте рецензента точно бы отправил вас на продолжение обучения. В спеке фигурируют два питоновских модуля для второго питона, которых нет в сизифе. Этот пакет вообще не должен собраться.

(Ответ для Grigory Ustinov на комментарий #18)
> По одному пакету это сделать довольно сложно

Хорошо, какие тогда требования по минимальному количеству пакетов?

> В спеке фигурируют два
> питоновских модуля для второго питона, которых нет в сизифе. Этот пакет
> вообще не должен собраться.

Не является ли это багом hasher тогда? Как он подсасывает пакеты, которых нет в сизифе?

P.S. Пофиксил в спеке модули на соответствующие третьему питону, всё собирается (x86_64, e2k), повысил ревизию до -alt3, но как проверить, что подобных ошибок больше нет - не знаю. В вики это тоже не описано; там создаётся впечатление, что у hasher/gear-hsh нет проблем с изоляцией своего чрута от основной системы, но получается, они есть. Был бы хорош чеклист того, что стоит проверить начинающему сборщику в спеке из того, что не может проверить hasher/gear-hsh.

(Ответ для Grigory Ustinov на комментарий #16)
> > Так-то тут уже можно и на отсмотр другим участником команды приглашать:
> Джойн по одному пакету? Или я что-то неправильно понял?
Ну я с одним пакетом когда-то и пришёл (правда, за ним оперативно нарисовался второй, а дальше вообще понеслось и опомнился только сотнях на четырёх).  Точнее, вообще с однострочной правкой к коробочному конфигу webalizer.


(Ответ для makise-homura на комментарий #19)
> Хорошо, какие тогда требования по минимальному количеству пакетов?
Я таких не видел, но порой и впрямь просят представить более одного примера (того, чем собираешься заняться, или того, что готов пособирать в качестве пробного задания -- своего, как в данном разе, или существующего).

> > В спеке фигурируют два питоновских модуля для второго питона,
> > которых нет в сизифе. Этот пакет вообще не должен собраться. 
> Не является ли это багом hasher тогда? Как он подсасывает пакеты,
> которых нет в сизифе?
Это скорее особенность join -- надеюсь, мы не дождёмся ни четвёртого питона,
ни третьего halflife с этим запросом в состоянии "всё ещё открыто" ;-]
(скажем, bug 39887 удалось в итоге пройти весьма оперативно)

Второпитоновые модули из сизифа по большей части выпилили, в частности, и эти (ещё в августе прошлого года):
http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/src/p/python-module-docutils/
http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/src/p/python-module-Pygments/

А вот в p10 ещё есть и python-module-docutils, и python-module-Pygments -- если ты собирался на дистрибутиве, то неудивительно (если на сизифе, то такого же эффекта можно достичь, например, передав hsh --apt-config=/путь/к/apt.conf.p10 со ссылкой на sources.list.p10 в нём).

> P.S. Пофиксил в спеке модули на соответствующие третьему питону, всё
> собирается (x86_64, e2k), повысил ревизию до -alt3, но как проверить,
> что подобных ошибок больше нет - не знаю.
Проверил на sisyphus_e2k (v4) и sisyphus (x86_64), подтверждаю, собирается.

> Был бы хорош чеклист того, что стоит проверить начинающему сборщику в спеке
> из того, что не может проверить hasher/gear-hsh.
Что-то ещё проверит сборочница (гругря, репозиторные проверки, которые сложно организовать вдали от соответствующих метаданных) -- но всё равно не всё, поэтому "вредный" отсматривающий, когда докопы по существу, тут не менее полезен, чем "вредный" профессор или военпред.

(Ответ для Michael Shigorin на комментарий #20)
> (Ответ для Grigory Ustinov на комментарий #16)
> > > Так-то тут уже можно и на отсмотр другим участником команды приглашать:
> > Джойн по одному пакету? Или я что-то неправильно понял?
> Ну я с одним пакетом когда-то и пришёл (правда, за ним оперативно
> нарисовался второй, а дальше вообще понеслось и опомнился только сотнях на
> четырёх).  Точнее, вообще с однострочной правкой к коробочному конфигу
> webalizer.

Миш, если у тебя нет времени на помощь с обучением человека, передай менторство кому-нибудь, кому это интересно. Человек в BuildRequires пишет про python3-module-Pygments, хотя им там даже не пахнет. Ну и в ченджлоге творится полнейший бардак: https://git.altlinux.org/people/homura/packages/?p=taisei.git;a=commitdiff;h=9e801bdf3f5c27af7f1a00cd3c79bbfe7faa93fc

Так дело не пойдёт. Только не в мою смену.

(Ответ для Michael Shigorin на комментарий #20)
> если ты собирался на дистрибутиве, то неудивительно (если на сизифе, то
> такого же эффекта можно достичь, например, передав hsh
> --apt-config=/путь/к/apt.conf.p10 со ссылкой на sources.list.p10 в нём).
Ну у меня p10, обновлённый до сизифа. Способа поставить сизиф с нуля я не смог нигде найти. Разумеется, никаких --apt-config я хэшеру не передавал.
Как вообще можно проверить, что в сборку пошли только пакеты, изолированные от тех, что стоят на основной системе?

(Ответ для Grigory Ustinov на комментарий #21)
> Человек в BuildRequires пишет
> про python3-module-Pygments, хотя им там даже не пахнет.
Без него не генерится документация (сейчас специально проверил это):
[6/190] Generating 'doc/ENVIRON.html.p/ENVIRON.html'.
../doc/ENVIRON.rst:267: (WARNING/2) Cannot analyze code. Pygments package not found.
../doc/ENVIRON.rst:273: (WARNING/2) Cannot analyze code. Pygments package not found.
../doc/ENVIRON.rst:279: (WARNING/2) Cannot analyze code. Pygments package not found.
../doc/ENVIRON.rst:285: (WARNING/2) Cannot analyze code. Pygments package not found.
../doc/ENVIRON.rst:291: (WARNING/2) Cannot analyze code. Pygments package not found.
../doc/ENVIRON.rst:297: (WARNING/2) Cannot analyze code. Pygments package not found.
../doc/ENVIRON.rst:303: (WARNING/2) Cannot analyze code. Pygments package not found.

> Ну и в ченджлоге
> творится полнейший бардак:
> https://git.altlinux.org/people/homura/packages/?p=taisei.git;a=commitdiff;
> h=9e801bdf3f5c27af7f1a00cd3c79bbfe7faa93fc
Можно определение бардака (и опционально, полнейшего бардака) относительно чейнджлога? Хотя бы чтобы понять, к чему именно претензия. В идеале - какой-нибудь мануал на альтвики по чейнджлогам - ибо я не нашёл; такое чувство, что там с руководствами по сборке пакетов в сизиф творится тоже относительно заметный "бардак" - например, когда там аж три руководства (просто, "с нуля" и "с полного нуля"), ни одно из которых из коробки неприменимо и приходится в уме из всех трёх компоновать свой собственный путь.
P.S. Если речь о том, что в спеке один из комментов к чейнджлогу улетел в репу только со следующим коммитом, а не с тем, к которому он должен был быть - сорян, не заметил, поправил, отребейсил и форспушнул сейчас. Теперь должно быть всё нормально. (Непривычно, конечно, копипастить чейнджлог из гита руками, да ещё и "до" того, как сделан соответствующий коммит (а на самом деле "коммит - правка чейнджлога в спеке - аменд коммита - пуш"; здесь я как раз забыл отамендить последний коммит); из-за этого там могут возникать такие косяки, да).

(Ответ для makise-homura на комментарий #22)
> Как вообще можно проверить, что в сборку пошли только пакеты,
> изолированные от тех, что стоят на основной системе?

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

> В идеале - какой-нибудь мануал на альтвики по чейнджлогам - ибо я не нашёл

Думаю, Гриша про вот этот фрагмент:

 %changelog
-* Thu Mar 10 2022 Igor Molchanov <homura@altlinux.org> 1.3.2-alt2
+* Fri May 27 2022 Igor Molchanov <homura@altlinux.org> 1.3.2-alt3
+- Change python2 modules to python3 ones
+
+* Fri Mar 11 2022 Igor Molchanov <homura@altlinux.org> 1.3.2-alt2
+- Enable gles20 and gles30 renderers
+
+* Thu Mar 10 2022 Igor Molchanov <homura@altlinux.org>
 - Minor beautifying of spec and gear rules

Ченжлог задним числом лучше вовсе не переписывать, а только дополнять -- недостатка циферок для Release: на складе пока не наблюдается :)

А так, что самое смешное, есть даже отдельное http://altlinux.org/руководство_по_написанию_changelog -- немножко расширил секцию примеров, спасибо за вопрос.

> такое чувство, что там с руководствами по сборке пакетов в сизиф творится
> тоже относительно заметный "бардак" - например, когда там аж три руководства
> (просто, "с нуля" и "с полного нуля"), ни одно из которых из коробки
> неприменимо и приходится в уме из всех трёх компоновать свой собственный
> путь.

Вообще-то с полдюжины.  И это в смену и Гриши, и нас с Черепановым, и Димы с Гошей, ага.

> P.S. Если речь о том, что в спеке один из комментов к чейнджлогу улетел в
> репу только со следующим коммитом, а не с тем, к которому он должен был быть
> - сорян, не заметил, поправил, отребейсил и форспушнул сейчас.

Обычно стараюсь отсматривать на всякий git diff перед коммитом :)

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

Выработал привычку для сколь-нибудь нетривиальных изменений разделять работу над содержимым пакета, спеком и (отдельно!) описанием сделанного.

Бишь обновил-похакал-покоммитил по существу; затем потрогал спек и тоже закоммитил с хотя бы однострочным описанием (в идеале -- почему/зачем); затем поправил версию/релиз в спеке и уже к этому изменению написал %changelog (кстати, есть утилитка add_changelog и к ней пакетик для редактора -- vim-plugin-spec_alt-ftplugin; по \ac позволяет создать/добавить ченжлог минимальными телодвижениями) -- и вот для коммита таких изменений удобно применять gear-commit -a (сразу и commit message сформирует по записи в %changelog).

И да, всё это должно быть удобно и кратко расписано на вики :-/

(Ответ для Michael Shigorin на комментарий #23)
> т.е. можно,
> конечно, извратиться для получения в чруте в т.ч. пакетов, стоящих на
> основной системе, но это надо очень конкретно постараться.
Интересно тогда, как у меня такое получается, даже когда я этого не хочу...

> Думаю, Гриша про вот этот фрагмент:
Да, это я уже поправил.

> А так, что самое смешное, есть даже отдельное
> http://altlinux.org/руководство_по_написанию_changelog -- немножко расширил
> секцию примеров, спасибо за вопрос.
О, отлично, спасибо. Интересно, почему на него нигде ссылок нет из этих руководств (или я не нашёл...)

> Вообще-то с полдюжины.  И это в смену и Гриши, и нас с Черепановым, и Димы с
> Гошей, ага.
Лол, отличная ситуация. Пора ещё одно руководство писать (в полном соответствии с xkcd_14_standards.jpg) - о том, как новичку разобраться во всех этих руководствах. =)

> кстати, есть утилитка add_changelog
> удобно применять gear-commit -a
Хм, надо будет изучить.

> И да, всё это должно быть удобно и кратко расписано на вики :-/
Да уж, вопрос только - когда...

На всякий случай по просьбе @mike бампнул версию libcglm:
https://git.altlinux.org/people/homura/packages/libcglm.git

Собирается на e2kv4 и x86_64, также собирается зависящий от неё taisei (и на x86_64 проверено, что запускается).

Можно ли это считать за второй пакет?

2 glebfm: я всё так же считаю, что homura@ готов собирать пакеты в сизиф,
и прошу перейти к шагу 3.

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

T/J/S -> 3.5.

(Ответ для Gleb F-Malinovskiy на комментарий #27)
> T/J/S -> 3.5.
Благодарю; всё так же считаю (comment 26), что Игорь готов собирать пакеты в сизиф -- по крайней мере уже им собранные (libcglm уже требует обновления -- ftbfs, емнип, исправленный в текущей версии).

Миша, ты забыл поменять статус.

Призван рецензент (bircoph@) для независимой оценки готовности кандидата.

T/J/S -> 4.2.

Добрый день!

1) libcglm:

1.1) Рекомендую использовать
%define _unpackaged_files_terminate_build 1
в хедере spec.

Не использование _не_ является ошибкой, но данный макрос поможет избегать неупакованных файлов при обновлении пакета. Значение по-умолчанию 0 позволяет легко исключать из установки ненужные файлы, но по моему опыту в целом даёт больше проблем, чем пользы (т.е. есть пакеты, где разумен 0, но большинству лучше будет от 1).

1.2) Апстрим предоставляет тесты (CGLM_USE_TEST), но пакет их не использует. Рекомендуется включать тесты в пакетах, если нет веской причины для обратного. Для этого в spec есть секция %check.

2) taisei:

2.1) аналогично 1.1)

2.2) некорректный формат %changelog, проблемы с этим заголовком:
* Fri Mar 11 2022 Igor Molchanov <homura@altlinux.org>

Не указана версия. \ac в vim ругается, да и сборочница сругнётся. Исправить легко, объединив содержимое со следующей записью для alt3.

2.3) Source в tar.xz — это неправильно, особенно для достаточно упитанного пакета. Следует использовать tar. А для сохранения точного апстримного URL можно использовать комментарий выше.

2.4)
056-debuginfo.brp: WARNING: You have 1 stripped ELF objects. Please compile with debugging information!
056-debuginfo.brp: WARNING: An excerpt from the list of affected files follows:
  ./usr/bin/taisei

Нужно отключить strip для taisei, это легко делается. Дальше rpm-build сам выделит debuginfo в отдельный пакет.

2.5) Лицензия указана некорректно: там кроме MIT есть медиафайлы под CC-BY 4.0.

2.6) Документация ставится в неверсионированную директорию: /usr/share/doc/taisei вместо /usr/share/doc/taisei-1.3.2. Это не особо важная проблема, но лучше исправить.

Итого: в целом работа кандидатом проделана аккуратно, но есть ряд досадных ошибок. Считаю, что прямо сейчас кандидат не готов к самостоятельной работе в Сизифе. Рекомендую исправить обнаруженные проблемы.

(In reply to Andrew Savchenko from comment #31)
> 056-debuginfo.brp: WARNING: You have 1 stripped ELF objects. Please compile
> with debugging information!
> 056-debuginfo.brp: WARNING: An excerpt from the list of affected files
> follows:
>   ./usr/bin/taisei
> 
> Нужно отключить strip для taisei, это легко делается. Дальше rpm-build сам
> выделит debuginfo в отдельный пакет.

Ещё можно добавлять в spec-и

%define _stripped_files_terminate_build 1

тогда rpm в этом месте не только пожалуется.

(Ответ для Michael Shigorin на комментарий #28)
> (Ответ для Gleb F-Malinovskiy на комментарий #27)
> > T/J/S -> 3.5.
> Благодарю; всё так же считаю (comment 26), что Игорь готов собирать пакеты в
> сизиф -- по крайней мере уже им собранные (libcglm уже требует обновления --
> ftbfs, емнип, исправленный в текущей версии).

Пакет возвращён в Сизиф и обновлён до текущей версии:
git.altlinux.org/gears/l/libcglm.git

Ухх, прошу прощения за длительное отсутствие реакции, люто завалили работой, некогда было разбирать пакеты, только в последние пару недель-таки вернулся к этому.

Итак:

> 1) libcglm:
Я правильно понимаю по comment 33, что это уже сделали и более неактуально?

> 2.1) аналогично 1.1)
Commit e0ab34a

> 2.2) некорректный формат %changelog, проблемы с этим заголовком:
> * Fri Mar 11 2022 Igor Molchanov <homura@altlinux.org>
Commit 814dbd1

> 2.3) Source в tar.xz — это неправильно, особенно для достаточно упитанного
> пакета.
Commit a33e7f4

> 2.4)
> Нужно отключить strip для taisei
Commit c2cfec9

> 2.5) Лицензия указана некорректно: там кроме MIT есть медиафайлы под CC-BY
> 4.0.
Commit e2cf4e4

> 2.6) Документация ставится в неверсионированную директорию:
> /usr/share/doc/taisei вместо /usr/share/doc/taisei-1.3.2. Это не особо
> важная проблема, но лучше исправить.
А вот тут вопрос неоднозначный. По-хорошему, тут надо тогда версионировать всё, что лежит в share, но с другой стороны, оно может меняться между релизами (то есть, бинарник тоже надо версионировать, получается?). Или это такая полиси (если да, то где она описана в вики? Я не видел) у альта - всё, что кладётся в /usr/share/doc, версионировать вне зависимости от целесообразности (а версионирование остального при этом не обязательно)? На самом деле, когда я заглянул туда, я увидел реально необычную картину - почти все каталоги с версией, в отличие от всех остальных операционных систем - проверил на Ubuntu 20.04.4 LTS (Focal Fossa), Debian GNU/Linux 11 (bullseye), Elbrus Linux 7.1, Astra Linux (Smolensk 1.5). Не, ну если это реально фишка альта, то я, конечно, сделаю.

> Ещё можно добавлять в spec-и
> %define _stripped_files_terminate_build 1
Commit 18b84bb

(In reply to makise-homura from comment #34)
> Ухх, прошу прощения за длительное отсутствие реакции, люто завалили работой,
> некогда было разбирать пакеты, только в последние пару недель-таки вернулся
> к этому.

Все мы волонтеры в этом деле, так что ничего страшного.

> Итак:
> 
> > 1) libcglm:
> Я правильно понимаю по comment 33, что это уже сделали и более неактуально?

Там вернули пакет в Сизиф, но указанные замечания никто не исправлял.
1.1. — дело вкуса и хорошей, по моему мнению, практики
А вот 1.2. никто не исправлял.
 
> > 2.1) аналогично 1.1)
> Commit e0ab34a
> 
> > 2.2) некорректный формат %changelog, проблемы с этим заголовком:
> > * Fri Mar 11 2022 Igor Molchanov <homura@altlinux.org>
> Commit 814dbd1
> 
> > 2.3) Source в tar.xz — это неправильно, особенно для достаточно упитанного
> > пакета.
> Commit a33e7f4
> 
> > 2.4)
> > Нужно отключить strip для taisei
> Commit c2cfec9
> 
> > 2.5) Лицензия указана некорректно: там кроме MIT есть медиафайлы под CC-BY
> > 4.0.
> Commit e2cf4e4

Вс
 
> > 2.6) Документация ставится в неверсионированную директорию:
> > /usr/share/doc/taisei вместо /usr/share/doc/taisei-1.3.2. Это не особо
> > важная проблема, но лучше исправить.
> А вот тут вопрос неоднозначный. По-хорошему, тут надо тогда версионировать
> всё, что лежит в share, но с другой стороны, оно может меняться между
> релизами (то есть, бинарник тоже надо версионировать, получается?). Или это
> такая полиси (если да, то где она описана в вики? Я не видел) у альта - всё,
> что кладётся в /usr/share/doc, версионировать вне зависимости от
> целесообразности (а версионирование остального при этом не обязательно)? На
> самом деле, когда я заглянул туда, я увидел реально необычную картину -
> почти все каталоги с версией, в отличие от всех остальных операционных
> систем - проверил на Ubuntu 20.04.4 LTS (Focal Fossa), Debian GNU/Linux 11
> (bullseye), Elbrus Linux 7.1, Astra Linux (Smolensk 1.5). Не, ну если это
> реально фишка альта, то я, конечно, сделаю.
> 
> > Ещё можно добавлять в spec-и
> > %define _stripped_files_terminate_build 1
> Commit 18b84bb

Случайно отправил раньше, продолжаем.
[Как же раздражает в багзилле, что tab+space = отправить]

2.1-2.5 = Всё хорошо.

(In reply to makise-homura from comment #34)
> > 2.6) Документация ставится в неверсионированную директорию:
> > /usr/share/doc/taisei вместо /usr/share/doc/taisei-1.3.2. Это не особо
> > важная проблема, но лучше исправить.
> А вот тут вопрос неоднозначный. По-хорошему, тут надо тогда версионировать
> всё, что лежит в share, но с другой стороны, оно может меняться между
> релизами (то есть, бинарник тоже надо версионировать, получается?). Или это
> такая полиси (если да, то где она описана в вики? Я не видел) у альта - всё,
> что кладётся в /usr/share/doc, версионировать вне зависимости от
> целесообразности (а версионирование остального при этом не обязательно)? На
> самом деле, когда я заглянул туда, я увидел реально необычную картину -
> почти все каталоги с версией, в отличие от всех остальных операционных
> систем - проверил на Ubuntu 20.04.4 LTS (Focal Fossa), Debian GNU/Linux 11
> (bullseye), Elbrus Linux 7.1, Astra Linux (Smolensk 1.5). Не, ну если это
> реально фишка альта, то я, конечно, сделаю.

В Gentoo тоже всё с версиями в doc. Как по мне, это просто удобно — сразу видно на какую версию документация. Ну и в Gentoo в ряде случаев можно ставить две версии одного пакета. В Альте так нельзя, но может быть libfoo и libfoo2.

В общем, прошу переделать, чтоб было как у (почти) всех в Альте.

По совокупности проделанной работы считаю что homura@ (Игорь) готов к самостоятельной работе в Team. Мелочи можно доводить до блеска уже в ходе работы.

JFYI,

(In reply to makise-homura from comment #34)
> > 2.6) Документация ставится в неверсионированную директорию:
> > /usr/share/doc/taisei вместо /usr/share/doc/taisei-1.3.2. Это не особо
> > важная проблема, но лучше исправить.
> А вот тут вопрос неоднозначный. По-хорошему, тут надо тогда версионировать
> всё, что лежит в share, но с другой стороны, оно может меняться между
> релизами (то есть, бинарник тоже надо версионировать, получается?). Или это
> такая полиси (если да, то где она описана в вики? Я не видел) у альта - всё,
> что кладётся в /usr/share/doc, версионировать вне зависимости от
> целесообразности (а версионирование остального при этом не обязательно)? На
> самом деле, когда я заглянул туда, я увидел реально необычную картину -
> почти все каталоги с версией, в отличие от всех остальных операционных
> систем - проверил на Ubuntu 20.04.4 LTS (Focal Fossa), Debian GNU/Linux 11
> (bullseye), Elbrus Linux 7.1, Astra Linux (Smolensk 1.5). Не, ну если это
> реально фишка альта, то я, конечно, сделаю.

Неверсионированные каталоги в /usr/share/doc - это традиция из Debian,
версионированные каталоги в /usr/share/doc - это традиция из Red Hat,
обе традиции из прошлого тысячелетия, у каждой есть свои преимущества.

В ALT в /usr/share/doc преимущественно используются версионированные каталоги.

Адрес подписан на devel@.
Пользователь добавлен в группу мейнтейнеров.

Желаю удачного мейнтейнерства!