Bug 47537

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, конечно, если уж зашла речь об идиомах.