Bug 38040

Created attachment 8582 [details]
SSH pubkey

Created attachment 8583 [details]
GPG ключ

*** Bug 38039 has been marked as a duplicate of this bug. ***

(In reply to Maxim Knyazev from comment #0)
> Ментор: klark@
Подтверждаю.

(In reply to Maxim Knyazev from comment #2)
> Created attachment 8583 [details]
> GPG ключ

Для gpg нужно указать имя в формате "<First name> <Last name>".

Created attachment 8637 [details]
Публичный ключ GPG

Свою ошибку исправил.

Подтверждаю. Дайте человеку доступ к сборочнице, пожалуйста.

Да, к гитовнице: T/J/S -> 2.0

> Email: Mattakushi10@mail.ru

К сожалению mail.ru -- сервис, который плохо сочетается с нашими списками рассылки.  У вас есть возможность выбрать другую почту для пересылки?

Почта:

mattakushiro@gmail.com

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

T/J/S -> 3.0.

Дайте, пожалуйста, человеку доступ к сборочнице.

Подготовил 11 пакетов, но мой gpg-ключ сборочница не принимает. Предоставляю лог:

$ ssh build.alt build 9wm 1.4.1-alt1
new task #248415: owner=mattaku repo=sisyphus
gpg: WARNING: unsafe ownership on homedir `/usr/lib/alt-gpgkeys'
gpg: Signature made Tue Mar 24 12:10:25 2020 UTC
gpg:                using RSA key 0xDCE36A69E8FAAE39
gpg: Can't check signature: public key not found
task add: 1.4.1-alt1: tag signature verification failure
removing task #248415 ... done

Уважаемый секретарь, ping.

Пакет alt-gpgkeys обновлён.

T/J/S -> 4.0.

Кандидат показал, что готов собирать пакеты.

С годовщиной!=)

Это ещё актуально?

(Ответ для Dmitry V. Levin на комментарий #18)
> Это ещё актуально?

Да, актуально. Прошу уважаемых менторов высказаться.

(In reply to Dmitry V. Levin from comment #18)
> Это ещё актуально?
"T/J/S -> 4.0" на март-2020 был последней стадией, тогда почему возник вопрос?

На тот момент было достаточно подтверждения одного (любого) ментора. Оно есть в комментарии #16. Сразу после этого джойна стали говорить, что ментор тот, кто указан первым. А уже в процессе джойна khab@ появился ещё и ментор со стороны. Это исправление: https://www.altlinux.org/index.php?title=Team%2FJoin%2FSecretary&type=revision&diff=50930&oldid=40945 датируется концом прошлого года, mattaku@ заджойнили в мае-2020 под мою ответственность.

Почему не закрыт баг -- не знаю, человек уже год у нас работает. И с мая прошлого года мы считали, что процедура завершена.

https://packages.altlinux.org/ru/sisyphus/maintainers/mattaku/tasks - согласно этому источнику, последний раз испытуемый собирал пакеты очень давно ещё до Н.Э. (Начала Эпидемии). Я уверен, что не только мне, но и всем остальным принимающим участие в этом процессе было бы интересно посмотреть на актуальные способности указанного кандидата.

(In reply to Leonid Krivoshein from comment #20)
> Почему не закрыт баг -- не знаю, человек уже год у нас работает. И с мая
> прошлого года мы считали, что процедура завершена.

Процедура находится на стадии [4.0] в новой нумерации.
Если кандидату уже не нужно завершать процедуру вступления, то лучше сказать об этом прямо.

(Ответ для Grigory Ustinov на комментарий #21)
> https://packages.altlinux.org/ru/sisyphus/maintainers/mattaku/tasks -
> согласно этому источнику, последний раз испытуемый собирал пакеты очень
> давно 

  А ты 
https://packages.altlinux.org/ru/sisyphus/maintainers/grenka/tasks
  не смотрел? :-) Там больше полугода нет изменений :(

(Ответ для Andrew Vasilyev на комментарий #23)
> (Ответ для Grigory Ustinov на комментарий #21)
> > https://packages.altlinux.org/ru/sisyphus/maintainers/mattaku/tasks -
> > согласно этому источнику, последний раз испытуемый собирал пакеты очень
> > давно 
> 
>   А ты 
> https://packages.altlinux.org/ru/sisyphus/maintainers/grenka/tasks
>   не смотрел? :-) Там больше полугода нет изменений :(

Ну я готовлю питоний мегатаск, мне простительно=)) Но если без шуток, то в отношении испытуемого указанная статистика верная, потому что я смотрел по письмам от сборочницы, просто не все же подписаны на этот список рассылки.

Согласно другому источнику последнее использование им нашей инфраструктуры было в июне 2020, уже сильно после Н.Э.:

http://git.altlinux.org/people/mattaku/packages/?p=fonts-ttf-astloch.git;a=commit;h=3e92fd4f961045e6f85cc0f6bb93e84e607dce0b

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

(In reply to Dmitry V. Levin from comment #22)
> Процедура находится на стадии [4.0] в новой нумерации.
Почему в новой? Новая появилась в декабре 2020, он заджойнился в мае 2020. Можно узнать тут причину? Баг моего джойна тоже не закрыт, мне теперь тоже до 5.0 доползать? :-) А как с остальными тимовцами?

(Ответ для Leonid Krivoshein на комментарий #25)
> Сборка, как основное занятие, для
> него уже тогда фактически закончилась -- сейчас у него другие рабочие
> задачи, он занимается поиском ошибок и переводами, насколько я знаю. Тут
> лучше пусть Андрей пояснит, как можно оценить его актуальные способности. 

А зачем тогда вообще нужен джойн и доступ к сборочнице, если человеку это не нужно? Выглядит, как пустая трата времени.
 
> Можно узнать тут причину? Баг моего джойна тоже не закрыт, мне теперь тоже
> до 5.0 доползать? :-) А как с остальными тимовцами?

Баги надо закрывать=))

(In reply to Leonid Krivoshein from comment #25)
> (In reply to Dmitry V. Levin from comment #22)
> > Процедура находится на стадии [4.0] в новой нумерации.
> Почему в новой? Новая появилась в декабре 2020, он заджойнился в мае 2020.

Я просто констатирую факт: процедура находится на стадии [4.0] в новой нумерации.

(In reply to Grigory Ustinov from comment #26)
> А зачем тогда вообще нужен джойн
Конкретно для него это было условием приёма на работу в отдел Андрея.

> и доступ к сборочнице, если человеку это не
> нужно? Выглядит, как пустая трата времени.
Чтобы работать в команде и, при необходимости, этим пользоваться. Но не я его начальник.

> Баги надо закрывать=))
Кто должен был закрыть этот баг, я? Извиняюсь, если что-то упустил.

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

(In reply to Leonid Krivoshein from comment #28)
> (In reply to Grigory Ustinov from comment #26)
> > А зачем тогда вообще нужен джойн
> Конкретно для него это было условием приёма на работу в отдел Андрея.

Это профанация join'а.  Не делайте так, пожалуйста.
Во многом из-за этого в процедуру и была введена ещё одна стадия.

А зачем нам такой в отделе сопровождения?

(In reply to Grigory Ustinov from comment #26)
> (Ответ для Leonid Krivoshein на комментарий #25)
> > Сборка, как основное занятие, для
> > него уже тогда фактически закончилась -- сейчас у него другие рабочие
> > задачи, он занимается поиском ошибок и переводами, насколько я знаю. Тут
> > лучше пусть Андрей пояснит, как можно оценить его актуальные способности. 
> 
> А зачем тогда вообще нужен джойн и доступ к сборочнице, если человеку это не
> нужно? Выглядит, как пустая трата времени.

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

Человек прямо сейчас не коммитит, что в этом плохого? Предположу, что нужное уже в репо. Как появится новая необходимость, закоммитит ещё.

Максим, вам ещё интересно завершать процедуру вступления в team?

(Ответ для Dmitry V. Levin на комментарий #32)
> Максим, вам ещё интересно завершать процедуру вступления в team?

Добрый вечер, да, конечно

Попробую позвать ещё одного человека (darktemplar@) для независимой оценки готовности кандидата.

Пожелания, замечания, проблемы, вопросы:
1) Пожелание по всем пакетам: не указывать тэг "Packager:". Оно автоматически заполняется.

2) Следующие пакеты не соответствует руководству по указанию версии и релиза:
https://www.altlinux.org/Spec#Version
https://www.altlinux.org/Spec#Release

Собираются не апстримные версии. Выглядит так, будто собирается из апстрима последний на момент сборки коммит из master или другой ветки, а указывается последняя версия из апстрима.

http://git.altlinux.org/people/mattaku/packages/?p=pspg.git;a=summary
http://git.altlinux.org/people/mattaku/packages/?p=pyte.git;a=summary
http://git.altlinux.org/people/mattaku/packages/?p=bear.git;a=summary
http://git.altlinux.org/people/mattaku/packages/?p=libaec.git;a=summary
http://git.altlinux.org/people/mattaku/packages/?p=ocproxy.git;a=summary
http://git.altlinux.org/people/mattaku/packages/?p=peek.git;a=summary
http://git.altlinux.org/people/mattaku/packages/?p=webtech.git;a=summary
http://git.altlinux.org/people/mattaku/packages/?p=nawk.git;a=summary
http://git.altlinux.org/people/mattaku/packages/?p=qodem.git;a=summary
http://git.altlinux.org/people/mattaku/packages/?p=vkmark.git;a=summary
http://git.altlinux.org/people/mattaku/packages/?p=airspyone_host.git;a=summary
http://git.altlinux.org/people/mattaku/packages/?p=meteo.git;a=summary
http://git.altlinux.org/people/mattaku/packages/?p=sequeler.git;a=summary

3) http://git.altlinux.org/people/mattaku/packages/?p=apetag.git;a=commitdiff;h=2df3a14252757983422b353892db5115e8244353

-%doc 00copying 00readme index.html

Зачем здесь удаляется документация?

4) http://git.altlinux.org/people/mattaku/packages/?p=pyte.git;a=summary

Пакет не собирается. Прошу прокомментировать.

Более того, в Сизифе и p9 уже есть pyte (python-module-pyte/python3-module-pyte), пусть и более старой версии. В связи с этим, новые проверки введённые ldv@ этот дубликат пакета не пропустят, а если нужна более новая версия, то надо обновлять уже существующие пакеты, а не собирать ещё одну копию с нуля.

5) http://git.altlinux.org/people/mattaku/packages/?p=bear.git;a=commitdiff;h=9f0d6edb1b820783067a0ef47a33f7b1411833c5

Зачем здесь указано "BuildRequires: clang" ? Насколько я вижу, эта зависимость при сборке не используется.

6) http://git.altlinux.org/people/mattaku/packages/?p=libaec.git;a=commitdiff;h=d81148f6cbbca11d02fa7b4f98910375ed596bf4

6.1) Requires: %name%{?_isa} = %version-%release

Правильно ли я понимаю, что данный спек брался откуда-то ещё и перерабатывался? Подобные строки часто бывают в спеках Fedora, в том числе автоимпортированных в ALT.
Согласно руководству https://www.altlinux.org/Руководство_по_написанию_changelog :
"Если .spec-файл адаптирован из другого дистрибутива, то старые записи %changelog обязательно должны быть сохранены".
Прошу следовать данному руководству, и если я угадал, что спек сделан на основе спека из другого дистрибутива, то вернуть записи %changelog. Тоже касается других spec-файлов, где это может быть актуально.

6.2) %_man1dir/aec.1.xz

Указывать явно суффикс сжатых man-страниц вредно. Когда в очередной раз используемое сжатие для man-страниц сменится, а вместе с ним и суффикс сжатых файлов, из-за этой строки пакет перестанет собираться. Я считаю, что лучше писать "%_man1dir/aec.1*" - в таком случае будет всё работать вне зависимости от используемого сжатия или его отсутствия.

6.3) Я считаю, что группа "Sciences/Computer science" точно не подходит пакету libaec-devel, а также возможно пакету libaec тоже. Для devel-пакетов обычно используются группы Development/*.

7) http://git.altlinux.org/people/mattaku/packages/?p=9wm.git;a=commitdiff;h=44c0672750dc81d966529acdc456de9946cd62e9

В данном пакете в .gear/rules указано только:

tar: @version@:.

При такой записи в .gear/rules лично я ожидаю, что последний коммит из апстрима в этой ветке будет @version@, но вместо этого там другой коммит.
Т.е. ожидается такая цепочка коммитов:
upstream commits -> @version@ -> maintainer's commits
В реальности здесь следующая цепочка коммитов:
upstream commits -> @version@ -> upstream commits again -> maintainer's commits

Вот эти условно названные "upstream commits again" при сборке втихую пропадут. В данном случае это коммиты:
http://git.altlinux.org/people/mattaku/packages/?p=9wm.git;a=commitdiff;h=f3985769cdff50ba1c87db3c22eab8396d448adc
http://git.altlinux.org/people/mattaku/packages/?p=9wm.git;a=commitdiff;h=b1278751d85ac2a8d41a87fc9d71e61434725e45

Чем мне это не нравится? Файлы в репозитории, и файлы, используемые во время сборки, с учётом всех патчей, имеют отличия, и это никак не отражено ни в .gear/rules, ни в spec-файле. Я считаю, что репозиторий должен отражать то состояние исходников, из которого пакет будет собираться. При этом изменения могут лежать как отдельно в файлах *.patch, так и уже быть наложенными на апстримные исходники. В данном же случае передо мной одни исходники, а при сборке - другие, пусть в данном случае различий и немного.

8) http://git.altlinux.org/people/mattaku/packages/?p=aeskeyfind.git;a=commitdiff;h=920495efc7bd6512a7fe3e11c0fa16f09e6a2236

Зачем данный пакет содержит директорию /usr/share/man/man1/man1?

9) http://git.altlinux.org/people/mattaku/packages/?p=taigo.git;a=commitdiff;h=ed18396ad81f5acc19899fecbcd1f13b4ddd5126

Данный пакет владеет директориями /usr/share/icons/hicolor/scalable/apps и /usr/share/metainfo. Я считаю это ошибкой упаковки. Данные директории не должны принадлежать этому пакету. У первой должен быть владелец только пакет icon-theme-hicolor, вторую тоже давно пора включить в какой-нибудь системный пакет.

9) http://git.altlinux.org/people/mattaku/packages/?p=passivetex.git;a=commitdiff;h=0cf79b22b7d7035035b881588ff052eb744e180f

install -m 0755 -p -d $RPM_BUILD_ROOT%_datadir/texmf/tex/xmltex/passivetex
install -m 0644 -p *.sty *.xmt $RPM_BUILD_ROOT%_datadir/texmf/tex/xmltex/passivetex

Был ли данный спек адаптирован откуда-либо? $RPM_BUILD_ROOT опять же чаще встречается в спеках Федоры скорее, чем в ALT. В ALT обычно принято использовать макрос %buildroot. Если это так, то всё указанное для changelog libaec актуально и здесь.

10) http://git.altlinux.org/people/mattaku/packages/?p=sequeler.git;a=summary

Указана версия 0.7.3, а исходники соответствуют апстримной версии 0.7.4. Я считаю это ошибкой.

11) http://git.altlinux.org/people/mattaku/packages/?p=peek.git;a=commitdiff;h=1ddf008faab865fe3a8b3c956281aa418801c9d8

Опять пакету принадлежат директории %_datadir/metainfo и %_iconsdir/hicolor/*.

12) http://git.altlinux.org/people/mattaku/packages/?p=webtech.git;a=commitdiff;h=c0a4e91e1d1ebe2d359ab247db652cf4fa9584a7

Group: Development/Python

Считаю, что в данном случае больше подойдёт группа Development/Python3.

13) http://git.altlinux.org/people/mattaku/packages/?p=nawk.git;a=commitdiff;h=93e24279f3a2bd034c9da5f473cbc163e939f8ad

13.1) Данные сборочные зависимости явно указывать не требуется:

BuildRequires: gcc
BuildRequires: glibc-devel

13.2) rm -rf %buildroot

Поскольку сборка обычно происходит в hasher, очищать %buildroot не нужно. Опять же такое часто встречается в спеках из других дистрибутивов. Является ли данный спек адаптированным? Если да, то %changelog не был сохранён.

14) git://git.altlinux.org/people/mattaku/packages/qodem.git

Возможно раньше пакет и собирался, но сейчас - не собирается.

15) http://git.altlinux.org/people/mattaku/packages/?p=vkmark.git;a=summary

15.1) Возможно раньше пакет и собирался, но сейчас - не собирается.

15.2) http://git.altlinux.org/people/mattaku/packages/?p=vkmark.git;a=commitdiff;h=b9d785b6064a6f98b64d25992b9d4759164e5eb2

Зачем здесь следующая runtime зависимость нужна?
Requires: libassimp-devel

Также вопрос вызывают следующие строки:

BuildRequires: assimp-devel
BuildRequires: libassimp-devel

Зачем они нужны вместе? Должно быть достаточно одной из них.

16) http://git.altlinux.org/people/mattaku/packages/?p=airspyone_host.git;a=commitdiff;h=8244027a86604d036aed3fe566da527a917b2273

16.1) Requires: libgudev-devel

Зачем данному пакету эта runtime зависимость?

16.2) Requires: %name%{?_isa} = %version-%release
make %{?_smp_mflags}

Эти строки опять-таки указывают что спек был адаптирован.

17) http://git.altlinux.org/people/mattaku/packages/?p=meteo.git;a=commitdiff;h=9d5c4ac2497fe51f6f700aedb472f5cfffecb2a6

Несмотря на наличие в секции %install строки "%find_lang %appname" в секции %files все переводы перечисляются явно вместо использования результата работы %find_lang:

%_datadir/locale/*/*/com.gitlab.bitseater.meteo.mo

Насколько мне известно, переводы по возможности принято делать через %find_lang и использование результатов этого вызова. Очень странно видеть явное перечисление переводов когда почти всё готово для использования результатов %find_lang. Прошу упаковать переводы через %find_lang, а не через явное перечисление переводов.

См. также: https://www.altlinux.org/FindLang_Policy

18) http://git.altlinux.org/tasks/250522/

%_libexecdir/python3/site-packages -> %python3_sitelibdir_noarch.

Ну и ошибка при сборке присутствует.

19) Пожелание: в некоторых спеках встречаются выражения "%{_mandir}/man1" или "%_mandir/man1". В ALT, насколько мне известно, принято вместо этого писать "%_man1dir", и в других спеках это даже встречается. Хорошо бы следовать принятому в ALT использованию макросов.

Также указанные ранее макросы "%{?_smp_mflags}", "%{?_isa}" и подобные в ALT не используются обычно. И вместо %version-%release советую использовать %EVR.

20) У многих пакетов указана группа "Emulators". Я считаю, что выбор сделан неверно. Насколько я вижу, в этой группе обычно находятся: средства виртуализации (типа qemu, virtualbox), эмуляции (типа pcsx2, dosbox, dosemu) и wine (хотя это слой совместимости, а не эмулятор). Например, для эмуляторов терминалов есть другая группа - "Terminals".



Заключение:
1) В большинстве пакетов судя по всему собирается master под видом релиза без указания этого в каком-либо виде, а в одном из пакетов вообще упакована другая версия, скорее всего находившаяся в master на момент сборки пакета. В дополнение к этому, почти везде используется директива gear "tar: .". Обычно так выглядит репозиторий у вступающего, который ещё не освоился с git и gear достаточно хорошо. Я такое расхождение указанной версии и реальной версии считаю ошибкой. Если есть необходимость всё-же собирать не релиз, а другую версию, то стоит собираемую версию явно указывать каким-либо образом, и хорошо бы озвучить такую необходимость здесь.
2) У многих спеков есть признаки, что это просто адаптация спека из другого дистрибутива. Я ничего не имею против такой адаптации, особенно если она сделана хорошо. В данном случае я не могу сказать что она сделана хорошо. В дополнение к этому, не сохранён %changelog адаптированных спеков, что противоречит руководству по changelog. Более того, у меня есть подозрение, что все новые пакеты являются адаптацией пакетов из других дистрибутивов. Если это так, то это не позволяет оценить насколько хорошо вступающий умеет писать спеки сам. Но я не знаю, является ли это обязательным требованием.

Я считаю, что вступающий недостаточно хорошо освоил используемые инструменты (как минимум git и gear), ситуация с %changelog скорее всего требует исправления тоже. Ну и пока исправляются эти 2 проблемы, стоит и остальные посмотреть, поскольку в спеках немало спорных моментов и проблемных мест.

(In reply to Aleksei Nikiforov from comment #35)
> Пожелания, замечания, проблемы, вопросы:
> 1) Пожелание по всем пакетам: не указывать тэг "Packager:". Оно
> автоматически заполняется.

Видимо, за исключением коллективных Packager из домена packages.altlinux.org.
Вероятно, в данном случае таких нет.

(Ответ для Aleksei Nikiforov на комментарий #35)

Спасибо, Алексей! Я восхищён вашим терпением и внимательностью к делегированному вам вопросу. Вы проделали колоссальную работу, в том числе и по реабилитации моей репутации в качестве ментора.

К сожалению за год много воды утекло и сейчас представляется трудным установить, где были применены мои указания, а где нет. Тем не менее некоторые из указанных пакетов мне знакомы.

Мои комментарии к замечаниям:
1.) Поле packager не запрещено. Мне оно глаза не режет и я сам его использую. Так что это всего лишь пожелание.

6.1) Надо удалить %{?_isa}. У нас это не используется.

8.) Опечатка. /usr/share/man/man1 А так да.

9.) На момент прошлого года это ещё не считалось ошибкой упаковки. К сожалению тогда это был единственный известный мне способ борьбы с postinstall unowned files. Я сам так делал=( Сейчас в своих пакетах переделываю.

13.1) Об этом я говорил минимум 2 раза в других пакетах.

Пользуясь случаем хотелось бы поинтересоваться вопросом адаптации спеков из других дистрибутивов. Понятное дело, что в различных дистрибутивах свои особенности написания спек-файлов. Тем не менее, надо признать, что существуют общие для всех вещи типа секции description или даже build и install. Надо ли указывать ченджлог дистрибутива, из которого был выдернут спек, если адаптация была выполнена на очень высоком уровне? На мой взгляд, было бы правильным формализировать этот вопрос указанием процента совпадений.

2mattaku: Буду ждать исправлений и сборки новых пакетов, в качестве подтверждения усвоенных замечаний.

(Ответ для Aleksei Nikiforov на комментарий #35)
> Пожелания, замечания, проблемы, вопросы:
> 1) Пожелание по всем пакетам: не указывать тэг "Packager:". Оно
> автоматически заполняется.
> 
> 2) Следующие пакеты не соответствует руководству по указанию версии и релиза:
> https://www.altlinux.org/Spec#Version
> https://www.altlinux.org/Spec#Release
> 
> Собираются не апстримные версии. Выглядит так, будто собирается из апстрима
> последний на момент сборки коммит из master или другой ветки, а указывается
> последняя версия из апстрима.
> 
> http://git.altlinux.org/people/mattaku/packages/?p=pspg.git;a=summary
> http://git.altlinux.org/people/mattaku/packages/?p=pyte.git;a=summary
> http://git.altlinux.org/people/mattaku/packages/?p=bear.git;a=summary
> http://git.altlinux.org/people/mattaku/packages/?p=libaec.git;a=summary
> http://git.altlinux.org/people/mattaku/packages/?p=ocproxy.git;a=summary
> http://git.altlinux.org/people/mattaku/packages/?p=peek.git;a=summary
> http://git.altlinux.org/people/mattaku/packages/?p=webtech.git;a=summary
> http://git.altlinux.org/people/mattaku/packages/?p=nawk.git;a=summary
> http://git.altlinux.org/people/mattaku/packages/?p=qodem.git;a=summary
> http://git.altlinux.org/people/mattaku/packages/?p=vkmark.git;a=summary
> http://git.altlinux.org/people/mattaku/packages/?p=airspyone_host.git;
> a=summary
> http://git.altlinux.org/people/mattaku/packages/?p=meteo.git;a=summary
> http://git.altlinux.org/people/mattaku/packages/?p=sequeler.git;a=summary
> 
> 3)
> http://git.altlinux.org/people/mattaku/packages/?p=apetag.git;a=commitdiff;
> h=2df3a14252757983422b353892db5115e8244353
> 
> -%doc 00copying 00readme index.html
> 
> Зачем здесь удаляется документация?
> 
> 4) http://git.altlinux.org/people/mattaku/packages/?p=pyte.git;a=summary
> 
> Пакет не собирается. Прошу прокомментировать.
> 
> Более того, в Сизифе и p9 уже есть pyte
> (python-module-pyte/python3-module-pyte), пусть и более старой версии. В
> связи с этим, новые проверки введённые ldv@ этот дубликат пакета не
> пропустят, а если нужна более новая версия, то надо обновлять уже
> существующие пакеты, а не собирать ещё одну копию с нуля.
> 
> 5)
> http://git.altlinux.org/people/mattaku/packages/?p=bear.git;a=commitdiff;
> h=9f0d6edb1b820783067a0ef47a33f7b1411833c5
> 
> Зачем здесь указано "BuildRequires: clang" ? Насколько я вижу, эта
> зависимость при сборке не используется.
> 
> 6)
> http://git.altlinux.org/people/mattaku/packages/?p=libaec.git;a=commitdiff;
> h=d81148f6cbbca11d02fa7b4f98910375ed596bf4
> 
> 6.1) Requires: %name%{?_isa} = %version-%release
> 
> Правильно ли я понимаю, что данный спек брался откуда-то ещё и
> перерабатывался? Подобные строки часто бывают в спеках Fedora, в том числе
> автоимпортированных в ALT.
> Согласно руководству
> https://www.altlinux.org/Руководство_по_написанию_changelog :
> "Если .spec-файл адаптирован из другого дистрибутива, то старые записи
> %changelog обязательно должны быть сохранены".
> Прошу следовать данному руководству, и если я угадал, что спек сделан на
> основе спека из другого дистрибутива, то вернуть записи %changelog. Тоже
> касается других spec-файлов, где это может быть актуально.
> 
> 6.2) %_man1dir/aec.1.xz
> 
> Указывать явно суффикс сжатых man-страниц вредно. Когда в очередной раз
> используемое сжатие для man-страниц сменится, а вместе с ним и суффикс
> сжатых файлов, из-за этой строки пакет перестанет собираться. Я считаю, что
> лучше писать "%_man1dir/aec.1*" - в таком случае будет всё работать вне
> зависимости от используемого сжатия или его отсутствия.
> 
> 6.3) Я считаю, что группа "Sciences/Computer science" точно не подходит
> пакету libaec-devel, а также возможно пакету libaec тоже. Для devel-пакетов
> обычно используются группы Development/*.
> 
> 7)
> http://git.altlinux.org/people/mattaku/packages/?p=9wm.git;a=commitdiff;
> h=44c0672750dc81d966529acdc456de9946cd62e9
> 
> В данном пакете в .gear/rules указано только:
> 
> tar: @version@:.
> 
> При такой записи в .gear/rules лично я ожидаю, что последний коммит из
> апстрима в этой ветке будет @version@, но вместо этого там другой коммит.
> Т.е. ожидается такая цепочка коммитов:
> upstream commits -> @version@ -> maintainer's commits
> В реальности здесь следующая цепочка коммитов:
> upstream commits -> @version@ -> upstream commits again -> maintainer's
> commits
> 
> Вот эти условно названные "upstream commits again" при сборке втихую
> пропадут. В данном случае это коммиты:
> http://git.altlinux.org/people/mattaku/packages/?p=9wm.git;a=commitdiff;
> h=f3985769cdff50ba1c87db3c22eab8396d448adc
> http://git.altlinux.org/people/mattaku/packages/?p=9wm.git;a=commitdiff;
> h=b1278751d85ac2a8d41a87fc9d71e61434725e45
> 
> Чем мне это не нравится? Файлы в репозитории, и файлы, используемые во время
> сборки, с учётом всех патчей, имеют отличия, и это никак не отражено ни в
> .gear/rules, ни в spec-файле. Я считаю, что репозиторий должен отражать то
> состояние исходников, из которого пакет будет собираться. При этом изменения
> могут лежать как отдельно в файлах *.patch, так и уже быть наложенными на
> апстримные исходники. В данном же случае передо мной одни исходники, а при
> сборке - другие, пусть в данном случае различий и немного.
> 
> 8)
> http://git.altlinux.org/people/mattaku/packages/?p=aeskeyfind.git;
> a=commitdiff;h=920495efc7bd6512a7fe3e11c0fa16f09e6a2236
> 
> Зачем данный пакет содержит директорию /usr/share/man/man1/man1?
> 
> 9)
> http://git.altlinux.org/people/mattaku/packages/?p=taigo.git;a=commitdiff;
> h=ed18396ad81f5acc19899fecbcd1f13b4ddd5126
> 
> Данный пакет владеет директориями /usr/share/icons/hicolor/scalable/apps и
> /usr/share/metainfo. Я считаю это ошибкой упаковки. Данные директории не
> должны принадлежать этому пакету. У первой должен быть владелец только пакет
> icon-theme-hicolor, вторую тоже давно пора включить в какой-нибудь системный
> пакет.
> 
> 9)
> http://git.altlinux.org/people/mattaku/packages/?p=passivetex.git;
> a=commitdiff;h=0cf79b22b7d7035035b881588ff052eb744e180f
> 
> install -m 0755 -p -d $RPM_BUILD_ROOT%_datadir/texmf/tex/xmltex/passivetex
> install -m 0644 -p *.sty *.xmt
> $RPM_BUILD_ROOT%_datadir/texmf/tex/xmltex/passivetex
> 
> Был ли данный спек адаптирован откуда-либо? $RPM_BUILD_ROOT опять же чаще
> встречается в спеках Федоры скорее, чем в ALT. В ALT обычно принято
> использовать макрос %buildroot. Если это так, то всё указанное для changelog
> libaec актуально и здесь.
> 
> 10) http://git.altlinux.org/people/mattaku/packages/?p=sequeler.git;a=summary
> 
> Указана версия 0.7.3, а исходники соответствуют апстримной версии 0.7.4. Я
> считаю это ошибкой.
> 
> 11)
> http://git.altlinux.org/people/mattaku/packages/?p=peek.git;a=commitdiff;
> h=1ddf008faab865fe3a8b3c956281aa418801c9d8
> 
> Опять пакету принадлежат директории %_datadir/metainfo и
> %_iconsdir/hicolor/*.
> 
> 12)
> http://git.altlinux.org/people/mattaku/packages/?p=webtech.git;a=commitdiff;
> h=c0a4e91e1d1ebe2d359ab247db652cf4fa9584a7
> 
> Group: Development/Python
> 
> Считаю, что в данном случае больше подойдёт группа Development/Python3.
> 
> 13)
> http://git.altlinux.org/people/mattaku/packages/?p=nawk.git;a=commitdiff;
> h=93e24279f3a2bd034c9da5f473cbc163e939f8ad
> 
> 13.1) Данные сборочные зависимости явно указывать не требуется:
> 
> BuildRequires: gcc
> BuildRequires: glibc-devel
> 
> 13.2) rm -rf %buildroot
> 
> Поскольку сборка обычно происходит в hasher, очищать %buildroot не нужно.
> Опять же такое часто встречается в спеках из других дистрибутивов. Является
> ли данный спек адаптированным? Если да, то %changelog не был сохранён.
> 
> 14) git://git.altlinux.org/people/mattaku/packages/qodem.git
> 
> Возможно раньше пакет и собирался, но сейчас - не собирается.
> 
> 15) http://git.altlinux.org/people/mattaku/packages/?p=vkmark.git;a=summary
> 
> 15.1) Возможно раньше пакет и собирался, но сейчас - не собирается.
> 
> 15.2)
> http://git.altlinux.org/people/mattaku/packages/?p=vkmark.git;a=commitdiff;
> h=b9d785b6064a6f98b64d25992b9d4759164e5eb2
> 
> Зачем здесь следующая runtime зависимость нужна?
> Requires: libassimp-devel
> 
> Также вопрос вызывают следующие строки:
> 
> BuildRequires: assimp-devel
> BuildRequires: libassimp-devel
> 
> Зачем они нужны вместе? Должно быть достаточно одной из них.
> 
> 16)
> http://git.altlinux.org/people/mattaku/packages/?p=airspyone_host.git;
> a=commitdiff;h=8244027a86604d036aed3fe566da527a917b2273
> 
> 16.1) Requires: libgudev-devel
> 
> Зачем данному пакету эта runtime зависимость?
> 
> 16.2) Requires: %name%{?_isa} = %version-%release
> make %{?_smp_mflags}
> 
> Эти строки опять-таки указывают что спек был адаптирован.
> 
> 17)
> http://git.altlinux.org/people/mattaku/packages/?p=meteo.git;a=commitdiff;
> h=9d5c4ac2497fe51f6f700aedb472f5cfffecb2a6
> 
> Несмотря на наличие в секции %install строки "%find_lang %appname" в секции
> %files все переводы перечисляются явно вместо использования результата
> работы %find_lang:
> 
> %_datadir/locale/*/*/com.gitlab.bitseater.meteo.mo
> 
> Насколько мне известно, переводы по возможности принято делать через
> %find_lang и использование результатов этого вызова. Очень странно видеть
> явное перечисление переводов когда почти всё готово для использования
> результатов %find_lang. Прошу упаковать переводы через %find_lang, а не
> через явное перечисление переводов.
> 
> См. также: https://www.altlinux.org/FindLang_Policy
> 
> 18) http://git.altlinux.org/tasks/250522/
> 
> %_libexecdir/python3/site-packages -> %python3_sitelibdir_noarch.
> 
> Ну и ошибка при сборке присутствует.
> 
> 19) Пожелание: в некоторых спеках встречаются выражения "%{_mandir}/man1"
> или "%_mandir/man1". В ALT, насколько мне известно, принято вместо этого
> писать "%_man1dir", и в других спеках это даже встречается. Хорошо бы
> следовать принятому в ALT использованию макросов.
> 
> Также указанные ранее макросы "%{?_smp_mflags}", "%{?_isa}" и подобные в ALT
> не используются обычно. И вместо %version-%release советую использовать %EVR.
> 
> 20) У многих пакетов указана группа "Emulators". Я считаю, что выбор сделан
> неверно. Насколько я вижу, в этой группе обычно находятся: средства
> виртуализации (типа qemu, virtualbox), эмуляции (типа pcsx2, dosbox, dosemu)
> и wine (хотя это слой совместимости, а не эмулятор). Например, для
> эмуляторов терминалов есть другая группа - "Terminals".
> 
> 
> 
> Заключение:
> 1) В большинстве пакетов судя по всему собирается master под видом релиза
> без указания этого в каком-либо виде, а в одном из пакетов вообще упакована
> другая версия, скорее всего находившаяся в master на момент сборки пакета. В
> дополнение к этому, почти везде используется директива gear "tar: .". Обычно
> так выглядит репозиторий у вступающего, который ещё не освоился с git и gear
> достаточно хорошо. Я такое расхождение указанной версии и реальной версии
> считаю ошибкой. Если есть необходимость всё-же собирать не релиз, а другую
> версию, то стоит собираемую версию явно указывать каким-либо образом, и
> хорошо бы озвучить такую необходимость здесь.
> 2) У многих спеков есть признаки, что это просто адаптация спека из другого
> дистрибутива. Я ничего не имею против такой адаптации, особенно если она
> сделана хорошо. В данном случае я не могу сказать что она сделана хорошо. В
> дополнение к этому, не сохранён %changelog адаптированных спеков, что
> противоречит руководству по changelog. Более того, у меня есть подозрение,
> что все новые пакеты являются адаптацией пакетов из других дистрибутивов.
> Если это так, то это не позволяет оценить насколько хорошо вступающий умеет
> писать спеки сам. Но я не знаю, является ли это обязательным требованием.
> 
> Я считаю, что вступающий недостаточно хорошо освоил используемые инструменты
> (как минимум git и gear), ситуация с %changelog скорее всего требует
> исправления тоже. Ну и пока исправляются эти 2 проблемы, стоит и остальные
> посмотреть, поскольку в спеках немало спорных моментов и проблемных мест.

Алексей, добрый вечер. Благодарю Вас за оценку моих пакетов из гита, которые были использованы для тренировки под наставлением Григория. Хотелось бы уточнить у Вас, что является замечанием, что является пожеланием и проблемой более явно. Еще раз, большое спасибо.

Максим, не стоит заниматься оверквотингом, багзилла и так всё помнит, достаточно сослаться на номер комментария.

(In reply to mattaku@altlinux.org from comment #40)
> Хотелось бы уточнить у Вас, что является замечанием, что является пожеланием
> и проблемой более явно.
Алексей пронумеровал все свои замечания. Если тебе из текста явно не понятно, перечисли, пожалуйста, конкретные номера.

(In reply to Aleksei Nikiforov from comment #35)
> Пожелания, замечания, проблемы, вопросы:
> [...]
> Пакет не собирается. Прошу прокомментировать.
К сожалению, Вам не передали, что в локальной гитовнице лежит много всего, не относящегося к делу, хотя Диме я это говорил. Видимо, так был организован процесс обучения, а лишнее не потёрто. Но часть пакетов прошла в Сизиф с одобрения менторов, только эти сборки стоило оценивать: https://packages.altlinux.org/en/sisyphus/maintainers/mattaku/srpms -- они собирались почти год назад, это тоже стоило учесть.

> 1) Пожелание по всем пакетам: не указывать тэг "Packager:". Оно
> автоматически заполняется.
Автоматически проставляется сборочницей, но чтобы найти в исходниках, нужно шерстить git log либо changelog, а Packager в спеке однозначно указывает на первого автора в Сизифе. Так что мне удобнее наоборот и, судя по спекам в наших репозиториях, не только мне.

На будущее считаю правильным отделять ошибки от пожеланий, что в данном случае как раз выполнено.

> 2) Следующие пакеты не соответствует руководству по указанию версии и релиза:
> http://git.altlinux.org/people/mattaku/packages/?p=ocproxy.git;a=summary
Поскольку это один из последних собранных в Сизиф пакетов и одобренных ментором, предлагаю с него начать. Высказанное замечание справедливо, релиз стоило исправить. И когда полностью закончим с ним, переходить к следующему.

Лог этой сборки:
http://git.altlinux.org/tasks/index/sisyphus/done/249465/logs/events.2.2.log

В данном случае repology сбивает с толку, т.к. все указывают последнюю апстримную версию 1.6 и отталкиваются от последнего коммита, как, например, здесь: https://src.fedoraproject.org/rpms/ocproxy/raw/f30/f/ocproxy.spec -- и у Игоря (viy@) так же, но при этом релиз проставлен верно.

(Ответ для mattaku@altlinux.org на комментарий #40)
> Алексей, добрый вечер. Благодарю Вас за оценку моих пакетов из гита, которые
> были использованы для тренировки под наставлением Григория. Хотелось бы
> уточнить у Вас, что является замечанием, что является пожеланием и проблемой
> более явно. Еще раз, большое спасибо.

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

По пунктам, как я вижу:
1) как и указано, пожелание.
2) пока не указана причина, хотя бы как минимум здесь в баге письменно, такую сборку я считаю ошибкой. Ещё лучше если факт такой сборки и её причина будут явно отражены в спеке и версии/релизе пакета.
3) вопрос, возможно ошибка
4) вопрос и возможно ошибка - сборка пакета с нуля вместо его обновления, сборка дубля пакета - сборочница такое не пропустит, если сделать задание
5) вопрос, и пожелание не ставить ненужные сборочные зависимости.
6.1) как я указал позднее, макросы типа "%{?_isa}" в ALT не используются и не существуют, и соответственно пожелание их при адаптации спека не использовать, вместо этого заменять при необходимости или удалять если они не нужны.
Относительно отсутствия %changelog из адаптированного спека, тут можно поспорить, но лично я думаю это скорее ошибка.
6.2) Опять же можно поспорить о том, что именно здесь. Но мне уже приходилось исправлять ошибку пересборки пакетов, где явно было указано что-то типа %_man1dir/%name.1.bz2, например, когда сжатие было xz, и соответственно файл стал называться %_man1dir/%name.1.xz. Это не сложно поправить, но я считаю что лучше сразу сделать так, чтобы успешная пересборка пакета не зависела от используемого сжатия man-страниц, тем более сделать это не сложно, потому считаю это небольшой, но ошибкой.
7) Такую ситуацию я считаю ошибкой несмотря на то, что в данном случае последствия незначительны. Вполне возможна ситуация, когда в таких пропущенных коммитах были бы важные исправления, и их отсутствие при сборке было бы не очевидно. Также уже доводилось видеть и исправлять пакет, где из-за путаницы с собираемыми исходниками и исходниками в репозитории собиралась неочевидным способом версия на пару лет более старая по сравнению с указанной в спеке версией пакета.
8) Тут вопрос, и я думаю скорее ошибка упаковки, чем пожелание. Либо абсолютно ненужная директория упакована, либо что-то забыли упаковать в %_man1dir
9) Тут думаю всё-таки ошибка упаковки, хотя не думаю что критичная, особенно про /usr/share/metainfo.
9) Оказывается, в процессе редактирования закрался второй пункт под этим номером. Пусть будет "9a" тогда чтобы отличать от предыдущего пункта. Про $RPM_BUILD_ROOT -> %buildroot - пожелание. Про changelog - то же, что и в пункте 6.1.
10) Как ранее написал и в прошлом сообщении, и здесь для пункта 2, считаю это ошибкой.
11) Аналогично пункту 9.
12) Не могу сказать насколько важно правильно заполнять группы, потому тут пожелание.
13.1) Пожелание
13.2) Пожелание по адаптации, аналогично пунктам 6.1 и 9а.
14) Был вопрос почему так. Но на него уже ответил Leonid Krivoshein.
15.1) Аналогично предыдущему пункту.
15.2) Хотя это может быть спорным моментом, если пакету не нужен для работы именно devel-пакет, типа libassimp-devel, то такую зависимость стоит считать ошибкой.
По поводу дублирования "BuildRequires: assimp-devel" и "BuildRequires: libassimp-devel" - выглядит как недоделанная адаптация спека, и потому есть пожелание доделывать такую адаптацию и не оставлять такие дубли.
16.1) Аналогично предыдущему пункту.
16.2) Аналогично пункту 6.1.
17) Можно поспорить, но с учётом того, что нарушается https://www.altlinux.org/FindLang_Policy, думаю стоит считать это ошибкой.
18) Скорее, пожелание.
19) Пожелание
20) Аналогично пункту 12 - пожелание.

(Ответ для Grigory Ustinov на комментарий #37)
> 8.) Опечатка. /usr/share/man/man1 А так да.

Не просто опечатка. Или не только опечатка. Это пустая директория. Либо она не нужна вообще, либо туда что-то забыли упаковать.

> 9.) На момент прошлого года это ещё не считалось ошибкой упаковки. К
> сожалению тогда это был единственный известный мне способ борьбы с
> postinstall unowned files. Я сам так делал=( Сейчас в своих пакетах
> переделываю.

Не все postinstall unowned files стоит исправлять таким способом. Я обычно делаю так: смотрю по репозиторию, есть ли пакеты, которым уже принадлежит эта директория, и уже в зависимости от результатов решаю нужно ли упаковывать директорию или нет. Иногда директория никому не принадлежит, а иногда просто не хватает зависимости на пакет, которому директория принадлежит, как например часто бывает у модулей alterator.

(Ответ для Grigory Ustinov на комментарий #38)
> Пользуясь случаем хотелось бы поинтересоваться вопросом адаптации спеков из
> других дистрибутивов. Понятное дело, что в различных дистрибутивах свои
> особенности написания спек-файлов. Тем не менее, надо признать, что
> существуют общие для всех вещи типа секции description или даже build и
> install. Надо ли указывать ченджлог дистрибутива, из которого был выдернут
> спек, если адаптация была выполнена на очень высоком уровне? На мой взгляд,
> было бы правильным формализировать этот вопрос указанием процента совпадений.

Мне кажется не стоит усложнять правила. Стоит их сделать проще, тогда не будет проблем им следовать. Была сделана первая сборка пакета с использованием чужого спека - берите %changelog оттуда. Если было использовано несколько разных спеков, то чтобы не считать где было больше строк или символов использовано, и где они важнее, опять-таки, берите первый из них.

(Ответ для Leonid Krivoshein на комментарий #41)
> К сожалению, Вам не передали, что в локальной гитовнице лежит много всего,
> не относящегося к делу, хотя Диме я это говорил. Видимо, так был организован
> процесс обучения, а лишнее не потёрто. Но часть пакетов прошла в Сизиф с
> одобрения менторов, только эти сборки стоило оценивать:
> https://packages.altlinux.org/en/sisyphus/maintainers/mattaku/srpms -- они
> собирались почти год назад, это тоже стоило учесть.

Этим сайтом я обычно не пользуюсь по различным причинам. Если на git.altlinux.org лежат недоделанные работы, то возможно стоит их либо убирать временно оттуда, либо помечать как WIP (work in progress) каким-либо образом, именем ветки, например, или явно написать в спеке.

(In reply to Aleksei Nikiforov from comment #42)
> (Ответ для mattaku@altlinux.org на комментарий #40)
> > Алексей, добрый вечер. Благодарю Вас за оценку моих пакетов из гита, которые
> > были использованы для тренировки под наставлением Григория. Хотелось бы
> > уточнить у Вас, что является замечанием, что является пожеланием и проблемой
> > более явно. Еще раз, большое спасибо.
> 
> Извините, стараюсь работать над более явным указанием где что именно.
> 
> По пунктам, как я вижу:
[...]

На мой взгляд роль ревьювера заключается в оценке общего уровня подготовки и выявлении критических проблем, если таковые имеются. Поэтому важно разделять:
1) личные предпочтения и обязательные требования;
2) мелкие недоработки и серьёзные ошибки.

Разумеется, ревьювер имеет право высказать все свои предложения, замечания и пожелания кандидату, но следует чётко выделить серьёзные проблемы, обязательные для исправления, и всё остальное. Поэтому я предлагаю все «возможно» сразу отправить в список пожеланий и некритичных проблем.

Так же следует помнить, что ошибки, недоработки или что-то не совсем правильно или оптимально сделанное время от времени проявляется у абсолютно всех активных мейнтенеров, даже очень опытных, даже у уважаемого ревьювера.

Поэтому предлагаю отделить мух от котлет и выделить перечень действительно серьёзных проблем, над которыми следует поработать кандидату для принятия в Team. На мой взгляд, их не так уж и много.

(Ответ для Andrew Savchenko на комментарий #43)
> Так же следует помнить, что ошибки, недоработки или что-то не совсем
> правильно или оптимально сделанное время от времени проявляется у абсолютно
> всех активных мейнтенеров, даже очень опытных, даже у уважаемого ревьювера.
> 

Согласен с этим.

> Поэтому предлагаю отделить мух от котлет и выделить перечень действительно
> серьёзных проблем, над которыми следует поработать кандидату для принятия в
> Team. На мой взгляд, их не так уж и много.

То, что я посчитал самым важным я отдельно ещё раз отметил в заключении в первом своём сообщении.

Бага ещё актуальна?

(Ответ для Grigory Ustinov на комментарий #45)
> Бага ещё актуальна?

Спустя ещё один год...

Более 3ёх лет никакой активности. Видимо RESOLVED WONTFIX.

Всегда можно переоткрыть баг, если передумаете.