Created attachment 14395 [details] ssh_public_key Псевдоним (имя пользователя): gerben Почта для перессылки: rastegind@gmail.com Намерения: хочу научиться собирать пакеты Имя ментора: dutyrok Подписка: dutyrok@altlinux.org
Created attachment 14396 [details] gpg_public_key
Created attachment 14422 [details] gpg_public_key Решил использовать подключ.
Created attachment 14423 [details] gpg_public_key
Created attachment 14424 [details] gpg_public
(Ответ для rastyoginds на комментарий #0) > Создано вложение 14395 [details] [подробности] > ssh_public_key > > Псевдоним (имя пользователя): gerben > Почта для перессылки: rastegind@gmail.com > Намерения: хочу научиться собирать пакеты > Имя ментора: dutyrok > > Подписка: dutyrok@altlinux.org Согласен быть ментором
Ментор есть, ключи в порядке. T/J/S -> 1.3.
Кандидат готов к следующему этапу T/J/M -> 2.0
ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3.
На данный момент собран: yyjson - https://git.altlinux.org/people/gerben/packages/?p=libyyjson.git;a=summary
Прошу кандидату дать доступ к сборочнице. T/J/M -> 3.0
ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. Адрес подписан на devel@. T/J/S -> 3.6.
В процессе вступления были собраны: gpg-tui - https://packages.altlinux.org/ru/tasks/349963/ libyyjson - https://packages.altlinux.org/ru/tasks/345401/ python3-module-yyjson - https://packages.altlinux.org/ru/tasks/345401/
Думаю кандидат готов к независимой оценке. Пора звать рецензента.
Призван рецензент (arseny@) для независимой оценки готовности кандидата. T/J/S -> 4.2.
(In reply to Gleb F-Malinovskiy from comment #14) > Призван рецензент (arseny@) для независимой оценки готовности кандидата. > > T/J/S -> 4.2. ACK.
(In reply to rastyoginds from comment #12) > В процессе вступления были собраны: > libyyjson - https://packages.altlinux.org/ru/tasks/345401/ > python3-module-yyjson - https://packages.altlinux.org/ru/tasks/345401/ Здравствуйте, Денис! Пакет libyyjson мне прямо понравился, упакован очень методично и бережно. В частности, докопаться не до чего. :) Впрочем, видимо, сами исходники не очень портили мейнтейнеру нервы (иначе "шрамы боевого опыта" остаются в спеке). Библиотека сразу упакована правильно. К питоньему модулю тоже вопросов не имею, URL и VCS расставлены с умом, pyproject_installer всё сделал. Я хотел бы ещё увидеть, как вы планируете обновлять такие пакеты в сизифе (вышла как минимум новая версия libyyjson). (In reply to rastyoginds from comment #12) > В процессе вступления были собраны: > gpg-tui - https://packages.altlinux.org/ru/tasks/349963/ Это немного позже.
(Ответ для Arseny Maslennikov на комментарий #16) > Я хотел бы ещё увидеть, как вы планируете обновлять такие пакеты в сизифе > (вышла как минимум новая версия libyyjson). Добрый день, Арсений! Спасибо за рецензию, пакеты обновил https://packages.altlinux.org/ru/tasks/362819/
(In reply to Denis Rastyogin from comment #17) > (Ответ для Arseny Maslennikov на комментарий #16) > > Я хотел бы ещё увидеть, как вы планируете обновлять такие пакеты в сизифе > > (вышла как минимум новая версия libyyjson). > > Добрый день, Арсений! Спасибо за рецензию, пакеты обновил > https://packages.altlinux.org/ru/tasks/362819/ Увидел. Неплохо! Питоний модуль даже успел обновиться дважды. :) Вопрос _к кандидату_: если вам вдруг потребуется изменить/улучшить исходники упакованных libyyjson или python3-module-py_yyjson (чего вам пока не приходилось) и упаковать результат, как вы это будете делать?
(Ответ для Arseny Maslennikov на комментарий #18) > Вопрос _к кандидату_: если вам вдруг потребуется изменить/улучшить исходники > упакованных libyyjson или python3-module-py_yyjson (чего вам пока не > приходилось) и упаковать результат, как вы это будете делать? У меня был небольшой опыт при сборке данного пакета https://git.altlinux.org/people/gerben/packages/?p=python3-module-fastapi-template.git;a=summary . С этими же пакетами я поступил бы также, добавил и применил патч.
(In reply to Denis Rastyogin from comment #19) > (Ответ для Arseny Maslennikov на комментарий #18) > > Вопрос _к кандидату_: если вам вдруг потребуется изменить/улучшить исходники > > упакованных libyyjson или python3-module-py_yyjson (чего вам пока не > > приходилось) и упаковать результат, как вы это будете делать? > > У меня был небольшой опыт при сборке данного пакета > https://git.altlinux.org/people/gerben/packages/?p=python3-module-fastapi- > template.git;a=summary . Да, так можно. :) Пойду читать gpg-tui на rust+cargo.
(In reply to Denis Rastyogin from comment #19) > (Ответ для Arseny Maslennikov на комментарий #18) > > Вопрос _к кандидату_: если вам вдруг потребуется изменить/улучшить исходники > > упакованных libyyjson или python3-module-py_yyjson (чего вам пока не > > приходилось) и упаковать результат, как вы это будете делать? > > У меня был небольшой опыт при сборке данного пакета > https://git.altlinux.org/people/gerben/packages/?p=python3-module-fastapi- > template.git;a=summary . С этими же пакетами я поступил бы также, добавил и > применил патч. Ооо. Попалось на глаза: https://git.altlinux.org/people/gerben/packages/?p=python3-module-fastapi-template.git;a=blob;f=.gear/instead_of_pytests.sh;h=d5cad27c8a986bebf3c1c7d44e72c769f7c15078;hb=982aa4c91056009949ee20c0452aafc62ecbbabb Вот ещё хороший вопрос. Зачем, по-вашему, здесь /bin/bash в hashbang? Есть же /bin/sh.
(Ответ для Arseny Maslennikov на комментарий #21) > Ооо. Попалось на глаза: > https://git.altlinux.org/people/gerben/packages/?p=python3-module-fastapi- > template.git;a=blob;f=.gear/instead_of_pytests.sh; > h=d5cad27c8a986bebf3c1c7d44e72c769f7c15078; > hb=982aa4c91056009949ee20c0452aafc62ecbbabb > > Вот ещё хороший вопрос. > Зачем, по-вашему, здесь /bin/bash в hashbang? Есть же /bin/sh. Если скрипт строго POSIX-совместим, тогда нужно использовать /bin/sh. Однако так как это пользовательский тест, то можно использовать более функциональный /bin/bash. Конкретно в этом случае не имеет особого значения, что использовать.
(In reply to Denis Rastyogin from comment #22) > Если скрипт строго POSIX-совместим, тогда нужно использовать /bin/sh. Для кода, который предполагает использование только в Альте можно считать, что /bin/sh это такой bash --posix и без libreadline. А зачем вообще тестирование из нескольких строк выносить в отдельный файл? Мне кажется, этот же код нормально смотрелся прямо в секции %check.
(Ответ для Gleb F-Malinovskiy на комментарий #23) > А зачем вообще тестирование из нескольких строк выносить в отдельный файл? > Мне кажется, этот же код нормально смотрелся прямо в секции %check. Мне показалось, что так будет лучше, с точки зрения читабельности spec файла. Да и в какой-то момент тесты могут вырасти с нескольких строчек, поэтому решил сделать небольшой задел на будущее)
(In reply to Denis Rastyogin from comment #22) > (Ответ для Arseny Maslennikov на комментарий #21) > > Ооо. Попалось на глаза: > > https://git.altlinux.org/people/gerben/packages/?p=python3-module-fastapi- > > template.git;a=blob;f=.gear/instead_of_pytests.sh; > > h=d5cad27c8a986bebf3c1c7d44e72c769f7c15078; > > hb=982aa4c91056009949ee20c0452aafc62ecbbabb > > > > Вот ещё хороший вопрос. > > Зачем, по-вашему, здесь /bin/bash в hashbang? Есть же /bin/sh. > > Если скрипт строго POSIX-совместим, тогда нужно использовать /bin/sh. Однако, > так как это пользовательский тест, А что значит "пользовательский тест"? Тест, наверное, в том смысле, что исполняется в %check с целью как-то протестировать собранное. А что есть "пользовательский"? > то можно использовать более > функциональный /bin/bash. Конкретно в этом случае не имеет особого значения, > что использовать. А раз не имеет значения, то отсюда и из реплики Глеба, как я понимаю, вытекает, что /bin/bash использовать можно, но незачем => не нужно. Более того, даже если в Альте бы поддерживались non-bash реализации sh, они бы все (busybox ash, dash) справились с вашим скриптом. Да и просто многие отличительные башизмы в исходном тексте скриптов труднее использовать правильно, чем функциональность, которая есть и в /bin/sh. Если же позарез потребуются вещи вроде <()-подстановки, к bash можно и вернуться, написав в видном месте, почему. [Написал и после этого проверил; у нас sh, он же sh5, точно умеет <(). Ну, значит, что-нибудь ещё действительно безобидное. А, и <() в хешернице потребует наличия там /proc. :)] В общем, пока что неубедительно; я б предложил далее так не делать, но мчаться срочно исправлять bash на sh тоже смысла нет, такие вещи можно поменять во время следующего обновления. :)
(In reply to Denis Rastyogin from comment #22) > (Ответ для Arseny Maslennikov на комментарий #21) > > Ооо. Попалось на глаза: > > https://git.altlinux.org/people/gerben/packages/?p=python3-module-fastapi- > > template.git;a=blob;f=.gear/instead_of_pytests.sh; > > h=d5cad27c8a986bebf3c1c7d44e72c769f7c15078; > > hb=982aa4c91056009949ee20c0452aafc62ecbbabb > > > > Вот ещё хороший вопрос. > > Зачем, по-вашему, здесь /bin/bash в hashbang? Есть же /bin/sh. > > Если скрипт строго POSIX-совместим, тогда нужно использовать /bin/sh. Однако > так как это пользовательский тест, то можно использовать более > функциональный /bin/bash. Конкретно в этом случае не имеет особого значения, > что использовать. Также, по мотивам: — начать скрипт с `set -e` — хорошая идея; `set -eu` ещё лучше; — `if [ ! -e $item ];`: конкретно тут никаких проблем, но лучше вогнать в привычку брать подстановки в "", чтобы не забыть это сделать там, где подстанавливаются данные внешней природы и возможно появление в команде новых слов после word split. На следующей строке, например, всё хорошо. То же самое справедливо и для .gear/vendor-modules.sh в gpg-tui. Вот любопытный этюд, рекомендую его как-нибудь запустить и посмотреть, что он выведет. :) sh -ex <<'__EOS' D="$(mktemp -d)"; trap "rm -rf $D" 0 1 2 3 6 9 15; cd "$D" bash -ec 'echo [INFO]: Add, update modules' touch N: bash -ec 'echo [INFO]: Add, update modules' touch F: bash -ec 'echo [INFO]: Add, update modules' __EOS BTW, для больших и/или многоразовых программ на шелле есть неплохая идиома: fatal() { printf '%s: %s\n' "$0" "$*" exit 1 } Тогда потом можно писать: [ -e "$item" ] || fatal "$item is missing." Возможны варианты по вкусу, конечно.
(In reply to Denis Rastyogin from comment #12) > В процессе вступления были собраны: > gpg-tui - https://packages.altlinux.org/ru/tasks/349963/ https://git.altlinux.org/tasks/archive/done/_341/349963/gears/300/git?p=git;a=blob;f=.gear/gpg-tui.spec;h=780ae8f9cbda3716bbb77730e3e66c93d14c886f;hb=314e887a72cd73c4c059bd0ed0ca3f5243e19ccc Спек годится. cargo и rustc настроены, актуальные флаги туда переданы, других грубых ошибок imho нет. А вот завендоренные исходники: vendor/winapi-i686-pc-windows-gnu/lib/libwinapi_activeds.a [new file with mode: 0644] blob vendor/winapi-i686-pc-windows-gnu/lib/libwinapi_advapi32.a [new file with mode: 0644] blob vendor/winapi-i686-pc-windows-gnu/lib/libwinapi_advpack.a [new file with mode: 0644] blob vendor/winapi-i686-pc-windows-gnu/lib/libwinapi_amsi.a [new file with mode: 0644] blob vendor/winapi-i686-pc-windows-gnu/lib/libwinapi_api-ms-win-net-isolation-l1-1-0.a [new file with mode: 0644] blob .gear/vendor-modules.sh содержит вызов команды `find`, где из поддерева `vendor/` будто предполагается удалить `*.a` в т. ч., а в коммите e21814d5bcc7f82e4d6b360d96cce326d9bc75f9 вот такое выше. Это как? Nits: Ман-страницы указаны в расчёте на то, что кто-нибудь их перед упаковкой в rpm сожмёт (smth.1.*). Интересно, почему так? (это не экзамен, на этот вопрос нет разумных неправильных ответов, хочу логику мышления увидеть)
(In reply to Arseny Maslennikov from comment #26) > BTW, для больших и/или многоразовых программ на шелле есть неплохая идиома: > fatal() { > printf '%s: %s\n' "$0" "$*" > exit 1 > } printf >&2, конечно, если уж зашла речь об идиомах.
(Ответ для Arseny Maslennikov на комментарий #25) Спасибо за подробную резензию, из неё я продчеркнул несколько моментов, о которых раньше не задумывался) > А что значит "пользовательский тест"? > Тест, наверное, в том смысле, что исполняется в %check с целью как-то > протестировать собранное. А что есть "пользовательский"? Под пользовательским имелось ввиду то что это вроде проверки "для себя", чтобы убедиться, что собранный пакет работает в сборочной среде. То есть это не часть общепринятого стандарта тестирования, а что-то кастомное, написанное под конкретный случай, из-за невозможности применить тесты из upstream. Я учту предложенные изменения при следующем обновлении пакета, спасибо!
(Ответ для Arseny Maslennikov на комментарий #27) > .gear/vendor-modules.sh содержит вызов команды `find`, где из поддерева > `vendor/` будто предполагается удалить `*.a` в т. ч., а в коммите > e21814d5bcc7f82e4d6b360d96cce326d9bc75f9 вот такое выше. Это как? С завендоренными исходниками действительно произошел небольшой косяк. Сначала появились vendors, а затем добавился скрипт для автоматизации. Только на этапе работы со скриптом я обратил внимание на файлы вроде vendor/winapi-i686-pc-windows-gnu/lib/libwinapi_activeds.a [новый файл с правами 0644] итд. В общем, скрипт не успел отработать до создания коммита) > Nits: > Ман-страницы указаны в расчёте на то, что кто-нибудь их перед упаковкой в > rpm сожмёт (smth.1.*). Интересно, почему так? (это не экзамен, на этот > вопрос нет разумных неправильных ответов, хочу логику мышления увидеть) В пакете rpm-build есть scripts/brp-compress.in:88: @RPMCONFIGDIR@/compress_files "$f", (https://git.altlinux.org/gears/r/rpm-build.git?p=rpm-build.git;a=blob;f=scripts/brp-compress.in;h=3e165adddfb7e5e0e65cbfe51094675049391ee2;hb=6496f05484ea73b4e97f32b376b4f03f56c3c5cf#:~:text=88-,%40RPMCONFIGDIR%40,-/compress_files%C2%A0%22%24f%22) Думаю, именно из-за этого происходит автоматическое сжатие man-страниц перед упаковкой в RPM.
