Bug 53275

Created attachment 17851 [details]
Публичный GPG-ключ

В соответствии с рекомендациями по оформлению заявки, прилагаю к данному сообщению свой публичный SSH-ключ

Created attachment 17852 [details]
Публичный SSH-ключ

В соответствии с рекомендациями по оформлению заявки, прилагаю к данному сообщению свой публичный SSH-ключ

(In reply to Alex from comment #0)
> Псевдоним: paladindev
> Почта: Alexander Davydzik <paladindev@altlinux.org>
> Адрес пересылки почты: paladingames1@gmail.com
> Имя ментора: Антон Мидюков
> Почта ментора: <antohami@altlinux.org>
> 
> Цель: Научиться собирать и сопровождать пакеты отсносящиеся к GNOME и
> использующие его технологический стек.

Подтверждаю.
Ключи выглядят нормально.
Кандидат готов начать вступление.
Прошу предоставить кандидату доступ к git.alt.

(In reply to Alex from comment #1)
> Created attachment 17851 [details]
> Публичный GPG-ключ
Выложите, пожалуйста, ключ так, чтобы вместо CRLF были только LF.

Created attachment 17868 [details]
Публичный GPG-ключ

Изменены окончания строк на LF

ssh ключ на gitery.alt зарегистрирован.
Адрес для пересылки создан.

T/J/S -> 2.3.

У кандидата есть пакет для сборки [1] (программа собственной разработки для Рабочей станции). Поэтому прошу предоставить кандидату доступ к сборочнице.

1. https://git.altlinux.org/people/paladindev/packages/?p=alt-tour.git;a=summary

ssh ключ на gyle.alt зарегистрирован.
Пакет alt-gpgkeys обновлён.
Адрес подписан на devel@.

T/J/S -> 3.6.

Считаю, что кандидат освоил сборку пакетов и работу со сборочницей на достаточном уровне и готов самостоятельно собирать пакеты.
Прошу назначить кандидату рецензента.

Призван рецензент (arseny@) для независимой оценки готовности кандидата.

T/J/S -> 4.2.

(In reply to Gleb F-Malinovskiy from comment #10)
> Призван рецензент (arseny@) для независимой оценки готовности кандидата.
> 
> T/J/S -> 4.2.
ACK.

Антон, Александр, пытались ли вы собрать что-нибудь, кроме alt-tour собственной разработки? Хотя бы пакета два, если они собраны без ошибок и если мы в процессе ревью убедились, что кандидат понимает, что делали.

(In reply to Arseny Maslennikov from comment #12)
> Антон, Александр, пытались ли вы собрать что-нибудь, кроме alt-tour
> собственной разработки? Хотя бы пакета два, если они собраны без ошибок и
> если мы в процессе ревью убедились, что кандидат понимает, что делает.
Т. е. пакет, где разработчик — кто-то ещё, а мейнтейнер — наш кандидат. :)

(In reply to Arseny Maslennikov from comment #13)
> (In reply to Arseny Maslennikov from comment #12)
> > Антон, Александр, пытались ли вы собрать что-нибудь, кроме alt-tour
> > собственной разработки? Хотя бы пакета два, если они собраны без ошибок и
> > если мы в процессе ревью убедились, что кандидат понимает, что делает.
> Т. е. пакет, где разработчик — кто-то ещё, а мейнтейнер — наш кандидат. :)

Да. Пакеты: packet, wev, manuals, dune3d, gnome-shell-extension-color-picker, gnome-shell-extension-ui-tune

Я собирался начать смотреть заявленное, но не успел ещё, под руку попался проект Tuner, который упаковывал тоже Александр.

В спеке этого пакета:
  94 %build
  95 %meson \
  96     %{subst_enable_meson_bool docs docs}
  97 %nil
  98 %meson_build
  99 

Вопрос _к кандидату_: Где ошибка?

(In reply to Arseny Maslennikov from comment #15)
> Я собирался начать смотреть заявленное, но не успел ещё, под руку попался
> проект Tuner, который упаковывал тоже Александр.
> 
> В спеке этого пакета:
>   94 %build
>   95 %meson \
>   96     %{subst_enable_meson_bool docs docs}
>   97 %nil
>   98 %meson_build
>   99 
> 
> Вопрос _к кандидату_: Где ошибка?

Ошибки там нет, т.к. пакет собирается успешно. В теории можно было бы убрать перенос и %nil, но в текущем виде выглядит лучше на мой личный взгляд.

(In reply to Alex from comment #16)
> (In reply to Arseny Maslennikov from comment #15)
> > Я собирался начать смотреть заявленное, но не успел ещё, под руку попался
> > проект Tuner, который упаковывал тоже Александр.
> > 
> > В спеке этого пакета:
> >   94 %build
> >   95 %meson \
> >   96     %{subst_enable_meson_bool docs docs}
> >   97 %nil
> >   98 %meson_build
> >   99 
> > 
> > Вопрос _к кандидату_: Где ошибка?
> 
> Ошибки там нет, т.к. пакет собирается успешно. В теории можно было бы убрать
> перенос и %nil, но в текущем виде выглядит лучше на мой личный взгляд.
Благодарю за ответ.
Я намеренно так сформулировал вопрос; здесь не ошибка в получившемся пакете, а проблема уровнем выше — в неясном замысле автора.
У вас тут как будто заявка на идиоматический способ записи длинной команды по аргументу на строку. Понятно, почему он удобен: например, становится легко оборачивать строки в %if/%endif, а также при добавлении и удалении опций возникают менее шумные, более читаемые диффы. Мне тоже так нравится. Но он не получился, здесь повешено чеховское ружьё, которое при добавлении новых опций выстрелит в ногу, и я не могу на ревью не обратить на это внимание.

Мне стало интересно, понимаете ли вы, как устроена эта конструкция, и, если да, почему вы решили написать эти строки именно так.

А так да — формально эта секция спека корректна, пакет действительно смог собраться, не приобрёл какие-то ухудшающие свойства, но дело вообще не в этом. :)

(In reply to Alex from comment #16)
> (In reply to Arseny Maslennikov from comment #15)
> > Я собирался начать смотреть заявленное, но не успел ещё, под руку попался
> > проект Tuner, который упаковывал тоже Александр.
> > 
> > В спеке этого пакета:
> >   94 %build
> >   95 %meson \
> >   96     %{subst_enable_meson_bool docs docs}
> >   97 %nil
> >   98 %meson_build
> >   99 
> > 
> > Вопрос _к кандидату_: Где ошибка?
> Ошибки там нет, т.к. пакет собирается успешно. В теории можно было бы убрать
> перенос и %nil, но в текущем виде выглядит лучше на мой личный взгляд.
Задам тот же вопрос в более наводящей форме. Какую роль там исполняет %nil, и чего не хватает, чтобы конструкция приобрела смысл?

(In reply to Arseny Maslennikov from comment #18)
> (In reply to Alex from comment #16)
> > (In reply to Arseny Maslennikov from comment #15)
> > > Я собирался начать смотреть заявленное, но не успел ещё, под руку попался
> > > проект Tuner, который упаковывал тоже Александр.
> > > 
> > > В спеке этого пакета:
> > >   94 %build
> > >   95 %meson \
> > >   96     %{subst_enable_meson_bool docs docs}
> > >   97 %nil
> > >   98 %meson_build
> > >   99 
> > > 
> > > Вопрос _к кандидату_: Где ошибка?
> > Ошибки там нет, т.к. пакет собирается успешно. В теории можно было бы убрать
> > перенос и %nil, но в текущем виде выглядит лучше на мой личный взгляд.
> Задам тот же вопрос в более наводящей форме. Какую роль там исполняет %nil,
> и чего не хватает, чтобы конструкция приобрела смысл?

%nil визуально показывает конец секции с вызовом meson setup. Можно было бы добавить "\" в конец 96 строки чтобы при слепом копипасте сборка не провалилась.

(In reply to Alex from comment #19)
> (In reply to Arseny Maslennikov from comment #18)
> > (In reply to Alex from comment #16)
> > > (In reply to Arseny Maslennikov from comment #15)
> > > > Я собирался начать смотреть заявленное, но не успел ещё, под руку попался
> > > > проект Tuner, который упаковывал тоже Александр.
> > > > 
> > > > В спеке этого пакета:
> > > >   94 %build
> > > >   95 %meson \
> > > >   96     %{subst_enable_meson_bool docs docs}
> > > >   97 %nil
> > > >   98 %meson_build
> > > >   99 
> > > > 
> > > > Вопрос _к кандидату_: Какую роль там исполняет %nil,
> > > > и чего не хватает, чтобы конструкция приобрела смысл?
> %nil визуально показывает конец секции с вызовом meson setup.
Не только визуально, но и синтаксически значимо, эта пустая строка после макрообработки _должна_ там быть, иначе к команде meson setup будет приклеено что-то со следующей строки.
> Можно было бы
> добавить "\" в конец 96 строки чтобы при слепом копипасте сборка не
> провалилась.
Не можно, а нужно! :)
Немаловажно, что, если после неё дописать что-то ещё в новую строку, в диффе от прежнего варианта к новому не будет замены 96 строки на почти идентичную, но в конце '\'.
Настоятельно рекомендую это сделать при следующем обновлении пакета (т. е. делать новый релиз ради такого изменения не обязательно, можете сделать, закоммитить и забыть до нового релиза).

В общем, ответ правильный :)
Либо вы уверены, что 96 строка последняя (и %nil становится ненужным), либо же нет и %nil актуален, но все переносы строк нужно эскейпить. Вы как мейнтейнер выбрали вариант и обосновали его, что и нужно было.

Будем смотреть другие пакеты.

Куда ни глянь, везде заполнены .gear/upstream/remotes; это хорошо. :)

packet:

Программа install(1), если её применяют не к чему-то исполняемому, требует при себе -m644 по историческим причинам (её придумали, чтобы ставить бинарники на место в ситуации, где cp(1) не справляется из-за ETXTBSY, а более широким градусом применения она обросла уже после).

Вот тут его нет:
  47 install -vD %SOURCE2 .cargo/config.toml
Увидел это в packet и где-то ещё; хорошо бы поправить при следующем обновлении.

Судя по всему, python-расширения для наутилуса все так и ставят: сам модуль и __pycache__. Интересно, не нужно ли их пересобирать при мажорном обновлении питона? (Это вопрос в сторону.)

К dune3d и manuals у меня вопросов нет.
Хотел предложить обновить manuals, там опубликовали 48.1, но, судя по всему, обновлять пакеты вы умеете. :)

wev:

Интересный пакет.

>   30 %install
>   31 %makeinstall_std PREFIX=/usr
>   32 
У нас есть макрос %_prefix, ему тут самое место.

>   27 %build
>   28 %make
>   29 
Вопрос к Алексу: почему между %make и %make_build сделан именно такой выбор?

Ещё обращаю внимание, что у Drew Devault последний коммит 3 месяца назад, а у Hans de Goede 4 года назад. Может, апстрим не там?
Правда, в обоих репозиториях есть уникальные коммиты, возможно, их надо притащить в любом случае.

color-picker:

По мелочи: в выражениях для sed к командам можно приписывать регулярное выражение, определяющее, на каких строках эти команды проводить.
    /version:/s/47.beta/%version.beta/g
Не сужу, нужно это здесь или нет, хотел просто проинформировать.

Кроме этого, вопросов нет.

ui-tune:

Нужно ли запускать make schemas во время сборки? Мы тут несколько месяцев назад с qualimock@ выяснили, что не только не нужно, но и не имеет смысла. Просто упаковываете схему, её подготовит специальный filetrigger после установки пакета (вызовет compile-schemas).

Мелкий nitpick: в списке файлов после %extdir/%uuid окончание "/" здесь вовсе не обязательно.

В общем, жду ответов на вопросы, жду исправления замечаний в пакетах, которые успели обновиться до текущего момента, отдельно хотел бы увидеть, как ув. кандидат рассмотрит замечание к ui-tune (иных шансов для нетривиальных действий тут нет).

wev:
Сменил апстрим на оригинального автора, использовал %_prefix и %make_build.
Использовал его из-за копипаста из другого похожего пакета.

ui-tune:
Исправил пути установки для locales и schemas.

(In reply to Alex from comment #25)
> wev:
> Сменил апстрим на оригинального автора, использовал %_prefix и %make_build.
> Использовал его из-за копипаста из другого похожего пакета.
Ага, OK. Такое бывает, смотрите внимательнее. :)

Конкретно здесь 5,5 исходников на сях, может, разницы и нет, но лучше писать общий вариант.

Я смотрю, вы убрали коммит про wl-протокол wl_seat версии 5, гномеры уже поддерживают wl_seat 10, видимо, правильно сделали. :)

> ui-tune:
> Исправил пути установки для locales и schemas.
OK.

(In reply to Arseny Maslennikov from comment #24)
> В общем, <...>, жду исправления замечаний в пакетах,
> которые успели обновиться до текущего момента
Осталось только одно такое замечание: про packet.
Он успел обновиться, но замечание про него у меня не касалось результирующего пакета (.cargo/config.toml не упаковывается в пакет, это лишь вопрос чистоплотности).

(In reply to Alex from comment #0)
> Псевдоним: paladindev
> Цель: Научиться собирать и сопровождать пакеты отсносящиеся к GNOME и
> использующие его технологический стек.
Заявленной цели Алекс достиг и (как минимум) немножко её перерос. Думаю, ему можно идти дальше.

Пользователь добавлен в группу мейнтейнеров.

Желаю удачного мейнтейнерства!