Псевдоним: ximper Почта: ghgh2222@yandex.ru Цель - в начале собирать пакеты для sisyphus, а после научится собирать дистрибутив на базе репозиториев р10 Имеется практика работы с gear: https://gitlab.com/ximper1/grim-alt-pkg/-/tree/sisyphus https://gitlab.com/ximper1/power-profiles-daemon-alt-pkg/-/tree/sisyphus https://gitlab.com/ximper1/switcheroo-control-alt-pkg/-/tree/sisyphus https://gitlab.com/ximper1/wofi-alt-pkg/-/tree/sisyphus (этот репозиторий нужно будет переделать с использованием hg-git...) Ментор пока не определен...
Created attachment 11572 [details] gpg key
Created attachment 11573 [details] ssh key
Человек обращался насчёт менторства; с учётом моего обычного времени ответа прошу Гришу подстраховать/взяться. К конкретно взятому grim.spec у меня оказались скорее мелкие вкусовые вопросы -- см. приложенный патчик, из существенного в нём только правка Group: (сверяться стоит с /usr/lib/rpm/GROUPS). В этом плане нужна проверка по 2.0, а заключение выше -- положительное по 3.0. PS: посмотрел switcheroo -- там тоже есть что поправить, см. тж. cleanup_spec из rpm-utils, http://altlinux.org/ALT_Packaging_HOWTO#Порядок_тэгов (ну и %setup -q в альте давно уже эквивалентно просто %setup).
(Ответ для Michael Shigorin на комментарий #3) > Человек обращался насчёт менторства; с учётом моего обычного времени ответа > прошу Гришу подстраховать/взяться. > > К конкретно взятому grim.spec у меня оказались скорее мелкие вкусовые > вопросы -- см. приложенный патчик, из существенного в нём только правка > Group: > (сверяться стоит с /usr/lib/rpm/GROUPS). > > В этом плане нужна проверка по 2.0, а заключение выше -- положительное по > 3.0. > > PS: посмотрел switcheroo -- там тоже есть что поправить, см. тж. > cleanup_spec из rpm-utils, > http://altlinux.org/ALT_Packaging_HOWTO#Порядок_тэгов (ну и %setup -q в > альте давно уже эквивалентно просто %setup). Вроде бы поправил
> К конкретно взятому grim.spec у меня оказались скорее мелкие вкусовые > вопросы -- см. приложенный патчик, из существенного в нём только правка > Group: > (сверяться стоит с /usr/lib/rpm/GROUPS). Ваш патч видимо не отправился.. Group наверное просто забыл заполнить...
Created attachment 11575 [details] grim.spec.diff (mike@) (Ответ для ghgh2222 на комментарий #5) > Ваш патч видимо не отправился.. Ещё бы не отправился, если я вместо того, чтоб перетащить комментарий в форму для прицепов -- пошёл смотреть другой пакет...
(Ответ для Michael Shigorin на комментарий #3) > Человек обращался насчёт менторства; с учётом моего обычного времени ответа > прошу Гришу подстраховать/взяться. Я предлагаю на уровне полиси запретить "страховать". 2 ментора - это куча проблем для всех. Во-первых, каждый ментор обладает своим взглядом на процесс обучения. В частности один человек пользуется одним инструментом, другой другим, а что делать кандидату? Во-вторых, ни один из двух менторов не будет чувствовать ответственности за кандидата. Тут как с запуском ядерных ракет. Я уже принимал участие в двойном менторстве как будучи кандидатом, так и будучи ментором. Оба случая привели к огромным проблемам. Так что либо ты, либо я, либо можно поискать кого-нибудь в devel-newbies.
(Ответ для Michael Shigorin на комментарий #3) > PS: посмотрел switcheroo -- там тоже есть что поправить, см. [...] > http://altlinux.org/ALT_Packaging_HOWTO#Порядок_тэгов Ссылку именно на порядке тегов дал не просто так; возможно, там же стоит как-то ненавязчиво подчеркнуть, что "далее" обычно включает разделение наборов строк пустою строкой. Применять его -- что к репозиторию, что мысленно ("а, понял") вслепую не стоит: например, я обычно пишу так, как помню по изящным спекам двадцатилетней давности -- кстати, Source0 == Source, Patch0 == Patch и для него есть просто %patch: Url: Source: Packager: поскольку единичный исходник более "тяготеет" к Url: -- но если исходников и/или патчей много, то Packager: есть смысл поднять к Url, а уже после перечислить все полэкрана (или пару экранов) того, что потребовалось для собственно пакета: Url: Packager: Source0: Source1: ... Patch0: Patch1: ... #Patch2000: alt-e2k.patch
(Ответ для Grigory Ustinov на комментарий #7) > Я предлагаю на уровне полиси запретить "страховать". > 2 ментора - это куча проблем для всех. Принял, понимаю ("у семи нянек дитя без глаза"). Тогда я как откликнувшийся.
(Ответ для Michael Shigorin на комментарий #9) > (Ответ для Grigory Ustinov на комментарий #7) > > Я предлагаю на уровне полиси запретить "страховать". > > 2 ментора - это куча проблем для всех. > Принял, понимаю ("у семи нянек дитя без глаза"). > Тогда я как откликнувшийся. Отлично! А то у меня и так по кандидатам завал=)
> > PS: посмотрел switcheroo -- там тоже есть что поправить, см. [...] > > http://altlinux.org/ALT_Packaging_HOWTO#Порядок_тэгов > Ссылку именно на порядке тегов дал не просто так; возможно, там же стоит > как-то ненавязчиво подчеркнуть, что "далее" обычно включает разделение > наборов строк пустою строкой. > > Применять его -- что к репозиторию, что мысленно ("а, понял") вслепую не > стоит: например, я обычно пишу так, как помню по изящным спекам > двадцатилетней давности -- кстати, Source0 == Source, Patch0 == Patch и для > него есть просто %patch: Отправил на гитлаб исправленный спек
Глеб, предлагаю переходить к п. 2 регламента (ssh-ключик похож, gpg-шный выписан на адрес Roman Alifanov <ximper@altlinux.org>, спеки в сизиф пускать можно).
(In reply to ghgh2222 from comment #1) > Created attachment 11572 [details] > gpg key (In reply to ghgh2222 from comment #2) > Created attachment 11573 [details] > ssh key Ok.
ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3.
По уже просмотренным пакетам считаю, что можно переходить к 3.0, заливать на git.alt и собирать в сборочнице в направлении 4.0.
(Ответ для Michael Shigorin на комментарий #15) > По уже просмотренным пакетам считаю, что можно переходить к 3.0, заливать на > git.alt и собирать в сборочнице в направлении 4.0. Залил все пакеты на gitery
ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.5.
Уже протестировал два пакета в сборочнице Тесты прошли успешно
Протестировал еще один пакет - power-profiles-daemon Сборка прошла без ошибок
Протестировал еще один пакет - wofi Сборка прошла без ошибок
(Ответ для ghgh2222 на комментарий #20) > Протестировал еще один пакет - wofi > Сборка прошла без ошибок Нет смысла дублировать BuildRequires: -- подпакетоспецифичные сборочные зависимости в принципе имеют смысл разве что если уж очень неприятны, сам подпакет при этом является отключаемым (%if_with/%if_enabled), а вся пачка зависимостей под вопросом относится именно к нему. И то их обычно в таких случаях запихивают под %if_* в блоке основных BR:. Также стоит начинать строку %changelog с "- "; см. тж. http://altlinux.org/Руководство_по_написанию_changelog (и если пользуетесь vim -- то vim-plugin-spec_alt-ftplugin и \ac для добавления новой записи или самого %changelog). И скорее эстетическое -- по спеку стоит прогнать cleanup_spec из rpm-utils, сократит как минимум %{name} в одном месте, где никакие подчёркивания не вынуждают добавлять лишние скобочки; также можно поменять %_mandir/manN на %_manNdir (конкретно %_man3dir так и вовсе забрать по *), %_libdir/pkgconfig на %_pkgconfigdir -- подобное можно заметить так: $ rpm --showrc | grep pkgconfig
(Ответ для Michael Shigorin на комментарий #21) > (Ответ для ghgh2222 на комментарий #20) > > Протестировал еще один пакет - wofi > > Сборка прошла без ошибок > Нет смысла дублировать BuildRequires: -- подпакетоспецифичные сборочные > зависимости в принципе имеют смысл разве что если уж очень неприятны, > сам подпакет при этом является отключаемым (%if_with/%if_enabled), > а вся пачка зависимостей под вопросом относится именно к нему. > > И то их обычно в таких случаях запихивают под %if_* в блоке основных BR:. > > Также стоит начинать строку %changelog с "- "; см. тж. > http://altlinux.org/Руководство_по_написанию_changelog > (и если пользуетесь vim -- то vim-plugin-spec_alt-ftplugin > и \ac для добавления новой записи или самого %changelog). > > И скорее эстетическое -- по спеку стоит прогнать cleanup_spec > из rpm-utils, сократит как минимум %{name} в одном месте, где никакие > подчёркивания не вынуждают добавлять лишние скобочки; также можно поменять > %_mandir/manN на %_manNdir (конкретно %_man3dir так и вовсе забрать по *), > %_libdir/pkgconfig на %_pkgconfigdir -- подобное можно заметить так: > > $ rpm --showrc | grep pkgconfig Исправил спек
Готов к осмотру моего пакета, wofi, рецензентом.
(Ответ для ghgh2222 на комментарий #22) > Исправил спек Вот этот мне прям нра: http://gitlab.com/ximper1/wofi-alt-pkg/-/blob/1.3-alt1/.gear/wofi.spec PS: а вот лишнюю цитату, отвечая в баге, стоит стереть во избежание излишнего простынеобразования :)
(Ответ для ghgh2222 на комментарий #23) > Готов к осмотру моего пакета, wofi, рецензентом. 2 grenka: глянешь? (или позовите кого сочтёте нужным на рецензию, коллеги) http://gitlab.com/ximper1/wofi-alt-pkg/-/blob/1.3-alt1/.gear/wofi.spec
(Ответ для Michael Shigorin на комментарий #25) > (Ответ для ghgh2222 на комментарий #23) > > Готов к осмотру моего пакета, wofi, рецензентом. > 2 grenka: глянешь? (или позовите кого сочтёте нужным на рецензию, коллеги) > > http://gitlab.com/ximper1/wofi-alt-pkg/-/blob/1.3-alt1/.gear/wofi.spec %package devel Group: Documentation Summary: Development package for %name Подпакет devel это вообще ни разу не Documentation. Во-вторых, наверное действительно пусть назначает секретарь. В-третьих, наверное для рецензента нужно подготовить больше пакетов. Или у нас можно заджойниться по одному простенькому пакетику?
(Ответ для Grigory Ustinov на комментарий #26) > Подпакет devel это вообще ни разу не Documentation. Проморгал; ты прав, обычно это что-то из `grep Development /usr/lib/rpm/GROUPS` -- Роман, поправьте при возможности. > В-третьих, наверное для рецензента нужно подготовить больше пакетов. > Или у нас можно заджойниться по одному простенькому пакетику? 1) см. comment 0 (там ещё парочка); 2) я тебе в какой-то баге уж на такое отвечал, что сам в команду попал с однострочным исправлением в конфиге webalizer, а уважаемый принимающий изначально был тестировщиком (да и ты если бы заранее узнал, что придётся податься в питоноборцы -- убежал бы, поди, сверкая пятками; страшно, да); 3) если есть консенсус по отсутствию консенсуса по уровню подготовки -- значит, придётся либо выбрать/назначить уважаемых людей, либо написать регламент (и потом периодически утыкаться в его неполноту).
(Ответ для Michael Shigorin на комментарий #27) > (Ответ для Grigory Ustinov на комментарий #26) > > Подпакет devel это вообще ни разу не Documentation. > Проморгал; ты прав, обычно это что-то из `grep Development > /usr/lib/rpm/GROUPS` -- Роман, поправьте при возможности. > > > В-третьих, наверное для рецензента нужно подготовить больше пакетов. > > Или у нас можно заджойниться по одному простенькому пакетику? > 1) см. comment 0 (там ещё парочка); > 2) я тебе в какой-то баге уж на такое отвечал, что сам в команду попал > с однострочным исправлением в конфиге webalizer, а уважаемый принимающий > изначально был тестировщиком (да и ты если бы заранее узнал, что придётся > податься в питоноборцы -- убежал бы, поди, сверкая пятками; страшно, да); > 3) если есть консенсус по отсутствию консенсуса по уровню подготовки -- > значит, придётся либо выбрать/назначить уважаемых людей, либо написать > регламент (и потом периодически утыкаться в его неполноту). https://gitlab.com/ximper1/wofi-alt-pkg/-/blob/1.3-alt2/.gear/wofi.spec Поправил
(Ответ для Michael Shigorin на комментарий #27) > 3) если есть консенсус по отсутствию консенсуса по уровню подготовки -- > значит, придётся либо выбрать/назначить уважаемых людей, либо написать > регламент (и потом периодически утыкаться в его неполноту). Регламент - вещь хорошая. Он создаёт хоть какую-то иллюзию справедливости. А то получается, что кто-то попадает к тебе и сразу в дамки, а кто-то ко мне иии... Из полутора десятков кандидатов у меня заджойнился только один. А потом ты же первый начинаешь грустить от того, что зависимости неправильно засунуты под ручку. Мы все делаем ошибки, но есть статистика.
(Ответ для Grigory Ustinov на комментарий #29) > Из полутора десятков кандидатов у меня заджойнился только один. > А потом ты же первый начинаешь грустить от того, что зависимости > неправильно засунуты под ручку. Мы все делаем ошибки, но есть статистика. Почитай на досуге про Сциллу и Харибду.
Призван рецензент (rider@) для независимой оценки готовности кандидата. T/J/S -> 4.2.
Призван рецензент (rider@) для независимой оценки готовности кандидата.
https://git.altlinux.org/people/ximper/packages/?p=wofi.git;a=blob;f=.gear/wofi.spec;h=80ae38f98a974977f5868f1ee32c5f3978fb7e35;hb=sisyphus 1. Packager лучше не указывать, он будет автоматический по тому, кто собрал. 2. Сборка идёт из апстримного гита. В этом случае лучше тарболл делать из апстримного тэга, а в spec-файл добавить тэг VCS:
https://git.altlinux.org/people/ximper/packages/?p=switcheroo-control.git;a=blob;f=.gear/switcheroo-control.spec;h=48c2a1c7fcb743718f52bb448cc8d67781d0cd44;hb=sisyphus Source указан как URL, но сборка идёт из гита, лучше наверное просто указать Source без URL. т.к. URL тут равен VCS, то тэг VCS указывать в этом пакете нет необходимости. И так же лучше собирать из апстримного тэга (в секции tar в gear/rules)
https://git.altlinux.org/people/ximper/packages/?p=power-profiles-daemon.git;a=blob;f=.gear/power-profiles-daemon.spec;h=789d8bbdd6f35b4fa6cecfec1d1309e623dfa7cd;hb=sisyphus Packager поле лучше убрать. в .gear/rules так же сделать из апстримного тэга. Непонятно, что в specfile делают комментарии и триггеры от федоры, хотя в changelog указано что спек базируется на OpenSUSE.
В grim.spec замечания в целом такие же как в предыдущих пакетах. И я бы ещё хотел увидеть работу с существующим кодом, можно, например, поправить ftbfs или исправить какую-то ошибку. https://git.altlinux.org/beehive/stats/Sisyphus-x86_64/ftbfs-joined В пакетах нет ни одной библиотеки, непонятно, получилось ли разобраться с особенностями упаковки библиотек в Альте.
(Ответ для Anton Farygin на комментарий #36) > В пакетах нет ни одной библиотеки, непонятно, получилось ли разобраться с > особенностями упаковки библиотек в Альте. 2ximper: Кстати интересный вопрос. У wofi есть devel подпакет, а как он используется? Ну то есть это просто хэдеры ради хэдеров или у них есть какая-то библиотека, которая их реализует? Просто обычно у девел подпакетов есть зависимость на некий библиотечный пакет, а тут её нет.
(Ответ для Anton Farygin на комментарий #36) > В пакетах нет ни одной библиотеки, непонятно, получилось ли разобраться > с особенностями упаковки библиотек в Альте. Мне кажется, нам и впрямь стоит "засвечивать" подобные особенности (чтоб человек знал, что они есть). Но требовать умения сборки библиотек, а также пакетов на c/c++/d/go/julia/rust и прочих перлопитонорубях -- по-моему, неуместно: у нас есть люди, которые много лет собирают свои пакетик-два и делают это хорошо, а вот ott@ уже как-то ушёл вместо того, чтобы чинить сломанные обновлением gcc пакеты как повинность. Понятно, что такое лучше не здесь обсуждать -- вопрос в том, кому ещё надо. 2 ximper: ознакомьтесь с http://altlinux.org/Shared_Libs_Policy на всякий.
(Ответ для Grigory Ustinov на комментарий #37) > 2ximper: Кстати интересный вопрос. У wofi есть devel подпакет, а как он > используется? Ну то есть это просто хэдеры ради хэдеров или у них есть > какая-то библиотека, которая их реализует? > > Просто обычно у девел подпакетов есть зависимость на некий библиотечный > пакет, а тут её нет. Ничего с ней не собирается, на сколько я понимаю. Там инструменты для разработки самого wofi вроде бы
(Ответ для Michael Shigorin на комментарий #38) > 2 ximper: ознакомьтесь с http://altlinux.org/Shared_Libs_Policy на всякий. Буду иметь в виду
(Ответ для Anton Farygin на комментарий #33) > https://git.altlinux.org/people/ximper/packages/?p=wofi.git;a=blob;f=.gear/ > wofi.spec;h=80ae38f98a974977f5868f1ee32c5f3978fb7e35;hb=sisyphus > > 1. Packager лучше не указывать, он будет автоматический по тому, кто собрал. Буду знать > 2. Сборка идёт из апстримного гита. В этом случае лучше тарболл делать из > апстримного тэга, Попробовал: https://gitlab.com/ximper1/wofi-alt-pkg/-/tree/1.3-alt3 Все собирается отлично. Теперь буду знать как это делается :) >а в spec-файл добавить тэг VCS У wofi нет гита. У него репозиторий на mercurial (hg). Я использовал hg-git для конфертации. В тэге URL ссылка на mercurial wofi.
*конвертации
Отправляйте wolf в репозиторий с --commit и скажите мне номер задания, которое будет в статусе EPERM.
(Ответ для Anton Farygin на комментарий #43) > Отправляйте wolf в репозиторий с --commit и скажите мне номер задания, > которое будет в статусе EPERM. #309961 На момент комментария, оно еще собирается.
> Packager поле лучше убрать. > в .gear/rules так же сделать из апстримного тэга. > Вроде все сделал Надеюсь нигде не ошибся https://gitlab.com/ximper1/power-profiles-daemon-alt-pkg/-/tree/0.12-alt2
Сделал задание #310242
проверил, заапрувил.
Собрал программу slurp Задание номер 312576
Ну что, коллеги, долго будем человека-то мариновать? http://t.me/alt_linux/272817 -- берегите вступающих в наши нестройные ряды :)
Роман сам не спешит, мы в контакте через телегу. Знаний для вступления пока недостаточно.
(Ответ для Anton Farygin на комментарий #50) > > http://t.me/alt_linux/272817 > Роман сам не спешит, мы в контакте через телегу. Там и прочёл. > Знаний для вступления пока недостаточно. Озвучь, что ли, недостачу -- так-то как по мне он уже меня на моём старте вполне обогнал как сопровождающий (или это подход "сперва тридцать, квартира, машина, а там и жениться можно"?) и вполне мог бы дальше учиться в процессе, как и все мы.
glebfm@, а какой минимальный набор знаний в альт тим? Я конечно еще далеко не все знаю, но хотя бы в минимальные рамки должен попадать. Хотелось бы более ясных критерий к добровольным членам альт тим..
(In reply to Roman Alifanov from comment #52) > glebfm@, а какой минимальный набор знаний в альт тим? Я конечно еще далеко > не все знаю, но хотя бы в минимальные рамки должен попадать. Хотелось бы > более ясных критерий к добровольным членам альт тим.. Дело в том, что невозможно сформулировать ясные критерии. Цель в том, чтобы вы научились собирать пакеты соответствующие ожиданиям и качеству пакетов, которые делаются для Сизифа. Получается, что можно только в каждом конкретном случае сказать, что сделано правильным, ожидаемым и понятным способом, а что нет. Ну и понятно, что нужно научиться пользоваться инструментарием и инфраструктурой.
(Ответ для Gleb F-Malinovskiy на комментарий #53) > > glebfm@, а какой минимальный набор знаний в альт тим? > Дело в том, что невозможно сформулировать ясные критерии. Более того, тут всё взаимозависимо: сизиф такой, каким его делают люди -- и от людей ожидают уровня, как-то перекликающегося с тем, что уже в сизифе (желательно "на повышение", а не "вниз"). Мне вот кажется, что от Романа как полноправного участника команды сизиф потихоньку начнёт скорее выигрывать, чем проигрывать; может, глянешь ещё раз что-нибудь из уже освоенного и сделанного им да примешь решение?
Итак, подытожим мою работу за время вступления: https://packages.altlinux.org/ru/sisyphus/srpms/system-monitoring-center/ https://packages.altlinux.org/ru/sisyphus/srpms/power-profiles-daemon/ https://packages.altlinux.org/ru/sisyphus/srpms/labwc/ https://packages.altlinux.org/ru/sisyphus/srpms/slurp/ https://packages.altlinux.org/ru/sisyphus/srpms/nautilus-image-converter/ (Этот пакет не собирался в сизифе и я его исправил, заменив апстрим и обновив до последней версии, как сказал rider@, для опыта работы с чужими репозиториями) https://packages.altlinux.org/ru/sisyphus/srpms/grim/ https://packages.altlinux.org/ru/sisyphus/srpms/wofi/
одна только проблема - наличие замечаний к пакетам и несколько итераций по сборке с исправлением замечаний. продолжаем наблюдать.
Раз уж меня завалило [#320477] TESTED (try 7) udis86.git=1.7.2-alt2 ... https://git.altlinux.org/tasks/320477/gears/40/git?p=git;a=commitdiff;h=fae72c6657ddc6cd4b73ba0375b631a4631a4ba8 -Summary: Disassembler library for the x86 and x86-64, development files +Summary: Disassembler library for the x86 and x86-64, development files https://git.altlinux.org/tasks/320477/gears/220/git?p=git;a=commitdiff;h=f8301e8743d825414a5192d089a675eba0f08a7a +BuildRequires: pkgconfig(libinput) >= 1.14.0' Мусор в конце строки. ... +%_mandir/man1/Hyprland.1* +%_mandir/man1/hyprctl.1* Можно использовать макрос %_man1dir
(Ответ для Andrew Vasilyev на комментарий #57) > +BuildRequires: pkgconfig(libinput) >= 1.14.0' > > Мусор в конце строки. > ... > +%_mandir/man1/Hyprland.1* > +%_mandir/man1/hyprctl.1* > > Можно использовать макрос %_man1dir исправлю в ближайшее время спасибо!
(Ответ для Andrew Vasilyev на комментарий #57) > Раз уж меня завалило [#320477] TESTED (try 7) udis86.git=1.7.2-alt2 ... Извините. Я не знал, что приходят письма каждый раз. P.S. Может можно сделать что-то, чтобы не беспокоить человека при каждой попытке сборки?
(Ответ для Roman Alifanov на комментарий #59) > P.S. Может можно сделать что-то, чтобы не беспокоить человека при каждой > попытке сборки? К сожалению, оно шлёт <s>кому попало</s> последнему из %changelog, а я не добавил NMU :( Кстати, при FAILED не шлёт :-)
(Ответ для Andrew Vasilyev на комментарий #60) > К сожалению, оно шлёт <s>кому попало</s> последнему из %changelog, > а я не добавил NMU :( Кстати, при FAILED не шлёт :-) Тогда, наверное, постараюсь минимизировать попытки :)
(In reply to Andrew Vasilyev from comment #60) > К сожалению, оно шлёт <s>кому попало</s> последнему из %changelog, > а я не добавил NMU :( Кстати, при FAILED не шлёт :-) Нет, оно шлёт тем, кто упомянут в ACL, а ты в этом ACL лидер. %changeog никак не влияет на то, кому отправляются письма.
Собрал наконец давно желанный оконный менеджер!: https://packages.altlinux.org/ru/sisyphus/srpms/hyprland/2938507130686813371 (там я пропатчил meson.build файлы для нативного udis86, а не из сабмодуля) Для него надо было пропатчить https://packages.altlinux.org/ru/sisyphus/srpms/udis86/ , для pkgconfig файла, чтобы meson видел этот пакет. Еще нужен был пакет https://packages.altlinux.org/ru/sisyphus/srpms/libdisplay-info/ , с которым я немного опоздал и, к сожалению, он был собран не по https://www.altlinux.org/Shared_Libs_Policy , как у меня
https://packages.altlinux.org/ru/tasks/321866/ Обновил libopencv в сизиф до версии 4.7.0 по совету rider@
(Ответ для Roman Alifanov на комментарий #64) > https://packages.altlinux.org/ru/tasks/321866/ > Обновил libopencv в сизиф до версии 4.7.0 по совету rider@ несмотря на то, что это задание не провалилось в репозиторий из-за python-3.11, я считаю что кандидат готов к участию в team при условии дальнейшего review изменений более опытными участниками. Кандидат обещает отправлять свои пакеты в репозиторий после процедуры review и я готов и дальше смотреть на его пакеты.
Антон, спасибо!
(Ответ для Roman Alifanov на комментарий #61) > > Кстати, при FAILED не шлёт :-) > Тогда, наверное, постараюсь минимизировать попытки :) Думаю, лучше доводить до работающего результата сборки у себя поместно -- затем уж стоит отправить на сборочницу (порой нарушаю это своё правило и изредка на этом "приплываю", когда разваливается не на каком armh, а на том же x86_64 или e2kv6, который под руками). При желании избежать спама добавил бы или в конец %install что-нить вроде exit 1, или в %files какое-нибудь /404; сам так не делаю, но если бы всеми силами старался избежать преждевременных уведомлений, то мог бы и попытаться.
(In reply to Anton Farygin from comment #65) > Кандидат обещает отправлять свои пакеты в репозиторий после процедуры review > и я готов и дальше смотреть на его пакеты. Поскольку это не значит, что кандидат готов к самостоятельной сборке в Сизиф, так что я думаю, что это как раз полностью описывает состояние 4.2 и нет смысла продвигаться дальше пока это не изменится. Я проходя мимо посмотрел на пару пакетов и у меня есть несколько замечаний: * У большинства файлов в конце "\ No newline at end of file", а в некоторых, наоборот, "new blank line at EOF", очень неаккуратно, за такими вещами лучше следить, с этим в том числе помогает pre-commit hook в git. * rm -rf в спеке совершенно излишне, всегда должно быть достаточно rm -r. * В конце предложений в %description должны быть точки. Точки не ставятся в Summary: и в первой строчке commit-message (потому что это ещё и email subject), а во всех остальных случаях в конце предложений ставятся точки.
Антон, вижу в начале рецензирования замечания вида "Не указывать VCS, если есть URL", "Не указывать Packager". Наверное, они давно учтены. Какие сейчас замечания, мешающие пройти Join? Прошу писать более формально для секретаря, он не понимает сложных конструкций, на каждом шаге нужно просто писать «да» или «нет». Настолько я понял ревью Глеба, сейчас замечания достаточно весомы: последняя строка файла неправильно оформлена. Есть ли что-то, относящееся к навыкам мантейнера? «Цель в том, чтобы вы научились собирать пакеты соответствующие ожиданиям» Чьим ожиданиям? Тут проглядывает лукавство формулировки. Для меня это выглядит, что вы выдаёте свои ожидания за общие. Потому что никакого консенсуса нет. Хочу обратить внимание, что тот уровень, который вы ждёте, приобретается в течение долгой работы с многими пакетами, для этого необходимо установление внутренней обратной связи у человека, а не работа по замечаниям.
Я повторю ещё раз свои слова: ментейнер освоил все наши технологии и способы ведения репозиториев, но делает ошибки при сборке или обновлении пакетов. Поэтому его нужно перевести на стадию 5.0, но договориться с ним о дальнейшем review изменений. Замечания Глеба в основном к оформлению изменений, я мало к этому придираюсь, хотя видимо стоило бы. Ну и раз глеб перевёл на 4.2, то видимо мы ждём дальнейших изменений от кандидата и делаем попытку перейти на 5.0 снова. Т.е. - Виталик, это уже не я перевёл его обратно на 4.2, ко мне вопросы не имеют никакого смысла ;)
(Ответ для Gleb F-Malinovskiy на комментарий #68) > * В конце предложений в %description должны быть точки. Точки не ставятся в > Summary: и в первой строчке commit-message (потому что это ещё и email > subject), а во всех остальных случаях в конце предложений ставятся точки. Нигде, кстати, не описано -- а применительно к %changelog ещё и спорно (полноразмерные предложения там встретишь отнюдь не всегда). Такие штуки, как и требования/пожелания/ожидания к логину кандидата, куда-нить бы да изложить со ссылкой из окрестностей [[join]]...
(Ответ для Vitaly Lipatov на комментарий #69) > «Цель в том, чтобы вы научились собирать пакеты соответствующие ожиданиям» > Чьим ожиданиям? Тут проглядывает лукавство формулировки. Для меня это > выглядит, что вы выдаёте свои ожидания за общие. Потому что никакого > консенсуса нет. Я к тому и докопался, что планка задирается куда-то в такие небеса, что не только я, а и vsu@ бы, поди, с такой в своё время посмотрел, махнул рукой и пошёл дальше (а ott@ и пошёл -- уже после join). С другой стороны, что-то вроде дебиановских DM/DD у нас и появилось после введения шага "может собирать, но коммитить только через отсмотр другими". Для некоторых случаев вроде группы студентов со старшим ответственным (который может и не пройти за такой порог, если не сочтёт это интересным), наработки которых в исполнении коего сможет посмотреть кто-то ещё -- такой вариант может и подойти. А так вспоминается разбор управленческой "игры" "bring me a rock" у Johanna Rothman, оно же "иди туда, не знаю куда, принеси то, не знаю что".
(Ответ для Anton Farygin на комментарий #70) ... > Т.е. - Виталик, это уже не я перевёл его обратно на 4.2, ко мне вопросы не > имеют никакого смысла ;) Я понял так, что ты, как рецензент, должен был либо одобрить, либо не одобрить. Одобрение не выдано, и кандидата откатили. Решение принято на основе твоей рецензии. Замечания Глеба (которые он делал не как секретарь) направлены на улучшение внимательности кандидата к таким мелким деталям, но не имеют отношения к прохождению в Тим.
ну давай ещё раз попробуем: Кандидат готов к работе над пакетами, но при условии что он продолжает свои пакеты показывать на review ещё какое-то время. Я считаю это самостоятельной работой, т.к. консультироваться ему надо только если или новые пакеты, или те, которые кандидат до этого не собирал.
(Ответ для Anton Farygin на комментарий #65) > (Ответ для Roman Alifanov на комментарий #64) > > https://packages.altlinux.org/ru/tasks/321866/ > > Обновил libopencv в сизиф до версии 4.7.0 по совету rider@ > > несмотря на то, что это задание не провалилось в репозиторий из-за > python-3.11, я считаю что кандидат готов к участию в team при условии > дальнейшего review изменений более опытными участниками. Уже в сизифе :)
Адрес подписан на devel@. Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства!
Ура!! Благодарю всех участников процесса :-)
