Created attachment 12735 [details] Add GPG public key Имя пользователя: qualimock Почта для пересылки: qualimock@yandex.ru Намерения: хочу научиться собирать пакеты Имя ментора: ancieg Подписка: ancieg@altlinux.org
Created attachment 12736 [details] Add SSH public key
(Ответ для QualiMock на комментарий #0) > Имя ментора: ancieg Ок, берусь. > Подписка: ancieg@altlinux.org Но в подписку не добавил :)
Ключи в порядке.
Актуально ли ещё?
(In reply to Gleb F-Malinovskiy from comment #4) > Актуально ли ещё? Да, актуально, но пока времени нет
В общем, время появилось, собрал один пакет на локальной машине. Желаю вернуться к процедуре Join'а.
Прошу зарегистрировать ключи на gitery и выдать доступ к gyle.
ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3.
(In reply to Anton Zhukharev from comment #7) > Прошу зарегистрировать ключи на gitery и выдать доступ к gyle. Прошу выдать доступ к gyle.
ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. Адрес подписан на devel@. T/J/S -> 3.6.
Собраны пакеты: cassette: https://packages.altlinux.org/en/sisyphus/srpms/cassette/ python3-module-aria2p: https://packages.altlinux.org/en/sisyphus/srpms/python3-module-aria2p/ nautilus-backspace: https://packages.altlinux.org/en/sisyphus/srpms/nautilus-backspace/ screenshot: https://packages.altlinux.org/en/sisyphus/srpms/screenshot/ opendoas: https://packages.altlinux.org/en/sisyphus/srpms/opendoas/
Я думаю, что можно пробовать двигаться дальше.
Призван рецензент (arseny@) для независимой оценки готовности кандидата. T/J/S -> 4.2.
(In reply to Gleb F-Malinovskiy from comment #13) > Призван рецензент (arseny@) для независимой оценки готовности кандидата. > > T/J/S -> 4.2. ACK. Взгляну на выходных.
Created attachment 17774 [details] nautilus-backspace-allow-override-datadir.diff
Недавно взглянул. Кое-что я уже посмотрел, но ответы пока в столе и ещё нуждаются в редактуре. Скоро опубликую их пачкой. Немного о nautilus-backspace. Нижеследующее почти не касается нашего с вами пакета, но тем не менее выступает хорошим упражнением для среднестатистического мейнтейнера и хорошим тоном для благосклонного апстрима. Если взглянуть на makefile апстрима, то видно, что апстрим на момент авторства немного не умел писать фазу `make install` для своего поделия. Позаботился о цикле разработки, но не о упаковывающих мейнтейнерах. :( Хороший мейнтейнер установит правильно (как вы и сделали в спеке), а отличный ещё и заапстримит правильную установку, благо makefile несложный, а патч небольшой. Предлагаю ув. кандидату это сделать; интуиция мне подсказывает, что апстрим будет договороспособен. :) Они там сверяют UID 0; понятно, что из `geteuid() == 0` никак не следует префикс, куда нужно ставить файлы, но и понятно, что хотелось поддерживать запуск `make install` на живой системе, где умолчания для uid 0 и != 0 _не_ неразумны и даже близки к устойчивой практике. В текущем виде такой код показывает мейнтейнеру пакетов кукиш. Апстриму стоило бы: - ввести что-нибудь вроде `datadir = /usr/share` в самом начале файла, тем самым добавив ручку для переопределения datadir; - да-да, при вызове `make datadir=$HOME/.local/share` установка переменной в командной строке _одерживает верх_ над установкой переменной в тексте! https://www.gnu.org/software/make/manual/make.html, "Overriding Variables" То есть, неосторожному оператору очень легко сломать аккуратный Makefile неаккуратным вызовом make(1). Не баг, а фича! (впрочем, неважно) - ветку `geteuid() != 0` посвятить изменению зн. `datadir` по умолчанию. И волки будут сыты, и овцы будут целы, см. приложенный патч. - поддержать переменную DESTDIR (может как отсутствовать, так и содержать путь к каталогу; писать после обращения к ней / не требуется); - совсем дальновидно: вызывать в рецептах `$(INSTALL)` вместо явного `install`. А ещё у них `make` без аргументов командной строки будет что-то куда-то устанавливать, так как `install` — первая цель по тексту. К такому поведению жизнь пользователей make(1) не готовила, это неприятный сюрприз. :) Ну, и `.PHONY: install schemas`, конечно; ни о каких файлах по именам "install" и "schemas" речи не идёт. Патч получится порядка 14 insertions(+), 11 deletions(-). Вам останется написать в spec: %makeinstall_std datadir=%datadir Танцы с ifneq чего-то 0 вас как мейнтейнера пакета не затронут. Я не помню, пригодна ли ~/.local (согласно спецификации на неё) для того, чтобы быть префиксом (т. е. содержать всё актуальное, что бывает в /usr/local или /usr). Если да, то возможен вариант prefix = /usr datadir = $(prefix)/share и далее аналогично. Но, с учётом того, что проект маленький, тут могут быть разные решения приняты.
Общее замечание. Если апстрим сопровождает свой проект в гите, делает релизы и вешает на релизные ревизии подписанные теги, то их можно тоже запушить на gitery. Тогда при сборке пакетного тега, от которого можно до них дойти по цепочке коммитов, они попадут и на git.a.o/gears, что удобно читателям. gyle так делает много лет, но я об этом узнал только в прошлом году — т. е. менторы об этом вообще не говорят. Надо эту практику по возможности популяризировать. :)
nautilus-backspace: В спеке нет: %define _unpackaged_files_terminate_build 1 Почему? Вопрос и на понимание, и из моего личного любопытства (я никогда не собирал всякий гном). Нужно ли glib-compile-schemas вызывать в %post пакета? Почему нельзя в файлтриггере?
cassette: объективно придраться не к чему. :)
python3-module-aria2p: Вопрос к кандидату: я вижу, что в -alt2 добавлена явная зависимость на aria2. Пожалуйста, обоснуйте это добавление. Кроме этого, нет вопросов.
org.adishatz.Screenshot: А ему точно нужны и meson, и cmake в качестве BR? Кроме этого, нет вопросов.
opendoas: Пакет в целом сложный, с существенной долей системной интеграции. Значит, и поговорить есть о чём! > %description -l ru_RU.UTF-8 > doas — это минимальная замена почтенного sudo. Первоначально она была написана > Тедом Унангстом из проекта OpenBSD, чтобы обеспечить 95%% функций sudo > с частью кодовой базы > обеспечить ... с частью кодовой базы Плохой и корявый перевод строго хуже отсутствия перевода. Надо либо написать своими словами, либо вообще забить на перевод. > Summary(ru_RU.UTF-8): Портативная версия команды doas из OpenBSD Здесь слово portable употреблено в особом смысле, который ему придаёт сообщество OpenBSD: имеется в виду вариант программы, совместимый не только с OpenBSD. В английском языке словосоч. "portable program" имеет два устойчивых смысла: * "работающий везде", толстый исполнимый (в мире windows — бинарный) дистрибутив приложения, не требующий установки в окружение (в т. ч. упаковки в альт для будущей установки); * более уместное значение из литературы вокруг POSIX, языка Си и комплектного библиотечного окружения: программа, которую можно без изменений собрать под произвольную машину и ОС. Эти два варианта — омонимы; второй из них — это "портируемая" программа, которую можно куда-то портировать, to port, например, под линукс. Проект OpenBSD употребляет "portable", ссылаясь на второй вариант употребления (у них portable — программа, совместимая не только с OpenBSD). Я бы в свете всего этого, если уж заниматься переводом этих описаний, вообще избежал намёков на то, что кто-то что-то куда-то портирует. Мы упаковываем вариант opendoas, совместимый с нами (другой упаковывать в альт смысла мало); об этом надо и написать. Навроде "Команда doas из OpenBSD, портированная для Linux". Конечно, ни в коем разе не навязываю стиль и выбор слов. :) > 50 mkdir -p %buildroot%_sysconfdir > 51 cat > %buildroot%_sysconfdir/doas.conf << EOF > 52 # Allow wheel by default > 53 permit :wheel > 54 EOF 1) Для других повышалок привилегий у нас предусмотрены control(8) facilities. Предлагаю взглянуть на семантику и варианты состояний у sudo и предоставить такие же варианты для opendoas (соответственно, упаковать эти контролы в пакет). 2) Если комментарии в конфиге выступают в том числе документацией для пользователя, то, IMHO, прилично писать такие заметки как документацию — книжным стилем; т. е. заканчивать предложения точкой и т. п. > 42 %build > 43 # Non standard build script > 44 ./configure --prefix=%prefix --with-timestamp --with-pam > 45 export CFLAGS="%optflags" > 46 %make_build Что означает запись non-standard build script? Nit: "/bin:/sbin:" в начале safepath в файле doas.c стоило бы, на мой вкус, выпатчить; в альте это симлинки на другие каталоги, входящие в safepath. Впрочем, не настаиваю.
(In reply to Arseny Maslennikov from comment #20) > python3-module-aria2p: > > Вопрос к кандидату: > я вижу, что в -alt2 добавлена явная зависимость на aria2. Пожалуйста, > обоснуйте это добавление. > > Кроме этого, нет вопросов. aria2p - это утилита, работающая с aria2, автогенератор не находит такие зависимости, поэтому пришлось указать явно. (In reply to Arseny Maslennikov from comment #21) > org.adishatz.Screenshot: > > А ему точно нужны и meson, и cmake в качестве BR? > > Кроме этого, нет вопросов. cmake был добавлен, поскольку он потребовался в процессе сборки. Однако, потом оказалось, что все собирается и без него. В https://packages.altlinux.org/en/tasks/379880/ я его убрал из BR. С nautilus-backspace и opendoas в ближайшее время разберусь.
В ближайшее время не получилось разобраться, прошу прощения за долгую задержку. nautulus-backspace: Поправил Makefile по вашим правкам и договорился с апстримом, меня добавили в команду разработки. glib-compile-shemas вообще не надо вызывать, убрал %post, поскольку для gsettings уже есть файлтриггер. Обновил в апстриме Makefile, пакет уже в Сизифе. https://packages.altlinux.org/en/tasks/386433/ opendoas: Убрал переводы, добавил control facilities, убрал "/bin:/sbin:" из safepath. Non-standard build script написал, потому что configure в opendoas самодельный и не работает с GNU Autotools. Исправил комментарий, пояснил конкретнее. Opendoas со всеми правками тоже уже в Сизифе. https://packages.altlinux.org/en/tasks/390571/
(In reply to Alexey Volkov from comment #24) > nautulus-backspace: > Поправил Makefile по вашим правкам и договорился с апстримом, меня добавили > в команду разработки. glib-compile-schemas вообще не надо вызывать, убрал > %post, поскольку для gsettings уже есть файлтриггер. Обновил в апстриме > Makefile, пакет уже в Сизифе. https://packages.altlinux.org/en/tasks/386433/ Хорошо. > opendoas: > Non-standard build script написал, потому что configure в opendoas > самодельный и не работает с GNU Autotools. Исправил комментарий, пояснил > конкретнее. Новый комментарий лучше, да. > Убрал переводы, добавил control facilities, убрал "/bin:/sbin:" из safepath. > Opendoas со всеми правками тоже уже в Сизифе. > https://packages.altlinux.org/en/tasks/390571/ Годится! По этим двум пакетам все вопросы тоже сняты.
(In reply to Alexey Volkov from comment #23) > (In reply to Arseny Maslennikov from comment #20) > > python3-module-aria2p: > > > > Вопрос к кандидату: > > я вижу, что в -alt2 добавлена явная зависимость на aria2. Пожалуйста, > > обоснуйте это добавление. > > aria2p - это утилита, работающая с aria2, автогенератор не находит такие > зависимости, поэтому пришлось указать явно. А можно ли применять aria2p в случае, где управляемая aria2 на другой машине, а связь между ними по сети? Или только в рамках одной машины? Если можно по сети, то на управляющей машине сама программа aria2 не обязательна, и, я считаю, зависимость ставить не стоит. Это как pulseaudio и libpulse0, только помягче. С libpulse0 много чего транзитивно собрано, и тащить в качестве зависимости pulseaudio-daemon излишне (он ещё, не ровён час, и автозапускаться будет даже на машинах, где звук настроен без его участия!)
(In reply to Arseny Maslennikov from comment #26) > А можно ли применять aria2p в случае, где управляемая aria2 на другой > машине, а связь между ними по сети? Или только в рамках одной машины? > Если можно по сети, то на управляющей машине сама программа aria2 не > обязательна, и, я считаю, зависимость ставить не стоит. Посмотрел, да, aria2 может быть на удаленном сервере. Убрал из зависимостей и обновил aria2p. https://packages.altlinux.org/en/tasks/390712/
(In reply to Alexey Volkov from comment #27) > (In reply to Arseny Maslennikov from comment #26) > > А можно ли применять aria2p в случае, где управляемая aria2 на другой > > машине, а связь между ними по сети? Или только в рамках одной машины? > > Если можно по сети, то на управляющей машине сама программа aria2 не > > обязательна, и, я считаю, зависимость ставить не стоит. > Посмотрел, да, aria2 может быть на удаленном сервере. Убрал из зависимостей > и обновил aria2p. https://packages.altlinux.org/en/tasks/390712/ OK, замечательно. :)
К уже собранным Алексеем пакетам у меня нет претензий. Давайте что-нибудь ещё соберём. Можете вместе с ментором или сами выбрать какой-нибудь проект, который не гном и не модуль разработки (т. е. самостоятельная программа либо бинарная библиотека). Если выбрать трудно, то я предлагаю найденную в багзилле заявку. https://bugzilla.altlinux.org/49791 Выглядит не кошмарно сложно, чай, не bun. Подобрал вот отсюда https://bugzilla.altlinux.org/buglist.cgi?bug_status=NEW&bug_status=REOPENED&order=Importance&product=New%2Fproposed%20packages
Я бы очень не хотел, чтобы процесс тормозился из-за меня. :) Плагин для OBS, что я предлагал выше, на тот момент был слишком сложен для начинающего мейнтейнера; он, по крайней мере, требует onnxruntime, который довольно сложно хорошо упаковать и которого в сизифе не было; теперь (в начальном виде) есть. (Patches welcome от любителей видеокарт BTW) Не исключено, что это может быть не единственная проблема со сборкой того плагина. В любом случае, не обязательно брать именно его. Но если интересна такая категория ПО — то вперёд! :)
Алексей, если у вас есть затруднение найти проект для упаковки, то можете взять какое-нибудь своё TESTED/FAILED задание, которое я ещё не видел и в котором есть пакеты, удовлетворяющие ограничениям из comment 29. Главное, пользуясь полученным опытом, довести пакеты до ума без подсказок.
Алексей, как у вас дела? https://altlinux.org/Team/Join/Review_Team Мы в качестве эксперимента учредили самоуправление в команде ревьюеров, в надежде, что это ускорит прохождение застрявших на 4.0 в тиму. Теперь у нас рецензенты самоназначаются. Моё дело — пингануть всех кандидатов у меня на рецензии, чтобы понять, могу ли я брать ещё или нет. Вот я и спрашиваю. :)
Арсений, извиняюсь за длительное молчание! Изначально я искал пакет, подходящий под условия, но затем сильно погрузился в рабочие задачи. Я подготовил инструмент для работы с данными OpenStreetMap, osmium вместе с библиотекой: https://packages.altlinux.org/tasks/381197/
(In reply to Alexey Volkov from comment #33) > Арсений, извиняюсь за длительное молчание! Да ничего такого, каждый в своём темпе; я совсем не надавливаю. :) > Изначально я искал пакет, > подходящий под условия, но затем сильно погрузился в рабочие задачи. > Я подготовил инструмент для работы с данными OpenStreetMap, osmium вместе с > библиотекой: > https://packages.altlinux.org/tasks/381197/ Спасибо, годится; взгляну на этой неделе.
(In reply to Alexey Volkov from comment #33) > Арсений, извиняюсь за длительное молчание! Изначально я искал пакет, > подходящий под условия, но затем сильно погрузился в рабочие задачи. > > Я подготовил инструмент для работы с данными OpenStreetMap, osmium вместе с > библиотекой: > https://packages.altlinux.org/tasks/381197/ Я сначала хотел только упомянуть, что %description у корневого пакета и у подпакета не стоит делать одинаковым. А они оказались разные... :D Пробовали ли вы взглянуть на получающиеся пакеты через, например, rpm -qi? rpm -qip protozero-devel-1.8.1-alt1.x86_64.rpm rpm -qip libosmium-devel-2.23.1-alt1.x86_64.rpm Как думаете, это OK или нет? (Ещё интересно, смотрели ли туда те, кто approve на пакет поставил.) Это в двух библиотечных пакетах так, что говорит о том, что это не одноразовый эксцесс, а вы так системно пишете. :) Всё остальное с этими тремя пакетами OK. Тем не менее, следующий дубль.
(In reply to Arseny Maslennikov from comment #35) > (In reply to Alexey Volkov from comment #33) > > Арсений, извиняюсь за длительное молчание! Изначально я искал пакет, > > подходящий под условия, но затем сильно погрузился в рабочие задачи. > > > > Я подготовил инструмент для работы с данными OpenStreetMap, osmium вместе с > > библиотекой: > > https://packages.altlinux.org/tasks/381197/ > Я сначала хотел только упомянуть, что %description у корневого пакета и у > подпакета не стоит делать одинаковым. Ну т. е. я обычно общую пасту в корневом и в подпакетах повторяю, но к подпакетам добавляю что-то отличительное. %define common_description <text wall> %description %common_description %description devel %common_description This package contains development headers for the NNN library. %description -n lib%name %common_description This package contains the NNN shared library. %description %tools %common_description This package contains example tools for NNN. %description yyy %common_description This package contains YYY integration for the NNN. и т. п.
Короче, пробуем ещё. > Давайте что-нибудь ещё соберём. Можете вместе с ментором или сами > выбрать какой-нибудь проект, который не гном и не модуль разработки > (т. е. самостоятельная программа либо бинарная библиотека). > <...> можете > взять какое-нибудь своё TESTED/FAILED задание, которое я ещё не видел и в > котором есть пакеты, удовлетворяющие ограничениям из comment 29. Главное, > пользуясь полученным опытом, довести пакеты до ума без подсказок.
