Created attachment 12742 [details] SSH Public Key Псевдоним: glinkinvd Почта для пересылки: VladislavDenisov2002@mail.ru Имя ментора: ancieg Цель вступления: Научиться собирать и сопровождать пакеты
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, но нового релизного тэга пока что нет.
Может поменяем рецензента? Текущий последнее время не проявляет активности в рецензировании данного кандидата. Вообще, если не секрет, мне было бы интересно узнать у рецензентов (в том числе и текущего) что может отталкивать от выполнениях рецензии - именно в рамках "работы" рецензента (помимо работы, личной жизни, отдыха и т.п.)?
(In reply to Vladislav Glinkin from comment #27) > Пересобрал tracy - https://packages.altlinux.org/ru/tasks/343948/ Хорошо. > Исправления: > - Исправил описания пакетов. Уже немного лучше, но, например, в описании libtracy нет вообще никакой информации о том, для чего эта библиотека и/или для чего её вообще подгружают программы. Я уж не говорю о том, что она вообще-то libTracyClient.so (что уже может намекать). Кстати, про имена пакетов с библиотеками. С точки зрения shared libs policy, строго говоря, пакет libtracy действительно ничего не нарушает — просто, если изменится soname, нужно будет сформировать пакет с другим именем, и тогда-то проще всего будет приписать 1 (или какая там будет версия). Не будь у подпакета плохого description, я бы совсем не возражал. Но стоит ли создавать искусственные затруднения тем, кому потом в этом разбираться? > - Пропатчил CMakeLists.txt для использования общепринятой директории для > .cmake модулей (ответа на вопрос, зачем апстрим клал их в /usr/share/ я не > нашёл). > - Изменил группу пакета на Development/Tools OK > > По поводу '%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, но нового релизного тэга пока что нет. Ладно. :)
(In reply to Anton Zhukharev from comment #28) > Может поменяем рецензента? > Текущий последнее время не проявляет активности в рецензировании данного > кандидата. > > Вообще, если не секрет, мне было бы интересно узнать у рецензентов (в том > числе и текущего) что может отталкивать от выполнениях рецензии - именно в > рамках "работы" рецензента (помимо работы, личной жизни, отдыха и т.п.)? Честно? :) Из моих субъективных заморочек — только необходимость ревьюить много пакетов на cargo.
(In reply to Arseny Maslennikov from comment #30) > (In reply to Anton Zhukharev from comment #28) > > Может поменяем рецензента? > > Текущий последнее время не проявляет активности в рецензировании данного > > кандидата. Справедливости ради, то, что я сегодня в эту багу написал, я уже подготовил чуть раньше на этой неделе, но думал прокомментировать сразу всё. Оптимально, наверное, было бы ввести какую-то частоту пинга и после нескольких таймаутов уже делать отвод. Что касается текущей рецензии: К упаковке tracy у меня вопросов нет, кроме неясных метаданных у libtracy (выше подробно). Они, строго говоря, не мешают _работе_ пакета, так что считаю, что кандидат уже научился собирать пакеты такого типа; а этот недочёт вызван не недостатком навыков, а допущен просто из лени. :) Осталось посмотреть пакеты на cargo.
(In reply to Vladislav Glinkin from comment #22) > (Ответ для 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/ — procs OK with nits. diff --git a/.gear/tags/list b/.gear/tags/list index a97751e2..9047f881 100644 --- a/.gear/tags/list +++ b/.gear/tags/list @@ -1,2 +1 @@ -71778f6f219eee5e7e3377c81cf20dba4e6b0db5 v0.14.0 -af63ccb7ec06e59535f562385d639c511c071c54 v0.14.3 +4f1f6ab87c8f10e7369c1b730d946f333b0fb64c v0.14.5 Убрали лишние теги — оч. хорошо. Ещё в 0.14.0-alt1 появилась вот такая строчка в %prep: > > +install -D %SOURCE2 .cargo/config.toml Если не передать -m644, на этом файле будет x-бит; вот такая у install(1) не вполне очевидная семантика (хотя она становится логичной, если вспомнить, для чего исторически была нужна install(1) и почему cp(1) для этого не подходила). # ls -ldi toml 24339638 -rw-r--r-- 1 root root 11 Jul 25 17:43 toml # install --debug -D toml .t/t.txt install: creating directory '.t' 'toml' -> '.t/t.txt' copy offload: unknown, reflink: yes, sparse detection: unknown # install --debug -D toml .t/t.txt removed '.t/t.txt' 'toml' -> '.t/t.txt' copy offload: unknown, reflink: yes, sparse detection: unknown # ls -ldi .t/t.txt 24339647 -rwxr-xr-x 1 root root 11 Jul 25 17:43 .t/t.txt # install --debug -D -m644 toml .t/t.txt removed '.t/t.txt' 'toml' -> '.t/t.txt' copy offload: unknown, reflink: yes, sparse detection: unknown # ls -ldi .t/t.txt 24339648 -rw-r--r-- 1 root root 11 Jul 25 17:45 .t/t.txt На config.toml x-бит не нужен. Здесь это не ведёт к ошибке упаковки, ибо файл в пакет не попал, да и дальше вы этим пользуетесь, но на будущее лучше имейте в виду. То же касается и hunt, и onefetch. > https://packages.altlinux.org/ru/tasks/343619/ — hunt OK. Дополнительных вопросов нет.
(In reply to Vladislav Glinkin from comment #22) > (Ответ для Arseny Maslennikov на комментарий #21) > > В общем: > > - жду ответов на вопросы; > > - хочу увидеть хотя бы 1 собранный не-noarch пакет на базе традиционных > > кросс-языковых систем управления проектом (meson/cmake/autotools); например, > > https://github.com/wolfpld/tracy был бы не самым бесполезным пакетом; > > - как уже писал выше, хочу увидеть обновление какого-нибудь пакета на > > rust-cargo, раз уж вам интересны пакеты на rust. :) > > 1. Обновление rust пакетов: > <...> > https://packages.altlinux.org/ru/tasks/343843/ — onefetch А зачем там CMake? В git и комментариях не написано. Что мешает убрать BR на cmake?
(Ответ для Arseny Maslennikov на комментарий #33) > А зачем там CMake? В git и комментариях не написано. Что мешает убрать BR на > cmake? Виноват, стоило оставить по этому поводу комментарий. Без cmake пакет не собирался.
(Ответ для Vladislav Glinkin на комментарий #34) > Виноват, стоило оставить по этому поводу комментарий. Без cmake пакет не > собирался. Требовался для сборки одного из растовых крэйтов.
(In reply to Vladislav Glinkin from comment #34) > (Ответ для Arseny Maslennikov на комментарий #33) > > А зачем там CMake? В git и комментариях не написано. Что мешает убрать BR на > > cmake? > > Виноват, стоило оставить по этому поводу комментарий. Без cmake пакет не > собирался. Если так, то ладно. Ещё лучше как-то описать причину, по которой он там нужен (кто его вызывает, для чего), и/или цитату из вывода. Смысл в том, чтобы читателю стало понятно, почему без него там никак. Среди исходников, конечно, затесалось вот это: % git ls-files -c | grep CMakeLists vendor/libz-ng-sys/src/zlib-ng/CMakeLists.txt vendor/libz-ng-sys/src/zlib-ng/test/pigz/CMakeLists.txt vendor/lzma-sys/xz-5.2/CMakeLists.txt Но само наличие там каких-то файлов ещё ни о чём не говорит :)
(In reply to Vladislav Glinkin from comment #35) > (Ответ для Vladislav Glinkin на комментарий #34) > > Виноват, стоило оставить по этому поводу комментарий. Без cmake пакет не > > собирался. > > Требовался для сборки одного из растовых крэйтов. Тогда я б написал там именно это и что за крейт. В будущем обновлении, конечно; торопиться с этим не обязательно. zlib-ng и xz, кстати, есть и системные... Это больше вопрос к тем, кто занимается соотв. крейтами; мы не можем ожидать, что в каждом cargo-пакете мейнтейнер все такие вещи упорно девендорил.
(Ответ для Arseny Maslennikov на комментарий #36) > (In reply to Vladislav Glinkin from comment #34) > > (Ответ для Arseny Maslennikov на комментарий #33) > > > А зачем там CMake? В git и комментариях не написано. Что мешает убрать BR на > > > cmake? > > > > Виноват, стоило оставить по этому поводу комментарий. Без cmake пакет не > > собирался. > > Если так, то ладно. Ещё лучше как-то описать причину, по которой он там > нужен (кто его вызывает, для чего), и/или цитату из вывода. Смысл в том, > чтобы читателю стало понятно, почему без него там никак. > > Среди исходников, конечно, затесалось вот это: > % git ls-files -c | grep CMakeLists > vendor/libz-ng-sys/src/zlib-ng/CMakeLists.txt > vendor/libz-ng-sys/src/zlib-ng/test/pigz/CMakeLists.txt > vendor/lzma-sys/xz-5.2/CMakeLists.txt > Но само наличие там каких-то файлов ещё ни о чём не говорит :) error: failed to run custom build command for `libz-ng-sys v1.1.9` Caused by: process didn't exit successfully: `/usr/src/RPM/BUILD/onefetch-2.21.0/target/release/build/libz-ng-sys-b86d4d5257a5f806/build-script-build_zng` (exit status: 101) --- stdout CMAKE_TOOLCHAIN_FILE_x86_64-unknown-linux-gnu = None CMAKE_TOOLCHAIN_FILE_x86_64_unknown_linux_gnu = None HOST_CMAKE_TOOLCHAIN_FILE = None CMAKE_TOOLCHAIN_FILE = None CMAKE_GENERATOR_x86_64-unknown-linux-gnu = None CMAKE_GENERATOR_x86_64_unknown_linux_gnu = None HOST_CMAKE_GENERATOR = None CMAKE_GENERATOR = None CMAKE_PREFIX_PATH_x86_64-unknown-linux-gnu = None CMAKE_PREFIX_PATH_x86_64_unknown_linux_gnu = None HOST_CMAKE_PREFIX_PATH = None CMAKE_PREFIX_PATH = None CMAKE_x86_64-unknown-linux-gnu = None CMAKE_x86_64_unknown_linux_gnu = None HOST_CMAKE = None CMAKE = None running: cd "/usr/src/RPM/BUILD/onefetch-2.21.0/target/release/build/libz-ng-sys-3ab9c0849bd3c7f2/out/build" && CMAKE_PREFIX_PATH="" "cmake" "/usr/src/RPM/BUILD/onefetch-2.21.0/vendor/libz-ng-sys/src/zlib-ng" "-DBUILD_SHARED_LIBS=OFF" "-DZLIB_COMPAT=OFF" "-DZLIB_ENABLE_TESTS=OFF" "-DWITH_GZFILEOP=ON" "-DCMAKE_INSTALL_PREFIX=/usr/src/RPM/BUILD/onefetch-2.21.0/target/release/build/libz-ng-sys-3ab9c0849bd3c7f2/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_CXX_COMPILER=c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=Release" --- stderr thread 'main' panicked at /usr/src/RPM/BUILD/onefetch-2.21.0/vendor/cmake/src/lib.rs:1098:5: failed to execute command: No such file or directory (os error 2) is `cmake` not installed? build script failed, must exit now note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace warning: build failed, waiting for other jobs to finish... error: Bad exit status from /usr/src/tmp/rpm-tmp.13907 (%build)
(In reply to Vladislav Glinkin from comment #38) > (Ответ для Arseny Maslennikov на комментарий #36) > > (In reply to Vladislav Glinkin from comment #34) > > > (Ответ для Arseny Maslennikov на комментарий #33) > > > > А зачем там CMake? В git и комментариях не написано. Что мешает убрать BR на > > > > cmake? > > > > > > Виноват, стоило оставить по этому поводу комментарий. Без cmake пакет не > > > собирался. > > > > Если так, то ладно. Ещё лучше как-то описать причину, по которой он там > > нужен (кто его вызывает, для чего), и/или цитату из вывода. Смысл в том, > > чтобы читателю стало понятно, почему без него там никак. > > > > Среди исходников, конечно, затесалось вот это: > > % git ls-files -c | grep CMakeLists > > vendor/libz-ng-sys/src/zlib-ng/CMakeLists.txt > > vendor/libz-ng-sys/src/zlib-ng/test/pigz/CMakeLists.txt > > vendor/lzma-sys/xz-5.2/CMakeLists.txt > > Но само наличие там каких-то файлов ещё ни о чём не говорит :) > > error: failed to run custom build command for `libz-ng-sys v1.1.9` > > Caused by: > process didn't exit successfully: > `/usr/src/RPM/BUILD/onefetch-2.21.0/target/release/build/libz-ng-sys- > b86d4d5257a5f806/build-script-build_zng` (exit status: 101) > --- stdout > <...> > running: cd > "/usr/src/RPM/BUILD/onefetch-2.21.0/target/release/build/libz-ng-sys- > 3ab9c0849bd3c7f2/out/build" && CMAKE_PREFIX_PATH="" "cmake" > "/usr/src/RPM/BUILD/onefetch-2.21.0/vendor/libz-ng-sys/src/zlib-ng" > "-DBUILD_SHARED_LIBS=OFF" "-DZLIB_COMPAT=OFF" "-DZLIB_ENABLE_TESTS=OFF" > "-DWITH_GZFILEOP=ON" > "-DCMAKE_INSTALL_PREFIX=/usr/src/RPM/BUILD/onefetch-2.21.0/target/release/ > build/libz-ng-sys-3ab9c0849bd3c7f2/out" "-DCMAKE_C_FLAGS= > -ffunction-sections -fdata-sections -fPIC -m64" > "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections > -fdata-sections -fPIC -m64" "-DCMAKE_CXX_COMPILER=c++" "-DCMAKE_ASM_FLAGS= > -ffunction-sections -fdata-sections -fPIC -m64" > "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=Release" > > <...> Ага. Примерно это в таких случаях и стоит указать в спеке (сократив пасту) или в git-истории (процитировав пасту хотя бы частично). Важно, что здесь нет какого-то единственно правильного формализма; главное, чтобы читатель понял. :) Больше к onefetch вопросов у меня нет.
(In reply to Arseny Maslennikov from comment #21) > В общем: > - жду ответов на вопросы; > - хочу увидеть хотя бы 1 собранный не-noarch пакет на базе традиционных > кросс-языковых систем управления проектом (meson/cmake/autotools); например, > https://github.com/wolfpld/tracy был бы не самым бесполезным пакетом; > - как уже писал выше, хочу увидеть обновление какого-нибудь пакета на > rust-cargo, раз уж вам интересны пакеты на rust. :) Всё это я увидел. По моей оценке, Владислав научился собирать и начал успешно сопровождать пакеты различного рода, не допуская серьёзных ошибок, и был конструктивен в командном общении. Считаю его достойным пополнить ряды ALT Linux Team.
(Ответ для Arseny Maslennikov на комментарий #40) > Всё это я увидел. > > По моей оценке, Владислав научился собирать и начал успешно сопровождать > пакеты различного рода, не допуская серьёзных ошибок, и был конструктивен в > командном общении. Считаю его достойным пополнить ряды ALT Linux Team. Спасибо :)
