ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | [4.2] join smasher@ | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Team Accounts | Reporter: | Vladislav Glinkin <glinkinvd> | ||||||||
| Component: | join | Assignee: | Gleb F-Malinovskiy <glebfm> | ||||||||
| Status: | ASSIGNED --- | QA Contact: | Andrey Cherepanov <cas> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | P5 | CC: | ancieg, arseny, glebfm, ldv | ||||||||
| Version: | unspecified | ||||||||||
| Hardware: | all | ||||||||||
| OS: | Linux | ||||||||||
| URL: | https://altlinux.org/Team/Join | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Vladislav Glinkin
2023-03-14 19:35:45 MSK
Created attachment 12743 [details]
GPG Public Key
(Ответ для Vladislav Glinkin на комментарий #0) > Имя ментора: ancieg Согласен быть ментором. > Псевдоним: glinkinvd
UPD:
В качестве псевдонима хочу использовать: smasher
Прикрепляю изменённый публичный GPG ключ
Created attachment 12759 [details]
GPG Public Key
(Ответ для Vladislav Glinkin на комментарий #3) > > Псевдоним: glinkinvd > UPD: > В качестве псевдонима хочу использовать: smasher > Прикрепляю изменённый публичный GPG ключ ОК. Просьба сразу выдать доступ к gitery. Ключи в порядке. ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3. Прошу выдать доступ к gyle. ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.5. На данный момент собрано: https://pypi.org/project/onigurumacffi/ https://pypi.org/project/remote-pdb/ https://pypi.org/project/babi-grammars/ https://pypi.org/project/babi/ в https://packages.altlinux.org/ru/tasks/328594/ https://crates.io/crates/hunt в https://packages.altlinux.org/ru/tasks/328085/ UPD: Новые, собранные пакеты https://crates.io/crates/procs в https://packages.altlinux.org/ru/tasks/326698/ https://pkg.go.dev/github.com/six-ddc/plow в https://packages.altlinux.org/ru/tasks/326695/ Новые пакеты: https://onefetch.dev/ в https://packages.altlinux.org/ru/tasks/326691/ https://www.gnu.org/software/pem/ в https://packages.altlinux.org/ru/tasks/326612/ https://pkg.go.dev/github.com/cenkalti/rain в https://packages.altlinux.org/ru/tasks/332277/ Думаю, что пора звать рецензента. Адрес подписан на devel@, теперь это делается раньше -- в пункте 3.6. Призван рецензент (arseny@) для независимой оценки готовности кандидата. T/J/S -> 4.2. (In reply to Gleb F-Malinovskiy from comment #15) > Призван рецензент (arseny@) для независимой оценки готовности кандидата. > > T/J/S -> 4.2. Посмотрю на этой неделе. Ну что ж, потихоньку начнём. :) pem --- В спеке в %files ман-страницы указаны как `.1.xz`. Лучше `.1*`, потому что тип сжатия ман-страниц может измениться независимо от вашего пакета (и суффикс вместе с ним). Например: %_man1dir/*.1* В пакете, например, onefetch это (формально) учтено, поэтому в ошибки упаковки не записываю. Но фрагмент имени про секцию лучше синхронизировать с номером секции в подкаталоге %_datadir/man, чтобы ловить у апстрима несовпадения. Придирки: * файл pem.txt с примером CSV-базы, видимо, является демонстрационным и для работы программы pem(1) не нужен, но апстрим его кладёт под %_datadir и, вероятно, более не занимается проектом. Я б его переложил под директиву %doc. (впрочем, пакет заработает и без этого). * вы зачем-то его переименовываете в example.pem, хотя программа сама не заканчивает имена файлов под ~/.pem этим суффиксом. Такой суффикс часто применяют для хранения реальных файлов PEM — base64-подобный контейнерный формат для блобов, например, x509-данных: ключи шифрования, сертификаты, ..., или блоков с цифровой подписью, проч. Формат PEM и это соглашение гораздо более популярны, чем GNU Pem. Я б не стал так делать, можно назвать example.txt, например. Да, реально отличать файлы стоит по сигнатурам их содержимого, но выдумывать соглашения за апстрим, полагаю, ни к чему. Вопрос _к кандидату_: Обоснуйте, пожалуйста, выбор gear-схемы. Если бы в пакете гипотетически появилась необходимость исправлять исходники, как вы бы это оформили? onefetch -------- Коммит, где фиксируются cargo-зависимости, называется "dependencies for version N"; в этом названии нет сказуемого, создаётся ложное впечатление, что зависимости есть только в этой ревизии дерева и дальше пропадут. > Write your commit message in the imperative: "Fix bug" and not "Fixed bug" > or "Fixes bug." This convention matches up with commit messages generated > by commands like git merge and git revert. https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html А вот %changelog в спеке это соглашение не затрагивает; там рекомендуется прошедшее время. То же самое касается других rust+cargo-пакетов. Придирки: В тексте %description предложения лучше заканчивать точкой (ибо это небольшой, но текст), в отличие от слоганов в %summary. То же самое касается %changelog. То же самое касается других rust+cargo-пакетов. procs ----- Среди cargo-барахла нашёлся, например, крейт winapi-i686-pc-windows-gnu, полный не работающих в нашей системе `.a`. Так как наш пакет, как я могу судить после беглого прочтения, не связан с кросс-компиляцией под маздай или с анализом блобов под эту платформу, этот мусор зря занимает место в архиве; его стоит убрать по мере возможностей. Надёжного инструмента для этого нет, но есть подсказки, как это делать руками: https://altlinux.org/RPM/Rust Рекомендую проверить и другие cargo-пакеты. Придирки: аналогично onefetch. hunt — в общем, аналогично. Сегодня пакеты на базе сборочной системы cargo сложнее обновлять, чем собирать заново. Чтобы закрепить свои навыки, Владиславу стоит обновить какой-нибудь существующий пакет на базе cargo, например, один из своих пакетов. Это заодно и шанс исправить (в будущих коммитах) описанные выше малые недочёты. :) Питон посмотрю в ближайшее время. (In reply to Arseny Maslennikov from comment #18) > Коммит, где фиксируются cargo-зависимости, называется "dependencies for > version N"; в этом названии нет сказуемого, создаётся ложное впечатление, > что зависимости есть только в этой ревизии дерева и дальше пропадут. > > Write your commit message in the imperative: "Fix bug" and not "Fixed bug" > > or "Fixes bug." This convention matches up with commit messages generated > > by commands like git merge and git revert. > https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html Например, "vendor dependencies for version N". Или update, reflect, ... по вкусу. (In reply to Arseny Maslennikov from comment #18) > Питон посмотрю в ближайшее время. Судя по всему, модули упакованы в соответствии со следующими гайдами: https://www.altlinux.org/Python_packaging_guide https://www.altlinux.org/Management_of_Python_dependencies_sources Каких-либо нормативных предписаний по поводу Python-модулей у нас нет, так что пусть. Вопрос _к кандидату_. В файле babi.spec: > # Remove the line 'license_file = LICENSE' for setuptools (actual for version 1.5.5) > sed -i '11d' setup.cfg > Пожалуйста, обоснуйте, почему вы выбрали именно такой способ поправить setup.cfg. В общем: - жду ответов на вопросы; - хочу увидеть хотя бы 1 собранный не-noarch пакет на базе традиционных кросс-языковых систем управления проектом (meson/cmake/autotools); например, https://github.com/wolfpld/tracy был бы не самым бесполезным пакетом; - как уже писал выше, хочу увидеть обновление какого-нибудь пакета на rust-cargo, раз уж вам интересны пакеты на rust. :) (Ответ для Arseny Maslennikov на комментарий #21) > В общем: > - жду ответов на вопросы; > - хочу увидеть хотя бы 1 собранный не-noarch пакет на базе традиционных > кросс-языковых систем управления проектом (meson/cmake/autotools); например, > https://github.com/wolfpld/tracy был бы не самым бесполезным пакетом; > - как уже писал выше, хочу увидеть обновление какого-нибудь пакета на > rust-cargo, раз уж вам интересны пакеты на rust. :) Арсений, здравствуйте. Хочу поблагодарить вас за вашу рецензию. Узнал для себя что-то новое и сделал выводы. 1. Обновление rust пакетов: https://packages.altlinux.org/ru/tasks/343071/ https://packages.altlinux.org/ru/tasks/343619/ https://packages.altlinux.org/ru/tasks/343843/ При обновлении данных пакетов произвёл очистку зависимостей вендора от бинарных артефактов. Все подробности и изменения можно просмотреть в гите (старался делать информативные коммиты). 2. Собрал tracy по вашей просьбе, однако пакет на данный момент не попал в сизиф (находится на ревью у ментора). Сборочное задание: https://packages.altlinux.org/ru/tasks/343948/ 3. Ответы на вопросы. > Обоснуйте, пожалуйста, выбор gear-схемы. Если бы в пакете гипотетически появилась необходимость исправлять исходники, как вы бы это оформили? На примере pem'а я тренировался собирать пакет с исходниками в виде тарболла с помощью gear. Правку исходников я бы оформил в виде патчей, полагаю. > Пожалуйста, обоснуйте, почему вы выбрали именно такой способ поправить setup.cfg. (babi) Пакет собирался из тэга, но на момент сборки пакета, в основной ветке upstream'а setup.cfg уже был исправлен. Принял решение поправить недочёт в setup.cfg с помощью sed'а в спеке (с соответствующим комментарием), так как в следующей версии пакета данное исправление не понадобится и строчку из спека можно будет удалить. Почему-то такое решения мне показалось самым простым. Дополнительно собрал: https://packages.altlinux.org/ru/tasks/344421/ https://packages.altlinux.org/ru/tasks/344504/ (In reply to Vladislav Glinkin from comment #22) > (Ответ для Arseny Maslennikov на комментарий #21) > > В общем: > > - жду ответов на вопросы; > > - хочу увидеть хотя бы 1 собранный не-noarch пакет на базе традиционных > > кросс-языковых систем управления проектом (meson/cmake/autotools); например, > > https://github.com/wolfpld/tracy был бы не самым бесполезным пакетом; > > - как уже писал выше, хочу увидеть обновление какого-нибудь пакета на > > rust-cargo, раз уж вам интересны пакеты на rust. :) > > Арсений, здравствуйте. Хочу поблагодарить вас за вашу рецензию. Узнал для > себя что-то новое и сделал выводы. ^^ Всегда пожалуйста! > <...> > 3. Ответы на вопросы. > > Обоснуйте, пожалуйста, выбор gear-схемы. Если бы в пакете гипотетически появилась необходимость исправлять исходники, как вы бы это оформили? > > На примере pem'а я тренировался собирать пакет с исходниками в виде тарболла > с помощью gear. Правку исходников я бы оформил в виде патчей, полагаю. Ок, это имеет смысл, пока их немного. > > Пожалуйста, обоснуйте, почему вы выбрали именно такой способ поправить setup.cfg. (babi) > > Пакет собирался из тэга, но на момент сборки пакета, в основной ветке > upstream'а setup.cfg уже был исправлен. > Принял решение поправить недочёт в setup.cfg с помощью sed'а в спеке (с > соответствующим комментарием), так как в следующей версии пакета данное > исправление не понадобится и строчку из спека можно будет удалить. > Почему-то такое решение мне показалось самым простым. Раз в следующей версии этот процедурный патч больше не понадобится, то и ладно. Но иначе было бы неубедительно. "Вас арестовала полиция спеков; в этот раз без штрафа, но больше не нарушайте". :) Другие случаи, где это допустимо, бывают, но очень и очень особенные; в основном касаются первых строк, номер которых несёт в файле особый смысл, "заголовочных" или вроде того. До остального доберусь чуть позже... (In reply to Vladislav Glinkin from comment #22) > (Ответ для Arseny Maslennikov на комментарий #21) > > В общем: > > - жду ответов на вопросы; > > - хочу увидеть хотя бы 1 собранный не-noarch пакет на базе традиционных > > кросс-языковых систем управления проектом (meson/cmake/autotools); например, > > https://github.com/wolfpld/tracy был бы не самым бесполезным пакетом; > > - как уже писал выше, хочу увидеть обновление какого-нибудь пакета на > > rust-cargo, раз уж вам интересны пакеты на rust. :) > > 2. Собрал tracy по вашей просьбе, Круто, спасибо! > однако пакет на данный момент не попал в сизиф (находится на ревью у ментора). Не беда. Меня и так долго ждали, посмотрю сам. > Сборочное задание: https://packages.altlinux.org/ru/tasks/343948/ Сначала на https://git.altlinux.org/tasks/343948/build/1000/x86_64/log гляжу. Замечания: 1) cmake запущен так: [00:00:03] Executing(%build): /bin/sh -e /usr/src/tmp/rpm-tmp.61562 <...> [00:00:03] + cmake -DCMAKE_SKIP_INSTALL_RPATH:BOOL=yes '-DCMAKE_C_FLAGS:STRING=-pipe -frecord-gcc-switches -Wall -g -O2 -flto=auto' '-DCMAKE_CXX_FLAGS:STRING=-pipe -frecord-gcc-switches -Wall -g -O2 -flto=auto' '-DCMAKE_Fortran_FLAGS:STRING=-pipe -frecord-gcc-switches -Wall -g -O2 -flto=auto' -DCMAKE_INSTALL_PREFIX=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_DESTINATION=lib64 -DLIB_SUFFIX=64 -S . -B x86_64-alt-linux -DBUILD_SHARED_LIBS=ON Не передано никакое значение для cache var CMAKE_BUILD_TYPE. Результат гораздо ниже, на этапе, где мы генерируем debuginfo-пакет: [00:01:15] 056-debuginfo.brp: WARNING: You have 5 stripped ELF objects. Please compile with debugging information! [00:01:15] 056-debuginfo.brp: WARNING: An excerpt from the list of affected files follows: [00:01:15] ./usr/bin/tracy [00:01:15] ./usr/bin/tracy-capture [00:01:15] ./usr/bin/tracy-csvexport [00:01:15] ./usr/bin/tracy-import-chrome [00:01:15] ./usr/bin/tracy-update Надо передавать что-то с debuginfo: `-DCMAKE_BUILD_TYPE=RelWithDebInfo`. Здесь очень полезно вставлять в спек `%define _stripped_files_terminate_build 1`; ещё одно определение, которое должно быть дефолтом, но им не является из-за большого числа пакетов, пересборка которых без этого сломается и которые потребуют вмешательства, создав на мейнтейнеров одноразовую волну нагрузки. Рекомендую это сделать, можно прямо рядом с `*unpackaged_files*`. 2) Апстрим ставит файлы: [00:01:15] -- Installing: /usr/src/tmp/tracy-buildroot/usr/share/Tracy/TracyTargets.cmake [00:01:15] -- Installing: /usr/src/tmp/tracy-buildroot/usr/share/Tracy/TracyTargets-noconfig.cmake [00:01:15] -- Installing: /usr/src/tmp/tracy-buildroot/usr/share/Tracy/TracyConfig.cmake Больше ничего в %_datadir/Tracy не ставит. Вы указали в спеке: 86 %files -n lib%name-devel 87 %_includedir/%name 88 %_includedir/common 89 %_includedir/client 90 %_libdir/libTracyClient.so 91 %_datadir/Tracy ^^^^^^^^^^^^^^^ Пакет получится корректным, конечно, но этот каталог выглядит слишком общим, чтобы в роли packager считать, что всё в нём всегда будет относиться к devel-пакету от библиотеки. Рекомендую: 91 -%_datadir/Tracy 91 +%_datadir/Tracy/*.cmake Да и cmake-конфиги в не-cmake-специфичном каталоге — это что-то особенного. Смогут ли программы-пользователи этих файлов найти их здесь? Стоило бы посмотреть, как апстрим закодил упаковку/установку в destdir этих файлов и чего хотел этим добиться. 3) Кстати, о библиотеках. В альте принята https://www.altlinux.org/Shared_Libs_Policy. Она придумана не просто так; её несоблюдение создаёт реальные проблемы. Вопрос к кандидату: соответствуют ли пакеты lib%name, lib%name-devel этой спецификации (по духу/смыслу, не обязательно по букве)? и, независимо от ответа, почему? Далее о спеке. https://git.altlinux.org/tasks/343948/gears/1000/git?p=git;a=blob;f=.gear/tracy.spec;h=66d8f8fba286aa4355d5989c5d29e32a56c28cb6;hb=11e11f6cf6946384b79329ce3c5bb10d4af85b87 > Group: Monitoring Это профилировщик работы программы для разработчика, а не средство наблюдения за неинтерактивными по природе системами. Development-что-то, полагаю. Не настаиваю, ибо есть пространство для интерпретации. > BuildRequires(pre): rpm-macros-cmake хорошо! > 21 BuildRequires: libcapstone-devel > 22 BuildRequires: libfreetype-devel > 23 BuildRequires: wayland-devel > 24 BuildRequires: libdbus-devel CMake, конечно, пытается конкурировать с pkg-config (и, как обычно, ему проигрывает), поэтому может .pc-файлами для обнаружения devel-артефактов не пользоваться. Но вообще лучше pkgconfig(freetype), pkgconfig(wayland), ... Я мог ошибиться в фактических именах. Так что в этом пакете настаивать я не стану. К тому же у нас, насколько мне известно, всё плохо с генерацией зависимостей вида `cmake($ID)` на пакеты с CMake-конфигами. Но на будущее — вот. > 40 %package -n lib%name > 41 Group: System/Libraries > 42 Summary: %name library > 43 %description -n lib%name > 44 %summary -n lib%name. Как вы думаете, что оказалось в %description? Можете проверить себя и посмотреть, какое фактически получилось описание: % wget https://git.altlinux.org/tasks/343948/build/1000/x86_64/rpms/libtracy-0.10-alt1.x86_64.rpm && rpm -qip libtracy-0.10-alt1.x86_64.rpm :) Дешёвый способ составить приличное описание — взять (уже приличную) копипасту из главного пакета и через пустую строку прописать "This package contains ...", пару слов о том, что же он всё-таки contains. Аналогично для других подпакетов. Про changelog вам, как я понимаю, ментор + коллеги должны были проесть все уши. :) С точки зрения информативности там всё хорошо. До остального доберусь позже... В общем, прошу: — ответить на вопрос; — разобраться с отмеченными недочётами, кроме тех, где явно написано, что не настаиваю. > Вопрос к кандидату: соответствуют ли пакеты lib%name, lib%name-devel этой спецификации (по духу/смыслу, не обязательно по букве)? и, независимо от ответа, почему? Насколько я понял, Shared Libs Policy нужна для того, чтобы разные версии разделяемых библиотек могли сосуществовать в одной системе, иначе при каждом обновлении разделяемой библиотеки могут быть неприятные последствия в виде поломки зависимых пакетов. По правилам упаковки: 1) Пакет вида lib%name должен содержать в себе файл с расширением .so (разделяемую библиотеку) с обязательным указанием версии. В данном пакете не должны лежать файлы, которые не содержат версию разделяемой библиотеки в названии или пути для избежания конфликтов с новой версией. 2) Пакет lib%name-devel предназначен для хранения файлов, имеющих отношение к разработке. К примеру, чаще всего в такие пакеты кладут заголовочные файлы. Однако, в моём случае, сюда так же попал и .so файл, не имеющий версии (так же сделано и в https://packages.altlinux.org/sisyphus/srpms/libxmlb/specfiles/). Так как оба вышеперечисленных условия соблюдаются, то мой .spec файл данную политику не нарушает, насколько я полагаю. > — разобраться с отмеченными недочётами, кроме тех, где явно написано, что не настаиваю. В ближайшее время постараюсь разобраться. Пересобрал tracy - https://packages.altlinux.org/ru/tasks/343948/ Исправления: - Исправил описания пакетов. - Пропатчил CMakeLists.txt для использования общепринятой директории для .cmake модулей (ответа на вопрос, зачем апстрим клал их в /usr/share/ я не нашёл). - Изменил группу пакета на Development/Tools По поводу '%define _stripped_files_terminate_build 1': Бинарные файл данного пакета компилируются с помощью запуска make. Каждая утилита имеет свою директорию согласно документации. В каждой директории расположены .mk файлы с различными конфигурациями. Насколько я понял, для поддержки debugging нужно указать CFLAGS += -g. Однако, конфигурация release.mk какой-либо утилиты данный флаг не использует. Пример: CFLAGS := -O3 ifndef TRACY_NO_LTO CFLAGS += -flto endif DEFINES := -DNDEBUG BUILD := release include ../../../common/unix-release.mk include build.mk Из-за этого, я ничего трогать не стал. Возможно, есть другой способ. На данный момент в апстриме перешли на использование cmake, но нового релизного тэга пока что нет. |
