Bug 43172

Summary: [4.0] join kaa@
Product: Team Accounts Reporter: Aleksei Kalinin <kaa>
Component: joinAssignee: Gleb F-Malinovskiy <glebfm>
Status: ASSIGNED --- QA Contact: Andrey Cherepanov <cas>
Severity: normal    
Priority: P5 CC: glebfm, grenka, ldv, mike, rider, shaba, sin, svn17, zerg
Version: unspecified   
Hardware: x86_64   
OS: Linux   
URL: https://www.altlinux.org/Team/Join/Secretary
Attachments:
Description Flags
Public SSH key
none
Wrong Public GPG key
none
Public GPG key none

Description Aleksei Kalinin 2022-07-06 22:43:31 MSK
Created attachment 11056 [details]
Public SSH key

Ник   : kaa
Почта : altlinux@faktor.pw
Ментор: kaa@altlinux.org
Ментор: Иван Савин svn17@basealt.ru
Моя цель: Научиться собирать пакеты.

На данный момент вместе с наставником получилось собрать пакет libvirt, исправив ошибку появившуюся в логе https://git.altlinux.org/beehive/logs/Sisyphus/x86_64/latest/error/libvirt-8.0.0-alt3. Был взят upstream commit.
Подробнее можно посмотреть в репозитории https://gitlab.com/faktor.lex/libvirt/-/tree/sisyphus
Надеюсь на ваши правки и рекомендации.
Comment 1 Aleksei Kalinin 2022-07-06 22:44:02 MSK
Created attachment 11057 [details]
Wrong Public GPG key
Comment 2 Иван Савин 2022-07-13 16:51:38 MSK
Подтверждаю заявку.
Comment 3 Aleksei Kalinin 2022-07-22 22:46:32 MSK
Была решена проблема описанная в репорте https://bugzilla.altlinux.org/43326
Вместе с наставником паке дополнительно был обновлен до версии 6.6.4
Comment 4 Иван Савин 2022-08-22 16:36:04 MSK
(Ответ для Aleksei Kalinin на комментарий #0)
> Создано вложение 11056 [details] [подробности]
> Public SSH key
> 
> Ник   : kaa
> Почта : altlinux@faktor.pw
> Ментор: kaa@altlinux.org
> Ментор: Иван Савин svn17@basealt.ru
> Моя цель: Научиться собирать пакеты.

Указано два ментора, и первый ментор это сам кандидат?
Какая-то путаница.
Comment 5 Иван Савин 2022-08-22 16:40:02 MSK
Прошу секретаря зарегистрировать ключи.
Comment 6 Aleksei Kalinin 2022-08-22 16:49:21 MSK
(In reply to Aleksei Kalinin from comment #0)
> Created attachment 11056 [details]
> Public SSH key
> 
> Ник   : kaa
> Почта : altlinux@faktor.pw
> Ментор: kaa@altlinux.org
> Ментор: Иван Савин svn17@basealt.ru
> Моя цель: Научиться собирать пакеты.
> 
> На данный момент вместе с наставником получилось собрать пакет libvirt,
> исправив ошибку появившуюся в логе
> https://git.altlinux.org/beehive/logs/Sisyphus/x86_64/latest/error/libvirt-8.
> 0.0-alt3. Был взят upstream commit.
> Подробнее можно посмотреть в репозитории
> https://gitlab.com/faktor.lex/libvirt/-/tree/sisyphus
> Надеюсь на ваши правки и рекомендации.

 Строка "Ментор: kaa@altlinux.org" в описании ошибка. Разумеется это почта не относится к менторству. Данная почта предполагается как рабочая почта по итогу присоединения к команде.
итоговый исправленный список запроса:
Ник   : kaa
Почта : altlinux@faktor.pw
Почта желаемая: kaa@altlinux.org
Ментор: Иван Савин svn17@basealt.ru
Цель: Научиться собирать пакеты.
Публичный SSH ключ: [Public SSH key](https://bugzilla.altlinux.org/attachment.cgi?id=11056)
Публичный GPG ключ: [Public GPG key](https://bugzilla.altlinux.org/attachment.cgi?id=11057)
Comment 7 Gleb F-Malinovskiy 2022-09-05 10:59:23 MSK
(In reply to Aleksei Kalinin from comment #6)
> Публичный SSH ключ: [Public SSH
> key](https://bugzilla.altlinux.org/attachment.cgi?id=11056)
> Публичный GPG ключ: [Public GPG
> key](https://bugzilla.altlinux.org/attachment.cgi?id=11057)

Ok.
Comment 8 Иван Савин 2022-09-06 11:35:32 MSK
Считаю, что кандидат умеет генерировать ключи и готов начать встаупление в team.
Comment 9 Gleb F-Malinovskiy 2022-09-13 19:36:52 MSK
ssh ключ на gitery.alt зарегистрирован.
Адрес для пересылки создан.

T/J/S -> 2.3.
Comment 10 Иван Савин 2022-09-14 11:43:06 MSK
Прошу кандидата предоставить примеры пакетов на git.altlinux.org.
Comment 11 Aleksei Kalinin 2022-10-26 22:02:00 MSK
Выбран брошеный пакет <flam3	3.1.1-alt3	20	@nobody>
Исправленна ошибка линковки статической библиотеки
Добавлен патч и оформлен spec файл
Исправления добавил на git.altlinux.org
https://git.altlinux.org/people/kaa/packages/?p=flam3.git;a=shortlog;h=refs/heads/sisyphus
Comment 12 Alexey Shabalin 2022-10-26 23:45:59 MSK
У апчьрима на github есть PR на эту тему, и кажется более правильный (используется LIBADD, а не LDFLAGS).
Так же в апстриме есть issue на CFLAGS -O3, его бы тоже исправить.
Comment 13 Aleksei Kalinin 2022-10-27 01:14:40 MSK
Comment on attachment 11057 [details]
Wrong Public GPG key

wrong name Aleksey
was changed because of name mistake
Comment 14 Aleksei Kalinin 2022-10-27 01:31:48 MSK
Created attachment 11772 [details]
Public GPG key

Обнаружил ошибку в своем имени(Aleksey должно быть  Aleksei), GPG ключа.
Поменял ключ и добавил во вложения новый публичный GPG ключ.
Comment 15 Aleksei Kalinin 2022-10-28 01:28:24 MSK
(In reply to Alexey Shabalin from comment #12)
> У апчьрима на github есть PR на эту тему, и кажется более правильный
> (используется LIBADD, а не LDFLAGS).

Применил PR коммит апстрима https://github.com/scottdraves/flam3/pull/33, но он не работает полностью. Для flam3_genome_LDADD и flam3_render_LDADD всё равно приходится добавлять флаг -lm. Думаю что пока добавлю изменения их этого PR и попралю патч.

> Так же в апстриме есть issue на CFLAGS -O3, его бы тоже исправить.
Проверю и тоже добавлю эти изменения.

Спасибо за Ваши замечания.
Comment 16 Aleksei Kalinin 2022-11-07 23:14:20 MSK
(In reply to Alexey Shabalin from comment #12)
Алексей, разбирался с Вашими замечаниями
> У апчьрима на github есть PR на эту тему, и кажется более правильный
> (используется LIBADD, а не LDFLAGS).

Изменения в PR работают без ключей для configure --enable-shared --disable-static, но в пакете есть исполняемые файлы которые требую линковки с библиотекой m. И реализация:
AC_CHECK_LIBM
AC_SUBST([LIBM])
выбивается из оформления линковки библиотек в апстриме(имхо тогда нужно все линкованные библиотеки так переделывать), поскольку PR так и не принят пока предлагаю патч: 
Index: b/Makefile.am
===================================================================
--- a/Makefile.am
+++ b/Makefile.am
@@ -11,19 +11,19 @@
 include_HEADERS = flam3.h isaac.h isaacs.h rect.c
 
 libflam3_la_SOURCES = flam3.c filters.c parser.c variations.c interpolation.c palettes.c jpeg.c png.c isaac.c
-libflam3_la_LDFLAGS = -no-undefined -ljpeg -lpng -lz -lpthread
+libflam3_la_LDFLAGS = -no-undefined -ljpeg -lpng -lz -lpthread -lm
 
 flam3_genome_SOURCES = flam3-genome.c docstring.c
 flam3_genome_LDADD = libflam3.la -lm
 
 flam3_animate_SOURCES = flam3-animate.c docstring.c
-flam3_animate_LDADD = libflam3.la -lm
+flam3_animate_LDADD = libflam3.la
 
 flam3_render_SOURCES = flam3-render.c docstring.c
 flam3_render_LDADD = libflam3.la -lm
 
 flam3_convert_SOURCES = flam3-convert.c docstring.c
-flam3_convert_LDADD = libflam3.la -lm
+flam3_convert_LDADD = libflam3.la
 
 pkgdata_DATA = flam3-palettes.xml


> Так же в апстриме есть issue на CFLAGS -O3, его бы тоже исправить.

Переобозначение флагов оптимизации через AM_CFLAGS действительно кажется страннм оно нарушает логику configure.ac. Учитывая обозначенную проблему https://github.com/scottdraves/flam3/issues/25
предлагаю патч:
Index: b/Makefile.am
===================================================================
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,7 +1,8 @@
 AUTOMAKE_OPTIONS = foreign no-dependencies
 
 GIT_DEF = -D'GIT_REV="$(shell git describe --tags --dirty)"'
-AM_CFLAGS = -g -O3 -std=gnu99 -ffast-math -DPACKAGE_DATA_DIR=\"$(pkgdatadir)\" $(GIT_DEF)
+CFLAGS ?= -g -O3
+AM_CFLAGS = -std=gnu99 -ffast-math -DPACKAGE_DATA_DIR=\"$(pkgdatadir)\" $(GIT_DEF)
 
 ACLOCAL_AMFLAGS = -I m4
 
Index: b/configure.ac
===================================================================
--- a/configure.ac
+++ b/configure.ac
@@ -14,7 +14,7 @@ save_CFLAGS=$CFLAGS
 
 AC_PROG_CC
 
-CFLAGS=$save_CFLAGS
+CFLAGS?=$save_CFLAGS
 
 AC_PROG_INSTALL

Все изменения оформил в ветке fix: https://git.altlinux.org/people/kaa/packages/?p=flam3.git;a=tree;h=refs/heads/fix;hb=fix

Жду ваших коментариев, исправлений
Спасибо
Comment 17 Иван Савин 2022-11-11 18:31:14 MSK
Считаю, что кандидат освоил необходимый минимум и готов собирать пакеты. Если замечаний нет, то прошу секретаря дать кандидату доступ к сборочнице.
Comment 18 Gleb F-Malinovskiy 2022-12-09 16:51:14 MSK
ssh ключ на gyle.alt зарегистрирован.
Пакет alt-gpgkeys обновлён.

T/J/S -> 3.5.
Comment 19 Aleksei Kalinin 2022-12-16 16:14:50 MSK
Спасибо.
Пакет собирается, все удачно в режиме --test-only
https://git.altlinux.org/tasks/311820/.
Вижу что пакет flam3 уже удален cleaner'ом https://packages.altlinux.org/ru/sisyphus/srpms/flam3/

В режиме --commit  предсказуемо ACL обрубил доступ.
Подготовленный комит тут с тегом 3.1.1-alt4
https://git.altlinux.org/people/kaa/packages/?p=flam3.git
Comment 20 Иван Савин 2022-12-19 14:27:10 MSK
(Ответ для Aleksei Kalinin на комментарий #19)

> Подготовленный комит тут с тегом 3.1.1-alt4
> https://git.altlinux.org/people/kaa/packages/?p=flam3.git

Нужно добавить ветку по умолчанию (default-branch).
Comment 21 Aleksei Kalinin 2022-12-19 19:02:30 MSK
(In reply to Иван Савин from comment #20)
> (Ответ для Aleksei Kalinin на комментарий #19)
> 
> > Подготовленный комит тут с тегом 3.1.1-alt4
> > https://git.altlinux.org/people/kaa/packages/?p=flam3.git
> 
> Нужно добавить ветку по умолчанию (default-branch).

Исправления внес. Теперь ветка клонируется и отображается по умолчанию в репозитории. Спасибо
Comment 22 Иван Савин 2022-12-20 17:49:35 MSK
Думаю, кандидат готов к переходу на следующий этап.
Comment 23 Gleb F-Malinovskiy 2022-12-26 18:20:05 MSK
(In reply to Иван Савин from comment #22)
> Думаю, кандидат готов к переходу на следующий этап.

Мне кажется, что любой рецензент скажет, что одного пакета мало.  Вы уверены, что этого пакета будет достаточно?
Comment 24 Иван Савин 2023-01-19 14:59:45 MSK
(Ответ для Gleb F-Malinovskiy на комментарий #23)
> (In reply to Иван Савин from comment #22)
> > Думаю, кандидат готов к переходу на следующий этап.
> 
> Мне кажется, что любой рецензент скажет, что одного пакета мало.  Вы
> уверены, что этого пакета будет достаточно?

Согласен. Поторопился.
Кандидат, прошу Вас предоставить больше примеров.
Comment 25 Grigory Ustinov 2023-01-19 15:10:35 MSK
(Ответ для Gleb F-Malinovskiy на комментарий #23)
> (In reply to Иван Савин from comment #22)
> > Думаю, кандидат готов к переходу на следующий этап.
> 
> Мне кажется, что любой рецензент скажет, что одного пакета мало.  Вы
> уверены, что этого пакета будет достаточно?

Один умник мне на такое ответил: А сколько надо? Формально у нас нет никаких критериев для оценки кандидатов и даже нет единого мнения по поводу базовых знаний. Мне кажется я знаю несколько потенциальных рецензентов, которым одного пакета было бы достаточно:) Иии ЧСХ их почему-то никогда не призывают быть рецензентами. Кстати назначение рецензентов - самая загадочная и мутная часть процедуры джойна.
Comment 26 Aleksei Kalinin 2023-04-29 02:27:12 MSK
(In reply to Grigory Ustinov from comment #25)
> (Ответ для Gleb F-Malinovskiy на комментарий #23)
> > (In reply to Иван Савин from comment #22)
> > > Думаю, кандидат готов к переходу на следующий этап.
> > 
> > Мне кажется, что любой рецензент скажет, что одного пакета мало.  Вы
> > уверены, что этого пакета будет достаточно?
> 
> Один умник мне на такое ответил: А сколько надо? Формально у нас нет никаких
> критериев для оценки кандидатов и даже нет единого мнения по поводу базовых
> знаний. Мне кажется я знаю несколько потенциальных рецензентов, которым
> одного пакета было бы достаточно:) Иии ЧСХ их почему-то никогда не призывают
> быть рецензентами. Кстати назначение рецензентов - самая загадочная и мутная
> часть процедуры джойна.

Доброго дня Grigory!
Наверное из таких же умников... Было бы действительно здорово понимать критерии оценки и требования к пакету или пакетам --- количественные или качественные, хотя бы минимальные. Это позволило бы отсеивать потенциальных кандидатов до создания заявки и сэкономило бы время. Но как говориться, это всего лишь имхо.
Comment 27 Aleksei Kalinin 2023-04-29 02:30:52 MSK
На данный момент в баге заявлено три пакета.
libvirt-8.0.0-alt3 -- один из первых опытов сборки под альт
sweethome3d-6.6.4-alt1 -- была исправлена ошибка и обновлен пакет
flam3-3.1.1-alt3 -- был взят для упражнений. Внесены исправления, оформлен.

Наткнулся на задачу в https://bugzilla.altlinux.org/42109, показавшуюся мне интересной и занялся сборкой пакета OpenTimeLineIO.
В ходе работы был "притянут" по зависимостям и собран пакет pyaaf2-1.6.0-alt1.
Для знакомства со сборкой python модулей был обновлен пакет myst-parser, но его не считаю эталонным для демонстрации, так как исключил секцию само-тестирования.(Будущее пакета стоит обсудить с текущим мейнтейнером)

Изменения:
http://git.altlinux.org/people/kaa/packages/python3-module-OpenTimelineIO.git
http://git.altlinux.org/people/kaa/packages/python3-module-pyaaf2.git
http://git.altlinux.org/people/kaa/packages/python3-module-myst-parser.git
Автосборка-тестирование:
https://git.altlinux.org/tasks/319059/

Жду ваших рекомендаций правок и исправлений.
Спасибо
Comment 28 Grigory Ustinov 2023-04-29 11:20:41 MSK
(Ответ для Aleksei Kalinin на комментарий #26)
> (In reply to Grigory Ustinov from comment #25)
> > (Ответ для Gleb F-Malinovskiy на комментарий #23)
> > > (In reply to Иван Савин from comment #22)
> > > > Думаю, кандидат готов к переходу на следующий этап.
> > > 
> > > Мне кажется, что любой рецензент скажет, что одного пакета мало.  Вы
> > > уверены, что этого пакета будет достаточно?
> > 
> > Один умник мне на такое ответил: А сколько надо? Формально у нас нет никаких
> > критериев для оценки кандидатов и даже нет единого мнения по поводу базовых
> > знаний. Мне кажется я знаю несколько потенциальных рецензентов, которым
> > одного пакета было бы достаточно:) Иии ЧСХ их почему-то никогда не призывают
> > быть рецензентами. Кстати назначение рецензентов - самая загадочная и мутная
> > часть процедуры джойна.
> 
> Доброго дня Grigory!
> Наверное из таких же умников... Было бы действительно здорово понимать
> критерии оценки и требования к пакету или пакетам --- количественные или
> качественные, хотя бы минимальные. Это позволило бы отсеивать потенциальных
> кандидатов до создания заявки и сэкономило бы время. Но как говориться, это
> всего лишь имхо.

Алексей, ну вы как человек, наверное, знакомый с программированием, представляете к чему ведёт "количественный" подход в нашем деле. Скажешь кандидату собрать условно 10 пакетов, он соберёт 10 пакетов типа hunspell-* где нужно просто упаковать два файла. В эту же категорию входят некоторые пакеты-плагины или даже питоновские модули и программы на расте, где буквально в шаблоне меняешь название пакета и всё собирается и работает.

А качественно - сложно зафиксировать и у всех людей разное представление о качестве всего, а не только мейнтейнеров.

У нас есть различные подходы к сборке пакетов. Есть популярные, есть не очень популярные. Есть различные инструменты, которыми мейнтейнеры пользуются.

В мои представления о "качестве" входит как раз освоение вот этих популярных подходов и инструментов. gear-import, gear-commit, gear-remotes-uscan возможно даже с github2spec, gear-store-tags. И схемы из тарбола и из тэга. Поскольку патчинг является неотъемлемой частью нашего дела, хотелось бы чтобы кандидат знал что с ними делать.

Кроме всего вышеперечисленного, кандидат должен уметь бегло пользоваться как нашими сервисами типа git, gyle, pao, wiki, так и сторонними типа repology. Понятное дело, что изобретать велосипед заново - неэффективно и иногда можно содрать пакет с федоры, сьюз или какого-то другого rpm-based дистрибутива. Кандидат должен понимать специфику нашего синтаксиса спек-файлов.

Ну и оформление - это тоже важная часть. Человек должен знать что такое гит, что такое коммит и что такое коммит-месседж. Trailing-spaces и ширина описания в 80 символов.

Всё вышеперечисленное - это то что удалось сформировать на ходу. Все косячат по-разному, поэтому требования тоже могут адаптироваться. И это мои представления о качестве, которые могут не совпадать с представлениями вашего ментора. А может быть ваш ментор сейчас прочитает и ему понравится мой подход:)
Comment 29 Sergey V Turchin 2023-05-03 17:47:04 MSK
Мельком глянул:
* исходники все упакованы, что делает невозможным прочесть изменения в них при обновлении версии.
* Imath у нас есть, с собой копию таскать не надо.
* похоже, всё, что идёт отдельными тарболами, надо собирать отдельными пакетами.
Comment 30 Aleksei Kalinin 2023-05-03 23:16:45 MSK
(In reply to Grigory Ustinov from comment #28)
> (Ответ для Aleksei Kalinin на комментарий #26)
> > (In reply to Grigory Ustinov from comment #25)
> > > (Ответ для Gleb F-Malinovskiy на комментарий #23)
> > > > (In reply to Иван Савин from comment #22)

Григорий, спасибо за развернутый ответ. Ваши примеры были полезны, позволили обратить внимание на инструменты gear, которые были мне не известны.

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

Говоря о количественном подходе предполагал ответ вида:
"Необходимо собрать 3 -- пакета такой то сложности, 2 -- другой сложности, 1 -- третей сложности. И если ты справился с каким-то определенным набором то следовательно знаком со всеми необходимыми инструментами." Но как понял над критериями уровня сложности тоже нужно поработать.
Comment 31 Aleksei Kalinin 2023-05-03 23:23:45 MSK
(In reply to Sergey V Turchin from comment #29)

Приветствую Сергей,
Важный для меня комментарий, так как в ходе сборки возникли вопросы касаемые под модулей.
Для меня не все очевидно, пожалуйста уточните:

> * исходники все упакованы, что делает невозможным прочесть изменения в них
> при обновлении версии.
Что значит "все"? В моем репозитории упакованы только под модули, а остальной код остался неизменным и собирается по тегу из upstream.

> * Imath у нас есть, с собой копию таскать не надо.
Да, согласен, и я обратил внимание на это. Но тарбол взят по конкретному коммиту как предполагается в релизе. Он не совпадает ни с одним релизом под модуля. В этом смысле доверился разработчику. 

> * похоже, всё, что идёт отдельными тарболами, надо собирать отдельными
> пакетами.
Когда принимал решение каким образом собирать пакет, взял для примера несколько пакетов которые так же используют под модули. И сделал по примерам.
Вопрос видимо культуры или традиции: как собирать код из репозитория с под модулями?
так как предполагают разработчики в релизе или используя пакеты дистрибутива.
Comment 32 Sergey V Turchin 2023-05-04 11:10:35 MSK
(Ответ для Aleksei Kalinin на комментарий #31)
> > * исходники все упакованы, что делает невозможным прочесть изменения в них
> > при обновлении версии.
> Что значит "все"? В моем репозитории упакованы только под модули
Не суть. Они лежат в git-е в бинарном виде, а не в текстовом.

> > * Imath у нас есть, с собой копию таскать не надо.
> Да, согласен, и я обратил внимание на это. Но тарбол взят по конкретному
> коммиту как предполагается в релизе. Он не совпадает ни с одним релизом под
> модуля. В этом смысле доверился разработчику. 
"Доверяй, но проверяй", а только потом в случае необходимости...

> Вопрос видимо культуры или традиции: как собирать код из репозитория с под
> модулями? так как предполагают разработчики в релизе или используя пакеты дистрибутива.
У нас и культура и традиции -- собирать используя пакеты.
Разработчики в принципе не умеют пакеты, поэтому пихают всё в один.

Т.е. всё, что можно пакетами -- лучше паковать отдельно. Что-то тащить с собой -- вообще не особо страшно, но только если это не библиотека, с которой может быть слинковано что-то, дополнительно линкующееся с тем же самым проектом, что из какого-то сабмодуля, но идущего отдельным пакетом или таким же внутренним сабмодулем.
Comment 33 Sergey V Turchin 2023-05-04 11:15:56 MSK
(Ответ для Sergey V Turchin на комментарий #32)
> Что-то тащить с собой -- вообще не особо страшно
Если есть соотв. пакет, то уже очень плохо.
Comment 34 Aleksei Kalinin 2023-05-04 23:08:15 MSK
(In reply to Sergey V Turchin from comment #32)
> (Ответ для Aleksei Kalinin на комментарий #31)

Сергей, мне все равно не понятно что значит "все упакованы", и теперь еще более не понятно что значит "в git-е в бинарном виде". Что это меняет? Насколько знаю, в базе git и так все лежит в бинарном виде. т.е. все типы объектов в .git/ojects бинарные. Если речь о пяти архивах подмодулей, то как я уже писал, это взято из примеров и еще руководства:
https://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%B0_%D1%81_git_submodule и они разумется бинарнарные их diff мы не увидим.
Как раз этот вариант кажется удобным для ведения репозитория изменений пакета с подмодулями. Каждый новый релиз предполагает отдельные тарболы подмодулей.

Самое неприятное что мне видится -- рост размера конечного пакета src.rpm из за таких вот кусков. Но больше уверенности что пакет после сборки будет работать так как задумывалось в рамках релиза. Но это имхо, так как привык доверять разработчику.

> У нас и культура и традиции -- собирать используя пакеты.

Сергей, спасибо, задачу понял. Сейчас уже существуют пакеты в sisyphus и p10:
(версии для sisyphus)
imath-3.1.6-alt4
pybind11-2.9.2-alt2
rapidjson-1.1.0-alt4
дополнительно займусь сборкой optional-lite и any, и вношу правки в cmake для исключения подмодулей из процесса сборки. 
Уже попробовал собрать OpenTimelineIO с уже существующим imath и pybind11 — собирается. Но полноценно работоспособность пакета проверить не могу ввиду его масштабов.

Спасибо за ваши правки и рекомендации!
Comment 35 Sergey V Turchin 2023-05-10 13:57:43 MSK
(Ответ для Aleksei Kalinin на комментарий #34)
> Сергей, мне все равно не понятно что значит "все упакованы", и теперь еще
> более не понятно что значит "в git-е в бинарном виде". Что это меняет?
Это меняет всё в принципе. Разница почти такая же, как у закрытого кода с открытым.

> Насколько знаю, в базе git и так все лежит в бинарном виде. т.е. все типы
> объектов в .git/ojects бинарные.
Вывод от git diff при использовании бинарных файлов нечитаем.
В случае если архив с исходниками будет распакован, то изменения не прячутся за бинарным файлом. Вот пример
https://git.altlinux.org/srpms/r/rav1e.git?p=rav1e.git;a=commitdiff;h=62695e75132b9c5e3e14955062c89e0bfc968f61
А если импортируете исходный GIT,то вообще каждый коммит каждого разработчика видно
https://git.altlinux.org/gears/c/containerd.git?p=containerd.git;a=shortlog;h=90544d153fb3b327d88c3f04ac19db866d7fe80e

> Самое неприятное что мне видится -- рост размера конечного пакета src.rpm из
> за таких вот кусков.
Само собой, это тоже.

> Но больше уверенности что пакет после сборки будет
> работать так как задумывалось в рамках релиза. Но это имхо, так как привык
> доверять разработчику.
Ваша задача -- красиво упаковать. По работоспособности будете потом обсуждать с пользователями и отделом тестирования.
Comment 36 Aleksei Kalinin 2023-05-19 00:51:53 MSK
Доброго дня
В процессе перехода к сборке с уже существующими пакетами, наткнулся на необходимость обновления пакета rapidjson
(разработчики давно не выпускали релизы, и в ALT пакет давно не обновлялся, решился обновить до минимально необходимого функционала для OpenTimelineIO)
Подготовленные исходники:
http://git.altlinux.org/people/kaa/packages/rapidjson.git


Собирая модули optional-lite и any создалось впечатление их «специфичности», в итоге возник вопрос: 
Не будет ли сборка этих модулей "загрязнением" пакетной базы ALT?
Исходники:
https://github.com/martinmoene/optional-lite
https://github.com/thelink2012/any.git
прошу экспертизы по вопросу

На данный момент подготовил сборку с учетом замечаний, касающихся прозрачности кода.
Подготовленные исходники:
http://git.altlinux.org/people/kaa/packages/python3-module-OpenTimelineIO-gen2.git
Если вопрос касается подмодулей, подобный вариант реализации встречается в репозиториях ALT, это разумеется не сделает репозиторий меньше, но при необходимости позволяет перемещаться по истории в том числе подмодулей.

Если подмодули  optional-lite и any  не представляют интереса для пакетной базы ALT, возможно  этот вариант сборки буде приемлемым.
https://git.altlinux.org/tasks/319059/
Comment 37 Aleksei Kalinin 2023-05-23 19:41:37 MSK
С молчаливого неодобрения реализации подмодулей...

Подгтовил вариант с использованием пакетов.

Отдельная задача только для пакета OpenTimelineIO:
 https://git.altlinux.org/tasks/321695/

> наткнулся на необходимость обновления пакета rapidjson
> (разработчики давно не выпускали релизы, и в ALT пакет давно не обновлялся,
> решился обновить до минимально необходимого функционала для OpenTimelineIO)
Подготовленные исходники:
 http://git.altlinux.org/people/kaa/packages/rapidjson.git

Пакеты касаемо которых испытаваю сомнения собраны подготовлены:
http://git.altlinux.org/people/kaa/packages/any.git
http://git.altlinux.org/people/kaa/packages/optional-lite.git


> В ходе работы был "притянут" по зависимостям и собран пакет pyaaf2-1.6.0-alt1.
 http://git.altlinux.org/people/kaa/packages/python3-module-pyaaf2.git

Вариант реализации пакета OpenTimelineIO с использованием пакетов:
 http://git.altlinux.org/people/kaa/packages/python3-module-OpenTimelineIO-gen3.git

Жду ваши правки и рекомендации. Спасибо!
Comment 38 Иван Савин 2023-05-25 12:26:56 MSK
Кандидат, это придирка конечно, но пробелы в конце строк в спеке это не красиво.
http://git.altlinux.org/people/kaa/packages/optional-lite.git
Comment 39 Иван Савин 2023-05-25 12:27:32 MSK
(Ответ для Иван Савин на комментарий #24)
> (Ответ для Gleb F-Malinovskiy на комментарий #23)
> > (In reply to Иван Савин from comment #22)
> > > Думаю, кандидат готов к переходу на следующий этап.
> > 
> > Мне кажется, что любой рецензент скажет, что одного пакета мало.  Вы
> > уверены, что этого пакета будет достаточно?
> 
> Согласен. Поторопился.
> Кандидат, прошу Вас предоставить больше примеров.

Секретарь, думаю что кандидат предоставил достаточно пакетов. Если Вы согласны, то прошу перевести его на следующий этап.
Comment 40 Sergey V Turchin 2023-05-25 14:49:03 MSK
(Ответ для Aleksei Kalinin на комментарий #37)
> С молчаливого неодобрения реализации подмодулей...
Если что, я не одобрял хранение в репозитории бинарных файлов вместо открытых исходников.
Если компонент слишком специфичный или патченый так, что другим лучше им не пользоваться, то лучше уж таскать с собой, чтоб никто его не видел.
Comment 41 Aleksei Kalinin 2023-05-26 14:12:24 MSK
(In reply to Иван Савин from comment #38)
> Кандидат, это придирка конечно, но пробелы в конце строк в спеке это не
> красиво.
> http://git.altlinux.org/people/kaa/packages/optional-lite.git

Спасибо за замечание, cделал pre-commit hook на этот случай. Бывает пропускаю такое несмотря на подсветку.
Нашел погрешность тут
https://git.altlinux.org/people/kaa/packages/optional-lite.git?p=optional-lite.git;a=blob;f=optional-lite.spec;h=091a5a76a92c3552a23460bb000074c60fe9e133;hb=HEAD#l30
исправлю перед финишным push

(In reply to Иван Савин from comment #38)
> Кандидат, это придирка конечно, но пробелы в конце строк в спеке это не
> красиво.
> http://git.altlinux.org/people/kaa/packages/optional-lite.git

(In reply to Sergey V Turchin from comment #40)
> (Ответ для Aleksei Kalinin на комментарий #37)
> > С молчаливого неодобрения реализации подмодулей...
> Если что, я не одобрял хранение в репозитории бинарных файлов вместо
> открытых исходников.
> Если компонент слишком специфичный или патченый так, что другим лучше им не
> пользоваться, то лучше уж таскать с собой, чтоб никто его не видел.

Сергей, этот коментарий касался отсутсвия отзывов по второму варианту реализации подмодулей:
https://bugzilla.altlinux.org/show_bug.cgi?id=43172#c36
мне показались специфичными подмодули состоящие по сути из одного заголовочного файла, но что бы не затягивать время, реализовал и второй вариант упаковав каждый подмодуль.
https://bugzilla.altlinux.org/show_bug.cgi?id=43172#c37
Comment 42 Aleksei Kalinin 2023-05-26 14:25:41 MSK
> реализовал и второй
> вариант упаковав каждый подмодуль.
> https://bugzilla.altlinux.org/show_bug.cgi?id=43172#c37

Прошу прощения ошибся. Это уже третий вариант реализации подмодулей в коде конечного пакета.


Первый вариант с тарболами кода подмодулей:
https://bugzilla.altlinux.org/show_bug.cgi?id=43172#c27

Второй вариант с использованием существующих пакетов и внесениес кода двух не упакованных подмодулей в историю git:
https://bugzilla.altlinux.org/show_bug.cgi?id=43172#c36

Третий вариант все подмодули упакованы:
https://bugzilla.altlinux.org/show_bug.cgi?id=43172#c37
Comment 43 Иван Савин 2023-06-01 18:23:25 MSK
Секретарь, предлагаю призвать рецензента.
Comment 44 Aleksei Kalinin 2023-06-29 15:03:14 MSK
Пока рисуется пентаграмма призыва. 
Обратил внимание, давно не обновлялся kdiff3.
Буду благодарен за исправления рекомендации!
Comment 45 Aleksei Kalinin 2023-06-29 15:05:20 MSK
(In reply to Aleksei Kalinin from comment #44)
> Пока рисуется пентаграмма призыва. 
> Обратил внимание, давно не обновлялся kdiff3.
> Буду благодарен за исправления рекомендации!

Номер задачи в режиме тестирования https://git.altlinux.org/tasks/323889/
Comment 46 Aleksei Kalinin 2023-07-01 00:55:20 MSK
UP

Заинтересовал пакет kde5-kstars "убежавший" на 4 минорных версии вперед относительно Alt🦭.
3.6.1 → 3.6.5
Номер задачи в режиме тестирования:https://git.altlinux.org/tasks/323974/ 

Понимаю, пакет не представляет важности, но все же вопрос:
*Есть ли  критерии необходимости обновления пакета? Может быть его  гипотетическая важность, с расстановкой приоритетов или может есть какие-то стратегические причины?

Еще, пакет был выбран по причине схожей особенности "раскидывания" исполняемых файлов.
Меня ввело в замешательство расположение исполняемых файлов в %_K5bin
 /usr/lib/kf5/bin/. Пути нет в $PATH и это затрудняет и делает неочевидным запуск приложений например из Mate. `$ kde5 <bin_name>` не выглядит очевидным.

*Актуально ли сейчас складывать исполняемые файлы в %_K5bin или уже можно ориентироваться только на %_bindir ?
Мое решение для kdiff3 не выглядит аккуратным, но более изящного способа сделать symlinc не нашел.
https://git.altlinux.org/people/kaa/packages/?p=kdiff3.git;a=blob;f=.gear/kdiff3.spec;h=09960bb908aa7b212c94ed680529bd612103b145;hb=HEAD#l57
Comment 47 Aleksei Kalinin 2023-07-01 01:04:53 MSK
Первый раз столкнулся с квотами gitery(kde5-kstars  оказался "тяжелым" ) после оптимизации репозитория и чистки хранилища получилось протолкнуть исходники. На данный момент все пакеты https://git.altlinux.org/people/kaa/packages/ касаются join. Их набралось приличное количество, и разбираться в них представляется затратным по времени...

Возможно ли получить конкретное задание от рецензента или может быть любой более актуальный пакет для сборки/обновления?

Жду правок и наставлений! Спасибо!
Comment 48 Grigory Ustinov 2023-07-01 08:31:29 MSK
Прошу прощения, что случайно подсмотрел... У вас коммиты как-то очень странно называются. На примере awesome: 🦭4.3-alt5. Я думал, что это опечатка в одном коммите, но потом глянул другие пакеты и там то же самое. Не прольёте ли немножко света на эту ситуацию?
Comment 49 Sergey V Turchin 2023-07-03 14:48:23 MSK
(Ответ для Aleksei Kalinin на комментарий #46)
> Заинтересовал пакет kde5-kstars "убежавший" на 4 минорных версии вперед
> относительно Alt🦭.
> 3.6.1 → 3.6.5
> Номер задачи в режиме тестирования:https://git.altlinux.org/tasks/323974/ 
Содержимое коммитов не соответствует их описанию.

> Меня ввело в замешательство расположение исполняемых файлов в %_K5bin
/usr/lib/rpm/macros.d/kf5

>  /usr/lib/kf5/bin/. Пути нет в $PATH и это затрудняет и делает неочевидным
> запуск приложений например из Mate. `$ kde5 <bin_name>` не выглядит
> очевидным.
kde3-kstars, kde4-kstars, kde5-kstars и kde6-kstars в одно место никак не положить.
Но, конкретно kstars можно. Он уже и не в составе KDE.

> *Актуально ли сейчас складывать исполняемые файлы в %_K5bin или уже можно
> ориентироваться только на %_bindir ?
Актуально было и будет всегда.
Comment 50 Aleksei Kalinin 2023-07-03 20:09:23 MSK
(In reply to Grigory Ustinov from comment #48)
> Прошу прощения, что случайно подсмотрел... У вас коммиты как-то очень
> странно называются. На примере awesome: 🦭4.3-alt5. Я думал, что это
> опечатка в одном коммите, но потом глянул другие пакеты и там то же самое.
> Не прольёте ли немножко света на эту ситуацию?

Не нашел строго теребования к комитам и добавил "самодеятельность" подобного рода. Показалось символичным добавлять символ Нерпы в коммит там где код стал Альтом. Особенно это ярко выражено на кодовой базе https://git.altlinux.org/people/kaa/packages/python3-module-myst-parser.git

Как раз ждал замечаний-требований по этому решению. Разумеется исправлю если это неприемлемо.
Comment 51 Grigory Ustinov 2023-07-03 20:38:40 MSK
(Ответ для Aleksei Kalinin на комментарий #50)
> (In reply to Grigory Ustinov from comment #48)
> > Прошу прощения, что случайно подсмотрел... У вас коммиты как-то очень
> > странно называются. На примере awesome: 🦭4.3-alt5. Я думал, что это
> > опечатка в одном коммите, но потом глянул другие пакеты и там то же самое.
> > Не прольёте ли немножко света на эту ситуацию?
> 
> Не нашел строго теребования к комитам и добавил "самодеятельность" подобного
> рода. Показалось символичным добавлять символ Нерпы в коммит там где код
> стал Альтом. Особенно это ярко выражено на кодовой базе
> https://git.altlinux.org/people/kaa/packages/python3-module-myst-parser.git
> 
> Как раз ждал замечаний-требований по этому решению. Разумеется исправлю если
> это неприемлемо.

Насколько мне известно, строго требования к именованию релизных коммитов у нас действительно нет. Но тем не менее, Нерпа не везде отображается корректно. Когда я писал своё сообщение, я не вникал в суть символа и ориентировался просто на пустой квадратик.

Скажем так, я бы не хотел видеть смайлики в названиях коммитов "моих пакетов" как минимум. Как максимум, бог знает сколько людей думает так же и это можно вынести на широкое обсуждение=) Я думаю, что тут есть и ментор и рецензент и моё мнение будет явно лишним.

Как говорится "Я только спросить".
Comment 52 Aleksei Kalinin 2023-07-03 22:44:45 MSK
(In reply to Sergey V Turchin from comment #49)
> Содержимое коммитов не соответствует их описанию.
Сергей, верно. Моя ошибка. Порой нужен ревью при пуше. Спасибо, исправил.

> /usr/lib/rpm/macros.d/kf5
Да уже в курсе этого механизма и обратил внимание на "магию" цифры 5 в конце исполняемого файла. Но в случае kdiff3 и kstars "магия" не работает, и символическая ссылка не создается. Может быть делать ссылку самостоятельно  добавляя(<bin>-kde5 для пути /usr/bin) в spec? 

> kde3-kstars, kde4-kstars, kde5-kstars и kde6-kstars в одно место никак не положить.
> Но, конкретно kstars можно. Он уже и не в составе KDE.
Понял что причина появления этого механизма как раз развитие kde. Но тяжело смириться с неочевидным способом доступа для подобных приложений из терминала и, к примеру из Mate.
Для kstars, с Вашег одобрения, перенес в /usr/bin/kstars.

Можно ли для kdiff3 сделать символическую ссылку вида /usr/bin/kdiff3-kde5?
Или sh скрипт `kde5 kdiff3` с тем же именем /usr/bin/kdiff3-kde5.
Comment 53 Aleksei Kalinin 2023-07-03 23:38:08 MSK
(In reply to Grigory Ustinov from comment #51)
> (Ответ для Aleksei Kalinin на комментарий #50)
> > (In reply to Grigory Ustinov from comment #48)
> > > Прошу прощения, что случайно подсмотрел... У вас коммиты как-то очень
> > > странно называются. На примере awesome: 🦭4.3-alt5. Я думал, что это
> > > опечатка в одном коммите, но потом глянул другие пакеты и там то же самое.
> > > Не прольёте ли немножко света на эту ситуацию?
> > 
> > Не нашел строго теребования к комитам и добавил "самодеятельность" подобного
> > рода. Показалось символичным добавлять символ Нерпы в коммит там где код
> > стал Альтом. Особенно это ярко выражено на кодовой базе
> > https://git.altlinux.org/people/kaa/packages/python3-module-myst-parser.git
> > 
> > Как раз ждал замечаний-требований по этому решению. Разумеется исправлю если
> > это неприемлемо.
> 
> Насколько мне известно, строго требования к именованию релизных коммитов у
> нас действительно нет. Но тем не менее, Нерпа не везде отображается
> корректно. Когда я писал своё сообщение, я не вникал в суть символа и
> ориентировался просто на пустой квадратик.
> 
> Скажем так, я бы не хотел видеть смайлики в названиях коммитов "моих
> пакетов" как минимум. Как максимум, бог знает сколько людей думает так же и
> это можно вынести на широкое обсуждение=) Я думаю, что тут есть и ментор и
> рецензент и моё мнение будет явно лишним.
> 
> Как говорится "Я только спросить".

Да, тоже заметил не стабильное отрабатывание этого символа. До какого-то обновления у меня и терминал отображал этот символ. Сейчас нет. Не вникал в причины.

Разумеется для пакетов которые уже имеют мэйнтейнеров подобные вольности не позволительны. Что бы было понятно, предварительно отслеживаю стиль коммитов, стратегию ведения репозитория и после этого вношу какие-то изменения соблюдая стиль. Затронул лишь те пакет которые "отвалились" или "притянутые" лично мной.

По поводу обсуждения, не знаю стоит ли выносить подобное, и не знаю как. Но выглядит занятно.  = ) Если подобное не возбраняется, пока это могло бы стать особенностью моих пакетов.
Comment 54 Aleksei Kalinin 2023-07-03 23:52:45 MSK
Сергей Григорий Спасибо за Ваши комментарии.

Вы активно участвуете в моем баге. И частично знаком с предложенными в ходе обсуждения пакетами. Если не затруднит, и у кого-то из Вас найдется время, может быть Вы могли бы занять роль рецензента?
Если это возможно и секретарь не будет против.

В любом случае благодарен за участие!
Comment 55 Sergey V Turchin 2023-07-04 11:11:00 MSK
(Ответ для Aleksei Kalinin на комментарий #52)
> Сергей, верно. Моя ошибка. Порой нужен ревью при пуше. Спасибо, исправил.
А я уже обновил kde5-kstars. :-)

> Может быть делать ссылку самостоятельно 
> добавляя(<bin>-kde5 для пути /usr/bin) в spec? 
Да, конечно. Суть лишь в том, чтобы не конфликтовать с другими мажорными версиями KDE, т.к. одна и та же программа может быть востребована для своей среды. Такие жирные вещи типа kdenlive или krita я пакую только одну версию в стандартное место.
 
> Для kstars, с Вашег одобрения, перенес в /usr/bin/kstars.
Я уже.
 
> Можно ли для kdiff3 сделать символическую ссылку вида /usr/bin/kdiff3-kde5?
> Или sh скрипт `kde5 kdiff3` с тем же именем /usr/bin/kdiff3-kde5.
Скрипт может быть предпочтительнее, т.к. захватит /usr/share/kf5, из которого могут браться данные в процессе работы. Включая /usr/share/kf5/applications и т.д..
Comment 56 Sergey V Turchin 2023-07-04 11:12:51 MSK
(Ответ для Aleksei Kalinin на комментарий #52)
> Для kstars, с Вашег одобрения, перенес в /usr/bin/kstars.
Так правильнее https://git.altlinux.org/gears/k/kde5-kstars.git?p=kde5-kstars.git;a=commitdiff;h=0b6756f8798de7cf9b5d324ee4de5a090b00c4c6
Comment 57 Aleksei Kalinin 2023-07-04 23:11:15 MSK
(In reply to Sergey V Turchin from comment #55)
> (Ответ для Aleksei Kalinin на комментарий #52)
> А я уже обновил kde5-kstars. :-)
Да ещё вчера заметил новую для меня ошибку сборочницы:
kde5-kstars' version `1:3.6.5-alt1' was built earlier for sisyphus from a different source: `gear:cc19dae9cd4c565563a934d30c20c93903dbfc6d'
не сразу понял, подумал что сам в другую задачу запустил. Только потом поискал по задачам https://packages.altlinux.org/en/tasks/search/?q=kde5-kstars нашел собранный пакет. = )
Познакомился с изменениями. Согласен, выглядит более изящно, стоило догадаться что надо учесть взаимоисключаемость с kde4 -_- Учту.

> Скрипт может быть предпочтительнее, т.к. захватит /usr/share/kf5, из
> которого могут браться данные в процессе работы. Включая
> /usr/share/kf5/applications и т.д..
Внес изменения, исправленный вариант запустил на тест:
https://git.altlinux.org/tasks/323889/
Comment 58 Sergey V Turchin 2023-07-05 11:45:26 MSK
(Ответ для Aleksei Kalinin на комментарий #57)
> стоило догадаться что надо учесть взаимоисключаемость с kde4 -_- Учту.
Не только. Файлы данных тоже переехали, иначе по умолчанию были бы недоступны самому приложению.
Comment 59 Aleksei Kalinin 2023-07-11 00:31:22 MSK
UP

Заметил что "отвалился" python модуль admesh https://packages.altlinux.org/en/sisyphus/srpms/python-module-admesh/, попутно заметил давно не обновлялся пакет admesh.
Учитывая тенденцию на завершение пддержики python2 вырезал связанный с ним функционал и подновил spec.

Изменения тут:
https://git.altlinux.org/tasks/324627/

Буду благодарен за исправления рекомендации!
Comment 60 Aleksei Kalinin 2023-07-12 17:42:38 MSK
Исправлена ошибка связанная с утилитой girar-show пакет girar-utils.

В истории git этого пакета два вида добавления коммитов, с разделением bump версии и исправления spec, и совмещенное исправление и поднятие версии.

Поскольку мои правки не значительны и проблема решается в одну строку, исправления в spec и саму ошибку объединил в один коммит.
Есть ли какое-то строгое правило на этот счет или подобного рода подход считается приемлемым? 

https://git.altlinux.org/tasks/324696
Comment 61 Иван Савин 2023-07-12 18:29:15 MSK
(Ответ для Aleksei Kalinin на комментарий #60)
> Исправлена ошибка связанная с утилитой girar-show пакет girar-utils.
> 
> В истории git этого пакета два вида добавления коммитов, с разделением bump
> версии и исправления spec, и совмещенное исправление и поднятие версии.
> 
> Поскольку мои правки не значительны и проблема решается в одну строку,
> исправления в spec и саму ошибку объединил в один коммит.
> Есть ли какое-то строгое правило на этот счет или подобного рода подход
> считается приемлемым? 
> 
> https://git.altlinux.org/tasks/324696

В истории коммитов этого пакета подобное есть. Значит, теоретически, так можно.

Алексей, сколько ты уже пакетов подготовил? Думаю нужно остановиться и дождаться решения рецензента.
Comment 62 Aleksei Kalinin 2023-07-19 20:01:13 MSK
(In reply to Иван Савин from comment #61)
> (Ответ для Aleksei Kalinin на комментарий #60)

> Алексей, сколько ты уже пакетов подготовил? Думаю нужно остановиться и
> дождаться решения рецензента.

Иван, если не ошибаюсь 14 было заявлено в этой задаче для Join. Подвел резюме. В списке исправленные, обновленные и новые пакеты. Некоторые уже потеряли актуальность, что ярко отражает один из аспектов названия репозитория sisyphus. = )
Буду ожидать рецензента. Спасибо!

- libvirt - первый пакет взятый с https://git.altlinux.org/beehive/stats/Sisyphus-x86_64/ftbfs-joined
    + Исправлена ошибка (лог уже "прокис") решение взято с upstream
    + Был оформлен https://gitlab.com/faktor.lex/libvirt.git
    + Не актуален. На данный момент уже неоднократно обновлен Alexey Shabalin
    
- sweethome3d - наткнулся на ошибку, оформил https://bugzilla.altlinux.org/43326
    + Исправлена ошибка обновлен пакет до версии 6.6.4
    + Не актуален. Evgeny Sinelnikov отправил в сизиф и обновил до 7.0

- flam3 - Брошенный пакет взятый с https://git.altlinux.org/beehive/stats/Sisyphus-x86_64/ftbfs-joined существовали ошибки при сборке 
    + Ошибки исправлены в соответствии с рекомендациями
    + Оформлена задача https://git.altlinux.org/tasks/311827/
    + На данный момент ждет подтверждения-одобрения

- awesome - взят как "брошенный" пакет, присутствовали ошибки сборки
    + Ошибки исправлены
    + Оформлен в задачу https://git.altlinux.org/tasks/313370/
    + Не актуален. Konstantin Lepikhov отреагировал на ACL оповещения оформил, отправил пакет
    
- python3-module-myst-parser - обновлен брошенный пакет
    + Взят для знакомства, пакет обновлен. Возникли проблемы с тестированием тесты были отключены
    + Оформлен http://git.altlinux.org/people/kaa/packages/python3-module-myst-parser.git
    + Не актуален. На данный момент пакет обновил и "забрал" Andrey Limachko

- rapidjson - обновлен по до необходимого функционала требующегося для пакета OpenTimeLineIO
- any - оформлен в пакет, необходим для сборки OpenTimeLineIO
- optional-lite - оформлен в пакет, необходим для сборки OpenTimeLineIO
- pyaaf2 - оформлен в пакет, необходим для функционирования OpenTimeLineIO
- OpenTimeLineIO - Взят по обращению в https://bugzilla.altlinux.org/42109.
   + Собран в разнличных исполнения реализации под модулей. Обновлен после первой сборки. Добавлено тестирование пакета.
   + Оформлена задача https://git.altlinux.org/tasks/321695/ последний вариант реализации под модулей -- пакетами

- kdiff3 - пакет давно не обновлялся 
    + Пакет обновлен внесены изменения в соответствии с рекомендациями
    + Оформлена задача https://git.altlinux.org/tasks/32388/
    + На данный момент ждет подтверждения-одобрения для принятия в sisyphus

- kde5-kstars - пакет давно не обновлялся 
    + Пакет обновлен внесены изменения в соответствии с рекомендациями
    + Оформлена задача https://git.altlinux.org/tasks/323974/
    + Не актуален. На данный момент Sergey V Turchin обновил и внес 

- admesh - пакет давно не обновлялся и "отвалился" от sisyphus https://packages.altlinux.org/en/tasks/156814/
    + Пакет обновлен
    + Оформлена задача https://git.altlinux.org/tasks/324627/
    + На данный момент ждет подтверждения-одобрения

- girar-utils - столкнулся с ошибкой утилиты, существовал отчет об ошибке https://bugzilla.altlinux.org/39207
    + Ошибка исправлена
    + Оформлена задача https://git.altlinux.org/tasks/324696
    + Не актуален. Andrey Cherepanov одобрил исправления.
Comment 63 Gleb F-Malinovskiy 2023-09-10 13:25:34 MSK
Призван рецензент (rider@) для независимой оценки готовности кандидата.

T/J/S -> 4.2.
Comment 64 Anton Farygin 2023-09-11 09:05:35 MSK
- flam3 - Брошенный пакет взятый с https://git.altlinux.org/beehive/stats/Sisyphus-x86_64/ftbfs-joined существовали ошибки при сборке 
    + Ошибки исправлены в соответствии с рекомендациями
    + Оформлена задача https://git.altlinux.org/tasks/311827/
    + На данный момент ждет подтверждения-одобрения

Я ещё бы перенёс 
  60 %define _stripped_files_terminate_build 1
  61 %define _unpackaged_files_terminate_build 1

в начало specfile - так лучше читается.
Comment 65 Anton Farygin 2023-09-11 09:15:47 MSK
https://git.altlinux.org/tasks/321695
rapidjson: не нравится мне идея в rules паковать по тэг c release. Лучше сделать diff по тэгу и приложить патч в specfile. Так и изменения будут нагляднее, и лишнего в тарболле не будет.


any: мне в принципе не нравится такой формат репозитория - предлагаю сделать по аналогии с rapidjson, когда наши изменения живут в одном дереве с апстримом и патчи делаются через diff в .gear/rules

В данном случае ещё у апстрима нет релиза, поэтому можно просто запаковать весь проект не по тэгу, а изменения закоммитить прямо в ветку и отдать в апстрим.
Comment 66 Anton Farygin 2023-09-11 09:18:33 MSK
https://git.altlinux.org/tasks/321695:

optional-lite репозиторий тоже надо переделать поверх апстримного, тарболл делать из апстримного тэга. Зачем в release указан ещё git коммит непонятно.
Comment 67 Anton Farygin 2023-09-11 09:56:48 MSK
https://git.altlinux.org/tasks/321695:

pyaaf2 - проверки у пакетов python отключать крайне нежелательно, лучше чинить. 

Непонятная мне конструкция:
%if "%python3_sitelibdir_noarch" != "%python3_sitelibdir"
install -d %buildroot%python3_sitelibdir
mv %buildroot%python3_sitelibdir_noarch/* \
       %buildroot%python3_sitelibdir/
%endif

зачем она ? 
В спеке два раза продублирован URL на github (один в комментарии, зачем непонятно)

Запись в changelog - если пишете с большой буквы, то ставьте точку в конце.

в rules:
tar: v@version@:. name=@name@-@version@ base=@name@-@version@
name= и base= можно просто убрать, тоже непонятно зачем они здесь нужны.
Comment 68 Anton Farygin 2023-09-11 09:59:05 MSK
https://git.altlinux.org/tasks/321695/
Большинство предыдущих замечаний касается и python3-module-OpenTimelineIO-gen3.git
Нужно переделать в соотвествии с предыдущими замечаниями и написать мне в личке (телеграм желательно) - я посмотрю.
Comment 69 Anton Farygin 2023-09-11 10:08:26 MSK
kdiff3
https://packages.altlinux.org/ru/tasks/323889/
непонятно как был сделан merge. Выглядит очень странно. Я бы его переделал.

Из commit message непонятно зачем понадобилось это изменение:

Allows execute kdiff3 from terminal with 'kdiff3-kde5' name

И почему оно не запускается как kdiff3
Comment 70 Anton Farygin 2023-09-11 10:10:51 MSK
kde5-kstars:
https://git.altlinux.org/tasks/323974/
просьба посмотреть @zerg
Comment 71 Anton Farygin 2023-09-11 10:20:21 MSK
admesh https://packages.altlinux.org/en/tasks/156814/
Убрать тэг Packager и дубли URL в спеке (комментарий)
и я бы ещё убрали COPYING из файлов пакета, т.к. лицензия стандартная.
Плюс тэг License привести в единообразие с версией лицензии в тексе COPYING
Comment 72 Sergey V Turchin 2023-09-11 12:04:23 MSK
(Ответ для Anton Farygin на комментарий #70)
> kde5-kstars:
> https://git.altlinux.org/tasks/323974/
> просьба посмотреть @zerg
Я уже давно сам обновил.
Comment 73 Sergey V Turchin 2023-09-11 15:07:30 MSK
(Ответ для Anton Farygin на комментарий #69)
> kdiff3
> https://packages.altlinux.org/ru/tasks/323889/
> непонятно как был сделан merge. Выглядит очень странно. Я бы его переделал.
Да. На https://invent.kde.org/sdk/kdiff3/-/commits/1.10.4 непохоже.

> Из commit message непонятно зачем понадобилось это изменение:
> Allows execute kdiff3 from terminal with 'kdiff3-kde5' name
> И почему оно не запускается как kdiff3
По крайней мере,
%_bindir/%name-kde5
пакуется независимо от того, существует или нет, хотя создаётся по условию.
Comment 74 Anton Farygin 2023-09-28 16:06:02 MSK
https://packages.altlinux.org/ru/tasks/324627/ 

approve выписан - замечания применены.
Comment 75 Aleksei Kalinin 2023-10-12 20:03:58 MSK
Актуализирую статус и небольшое резюме

Список рекомендаций от рецензента:
 - Указать значения «Url:» «Vcs:» спек файла, удалить дубли комментариев.
 - Исключать файлы копирайта (COPYING, LICENSE). В случае если в spec файле для тэга «License:» лицензия полностью соответствует содержимому этих файлов.
 - Именование патчей в соответствии с рекомендациями «Наименование патчей.» https://www.altlinux.org/%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%B0_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8F_%D1%81%D0%BF%D0%B5%D0%BA_%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2_%D0%B2_ALT_Linux
 - Приведение стратегии ведения репозитория c единым рабочим деревом(worktree) и alt инструкциями в директории .gear.
 - Подключение внешней кодовой базы(upstream), если отсутствовала.
 - Использовать конструкцию «diff: v@version@:. .  exclude=.gear/**», в случае необходимости использования промежуточного релиза.
	
Исправления и замечания применены к списку актуальных для сборки пакетов.
	
Список пакетов одобренных рецензентом:
- flam3 - брошенный пакет "отвалился" от sisyphus по причине ошибки сборки.
Одобрен рецензентом https://packages.altlinux.org/en/sisyphus/srpms/flam3/

- rapidjson - обновлен по до необходимого функционала требующегося для пакета OpenTimeLineIO
Одобрен рецензентом  https://packages.altlinux.org/en/sisyphus/srpms/rapidjson/

- any - оформлен в пакет, необходим для сборки OpenTimeLineIO
Одобрен рецензентом https://packages.altlinux.org/en/sisyphus/srpms/any/

- optional-lite - оформлен в пакет, необходим для сборки OpenTimeLineIO
Одобрен рецензентом https://packages.altlinux.org/en/sisyphus/srpms/optional-lite/

- pyaaf2 - оформлен в пакет, необходим для функционирования OpenTimeLineIO
Одобрен рецензентом https://packages.altlinux.org/en/sisyphus/srpms/python3-module-pyaaf2/

- OpenTimeLineIO - Взят по обращению в https://bugzilla.altlinux.org/42109.
 Одобрен рецензентом https://packages.altlinux.org/en/sisyphus/srpms/python3-module-OpenTimelineIO/

- admesh - пакет давно не обновлялся и "отвалился" от sisyphus
Одобрен рецензентом: https://packages.altlinux.org/en/sisyphus/srpms/admesh/
	             https://packages.altlinux.org/en/sisyphus/srpms/python3-module-admesh/

Дополнительно для сборки предложен пакет libreoffice-online выпавший из sisyphus (обшибкой сборки)
Подготовлен патч исправления. Версия 6.2.3.2 нормально собирается как для P10 так и для Sisyphus. Поскольку проект libreoffice-online давно не поддерживается взят форк collabora-online  https://git.altlinux.org/tasks/331510
Разбираюсь с работой в рижиме сервиса в alt.
Comment 76 Aleksei Kalinin 2023-10-26 17:20:18 MSK
collabora-online собрана проверена одобрена rider для sisyphus

Взята на самая свежая версия исходников так как она соответствует существующему в sisyphus libreofficekit.
Пакет ориентирован на работу в изолированном окружении, и предполагает повышенные разрешения.
Было принято решение отдать выбор пользователю --- сделан вывод с предупреждениями и рекомендациями при установке пакета.

Исключены инструкции дублирующие filetriggers. 

Вообще было бы хорошо провести полноценное тестирование этой махины, но у меня нет такой возможности.
Comment 77 Aleksei Kalinin 2023-10-26 17:24:56 MSK
Дополнительно для обновления был выдан пакет libopencv.

Столкнулся с проблемой не хватки места на git.altlinux.org/people/kaa/
write error: Disk quota exceeded

Возможно ли увеличить место?

На данный моемнт, что бы не тратить время удалил всё.
Comment 78 Sergey V Turchin 2023-10-26 17:29:00 MSK
(Ответ для Aleksei Kalinin на комментарий #76)
> Взята на самая свежая версия исходников так как она соответствует
> существующему в sisyphus libreofficekit.
Лучше ориентироваться на libreofficekit-still. Он стабильнее и новее.
Comment 79 Aleksei Kalinin 2023-10-27 19:44:22 MSK
@glebfm прошу помощи с дисковой квотой "Disk quota exceeded"
Удалил все что было
Сейчас для меня актуально 2 пакета.
Но места нехватает.
$ ssh gitery quota
     Filesystem   space   quota   limit   grace   files   quota   limit   grace
     /dev/simfs    977M*   977M   1465M    none     122    100k    150k
Хитростями получилось протолкнуть тэг, а ветку поумолчанию не могу обозначить.
$ ssh  gitery default-branch /people/kaa/packages/libopencv.git sisyphus
error: unable to write symref for HEAD: Disk quota exceeded
Comment 80 Aleksei Kalinin 2023-10-27 19:55:09 MSK
(In reply to Sergey V Turchin from comment #78)
> (Ответ для Aleksei Kalinin на комментарий #76)
> > Взята на самая свежая версия исходников так как она соответствует
> > существующему в sisyphus libreofficekit.
> Лучше ориентироваться на libreofficekit-still. Он стабильнее и новее.

Приветствую Сергей!

На момент сборки новее был именно libreofficekit 7.6.2.1-alt1, а *-still 7.5.7.1-alt3
А для collabora-online нужны еще более свежие дополнения из collabora-office поэтому пришлось некоторый функционал исключать патчами.
И как уже писал, из-за этого не стал брать самую свежую версию. 
Можно конечно отдельно притянуть "в комплекте" libreofficekit...
Comment 81 Aleksei Kalinin 2023-11-09 02:27:22 MSK
(In reply to Aleksei Kalinin from comment #77)
> Дополнительно для обновления был выдан пакет libopencv.

Пакет libopencv обновлен до версии 4.8.1. Спасибо за дополнения @slev.
https://bugzilla.altlinux.org/47843
 
> Столкнулся с проблемой не хватки места на git.altlinux.org/people/kaa/
> write error: Disk quota exceeded

Спасибо проблема с квотой решена. Спасибо @rider и @ldv
Comment 82 Aleksei Kalinin 2023-11-09 10:07:02 MSK
На данный момент в рамках энжойн в sisyphus принято 13 пакетов под моим именем.
Задача отнимает слишком много времени. Меня устраивает возможность вносить изменения в пакеты с одобрения зинтересованных мэйнтейнеров.

Всем спасибо за помощь и участие!
Comment 83 Sergey V Turchin 2023-11-09 11:51:23 MSK
> WONTFIX
Это может означать удаление ключей. Да и резолвит баг тот, кому он назначен.
Comment 84 Evgeny Sinelnikov 2023-11-09 11:59:32 MSK
У меня вопрос...

А какие ещё должен проявить навыки Алексей, чтобы его приняли в ALT Linux Team?

По-моему, он достаточно много провёл работы, чтобы рецензент одобрил его кандидатуру.
Comment 85 Anton Farygin 2023-11-09 12:01:11 MSK
Много очень ошибок возникает при сборке.
Несовместимых с самостоятельной сборкой пакетов в репозиторий.
Comment 86 Anton Farygin 2023-11-09 12:02:25 MSK
при этом итоговый результат всех устраивает, но без review Алексею пока пакеты в репозиторий лучше не отправлять.
Comment 87 Sergey V Turchin 2023-11-09 12:10:49 MSK
(Ответ для Evgeny Sinelnikov на комментарий #84)
> WONTFIX → LATER


(Ответ для Sergey V Turchin на комментарий #83)
> Да и резолвит баг тот, кому он назначен.
:-)
Comment 88 Evgeny Sinelnikov 2023-11-09 12:12:00 MSK
(Ответ для Anton Farygin на комментарий #85)
> Много очень ошибок возникает при сборке.
> Несовместимых с самостоятельной сборкой пакетов в репозиторий.

Какие конкретно ошибки, по каким конкретно пакетам проявлены и не исправлены, чтобы можно было уверенно заявить, что работа данного кандидата несовместима с "с самостоятельной сборкой пакетов в репозиторий"?

Насколько я вижу все пакеты исправлены по достаточно противоречивым требованиям разных мейнтейнеров. При этом освоены такие схемы сборки, которыми не обладают некоторые бывалые люди в Team.
Comment 89 Anton Farygin 2023-11-09 12:20:51 MSK
Ну из последнего, что я помню - при сборке python модуля не разобрался с межпакетными зависимостями и сделал наоборот - вместо добавления нужного provides загасил requires.

Ну и совсем банальные, вроде намешанных изменений из разных коммитов. Из-за невнимательности.
Comment 90 Evgeny Sinelnikov 2023-11-09 12:45:44 MSK
"Пусть первый, кто тут без греха, бросит в него камень".

Это всё не конкретные примеры. Ссылки, пожалуйста...

Хотя это бесполезно. Считаю данное мнение предвзятым.

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

Сейчас предлагаю сфокусироваться на конкретных деталях:
- взять очередной пакет из требований рабочего процесса;
- разобрать уже сложившиеся в выбранном пакете проблемы, накопленные более "опытными" и "достойными" товарищами;
- подготовить его сборку, обновление или исправление.

По результатам будем разбирать где, когда и кем в данном пакете осуществлены некомпетентные и банальные ошибки. И уже из этих исправлений тогда делать выводы.
Comment 91 Anton Farygin 2023-11-09 13:30:34 MSK
Какие ссылки ? git уже давно переписан. 

Ну раз вы считаете моё мнение предвзятое, то с данным ментейнером разбирайтесь сами.
Comment 92 Иван Савин 2023-11-09 14:13:55 MSK
(Ответ для Anton Farygin на комментарий #91)
> Какие ссылки ? git уже давно переписан. 
> 
> Ну раз вы считаете моё мнение предвзятое, то с данным ментейнером
> разбирайтесь сами.

Прошу рецензента указать причину возврата к пункту 3.5.
По каким вопросам требуется дополнительная работа?
Comment 93 Anton Farygin 2023-11-09 14:18:26 MSK
Не могу быть рецензентом данного кандидата в связи с обвинениями в предвзятости.

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

Рекомендую следующему рецензенту посмотреть как кандидат самостоятельно, без чужой помощи, собирает новые и обновляет существующие пакеты.
Comment 94 Иван Савин 2023-11-09 18:38:44 MSK
Прошу секретаря призвать рецензента.
Comment 95 Aleksei Kalinin 2023-11-13 21:22:18 MSK
По поводу самостоятельности считаю необходимым расставить акценты

Перечислю пакеты которые собраны только в рамках процедуры join с самого начала.

libvirt
 - пакет висел в состоянии ошибки на ftbfs.
 - самостоятельно разобрался нашел решение в upstream.
 - с наставником в рамках знакомства с инструментами alt был оформлен в пакет.

sweethome3d https://packages.altlinux.org/en/sisyphus/srpms/sweethome3d/
 - столкнулся с ошибкой оформил баг https://bugzilla.altlinux.org/43326
    + подготовил оформил исправления
 - по рекомендации и с правками и под руководством наставника обновил пакет
 - пакет был принят в sisyphus

flam3 https://git.altlinux.org/gears/f/flam3.git?p=flam3.git;a=shortlog
 - пакет не поддерживается upstream'ом висел в состоянии ошибки на ftbfs.
    + исправлены ошибки, проверена работоспособность, собран
 - Alexey Shabalin добавил замечания обозначенные в issue upstream
    + разобрался замечаниями внес исправления в сборочные инструкции
 - обратил внимание на необходимость маскировать макросы для changlog "%%"
 - изучил механизм check-git-inheritance
 - пожелание от рецензента по рефракторингу spec (макросы перенесены в начало файла)
 (In reply to Anton Farygin from comment #64)
> Я ещё бы перенёс
>   60 %define _stripped_files_terminate_build 1
>   61 %define _unpackaged_files_terminate_build 1
 - дополнительные пожелания рецензента в telegram переписке о переработке структуры ведения пакета
    + переделана стратегия ведения пакета:
        * изменено worktree (исходники перенесены из каталога flam3 в корень проекта)
        * подключена git-история upstream'ного проекта
        * взят последний commit из upstream
        * средствами diff в rules патчем наложен на кодовую базу релиза upstream
    + все патчи переименованы в соответствии с рекомендациями с alt wiki

awesome https://git.altlinux.org/tasks/313370/gears/100/git?p=git;a=commitdiff;h=7c5d75a83fa211244f8c058d1b2969cdcb4498d3
 (хороший пример как по разному решают проблемы и используют разные фишки)
 - висел в состоянии ошибки на ftbfs.
    + разобрался с ошибкой внес правки в spec
 - Konstantin Lepikhov отреагировал на ACL оповещения, иначе оформил и отправил пакет

python3-module-myst-parser
 - висел на ftbfs
    + пакет был обновлен до последней актуальной версии
    + актуализирован spec в соответствии современными сборочными python макросами
    + подключены тесты (возникли проблемы с тестированием некоторые тесты добавлены в игнорир)
 - за время ожидания ревью пакет пакет забрал Andrey Limachko

rapidjson https://git.altlinux.org/gears/r/rapidjson.git?p=rapidjson.git;a=shortlog
 - обновлялся до необходимого функционала требующегося для пакета OpenTimeLineIO
    (upstream не выпускал релизы с 2016 года, но ведет активную разработку по сей день)
    + пакет был обновлен до промежуточного релиза и собирался по gear тэгу с учетом необходимых изменений
        * взят upstream commit с необходимыми изменениями для OpenTimeLineIO
    + был соблюден изначальный стиль ведения репозитория
 - пожелание от рецензента по реструктуризации: переделана стратегия ведения git репозитория и стратегия сборки средствами gear
 rules
(In reply to Anton Farygin from comment #65)
> https://git.altlinux.org/tasks/321695
> rapidjson: не нравится мне идея в rules паковать по тэг c release. Лучше
> сделать diff по тэгу и приложить патч в specfile. Так и изменения будут
> нагляднее, и лишнего в тарболле не будет.
 - дополнительные пожелания рецензента в telegram переписке о переработке структуры ведения пакета
    + согласовать с мэйнтейнером и после переделать стиль и стратегию ведения репозитория
    + переделана стратегия изменено worktree
        * empty branch(-s ours) изменена на ведение кодовой базы в корневом каталоге
        * инструкции для сборки alt и патчи перенесены в .gear
    + убраны комментарии ссылки до upstream, в пользу тега "Vcs:"
    + переделал spec: изменены пути для пакета rapidjson-doc

any https://git.altlinux.org/gears/a/any.git?p=any.git;a=shortlog
 - пакет собран с нуля т.к. необходим для OpenTimeLineIO
    + выбрана стратегия -s ours т.к. показалась удобной
    + upstream не вел релизных теэгов пакет собирался до последнего commitа
    + добавлены cmake инструкции для идентификации заголовочных файлов
 - пожелание от рецензента по реструктуризации --- переделана стратегия ведения git репозитория
(In reply to Anton Farygin from comment #65)
> any: мне в принципе не нравится такой формат репозитория - предлагаю сделать
> по аналогии с rapidjson, когда наши изменения живут в одном дереве с
> upstream и патчи делаются через diff в .gear/rules
 - дополнительные пожелания рецензента в telegram переписке
    + исправлена версия с 0.0.0-alt1 на 0-alt1
    + удалить дубль c тэгом Url: комментария на upstream

optional-lite https://git.altlinux.org/gears/o/optional-lite.git?p=optional-lite.git;a=shortlog
 - пакет собран с нуля т.к. необходим для OpenTimeLineIO
    + выбрана стратегия -s ours т.к. показалась удобной
    + upstream давно не вел релизных теэгов пакет собирался из промежуточного commitа
 - пожелание от рецензента по реструктуризации: пределана стратегия ведения git репозитория и стратегия сборки средствами gear rules
 - в release указан git commit в соответствии с инструкциями
https://www.altlinux.org/Spec#%D0%9F%D1%80%D0%BE%D0%BC%D0%B5%D0%B6%D1%83%D1%82%D0%BE%D1%87%D0%BD%D1%8B%D0%B5_upstream-%D1%80%D0%B5%D0%BB%D0%B8%D0%B7%D1%8B
(In reply to Anton Farygin from comment #66)
> https://git.altlinux.org/tasks/321695:
>
> optional-lite репозиторий тоже надо переделать поверх апстримного, тарболл
> делать из апстримного тэга. Зачем в release указан ещё git commit непонятно.
 - дополнительные пожелания рецензента в telegram переписке
   + удалил дублирование c тэгом Url: комментария на git upstream

pyaaf2 https://git.altlinux.org/gears/p/python3-module-pyaaf2.git?p=python3-module-pyaaf2.git;a=shortlog
 - пакет собран с нуля т.к. необходим для OpenTimeLineIO
(In reply to Anton Farygin from comment #67)
> https://git.altlinux.org/tasks/321695:
>
> pyaaf2 - проверки у пакетов python отключать крайне нежелательно, лучше
> чинить.
>
> Непонятная мне конструкция:
> %if "%python3_sitelibdir_noarch" != "%python3_sitelibdir"
> install -d %buildroot%python3_sitelibdir
> mv %buildroot%python3_sitelibdir_noarch/* \
>        %buildroot%python3_sitelibdir/
> %endif
>
> зачем она ?
> В спеке два раза продублирован URL на github (один в комментарии, зачем
> непонятно)
>
> Запись в changelog - если пишете с большой буквы, то ставьте точку в конце.
>
> в rules:
> tar: v@version@:. name=@name@-@version@ base=@name@-@version@
> name= и base= можно просто убрать, тоже непонятно зачем они здесь нужны.
    + убрал %def_disable check так как необходимость отпала
    + конструкция %if была сделана от непонимания, как сборочное окружение раскладывает по нативным путям модули разбирался сам. Решение оказалось простым BuildArch: noarch т.к. пакет действительно не зависит от архитектуры.
    + дублирование upstream тэга взято из образцов spec и показалось удобным рядом с секцией Sources --- удалено по желанию рецензента
    + точки в changelog проставлены
    + tar: v@version@:. name=@name@-@version@ base=@name@-@version@ взяты как основа в соответствии с примерами --- удалено по желанию рецензента

OpenTimeLineIO https://git.altlinux.org/gears/p/python3-module-OpenTimelineIO.git?p=python3-module-OpenTimelineIO.git;a=shortlog
 - пакет собран с нуля
 - было собрано 3 варианта реализации под модулей в соответствии с примерами найденными в дистрибутиве
    + бинарно-запакованные под модули в соответствии с заложенными разработчиками кодовыми срезами
    + включение git истории под модулей и создание тарболов по gear tag
    + конечный вариант сборка всех под модулей пакетам и обновление уже существующих пакетов
    + выбрана стратегия -s ours т.к. показалась удобной
(In reply to Anton Farygin from comment #68)
> https://git.altlinux.org/tasks/321695/
> Большинство предыдущих замечаний касается и
> python3-module-OpenTimelineIO-gen3.git
> Нужно переделать в соответствии с предыдущими замечаниями и написать мне в
> личке (телеграм желательно) - я посмотрю.
 - пожелание от рецензента по реструктуризации: переделана стратегия ведения git репозитория
 - удалил дубль c тэгом Url: комментария на upstream
 - дополнительные пожелания рецензента в telegram переписке
    + все патчи переименованы в соответствии с рекомендациями с alt wiki

kdiff3 https://git.altlinux.org/tasks/323889/gears/40/git?p=git;a=shortlog
 - пакет попросили обновить коллеги
    + обновлен до 1.10.4 используется из сборочной задачи
    + удален патч примененный в upstream изменениях
    + добавлена возможность использовать в терминале отличном от среды kde
 - что бы не аффектить нативного мэйнтенера оставлен в предложном виде
(In reply to Anton Farygin from comment #69)
> kdiff3
> https://packages.altlinux.org/ru/tasks/323889/
> непонятно как был сделан merge. Выглядит очень странно. Я бы его переделал.
>
> Из commit message непонятно зачем понадобилось это изменение:
>
> Allows execute kdiff3 from terminal with 'kdiff3-kde5' name
>
> И почему оно не запускается как kdiff3
 - Allows execute kdiff3 from terminal with 'kdiff3-kde5' name считаю понятным. Проблема заключается в историческом развитии kde и специфики путей для исполняемых файлов связанных с kde. Как верно заметил Sergey V Turchin:
  (In reply to Sergey V Turchin from comment #73)
> По крайней мере,
> %_bindir/%name-kde5
> пакуется независимо от того, существует или нет, хотя создаётся по условию.
 
 - для случаев исполняемых файлов заканчивающихся на -kde5 существуют сборочные макросы, которые самостоятельно делают симлинки в bindir, но этот случай не работает с kdiff3. Поэтому для упрощения пользования из консоли(минуя конструкцию $ kde5 kdiff3 ) было применено исправление в виде скрипта по рекомендации Sergey V Turchin.

kde5-kstars 
 - взят для привлечения внимания к join
    + обновлен до версии 3.6.5
 - оставлен по причине обновления нативным мэйнтейнером Sergey V Turchin

admesh https://git.altlinux.org/gears/a/admesh.git?p=admesh.git;a=shortlog
 - давно не обновлялся висел на ftbfs
    + обновлен до последних версий в соответствии соблюдением изначального стиля ведения репозитория
(In reply to Anton Farygin from comment #71)
> admesh https://packages.altlinux.org/en/tasks/156814/
> Убрать тэг Packager и дубли URL в спеке (комментарий)
> и я бы ещё убрали COPYING из файлов пакета, т.к. лицензия стандартная.
> Плюс тэг License привести в единообразие с версией лицензии в тексе COPYING
    + COPYING убран из секции %doc лицензия поправлена
    + убран тэг Packager от предыдущего мэйнтенера
    + все патчи переименованы в соответствии с рекомендациями с alt wiki
    + удалена пустая секция %doc

python3-module-admesh https://git.altlinux.org/gears/p/python3-module-admesh.git?p=python3-module-admesh.git;a=shortlog
 - давно не обновлялся висел на ftbfs пакет связан с  admesh
    + обновлен с учетом актуальных макросов сборки python
    + исключена поддержка python2
    + подготовлен патч исправления инструкции tox.ini для работоспособности самотестирования средствами актуального %tox_check_pyproject
 - пожелания рецензента схожие с пакетом admesh
    + убран тэг Packager от предыдущего мэйнтенера
    + патч переименованы в соответствии с рекомендациями с alt wiki
    + COPYING убран из секции %doc

girar-utils https://git.altlinux.org/gears/g/girar-utils.git?p=girar-utils.git;a=shortlog
 - столкнулся с ошибкой утилиты, существовал отчет об ошибке https://bugzilla.altlinux.org/39207
    + ошибка исправлена
    + spec оформлен в соответствии со стилем ведения пакета
 - принят в sisyphus Andrey Cherepanov

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

libreoffice-online {удален по причине нехватки места для новых пакетов}
 - выпал из sisyphus c ошибкой, рецензентом предложено исправить
    + ошибка исправлена патчем
    + протестирована сборка в sysiphus и p10
 - рецензентом предложено обновить пакет
 - поскольку проект libreoffice-online давно не поддерживается, рецензентом предложен для сборки форк collabora-online

collabora-online https://git.altlinux.org/gears/c/collabora-online.git?p=collabora-online.git;a=shortlog
 - предложено рецензентом собрать в замен libreoffice-online
    + в ходе изучения найдена оптимальная свзяка с собранным в sisyphus на момент самым актульным libreoffice-7.6.2.1 как backend и collabora-online-23.05.4.2 для пакета подготовлен соответсвующий патч для обеспечения работоспособности связки
    + разобрался в системы кеширвания из-за, связанных проблем с этим механизмом
        * исправлена ошибка в коде пакета решающая проблему работоспособности механизма в alt
    + пакет собран в соответствии с рекомендациями разработчика касаемо разрешений безопасности
    + протестирован в режиме работы сервиса
 - по причине наличия потенциальной проблемы безопасности поставлен на обсуждение с рецензентом в тестовом варианте
    + в ходе тестирования предложено предоставить решение о расширении разрешений безопасности для исполняемых файлов пакета самому пользователю пакета, с рекомендацией вывода при сборке.
 - по рекомендации рецензента
    + вывод с предложением-предупреждением перенесен в отдельный файл README.alt
    + удалены init скрипты
    + исключены инструкции дублирующие filetriggers(проверено отрабатывает)
    + убран define пере обозначающий %_localstatedir(был задублирован в ходе подбора путей)

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

libopencv https://git.altlinux.org/gears/l/libopencv.git?p=libopencv.git;a=shortlog
 - предложено рецензетом обновить в рамках https://bugzilla.altlinux.org/47843
    + обновлен до версии 4.8.1 с сохранением стиля ведения репозитория
 - столкнулся с уже существовавшей проблемой предоставления провайдов
    + в виду недостаточных знаний обозначил проблему в отчете об ошибке -- Stanislav Levin помог разобраться в причинах
    + доработки и рекомендации Stanislav Levin оформлены в пакет
 - по рекомендации рецензента
    + изменена форма changelog взятая из устаревшей документации

dhcpd https://git.altlinux.org/gears/d/dhcp.git?p=dhcp.git;a=shortlog
 - предложено рецензентом закрыть ошибку обозначенную https://bugzilla.altlinux.org/36509
    + предложенные исправление применены в том виде в котором описаны в баге
 - возникли различные пожелания от Михаила Ефремов и Евгения Синельникова касаемо контрола предложенного в патче бага
    + в ходе беседы с заинтересованными участниками, учел все пожелания и подготовил универсальный контрол с подключением libshell скриптов.(возможность работы контрола несмотря на вмешательство!)

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

Предложенные пакеты разносторонние и затрагивают многие механизмы системы. Продолжая в таком духе, можно было бы набрать больше пакетов для поддержки, но ввиду не схожих рабочих задач и недостатка времени, не все из эти пакеты смогу поддерживать.
Comment 96 Gleb F-Malinovskiy 2023-12-05 19:24:36 MSK
Адрес подписан на devel@, теперь это делается раньше -- в пункте 3.6.