Псевдоним: qwetwe E-mail: qwetwe@basealt.ru Ментор: Станислав Левин (slev@altlinux.org) Моя цель: Научиться собирать пакеты. Освоить git.alt.
Created attachment 8571 [details] Публичная часть SSH-ключа
Created attachment 8572 [details] Публичная часть GPG-ключа
Спасибо. Ментор не против.
(In reply to Ivan Alekseev from comment #1) > Created attachment 8571 [details] > Публичная часть SSH-ключа Ok. (In reply to Ivan Alekseev from comment #2) > Created attachment 8572 [details] > Публичная часть GPG-ключа Ok.
ssh ключ на gitery.alt зарегистрирован. ssh ключ на gyle.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 3.0.
Испытуемый готов перейти к этапу 3.
Пакет alt-gpgkeys обновлён. T/J/S -> 3.5.
gpg ключ протух 2021-02-02, нельзя ли добавить проверку на валидность при регистрации ключа?
(In reply to Stanislav Levin from comment #8) > gpg ключ протух 2021-02-02, нельзя ли добавить проверку на валидность при > регистрации ключа? Прецедентов с новыми ключами не было. Стоит добавить, да.
Прошу прощения за неудобства. Сгенерировал новый ключ, на этот раз бессрочный.
Created attachment 10153 [details] Публичная часть GPG-ключа
(In reply to Ivan Alekseev from comment #11) > Created attachment 10153 [details] > Публичная часть GPG-ключа Мне кажется, что проще продлить старый ключ. Новый нужно запушить на git.alt как описано в https://www.altlinux.org/Работа_с_ключами_разработчика#Обновление_существующего_GPG-ключа_в_пакете_alt-gpgkeys gpg: key 34283EF51C1FC29B was created 7170 seconds in the future (time warp or clock problem) Проверьте часы, пожалуйста.
(Ответ для Gleb F-Malinovskiy на комментарий #12) > (In reply to Ivan Alekseev from comment #11) > > Created attachment 10153 [details] [подробности] [details] > > Публичная часть GPG-ключа > > Мне кажется, что проще продлить старый ключ. Продлил старый ключ, запушил в приватный репозиторий на git.alt.
Открыл заявку на компонент alt-gpgkeys: https://bugzilla.altlinux.org/41754
На текущий момент собрано 13 проектов: dlib freeipa-healthcheck (p9/p10/sisyphus) freeipmi (обновлено: p10/sisyphus) howdy kms-cmake-utils kms-jsoncpp kms-jsonrpc kurento-module-creator pastel python3-module-bowler (sisyphus) python3-module-fissix (sisyphus) python3-module-moreorless (sisyphus) spotify-tui (p10/sisyphus)
Фактически собранные пакеты: - local-only (но текущая версия не проверялась ментором): dlib howdy Почему не запушено в репозиторий: howdy зависит от python-pam, который в свою очередь все еще не поддерживает Python3 и не может быть отправлен в сизиф. See https://sourceforge.net/p/pam-python/tickets/5/ - отправленные в сизиф: freeipa-healthcheck freeipmi (обновление) python3-module-bowler python3-module-fissix python3-module-moreorless spotify-tui shfmt Пакеты, отправленные в сизиф, достаточно простые, исполняли тренировочную роль, но в то же самое время полезные для пользователей. Думаю, что кандидат готов перейти на следующий этап.
Можно, пожалуйста, узнать имя рецензента?
Я не нашёл рецензента и решил, что я и сам подойду. Общие замечания: * .gear/rules: tar.gz: ... нет никакого смысла сжимать исходники потому что промежуточный временный tarball (который генерирует gear для того, чтобы передать hasher-у) сжимается zstd, а src.rpm сжимается xz, т.е. происходит ненужное двойное сжатие, которое влияет и на скорость работы и на степень сжатия. * Макросы типа %__ являются внутренними для rpm, потому и имеют такой префикс. Гораздо проще запустить нужную программу, чем использовать внутренние макросы для выяснения её названия, которое и так известно. * У вас во многих пакетах есть файлы я new blank line at EOF. (совет) Посмотрите на pre-commit hook, который идёт прямо в комплекте с git, он сообщает о таких ошибках (а заодно ещё и о некоторых других). Я сделал у себя так, чтобы он включался во всех моих git-репозиториях. * (мысли вслух) Мне кажется, у нас принято в первых сборках пакета писать в %changelog что-то о том, что это initial build, это настолько привычно, что когда этого не видишь, удивляешься, хотя возможно вы просто не сразу начали это делать. :) * (мысли вслух) Лично мне не нравится практика складывания абсолютно всех файлов, связанных со сборкой пакета (включая spec) в каталог .gear/. Обычно, когда я собираю пакет из апстримного git-а, я кладу и spec и все дополнительные файлы в каталог alt/. dlib * У коммита 00d7b1e8 автором значится Стас, а коммитером вы, скорее всего он видоизменялся в процессе. Сам коммит разбандливает только pybind11, хотя в commit-message написано, что разбандливается гораздо больше всего. * В spec-файле есть такой фрагмент: # cpp.req unconditionally adds /usr/include/dlib to the include path, # dlib doesn't support that %add_findreq_skiplist %_includedir/dlib/* Возможно, вы решили, что ошибки, которые генерирует cpp.req страшнее, чем они есть, но на самом деле это просто информационные сообщения. Действительно, получается, что cpp.req не может найти в этих хедерах никаких зависимостей, но при этом выводит очень много текста. Во-первых, это экономия на спичках. Во-вторых, если мы точно знаем, что cpp.req ничего не найдёт и точно хотим сэкономить на спичках, то, возможно, лучше явно выключить именно этот генератор зависимостей (AutoReq: nocpp). * %python3_build_debug ... --compiler-flags "-O2 -g" зачем передавать эти флаги, если они уже есть в optflags и %python3_build_debug должен их экспортировать правильным образом? Если же нет, то использовать в качестве флагов нужно как раз %optflags. * License: BSL and PDDL Я сходу не нашёл, где там PDDL. howdy * BuildArch: x86_64 Это не будет работать на архитектурах отличных от x86_64 потому что там нельзя собрать пакет под x86_64. Для ограничения списка архитектур нужно использовать ExclusiveArch: или ExcludeArch: в зависимости от задачи. Совсем хорошо будет, если вы возле этого ограничения напишите, чем оно обусловлено. * .gear/rules copy: fedora/com.github.boltgolt.howdy.policy Зачем копировать файл, который и так является частью апстримных исходников? spotify-tui * (мысли вслух) В update-vendored-sources.sh я бы добавил в начало toplevel="$(git rev-parse --show-toplevel)" cd "$toplevel/alt" Меня немного пугают скрипты, которые неизвестно где делают rm -rf. Кстати, инструкция "sh update-vendored-sources.sh" делает почти бесполезным shebang (в котором, кстати, написано bash) в начале скрипта. * Зависимость BuildRequires: на /proc больше не нужна поскольку она с какого-то момента есть у пакета rust. shfmt * (мысли вслух) В пакете spotify-tui update-vendored-sources.sh получился лучше потому что в этой ситуации mv -f vendor/ alt/ mv откажется заменять каталог alt/vendor если он не пустой. Хорошая работа, я считаю, что кандидат готов к самостоятельной работе в Team.
(Ответ для Gleb F-Malinovskiy на комментарий #18) Глеб, большое спасибо за рецензию, замечания приму к сведению.
Адрес подписан на devel@. Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства!
