Bug 38040 - [3.4] join mattaku@
Summary: [3.4] join mattaku@
Status: CLOSED NOTABUG
Alias: None
Product: Team Accounts
Classification: Development
Component: join (show other bugs)
Version: unspecified
Hardware: x86 Linux
: P5 normal
Assignee: Gleb F-Malinovskiy
QA Contact: Andrey Cherepanov
URL: https://www.altlinux.org/Team/Join/Se...
Keywords:
: 38039 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-02-06 02:54 MSK by Maxim Knyazev
Modified: 2023-08-04 13:40 MSK (History)
10 users (show)

See Also:


Attachments
SSH pubkey (96 bytes, text/plain)
2020-02-06 02:56 MSK, Maxim Knyazev
no flags Details
GPG ключ (3.01 KB, text/plain)
2020-02-06 02:57 MSK, Maxim Knyazev
no flags Details
Публичный ключ GPG (3.00 KB, application/x-iwork-keynote-sffkey)
2020-02-26 17:41 MSK, Maxim Knyazev
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maxim Knyazev 2020-02-06 02:54:56 MSK
Псевдоним: Mattaku
Email: Mattakushi10@mail.ru
Ментор: grenka@ , klark@
Цель: Научиться собирать пакеты и освоить инфраструктуру.
Comment 1 Maxim Knyazev 2020-02-06 02:56:30 MSK
Created attachment 8582 [details]
SSH pubkey
Comment 2 Maxim Knyazev 2020-02-06 02:57:03 MSK
Created attachment 8583 [details]
GPG ключ
Comment 3 Michael Shigorin 2020-02-06 11:23:02 MSK
*** Bug 38039 has been marked as a duplicate of this bug. ***
Comment 4 Leonid Krivoshein 2020-02-07 16:20:42 MSK
(In reply to Maxim Knyazev from comment #0)
> Ментор: klark@
Подтверждаю.
Comment 5 Gleb F-Malinovskiy 2020-02-19 13:28:00 MSK
(In reply to Maxim Knyazev from comment #2)
> Created attachment 8583 [details]
> GPG ключ

Для gpg нужно указать имя в формате "<First name> <Last name>".
Comment 6 Maxim Knyazev 2020-02-26 17:41:45 MSK
Created attachment 8637 [details]
Публичный ключ GPG

Свою ошибку исправил.
Comment 7 Grigory Ustinov 2020-02-27 16:04:00 MSK
Подтверждаю. Дайте человеку доступ к сборочнице, пожалуйста.
Comment 8 Leonid Krivoshein 2020-02-28 18:41:45 MSK
Да, к гитовнице: T/J/S -> 2.0
Comment 9 Gleb F-Malinovskiy 2020-03-03 14:39:51 MSK
> Email: Mattakushi10@mail.ru

К сожалению mail.ru -- сервис, который плохо сочетается с нашими списками рассылки.  У вас есть возможность выбрать другую почту для пересылки?
Comment 10 Maxim Knyazev 2020-03-04 16:58:39 MSK
Почта:

mattakushiro@gmail.com
Comment 11 Gleb F-Malinovskiy 2020-03-04 17:29:21 MSK
ssh ключ на gitery.alt зарегистрирован.
ssh ключ на gyle.alt зарегистрирован.
Адрес для пересылки создан.

T/J/S -> 3.0.
Comment 12 Leonid Krivoshein 2020-03-18 03:26:34 MSK
Дайте, пожалуйста, человеку доступ к сборочнице.
Comment 13 Maxim Knyazev 2020-03-24 16:26:07 MSK
Подготовил 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
Comment 14 Andrey Cherepanov 2020-03-30 14:06:23 MSK
Уважаемый секретарь, ping.
Comment 15 Gleb F-Malinovskiy 2020-03-30 18:56:02 MSK
Пакет alt-gpgkeys обновлён.

T/J/S -> 4.0.
Comment 16 Leonid Krivoshein 2020-05-12 19:44:16 MSK
Кандидат показал, что готов собирать пакеты.
Comment 17 Grigory Ustinov 2021-02-09 10:08:02 MSK
С годовщиной!=)
Comment 18 Dmitry V. Levin 2021-02-20 17:38:36 MSK
Это ещё актуально?
Comment 19 Andrey Cherepanov 2021-02-20 18:54:17 MSK
(Ответ для Dmitry V. Levin на комментарий #18)
> Это ещё актуально?

Да, актуально. Прошу уважаемых менторов высказаться.
Comment 20 Leonid Krivoshein 2021-02-20 20:44:18 MSK
(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 под мою ответственность.

Почему не закрыт баг -- не знаю, человек уже год у нас работает. И с мая прошлого года мы считали, что процедура завершена.
Comment 21 Grigory Ustinov 2021-02-20 20:49:35 MSK
https://packages.altlinux.org/ru/sisyphus/maintainers/mattaku/tasks - согласно этому источнику, последний раз испытуемый собирал пакеты очень давно ещё до Н.Э. (Начала Эпидемии). Я уверен, что не только мне, но и всем остальным принимающим участие в этом процессе было бы интересно посмотреть на актуальные способности указанного кандидата.
Comment 22 Dmitry V. Levin 2021-02-20 20:59:38 MSK
(In reply to Leonid Krivoshein from comment #20)
> Почему не закрыт баг -- не знаю, человек уже год у нас работает. И с мая
> прошлого года мы считали, что процедура завершена.

Процедура находится на стадии [4.0] в новой нумерации.
Если кандидату уже не нужно завершать процедуру вступления, то лучше сказать об этом прямо.
Comment 23 Andrew Vasilyev 2021-02-20 21:02:49 MSK
(Ответ для Grigory Ustinov на комментарий #21)
> https://packages.altlinux.org/ru/sisyphus/maintainers/mattaku/tasks -
> согласно этому источнику, последний раз испытуемый собирал пакеты очень
> давно 

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

Ну я готовлю питоний мегатаск, мне простительно=)) Но если без шуток, то в отношении испытуемого указанная статистика верная, потому что я смотрел по письмам от сборочницы, просто не все же подписаны на этот список рассылки.
Comment 25 Leonid Krivoshein 2021-02-20 21:24:18 MSK
Согласно другому источнику последнее использование им нашей инфраструктуры было в июне 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 доползать? :-) А как с остальными тимовцами?
Comment 26 Grigory Ustinov 2021-02-20 21:29:41 MSK
(Ответ для Leonid Krivoshein на комментарий #25)
> Сборка, как основное занятие, для
> него уже тогда фактически закончилась -- сейчас у него другие рабочие
> задачи, он занимается поиском ошибок и переводами, насколько я знаю. Тут
> лучше пусть Андрей пояснит, как можно оценить его актуальные способности. 

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

Баги надо закрывать=))
Comment 27 Dmitry V. Levin 2021-02-20 21:39:18 MSK
(In reply to Leonid Krivoshein from comment #25)
> (In reply to Dmitry V. Levin from comment #22)
> > Процедура находится на стадии [4.0] в новой нумерации.
> Почему в новой? Новая появилась в декабре 2020, он заджойнился в мае 2020.

Я просто констатирую факт: процедура находится на стадии [4.0] в новой нумерации.
Comment 28 Leonid Krivoshein 2021-02-20 21:40:55 MSK
(In reply to Grigory Ustinov from comment #26)
> А зачем тогда вообще нужен джойн
Конкретно для него это было условием приёма на работу в отдел Андрея.

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

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

Но хочу напомнить, что его заджойнили под мою ответственность, т.к. до высоких требований другого ментора он не дотягивал, а по работе ему это и сейчас не требуется. Все собранные им тогда пакеты в нашей инфраструктуре посмотреть можно и сейчас.
Comment 29 Dmitry V. Levin 2021-02-20 22:11:37 MSK
(In reply to Leonid Krivoshein from comment #28)
> (In reply to Grigory Ustinov from comment #26)
> > А зачем тогда вообще нужен джойн
> Конкретно для него это было условием приёма на работу в отдел Андрея.

Это профанация join'а.  Не делайте так, пожалуйста.
Во многом из-за этого в процедуру и была введена ещё одна стадия.
Comment 30 AEN 2021-02-20 22:31:31 MSK
А зачем нам такой в отделе сопровождения?
Comment 31 Andrew Savchenko 2021-02-20 22:48:11 MSK
(In reply to Grigory Ustinov from comment #26)
> (Ответ для Leonid Krivoshein на комментарий #25)
> > Сборка, как основное занятие, для
> > него уже тогда фактически закончилась -- сейчас у него другие рабочие
> > задачи, он занимается поиском ошибок и переводами, насколько я знаю. Тут
> > лучше пусть Андрей пояснит, как можно оценить его актуальные способности. 
> 
> А зачем тогда вообще нужен джойн и доступ к сборочнице, если человеку это не
> нужно? Выглядит, как пустая трата времени.

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

Человек прямо сейчас не коммитит, что в этом плохого? Предположу, что нужное уже в репо. Как появится новая необходимость, закоммитит ещё.
Comment 32 Dmitry V. Levin 2021-03-23 19:51:01 MSK
Максим, вам ещё интересно завершать процедуру вступления в team?
Comment 33 mattaku@altlinux.org 2021-03-23 20:40:59 MSK
(Ответ для Dmitry V. Levin на комментарий #32)
> Максим, вам ещё интересно завершать процедуру вступления в team?

Добрый вечер, да, конечно
Comment 34 Dmitry V. Levin 2021-03-26 04:30:26 MSK
Попробую позвать ещё одного человека (darktemplar@) для независимой оценки готовности кандидата.
Comment 35 Aleksei Nikiforov 2021-03-29 18:28:27 MSK
Пожелания, замечания, проблемы, вопросы:
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 проблемы, стоит и остальные посмотреть, поскольку в спеках немало спорных моментов и проблемных мест.
Comment 36 Dmitry V. Levin 2021-03-29 18:33:39 MSK
(In reply to Aleksei Nikiforov from comment #35)
> Пожелания, замечания, проблемы, вопросы:
> 1) Пожелание по всем пакетам: не указывать тэг "Packager:". Оно
> автоматически заполняется.

Видимо, за исключением коллективных Packager из домена packages.altlinux.org.
Вероятно, в данном случае таких нет.
Comment 37 Grigory Ustinov 2021-03-29 20:02:14 MSK
(Ответ для Aleksei Nikiforov на комментарий #35)

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

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

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

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

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

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

13.1) Об этом я говорил минимум 2 раза в других пакетах.
Comment 38 Grigory Ustinov 2021-03-29 20:02:54 MSK
Пользуясь случаем хотелось бы поинтересоваться вопросом адаптации спеков из других дистрибутивов. Понятное дело, что в различных дистрибутивах свои особенности написания спек-файлов. Тем не менее, надо признать, что существуют общие для всех вещи типа секции description или даже build и install. Надо ли указывать ченджлог дистрибутива, из которого был выдернут спек, если адаптация была выполнена на очень высоком уровне? На мой взгляд, было бы правильным формализировать этот вопрос указанием процента совпадений.
Comment 39 Grigory Ustinov 2021-03-29 20:04:25 MSK
2mattaku: Буду ждать исправлений и сборки новых пакетов, в качестве подтверждения усвоенных замечаний.
Comment 40 mattaku@altlinux.org 2021-03-29 20:50:39 MSK
(Ответ для 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 проблемы, стоит и остальные
> посмотреть, поскольку в спеках немало спорных моментов и проблемных мест.

Алексей, добрый вечер. Благодарю Вас за оценку моих пакетов из гита, которые были использованы для тренировки под наставлением Григория. Хотелось бы уточнить у Вас, что является замечанием, что является пожеланием и проблемой более явно. Еще раз, большое спасибо.
Comment 41 Leonid Krivoshein 2021-03-29 22:51:11 MSK
Максим, не стоит заниматься оверквотингом, багзилла и так всё помнит, достаточно сослаться на номер комментария.

(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@) так же, но при этом релиз проставлен верно.
Comment 42 Aleksei Nikiforov 2021-03-30 11:16:51 MSK
(Ответ для 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) каким-либо образом, именем ветки, например, или явно написать в спеке.
Comment 43 Andrew Savchenko 2021-03-30 14:56:37 MSK
(In reply to Aleksei Nikiforov from comment #42)
> (Ответ для mattaku@altlinux.org на комментарий #40)
> > Алексей, добрый вечер. Благодарю Вас за оценку моих пакетов из гита, которые
> > были использованы для тренировки под наставлением Григория. Хотелось бы
> > уточнить у Вас, что является замечанием, что является пожеланием и проблемой
> > более явно. Еще раз, большое спасибо.
> 
> Извините, стараюсь работать над более явным указанием где что именно.
> 
> По пунктам, как я вижу:
[...]

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

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

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

Поэтому предлагаю отделить мух от котлет и выделить перечень действительно серьёзных проблем, над которыми следует поработать кандидату для принятия в Team. На мой взгляд, их не так уж и много.
Comment 44 Aleksei Nikiforov 2021-03-30 15:00:14 MSK
(Ответ для Andrew Savchenko на комментарий #43)
> Так же следует помнить, что ошибки, недоработки или что-то не совсем
> правильно или оптимально сделанное время от времени проявляется у абсолютно
> всех активных мейнтенеров, даже очень опытных, даже у уважаемого ревьювера.
> 

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

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

То, что я посчитал самым важным я отдельно ещё раз отметил в заключении в первом своём сообщении.
Comment 45 Grigory Ustinov 2021-09-10 15:32:33 MSK
Бага ещё актуальна?
Comment 46 Grigory Ustinov 2022-09-16 14:31:01 MSK
(Ответ для Grigory Ustinov на комментарий #45)
> Бага ещё актуальна?

Спустя ещё один год...
Comment 47 Grigory Ustinov 2023-07-07 14:07:48 MSK
Более 3ёх лет никакой активности. Видимо RESOLVED WONTFIX.
Comment 48 Gleb F-Malinovskiy 2023-08-04 13:40:52 MSK
Всегда можно переоткрыть баг, если передумаете.