ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | [4.0] join kaa@ | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Team Accounts | Reporter: | Aleksei Kalinin <kaa> | ||||||||
| Component: | join | Assignee: | 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
Aleksei Kalinin
2022-07-06 22:43:31 MSK
Created attachment 11057 [details]
Wrong Public GPG key
Подтверждаю заявку. Была решена проблема описанная в репорте https://bugzilla.altlinux.org/43326 Вместе с наставником паке дополнительно был обновлен до версии 6.6.4 (Ответ для Aleksei Kalinin на комментарий #0) > Создано вложение 11056 [details] [подробности] > Public SSH key > > Ник : kaa > Почта : altlinux@faktor.pw > Ментор: kaa@altlinux.org > Ментор: Иван Савин svn17@basealt.ru > Моя цель: Научиться собирать пакеты. Указано два ментора, и первый ментор это сам кандидат? Какая-то путаница. Прошу секретаря зарегистрировать ключи. (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) (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. Считаю, что кандидат умеет генерировать ключи и готов начать встаупление в team. ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3. Прошу кандидата предоставить примеры пакетов на git.altlinux.org. Выбран брошеный пакет <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 У апчьрима на github есть PR на эту тему, и кажется более правильный (используется LIBADD, а не LDFLAGS). Так же в апстриме есть issue на CFLAGS -O3, его бы тоже исправить. Comment on attachment 11057 [details]
Wrong Public GPG key
wrong name Aleksey
was changed because of name mistake
Created attachment 11772 [details]
Public GPG key
Обнаружил ошибку в своем имени(Aleksey должно быть Aleksei), GPG ключа.
Поменял ключ и добавил во вложения новый публичный GPG ключ.
(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, его бы тоже исправить. Проверю и тоже добавлю эти изменения. Спасибо за Ваши замечания. (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 Жду ваших коментариев, исправлений Спасибо Считаю, что кандидат освоил необходимый минимум и готов собирать пакеты. Если замечаний нет, то прошу секретаря дать кандидату доступ к сборочнице. ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.5. Спасибо. Пакет собирается, все удачно в режиме --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 (Ответ для Aleksei Kalinin на комментарий #19) > Подготовленный комит тут с тегом 3.1.1-alt4 > https://git.altlinux.org/people/kaa/packages/?p=flam3.git Нужно добавить ветку по умолчанию (default-branch). (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). Исправления внес. Теперь ветка клонируется и отображается по умолчанию в репозитории. Спасибо Думаю, кандидат готов к переходу на следующий этап. (In reply to Иван Савин from comment #22) > Думаю, кандидат готов к переходу на следующий этап. Мне кажется, что любой рецензент скажет, что одного пакета мало. Вы уверены, что этого пакета будет достаточно? (Ответ для Gleb F-Malinovskiy на комментарий #23) > (In reply to Иван Савин from comment #22) > > Думаю, кандидат готов к переходу на следующий этап. > > Мне кажется, что любой рецензент скажет, что одного пакета мало. Вы > уверены, что этого пакета будет достаточно? Согласен. Поторопился. Кандидат, прошу Вас предоставить больше примеров. (Ответ для Gleb F-Malinovskiy на комментарий #23) > (In reply to Иван Савин from comment #22) > > Думаю, кандидат готов к переходу на следующий этап. > > Мне кажется, что любой рецензент скажет, что одного пакета мало. Вы > уверены, что этого пакета будет достаточно? Один умник мне на такое ответил: А сколько надо? Формально у нас нет никаких критериев для оценки кандидатов и даже нет единого мнения по поводу базовых знаний. Мне кажется я знаю несколько потенциальных рецензентов, которым одного пакета было бы достаточно:) Иии ЧСХ их почему-то никогда не призывают быть рецензентами. Кстати назначение рецензентов - самая загадочная и мутная часть процедуры джойна. (In reply to Grigory Ustinov from comment #25) > (Ответ для Gleb F-Malinovskiy на комментарий #23) > > (In reply to Иван Савин from comment #22) > > > Думаю, кандидат готов к переходу на следующий этап. > > > > Мне кажется, что любой рецензент скажет, что одного пакета мало. Вы > > уверены, что этого пакета будет достаточно? > > Один умник мне на такое ответил: А сколько надо? Формально у нас нет никаких > критериев для оценки кандидатов и даже нет единого мнения по поводу базовых > знаний. Мне кажется я знаю несколько потенциальных рецензентов, которым > одного пакета было бы достаточно:) Иии ЧСХ их почему-то никогда не призывают > быть рецензентами. Кстати назначение рецензентов - самая загадочная и мутная > часть процедуры джойна. Доброго дня Grigory! Наверное из таких же умников... Было бы действительно здорово понимать критерии оценки и требования к пакету или пакетам --- количественные или качественные, хотя бы минимальные. Это позволило бы отсеивать потенциальных кандидатов до создания заявки и сэкономило бы время. Но как говориться, это всего лишь имхо. На данный момент в баге заявлено три пакета. 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/ Жду ваших рекомендаций правок и исправлений. Спасибо (Ответ для 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 символов. Всё вышеперечисленное - это то что удалось сформировать на ходу. Все косячат по-разному, поэтому требования тоже могут адаптироваться. И это мои представления о качестве, которые могут не совпадать с представлениями вашего ментора. А может быть ваш ментор сейчас прочитает и ему понравится мой подход:) Мельком глянул: * исходники все упакованы, что делает невозможным прочесть изменения в них при обновлении версии. * Imath у нас есть, с собой копию таскать не надо. * похоже, всё, что идёт отдельными тарболами, надо собирать отдельными пакетами. (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 -- третей сложности. И если ты справился с каким-то определенным набором то следовательно знаком со всеми необходимыми инструментами." Но как понял над критериями уровня сложности тоже нужно поработать. (In reply to Sergey V Turchin from comment #29) Приветствую Сергей, Важный для меня комментарий, так как в ходе сборки возникли вопросы касаемые под модулей. Для меня не все очевидно, пожалуйста уточните: > * исходники все упакованы, что делает невозможным прочесть изменения в них > при обновлении версии. Что значит "все"? В моем репозитории упакованы только под модули, а остальной код остался неизменным и собирается по тегу из upstream. > * Imath у нас есть, с собой копию таскать не надо. Да, согласен, и я обратил внимание на это. Но тарбол взят по конкретному коммиту как предполагается в релизе. Он не совпадает ни с одним релизом под модуля. В этом смысле доверился разработчику. > * похоже, всё, что идёт отдельными тарболами, надо собирать отдельными > пакетами. Когда принимал решение каким образом собирать пакет, взял для примера несколько пакетов которые так же используют под модули. И сделал по примерам. Вопрос видимо культуры или традиции: как собирать код из репозитория с под модулями? так как предполагают разработчики в релизе или используя пакеты дистрибутива. (Ответ для Aleksei Kalinin на комментарий #31) > > * исходники все упакованы, что делает невозможным прочесть изменения в них > > при обновлении версии. > Что значит "все"? В моем репозитории упакованы только под модули Не суть. Они лежат в git-е в бинарном виде, а не в текстовом. > > * Imath у нас есть, с собой копию таскать не надо. > Да, согласен, и я обратил внимание на это. Но тарбол взят по конкретному > коммиту как предполагается в релизе. Он не совпадает ни с одним релизом под > модуля. В этом смысле доверился разработчику. "Доверяй, но проверяй", а только потом в случае необходимости... > Вопрос видимо культуры или традиции: как собирать код из репозитория с под > модулями? так как предполагают разработчики в релизе или используя пакеты дистрибутива. У нас и культура и традиции -- собирать используя пакеты. Разработчики в принципе не умеют пакеты, поэтому пихают всё в один. Т.е. всё, что можно пакетами -- лучше паковать отдельно. Что-то тащить с собой -- вообще не особо страшно, но только если это не библиотека, с которой может быть слинковано что-то, дополнительно линкующееся с тем же самым проектом, что из какого-то сабмодуля, но идущего отдельным пакетом или таким же внутренним сабмодулем. (Ответ для Sergey V Turchin на комментарий #32) > Что-то тащить с собой -- вообще не особо страшно Если есть соотв. пакет, то уже очень плохо. (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 — собирается. Но полноценно работоспособность пакета проверить не могу ввиду его масштабов. Спасибо за ваши правки и рекомендации! (Ответ для 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 из > за таких вот кусков. Само собой, это тоже. > Но больше уверенности что пакет после сборки будет > работать так как задумывалось в рамках релиза. Но это имхо, так как привык > доверять разработчику. Ваша задача -- красиво упаковать. По работоспособности будете потом обсуждать с пользователями и отделом тестирования. Доброго дня В процессе перехода к сборке с уже существующими пакетами, наткнулся на необходимость обновления пакета 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/ С молчаливого неодобрения реализации подмодулей... Подгтовил вариант с использованием пакетов. Отдельная задача только для пакета 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 Жду ваши правки и рекомендации. Спасибо! Кандидат, это придирка конечно, но пробелы в конце строк в спеке это не красиво. http://git.altlinux.org/people/kaa/packages/optional-lite.git (Ответ для Иван Савин на комментарий #24) > (Ответ для Gleb F-Malinovskiy на комментарий #23) > > (In reply to Иван Савин from comment #22) > > > Думаю, кандидат готов к переходу на следующий этап. > > > > Мне кажется, что любой рецензент скажет, что одного пакета мало. Вы > > уверены, что этого пакета будет достаточно? > > Согласен. Поторопился. > Кандидат, прошу Вас предоставить больше примеров. Секретарь, думаю что кандидат предоставил достаточно пакетов. Если Вы согласны, то прошу перевести его на следующий этап. (Ответ для Aleksei Kalinin на комментарий #37) > С молчаливого неодобрения реализации подмодулей... Если что, я не одобрял хранение в репозитории бинарных файлов вместо открытых исходников. Если компонент слишком специфичный или патченый так, что другим лучше им не пользоваться, то лучше уж таскать с собой, чтоб никто его не видел. (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 > реализовал и второй > вариант упаковав каждый подмодуль. > 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 Секретарь, предлагаю призвать рецензента. Пока рисуется пентаграмма призыва. Обратил внимание, давно не обновлялся kdiff3. Буду благодарен за исправления рекомендации! (In reply to Aleksei Kalinin from comment #44) > Пока рисуется пентаграмма призыва. > Обратил внимание, давно не обновлялся kdiff3. > Буду благодарен за исправления рекомендации! Номер задачи в режиме тестирования https://git.altlinux.org/tasks/323889/ 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 Первый раз столкнулся с квотами gitery(kde5-kstars оказался "тяжелым" ) после оптимизации репозитория и чистки хранилища получилось протолкнуть исходники. На данный момент все пакеты https://git.altlinux.org/people/kaa/packages/ касаются join. Их набралось приличное количество, и разбираться в них представляется затратным по времени... Возможно ли получить конкретное задание от рецензента или может быть любой более актуальный пакет для сборки/обновления? Жду правок и наставлений! Спасибо! Прошу прощения, что случайно подсмотрел... У вас коммиты как-то очень странно называются. На примере awesome: 🦭4.3-alt5. Я думал, что это опечатка в одном коммите, но потом глянул другие пакеты и там то же самое. Не прольёте ли немножко света на эту ситуацию? (Ответ для 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 ? Актуально было и будет всегда. (In reply to Grigory Ustinov from comment #48) > Прошу прощения, что случайно подсмотрел... У вас коммиты как-то очень > странно называются. На примере awesome: 🦭4.3-alt5. Я думал, что это > опечатка в одном коммите, но потом глянул другие пакеты и там то же самое. > Не прольёте ли немножко света на эту ситуацию? Не нашел строго теребования к комитам и добавил "самодеятельность" подобного рода. Показалось символичным добавлять символ Нерпы в коммит там где код стал Альтом. Особенно это ярко выражено на кодовой базе https://git.altlinux.org/people/kaa/packages/python3-module-myst-parser.git Как раз ждал замечаний-требований по этому решению. Разумеется исправлю если это неприемлемо. (Ответ для 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 > > Как раз ждал замечаний-требований по этому решению. Разумеется исправлю если > это неприемлемо. Насколько мне известно, строго требования к именованию релизных коммитов у нас действительно нет. Но тем не менее, Нерпа не везде отображается корректно. Когда я писал своё сообщение, я не вникал в суть символа и ориентировался просто на пустой квадратик. Скажем так, я бы не хотел видеть смайлики в названиях коммитов "моих пакетов" как минимум. Как максимум, бог знает сколько людей думает так же и это можно вынести на широкое обсуждение=) Я думаю, что тут есть и ментор и рецензент и моё мнение будет явно лишним. Как говорится "Я только спросить". (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. (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 > > > > Как раз ждал замечаний-требований по этому решению. Разумеется исправлю если > > это неприемлемо. > > Насколько мне известно, строго требования к именованию релизных коммитов у > нас действительно нет. Но тем не менее, Нерпа не везде отображается > корректно. Когда я писал своё сообщение, я не вникал в суть символа и > ориентировался просто на пустой квадратик. > > Скажем так, я бы не хотел видеть смайлики в названиях коммитов "моих > пакетов" как минимум. Как максимум, бог знает сколько людей думает так же и > это можно вынести на широкое обсуждение=) Я думаю, что тут есть и ментор и > рецензент и моё мнение будет явно лишним. > > Как говорится "Я только спросить". Да, тоже заметил не стабильное отрабатывание этого символа. До какого-то обновления у меня и терминал отображал этот символ. Сейчас нет. Не вникал в причины. Разумеется для пакетов которые уже имеют мэйнтейнеров подобные вольности не позволительны. Что бы было понятно, предварительно отслеживаю стиль коммитов, стратегию ведения репозитория и после этого вношу какие-то изменения соблюдая стиль. Затронул лишь те пакет которые "отвалились" или "притянутые" лично мной. По поводу обсуждения, не знаю стоит ли выносить подобное, и не знаю как. Но выглядит занятно. = ) Если подобное не возбраняется, пока это могло бы стать особенностью моих пакетов. Сергей Григорий Спасибо за Ваши комментарии. Вы активно участвуете в моем баге. И частично знаком с предложенными в ходе обсуждения пакетами. Если не затруднит, и у кого-то из Вас найдется время, может быть Вы могли бы занять роль рецензента? Если это возможно и секретарь не будет против. В любом случае благодарен за участие! (Ответ для 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 и т.д.. (Ответ для Aleksei Kalinin на комментарий #52) > Для kstars, с Вашег одобрения, перенес в /usr/bin/kstars. Так правильнее https://git.altlinux.org/gears/k/kde5-kstars.git?p=kde5-kstars.git;a=commitdiff;h=0b6756f8798de7cf9b5d324ee4de5a090b00c4c6 (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/ (Ответ для Aleksei Kalinin на комментарий #57) > стоило догадаться что надо учесть взаимоисключаемость с kde4 -_- Учту. Не только. Файлы данных тоже переехали, иначе по умолчанию были бы недоступны самому приложению. UP Заметил что "отвалился" python модуль admesh https://packages.altlinux.org/en/sisyphus/srpms/python-module-admesh/, попутно заметил давно не обновлялся пакет admesh. Учитывая тенденцию на завершение пддержики python2 вырезал связанный с ним функционал и подновил spec. Изменения тут: https://git.altlinux.org/tasks/324627/ Буду благодарен за исправления рекомендации! Исправлена ошибка связанная с утилитой girar-show пакет girar-utils. В истории git этого пакета два вида добавления коммитов, с разделением bump версии и исправления spec, и совмещенное исправление и поднятие версии. Поскольку мои правки не значительны и проблема решается в одну строку, исправления в spec и саму ошибку объединил в один коммит. Есть ли какое-то строгое правило на этот счет или подобного рода подход считается приемлемым? https://git.altlinux.org/tasks/324696 (Ответ для Aleksei Kalinin на комментарий #60) > Исправлена ошибка связанная с утилитой girar-show пакет girar-utils. > > В истории git этого пакета два вида добавления коммитов, с разделением bump > версии и исправления spec, и совмещенное исправление и поднятие версии. > > Поскольку мои правки не значительны и проблема решается в одну строку, > исправления в spec и саму ошибку объединил в один коммит. > Есть ли какое-то строгое правило на этот счет или подобного рода подход > считается приемлемым? > > https://git.altlinux.org/tasks/324696 В истории коммитов этого пакета подобное есть. Значит, теоретически, так можно. Алексей, сколько ты уже пакетов подготовил? Думаю нужно остановиться и дождаться решения рецензента. (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 одобрил исправления. Призван рецензент (rider@) для независимой оценки готовности кандидата. T/J/S -> 4.2. - 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 - так лучше читается. https://git.altlinux.org/tasks/321695 rapidjson: не нравится мне идея в rules паковать по тэг c release. Лучше сделать diff по тэгу и приложить патч в specfile. Так и изменения будут нагляднее, и лишнего в тарболле не будет. any: мне в принципе не нравится такой формат репозитория - предлагаю сделать по аналогии с rapidjson, когда наши изменения живут в одном дереве с апстримом и патчи делаются через diff в .gear/rules В данном случае ещё у апстрима нет релиза, поэтому можно просто запаковать весь проект не по тэгу, а изменения закоммитить прямо в ветку и отдать в апстрим. https://git.altlinux.org/tasks/321695: optional-lite репозиторий тоже надо переделать поверх апстримного, тарболл делать из апстримного тэга. Зачем в release указан ещё git коммит непонятно. 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= можно просто убрать, тоже непонятно зачем они здесь нужны. https://git.altlinux.org/tasks/321695/ Большинство предыдущих замечаний касается и python3-module-OpenTimelineIO-gen3.git Нужно переделать в соотвествии с предыдущими замечаниями и написать мне в личке (телеграм желательно) - я посмотрю. kdiff3 https://packages.altlinux.org/ru/tasks/323889/ непонятно как был сделан merge. Выглядит очень странно. Я бы его переделал. Из commit message непонятно зачем понадобилось это изменение: Allows execute kdiff3 from terminal with 'kdiff3-kde5' name И почему оно не запускается как kdiff3 kde5-kstars: https://git.altlinux.org/tasks/323974/ просьба посмотреть @zerg admesh https://packages.altlinux.org/en/tasks/156814/ Убрать тэг Packager и дубли URL в спеке (комментарий) и я бы ещё убрали COPYING из файлов пакета, т.к. лицензия стандартная. Плюс тэг License привести в единообразие с версией лицензии в тексе COPYING (Ответ для Anton Farygin на комментарий #70) > kde5-kstars: > https://git.altlinux.org/tasks/323974/ > просьба посмотреть @zerg Я уже давно сам обновил. (Ответ для 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 пакуется независимо от того, существует или нет, хотя создаётся по условию. https://packages.altlinux.org/ru/tasks/324627/ approve выписан - замечания применены. Актуализирую статус и небольшое резюме Список рекомендаций от рецензента: - Указать значения «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. collabora-online собрана проверена одобрена rider для sisyphus Взята на самая свежая версия исходников так как она соответствует существующему в sisyphus libreofficekit. Пакет ориентирован на работу в изолированном окружении, и предполагает повышенные разрешения. Было принято решение отдать выбор пользователю --- сделан вывод с предупреждениями и рекомендациями при установке пакета. Исключены инструкции дублирующие filetriggers. Вообще было бы хорошо провести полноценное тестирование этой махины, но у меня нет такой возможности. Дополнительно для обновления был выдан пакет libopencv. Столкнулся с проблемой не хватки места на git.altlinux.org/people/kaa/ write error: Disk quota exceeded Возможно ли увеличить место? На данный моемнт, что бы не тратить время удалил всё. (Ответ для Aleksei Kalinin на комментарий #76) > Взята на самая свежая версия исходников так как она соответствует > существующему в sisyphus libreofficekit. Лучше ориентироваться на libreofficekit-still. Он стабильнее и новее. @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
(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... (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 На данный момент в рамках энжойн в sisyphus принято 13 пакетов под моим именем. Задача отнимает слишком много времени. Меня устраивает возможность вносить изменения в пакеты с одобрения зинтересованных мэйнтейнеров. Всем спасибо за помощь и участие! > WONTFIX
Это может означать удаление ключей. Да и резолвит баг тот, кому он назначен.
У меня вопрос... А какие ещё должен проявить навыки Алексей, чтобы его приняли в ALT Linux Team? По-моему, он достаточно много провёл работы, чтобы рецензент одобрил его кандидатуру. Много очень ошибок возникает при сборке. Несовместимых с самостоятельной сборкой пакетов в репозиторий. при этом итоговый результат всех устраивает, но без review Алексею пока пакеты в репозиторий лучше не отправлять. (Ответ для Evgeny Sinelnikov на комментарий #84) > WONTFIX → LATER (Ответ для Sergey V Turchin на комментарий #83) > Да и резолвит баг тот, кому он назначен. :-) (Ответ для Anton Farygin на комментарий #85) > Много очень ошибок возникает при сборке. > Несовместимых с самостоятельной сборкой пакетов в репозиторий. Какие конкретно ошибки, по каким конкретно пакетам проявлены и не исправлены, чтобы можно было уверенно заявить, что работа данного кандидата несовместима с "с самостоятельной сборкой пакетов в репозиторий"? Насколько я вижу все пакеты исправлены по достаточно противоречивым требованиям разных мейнтейнеров. При этом освоены такие схемы сборки, которыми не обладают некоторые бывалые люди в Team. Ну из последнего, что я помню - при сборке python модуля не разобрался с межпакетными зависимостями и сделал наоборот - вместо добавления нужного provides загасил requires. Ну и совсем банальные, вроде намешанных изменений из разных коммитов. Из-за невнимательности. "Пусть первый, кто тут без греха, бросит в него камень". Это всё не конкретные примеры. Ссылки, пожалуйста... Хотя это бесполезно. Считаю данное мнение предвзятым. Алексей, предлагаю, по мере появляющегося времени, публиковать здесь сборки своих пакетов, чтобы избегать предвзятых аргументов. Сейчас предлагаю сфокусироваться на конкретных деталях: - взять очередной пакет из требований рабочего процесса; - разобрать уже сложившиеся в выбранном пакете проблемы, накопленные более "опытными" и "достойными" товарищами; - подготовить его сборку, обновление или исправление. По результатам будем разбирать где, когда и кем в данном пакете осуществлены некомпетентные и банальные ошибки. И уже из этих исправлений тогда делать выводы. Какие ссылки ? git уже давно переписан. Ну раз вы считаете моё мнение предвзятое, то с данным ментейнером разбирайтесь сами. (Ответ для Anton Farygin на комментарий #91) > Какие ссылки ? git уже давно переписан. > > Ну раз вы считаете моё мнение предвзятое, то с данным ментейнером > разбирайтесь сами. Прошу рецензента указать причину возврата к пункту 3.5. По каким вопросам требуется дополнительная работа? Не могу быть рецензентом данного кандидата в связи с обвинениями в предвзятости. А в целом надо поработать над внимательностью и с теми пакетами, которые мы собирали вместе - всегда были какие-то ошибки разной степени критичности. Рекомендую следующему рецензенту посмотреть как кандидат самостоятельно, без чужой помощи, собирает новые и обновляет существующие пакеты. Прошу секретаря призвать рецензента. По поводу самостоятельности считаю необходимым расставить акценты Перечислю пакеты которые собраны только в рамках процедуры 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 который пришлось крутить и всячески тестировать в разных режимах. Подход к обновлению пакетов был строго с точки зрения оказание содействия мэйнтейнеру ведущему пакет, но не переделывание уже сложившейся культуры или стиля. Предложенные пакеты разносторонние и затрагивают многие механизмы системы. Продолжая в таком духе, можно было бы набрать больше пакетов для поддержки, но ввиду не схожих рабочих задач и недостатка времени, не все из эти пакеты смогу поддерживать. Адрес подписан на devel@, теперь это делается раньше -- в пункте 3.6. |
