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.

Спасибо :)

(каким-то образом эта заявка была забыта и не обработана, прошу прощения)

Пользователь добавлен в группу мейнтейнеров.

Желаю удачного мейнтейнерства!