43172 2022-07-06 22:43:31 +0300 [4.0] join kaa@ 2023-12-05 19:24:36 +0300 1 1 4 Development Team Accounts join unspecified x86_64 Linux ASSIGNED https://www.altlinux.org/Team/Join/Secretary P5 normal --- 1 kaa glebfm glebfm grenka ldv mike rider shaba sin svn17 zerg cas oldest_to_newest 212398 0 11056 kaa 2022-07-06 22:43:31 +0300 Created attachment 11056 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 Надеюсь на ваши правки и рекомендации. 212399 1 11057 kaa 2022-07-06 22:44:02 +0300 Created attachment 11057 Wrong Public GPG key 212691 2 svn17 2022-07-13 16:51:38 +0300 Подтверждаю заявку. 213092 3 kaa 2022-07-22 22:46:32 +0300 Была решена проблема описанная в репорте https://bugzilla.altlinux.org/43326 Вместе с наставником паке дополнительно был обновлен до версии 6.6.4 213904 4 svn17 2022-08-22 16:36:04 +0300 (Ответ для Aleksei Kalinin на комментарий #0) > Создано вложение 11056 [подробности] > Public SSH key > > Ник : kaa > Почта : altlinux@faktor.pw > Ментор: kaa@altlinux.org > Ментор: Иван Савин svn17@basealt.ru > Моя цель: Научиться собирать пакеты. Указано два ментора, и первый ментор это сам кандидат? Какая-то путаница. 213905 5 svn17 2022-08-22 16:40:02 +0300 Прошу секретаря зарегистрировать ключи. 213906 6 kaa 2022-08-22 16:49:21 +0300 (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) 214459 7 glebfm 2022-09-05 10:59:23 +0300 (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. 214554 8 svn17 2022-09-06 11:35:32 +0300 Считаю, что кандидат умеет генерировать ключи и готов начать встаупление в team. 214855 9 glebfm 2022-09-13 19:36:52 +0300 ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3. 214882 10 svn17 2022-09-14 11:43:06 +0300 Прошу кандидата предоставить примеры пакетов на git.altlinux.org. 216548 11 kaa 2022-10-26 22:02:00 +0300 Выбран брошеный пакет <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 216549 12 shaba 2022-10-26 23:45:59 +0300 У апчьрима на github есть PR на эту тему, и кажется более правильный (используется LIBADD, а не LDFLAGS). Так же в апстриме есть issue на CFLAGS -O3, его бы тоже исправить. 216551 13 11057 kaa 2022-10-27 01:14:40 +0300 Comment on attachment 11057 Wrong Public GPG key wrong name Aleksey was changed because of name mistake 216552 14 11772 kaa 2022-10-27 01:31:48 +0300 Created attachment 11772 Public GPG key Обнаружил ошибку в своем имени(Aleksey должно быть Aleksei), GPG ключа. Поменял ключ и добавил во вложения новый публичный GPG ключ. 216593 15 kaa 2022-10-28 01:28:24 +0300 (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, его бы тоже исправить. Проверю и тоже добавлю эти изменения. Спасибо за Ваши замечания. 217023 16 kaa 2022-11-07 23:14:20 +0300 (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 Жду ваших коментариев, исправлений Спасибо 217252 17 svn17 2022-11-11 18:31:14 +0300 Считаю, что кандидат освоил необходимый минимум и готов собирать пакеты. Если замечаний нет, то прошу секретаря дать кандидату доступ к сборочнице. 218671 18 glebfm 2022-12-09 16:51:14 +0300 ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.5. 219092 19 kaa 2022-12-16 16:14:50 +0300 Спасибо. Пакет собирается, все удачно в режиме --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 219209 20 svn17 2022-12-19 14:27:10 +0300 (Ответ для Aleksei Kalinin на комментарий #19) > Подготовленный комит тут с тегом 3.1.1-alt4 > https://git.altlinux.org/people/kaa/packages/?p=flam3.git Нужно добавить ветку по умолчанию (default-branch). 219224 21 kaa 2022-12-19 19:02:30 +0300 (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). Исправления внес. Теперь ветка клонируется и отображается по умолчанию в репозитории. Спасибо 219310 22 svn17 2022-12-20 17:49:35 +0300 Думаю, кандидат готов к переходу на следующий этап. 219501 23 glebfm 2022-12-26 18:20:05 +0300 (In reply to Иван Савин from comment #22) > Думаю, кандидат готов к переходу на следующий этап. Мне кажется, что любой рецензент скажет, что одного пакета мало. Вы уверены, что этого пакета будет достаточно? 220344 24 svn17 2023-01-19 14:59:45 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #23) > (In reply to Иван Савин from comment #22) > > Думаю, кандидат готов к переходу на следующий этап. > > Мне кажется, что любой рецензент скажет, что одного пакета мало. Вы > уверены, что этого пакета будет достаточно? Согласен. Поторопился. Кандидат, прошу Вас предоставить больше примеров. 220345 25 grenka 2023-01-19 15:10:35 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #23) > (In reply to Иван Савин from comment #22) > > Думаю, кандидат готов к переходу на следующий этап. > > Мне кажется, что любой рецензент скажет, что одного пакета мало. Вы > уверены, что этого пакета будет достаточно? Один умник мне на такое ответил: А сколько надо? Формально у нас нет никаких критериев для оценки кандидатов и даже нет единого мнения по поводу базовых знаний. Мне кажется я знаю несколько потенциальных рецензентов, которым одного пакета было бы достаточно:) Иии ЧСХ их почему-то никогда не призывают быть рецензентами. Кстати назначение рецензентов - самая загадочная и мутная часть процедуры джойна. 225181 26 kaa 2023-04-29 02:27:12 +0300 (In reply to Grigory Ustinov from comment #25) > (Ответ для Gleb F-Malinovskiy на комментарий #23) > > (In reply to Иван Савин from comment #22) > > > Думаю, кандидат готов к переходу на следующий этап. > > > > Мне кажется, что любой рецензент скажет, что одного пакета мало. Вы > > уверены, что этого пакета будет достаточно? > > Один умник мне на такое ответил: А сколько надо? Формально у нас нет никаких > критериев для оценки кандидатов и даже нет единого мнения по поводу базовых > знаний. Мне кажется я знаю несколько потенциальных рецензентов, которым > одного пакета было бы достаточно:) Иии ЧСХ их почему-то никогда не призывают > быть рецензентами. Кстати назначение рецензентов - самая загадочная и мутная > часть процедуры джойна. Доброго дня Grigory! Наверное из таких же умников... Было бы действительно здорово понимать критерии оценки и требования к пакету или пакетам --- количественные или качественные, хотя бы минимальные. Это позволило бы отсеивать потенциальных кандидатов до создания заявки и сэкономило бы время. Но как говориться, это всего лишь имхо. 225182 27 kaa 2023-04-29 02:30:52 +0300 На данный момент в баге заявлено три пакета. 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/ Жду ваших рекомендаций правок и исправлений. Спасибо 225189 28 grenka 2023-04-29 11:20:41 +0300 (Ответ для 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 символов. Всё вышеперечисленное - это то что удалось сформировать на ходу. Все косячат по-разному, поэтому требования тоже могут адаптироваться. И это мои представления о качестве, которые могут не совпадать с представлениями вашего ментора. А может быть ваш ментор сейчас прочитает и ему понравится мой подход:) 225365 29 zerg 2023-05-03 17:47:04 +0300 Мельком глянул: * исходники все упакованы, что делает невозможным прочесть изменения в них при обновлении версии. * Imath у нас есть, с собой копию таскать не надо. * похоже, всё, что идёт отдельными тарболами, надо собирать отдельными пакетами. 225376 30 kaa 2023-05-03 23:16:45 +0300 (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 -- третей сложности. И если ты справился с каким-то определенным набором то следовательно знаком со всеми необходимыми инструментами." Но как понял над критериями уровня сложности тоже нужно поработать. 225377 31 kaa 2023-05-03 23:23:45 +0300 (In reply to Sergey V Turchin from comment #29) Приветствую Сергей, Важный для меня комментарий, так как в ходе сборки возникли вопросы касаемые под модулей. Для меня не все очевидно, пожалуйста уточните: > * исходники все упакованы, что делает невозможным прочесть изменения в них > при обновлении версии. Что значит "все"? В моем репозитории упакованы только под модули, а остальной код остался неизменным и собирается по тегу из upstream. > * Imath у нас есть, с собой копию таскать не надо. Да, согласен, и я обратил внимание на это. Но тарбол взят по конкретному коммиту как предполагается в релизе. Он не совпадает ни с одним релизом под модуля. В этом смысле доверился разработчику. > * похоже, всё, что идёт отдельными тарболами, надо собирать отдельными > пакетами. Когда принимал решение каким образом собирать пакет, взял для примера несколько пакетов которые так же используют под модули. И сделал по примерам. Вопрос видимо культуры или традиции: как собирать код из репозитория с под модулями? так как предполагают разработчики в релизе или используя пакеты дистрибутива. 225397 32 zerg 2023-05-04 11:10:35 +0300 (Ответ для Aleksei Kalinin на комментарий #31) > > * исходники все упакованы, что делает невозможным прочесть изменения в них > > при обновлении версии. > Что значит "все"? В моем репозитории упакованы только под модули Не суть. Они лежат в git-е в бинарном виде, а не в текстовом. > > * Imath у нас есть, с собой копию таскать не надо. > Да, согласен, и я обратил внимание на это. Но тарбол взят по конкретному > коммиту как предполагается в релизе. Он не совпадает ни с одним релизом под > модуля. В этом смысле доверился разработчику. "Доверяй, но проверяй", а только потом в случае необходимости... > Вопрос видимо культуры или традиции: как собирать код из репозитория с под > модулями? так как предполагают разработчики в релизе или используя пакеты дистрибутива. У нас и культура и традиции -- собирать используя пакеты. Разработчики в принципе не умеют пакеты, поэтому пихают всё в один. Т.е. всё, что можно пакетами -- лучше паковать отдельно. Что-то тащить с собой -- вообще не особо страшно, но только если это не библиотека, с которой может быть слинковано что-то, дополнительно линкующееся с тем же самым проектом, что из какого-то сабмодуля, но идущего отдельным пакетом или таким же внутренним сабмодулем. 225398 33 zerg 2023-05-04 11:15:56 +0300 (Ответ для Sergey V Turchin на комментарий #32) > Что-то тащить с собой -- вообще не особо страшно Если есть соотв. пакет, то уже очень плохо. 225470 34 kaa 2023-05-04 23:08:15 +0300 (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 — собирается. Но полноценно работоспособность пакета проверить не могу ввиду его масштабов. Спасибо за ваши правки и рекомендации! 225648 35 zerg 2023-05-10 13:57:43 +0300 (Ответ для 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 из > за таких вот кусков. Само собой, это тоже. > Но больше уверенности что пакет после сборки будет > работать так как задумывалось в рамках релиза. Но это имхо, так как привык > доверять разработчику. Ваша задача -- красиво упаковать. По работоспособности будете потом обсуждать с пользователями и отделом тестирования. 226095 36 kaa 2023-05-19 00:51:53 +0300 Доброго дня В процессе перехода к сборке с уже существующими пакетами, наткнулся на необходимость обновления пакета 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/ 226290 37 kaa 2023-05-23 19:41:37 +0300 С молчаливого неодобрения реализации подмодулей... Подгтовил вариант с использованием пакетов. Отдельная задача только для пакета 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 Жду ваши правки и рекомендации. Спасибо! 226417 38 svn17 2023-05-25 12:26:56 +0300 Кандидат, это придирка конечно, но пробелы в конце строк в спеке это не красиво. http://git.altlinux.org/people/kaa/packages/optional-lite.git 226418 39 svn17 2023-05-25 12:27:32 +0300 (Ответ для Иван Савин на комментарий #24) > (Ответ для Gleb F-Malinovskiy на комментарий #23) > > (In reply to Иван Савин from comment #22) > > > Думаю, кандидат готов к переходу на следующий этап. > > > > Мне кажется, что любой рецензент скажет, что одного пакета мало. Вы > > уверены, что этого пакета будет достаточно? > > Согласен. Поторопился. > Кандидат, прошу Вас предоставить больше примеров. Секретарь, думаю что кандидат предоставил достаточно пакетов. Если Вы согласны, то прошу перевести его на следующий этап. 226450 40 zerg 2023-05-25 14:49:03 +0300 (Ответ для Aleksei Kalinin на комментарий #37) > С молчаливого неодобрения реализации подмодулей... Если что, я не одобрял хранение в репозитории бинарных файлов вместо открытых исходников. Если компонент слишком специфичный или патченый так, что другим лучше им не пользоваться, то лучше уж таскать с собой, чтоб никто его не видел. 226544 41 kaa 2023-05-26 14:12:24 +0300 (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 226548 42 kaa 2023-05-26 14:25:41 +0300 > реализовал и второй > вариант упаковав каждый подмодуль. > 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 226898 43 svn17 2023-06-01 18:23:25 +0300 Секретарь, предлагаю призвать рецензента. 228578 44 kaa 2023-06-29 15:03:14 +0300 Пока рисуется пентаграмма призыва. Обратил внимание, давно не обновлялся kdiff3. Буду благодарен за исправления рекомендации! 228580 45 kaa 2023-06-29 15:05:20 +0300 (In reply to Aleksei Kalinin from comment #44) > Пока рисуется пентаграмма призыва. > Обратил внимание, давно не обновлялся kdiff3. > Буду благодарен за исправления рекомендации! Номер задачи в режиме тестирования https://git.altlinux.org/tasks/323889/ 228714 46 kaa 2023-07-01 00:55:20 +0300 UP Заинтересовал пакет kde5-kstars "убежавший" на 4 минорных версии вперед относительно Alt﷐[U+1F9AD]﷑. 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 228715 47 kaa 2023-07-01 01:04:53 +0300 Первый раз столкнулся с квотами gitery(kde5-kstars оказался "тяжелым" ) после оптимизации репозитория и чистки хранилища получилось протолкнуть исходники. На данный момент все пакеты https://git.altlinux.org/people/kaa/packages/ касаются join. Их набралось приличное количество, и разбираться в них представляется затратным по времени... Возможно ли получить конкретное задание от рецензента или может быть любой более актуальный пакет для сборки/обновления? Жду правок и наставлений! Спасибо! 228716 48 grenka 2023-07-01 08:31:29 +0300 Прошу прощения, что случайно подсмотрел... У вас коммиты как-то очень странно называются. На примере awesome: ﷐[U+1F9AD]﷑4.3-alt5. Я думал, что это опечатка в одном коммите, но потом глянул другие пакеты и там то же самое. Не прольёте ли немножко света на эту ситуацию? 228815 49 zerg 2023-07-03 14:48:23 +0300 (Ответ для Aleksei Kalinin на комментарий #46) > Заинтересовал пакет kde5-kstars "убежавший" на 4 минорных версии вперед > относительно Alt﷐[U+1F9AD]﷑. > 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 ? Актуально было и будет всегда. 228855 50 kaa 2023-07-03 20:09:23 +0300 (In reply to Grigory Ustinov from comment #48) > Прошу прощения, что случайно подсмотрел... У вас коммиты как-то очень > странно называются. На примере awesome: ﷐[U+1F9AD]﷑4.3-alt5. Я думал, что это > опечатка в одном коммите, но потом глянул другие пакеты и там то же самое. > Не прольёте ли немножко света на эту ситуацию? Не нашел строго теребования к комитам и добавил "самодеятельность" подобного рода. Показалось символичным добавлять символ Нерпы в коммит там где код стал Альтом. Особенно это ярко выражено на кодовой базе https://git.altlinux.org/people/kaa/packages/python3-module-myst-parser.git Как раз ждал замечаний-требований по этому решению. Разумеется исправлю если это неприемлемо. 228857 51 grenka 2023-07-03 20:38:40 +0300 (Ответ для Aleksei Kalinin на комментарий #50) > (In reply to Grigory Ustinov from comment #48) > > Прошу прощения, что случайно подсмотрел... У вас коммиты как-то очень > > странно называются. На примере awesome: ﷐[U+1F9AD]﷑4.3-alt5. Я думал, что это > > опечатка в одном коммите, но потом глянул другие пакеты и там то же самое. > > Не прольёте ли немножко света на эту ситуацию? > > Не нашел строго теребования к комитам и добавил "самодеятельность" подобного > рода. Показалось символичным добавлять символ Нерпы в коммит там где код > стал Альтом. Особенно это ярко выражено на кодовой базе > https://git.altlinux.org/people/kaa/packages/python3-module-myst-parser.git > > Как раз ждал замечаний-требований по этому решению. Разумеется исправлю если > это неприемлемо. Насколько мне известно, строго требования к именованию релизных коммитов у нас действительно нет. Но тем не менее, Нерпа не везде отображается корректно. Когда я писал своё сообщение, я не вникал в суть символа и ориентировался просто на пустой квадратик. Скажем так, я бы не хотел видеть смайлики в названиях коммитов "моих пакетов" как минимум. Как максимум, бог знает сколько людей думает так же и это можно вынести на широкое обсуждение=) Я думаю, что тут есть и ментор и рецензент и моё мнение будет явно лишним. Как говорится "Я только спросить". 228860 52 kaa 2023-07-03 22:44:45 +0300 (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. 228862 53 kaa 2023-07-03 23:38:08 +0300 (In reply to Grigory Ustinov from comment #51) > (Ответ для Aleksei Kalinin на комментарий #50) > > (In reply to Grigory Ustinov from comment #48) > > > Прошу прощения, что случайно подсмотрел... У вас коммиты как-то очень > > > странно называются. На примере awesome: ﷐[U+1F9AD]﷑4.3-alt5. Я думал, что это > > > опечатка в одном коммите, но потом глянул другие пакеты и там то же самое. > > > Не прольёте ли немножко света на эту ситуацию? > > > > Не нашел строго теребования к комитам и добавил "самодеятельность" подобного > > рода. Показалось символичным добавлять символ Нерпы в коммит там где код > > стал Альтом. Особенно это ярко выражено на кодовой базе > > https://git.altlinux.org/people/kaa/packages/python3-module-myst-parser.git > > > > Как раз ждал замечаний-требований по этому решению. Разумеется исправлю если > > это неприемлемо. > > Насколько мне известно, строго требования к именованию релизных коммитов у > нас действительно нет. Но тем не менее, Нерпа не везде отображается > корректно. Когда я писал своё сообщение, я не вникал в суть символа и > ориентировался просто на пустой квадратик. > > Скажем так, я бы не хотел видеть смайлики в названиях коммитов "моих > пакетов" как минимум. Как максимум, бог знает сколько людей думает так же и > это можно вынести на широкое обсуждение=) Я думаю, что тут есть и ментор и > рецензент и моё мнение будет явно лишним. > > Как говорится "Я только спросить". Да, тоже заметил не стабильное отрабатывание этого символа. До какого-то обновления у меня и терминал отображал этот символ. Сейчас нет. Не вникал в причины. Разумеется для пакетов которые уже имеют мэйнтейнеров подобные вольности не позволительны. Что бы было понятно, предварительно отслеживаю стиль коммитов, стратегию ведения репозитория и после этого вношу какие-то изменения соблюдая стиль. Затронул лишь те пакет которые "отвалились" или "притянутые" лично мной. По поводу обсуждения, не знаю стоит ли выносить подобное, и не знаю как. Но выглядит занятно. = ) Если подобное не возбраняется, пока это могло бы стать особенностью моих пакетов. 228863 54 kaa 2023-07-03 23:52:45 +0300 Сергей Григорий Спасибо за Ваши комментарии. Вы активно участвуете в моем баге. И частично знаком с предложенными в ходе обсуждения пакетами. Если не затруднит, и у кого-то из Вас найдется время, может быть Вы могли бы занять роль рецензента? Если это возможно и секретарь не будет против. В любом случае благодарен за участие! 228892 55 zerg 2023-07-04 11:11:00 +0300 (Ответ для 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 и т.д.. 228893 56 zerg 2023-07-04 11:12:51 +0300 (Ответ для Aleksei Kalinin на комментарий #52) > Для kstars, с Вашег одобрения, перенес в /usr/bin/kstars. Так правильнее https://git.altlinux.org/gears/k/kde5-kstars.git?p=kde5-kstars.git;a=commitdiff;h=0b6756f8798de7cf9b5d324ee4de5a090b00c4c6 228959 57 kaa 2023-07-04 23:11:15 +0300 (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/ 228973 58 zerg 2023-07-05 11:45:26 +0300 (Ответ для Aleksei Kalinin на комментарий #57) > стоило догадаться что надо учесть взаимоисключаемость с kde4 -_- Учту. Не только. Файлы данных тоже переехали, иначе по умолчанию были бы недоступны самому приложению. 229426 59 kaa 2023-07-11 00:31:22 +0300 UP Заметил что "отвалился" python модуль admesh https://packages.altlinux.org/en/sisyphus/srpms/python-module-admesh/, попутно заметил давно не обновлялся пакет admesh. Учитывая тенденцию на завершение пддержики python2 вырезал связанный с ним функционал и подновил spec. Изменения тут: https://git.altlinux.org/tasks/324627/ Буду благодарен за исправления рекомендации! 229573 60 kaa 2023-07-12 17:42:38 +0300 Исправлена ошибка связанная с утилитой girar-show пакет girar-utils. В истории git этого пакета два вида добавления коммитов, с разделением bump версии и исправления spec, и совмещенное исправление и поднятие версии. Поскольку мои правки не значительны и проблема решается в одну строку, исправления в spec и саму ошибку объединил в один коммит. Есть ли какое-то строгое правило на этот счет или подобного рода подход считается приемлемым? https://git.altlinux.org/tasks/324696 229578 61 svn17 2023-07-12 18:29:15 +0300 (Ответ для Aleksei Kalinin на комментарий #60) > Исправлена ошибка связанная с утилитой girar-show пакет girar-utils. > > В истории git этого пакета два вида добавления коммитов, с разделением bump > версии и исправления spec, и совмещенное исправление и поднятие версии. > > Поскольку мои правки не значительны и проблема решается в одну строку, > исправления в spec и саму ошибку объединил в один коммит. > Есть ли какое-то строгое правило на этот счет или подобного рода подход > считается приемлемым? > > https://git.altlinux.org/tasks/324696 В истории коммитов этого пакета подобное есть. Значит, теоретически, так можно. Алексей, сколько ты уже пакетов подготовил? Думаю нужно остановиться и дождаться решения рецензента. 230029 62 kaa 2023-07-19 20:01:13 +0300 (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 одобрил исправления. 232794 63 glebfm 2023-09-10 13:25:34 +0300 Призван рецензент (rider@) для независимой оценки готовности кандидата. T/J/S -> 4.2. 232808 64 rider 2023-09-11 09:05:35 +0300 - 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 - так лучше читается. 232810 65 rider 2023-09-11 09:15:47 +0300 https://git.altlinux.org/tasks/321695 rapidjson: не нравится мне идея в rules паковать по тэг c release. Лучше сделать diff по тэгу и приложить патч в specfile. Так и изменения будут нагляднее, и лишнего в тарболле не будет. any: мне в принципе не нравится такой формат репозитория - предлагаю сделать по аналогии с rapidjson, когда наши изменения живут в одном дереве с апстримом и патчи делаются через diff в .gear/rules В данном случае ещё у апстрима нет релиза, поэтому можно просто запаковать весь проект не по тэгу, а изменения закоммитить прямо в ветку и отдать в апстрим. 232811 66 rider 2023-09-11 09:18:33 +0300 https://git.altlinux.org/tasks/321695: optional-lite репозиторий тоже надо переделать поверх апстримного, тарболл делать из апстримного тэга. Зачем в release указан ещё git коммит непонятно. 232812 67 rider 2023-09-11 09:56:48 +0300 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= можно просто убрать, тоже непонятно зачем они здесь нужны. 232814 68 rider 2023-09-11 09:59:05 +0300 https://git.altlinux.org/tasks/321695/ Большинство предыдущих замечаний касается и python3-module-OpenTimelineIO-gen3.git Нужно переделать в соотвествии с предыдущими замечаниями и написать мне в личке (телеграм желательно) - я посмотрю. 232815 69 rider 2023-09-11 10:08:26 +0300 kdiff3 https://packages.altlinux.org/ru/tasks/323889/ непонятно как был сделан merge. Выглядит очень странно. Я бы его переделал. Из commit message непонятно зачем понадобилось это изменение: Allows execute kdiff3 from terminal with 'kdiff3-kde5' name И почему оно не запускается как kdiff3 232816 70 rider 2023-09-11 10:10:51 +0300 kde5-kstars: https://git.altlinux.org/tasks/323974/ просьба посмотреть @zerg 232820 71 rider 2023-09-11 10:20:21 +0300 admesh https://packages.altlinux.org/en/tasks/156814/ Убрать тэг Packager и дубли URL в спеке (комментарий) и я бы ещё убрали COPYING из файлов пакета, т.к. лицензия стандартная. Плюс тэг License привести в единообразие с версией лицензии в тексе COPYING 232833 72 zerg 2023-09-11 12:04:23 +0300 (Ответ для Anton Farygin на комментарий #70) > kde5-kstars: > https://git.altlinux.org/tasks/323974/ > просьба посмотреть @zerg Я уже давно сам обновил. 232851 73 zerg 2023-09-11 15:07:30 +0300 (Ответ для 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 пакуется независимо от того, существует или нет, хотя создаётся по условию. 234028 74 rider 2023-09-28 16:06:02 +0300 https://packages.altlinux.org/ru/tasks/324627/ approve выписан - замечания применены. 234879 75 kaa 2023-10-12 20:03:58 +0300 Актуализирую статус и небольшое резюме Список рекомендаций от рецензента: - Указать значения «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. 235757 76 kaa 2023-10-26 17:20:18 +0300 collabora-online собрана проверена одобрена rider для sisyphus Взята на самая свежая версия исходников так как она соответствует существующему в sisyphus libreofficekit. Пакет ориентирован на работу в изолированном окружении, и предполагает повышенные разрешения. Было принято решение отдать выбор пользователю --- сделан вывод с предупреждениями и рекомендациями при установке пакета. Исключены инструкции дублирующие filetriggers. Вообще было бы хорошо провести полноценное тестирование этой махины, но у меня нет такой возможности. 235758 77 kaa 2023-10-26 17:24:56 +0300 Дополнительно для обновления был выдан пакет libopencv. Столкнулся с проблемой не хватки места на git.altlinux.org/people/kaa/ write error: Disk quota exceeded Возможно ли увеличить место? На данный моемнт, что бы не тратить время удалил всё. 235760 78 zerg 2023-10-26 17:29:00 +0300 (Ответ для Aleksei Kalinin на комментарий #76) > Взята на самая свежая версия исходников так как она соответствует > существующему в sisyphus libreofficekit. Лучше ориентироваться на libreofficekit-still. Он стабильнее и новее. 235845 79 kaa 2023-10-27 19:44:22 +0300 @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 235847 80 kaa 2023-10-27 19:55:09 +0300 (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... 236709 81 kaa 2023-11-09 02:27:22 +0300 (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 236727 82 kaa 2023-11-09 10:07:02 +0300 На данный момент в рамках энжойн в sisyphus принято 13 пакетов под моим именем. Задача отнимает слишком много времени. Меня устраивает возможность вносить изменения в пакеты с одобрения зинтересованных мэйнтейнеров. Всем спасибо за помощь и участие! 236753 83 zerg 2023-11-09 11:51:23 +0300 > WONTFIX Это может означать удаление ключей. Да и резолвит баг тот, кому он назначен. 236754 84 sin 2023-11-09 11:59:32 +0300 У меня вопрос... А какие ещё должен проявить навыки Алексей, чтобы его приняли в ALT Linux Team? По-моему, он достаточно много провёл работы, чтобы рецензент одобрил его кандидатуру. 236755 85 rider 2023-11-09 12:01:11 +0300 Много очень ошибок возникает при сборке. Несовместимых с самостоятельной сборкой пакетов в репозиторий. 236756 86 rider 2023-11-09 12:02:25 +0300 при этом итоговый результат всех устраивает, но без review Алексею пока пакеты в репозиторий лучше не отправлять. 236759 87 zerg 2023-11-09 12:10:49 +0300 (Ответ для Evgeny Sinelnikov на комментарий #84) > WONTFIX → LATER (Ответ для Sergey V Turchin на комментарий #83) > Да и резолвит баг тот, кому он назначен. :-) 236760 88 sin 2023-11-09 12:12:00 +0300 (Ответ для Anton Farygin на комментарий #85) > Много очень ошибок возникает при сборке. > Несовместимых с самостоятельной сборкой пакетов в репозиторий. Какие конкретно ошибки, по каким конкретно пакетам проявлены и не исправлены, чтобы можно было уверенно заявить, что работа данного кандидата несовместима с "с самостоятельной сборкой пакетов в репозиторий"? Насколько я вижу все пакеты исправлены по достаточно противоречивым требованиям разных мейнтейнеров. При этом освоены такие схемы сборки, которыми не обладают некоторые бывалые люди в Team. 236762 89 rider 2023-11-09 12:20:51 +0300 Ну из последнего, что я помню - при сборке python модуля не разобрался с межпакетными зависимостями и сделал наоборот - вместо добавления нужного provides загасил requires. Ну и совсем банальные, вроде намешанных изменений из разных коммитов. Из-за невнимательности. 236765 90 sin 2023-11-09 12:45:44 +0300 "Пусть первый, кто тут без греха, бросит в него камень". Это всё не конкретные примеры. Ссылки, пожалуйста... Хотя это бесполезно. Считаю данное мнение предвзятым. Алексей, предлагаю, по мере появляющегося времени, публиковать здесь сборки своих пакетов, чтобы избегать предвзятых аргументов. Сейчас предлагаю сфокусироваться на конкретных деталях: - взять очередной пакет из требований рабочего процесса; - разобрать уже сложившиеся в выбранном пакете проблемы, накопленные более "опытными" и "достойными" товарищами; - подготовить его сборку, обновление или исправление. По результатам будем разбирать где, когда и кем в данном пакете осуществлены некомпетентные и банальные ошибки. И уже из этих исправлений тогда делать выводы. 236767 91 rider 2023-11-09 13:30:34 +0300 Какие ссылки ? git уже давно переписан. Ну раз вы считаете моё мнение предвзятое, то с данным ментейнером разбирайтесь сами. 236775 92 svn17 2023-11-09 14:13:55 +0300 (Ответ для Anton Farygin на комментарий #91) > Какие ссылки ? git уже давно переписан. > > Ну раз вы считаете моё мнение предвзятое, то с данным ментейнером > разбирайтесь сами. Прошу рецензента указать причину возврата к пункту 3.5. По каким вопросам требуется дополнительная работа? 236777 93 rider 2023-11-09 14:18:26 +0300 Не могу быть рецензентом данного кандидата в связи с обвинениями в предвзятости. А в целом надо поработать над внимательностью и с теми пакетами, которые мы собирали вместе - всегда были какие-то ошибки разной степени критичности. Рекомендую следующему рецензенту посмотреть как кандидат самостоятельно, без чужой помощи, собирает новые и обновляет существующие пакеты. 236794 94 svn17 2023-11-09 18:38:44 +0300 Прошу секретаря призвать рецензента. 236994 95 kaa 2023-11-13 21:22:18 +0300 По поводу самостоятельности считаю необходимым расставить акценты Перечислю пакеты которые собраны только в рамках процедуры 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 который пришлось крутить и всячески тестировать в разных режимах. Подход к обновлению пакетов был строго с точки зрения оказание содействия мэйнтейнеру ведущему пакет, но не переделывание уже сложившейся культуры или стиля. Предложенные пакеты разносторонние и затрагивают многие механизмы системы. Продолжая в таком духе, можно было бы набрать больше пакетов для поддержки, но ввиду не схожих рабочих задач и недостатка времени, не все из эти пакеты смогу поддерживать. 238459 96 glebfm 2023-12-05 19:24:36 +0300 Адрес подписан на devel@, теперь это делается раньше -- в пункте 3.6. 11056 2022-07-06 22:43:31 +0300 2022-07-06 22:43:31 +0300 Public SSH key altlinux_kaa.rsa.pub application/octet-stream 742 kaa c3NoLXJzYSBBQUFBQjNOemFDMXljMkVBQUFBREFRQUJBQUFDQVFET2dJRVdwODhSRUZPVXd0RWpH U1k2NmdGd3BPZWxxaW9WUDNrZVhmWXNlQVUxdWRwU00wWmp3NXIzQ1lnZXdkSU0vZ2Y5Z2VDejBL a2tmalpFYXdXV1p3UytrRUE3OHltZW9sc29wVFRtRzZQUG15SXRPRUYyR0VncjVzaVN3MityQi9Z MEpQV0VXbTkrZ0xCWEFIQkk0a0pWLzhvUWJYMTFoUjhybzN4R1hBMU0zTmlKSVVXcHRoVkxYWmxO TVZ2U0szS2NRaEY2T1MrL01weUZHMStDQXVxc1RpeE53bHNRWnk4QmltaXZBZGdqaE1SK2NRQml6 L28yUWlFNzNURXdrUU93OTJocTVEVzVBRnV5eGpCZ3lFaGdkQ2dreXk4TkJzODY3S3hqREx0eGFz UjVIRjllRGpkSXhLenhQeHJNamk2L1VjMUR6ZGhnWDZIWFFWaEMzK1lOdWlwL1pvcnhLa2tydHQz cytWRmllaGsydVhrWWIvd1phTjZVVmtzMElVSmdtNmliR3dGUFdXeHJwNFBtT0YvL0FTUGliU0ZV QkUrdm5GTzNEQVIyR1F0a0hQdk4rVVVLaDUyS3BjMnYwQWxGR3BGYkJGZnZVTWh6UW90MHVabDU1 M1NHNVU5ckFBbWhaaDlyclhBdXRyN28wVVUxdVFXK2QwcWhSV3FvOWZHM29RT0pCc2V3eHVoQ3R1 b2RtV2dkWFU5bTRPMm1PMEVCRDBNdXJYZHNNWlhQWjBzWVRIUmF2RlJxNTcrSndXbis5bmxqWE9D V3Y0MmFOdTcwMkNLeVNsY1ZxY25NWGY2WFFhY3UzS255VFV6SksxYVJjd3pMd01KazhhdmkyVDFZ bXpnWkJIRHc5bStaMWxCRkRmZ0REUUZiN1dsaENFNHc1WlBTa3c9PSBrYWFAYWx0bGludXgub3Jn Cg== 11057 2022-07-06 22:44:02 +0300 2022-10-27 01:31:48 +0300 Wrong Public GPG key wrong_key application/octet-stream 3147 kaa LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkdLQ1lvc0JFQUNnalhp R1RRN3JraUdIUTVPQ3FQU0hHVXlhM2haejlsYW1OYkg0VzNFcVk3eElYRmVGCk0vOHpKNHduSkNr dzB0aGcrcXhjTTlqSXA1UUpVeXJJZ2xGMWpJWmtISUpRNEhDazZ2UnJ6OGo3Qk93VjRvUG0KekVL T0NKN0RKdzB0bnIwVFE3SjRGb2NHSEtSRVFadTVWZVBacUVRN3BjUm9MalpzNkxiajVqT3V5bDZ6 eWMwOApOQ3N0dFJjUklFMVMvazYxSDRjb1dSUGVIOFU0eUxFT2ZucW1zbGsyaTA0THM5L204eWx3 b3hBVHJGM2s2MWJKCkpuaGhaejd0aWZsSnpFWU5LcXM3enpBdjBUZ2ZDdTkxbnF0UXBNajFIenZL MVg2eXBLeHZyM3pGcm5BM3lIaXMKZXBxNjlSU2Z1T2loZFdYSTdTYUN4OUdrN01sYXRLSm4zT004 RTRuRU5lOEZTZVpiZnFuakozQytYMFAzZG5DVgpVaDFmY3ozRStsclRLczNlVVRkd0NiK1ZNOTQ2 ZS9waDNBWml3Q2U2dHZlQ05oaWxFYURNZ3lmUlZXaU16YTJCCkFPUGlQYU5FZG5hSnFNTm40SjdT ZC83ZDJ2ZCtHTCthV0dHTzFVTHoyV3JPOEJEWUpaaHR2TTB5aVJpNUlQcnIKS1RuYXlKNytNcDNj RGZ5aGdCVjFWRzdJek1hVlZsdmoyYzlhbENaUFZHZWZZS1h6SDlYY1crWWpDemFUNXVOSwpWWkhL ZjVyR2tUMHJoSDFMTW9wSjUvUWUzYk4zeDNSSWFSOHlPT2gxTDVaNmpRRVRkQW5IVUdiQjNtOTU5 RHNqCmpseFhyVVZla0lsaTVKT1dVejRYeTNTeFdrd0ZiUUJ3WGQ5dXc2dkN4OW5CSnU5N2F1VHBY MnFxSndBUkFRQUIKdEMxQmJHVnJjMlY1SUV0aGJHbHVhVzRnS0hkdmNtc2dkV2xrS1NBOGEyRmhR R0ZzZEd4cGJuVjRMbTl5Wno2SgpBazRFRXdFS0FEZ1dJUVRwSGxmczNHVmFkYzBnTXhUc0E4dS9T UzM0S2dVQ1lvSmlpd0liQXdVTENRZ0hBZ1lWCkNna0lDd0lFRmdJREFRSWVBUUlYZ0FBS0NSRHNB OHUvU1MzNEtocHpEL3dOcG05d2NLMGR6MmZWdHo0aFUrMjEKWkw2QjVIalByc0tGYjZ2cVRHZlIw TTRJclpKNWRzSndacmVOUzJ2bU1jMlNuRFhaOFN4NUozdGluZWxFNE5tZwppSlZTK21GbVNEQUNL SVVaaHMwM1NBdVN5OWZJNHB1cE5WV1ROTGpJekt0QTlvaDR1dzBaN1g4STljSDlkRWhOCkltampS ZDhaRnpONllDeHdXUmdyR1F6SWhXZ1BzYW9iY1dqd0hWWEwvckJ6UEs5Sng0MVN6Wm1IYUpad25U UGIKMFBVeVVwWjRobkNERFRvMmJaL3pWVzJabTV0dzFGZkI1OE02dytpb0ljNHBPRTlUWHlsZlgy a3RzMGl4bFFlQQpTNkpDYjJKU3NaSjV1L0MzR3QrYnNVTElLYk4zVnNlWG9FR3A4TlEvTjNuUzB1 YkZMelI5RFNvU2pxeVlYZFEwCjg3VDg3bzNqV29QSmZ6ZmlGMzM3aTZVWFhIS0puZEkyKzlVZHBy VHA2WmgxZlpBMm55bXIxR3V3dXY4d1R2RVEKM2tDS0Y3YkJRY0ZJV1VleHE0Si8rWU9ZWGhKanUr NU9TbzRTT3JWeU83QXd4R1VWSWJlZmd0aTBvUk1RY2tyeQpPR2pZWVpNeHNLbHh1cjdjL01MNzZn Y0VjV3k3RUFGRG9QYUkvRUtWa1A2bDFIekpSM0RwTmVkd1djRXczZmI0ClRrV1QveExMck5XZTFw ck9zbEM3Zm9UbWtPSzQvZXAyQ1UreUNFWnF2dlJpbmptR1VPUkRmWXpmVWZOSEZQSHUKWktiMTFy TXFzM3ovOVZRei9heXYzSjVzZFV3cnVmUGV1d3J0bVFMYWV5TU9MR0cxSWR3SVZNQXNGajdHZVlt dQplaXBnTWgrZTNZcFRYdTQ5TWFmZHBia0NEUVJpZ21LTEFSQUF2MlB0K0tSZjIxNno2ZE1FU3dk bTVxSEMrT2x2CkxtbUdnMVBxdGtsYklUWE1GdHdFbUtQQ2JQa2VCUW9CQ2g3eDByeVo5OWpsQVQx UkJjSDdEM0dqM2duUDYrUEgKNEhPZDJNOVo2QmlRUUdOQ0dYMXRUVitnU0VsTDh5OHlrenJoUmZG WXh1NnFyWTZEUVJuc0tzV3B6ODU4WTBLWgpHQ3hFdlI1bkRzRzExQTdXSHhLOXpvVDJqdmNCVS9P UGZvT25RQnNmait3bkxTYkJ3dWN6Y0VKM1NIMWpBZVBXCnRBSEtMcDlCVlBCM08vQnkrbFNJYmJo RlZKNDg5WXo0NjBacENtZlMrWVpzQ3RYTUJrVlBMVkttQTQzSzlhYUMKbzdKUkt6NWR6ZThLaWNE UFJqdEowYXJ2MDVWTkZKWVFmdlZyZUxDSEpLQW9wSDI5MWc5OVVjK2JXRHcrcEUwdApCWXBpa2NQ SlZwbFNOTUlSVGNRRlNMMGY2T1JIS20xcFVxQUFWSVgwTEdnYTM2OThlNnVHYVI1dGVBdU5jeTJr Cmp0M0Y5RjZMS0tHeHFKNnFxTVJXVjRNRGZnWXBxamhLSWxDVFZqc08wZGZxck91Q0lQVjFuVmZP b1FKWmxmdGgKbUkvcGdmeEtWdW1jb1ZrWktvdW5jT1pJc294VTVkeldXaTFKS05qamlXUjFaVERO VzM4NVM1dmlmNkYyOXA0SwpUOHpWdGttcE8rcVJLeEt2WVpJaFRQS2RNRG42VmYwMmpDa1hmalJt ek5iejhQL0JHYjRMVXlnR3M2Z2pvb044Ckd2NDU2YjN5Sm1lQTZUcC91SFp4TDY1ODVLOTRrSk5p Y1ljTzdtUWVvb1NLSTNmWitFY09EMWFkVFFLeWh5Q2YKSVlZeEF0dVZVR3JMSDIwQUVRRUFBWWtD TmdRWUFRb0FJQlloQk9rZVYremNaVnAxelNBekZPd0R5NzlKTGZncQpCUUppZ21LTEFoc01BQW9K RU93RHk3OUpMZmdxeWZnUUFKSlUxbUxGV2ZxazYxWEZJSkwxYWN3RnZIT1FScENyCjZMcWJlNWFR UkZkc2tyOFdmQXpQcFJmTTNaYi9oclIyY29Dc0ExbmdCaU4xTWRVMzA2eW5qSkE1d1JNL29XTVkK dEtVMHBXbUovQmpKNVNuYW5EL3RBRndYZHVGWVdJVzFONms2V29zV3M3YVk1Z29ReDBmLzFJcmtK TENOdlpsLwpzbG9VTFg1TFBLWHVMamJub29YbHhTRVlrOHNta2wrTlcrRkM4U2RhZUtGNjNiN2x2 SE9PaVJCdTdXa281eUxRCmtpZEljdmN1WFBOc1JEK091TUI4MUVQOUVkclBXeUgzTTZ0SmV6eE50 T210UHRGNGhWZ2VIUGU0czRxWjlhaEUKSEdIaUlsc2YvL0o4Z2ZZc0s3QmNkYmZSSGFEdjB4OExq ZUM1N1ovQmlrWk1nWXlhajliemhHcVZuZzJPcjhlYQpmdEtLeUtVbDdNRFcyLzJBbEVOY1JtODFV NkJESXJKTmJUaGVOSExQNWo4V256QU1yOEh0OHo2TkhHenBtQXpHCkFMdDBsZjhoOGFKeHNJUWd2 S1JHU0pLTFZjWnRmQlNYdlduOW80TERiMEdXRklCQk9Nemdwc3hIZVRJTEdqc3AKMFNSTVB4LzhX Mmc2Ky9HMUF0SFQrbkY1MXQ1OHVIQi9aYTk4YnNFYURQWFNMT1R6cnpTQTFHcGlDc1lVMTlpKwpB dk1kZWErVGUxcUNpaDNEZWpBTUFYcTArcjZwcFd2alVGVzdLSy9sWTVoNVhGazBzNnFkZWcyVUxJ Q05hcG93CjRLKzlobmw1WnJtSTEwa1dYdndickt3Y0VFMTkyejdYdTEyUkxVbWcrYm5GSWJ6cnRD UU8xMFg3a1p3aWh1eVYKWXVkaUhrVUxPYmsvCj1pYmp0Ci0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZ IEJMT0NLLS0tLS0K 11772 2022-10-27 01:31:48 +0300 2022-10-27 01:31:48 +0300 Public GPG key altlinux_kaa.gpg.pub application/vnd.ms-publisher 3094 kaa LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkdNOGR5TUJFQUNvOUlO WjFRYjRnUUN5Q0E4aVZMKzd1N2JjUWRlUGVNakhUWVFIUXE4SXJCNWY0NzBDCllNUXhhem9nWU9X ZjN0NndKbUtVOWdRVGxtNWFkdWdja1JubjNhK3A2dytWZEpiYXBieDVJaFoydUwwU0RsUVMKQ0c4 MmJKL25IZlRMc1ZRMUVjUTNYTkY4c1NoSkxkNUU5cmE1KzNQZkpZLzI3NUh3ZFpocDYwaHpBTE1E TTFDaQp4L0ZEVlp1RWdmOVRXY1RySTdpY1hvYlRFNEpwMWcxRTRYTEkwdDNxMmk1NDNnUnRxNlpB UGpsOXl5N1drNCs3ClhGRC9rK05iRjFQVC8wamEzN1ZYN0Z1cC9lbzhUakQzUHkyTlNzRS8remNm YWgxaHZhQ1ZQQU45SE5OOERNdHUKK0QwNmhUUzVQZTAvejU4OGkwSXVlVFl6d0JOMW1XQUw5Z1Nt TW1vWVFCVUx6SnlPS0NFR25XbjFUV2NqNFBsSApMUFZpeWNaYW13eVBJZFBUNldaVk9LZE5taDRv Mlp5UFlWaldDS0xaeGpLeVl5cXlkZndvN0JZRFlFeEZZdVZWCmhpV0V3VEdSWERRUUFmVzZEbmJz UVM3eFltb05xakJlS3hvelU0d242eEtxZERSZDhURkJadW9MaG10SlBOWWMKWVljRzRzc1ZLU2hj cktQSWVtMWZaMUR0Ym9kSHYzTHR4Ti83QzYvNVJvZTBleWhEWElPakJwNFJYdkd1bEJQMgowRHkx T1diMWRqeTJvMmlIV0JJbCtGb3FCZHhvRG9Kejc0OHl2RzFjWlV1bC9kSE1kaUtLWG41SFBCNUp6 eVFZClE4Y2tzN1daM2xuN25QSFZ6TVNoTmFPcytvaURqQ1U0T3NPWlBNNDZ6ekNKck5LK08rQnhx L01BN3dBUkFRQUIKdEROQmJHVnJjMlZwSUV0aGJHbHVhVzRnS0VGTVZDQk1hVzUxZUNCVVpXRnRL U0E4YTJGaFFHRnNkR3hwYm5WNApMbTl5Wno2SkFqZ0VFd0VJQUNJRkFtTThkeU1DR3dNR0N3a0lC d01DQmhVSUFna0tDd1FXQWdNQkFoNEJBaGVBCkFBb0pFT0xTSlMzZ09tZU5JRDBRQUo4ZENNNzV0 M0Uyb25nckN1dlUwMmVscFJqZFhqTVAwUDZCSVpjV2FUZXoKdzlYcHdpL3U3ZzBjREUyT1U1cFlL a0F2ZVZicnFreU53aWowMThXdmkrRUU1bm5EZFA3cmJSLzNrK0NwbmRsTApPb212UnJKL2wvMis0 OUM5VnE2NktoNjdzemhCYnZrQnhTemxNTlpSTGZLUGhKREZYcmFhWHJqckhDNnQva2hiCnptM1p3 cUZZZ3VpYWxlQjZmWUFIdjE5QVV5TzdxcFV4UEhWVGd6THFoc0QxNDNrOXZ5aFhiRTlRUzBxdTBT V2MKamxjZkN4SDlBL1hBMU1QV3ozd2MySDc3QXViVkFkdkhhTEtrWDhXVGJybWdmM3dod0xzYUo3 M3dta0V1Y1krWgpMbGRnVVkwRUt3dEhNZXpxelBJOHN0OGhtRTlJV2V3bVJFTmRhQllJbVRuVWNL emRMY3llT2hvMDVyVnROZkF2CmRXNUsxdEtuaVdqcDVvdWN1V3hCT0sxejZlcWNoQzlhdlhOdXF2 eDlYV0RKdC9iaERlcHp6cHdoWi9PYnJTS2UKNGVmTDJKZmlQSHA2ZmFkNVoyTEQwNTRpd3ZxZ2dH MUE2cHhxSmdZNGRKcG9kYU42RnNqSnRaQjZ3MTF2dUYxNwpFSzB0ZHN3ZmZFWXREWHVFQXUycHBO SG5JdFoyTXJCQTV2TEFRN3M2bjRUaDA3Y2luVGg4dWY1YmhsSWtBWmY3CmF2NnF4TmlLbm54RmRM WEx5V3RreEtRU1pnZU4zc29GZE1RV21GYlJoRjA0emJMbGZwbEVGV0dnVjZtT2JNZlAKYW9JeHY5 S09hSHlEZWNOL3A3R3JiY3huK24raXN3REt0c2xrNjE2RXk1ZUkzWUVKSU4reXBNNmxMQlNhdlJ0 dwp1UUlOQkdNOGR5TUJFQUNkU296cnRYeTBxU1Zpa0R2SVNSaTh1cGRpK1hNeFlsMDUrK2UrMTdn T3JCRllVVng4CkRTd1FCN2YwR1RZY1pGQ3RHNjIrTCtxb2NNMk43bnhRWTFxVVN1NHhoeXo5eGJR OUNmZnVwYzRVYVIxK0cwTmcKUTNBQUk3V3BVclpGNTNIZGJVTysyQ2VLZkJjRjhkRDhycXNMUXlw dk0zVFE1ZTAxenpWNDBSNDIvSXVoVWt2LwpVeXRVVXMzL2dQbFJXVFhMN1IxRXozSk93dmptYWVp bTZUa2d0cTlTQ3grT2FyWkR1U1FOdW9kL3Z6WWdxWjNJClNWaTEvTTVYR1JQTDZDUjdxUUZ5cXZ0 cU1ZT0x0Si9QMU4rZzc2VU1HM3N5QktSNVU2QWluNzlvVXkwWFZJT1MKeDZVL3FPSitxaE1qWlpr TU9aVEZtbFRiV0hEbjBXOVJwelVTMUcyTE85bUFMdk5qaVUwZW9VSzQ2RVFZYjIxQQo0djdNRTRk Z3F6MGtJUXpRYlNjNWVJWjNWSVpTbGQycGRucy9VM0RQTk05MTVxZWVLNkpFK1ZGU2l0eEtmUVAv Cm9OcTBKME1MTWxoeVArQnA0ZjJTangxalNFWXp4R0hvTEhhbU8xY1B0RDJlTU5KRWJONFRvai9L YmwzTTBmOWIKSmhGTlRNMVoxUmRRYVN6VXFhL2xOMVdldzF0Ym0rVTBqcUNzdWdYdUpJMWxVVEd6 ZktORnRRZFVVNlhmaUZlNgpQMHpXemJRVkFLNVE0SldYc0VManVzNVRCc21KTG5yZUJsYWFLUGZm bmxlakVvTkcrQW9MbTV5T2R1Q21aYnFPClhOQUY4a2YrNzJvOVlYWFR3K25yV1JTNXorNFFqck9V V2FhdlhMRHpXTXU1MVJJUlNuSWlreVNEY3dBUkFRQUIKaVFJZkJCZ0JDQUFKQlFKalBIY2pBaHNN QUFvSkVPTFNKUzNnT21lTk5yTVArZ0svRFkwVTBMNExOZ2ppamphbQo2SmtFVTh3a3FPU2VoTlFP eFcwUno1V3Z2VE9xcFBRR0cyR0htNFdlQ0VaMGxiTktKRklQWmlpWGhPbEJ0RlhLCkUraS8vTm9v VSt4SXhVcXdEYVAxQ2puaXFhb3NSSnpLcmN3L3Z6ZEJTRklsWFRyalJjcUFqcDJZUUlaZTl1cUgK S29GVmRSc3pRTEhIeWtBZThpU2tydVI3bEZtQWtlcXd5TUZNY1NxYTM2T1lxaTVLVFpST2dUNlRu WHoxc25hbwprc3dzekhEd3ZrUXJjdkZxcTcwcy8wd3h5UjEwcExyVFNXSnRaSXlPbS9JSTZPcWpG TnUveExZaDVUejNHb0tHCjEreG5GUzNnMEF4bU9FZWhkaHN3SGRreTcwaEpRQ3Bldi95QjQ3SVBt YXYzV1NDUGVpVnBuUmNBTlhTSjhTeisKZlhqNEdSRkR3aWdxM3c1cDhMZS9mZ2YvZzQ4RG4zWWpx UHBjbXE5STVxOWt1K3Z6OXRCS21JOUIyWmVrZDVGYwp3Y05kZTBsOXFsRjIvcHFIZTNwVGFZMjRN N09xYThnL0tLRFRkNDFBTUZyeVdjQ3dvVmV4cHNxTVFUb3pqenBaCnZ4V0w4bkx0TUhMUVZZdlVm NENSTEVWd3BuWlJZUDEySWo3WkVpdENMMXg3VEtRWkp6NjVpbnVpZ29YZFpSSDQKZEFxMGRTRHRa TGZHVEZpdURoR0d1ODRZaXBYL3hQREFhQ3lPRVhBK1dDdDQ0NFpOTFNVb0o1dnAvREVSVEtuOQp6 c2ZCQkNPUW16YkZRb1pyNXZ4Sm9CKzVWZHJYWEgzUGdVSVlsYTJreU1uVUJ5Qll3TWxlZEo5M3V0 bDdqZE5zClFYUm8ydnpwbGVZTzZRZC9NNEFaSnFMaQo9YXlOZgotLS0tLUVORCBQR1AgUFVCTElD IEtFWSBCTE9DSy0tLS0tCg==