38040 2020-02-06 02:54:56 +0300 [3.4] join mattaku@ 2023-08-04 13:40:52 +0300 1 1 4 Development Team Accounts join unspecified x86 Linux CLOSED NOTABUG https://www.altlinux.org/Team/Join/Secretary P5 normal --- 1 mattakushi10 glebfm aen andy bircoph darktemplar darktemplaralt glebfm grenka klark ldv mattaku cas oldest_to_newest 187580 0 mattakushi10 2020-02-06 02:54:56 +0300 Псевдоним: Mattaku Email: Mattakushi10@mail.ru Ментор: grenka@ , klark@ Цель: Научиться собирать пакеты и освоить инфраструктуру. 187581 1 8582 mattakushi10 2020-02-06 02:56:30 +0300 Created attachment 8582 SSH pubkey 187582 2 8583 mattakushi10 2020-02-06 02:57:03 +0300 Created attachment 8583 GPG ключ 187588 3 mike 2020-02-06 11:23:02 +0300 *** Bug 38039 has been marked as a duplicate of this bug. *** 187649 4 klark 2020-02-07 16:20:42 +0300 (In reply to Maxim Knyazev from comment #0) > Ментор: klark@ Подтверждаю. 188027 5 glebfm 2020-02-19 13:28:00 +0300 (In reply to Maxim Knyazev from comment #2) > Created attachment 8583 [details] > GPG ключ Для gpg нужно указать имя в формате "<First name> <Last name>". 188204 6 8637 mattakushi10 2020-02-26 17:41:45 +0300 Created attachment 8637 Публичный ключ GPG Свою ошибку исправил. 188222 7 grenka 2020-02-27 16:04:00 +0300 Подтверждаю. Дайте человеку доступ к сборочнице, пожалуйста. 188248 8 klark 2020-02-28 18:41:45 +0300 Да, к гитовнице: T/J/S -> 2.0 188288 9 glebfm 2020-03-03 14:39:51 +0300 > Email: Mattakushi10@mail.ru К сожалению mail.ru -- сервис, который плохо сочетается с нашими списками рассылки. У вас есть возможность выбрать другую почту для пересылки? 188332 10 mattakushi10 2020-03-04 16:58:39 +0300 Почта: mattakushiro@gmail.com 188335 11 glebfm 2020-03-04 17:29:21 +0300 ssh ключ на gitery.alt зарегистрирован. ssh ключ на gyle.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 3.0. 188595 12 klark 2020-03-18 03:26:34 +0300 Дайте, пожалуйста, человеку доступ к сборочнице. 188764 13 mattakushi10 2020-03-24 16:26:07 +0300 Подготовил 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 188963 14 cas 2020-03-30 14:06:23 +0300 Уважаемый секретарь, ping. 188985 15 glebfm 2020-03-30 18:56:02 +0300 Пакет alt-gpgkeys обновлён. T/J/S -> 4.0. 189879 16 klark 2020-05-12 19:44:16 +0300 Кандидат показал, что готов собирать пакеты. 196089 17 grenka 2021-02-09 10:08:02 +0300 С годовщиной!=) 196389 18 ldv 2021-02-20 17:38:36 +0300 Это ещё актуально? 196396 19 cas 2021-02-20 18:54:17 +0300 (Ответ для Dmitry V. Levin на комментарий #18) > Это ещё актуально? Да, актуально. Прошу уважаемых менторов высказаться. 196401 20 klark 2021-02-20 20:44:18 +0300 (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 под мою ответственность. Почему не закрыт баг -- не знаю, человек уже год у нас работает. И с мая прошлого года мы считали, что процедура завершена. 196402 21 grenka 2021-02-20 20:49:35 +0300 https://packages.altlinux.org/ru/sisyphus/maintainers/mattaku/tasks - согласно этому источнику, последний раз испытуемый собирал пакеты очень давно ещё до Н.Э. (Начала Эпидемии). Я уверен, что не только мне, но и всем остальным принимающим участие в этом процессе было бы интересно посмотреть на актуальные способности указанного кандидата. 196403 22 ldv 2021-02-20 20:59:38 +0300 (In reply to Leonid Krivoshein from comment #20) > Почему не закрыт баг -- не знаю, человек уже год у нас работает. И с мая > прошлого года мы считали, что процедура завершена. Процедура находится на стадии [4.0] в новой нумерации. Если кандидату уже не нужно завершать процедуру вступления, то лучше сказать об этом прямо. 196404 23 andy 2021-02-20 21:02:49 +0300 (Ответ для Grigory Ustinov на комментарий #21) > https://packages.altlinux.org/ru/sisyphus/maintainers/mattaku/tasks - > согласно этому источнику, последний раз испытуемый собирал пакеты очень > давно А ты https://packages.altlinux.org/ru/sisyphus/maintainers/grenka/tasks не смотрел? :-) Там больше полугода нет изменений :( 196406 24 grenka 2021-02-20 21:20:47 +0300 (Ответ для Andrew Vasilyev на комментарий #23) > (Ответ для Grigory Ustinov на комментарий #21) > > https://packages.altlinux.org/ru/sisyphus/maintainers/mattaku/tasks - > > согласно этому источнику, последний раз испытуемый собирал пакеты очень > > давно > > А ты > https://packages.altlinux.org/ru/sisyphus/maintainers/grenka/tasks > не смотрел? :-) Там больше полугода нет изменений :( Ну я готовлю питоний мегатаск, мне простительно=)) Но если без шуток, то в отношении испытуемого указанная статистика верная, потому что я смотрел по письмам от сборочницы, просто не все же подписаны на этот список рассылки. 196408 25 klark 2021-02-20 21:24:18 +0300 Согласно другому источнику последнее использование им нашей инфраструктуры было в июне 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 доползать? :-) А как с остальными тимовцами? 196409 26 grenka 2021-02-20 21:29:41 +0300 (Ответ для Leonid Krivoshein на комментарий #25) > Сборка, как основное занятие, для > него уже тогда фактически закончилась -- сейчас у него другие рабочие > задачи, он занимается поиском ошибок и переводами, насколько я знаю. Тут > лучше пусть Андрей пояснит, как можно оценить его актуальные способности. А зачем тогда вообще нужен джойн и доступ к сборочнице, если человеку это не нужно? Выглядит, как пустая трата времени. > Можно узнать тут причину? Баг моего джойна тоже не закрыт, мне теперь тоже > до 5.0 доползать? :-) А как с остальными тимовцами? Баги надо закрывать=)) 196410 27 ldv 2021-02-20 21:39:18 +0300 (In reply to Leonid Krivoshein from comment #25) > (In reply to Dmitry V. Levin from comment #22) > > Процедура находится на стадии [4.0] в новой нумерации. > Почему в новой? Новая появилась в декабре 2020, он заджойнился в мае 2020. Я просто констатирую факт: процедура находится на стадии [4.0] в новой нумерации. 196411 28 klark 2021-02-20 21:40:55 +0300 (In reply to Grigory Ustinov from comment #26) > А зачем тогда вообще нужен джойн Конкретно для него это было условием приёма на работу в отдел Андрея. > и доступ к сборочнице, если человеку это не > нужно? Выглядит, как пустая трата времени. Чтобы работать в команде и, при необходимости, этим пользоваться. Но не я его начальник. > Баги надо закрывать=)) Кто должен был закрыть этот баг, я? Извиняюсь, если что-то упустил. Но хочу напомнить, что его заджойнили под мою ответственность, т.к. до высоких требований другого ментора он не дотягивал, а по работе ему это и сейчас не требуется. Все собранные им тогда пакеты в нашей инфраструктуре посмотреть можно и сейчас. 196412 29 ldv 2021-02-20 22:11:37 +0300 (In reply to Leonid Krivoshein from comment #28) > (In reply to Grigory Ustinov from comment #26) > > А зачем тогда вообще нужен джойн > Конкретно для него это было условием приёма на работу в отдел Андрея. Это профанация join'а. Не делайте так, пожалуйста. Во многом из-за этого в процедуру и была введена ещё одна стадия. 196414 30 aen 2021-02-20 22:31:31 +0300 А зачем нам такой в отделе сопровождения? 196415 31 bircoph 2021-02-20 22:48:11 +0300 (In reply to Grigory Ustinov from comment #26) > (Ответ для Leonid Krivoshein на комментарий #25) > > Сборка, как основное занятие, для > > него уже тогда фактически закончилась -- сейчас у него другие рабочие > > задачи, он занимается поиском ошибок и переводами, насколько я знаю. Тут > > лучше пусть Андрей пояснит, как можно оценить его актуальные способности. > > А зачем тогда вообще нужен джойн и доступ к сборочнице, если человеку это не > нужно? Выглядит, как пустая трата времени. К сожалению, пустой тратой времени выглядит чтение твоих постов и писем. Ты систематически предъявляешь необоснованные и чрезмерные требования к новым участникам тима. Человек прямо сейчас не коммитит, что в этом плохого? Предположу, что нужное уже в репо. Как появится новая необходимость, закоммитит ещё. 197187 32 ldv 2021-03-23 19:51:01 +0300 Максим, вам ещё интересно завершать процедуру вступления в team? 197189 33 mattaku 2021-03-23 20:40:59 +0300 (Ответ для Dmitry V. Levin на комментарий #32) > Максим, вам ещё интересно завершать процедуру вступления в team? Добрый вечер, да, конечно 197262 34 ldv 2021-03-26 04:30:26 +0300 Попробую позвать ещё одного человека (darktemplar@) для независимой оценки готовности кандидата. 197366 35 darktemplaralt 2021-03-29 18:28:27 +0300 Пожелания, замечания, проблемы, вопросы: 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 проблемы, стоит и остальные посмотреть, поскольку в спеках немало спорных моментов и проблемных мест. 197367 36 ldv 2021-03-29 18:33:39 +0300 (In reply to Aleksei Nikiforov from comment #35) > Пожелания, замечания, проблемы, вопросы: > 1) Пожелание по всем пакетам: не указывать тэг "Packager:". Оно > автоматически заполняется. Видимо, за исключением коллективных Packager из домена packages.altlinux.org. Вероятно, в данном случае таких нет. 197369 37 grenka 2021-03-29 20:02:14 +0300 (Ответ для Aleksei Nikiforov на комментарий #35) Спасибо, Алексей! Я восхищён вашим терпением и внимательностью к делегированному вам вопросу. Вы проделали колоссальную работу, в том числе и по реабилитации моей репутации в качестве ментора. К сожалению за год много воды утекло и сейчас представляется трудным установить, где были применены мои указания, а где нет. Тем не менее некоторые из указанных пакетов мне знакомы. Мои комментарии к замечаниям: 1.) Поле packager не запрещено. Мне оно глаза не режет и я сам его использую. Так что это всего лишь пожелание. 6.1) Надо удалить %{?_isa}. У нас это не используется. 8.) Опечатка. /usr/share/man/man1 А так да. 9.) На момент прошлого года это ещё не считалось ошибкой упаковки. К сожалению тогда это был единственный известный мне способ борьбы с postinstall unowned files. Я сам так делал=( Сейчас в своих пакетах переделываю. 13.1) Об этом я говорил минимум 2 раза в других пакетах. 197370 38 grenka 2021-03-29 20:02:54 +0300 Пользуясь случаем хотелось бы поинтересоваться вопросом адаптации спеков из других дистрибутивов. Понятное дело, что в различных дистрибутивах свои особенности написания спек-файлов. Тем не менее, надо признать, что существуют общие для всех вещи типа секции description или даже build и install. Надо ли указывать ченджлог дистрибутива, из которого был выдернут спек, если адаптация была выполнена на очень высоком уровне? На мой взгляд, было бы правильным формализировать этот вопрос указанием процента совпадений. 197372 39 grenka 2021-03-29 20:04:25 +0300 2mattaku: Буду ждать исправлений и сборки новых пакетов, в качестве подтверждения усвоенных замечаний. 197374 40 mattaku 2021-03-29 20:50:39 +0300 (Ответ для 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 проблемы, стоит и остальные > посмотреть, поскольку в спеках немало спорных моментов и проблемных мест. Алексей, добрый вечер. Благодарю Вас за оценку моих пакетов из гита, которые были использованы для тренировки под наставлением Григория. Хотелось бы уточнить у Вас, что является замечанием, что является пожеланием и проблемой более явно. Еще раз, большое спасибо. 197375 41 klark 2021-03-29 22:51:11 +0300 Максим, не стоит заниматься оверквотингом, багзилла и так всё помнит, достаточно сослаться на номер комментария. (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@) так же, но при этом релиз проставлен верно. 197386 42 darktemplaralt 2021-03-30 11:16:51 +0300 (Ответ для 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) каким-либо образом, именем ветки, например, или явно написать в спеке. 197396 43 bircoph 2021-03-30 14:56:37 +0300 (In reply to Aleksei Nikiforov from comment #42) > (Ответ для mattaku@altlinux.org на комментарий #40) > > Алексей, добрый вечер. Благодарю Вас за оценку моих пакетов из гита, которые > > были использованы для тренировки под наставлением Григория. Хотелось бы > > уточнить у Вас, что является замечанием, что является пожеланием и проблемой > > более явно. Еще раз, большое спасибо. > > Извините, стараюсь работать над более явным указанием где что именно. > > По пунктам, как я вижу: [...] На мой взгляд роль ревьювера заключается в оценке общего уровня подготовки и выявлении критических проблем, если таковые имеются. Поэтому важно разделять: 1) личные предпочтения и обязательные требования; 2) мелкие недоработки и серьёзные ошибки. Разумеется, ревьювер имеет право высказать все свои предложения, замечания и пожелания кандидату, но следует чётко выделить серьёзные проблемы, обязательные для исправления, и всё остальное. Поэтому я предлагаю все «возможно» сразу отправить в список пожеланий и некритичных проблем. Так же следует помнить, что ошибки, недоработки или что-то не совсем правильно или оптимально сделанное время от времени проявляется у абсолютно всех активных мейнтенеров, даже очень опытных, даже у уважаемого ревьювера. Поэтому предлагаю отделить мух от котлет и выделить перечень действительно серьёзных проблем, над которыми следует поработать кандидату для принятия в Team. На мой взгляд, их не так уж и много. 197397 44 darktemplaralt 2021-03-30 15:00:14 +0300 (Ответ для Andrew Savchenko на комментарий #43) > Так же следует помнить, что ошибки, недоработки или что-то не совсем > правильно или оптимально сделанное время от времени проявляется у абсолютно > всех активных мейнтенеров, даже очень опытных, даже у уважаемого ревьювера. > Согласен с этим. > Поэтому предлагаю отделить мух от котлет и выделить перечень действительно > серьёзных проблем, над которыми следует поработать кандидату для принятия в > Team. На мой взгляд, их не так уж и много. То, что я посчитал самым важным я отдельно ещё раз отметил в заключении в первом своём сообщении. 202618 45 grenka 2021-09-10 15:32:33 +0300 Бага ещё актуальна? 214978 46 grenka 2022-09-16 14:31:01 +0300 (Ответ для Grigory Ustinov на комментарий #45) > Бага ещё актуальна? Спустя ещё один год... 229174 47 grenka 2023-07-07 14:07:48 +0300 Более 3ёх лет никакой активности. Видимо RESOLVED WONTFIX. 230863 48 glebfm 2023-08-04 13:40:52 +0300 Всегда можно переоткрыть баг, если передумаете. 8582 2020-02-06 02:56:30 +0300 2020-02-06 02:56:30 +0300 SSH pubkey id_ed25519.pub text/plain 96 mattakushi10 c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSUtMa2haTjBZUHJORVl6ZVVwMTFq QkNZM0dZc1dUYlpGeGVSTG1Ea1ZURS8gbWF4QE1heC4wLjIuMTUK 8583 2020-02-06 02:57:03 +0300 2020-02-06 02:57:03 +0300 GPG ключ GPG asciiarmor key text/plain 3079 mattakushi10 LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkY0N1VRNEJFQUR2ZkRm cm5LM2xCVDhxSHgvaG4vbHdscXBOelIzNndjRW1JZ0VWWFZLL2k1UU15bTFuCjJpaHlZcEczSnJ3 ZFF6NkZCellza0tCZkhnMXVLcVJQaVYvY0pKdDMycUVhV29ENHllajZORCsvN1pKWWt0NlUKSmtT VUJSK1ZBRjR3b1JTWXVVVTJ1RGJ0V3RQbC92ajFFcVE5bk9vZnNqMVRzbTFhWityUXY5Wk9XVXcw MW9PTAo0NTJ4bUhBcEtaYkZ6VS95NTRUQkIxcHRwZzViOXhUV2JnbVkxdjdwU1FzWElnbXB1UkM1 eXA3U1Urc1MyZ1lOCnNQcTlzeUozWDRwU0Z5NVl4ZzZSbTRRS1JiMFNEUzloZkhzVkNBR1NyS2Vq bm4zYTFHYUFrWEk2MC9Lbnh6QXQKNTB0cG00RzF5bVh5T2dpN3dqNGdUbXBhN3FVUUhPWTVobHll QUR5YWpsMnhiZ1ZMRmQzL2Z2SDNlcDVzdnlOcApId1h0L0s5WElyZ1ZoQjFjbG8rMjE1aXBnaDll Y3d5RTk3QmpqZ0FsczVRQ0lvQ2JkcHRRbjNwem1DcjVjODJECkRFOWhFU092NW9tUUN1bnpiOUNT b0xCak5LTVNrdTY1L2pBUHhCTE4xQ0o3QkVrL1QxL1RSai9jcDlVSzdrTm4KZUQzTXc4aStsQlNI a0xKQUI3aUlzTis1MHU2V0pBNWgrbFFHQ0lTdTZKbENSaWlEMXBCM0xQQUtpLzJTQk1ZbgpPSmNT Ukp2d3BQN092NDkvb2FYTFpzK3lmNkM3T2dPek03eUVGQ2kzZVBsVGRmT0JTM1JzK05UcEZZR0w2 L08rCkFpV3doRnMvMm9NQVkrZWRKTVgzeEw2MEFaL1Q5aVRRT3ZjeXRJdzZacFBlV1hML244QXBn cHNBNVFBUkFRQUIKdENWdFlYUjBZV3QxSUNodWIzQmxLU0E4YldGMGRHRnJkVUJoYkhSc2FXNTFl QzV2Y21jK2lRSTRCQk1CQWdBaQpCUUplTzFFT0Foc0RCZ3NKQ0FjREFnWVZDQUlKQ2dzRUZnSURB UUllQVFJWGdBQUtDUkMyNW1tU09wU3pmZThECkQvb0NPRGRQY0Q2UzdxbS9Lc1pMMEJwT2lta2lk QXFzdUZWdm8wZ0tEMStkNkcwWnZjL1JwYjVCVEpnQ2FRTHgKaGxROGU1QkVyaURXTzRHaFdSUHMw b0R1SldKaWxDZEhXcGduaVJ0QUxmS1VIZk5ybjlVOUhGQkQ1c09yMkpyaAoyeU1yb2NlUGRsSUw0 SVpzMzFIYW4xZzZKeTBkYnI3QVc2RlhxZXkzajNFT3V6Vjl2UTZYM2JicXo2OW5pcnl3ClRXUE43 bXhCelh4R3J4VURVTVMwanRNYlJJK2xhMlRoWFVQckZYVS93V0M4VjRkdFZQMXJTRjN2Q1VjWDYr OXIKSXdTZnZRK3VVNENCekxBOWhCQ0FlUmJRZUJlazc5cWdMVTdyU09CRUwyTUJ5SmNDdXB3dmR0 Znp0MHFuR3BBZApWZmpUdFJmS0lqRW9RRWU1WjFoOVFZYi84VEdTQ2lyaEVhQ05BT2hCZUdOM1VQ WjRMRTBXUVNWU0pZN0dsSlVICmwxRXhwbXdEbk5xMG4xWDhMTDBreUFxN041TmZSMkVUV012YUl4 VDFzZ2syVU5OUUxySWlxdDF4NEU0b3l5cFIKaGtoTktjdkNRSWQ1ekplSUV2OVJyVk1SUU4zL1Za QTJzYzRjWWs0RlBQQUFMeTRha1lvQ2VhdDVRQk9RTnE4MApnZnhZeGp1WnhZYWN1MFBrVW5nQnZ4 V3YwRDA0aW90NFhRcWhrd3pNQzhXYS9hREVtUmxUek5rUzFpdmdRSDRYCkJxeXpocktaQm8yQzNC cUhuL3FQblYveElNMHFTOW1JMVhDUWtnR1J1OU91WmNxNWJvODE1bGVyOENad0FaY0cKUlRiSmZl dnErOExvdExXSXpaY3lnY1ZtYjVQb2RHVFVwNmtXQWNpNHdKcFBqYmtDRFFSZU8xRU9BUkFBM1Zj RwpXZWVLY0xIdXg2bDAxZTRSRXpPNWl1SFBJOUFxSDhTYnRrc0lEckt1ODZsYkhTVUJ6bkhENWY0 K1ZCZkhyc25YCmg3ZHo5SnIvY0RVUFF5RjZKdlZBV1A5dVNoTkdrZi9xSmswRlpmNkpLbEdZYlEy MlZGeFB1cldaV1pZWG9mN2gKMFdhYTJPS09RN2lIVlBDN3pzTDh2WVNib2M3M0o4QVBnM2pWZzRr YjF4eE5MVk9SYiswdzhLaGdaeWdoNTBkMgpMeFI5UVdybGU3WmtUNE8rWllHeUpDbHU3NE9KZ3lO QUZ5Nyt2SmN0NjJnN1lFWjVBTWhwQWs0R21EYm9Jb1FCCjFud0IwWlVsSUVEZW40WTFJS2IvaXdj MXpvdzhBRGE0REhKQTMzbHdqd3VOelRieXJoYWNGK0VsWWNpQTVVWmEKaWNhQWxJWjBYY3pGS3lT RVN2N2dkczhJQWdyWTBtZjZJaDZCUlNydU0rUEt5V3VpTm5hSDJ6TTVocjdTc2QrMgozUFY2bFFR T2pJREQxVUs3L2NjNTV2d052Z0piNU5SK1RPbHBWZlRSZ0JnZ2NCdllUZXYrQmFlUkF4elUrZVNr CnVLQS90TDZCdnMyZU1lMXNud0MxcENWU0J1TUliSzhvdmUveWhJZE1HMWtYQ2diRWNHYlorUllr NmxmRFM4R0MKZEhpZ1dXYUozeWJKTDJKUkpPajFNOFdKTXZJcEJjU1pEZHJUYzRJUkNGR0JJMzZh VE9QRWsyQTA3b2FocTc1RQphSlNyMzhuNDU3Z2VUcG5LdGtGMWdpV29IaFpGUzB0Wk9Ua3lwdjJR eGtFclJTL2dHR3V5SndQSytJSVQrRXhQCkd5c0VUSnVCUjFsRW1sTTZQQmNXbDlidHBkQ3J3VnUx L2M2cWdxVUFFUUVBQVlrQ0h3UVlBUUlBQ1FVQ1hqdFIKRGdJYkRBQUtDUkMyNW1tU09wU3pmWlM0 RC8wVVkzNjJDaStJK3JoK3RlemdBMWduNDUxbE5GUkNMWCtTK1pHUwpuSU9SZDNhSGliQXp4dEcx TVNYNUpZbVJxd1RyNm1NOGs2bXNnd0Fwbit2Yk1UZFZ3MzNPT3JudFRQODI4YnlpCmVkL0ozSnNI aU4veGo5V2o1VkQzOS9qQ0t4YUk0WE52WjliYnhwZ2ZkcnpuS2RtM21pVEwvVmxIdlFFKy9XalgK M3JJTmNxblEva2hiWGhaOXdOUFNLZTVRQ0dWRGxGZEdpd0lIckU4SGd5R0JGdnF3ZGY3ZDBISlpV VEpWNTlsbgpnQnQ2OHBqTVZRZUtqQVY3T2Q3SkRjMGt4QzFGa3c0TTBDdjF3bkdyODVPL0tiUEN4 RDBLb1RXRlBFdTRIdUZWClVCaGcyM0RqVzgzWlEydHBYTlUxUzg1WmxHQmErTCs2OUJYRTZyL1hP MmJKT0IrUGlRNTJPdHFnaXlSMTU4NjUKbnkraFBEZFp3cWxRbUo5WWpUcE40VzhJYmV4S282LzFy ZEFUaTc0aVFHRWt6NDhwcy9VV0MwMXdjVVNjUkEvRApOZE5wb0FGYWxwalZSWERGQXhDb2xpNC9Q T1NHYzRxMjFwV0tOKzJLekVVU3YzOWNXenJicW1lUXQrOHp6ZUprCk81cHJNdG5SOGNlS002aXl2 cXk2dndaNVpHTjAwNEdpK2pNTFlVZ1ViUmxWKzgxbWZwTlVzYTd4NUp3bk9GQnIKdmR5VGh5RmhX Ym53Q01UZjA0Z1hDZW1LbitvdmNUOUQ2VFVYb1VuV2RnWU90UVpQUTEvcEJBVnFaZ2ROcW1LUQpr eXJUT0J3VVJJWitGUjhCcWhTYXByaTFJdExqcDNOcFVENFZ0N3d3V0dNc3AzQzV1VWhNc21hR1Vo Z2RLbUJVCjFqZjlmZz09Cj1XQk8xCi0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZIEJMT0NLLS0tLS0K Cg== 8637 2020-02-26 17:41:45 +0300 2020-02-26 17:41:45 +0300 Публичный ключ GPG GPG.key application/x-iwork-keynote-sffkey 3074 mattakushi10 LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkY1V2dsNEJFQUM3L21X MjN0OW5tMkZndzdaTitoZE0rTGNIWStnMTVWOHhLYXhUeXlnQ29TMnorTlZVCkljZmRVQ0F5KzZo UHBvQmJNT1hVMlpyRElqYlFWajQ0c0EzMUdUMjhpWmZBSXI4OGo4M1JHWThERnBqcVJKb20Kc25h K2cwL29jVVo4N3dHQlo0TGY2ZzUrdEZLaW1Vb1c4dDVFVzJDSEJoYkk1bGNTMlIrOStvMFU1eEFO cms3eQpTd2c1ZVpYeXhOaW9ERkZ2VmgwWWdxZGhlRFhHL01CUEJDdDY4Y2NObEJMRFVnWGZIL1Br blc0c0RVeFhHeXQ0Cjc0Y1ZZN1VoRTJRaHNTLzJnd3lheEZJN3Bqa3MzNnhzb0YrNHlzU1hpSFcz NWtCWXYzKytWWWorc0VQbWVBYXMKZ3N3U1RSVTB1Mk4ydVBxL29HSkxxR3FSREZJa0UzamQxVXkw M3RaRG9uSUlINkh4TTJwUGdMVkU4cHQxeFB4egpabkMrYW1ZK3JacGdOdk9zMlA2eCtKNlhWeFJ6 VHVxbG5XS1l2dWR3VnNCTkFxTm5UQ3NSVE5jaHlrZ2JkeTBECk13T05HQ3BWRmNUcEFkdHNOK2lS VGtmcGZhb0duSlVCdnhickI1VUoybTk3REhSelJQWWRaSWxrK3pWblhQWU4KQjVDb0Q1bkNmK1NW a3lCUGErdlNqTzZ2b0RQc3NZY1ByVSt2NlpheENuNjE0WTVEd3BkVHRRSUFEaXhLcWE1VwpwZm1m N3BxTjJzN21UN1dueHhEQjUwVFNsZVFRN25MSHFmTDNRa3V3VFJkL09JeUVlVzRFbUU0bXBJNUps MnpECjhpYnJycldqa2wxTkJYdndMMm9KalFXU3Y2NjVXL1FFWjZnektFLzNUSGFRaE9nUG5tY3ZW NWNFU1FBUkFRQUIKdENSTllYaHBiU0JMYm5saGVtVjJJRHh0WVhSMFlXdDFRR0ZzZEd4cGJuVjRM bTl5Wno2SkFqZ0VFd0VDQUNJRgpBbDVXZ2w0Q0d3TUdDd2tJQndNQ0JoVUlBZ2tLQ3dRV0FnTUJB aDRCQWhlQUFBb0pFTnpqYW1ubytxNDVOeElQCi8wanJPSmxOU0FGcnV4N1JiNHBoa2IrbWFrNitR MkJDNHBOMVo0aFhEYlpzbXNSZjR1b3puczhPcHNCenZpd0IKZnZPcUZESVp5T0tlSlduY253V3NG dDVPSlJmRUdpYk5kaG9vYTI1WWxqaVFibWxlTEluR1lJUU0yTEs5ZGNQOQpaM3lrRGNMRTRZYXJ0 b2dYZldSUm9DeHZNcTVQeG80M3V2RjBhT2FLUlRrTGpteW5vUkU0b2cxbUZoelVha2F5CnE3REhl Q3BDbTJFbjZYWk5xUlYveklEdGlWUlJKN1VjQzJCTmIzL2dDaVZiQkNoakpiYVJWREpuUjNxSzRH OC8KdDVxTUo5bHVCTGdLVUVyY3V5NnMzaFE1dTQ0c0lGeS9qVDl3NlEvOWlNK0FuNXVoTktlWmhs WUQ0aWZDeVZLSQpYZy8vRW9ERlZyWnhDZTh5R2hLOUh6QmM5Ulo2U20rQmVBNEJYbUFKUmtycGpr WUJyTmlWNWhFaFRlb2ZTY25xCm5teTJVc3JyL2lUNDl6cTVSN0dYeU52cG1ZLzMyTEpqNGhDTHRo b25kZk1hY2JoNGQzSWFVZlU2UTVjMWRYdCsKSmFuUDdyZ24zZHhiWCtzemsxMEUrRWpXaXg5MEhw WlVhU3poSTlDSWIxd3RXaU1MbEY1T0IyQ3d3YUpsekgrVwo0cXZtUTMycmN1Q1pTTVhkd25IZFBx Z0l0ZnlJSXhOSUlhbXA4L2lIazYrWk9ld09ndVZ3UldaK2hLMW95cVVtCjZueU4zMjZONU9pajBP OUc1WFlEK0lYR1lEYnJCcXVBb1ppY21CSXFlbFYzTmVPSzB1cVl4UXpBUG1qNmZLQ1gKTkI0Y2ND cnJPbG5hQnR5SHRPTGF2TDdwaEJreC9paHJNdllIejFNT0RWQ0t1UUlOQkY1V2dsNEJFQURaREtF bwprODhORUU1b3ZHcVp5RG9zeFIzZ00vK0ZoMGVpZW1uaW5xYWtKclUrZER6MXlNS2tLdUthblNq SjB1ZHZZRjl5ClFkZW1QUmQ0enhoZ2cxRUJUdHk2bXdtYmloM24yU1ZSUEZnbXlQZ3lYbkJsa2hK WWUxMENVRVpIbjNtNGcvQTgKQ3AwYnlva2JGUTFxSmtSRHUxMzJ3T3dZUjBTeDFrYzhBaFdnVXdJ Tk5zcSt3dlJMNmJkZDFSanNDUEpwSzBYVwptT2NPem0vVWlNaGVFVzZUb0ljOTRCNHF5ajJqREJm MG1VL0hSZmlWQlBXT2FEbXZoUUFBSlNCVjV6M3A4SlVDClFOZVFJcmpRVW5JbFM4MktQa2E4M0pq MWNkRGd2NGZteDlQZnhuZytvNDB0bFRJNDlDYkYrNGQ4cWpWL09sVk0KbUo0bVYzNXNJSVFBNFdL WW1LVC9LeHBSb2UwR2szL1NuWkJvdTFCOW03QTlVTmlvcUE0MlhEYjQyRGQwNlQrQgpSNXR0S2kz Q0psUkJNRU1NU0RZdlh2OU5yT0NxVm5GcnZQN0RybHBQaEJvMWN5K1U2b3NwRVpDU1ZMYS9RSTdR Ci9waGRuTzRHYzFtNTBtYy9RYnNOMnM1U0VTcFY3T1pOaTZUellQOWZ4UVJzWUxTL0FIT1dOSlAv VFN5QlZwNGcKaGd0eng0V1lKdUg5NnUyWk9SNUdpaEU4MmNPRnA4L3BRb29ua1BCZDd3cjRaWGxw VEpYeFA0Q0MrajFJbkMyWApOcklYNGZZUExHSG5BTENwUHZFSHdsMFg1SG5tWHNiSlREL2RZcURU UVNkYTIrUGw1ZWhoTXV4NmtXZitjUHgvCmRiUCtQVkxYZ1dUcXRLMFI0NXFETDZqVTNKQ3FhY3BY WFl3dzJRQVJBUUFCaVFJZkJCZ0JBZ0FKQlFKZVZvSmUKQWhzTUFBb0pFTnpqYW1ubytxNDVqZjRQ LzByZTBxelA3UzA4aEd5Q2Z2RUJtSUlFdllaWmY0Ymt3THY4OG5QWQpiMTl3Vk04SXhwYWdqN1Bn MlE0aUpJTjNSN3RpeUhDVEFDV1VXYmN4azdQUVlhMDhWN3BCQkVtN08yUHdWZm1jCnZiRWFnUENW blllK3F6Z2hDOEgreFU5ZW9mbEJlakc5TGRmWHo5NHFQcmF4Y2MzeGhyYVduaDRUNEZRend2WWIK R2htTVl5d0ZsRHplSzBqbloyZ0o1eVhUS1U0S3l2aEgwd080MjBJazBSN2hlanAra2JzNkM5OFc3 V2R2d3cvagpjcUJqUjFja0VZTWdiV3pheXBpVUxoc3hWSVBqeWNXY3ZTbWNJWGl0T3F1UWFpYUp1 a1MvSE5ienhYQWZKbnNJCmNYdEIxWU1jdld6RlM4RFJRQ1lMVFcycEoySkYwMzF5RGVVdU5DNVUx SVo1Tk5QMHBYOHdlSnhjYU8rR0xnb0EKOFZCTXlGTDBGZTdhRXBZcVh5TlBFYzRKNGNKNmswZlBE Z3JmQmFvTno3dHV1UkpwOFRxS3Rva09CaFBlTmpGZQo5bUdHNXlFU0hjbkdqalROQzhsV1RyVW9Y ckp2L2tTTE42ek1BMXQ3QXN6OGFLeUtITjJmRyt0TU9mQ1VVcWdzCmhIbWMvRVRuUHlGZTg5d3dD Kzh3cWRNL0dNUFZ5R3g0RWtLNFB2MWVrZ1UrL1dYU0VnaEEzTjJsbFdQcWhlTFoKZDBJSFgzSjZt Tm1zUDZOazF2YUN0ZU9sNUtzN2xqTHI1SWdwNDdwY2I5QVlzN0o3ZzhZYURQUFJScXVjZjdaUgo2 WjdtUk9GaWpJQXV6aUtyNVNFQ2ZVeDhPSGZTVkVIbjcxUGpFc00xMUFOSG9QamRtbnp0R0FUL0p3 Z21KNDFSCkY5eHUKPWtPL0EKLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxPQ0stLS0tLQo=