Created attachment 9453 [details] ключи Псевдоним: fruktime адрес пересылки почты: fruktime@altlinux.org Имя ментора: Егор Почта ментора: egori@altlinux.org
> Имя ментора: Егор > Почта ментора: egori@altlinux.org Подтверждаю.
Created attachment 9454 [details] GPG
Created attachment 9455 [details] SHH
(Ответ для Дмитрий на комментарий #3) > Создано вложение 9455 [details] [подробности] > SHH Ok. (Ответ для Дмитрий на комментарий #2) > Создано вложение 9454 [details] [подробности] > GPG Мы просим делать uid в ключе в формате Firstname Lastname.
Created attachment 9463 [details] GPG исправил
(Ответ для Дмитрий на комментарий #5) > Создано вложение 9463 [details] [подробности] > GPG Ok. (Ответ для Дмитрий на комментарий #0) > адрес пересылки почты: fruktime@altlinux.org А на какой адрес пересылать почту для fruktime@a.o?
(Ответ для Gleb F-Malinovskiy на комментарий #6) > (Ответ для Дмитрий на комментарий #5) > > Создано вложение 9463 [details] [подробности] > > GPG > Ok. > > (Ответ для Дмитрий на комментарий #0) > > адрес пересылки почты: fruktime@altlinux.org > А на какой адрес пересылать почту для fruktime@a.o? fruktime@basealt.ru
Прошу предоставить доступ на git.altlinux.org.
ssh ключ на gitery.alt зарегистрирован. ssh ключ на gyle.alt зарегистрирован. Адрес для пересылки создан.
Не могу залогиниться на gyle и gitary по ключу ssh: sign_and_send_pubkey: signing failed: agent refused operation ssh: git_fruktime@gyle.altlinux.org: Permission denied (publickey). config файл прописал
(In reply to Дмитрий from comment #10) > ssh: sign_and_send_pubkey: signing failed: agent refused operation Эта фраза значит, что вы используете ssh-agent, а он по какой-то причине на даёт использовать ключ. Чаще всего это значит, что используется ключ без пароля (не самая лучшая практика), ~/.xprofile успешно загрузил ключ в ssh-agent в режиме подтверждения каждой операции, а ssh-agent не смог запросить подтверждение (либо потому что у вас нет ssh-askpass, либо потому что ssh-askpass не смог запустить графическое окошко). Реализации ssh-askpass: $ apt-cache show /usr/lib/openssh/ssh-askpass Package /usr/lib/openssh/ssh-askpass is a virtual package provided by: x11-ssh-askpass 1:1.2.4.1-alt5:sisyphus+278100.7500.1.1@1626060657 plasma5-ksshaskpass 1:5.22.3-alt1:sisyphus+277521.2100.4.3@1625815540 gtk2-ssh-askpass 5.4p1-alt1:sisyphus+278100.2000.1.1@1626058462 You should explicitly select one to show. E: Package /usr/lib/openssh/ssh-askpass is a virtual package with multiple providers.
Считаю, что кандитат освоился с инструментами и готов к следующему этапу, прошу предоставить доступ на сборочницу. Текущий репозиторий: https://git.altlinux.org/people/fruktime/packages/?p=python3-module-django-environ.git;a=summary
ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.5.
Считаю, что кандитат освоил сборку пакетов разных типов и готов отправлять пакеты в Сизиф. Прошу призвать рецензента для независимой оценки готовности кандидата. Текущие репозитории: https://git.altlinux.org/people/fruktime/packages/?p=python3-module-django-storages.git;a=summary https://git.altlinux.org/people/fruktime/packages/?p=python3-module-django-minify-html.git;a=summary https://git.altlinux.org/people/fruktime/packages/?p=python3-module-django-htmlmin.git;a=summary https://git.altlinux.org/people/fruktime/packages/?p=python3-module-django-environ.git;a=summary https://git.altlinux.org/people/fruktime/packages/?p=minify-html.git;a=summary https://git.altlinux.org/people/fruktime/packages/?p=ttyd.git;a=summary А также обновлены: https://git.altlinux.org/people/fruktime/packages/?p=python3-module-django-ckeditor.git;a=summary https://git.altlinux.org/people/fruktime/packages/?p=libwebsockets.git;a=summary
так и не призвали рецензента
Я готов быть вторым ментором, если есть проблемы с поиском.
Честно говоря, я эту багу в упор не замечаю потому что она не в том статусе.
Я не нашёл рецензента и решил, что я сам подойду. Общие замечания: * Наш rpm поддерживает тег VCS, его не нужно оставлять закомментированным. * У вас в некоторых файлах No newline at end of file, а в некоторых других, наоборот, new blank line at EOF (иногда даже две), это касается почти всех ваших пакетов. (совет) Посмотрите на pre-commit hook, который идёт прямо в комплекте с git, он сообщает о таких ошибках (а заодно ещё и о некоторых других). Я сделал у себя так, чтобы он включался во всех моих git-репозиториях. * (принцип наименьшего удивления) Почему-то почти во всех spec-ах вы везде делаете два перевода строки между секциями %files и %changelog, хотя во всех остальных местах вы этого не делаете, в первый раз это кажется случайностью, но в итоге выглядит как непоследовательный стиль. * (мысли вслух) Лично мне не нравится практика складывания абсолютно всех файлов, связанных со сборкой пакета в каталог .gear/. Обычно, когда я собираю пакет из апстримного git-а, я кладу и spec и все дополнительные файлы в каталог alt/ потому что .gear предназначен для конфигурации. python3-module-django-minify-html * Почему ExcludeArch: i586 armh? О таких вещах лучше писать рядом в виде комментария. python3-module-django-htmlmin * Версионирование нерелизных коммитов из апстрима. ** (совет) Вместо version: 0.11.0, release: alt0.git.01575db, лучше использовать версию производную от той, которую даёт git describe, т.е. в этом случае 0.11.0-21-g01575db я бы превратил в version: 0.11.0.21.g01575db, а релиз делал alt1. Идея в том, что версия это версия апстримного кода, а релиз это версия нашего пакета, предлагаемый подход гораздо лучше отражает это разделение. ** (совет) Лучше никогда не использовать alt0 в релизе, это плохая привычка потому что для релиза alt0.git.01575db очень сложно сделать *меньший*, например если нужно собрать backport в бранч. python3-module-django-environ * В этом пакете что-то не так пошло с commit message, я не понимаю, что в нём написано. minify-html В этом пакете я не очень понимаю, что и откуда растёт и как должно было выглядеть. * В коммите b9ff2db вы добавляете целый скрипт для получения crates.tar (это хорошая идея), но crates.tar так и остаётся файлом, состоящим из одного пробела. ** (мысли вслух) Если код из этого скрипта всё же нужен, то может быть лучше записать то, что он делает прямо в спек-файл? По сути, когда вы запускаете в скрипте git archive, вы делаете то же самое, что делает gear, но заново. Я делал похожую вещь в пакете shellcheck, там я реализовал специальный режим, в котором при сборке пакета нужна сеть, но вместо сборки пакета скачиваются все нужные исходники. * В коммите 94ef1e1 вы добавляете сгенерированные файлы. Откуда они берутся? Нельзя ли их генерировать во время сборки пакета? * Почему ExcludeArch: ? ttyd * Почему-то в BuildRequires попал vim-common. Вообще-то есть инструмент для получения списка необходимых сборочных зависимостей, посмотрите на buildreq. python3-module-django-ckeditor * В коммите 3ffa4 вопреки commit message просто в другое место добавляется spec-файл, а старый spec-файл пропадает почему-то в мерж-коммите 4937e4, это сбивает с толку, если честно. Я понимаю, что вы хотели поменять схему сборки пакета, но получилось совершенно непонятно с точки зрения git-овой истории. libwebsockets * По поводу коммита 050fd54: ** Использовали ли вы утилиту gear-import для импорта исходников? Это хороший способ делать это правильно. ** (совет) Я бы использовал "Import <url>" в качестве commit message, так будет сразу понятно, что именно и откуда было импортировано. * Было бы гораздо лучше, если бы вы отразили в %changelog то изменение, которое вы сделали в этом пакете. Вы же включили в нём дополнительную функциональность, а не только обновили его, а это стоит отражать в %changelog. * При обновлении у пакета поменялся soname. Посмотрите, пожалуйста https://www.altlinux.org/Shared_Libs_Policy В целом, ваши более новые пакеты выглядят достаточно хорошо (за мелких замечаний), можно завершить вступление в команду. Не забывайте, что грамотное оформление git-репозитория и %changelog поможет другим людям (например, вам самому через несколько лет) понять, зачем и как что-то было сделано.
(In reply to Gleb F-Malinovskiy from comment #18) > python3-module-django-htmlmin > > * Версионирование нерелизных коммитов из апстрима. > ** (совет) Вместо version: 0.11.0, release: alt0.git.01575db, лучше > использовать версию производную от той, которую даёт git describe, > т.е. в этом случае 0.11.0-21-g01575db я бы превратил в version: > 0.11.0.21.g01575db, а релиз делал alt1. Идея в том, что версия это версия > апстримного кода, а релиз это версия нашего пакета, предлагаемый подход > гораздо лучше отражает это разделение. В таком случае думаю стоит обновить вики. 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 "При сборке промежуточных релизов upstream-кода (срезов по дате, по системе контроля версий), следует указывать информацию о срезе в поле Release:" > minify-html > > В этом пакете я не очень понимаю, что и откуда растёт и как должно было > выглядеть. > * В коммите b9ff2db вы добавляете целый скрипт для получения crates.tar (это > хорошая идея), но crates.tar так и остаётся файлом, состоящим из одного > пробела. Это сделано, чтобы не тянуть в git историю блобы с зависимостями и не раздувать репозиторий. По похожей схеме собирается например alacritty. > ** (мысли вслух) Если код из этого скрипта всё же нужен, то может быть > лучше записать то, что он делает прямо в спек-файл? По сути, когда вы > запускаете в скрипте git archive, вы делаете то же самое, что делает gear, > но заново. Я делал похожую вещь в пакете shellcheck, там я реализовал > специальный режим, в котором при сборке пакета нужна сеть, но вместо сборки > пакета скачиваются все нужные исходники. Как по мне, внешний скрипт, который вендорит зависимости, гораздо понятнее, чем 'специальный режим' в спеке, это, конечно, красиво, но ИМХО мисюз. Хотя сам бы я коммитил зависимости в гит и не мучался с srpm. > python3-module-django-ckeditor > * В коммите 3ffa4 вопреки commit message просто в другое место добавляется > spec-файл, а старый spec-файл пропадает почему-то в мерж-коммите 4937e4, это > сбивает с толку, если честно. Я понимаю, что вы хотели поменять схему > сборки пакета, но получилось совершенно непонятно с точки зрения git-овой > истории. Да, странно, что в 3ffa490 есть сразу 2 django-ckeditor.spec В остальном согласен с Глебом. Дим, исправь, пожалуйста, что можно исправить.
(In reply to Egor Ignatov from comment #19) > (In reply to Gleb F-Malinovskiy from comment #18) > > ** (совет) Вместо version: 0.11.0, release: alt0.git.01575db, лучше > > использовать версию производную от той, которую даёт git describe, > > т.е. в этом случае 0.11.0-21-g01575db я бы превратил в version: > > 0.11.0.21.g01575db, а релиз делал alt1. Идея в том, что версия это версия > > апстримного кода, а релиз это версия нашего пакета, предлагаемый подход > > гораздо лучше отражает это разделение. > В таком случае думаю стоит обновить вики. > 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 > "При сборке промежуточных релизов upstream-кода (срезов по дате, по системе > контроля версий), следует указывать информацию о срезе в поле Release:" Это был просто совет -- оба варианта рабочие, но на вики точно стоит написать о таком способе, если не написано. > > minify-html > > > > В этом пакете я не очень понимаю, что и откуда растёт и как должно было > > выглядеть. > > * В коммите b9ff2db вы добавляете целый скрипт для получения crates.tar (это > > хорошая идея), но crates.tar так и остаётся файлом, состоящим из одного > > пробела. > Это сделано, чтобы не тянуть в git историю блобы с зависимостями и не > раздувать репозиторий. По похожей схеме собирается например alacritty. В таком случае об этом стоит написать в spec-е, написать инструкцию (в идеале со скриптом) по получению сгенерированного исходного кода и класть сгенерированный код (хотя бы средствами gear) в отдельный tarball. > > ** (мысли вслух) Если код из этого скрипта всё же нужен, то может быть > > лучше записать то, что он делает прямо в спек-файл? По сути, когда вы > > запускаете в скрипте git archive, вы делаете то же самое, что делает gear, > > но заново. Я делал похожую вещь в пакете shellcheck, там я реализовал > > специальный режим, в котором при сборке пакета нужна сеть, но вместо сборки > > пакета скачиваются все нужные исходники. > Как по мне, внешний скрипт, который вендорит зависимости, гораздо понятнее, > чем 'специальный режим' в спеке, это, конечно, красиво, но ИМХО мисюз. > Хотя сам бы я коммитил зависимости в гит и не мучался с srpm. Согласен, что мисюз, но я бы этим скриптом не смог сходу воспользоваться, его бы пришлось для этого прочитать, а всё что в spec-е работает в воспроизводимой изолированной среде с известными свойствами.
Я спрошу здесь, что бы не заводить пока что отдельную багу. А почему бы нам не приравнять каталог altlinux/ в дереве к .gear/ по смыслу (в gear) ? Тогда все, что надо для сборки лежало бы в осмысленном каталоге altlinux (по аналогии с debian) и одним камнем преткновения было бы меньше.
(In reply to Anton Farygin from comment #21) > Я спрошу здесь, что бы не заводить пока что отдельную багу. > > А почему бы нам не приравнять каталог altlinux/ в дереве к .gear/ по смыслу > (в gear) ? .gear-rules и .gear/rules это уже слишком много вариантов, а ты предлагаешь это ещё усложнить, тем более, что выбрать название этого дополнительного каталога будет сложно. > Тогда все, что надо для сборки лежало бы в осмысленном каталоге altlinux (по > аналогии с debian) и одним камнем преткновения было бы меньше. Мне не кажется, что это такой уж камень преткновения. Я просто привык, что .gear/rules единственный файл, который нужно менять в .gear, а остальные файлы меняют только инструменты. А спек может быть где угодно, почему именно здесь?
(In reply to Anton Farygin from comment #21) > Я спрошу здесь, что бы не заводить пока что отдельную багу. Для этого есть список рассылки. Заводя обсуждение здесь, ты сужаешь аудиторию. Я решил прокомментировать, поскольку считаю, что новичкам, проходящим join, важно отличать правильные примеры от неправильных.
(In reply to Gleb F-Malinovskiy from comment #20) > (In reply to Egor Ignatov from comment #19) > > Это сделано, чтобы не тянуть в git историю блобы с зависимостями и не > > раздувать репозиторий. По похожей схеме собирается например alacritty. > В таком случае об этом стоит написать в spec-е, написать инструкцию (в > идеале со скриптом) по получению сгенерированного исходного кода и класть > сгенерированный код (хотя бы средствами gear) в отдельный tarball. Хочу вернуться чуть-чуть к этому вопросу: мне кажется, что такой путь очень сложный... > > Хотя сам бы я коммитил зависимости в гит и не мучался с srpm. ... и стоит делать вот так. Потому что: 1. сгенерированные исходники лучше генерировать при сборке пакета потому что так проще всего показать, откуда они берутся и как; 2. экономия на размере репозитория это экономия на спичках, а п. 1. важнее.
(Ответ для Gleb F-Malinovskiy на комментарий #24) > (In reply to Gleb F-Malinovskiy from comment #20) > > (In reply to Egor Ignatov from comment #19) > > > Это сделано, чтобы не тянуть в git историю блобы с зависимостями и не > > > раздувать репозиторий. По похожей схеме собирается например alacritty. > > В таком случае об этом стоит написать в spec-е, написать инструкцию (в > > идеале со скриптом) по получению сгенерированного исходного кода и класть > > сгенерированный код (хотя бы средствами gear) в отдельный tarball. > Хочу вернуться чуть-чуть к этому вопросу: мне кажется, что такой путь очень > сложный... > > > > Хотя сам бы я коммитил зависимости в гит и не мучался с srpm. > ... и стоит делать вот так. > Потому что: > 1. сгенерированные исходники лучше генерировать при сборке пакета потому что > так проще всего показать, откуда они берутся и как; > 2. экономия на размере репозитория это экономия на спичках, а п. 1. важнее. Так не получится сделать, у некоторых зависимостей есть папка .git, и чексуммы считаются с учетом этой папки, а если тянуть зависимости в репозиторий, то .git игнорится и чексуммы в итоге не совпадают. Можно собрать без отдельного скрипта например как тут: https://packages.altlinux.org/ru/sisyphus/srpms/rust-cargo-c/specfiles/
Адрес подписан на devel@. Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства!
