Bug 39887

Created attachment 9275 [details]
id_rsa.pub

В качестве менторов -- bircoph@ (основной, если согласится) и я.

От себя бы хотел добавить свой проект (https://github.com/ilyakurdyukov/jpeg-quantsmooth), далее только добавление и обновление патчей с оптимизацией для Эльбруса (пока скинуты сюда https://github.com/ilyakurdyukov/e2k-ports), другие архитектуры ломать не должны.

В идеале добиться добавления этих патчей в официальные репозитории, тогда в Альте уже будут не нужны.

Created attachment 9276 [details]
gpg-4096.pub

Нужно дополнить:

> www.altlinux.org/Работа_с_ключами_разработчика
> Создать новый GPG-ключ можно командой
> $ gpg --gen-key

В современной версии gpg (2.1.17 или выше), при использовании --gen-key не спрашивается тип ключа, так что мне сгенерировало дефолтный на 3072. Нужно использовать ключ --full-gen-key. Это в Альте gpg старый и знает только --gen-key, который работает как --full-gen-key в новом.

(Ответ для ilyakurdyukov на комментарий #3)
> От себя бы хотел добавить свой проект
> (https://github.com/ilyakurdyukov/jpeg-quantsmooth)
Отлично :-)

По работе над пакетом в почтовой переписке считаю, что можно переходить к п.2.

(Ответ для ilyakurdyukov на комментарий #4)
> Нужно дополнить:
> > www.altlinux.org/Работа_с_ключами_разработчика
Тут уж к принимающим (насколько понимаю, прямо сейчас это скорее ldv@),
но всяко спасибо, что сообщили о замеченном.

Created attachment 9282 [details]
jpegqs-gear.zip

Сборка пакетов jpegqs в hasher:

wget https://github.com/ilyakurdyukov/jpeg-quantsmooth/archive/refs/tags/1.20210408.tar.gz -O jpeg-quantsmooth-1.20210408.tar.gz
unzip jpegqs-gear.zip
cd jpegqs-gear
git init && git add . && git commit -m "added spec and rules"
gear-update -c ../jpeg-quantsmooth-1.20210408.tar.gz jpegqs
gear-commit -a
gear-hsh $TMP

Исходники предполагается сохранить в git.alt, чтобы не качать с гитхаба при билде.

(Ответ для ilyakurdyukov на комментарий #6)
> unzip jpegqs-gear.zip
> cd jpegqs-gear
> git init && git add . && git commit -m "added spec and rules"
Сам обычно сперва добавляю исходники, затем .gear/rules и затем спек.

> wget .../refs/tags/1.20210408.tar.gz -O jpeg-quantsmooth-1.20210408.tar.gz
> gear-update -c ../jpeg-quantsmooth-1.20210408.tar.gz jpegqs
Вот здесь всё-таки хотелось бы видеть переход от git-репозитория в github
к git-репозиторию с .gear; хотя это и не является обязательным, но устраивать вместо git pull танцы с потерей апстримной истории, являясь апстримом, как-то странно.

> gear-commit -a
> gear-hsh $TMP
У меня собралось на x86_64, e2kv4, ppc64le и aarch64.

> Исходники предполагается сохранить в git.alt, чтобы не качать с гитхаба
> при билде.
А качать при сборке и не получится ничего -- в hasher по умолчанию отключена сеть из соображений безопасности и воспроизводимости, см. тж. про share_network
в /usr/share/doc/hasher-priv-*/DESIGN

Проблемы руководства:

https://www.altlinux.org/Краткое_руководство_по_сборке_пакета

> Создайте в домашнем каталоге файл .rpmmacros (обязательна точка в начале) примерно такого содержания: 
> %_packager Vassily Poupkine <pupkin@altlinux.org>

Это неверно и вводит в заблуждение.

Должно быть что-то вроде:

Создайте в домашнем каталоге файл ~/.hasher/config примерно такого содержания: 
packager="Vassily Poupkine <pupkin@altlinux.org>"

> И, наконец, сборка!
> gear-hsh $TMP/

Тут следует написать что gear-hsh берёт файлы из .git, поэтому любые изменения в spec, rules и т.д. нужно коммитить перед запуском gear-hsh.

(In reply to Michael Shigorin from comment #2)
> В качестве менторов -- bircoph@ (основной, если согласится) и я.

Да, я согласен.

(In reply to ilyakurdyukov from comment #3)
> От себя бы хотел добавить свой проект
> (https://github.com/ilyakurdyukov/jpeg-quantsmooth), 

Всячески приветствуется :)

> далее только добавление
> и обновление патчей с оптимизацией для Эльбруса (пока скинуты сюда
> https://github.com/ilyakurdyukov/e2k-ports), другие архитектуры ломать не
> должны.

Думаю, что в дальнейшем тоже может понадобиться собрать или подновить ту или иную утилиту или иной инструмент, необходимый для работы.

> В идеале добиться добавления этих патчей в официальные репозитории, тогда в
> Альте уже будут не нужны.

Как показал опыт libjpeg-turbo, будут апстримы, которые не заинтересованы в наших правках и оптимизациях. Но, безусловно, следует стремиться к тому, чтоб все наработки попадали в upstream.

(In reply to ilyakurdyukov from comment #4)
> Created attachment 9276 [details]
> gpg-4096.pub
> 
> Нужно дополнить:
> 
> > www.altlinux.org/Работа_с_ключами_разработчика
> > Создать новый GPG-ключ можно командой
> > $ gpg --gen-key
> 
> В современной версии gpg (2.1.17 или выше), при использовании --gen-key не
> спрашивается тип ключа, так что мне сгенерировало дефолтный на 3072. Нужно
> использовать ключ --full-gen-key. Это в Альте gpg старый и знает только
> --gen-key, который работает как --full-gen-key в новом.

По-моему, Вы упустили, что в Альте две версии gpg:
gpg v1 — пакет gnupg (1.4.23)
gpg v2 — пакет gnupg2 (2.2.27)

Так что поставьте себе gnupg2 и будет Вам счастье. Я себе в пользовательском PATH добавил символьную ссылку gpg -> gpg2.

(In reply to ilyakurdyukov from comment #4)
> Created attachment 9276 [details]
> gpg-4096.pub

Пожалуйста, создайте отдельный signing subkey (тоже rsa 4096) для этого ключа (создавать новый ключ при этом не обязательно, можно отредактировать имеющийся). Поскольку коммитов ожидается много, следует беречь основной ключ.

Полученный результат также можно отправить на какой-нибудь публичный keyserver, но это опционально.

(In reply to Michael Shigorin from comment #5)
> (Ответ для ilyakurdyukov на комментарий #3)
> > От себя бы хотел добавить свой проект
> > (https://github.com/ilyakurdyukov/jpeg-quantsmooth)
> Отлично :-)
> 
> По работе над пакетом в почтовой переписке считаю, что можно переходить к
> п.2.

Предлагаю сперва дождаться исправления gpg-ключа, а затем уже переходить — чтоб секретарю дважды работу не делать.

(Ответ для ilyakurdyukov на комментарий #8)
> Проблемы руководства:
Это лучше отдельной багой повесить :-)

Сюда: http://bugzilla.altlinux.org/enter_bug.cgi?product=Infrastructure
на компонент www.altlinux.org,
указав Url: http://www.altlinux.org/Работа_с_ключами_разработчика,
добавив в копию тех же людей, что и здесь,
и упомянув эту багу.

Спасибо!

Created attachment 9283 [details]
gpg-4096-2.pub

Добавил sign ключ.

> Так что поставьте себе gnupg2 и будет Вам счастье. Я себе в пользовательском PATH добавил символьную ссылку gpg -> gpg2.

Если gpg2 есть в Альте, то тем более руководство по созданию ключей поправить. А еще там про создание signing subkey не написано.

(In reply to ilyakurdyukov from comment #15)
> Created attachment 9283 [details]
> gpg-4096-2.pub
> 
> Добавил sign ключ.

Считаю, что кандидат готов к переходу на следующий этап (email, gitery, gyle).

(In reply to ilyakurdyukov from comment #16)
> > Так что поставьте себе gnupg2 и будет Вам счастье. Я себе в пользовательском PATH добавил символьную ссылку gpg -> gpg2.
> 
> Если gpg2 есть в Альте, то тем более руководство по созданию ключей
> поправить. А еще там про создание signing subkey не написано.

Илья, этот баг предназначен для отслеживания процесса Вашего вступления в Team и возможного обсуждения возникающих к Вам вопросов. Прошу всё остальное обсуждать по иным каналам.

1) Как Миша уже предложил в comment 14, откройте отдельный баг по улучшению документации и давайте продолжим обсуждение там.

1.1) Отдельный signing subkey у нас рекомендуется, в т.ч. мной, исходя из общей практики использования GnuPG и Web-of-Trust. Насколько я знаю, это не официально установленная политика и, следовательно, не 100% обязательное требование; тем более, что у нас есть старожилы, для которых это требование заведомо не выполняется. Но в идеале мне бы хотелось, чтоб у всех были отдельные подключили для подписи и на основном ключе оставлена только функция сертификации.

2) Пожалуйста, не тащите сюда zip-файлы и иные архивы. Достаточно дать ссылку. Тем более, скоро у Вас будет доступ к git.alt.

3) По поводу git, раз уж Миша затронул этот вопрос:
(In reply to Michael Shigorin from comment #7)
> Вот здесь всё-таки хотелось бы видеть переход от git-репозитория в github
> к git-репозиторию с .gear; хотя это и не является обязательным, но
> устраивать вместо git pull танцы с потерей апстримной истории, являясь
> апстримом, как-то странно.

Я считаю, что мейнтенер вправе самостоятельно выбирать любой из поддерживаемых у нас методов ведения репозиториев пакетов — хоть сборку из srpm. Поэтому с точки зрения ментора у меня нет претензий к сделанному кандидатом выбору.

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

Предлагаю по необходимости обсудить дальнейшие детали того, кто как считает лучше вести git за пределами этого бага в отдельной переписке.

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

T/J/S -> 2.4.

Считаю, что кандидат готов собирать пакеты.

(Ответ для Andrew Savchenko на комментарий #20)
> Считаю, что кандидат готов собирать пакеты.
Предлагаю переходить собственно к п.4.

Пакет alt-gpgkeys обновлён.

T/J/S -> 3.4.

Несколько собранных Ильёй пакетов уже в Сизифе: jpegqs (сделан с нуля), ffmpeg и libjpeg-turbo со сложными изменениями.

Считаю, что кандидат готов к самостоятельной работе в Сизифе.

В sisyphus и sisyphus_e2k уже вошли libjpeg-turbo, libx264, ffmpeg, libopencv, libaom, libwebp с исправлениями и/или свободными оптимизациями для e2k
в исполнении Ильи и jpegqs его же авторства:

http://git.altlinux.org/tasks/archive/done/_266/272415/logs/events.2.1.log
http://git.altlinux.org/tasks/archive/done/_266/272441/logs/events.2.3.log
http://git.altlinux.org/tasks/archive/done/_266/272534/logs/events.2.1.log
http://git.altlinux.org/tasks/archive/done/_266/272558/logs/events.3.1.log
http://git.altlinux.org/tasks/archive/done/_266/273272/logs/events.3.3.log
http://git.altlinux.org/tasks/archive/done/_266/273344/logs/events.2.1.log
http://git.altlinux.org/tasks/archive/done/_267/273452/logs/events.1.1.log

Считаю, что кандидат более чем готов быть майнтейнером.

ping

ping -b

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

Дак вроде и так два человека посмотрели: bircoph@ и mike@
Оба согласились, что кандидат более, чем готов.

Насколько я понял, за июнь кандидат отправил и закоммитил уже намного больше тасков, чем было указано выше. Из новых пакетов видимо только jpegqs, в котором можно было бы убрать запятую в BuildRequires, потому что так не принято, но это мелочи.

Я полностью солидарен с предыдущими менторами и считаю, что кандидат вполне понимает базовые альтовые особенности сборки и достоин быть в списке тим.

(In reply to Grigory Ustinov from comment #28)
> Дак вроде и так два человека посмотрели: bircoph@ и mike@
> Оба согласились, что кандидат более, чем готов.

Ну тогда я тоже выскажусь.
В изменениях в большинстве пакетов прослеживаются две неприятные вещи:
1. Кое-где изменения, которые нужны для e2k (и не вредны для других архитектур) применяются под условием %ifarch %e2k.  Мне кажется, что это неправильно потому что важно иметь (по возможности) одну и ту же кодовую базу на разных архитектурах.  Когда я вижу применение патча под условием %ifarch, мне начинает казаться, что этот патч очень низкого качества, потому что он ломает какие-то другие архитектуры.  С первого взгляда мне кажется, что ни один ваш патч к таким не относится.
2. Кое-где используется sed для применения не вполне тривиальных изменений в исходном коде, это часто нечитаемо и всегда ненадёжно.  В случае с boost почему-то используется и патч и cat >>, хотя кажется, что было бы логичнее, если бы и это изменение было частью патча.  Изменения в embree, qtractor и quake3 тоже скорее всего выглядели бы лучше в виде патча.

Ну и по поводу изменения в rpm-build-ocaml тоже выскажусь.  Конструкция %(bash -c "[[ %{_target_cpu} == e2k* ]] && ... || ...) приводит к тому, что из одного bash запускается другой (/bin/sh -> /bin/bash).  Мне кажется, что для внутреальтовых макросов можно считать что конструкция %() запустит /bin/sh, который поддерживает bash-изм [[ == ]].  А если хочется написать что-то похожее в portable виде, то просто используйте case.

Адрес подписан на devel@.
Пользователь добавлен в группу мейнтейнеров.

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

> Кое-где изменения, которые нужны для e2k (и не вредны для других архитектур)
> применяются под условием %ifarch %e2k.

Я делаю это для того, чтобы не беспокоить мейнтейнеров Альта когда патчи перестанут подходить из-за изменений в апстриме. Патчи же всегда делаю так, чтобы они не меняли ничего для других архитектур. Кроме sed патча для питона спрятанного под ifarch, чтобы не усложнять его еще более.

> Ну и по поводу изменения в rpm-build-ocaml тоже выскажусь.

Насчёт ocaml у меня было два варианта:

rpm --eval '%{!?_with_ocamlopt:%{!?_without_ocamlopt:%{expand:%%global %(bash -c "[[ %{_target_cpu} == e2k* ]] && echo _without_ocamlopt --without-ocamlopt || echo _with_ocamlopt --with-ocamlopt")}}}%{expand:%%{?_with_ocamlopt:yes}%%{?_without_ocamlopt:no}}'

rpm --eval '%{!?_with_ocamlopt:%{!?_without_ocamlopt:%{expand:%%global %(echo %{_target_cpu} | sed "/^e2k/{s|.*|_without_ocamlopt --without-ocamlopt|;q};s|.*|_with_ocamlopt --with-ocamlopt|")}}}%{expand:%%{?_with_ocamlopt:yes}%%{?_without_ocamlopt:no}}'

Не претендую что это красивое решение, зато работало, мне не понравилось насколько rpm макросы убогие и непродуманные (нельзя вставить %if в макрос). Из-за чего приходится городить такие нечитаемные конструкции. У меня возникли разногласия с мейнтейнером ocaml, так что я оставил mike@ свои наработки по ocaml и перешел к другим задачам.

(In reply to Gleb F-Malinovskiy from comment #29)
> 1. Кое-где изменения, которые нужны для e2k (и не вредны для других
> архитектур) применяются под условием %ifarch %e2k.  Мне кажется, что это
> неправильно потому что важно иметь (по возможности) одну и ту же кодовую
> базу на разных архитектурах.  Когда я вижу применение патча под условием
> %ifarch, мне начинает казаться, что этот патч очень низкого качества, потому
> что он ломает какие-то другие архитектуры.  С первого взгляда мне кажется,
> что ни один ваш патч к таким не относится.

Мы много обсуждали этот вопрос в процессе подготовки. Я тоже поддерживаю безусловное наложение патчей. Но Миша справедливо указал, что проблема в том, кто будет поддерживать сильно нетривиальные изменения для e2k. У мейнтенера пакета может не быть возможности это делать (например, нет доступа к e2k) или времени. Насколько я помню, патч в ffmpeg именно на таких условиях и был принят.

Согласен, что это не очень хорошо, но лучше, чем никак. Наверное, единственный альтернативный выход — добавлять Илью в ACL таких пакетов, но это увеличит на него нагрузку, т.к. вместо отложенного решения проблем потребуется незамедлительное.

Ура!  Мы строили-строили и наконец построили :-)

А за дополнительный отсмотр спасибо -- думаю, уже по ходу пьесы будем решать.
Так-то стараемся патчи по апстримам распихивать (кстати, ffmpeg пора тоже).