Created attachment 10136 [details] ssh public key for homura@altlinux.org Имя ментора: mike Псевдоним: homura Адрес почты: akemi_homura@kurisa.ch (если можно несколько, то тогда ещё Igor.A.Molchanov@mcst.ru) SSH- и GPG-ключи: в приложениях к багрепорту Цель: собрать для начала Taisei Project (https://taisei-project.org/), потом, возможно, что-то ещё (xnp2, dosbox-x, ...).
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@. Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства!
