Bug 39887

Summary: [5.0] join ilyakurdyukov@
Product: Team Accounts Reporter: ilyakurdyukov
Component: joinAssignee: Gleb F-Malinovskiy <glebfm>
Status: CLOSED FIXED QA Contact: Andrey Cherepanov <cas>
Severity: normal    
Priority: P5 CC: aen, bircoph, glebfm, grenka, ldv, mike
Version: unspecified   
Hardware: e2k   
OS: Linux   
URL: http://altlinux.org/Team/Join/Secretary
Attachments:
Description Flags
gpg.pub
none
id_rsa.pub
none
gpg-4096.pub
none
jpegqs-gear.zip
none
gpg-4096-2.pub none

Description ilyakurdyukov 2021-04-06 16:28:02 MSK
Created attachment 9274 [details]
gpg.pub

имя пользователя: ilyakurdyukov
почта: ilyakurdyukov@basealt.ru
Comment 1 ilyakurdyukov 2021-04-06 16:29:27 MSK
Created attachment 9275 [details]
id_rsa.pub
Comment 2 Michael Shigorin 2021-04-06 17:30:37 MSK
В качестве менторов -- bircoph@ (основной, если согласится) и я.
Comment 3 ilyakurdyukov 2021-04-06 17:45:29 MSK
От себя бы хотел добавить свой проект (https://github.com/ilyakurdyukov/jpeg-quantsmooth), далее только добавление и обновление патчей с оптимизацией для Эльбруса (пока скинуты сюда https://github.com/ilyakurdyukov/e2k-ports), другие архитектуры ломать не должны.

В идеале добиться добавления этих патчей в официальные репозитории, тогда в Альте уже будут не нужны.
Comment 4 ilyakurdyukov 2021-04-06 18:28:14 MSK
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 в новом.
Comment 5 Michael Shigorin 2021-04-08 13:29:51 MSK
(Ответ для ilyakurdyukov на комментарий #3)
> От себя бы хотел добавить свой проект
> (https://github.com/ilyakurdyukov/jpeg-quantsmooth)
Отлично :-)

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

(Ответ для ilyakurdyukov на комментарий #4)
> Нужно дополнить:
> > www.altlinux.org/Работа_с_ключами_разработчика
Тут уж к принимающим (насколько понимаю, прямо сейчас это скорее ldv@),
но всяко спасибо, что сообщили о замеченном.
Comment 6 ilyakurdyukov 2021-04-08 13:49:47 MSK
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, чтобы не качать с гитхаба при билде.
Comment 7 Michael Shigorin 2021-04-08 14:02:04 MSK
(Ответ для 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
Comment 8 ilyakurdyukov 2021-04-08 14:27:28 MSK
Проблемы руководства:

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.
Comment 9 Andrew Savchenko 2021-04-08 16:55:53 MSK
(In reply to Michael Shigorin from comment #2)
> В качестве менторов -- bircoph@ (основной, если согласится) и я.

Да, я согласен.
Comment 10 Andrew Savchenko 2021-04-08 17:27:26 MSK
(In reply to ilyakurdyukov from comment #3)
> От себя бы хотел добавить свой проект
> (https://github.com/ilyakurdyukov/jpeg-quantsmooth), 

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

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

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

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

Как показал опыт libjpeg-turbo, будут апстримы, которые не заинтересованы в наших правках и оптимизациях. Но, безусловно, следует стремиться к тому, чтоб все наработки попадали в upstream.
Comment 11 Andrew Savchenko 2021-04-08 17:32:10 MSK
(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.
Comment 12 Andrew Savchenko 2021-04-08 17:39:53 MSK
(In reply to ilyakurdyukov from comment #4)
> Created attachment 9276 [details]
> gpg-4096.pub

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

Полученный результат также можно отправить на какой-нибудь публичный keyserver, но это опционально.
Comment 13 Andrew Savchenko 2021-04-08 17:41:57 MSK
(In reply to Michael Shigorin from comment #5)
> (Ответ для ilyakurdyukov на комментарий #3)
> > От себя бы хотел добавить свой проект
> > (https://github.com/ilyakurdyukov/jpeg-quantsmooth)
> Отлично :-)
> 
> По работе над пакетом в почтовой переписке считаю, что можно переходить к
> п.2.

Предлагаю сперва дождаться исправления gpg-ключа, а затем уже переходить — чтоб секретарю дважды работу не делать.
Comment 14 Michael Shigorin 2021-04-08 18:19:11 MSK
(Ответ для ilyakurdyukov на комментарий #8)
> Проблемы руководства:
Это лучше отдельной багой повесить :-)

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

Спасибо!
Comment 15 ilyakurdyukov 2021-04-08 19:03:23 MSK
Created attachment 9283 [details]
gpg-4096-2.pub

Добавил sign ключ.
Comment 16 ilyakurdyukov 2021-04-08 19:08:44 MSK
> Так что поставьте себе gnupg2 и будет Вам счастье. Я себе в пользовательском PATH добавил символьную ссылку gpg -> gpg2.

Если gpg2 есть в Альте, то тем более руководство по созданию ключей поправить. А еще там про создание signing subkey не написано.
Comment 17 Andrew Savchenko 2021-04-09 19:43:50 MSK
(In reply to ilyakurdyukov from comment #15)
> Created attachment 9283 [details]
> gpg-4096-2.pub
> 
> Добавил sign ключ.

Считаю, что кандидат готов к переходу на следующий этап (email, gitery, gyle).
Comment 18 Andrew Savchenko 2021-04-09 19:58:24 MSK
(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 за пределами этого бага в отдельной переписке.
Comment 19 Dmitry V. Levin 2021-04-10 02:22:29 MSK
Адрес для пересылки создан.
Ключ на gitery.alt зарегистрирован.
Ключ на gyle.alt зарегистрирован.

T/J/S -> 2.4.
Comment 20 Andrew Savchenko 2021-04-12 23:20:17 MSK
Считаю, что кандидат готов собирать пакеты.
Comment 21 Michael Shigorin 2021-04-27 14:42:35 MSK
(Ответ для Andrew Savchenko на комментарий #20)
> Считаю, что кандидат готов собирать пакеты.
Предлагаю переходить собственно к п.4.
Comment 22 Gleb F-Malinovskiy 2021-05-18 15:54:40 MSK
Пакет alt-gpgkeys обновлён.

T/J/S -> 3.4.
Comment 23 Andrew Savchenko 2021-05-31 23:31:35 MSK
Несколько собранных Ильёй пакетов уже в Сизифе: jpegqs (сделан с нуля), ffmpeg и libjpeg-turbo со сложными изменениями.

Считаю, что кандидат готов к самостоятельной работе в Сизифе.
Comment 24 Michael Shigorin 2021-06-03 17:25:41 MSK
В 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

Считаю, что кандидат более чем готов быть майнтейнером.
Comment 25 Michael Shigorin 2021-06-10 22:54:15 MSK
ping
Comment 26 Andrew Savchenko 2021-06-29 17:27:21 MSK
ping -b
Comment 27 Gleb F-Malinovskiy 2021-06-30 13:05:23 MSK
Призван ещё один человек (grenka@) для независимой оценки готовности кандидата.
Comment 28 Grigory Ustinov 2021-06-30 13:31:54 MSK
Дак вроде и так два человека посмотрели: bircoph@ и mike@
Оба согласились, что кандидат более, чем готов.

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

Я полностью солидарен с предыдущими менторами и считаю, что кандидат вполне понимает базовые альтовые особенности сборки и достоин быть в списке тим.
Comment 29 Gleb F-Malinovskiy 2021-06-30 19:22:38 MSK
(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.
Comment 30 Gleb F-Malinovskiy 2021-06-30 19:25:16 MSK
Адрес подписан на devel@.
Пользователь добавлен в группу мейнтейнеров.

Желаю удачного мейнтейнерства!
Comment 31 ilyakurdyukov 2021-06-30 19:32:48 MSK
> Кое-где изменения, которые нужны для e2k (и не вредны для других архитектур)
> применяются под условием %ifarch %e2k.

Я делаю это для того, чтобы не беспокоить мейнтейнеров Альта когда патчи перестанут подходить из-за изменений в апстриме. Патчи же всегда делаю так, чтобы они не меняли ничего для других архитектур. Кроме sed патча для питона спрятанного под ifarch, чтобы не усложнять его еще более.
Comment 32 ilyakurdyukov 2021-06-30 19:44:56 MSK
> Ну и по поводу изменения в 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 и перешел к другим задачам.
Comment 33 Andrew Savchenko 2021-06-30 21:12:13 MSK
(In reply to Gleb F-Malinovskiy from comment #29)
> 1. Кое-где изменения, которые нужны для e2k (и не вредны для других
> архитектур) применяются под условием %ifarch %e2k.  Мне кажется, что это
> неправильно потому что важно иметь (по возможности) одну и ту же кодовую
> базу на разных архитектурах.  Когда я вижу применение патча под условием
> %ifarch, мне начинает казаться, что этот патч очень низкого качества, потому
> что он ломает какие-то другие архитектуры.  С первого взгляда мне кажется,
> что ни один ваш патч к таким не относится.

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

Согласен, что это не очень хорошо, но лучше, чем никак. Наверное, единственный альтернативный выход — добавлять Илью в ACL таких пакетов, но это увеличит на него нагрузку, т.к. вместо отложенного решения проблем потребуется незамедлительное.
Comment 34 Michael Shigorin 2021-06-30 21:23:52 MSK
Ура!  Мы строили-строили и наконец построили :-)

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