Created attachment 10997 [details] ssh_public_key Псевдоним (имя пользователя): dutyrok Почта для перессылки: shashkin.aleksander2016@yandex.ru Намерения: хочу научиться собирать пакеты Имя ментора: ancieg Подписка: ancieg@altlinux.org
Created attachment 10998 [details] gpg public key
Created attachment 11007 [details] gpg_public_key Решил использовать подключ.
(Ответ для Alexandr Shashkin на комментарий #0) > Создано вложение 10997 [details] [подробности] > ssh_public_key > > Псевдоним (имя пользователя): dutyrok > Почта для перессылки: shashkin.aleksander2016@yandex.ru > Намерения: хочу научиться собирать пакеты > Имя ментора: ancieg > > Подписка: ancieg@altlinux.org Согласен быть ментором.
Ключи выглядят ОК.
Кандидат готов к переходу на следующий этап.
(Ответ для Alexandr Shashkin на комментарий #0) > Намерения: хочу научиться собирать пакеты Кандидат планирует собрать следующие пакеты: * cgit * bit * python3-module-fastapi
ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3.
(Ответ для Anton Zhukharev на комментарий #6) > (Ответ для Alexandr Shashkin на комментарий #0) > > Намерения: хочу научиться собирать пакеты > Кандидат планирует собрать следующие пакеты: > * cgit > * bit > * python3-module-fastapi Кандидату также понадобилось собрать: python3-module-clickhouse-sqlalchemy (https://pypi.org/project/clickhouse-sqlalchemy/)
На данный момент собраны: clickhouse-sqlalchemy - https://git.altlinux.org/people/dutyrok/packages/?p=python3-module-clickhouse-sqlalchemy.git;a=summary fastapi - https://git.altlinux.org/people/dutyrok/packages/?p=python3-module-fastapi.git;a=summary
(Ответ для Alexandr Shashkin на комментарий #9) > На данный момент собраны: > clickhouse-sqlalchemy - > https://git.altlinux.org/people/dutyrok/packages/?p=python3-module- > clickhouse-sqlalchemy.git;a=summary > fastapi - > https://git.altlinux.org/people/dutyrok/packages/?p=python3-module-fastapi. > git;a=summary Извините, я не увидел python3-module-fastapi в репозитории сизифа. Если оно действительно собирается, то запускайте задание, не тяните. Мне он нужен.
(Ответ для Grigory Ustinov на комментарий #10) > (Ответ для Alexandr Shashkin на комментарий #9) > > На данный момент собраны: > > clickhouse-sqlalchemy - > > https://git.altlinux.org/people/dutyrok/packages/?p=python3-module- > > clickhouse-sqlalchemy.git;a=summary > > fastapi - > > https://git.altlinux.org/people/dutyrok/packages/?p=python3-module-fastapi. > > git;a=summary > > Извините, я не увидел python3-module-fastapi в репозитории сизифа. Если оно > действительно собирается, то запускайте задание, не тяните. Мне он нужен. Собирается. Как раз таки кандидат ещё планировал собрать pydantic, однако он уже попал в репозиторий. Если кандидат не против, то можно собрать (справедливости ради потом передать пакет под лидерство вступающего после вступления).
> Если кандидат не против, то можно собрать (справедливости ради потом передать > пакет под лидерство вступающего после вступления). Я не против такого варианта развития событий. Пусть тогда Антон Жухарев соберет его в Сизиф.
(Ответ для Alexandr Shashkin на комментарий #12) > > Если кандидат не против, то можно собрать (справедливости ради потом передать > > пакет под лидерство вступающего после вступления). > > Я не против такого варианта развития событий. Пусть тогда Антон Жухарев > соберет его в Сизиф. https://git.altlinux.org/tasks/307049/
(Ответ для Anton Zhukharev на комментарий #13) > (Ответ для Alexandr Shashkin на комментарий #12) > > > Если кандидат не против, то можно собрать (справедливости ради потом передать > > > пакет под лидерство вступающего после вступления). > > > > Я не против такого варианта развития событий. Пусть тогда Антон Жухарев > > соберет его в Сизиф. > https://git.altlinux.org/tasks/307049/ Спасибо!
Собран пакет bit - https://git.altlinux.org/people/dutyrok/packages/?p=bit.git;a=summary Из заявленного ранее осталось собрать cgit.
(Ответ для Alexandr Shashkin на комментарий #15) > Из заявленного ранее осталось собрать cgit. На данный момент собран пакет daemon, cgit будет собран кандидатом несколько позже после сборки необходимых Lua-модулей. Прошу кандидату дать доступ к сборочнице.
ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.5.
Cgit собран - https://git.altlinux.org/people/dutyrok/packages/?p=cgit.git;a=summary Для него потребовалось собрать два дополнительных пакета: lua5.3-module-luaposix - https://git.altlinux.org/people/dutyrok/packages/?p=lua5.3-module-luaposix.git;a=summary lua5.3-module-luaossl - https://git.altlinux.org/people/dutyrok/packages/?p=lua5.3-module-luaossl.git;a=summary
В процессе вступления были собраны еще некоторые пакеты. Вот сборочные задания на все пакеты: cgit и lua5.3-module-luaposix - https://packages.altlinux.org/ru/tasks/317060/ bit (p10) - https://packages.altlinux.org/ru/tasks/317901/ bit (sisyphus) - https://packages.altlinux.org/ru/tasks/315696/ lua5.3-module-luaossl - https://packages.altlinux.org/ru/tasks/317807/ lua5.3-module-luaunit и lua5.3-module-openssl - https://packages.altlinux.org/ru/tasks/316966/ python3-module-flask-httpauth - https://packages.altlinux.org/ru/tasks/316905/ go-callvis - https://packages.altlinux.org/ru/tasks/316843/ python3-module-clickhouse-sqlalchemy - https://packages.altlinux.org/ru/tasks/315695/ daemon - https://packages.altlinux.org/ru/tasks/315675/
Пора звать рецензента.
(Ответ для Alexandr Shashkin на комментарий #19) > В процессе вступления были собраны еще некоторые пакеты. Eще собрал sniffnet: p10 - https://packages.altlinux.org/ru/tasks/318211/ sisyphus - https://packages.altlinux.org/ru/tasks/318207/
Обновил fastapi до последней (на данный момент) версии 0.95.1: https://packages.altlinux.org/ru/sisyphus/srpms/python3-module-fastapi/. Пришлось отключить прохождение одного теста, связанного с python3-module-databases, так как python3-module-databases поломался из-за слишком нового python3-module-sqlalchemy (2.0.12-alt1, databases не умеет с ним работать), и по этой причине тест падал.
Призван рецензент (slev@) для независимой оценки готовности кандидата. T/J/S -> 4.2.
lua5.3-module-luaposix: - пакет висит в FTBFS 2 месяца, нужно разобраться с причиной ошибки и постараться исправить (если возможно) - странно, что собирается из коммита d851eaf8d57d76ea51bc00b850d1067cf5221181, хотя сегодня v36.1 - это другой коммит (3381f2983846865d0bb4d188bbac826a1d27ea56). Но, возможно, автор форспушнул. Поэтому в более свежей версии rockspec можно уже не прикладывать, а использовать авторский. - LICENSE можно не упаковывать в этом пакете: https://www.altlinux.org/Spec#License
(Ответ для Stanislav Levin на комментарий #24) > - LICENSE можно не упаковывать в этом пакете: > https://www.altlinux.org/Spec#License Сегодня в другой баге уже обсуждали. В тексте MIT сказано буквально следующее: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. Указание лицензии MIT в спеке не является копией самого текста "permission notice". Лицензии обычно требуют прикладывать текст лицензии к распространяемому коду или его бинарному представлению. Там не сказано, что если у вас есть каталог с лицензиями, то можете не прикладывать. Предлагаю исправить статью, чтобы не вводить новичков и некоторых старичков в заблуждение.
cgit: - переложите фильтры из %_target_libdir_noarch/%name в %_libexecdir/%name/filters - конфигурационные файлы не помечены как конфиги, так и задумано? если нет, то можно почитать тут https://www.cl.cam.ac.uk/~jw35/docs/rpm_config.html - почему упакован образец cgitrc.example, а не действительный rc конфиг cgitrc? - в чем смысл выделять конфиг апача для "web frontend for git repositories" в отдельный подпакет? - почему используется lua 5.1 для сборки, а не lua 5.3 или luajit?
В тексте лицензии MIT использована формулировка "shall be included", что открывает возможность ещё одного варианта: запаковать ссылку на файл с текстом лицензии, тогда название лицензии будет видно, даже не открывая файл. Например, ln -s %_licensedir/MIT LICENSE %doc --no-dereference LICENSE
lua5.3-module-luaossl: - пакет находится в FTBFS (желательно поправить) - https://www.altlinux.org/Spec#Summary > В конце Summary не должно быть точки. Могу порекомендовать использовать cleanup_spec из rpm-utils. - неизвестен источник rockspec было бы неплохо указывать откуда был взят rockspec, например, https://luarocks.org/manifests/daurnimator/luaossl-20220711-0.rockspec Таким образом вам или следующему сопровождающему будет понятно, куда надо идти за rockspec'ом.
lua5.3-module-luaossl: - delete duplicate provides that starts with dot inside brackets тут непонятно, почему lua5.3(_openssl) и lua5.3(openssl) - это одно и то же?
(In reply to Stanislav Levin from comment #29) > lua5.3-module-luaossl: > - delete duplicate provides that starts with dot inside brackets > тут непонятно, почему lua5.3(_openssl) и lua5.3(openssl) - это одно и то > же? опечатка: lua5.3(_openssl) => lua5.3(.openssl)
lua5.3-module-luaunit: - rm -rvf %luarocks_dbdir/%oname/%oversion/test забыли добавить %buildroot. Поэтому рекомендую не использовать -f в подобных сценариях.
lua5.3-module-openssl: - состояние submodule lua-compat не соответствует сконфигурированному, должно быть e00fd0a415694dc15687593e355441af6dfa30bd, фактическое состояние 8f8e4c6adb43e107f5902e784ef207dc3c8ca06b (today's master) Как вы делаете 'add submodules'? Вероятно, вы клонируете целевой репозиторий и тарите текущий коммит вместо положенного? Рекомендую зафиксировать эту процедуру в репозитории для упрощения последующих обновлений. - фактическая упакованная версия 0.8.2-1, оформленно как 0.8.2 https://www.altlinux.org/Spec#%D0%9F%D1%80%D0%BE%D0%BC%D0%B5%D0%B6%D1%83%D1%82%D0%BE%D1%87%D0%BD%D1%8B%D0%B5_upstream-%D1%80%D0%B5%D0%BB%D0%B8%D0%B7%D1%8B - такая же рекомендация по rockspec, как и для lua5.3-module-luaossl
python3-module-flask-httpauth: - не рекомендую добавлять в changelog несуществующие релизы в альте: например, 4.7.0-alt1 никогда не было в сизифе, в таком случае можно было сделать слияние с апстримным тегом и накатить 'Initial build for sisyphus'. - рекомендации по написанию changelog: https://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog то есть не рекомендуется указывать косметические изменения в spec файле, потому что они никому не интересны. - рекомендую не использовать глоббинг вида %python3_sitelibdir/* люди делают ошибки при упаковке (например, делают слияние с неправильным тэгом, забывают изменить версию проекта, генерируют некорректные основанные на SCM версии и тд) и такой глоббинг скрывает их. Рекомендую использовать следующее: %python3_sitelibdir/%{pyproject_distinfo %pypi_name} или %python3_sitelibdir/YOUR_PROJECT_NAME-%version.dist-info/ - нет необходимости делать provide вида: %py3_provides %pypi_name
go-callvis: - схема пакетирования. На этапе вступления очень важно, чтобы кандидат использовал одну из "общепринятых" схем пакетирования. В этом пакете вы тарите корень репозитория и отдельно накладываете патч. Такой схемы в gear-rules(5) нет. Пожалуйста, сделайте одним из указанных вариантов. - опечатка в тексте коммита 0.6.1.gita410f11-alt1 => 0.6.1-alt1.gita410f11 Можно использовать gear-commit из gear для генерации сообщения коммита из последней записи changelog. - добавляйте патчи отдельными коммитами с объяснением их необходимости. Вы закоммитили патч с сообщением 'add vendor for package', это не добавило ясносности зачем он нужен. Пришлось догадаться, что он выдернут из старого PR. - рекомендую фиксировать процедуру генерации бандла go модулей для облегчения последующего процесса обновления
python3-module-clickhouse-sqlalchemy: - нет необходимости в provide вида: %py3_provides %pypi_name - CONTRIBUTING.rst не файл документации пользователя - не рекомендую добавлять в changelog несуществующие релизы в альте: например, 0.2.2-alt1 никогда не было в сизифе, в таком случае можно было сделать слияние с апстримным тегом и накатить 'Initial build for sisyphus'. - рекомендации по написанию changelog: https://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog то есть не рекомендуется указывать косметические изменения в spec файле, потому что они никому не интересны (пример неинтересности, add %%py3_provides %%pypi_name) - текст коммита Например, 358717464c4c68510b352589bd61570a3ef4cfa8. Что можно понять из 'add %py3_provides %pypi_name'? Для чего это нужно?
> - рекомендую фиксировать процедуру генерации бандла go модулей для > облегчения последующего процесса обновления А что под этим подразумевается?
(In reply to Alexandr Shashkin from comment #36) > > - рекомендую фиксировать процедуру генерации бандла go модулей для > > облегчения последующего процесса обновления > > А что под этим подразумевается? То, как вы получаете go модули, например, в простейшем случае `go mod vendor`.
(Ответ для Stanislav Levin на комментарий #32) > lua5.3-module-openssl: > - фактическая упакованная версия 0.8.2-1, оформленно как 0.8.2 > > https://www.altlinux.org/ > Spec#%D0%9F%D1%80%D0%BE%D0%BC%D0%B5%D0%B6%D1%83%D1%82%D0%BE%D1%87%D0%BD%D1%8B > %D0%B5_upstream-%D1%80%D0%B5%D0%BB%D0%B8%D0%B7%D1%8B Если верить wiki luarocks https://github.com/luarocks/luarocks/wiki/Rockspec-format, то версия, указываемая в rockspec является версией пакета и суффиксом, который определяет ревизию этого самого rockspec. > version (string, mandatory field) - the version of the package, plus a suffix > indicating the revision of the rockspec. Example: "2.0.1-1" Если просматривать изменения (https://github.com/zhaozg/lua-openssl/releases), которые вносились между ревизиями спека, то видно, что они касаются только самого rockspec или связанных с ним файлов. Собственно поэтому я и указал версию 0.8.2 А вы, как я понял, предлагаете мне указать 0.8.2-alt1.1 (если я не прав, то поправьте). Но является ли моя упакованная версия ошибкой (согласно https://github.com/luarocks/luarocks/wiki/Rockspec-format)?
(Ответ для Stanislav Levin на комментарий #37) > (In reply to Alexandr Shashkin from comment #36) > > > - рекомендую фиксировать процедуру генерации бандла go модулей для > > > облегчения последующего процесса обновления > > > > А что под этим подразумевается? > > То, как вы получаете go модули, например, в простейшем случае `go mod > vendor`. Меня больше интересует слово "фиксировать": это создать где-нибудь в репозитории скрипт, или прям в сообщении к коммиту прописать команды, которые я сделал для получения модулей?
(In reply to Alexandr Shashkin from comment #38) > (Ответ для Stanislav Levin на комментарий #32) > > lua5.3-module-openssl: > > - фактическая упакованная версия 0.8.2-1, оформленно как 0.8.2 > > > > https://www.altlinux.org/ > > Spec#%D0%9F%D1%80%D0%BE%D0%BC%D0%B5%D0%B6%D1%83%D1%82%D0%BE%D1%87%D0%BD%D1%8B > > %D0%B5_upstream-%D1%80%D0%B5%D0%BB%D0%B8%D0%B7%D1%8B > > Если верить wiki luarocks > https://github.com/luarocks/luarocks/wiki/Rockspec-format, то версия, > указываемая в rockspec является версией пакета и суффиксом, который > определяет ревизию этого самого rockspec. > > version (string, mandatory field) - the version of the package, plus a suffix > > indicating the revision of the rockspec. Example: "2.0.1-1" > > Если просматривать изменения > (https://github.com/zhaozg/lua-openssl/releases), которые вносились между > ревизиями спека, то видно, что они касаются только самого rockspec или > связанных с ним файлов. > > Собственно поэтому я и указал версию 0.8.2 > А вы, как я понял, предлагаете мне указать 0.8.2-alt1.1 (если я не прав, то > поправьте). Но является ли моя упакованная версия ошибкой (согласно > https://github.com/luarocks/luarocks/wiki/Rockspec-format)? rockspec является частью проекта. Что вы будете делать при обновлении, например, 0.8.2 -> 0.8.2-0 -> 0.8.2-1 и тд?
(Ответ для Stanislav Levin на комментарий #40) > rockspec является частью проекта. > Что вы будете делать при обновлении, например, 0.8.2 -> 0.8.2-0 -> 0.8.2-1 и > тд? Ну тогда бы мне пришлось поднимать версию релиза (alt1->alt2). Что подобно alt1.1 -> alt1.2 . Только второе будет более ясно. Согласен, исправлю по вашей рекомендации.
(In reply to Alexandr Shashkin from comment #39) > (Ответ для Stanislav Levin на комментарий #37) > > (In reply to Alexandr Shashkin from comment #36) > > > > - рекомендую фиксировать процедуру генерации бандла go модулей для > > > > облегчения последующего процесса обновления > > > > > > А что под этим подразумевается? > > > > То, как вы получаете go модули, например, в простейшем случае `go mod > > vendor`. > > Меня больше интересует слово "фиксировать": это создать где-нибудь в > репозитории скрипт, или прям в сообщении к коммиту прописать команды, > которые я сделал для получения модулей? Это рекомендация, реализация за вами и может быть любой из перечисленных или иной (например, обычно прикладываю скриптик).
sniffnet: - почему было решено собирать пакет из src RPM? - лицензия Apache-2.0 MIT, поддерживаемые операторы в выражении лицензии: and, or, with. Так, upstream определяет свою лицензию как 'MIT OR Apache-2.0'. Можно посмотреть тут: https://lists.altlinux.org/pipermail/devel/2019-November/209050.html - ExcludeArch: i586 armh дан короткий комментарий '# out of memory', который не сильно проясняет проблему, можно подробнее? - имеет смысл показывать сообщение об использовании в %post? кто должен это прочитать? - как был получен бандл внешних зависимостей? Опять же, рекомендую задокументировать эту процедуру в репозитории тем или иным образом.
(Ответ для Stanislav Levin на комментарий #43) > sniffnet: > - почему было решено собирать пакет из src RPM? 1) Репозиторий с завендоренными зависимостями весит около 200 мб, поэтому чтобы не загружать в git.altlinux.org/people, где есть лимит, собрал через src.rpm 2) Ментор хотел, чтобы я в качестве обучения, попробовал собрать пакеты таким образом > - лицензия Apache-2.0 MIT, > поддерживаемые операторы в выражении лицензии: and, or, with. > Так, upstream определяет свою лицензию как 'MIT OR Apache-2.0'. > Можно посмотреть тут: > https://lists.altlinux.org/pipermail/devel/2019-November/209050.html Учту > - ExcludeArch: i586 armh > дан короткий комментарий '# out of memory', который не сильно проясняет > проблему, можно подробнее? По этой причине падала сборка на armh и i586 > - имеет смысл показывать сообщение об использовании в %post? кто должен > это прочитать? Тот, кто будет устанавливать. А как тогда лучше: положить README в doc каталог с указанием на эту команду? > - как был получен бандл внешних зависимостей? Опять же, рекомендую > задокументировать эту процедуру в репозитории тем или иным образом. Хорошо, создам скрипт
python3-module-fastapi: - пакет висит в FTBFS, желательно поправить - не включайте в changelog записи вида 'reformat description' или 'add Vcs tag' Эта информация имеет околонулевой смысл здесь. - разбивайте коммиты на минимально возможные логически независимые изменения. Например, коммит 522197b6dc3fe3838e35bf4afee15e2c155ab64c. Здесь намешано всё подряд, как понять, что сделано и для чего? - не хватает описания для патчей, почему же они нужны? Сообщали ли вы в upstream о возникших проблемах? - %add_pyproject_deps_check_filter ruff types- можно убрать с rpm-build-pyproject 0.0.4-alt1 - это лишнее BuildRequires: python3(python-multipart), вы уже имеете эту зависимость в requirements-tests.txt. - sedding можно заменить на опцию pytest, --deselect 'tests/test_tutorial/test_async_sql_databases/test_tutorial001.py::test_create_read' - -Werror, общепринято считать любой warning ошибкой при запуске тестов, но при пакетировании - это настоящая проблема(любой DeprecationWarning неоправданно сломает сборку), поэтому рекомендую игнорировать все warning при тестировании (апстрим может быть не готов к такому), сделать это можно через опцию pytest '-Wignore' - CONTRIBUTING.md и SECURITY.md - не файлы документации пользователя
(In reply to Alexandr Shashkin from comment #44) > (Ответ для Stanislav Levin на комментарий #43) > > sniffnet: > > - ExcludeArch: i586 armh > > дан короткий комментарий '# out of memory', который не сильно проясняет > > проблему, можно подробнее? > По этой причине падала сборка на armh и i586 А если бы сборка падала на x86_64? Если есть проблема, то с ней нужно постараться разобраться, хотя бы срепортить в апстрим. Есть ли тикет?
(In reply to Alexandr Shashkin from comment #44) > (Ответ для Stanislav Levin на комментарий #43) > > sniffnet: > > > - имеет смысл показывать сообщение об использовании в %post? кто должен > > это прочитать? > Тот, кто будет устанавливать. А как тогда лучше: положить README в doc > каталог с указанием на эту команду? > Об этом должны думать разработчики программы и сообщить пользователю о нехватке тех или иных capabilities для чего-то.
(Ответ для Stanislav Levin на комментарий #45) > python3-module-fastapi: > - пакет висит в FTBFS, желательно поправить В задании https://packages.altlinux.org/ru/tasks/324350/ в sisyphus прошел starlette 0.28.0 . Fastapi на него еще не переехал, поэтому часть функционала отвалилась (один конкретный тест). Так как upstream довольно часто производит обновления, я жду, когда они переедут на новый starlette. > - разбивайте коммиты на минимально возможные логически независимые > изменения. Например, коммит 522197b6dc3fe3838e35bf4afee15e2c155ab64c. > Здесь намешано всё подряд, как понять, что сделано и для чего? А можете пожалуйста уточнить, что значит "все подряд". Я вижу только обновление версии и переезд на новые макросы. Единственное, что можно было сделать, это переход на новые макросы отдельным коммитом, по-моему? > - не хватает описания для патчей, почему же они нужны? > Сообщали ли вы в upstream о возникших проблемах? Все патчи взяты из pull request в upstream. Он исправляют тесты. И тогда вопрос, а где разместить эти описания? > - %add_pyproject_deps_check_filter ruff types- > можно убрать с rpm-build-pyproject 0.0.4-alt1 Хорошо. > - sedding можно заменить на опцию pytest, > --deselect > 'tests/test_tutorial/test_async_sql_databases/test_tutorial001.py:: > test_create_read' Хорошо. > - это лишнее BuildRequires: python3(python-multipart), вы уже имеете эту > зависимость в requirements-tests.txt. Осталось со старых времен, когда еще сборка fastapi производилась по-другому. Учту. > - -Werror, общепринято считать любой warning ошибкой при запуске тестов, но > при пакетировании - это настоящая проблема(любой DeprecationWarning > неоправданно сломает сборку), поэтому рекомендую игнорировать все warning при > тестировании > (апстрим может быть не готов к такому), сделать это можно через опцию > pytest > '-Wignore' Хорошо. > - CONTRIBUTING.md и SECURITY.md - не файлы документации пользователя Хорошо.
(In reply to Alexandr Shashkin from comment #48) > (Ответ для Stanislav Levin на комментарий #45) > > python3-module-fastapi: > > - разбивайте коммиты на минимально возможные логически независимые > > изменения. Например, коммит 522197b6dc3fe3838e35bf4afee15e2c155ab64c. > > Здесь намешано всё подряд, как понять, что сделано и для чего? > А можете пожалуйста уточнить, что значит "все подряд". Я вижу только > обновление версии и переезд на новые макросы. Единственное, что можно было > сделать, это переход на новые макросы отдельным коммитом, по-моему? > Все подряд - это что-то больше одного. Если вам не понравилась формулировка, извините. В данном случае я бы выделил: - обновление версии - генерация зависимостей - замена tox
(In reply to Alexandr Shashkin from comment #48) > (Ответ для Stanislav Levin на комментарий #45) > > python3-module-fastapi: > > - не хватает описания для патчей, почему же они нужны? > > Сообщали ли вы в upstream о возникших проблемах? > Все патчи взяты из pull request в upstream. > Он исправляют тесты. И тогда вопрос, а где разместить эти описания? > Можно, например, сгенерировать патч-файл с помощью `git format-patch`. В тексте коммита, который добавит этот патч-файл, указать, что взято оттуда-то. Эту же информацию продублировать комментарием в спекфайле.
(In reply to Alexandr Shashkin from comment #44) > (Ответ для Stanislav Levin на комментарий #43) > > sniffnet: > > - почему было решено собирать пакет из src RPM? > 1) Репозиторий с завендоренными зависимостями весит около 200 мб, поэтому > чтобы не загружать в git.altlinux.org/people, где есть лимит, собрал через > src.rpm Репозиторий с завендоренными зависимостями весил 888МБ. (In reply to Stanislav Levin from comment #46) > (In reply to Alexandr Shashkin from comment #44) > > (Ответ для Stanislav Levin на комментарий #43) > > > sniffnet: > > > - ExcludeArch: i586 armh > > > дан короткий комментарий '# out of memory', который не сильно проясняет > > > проблему, можно подробнее? > > По этой причине падала сборка на armh и i586 > > А если бы сборка падала на x86_64? Если есть проблема, то с ней нужно > постараться разобраться, хотя бы срепортить в апстрим. Есть ли тикет? Проблема нехватки памяти на girar на 32-разрядных архитектурах при сборке жирного Rust-проекта - не проблема апстрима, а проблема girar. Не вижу смысла сообщать в апстрим об этом. Можно попробовать для armh и i586 уменьшить %__nprocs, что может уменьшить суммарное потребление памяти (однако, это не всегда помогает).
(In reply to Grigory Ustinov from comment #25) > (Ответ для Stanislav Levin на комментарий #24) > > - LICENSE можно не упаковывать в этом пакете: > > https://www.altlinux.org/Spec#License > > Сегодня в другой баге уже обсуждали. > > В тексте MIT сказано буквально следующее: > > The above copyright notice and this permission notice shall be included in > all copies or substantial portions of the Software. > > Указание лицензии MIT в спеке не является копией самого текста "permission > notice". > > Лицензии обычно требуют прикладывать текст лицензии к распространяемому коду > или его бинарному представлению. Там не сказано, что если у вас есть каталог > с лицензиями, то можете не прикладывать. Предлагаю исправить статью, чтобы > не вводить новичков и некоторых старичков в заблуждение. Также хочу обратить внимание, что в файле с лицензией (например в MIT, BSD и др.) можно встречать строки следующего вида: Copyright (C) 2006-2023 luaposix authors Такого в шаблонах лицензий в /usr/share/license/ нету и вопрос об неупаковке файла лицензии, лежащего в репозитории, на мой взгляд, не решён: или пакуем лицензию для каждого пакета с копирайтом или нужно придумать что ещё делать. Об это в https://www.altlinux.org/Spec#License нет ни слова.
(Ответ для Anton Zhukharev на комментарий #52) > Также хочу обратить внимание, что в файле с лицензией (например в MIT, BSD и > др.) > можно встречать строки следующего вида: > > Copyright (C) 2006-2023 luaposix authors > > Такого в шаблонах лицензий в /usr/share/license/ нету и вопрос об неупаковке > файла > лицензии, лежащего в репозитории, на мой взгляд, не решён: или пакуем > лицензию > для каждого пакета с копирайтом или нужно придумать что ещё делать. > Об это в https://www.altlinux.org/Spec#License нет ни слова. Именно! Я в личной беседе с slev@ писал абсолютно то же самое. Причём в случае MIT, насколько я понимаю, в этом и заключается её главный смысл: сохранить имя автора.
(In reply to Anton Zhukharev from comment #51) > (In reply to Alexandr Shashkin from comment #44) > > (Ответ для Stanislav Levin на комментарий #43) > > > sniffnet: > > > - почему было решено собирать пакет из src RPM? > > 1) Репозиторий с завендоренными зависимостями весит около 200 мб, поэтому > > чтобы не загружать в git.altlinux.org/people, где есть лимит, собрал через > > src.rpm > Репозиторий с завендоренными зависимостями весил 888МБ. > Столько занимает "распакованный" репозиторий, но данные хранятся не в сыром виде. Приблизительно, это 'size-pack: 225.84 MiB'.
Антон, вы кандидат на вступление?
(In reply to Stanislav Levin from comment #55) > Антон, вы кандидат на вступление? Нет.
(In reply to Anton Zhukharev from comment #51) > Проблема нехватки памяти на girar на 32-разрядных архитектурах при сборке > жирного Rust-проекта - не проблема апстрима, а проблема girar. В этом вопросе вы точно ошибаетесь, поскольку сборкам на x86 и x86_64 отводится одинаковый объём памяти. А вот размер адресного пространства различается.
(In reply to Dmitry V. Levin from comment #57) > (In reply to Anton Zhukharev from comment #51) > > Проблема нехватки памяти на girar на 32-разрядных архитектурах при сборке > > жирного Rust-проекта - не проблема апстрима, а проблема girar. > > В этом вопросе вы точно ошибаетесь, поскольку сборкам на x86 и x86_64 > отводится одинаковый объём памяти. А вот размер адресного пространства > различается. Очень надеюсь, что ошибаюсь, однако сам с таким сталкивался на armh и i586. Это связано с Racket, где для сборки пакетов используются т.н. "комнаты". Пример вот здесь: https://git.altlinux.org/tasks/archive/done/_301/308872/logs/events.5.1.log И на этих архитектурах при увеличении количества "комнат" я утыкался в нехватку памяти на сборочнице. Это, впрочем, вполне, могла быть проблема самого Racket. Хотя если указывать хэшеру --target=i586 на моей x86-64-системе, то памяти хватало. Как обстоят дела сейчас - сказать не могу - всю сборку Racket необходимо переделывать из-за ряда возникших проблем (как прямых, так и не совсем). Впрочем, это обсуждение, уже не для этого баг-репорта.
(Ответ для Stanislav Levin на комментарий #32) > lua5.3-module-openssl: > - состояние submodule lua-compat не соответствует сконфигурированному, > должно быть e00fd0a415694dc15687593e355441af6dfa30bd, фактическое > состояние 8f8e4c6adb43e107f5902e784ef207dc3c8ca06b (today's master) > > Как вы делаете 'add submodules'? Вероятно, вы клонируете > целевой репозиторий и тарите текущий коммит вместо положенного? > Рекомендую зафиксировать эту процедуру в репозитории для упрощения > последующих обновлений. > > - фактическая упакованная версия 0.8.2-1, оформленно как 0.8.2 > https://www.altlinux.org/Spec#%D0%9F%D1%80%D0%BE%D0%BC%D0%B5%D0%B6%D1%83 > %D1%82%D0%BE%D1%87%D0%BD%D1%8B%D0%B5_upstream-%D1%80%D0%B5%D0%BB%D0%B8%D0%B7%D1%8B > > - такая же рекомендация по rockspec, как и для lua5.3-module-luaossl Я внес указанные изменения. Но в выходные обновился openssl https://packages.altlinux.org/en/tasks/324359/. И в результате 3 теста зафэйлились (https://git.altlinux.org/tasks/324716/build/1000/x86_64/log). Я хотел проверить это с последней версией указанного пакета. Но для нее требуется новый luarocks, а обновить его корректно не получится, так как необходимо править пакет rpm-build-lua (который собрал Селезнев и закрыл на него acl). Милюков предложил соответствующие исправления в таске https://git.altlinux.org/tasks/315204/, но Селезнев пока ответа не дал). Как поступить в данной ситуации?
(Ответ для Alexandr Shashkin на комментарий #59) > Милюков предложил > соответствующие исправления в таске https://git.altlinux.org/tasks/315204/, > но Селезнев пока ответа не дал). Уточнение: Милюков писал письмо Селезневу по этому вопросу и ответа нет именно там.
(Ответ для Stanislav Levin на комментарий #26) > cgit: > - переложите фильтры из > %_target_libdir_noarch/%name в %_libexecdir/%name/filters > > - конфигурационные файлы не помечены как конфиги, так и задумано? > если нет, то можно почитать тут > https://www.cl.cam.ac.uk/~jw35/docs/rpm_config.html > > - почему упакован образец cgitrc.example, а не действительный rc конфиг > cgitrc? > > - почему используется lua 5.1 для сборки, а не lua 5.3 или luajit? Исправил и собрал таск https://packages.altlinux.org/ru/tasks/324756/ > - в чем смысл выделять конфиг апача для "web frontend for git repositories" > в отдельный подпакет? > В README cgit: https://git.zx2c4.com/cgit/tree/README предлагается настройка apache, но не сказано, что должен использоваться только он. Также на просторах интернета я находил статьи, как запустить cgit с другими веб серверами, поэтому и вынес в отдельный подпакет.
(Ответ для Stanislav Levin на комментарий #24) > lua5.3-module-luaposix: > - пакет висит в FTBFS 2 месяца, нужно разобраться с причиной ошибки и > постараться исправить (если возможно) > - странно, что собирается из коммита > d851eaf8d57d76ea51bc00b850d1067cf5221181, хотя сегодня v36.1 - это другой > коммит (3381f2983846865d0bb4d188bbac826a1d27ea56). Но, возможно, автор > форспушнул. Поэтому в более свежей версии rockspec можно уже не > прикладывать, а использовать авторский. > - LICENSE можно не упаковывать в этом пакете: > https://www.altlinux.org/Spec#License Исправления можно увидеть в таске https://packages.altlinux.org/ru/tasks/324892/
(Ответ для Stanislav Levin на комментарий #28) > lua5.3-module-luaossl: > - пакет находится в FTBFS (желательно поправить) Поправлено: https://packages.altlinux.org/ru/tasks/324892/ > - https://www.altlinux.org/Spec#Summary > > > В конце Summary не должно быть точки. > > Могу порекомендовать использовать cleanup_spec из rpm-utils. > > - неизвестен источник rockspec > было бы неплохо указывать откуда был взят rockspec, например, > https://luarocks.org/manifests/daurnimator/luaossl-20220711-0.rockspec > Таким образом вам или следующему сопровождающему будет понятно, куда надо > идти > за rockspec'ом. https://git.altlinux.org/people/dutyrok/packages/?p=lua5.3-module-luaossl.git;a=shortlog;h=refs/heads/sisyphus lua5.3-module-luaossl: - delete duplicate provides that starts with dot inside brackets тут непонятно, почему lua5.3(_openssl) и lua5.3(openssl) - это одно и то же? Я посчитал, что это ошибка скриптов для поиска provides и requires в lua. После того, как я завел ошибки на эту тему: #46285, #46286. Они были закрыты в таске https://packages.altlinux.org/ru/tasks/321961/
(Ответ для Stanislav Levin на комментарий #31) > lua5.3-module-luaunit: > > - rm -rvf %luarocks_dbdir/%oname/%oversion/test > > забыли добавить %buildroot. Поэтому рекомендую не использовать -f в > > подобных сценариях. Поправил в таске https://packages.altlinux.org/ru/tasks/324892/
(Ответ для Stanislav Levin на комментарий #33) > python3-module-flask-httpauth: > > - не рекомендую добавлять в changelog несуществующие релизы в альте: > например, 4.7.0-alt1 никогда не было в сизифе, в таком случае можно было > сделать слияние с апстримным тегом и накатить 'Initial build for > sisyphus'. > > - рекомендации по написанию changelog: > https://www.altlinux.org/ > %D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0% > BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog > то есть не рекомендуется указывать косметические изменения в spec файле, > потому что они никому не интересны. Для данного пакета это не исправить, на будущее учту > > - рекомендую не использовать глоббинг вида %python3_sitelibdir/* > люди делают ошибки при упаковке (например, делают слияние с неправильным > тэгом, забывают изменить версию проекта, генерируют некорректные > основанные > на SCM версии и тд) и такой глоббинг скрывает их. > Рекомендую использовать следующее: > %python3_sitelibdir/%{pyproject_distinfo %pypi_name} > или > %python3_sitelibdir/YOUR_PROJECT_NAME-%version.dist-info/ > > - нет необходимости делать provide вида: > %py3_provides %pypi_name Исправил тут: https://git.altlinux.org/people/dutyrok/packages/?p=python3-module-flask-httpauth.git;a=shortlog;h=refs/heads/sisyphus (войдут в следующий релиз)
(Ответ для Stanislav Levin на комментарий #35) > python3-module-clickhouse-sqlalchemy: > > - нет необходимости в provide вида: > > %py3_provides %pypi_name > - CONTRIBUTING.rst не файл документации пользователя > > - не рекомендую добавлять в changelog несуществующие релизы в альте: > например, 0.2.2-alt1 никогда не было в сизифе, в таком случае можно было > сделать слияние с апстримным тегом и накатить 'Initial build for > sisyphus'. > > > - рекомендации по написанию changelog: > https://www.altlinux.org/ > %D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0% > BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog > то есть не рекомендуется указывать косметические изменения в spec файле, > потому что они никому не интересны (пример неинтересности, > add %%py3_provides %%pypi_name) > > - текст коммита > Например, 358717464c4c68510b352589bd61570a3ef4cfa8. > Что можно понять из 'add %py3_provides %pypi_name'? Для чего это нужно? Исправил https://packages.altlinux.org/ru/tasks/315695/
(Ответ для Stanislav Levin на комментарий #34) > go-callvis: > > - схема пакетирования. На этапе вступления очень важно, чтобы кандидат > использовал одну из "общепринятых" схем пакетирования. В этом пакете > вы тарите корень репозитория и отдельно накладываете патч. Такой схемы > в gear-rules(5) нет. Пожалуйста, сделайте одним из указанных вариантов. > > - опечатка в тексте коммита > 0.6.1.gita410f11-alt1 => 0.6.1-alt1.gita410f11 > Можно использовать gear-commit из gear для генерации сообщения коммита из > последней записи changelog. > > - добавляйте патчи отдельными коммитами с объяснением их необходимости. > Вы закоммитили патч с сообщением 'add vendor for package', это не добавило > ясносности зачем он нужен. Пришлось догадаться, что он выдернут из старого > PR. > > - рекомендую фиксировать процедуру генерации бандла go модулей для > облегчения последующего процесса обновления Исправил: https://packages.altlinux.org/ru/tasks/316843/
(Ответ для Stanislav Levin на комментарий #46) > (In reply to Alexandr Shashkin from comment #44) > > (Ответ для Stanislav Levin на комментарий #43) > > > sniffnet: > > > - ExcludeArch: i586 armh > > > дан короткий комментарий '# out of memory', который не сильно проясняет > > > проблему, можно подробнее? > > По этой причине падала сборка на armh и i586 > > А если бы сборка падала на x86_64? Если есть проблема, то с ней нужно > постараться разобраться, хотя бы срепортить в апстрим. Есть ли тикет? Решил проблему с нехваткой памяти: убрал из RUSTFLAGS '-g' опцию (Equivalent to -C debuginfo=2). Также исправил следующее (из комментария https://bugzilla.altlinux.org/show_bug.cgi?id=43096#c43): > - лицензия Apache-2.0 MIT, > поддерживаемые операторы в выражении лицензии: and, or, with. > Так, upstream определяет свою лицензию как 'MIT OR Apache-2.0'. > Можно посмотреть тут: > https://lists.altlinux.org/pipermail/devel/2019-November/209050.html > > > - имеет смысл показывать сообщение об использовании в %post? кто должен > это прочитать? > > - как был получен бандл внешних зависимостей? Опять же, рекомендую > задокументировать эту процедуру в репозитории тем или иным образом. Можно увидеть здесь https://packages.altlinux.org/ru/tasks/325478/
(Ответ для Stanislav Levin на комментарий #45) > python3-module-fastapi: Исправления можно увидеть: https://packages.altlinux.org/ru/tasks/325661/ > - %add_pyproject_deps_check_filter ruff types- > можно убрать с rpm-build-pyproject 0.0.4-alt1 > > - это лишнее BuildRequires: python3(python-multipart), вы уже имеете эту > зависимость в requirements-tests.txt. > > - sedding можно заменить на опцию pytest, --deselect > 'tests/test_tutorial/test_async_sql_databases/test_tutorial001.py:: > test_create_read' > > > - -Werror, общепринято считать любой warning ошибкой при запуске тестов, но > при пакетировании - это настоящая проблема(любой DeprecationWarning > неоправданно сломает сборку), поэтому рекомендую игнорировать все warning при > тестировании (апстрим может быть не готов к такому), сделать это можно через опцию > pytest '-Wignore' > > > > - CONTRIBUTING.md и SECURITY.md - не файлы документации пользователя Теперь подробнее о некоторых моментах: > > - пакет висит в FTBFS, желательно поправить > Как я писал ранее, fastapi был сломан пришедшим в sisyphus starlette-0.28. Сейчас в upstream имеется план по изменению поведения (в том числе "критические изменения") в самом пакете и в его зависимости starlette (подробнее можно увидеть здесь: https://github.com/tiangolo/fastapi/pull/9636/files#r1224626560). Поэтому временно отключил один тест, который начал падать после появления новой версии. > - не включайте в changelog записи вида 'reformat description' или 'add Vcs > tag' > Эта информация имеет околонулевой смысл здесь. > > - разбивайте коммиты на минимально возможные логически независимые > изменения. Например, коммит 522197b6dc3fe3838e35bf4afee15e2c155ab64c. > Здесь намешано всё подряд, как понять, что сделано и для чего? Добавленное в changelog уже не убрать и указанный коммит уже не разбить, но на будущее учту. > - не хватает описания для патчей, почему же они нужны? > Сообщали ли вы в upstream о возникших проблемах? Проанализировал то, как в upstream настроены тесты для запуска в github workflow (https://github.com/tiangolo/fastapi/blob/0.99.1/scripts/test.sh) - там выполняются тесты только из директории tests/. Я тоже указал директорию при вызове pytest в spec файле (тем более что директория docs_src не пакуется, и я не вижу смысла выполнять из нее тесты). Поэтому надобность в патче fastapi-0.95.1-alt-email_tests.patch отпала (Но в ответ на вопрос об описании: он был взят здесь https://github.com/tiangolo/fastapi/pull/4409) Для второго патча добавил описание. Он нужен для совместимости тестов fastapi со слишком новым sqlalchemy (у нас 2.0.18, а для fastapi требуется sqlalchemy >=1.3.18,<1.4.43). Пока не вижу смысла отправлять в upstream изменения, поскольку изменения могут оказаться бесполезными из-за грядущего переезда upstream на новую версию sqlalchemy
(Ответ для Alexandr Shashkin на комментарий #59) > (Ответ для Stanislav Levin на комментарий #32) > > lua5.3-module-openssl: > > - состояние submodule lua-compat не соответствует сконфигурированному, > > должно быть e00fd0a415694dc15687593e355441af6dfa30bd, фактическое > > состояние 8f8e4c6adb43e107f5902e784ef207dc3c8ca06b (today's master) > > > > Как вы делаете 'add submodules'? Вероятно, вы клонируете > > целевой репозиторий и тарите текущий коммит вместо положенного? > > Рекомендую зафиксировать эту процедуру в репозитории для упрощения > > последующих обновлений. > > > > - фактическая упакованная версия 0.8.2-1, оформлено как 0.8.2 > > https://www.altlinux.org/Spec#%D0%9F%D1%80%D0%BE%D0%BC%D0%B5%D0%B6%D1%83 > > %D1%82%D0%BE%D1%87%D0%BD%D1%8B%D0%B5_upstream-%D1%80%D0%B5%D0%BB%D0%B8%D0%B7%D1%8B > > > > - такая же рекомендация по rockspec, как и для lua5.3-module-luaossl > > Я внес указанные изменения. Но в выходные обновился openssl > https://packages.altlinux.org/en/tasks/324359/. > И в результате 3 теста зафэйлились > (https://git.altlinux.org/tasks/324716/build/1000/x86_64/log). Я хотел > проверить это с последней версией указанного пакета. Но для нее требуется > новый luarocks, > а обновить его корректно не получится, так как необходимо править пакет > rpm-build-lua > (который собрал Селезнев и закрыл на него acl). Милюков предложил > соответствующие исправления в таске https://git.altlinux.org/tasks/315204/, > но Селезнев пока ответа не дал). Пакет lua5.3-module-openssl собирался опционально для cgit, но потом я от (lua-openssl) отказался. Соответственно в репозиторий он не попал. Сейчас этот пакет мне не нужен, в репозиторий я его отправлять не собираюсь, поэтому его можно не проверять.
Считаю, что можно двигаться дальше. ACK
Адрес подписан на devel@. Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства!
