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. Главное,
> пользуясь полученным опытом, довести пакеты до ума без подсказок.