Created attachment 9167 [details]
GPG Key

Принял. Готовлю тестовое задание.

(Ответ для Alexey Shabalin на комментарий #2)
> Принял. Готовлю тестовое задание.
(Ответ для ALexey Kostarev на комментарий #0)
> Создано вложение 9166 [details] [подробности]
> SSH-ключ
(Ответ для ALexey Kostarev на комментарий #1)
> Создано вложение 9167 [details] [подробности]
> GPG Key

Ok.

Прошу создать учетную запись на git.altlinux.org и предоставить возможность тестовой сборки на сборочном сервере.

Предлагаю переделать gpg ключ.
Если устраивает логин kaf, то в gpg ключе укажите email kaf@altlinux.org.
В описании ключа упоминать сторонний email kaf@nevod.ru совсем лишнее.
Оставьте только "Alexey Kostarev".
Для ключа можно добавить дополнительные email.

PS: ssh ключ можно не переделывать, там комментарий не существенный, при добавлении на сервер его все равно поправят, я так думаю.

Created attachment 9177 [details]
Новый GPG-ключ  для E-mall kaf@altlinux.org

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

T/J/S -> 2.4.

Created attachment 9191 [details]
Новый ssh-ключ

Коллеги к сожалению я запятовал свой пароль к ssh-ключу
Есть ли возможность заменить открытый ключ на приложенный?

Created attachment 9198 [details]
Подписанный новый ssh-ключ

(Ответ для ALexey Kostarev на комментарий #8)
> Создано вложение 9191 [details] [подробности]
> Новый ssh-ключ
> 
> Коллеги к сожалению я запятовал свой пароль к ssh-ключу
> Есть ли возможность заменить открытый ключ на приложенный?
(Ответ для ALexey Kostarev на комментарий #9)
> Создано вложение 9198 [details] [подробности]
> Подписанный новый ssh-ключ

Да, так можно предположить, что этот ssh-ключ и gpg-ключ чуть выше сделал один и тот же человек. :)
Ключи на серверах обновил, проверяйте.

Прошу добавить gpg ключ на сборочницу для сборки тестовых заданий.

(Ответ для ALexey Kostarev на комментарий #0)
> как любитель базы ClickHouse было бы интересно собрать пакет для него

Этот? :)

http://packages.altlinux.org/clickhouse

Да спасибо - я его уже обнаружил и попытался собрать у себя

Но сходу не получилось

Версия там довольно старая - 20.3

Мне же сейчас нужна 20.12 или 21.2 - там есть поддержка Postgers Wire Protocol

Я пока поступаю проще - собираю свежий docker-образ на основе стандартного, добавляя необходимые мне плюшечки - возможность описания при запуске списка импортируемых таблиц из БД postgres

https://github.com/Flexberry/dockerfiles/tree/master/clickhouse/official

При навешивании тега на hub.docker.com срабатывает пересборка образа
https://hub.docker.com/r/flexberry/clickhouse-official

Да коллеги мой gpg-ключ еще не попал в gyle?
Остались еще какие-либо проблемы?

Хотелось бы получить подарок на 23 февраля.


Ставлю в очередь task на gyle:
$ ssh gyle task add repo haproxy 2.3.5-alt1
gpg: Signature made Fri Feb 19 13:28:46 2021 UTC
gpg:                using RSA key 0x0DD3B4F9127CA906
gpg: Can't check signature: public key not found
task add: 2.3.5-alt1: tag signature verification failure

(In reply to Alexey Shabalin from comment #11)
> Прошу добавить gpg ключ на сборочницу для сборки тестовых заданий.

T/J/S -> 3.0.

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

T/J/S -> 3.4.

Кандидат уже успешно собрал пару простых заданий (обновление существующих пакетов с помощью srpm и gear). Я их пропустил в сизиф.

Заключительное задание на сборку нового пакета.
Приглашаю к review #269308.

Из моих замечаний:
- временные файлы patroni.spec~ в репо
- patroni.init надо адаптировать на основе альтовых шаблонов
- patroni.service в таком виде не нужен, он вызывает patroni.init
  В service файле лучше использовать что-то типа
Type=simple
User=postgres
Group=postgres
EnvironmentFile=/etc/sysconfig/patroni
ExecStart=/usr/bin/patroni /etc/patroni/config.yml
ExecReload=/bin/kill -s HUP $MAINPID
KillMode=process

- вместо %_sysconfdir/%{name}_env.conf надо использовать %_sysconfdir/sysconfig/%name
- в config.yml 
  log_filename: 'postgresql-2.0.1-ALT.log'
  Точно логи должны привязываться к версии?
  тоже самое про scope: "2.0.1-ALT"
- отсутствуют настройки для log rotation

К python3-module-pysyncobj и python3-module-ydiff у меня претензий нет.

(Ответ для Alexey Shabalin на комментарий #17)
> - вместо %_sysconfdir/%{name}_env.conf надо использовать
> %_sysconfdir/sysconfig/%name

  А почему не %_sysconfigdir/%name ?

(Ответ для Alexey Shabalin на комментарий #17)
> - patroni.init надо адаптировать на основе альтовых шаблонов
По этой части могу попробовать содействовать в качестве со-ментора.

(Ответ для Andrew Vasilyev на комментарий #18)
> (Ответ для Alexey Shabalin на комментарий #17)
> > - вместо %_sysconfdir/%{name}_env.conf надо использовать
> > %_sysconfdir/sysconfig/%name
> 
>   А почему не %_sysconfigdir/%name ?

Исходя из того, что 
$_sysconfdir  = /etc
Алексей Шабалин прав
 %_sysconfdir/sysconfig/%name

(Ответ для Alexey Shabalin на комментарий #17)

> - patroni.init надо адаптировать на основе альтовых шаблонов

Добрый день, коллеги
У меня вопрос по зависимостям

Во время запуска patroni должен существовать пользователь postgres
и одна из доступных версий postgres-серверов
postgresql9.5-server
postgresql9.6-server
postgresql10-server
...
postgresql13-server

Мне в зависимостях для patroni писать общее имя из Provides этих пакетов?

Там два кандидата
/usr/bin/postgres
postgresql-server

Какой предпочnительный?

И да - в этом случае я могу рассчитывает на наличие пользователя postgres при запуске init-скриптов

Кстати сейчас встал в тупик - а где в пакетах описываются и создаются пользователи в случае нербходимости?

> - вместо %_sysconfdir/%{name}_env.conf надо использовать
> %_sysconfdir/sysconfig/%name


Да и коллеги у меня вопрос по экспорту переменных

В качестве ствртового скрипта у меня используется 
python3 модуль /usr/bin/patroni

Ему надо передать переменные среды их файла
%_sysconfdir/sysconfig/patroni

Я его читаю в /etc/init.d/patroni через
ENVFILE=/etc/sysconfig/patroni
SourceIfNotEmpty $ENVFILE

но далее привызове 
start-stop-daemon --start ... --name patroni  --user postgres --startas /bin/su - ...

Я эту среду теряю

Что делать писать дополнительный shell_скрипт для импорта среды из
/etc/sysconfig/patroni
?

Зачем тогда функция 
SourceIfNotEmpty
?

(Ответ для Alexey Shabalin на комментарий #17)
 
> Заключительное задание на сборку нового пакета.
> Приглашаю к review #269308.
> 
> Из моих замечаний:
> - временные файлы patroni.spec~ в репо
Удалил

> - patroni.init надо адаптировать на основе альтовых шаблонов
- Перевел на: 
  start_daemon
  stop_daemon
  status
- добавил поддержку softdog/watchdog

> - patroni.service в таком виде не нужен, он вызывает patroni.init
>   В service файле лучше использовать что-то типа
> Type=simple
> User=postgres
> Group=postgres
> EnvironmentFile=/etc/sysconfig/patroni
> ExecStart=/usr/bin/patroni /etc/patroni/config.yml
> ExecReload=/bin/kill -s HUP $MAINPID
> KillMode=process
- Поменял
- Добавил поддержку softdog/watchdog

> - вместо %_sysconfdir/%{name}_env.conf надо использовать
> %_sysconfdir/sysconfig/%name
Изменил
Так как environments через su - не передаются добавил дополнительный shell-скрипт
/usr/bin/patroni.sh 
для инициализации переменных под пользователем postgres
перед вызовом python-скрипта /usr/bin/patroni

> - в config.yml 
>   log_filename: 'postgresql-2.0.1-ALT.log'
упростил до postgresql.log
>   Точно логи должны привязываться к версии?
Это наследство от пакеа в ubuntu, еде в рамках одного сервера могут запускаться несколько версий postgres

>   тоже самое про scope: "2.0.1-ALT"
Упростил до ALT

> - отсутствуют настройки для log rotation
Мне кажется не стоит использовать стандартный logrotation
так как после ротации приходится перегруэать patroni и postgres
что может привести к смене лидера HA-кластера
Так что воспоьзовался встроенной ротацией patroni и postgres
Правда в этом случае архивные логи не сжимаются что приводит к небольшому overhead по дисковому пространству

patroni:
В /etc/sysconfig/patroni добавлены настройки ротации логов:
## LogRotate tuning
export PATRONI_LOG_DIR=/var/log/patroni
export PATRONI_LOG_FILE_NUM=7
export PATRONI_LOG_FILE_SIZE=1200000

Логи, к сожалению, в patroni ротируются не по времени - только по объему
Предельный размер 1.2Mb при стандартном режиме работы (логи статуса patromi -master/slave) лог достигает примерно за сутки
Так что при обычном режиме работы логи будут храниться в недельном промежутке

postgres:
В /etc/patroni/config.yml добавлена неделная ротация ежедневных  логов:
    logging_collector: 'on'
    log_directory: '/var/log/patroni'
    log_filename: 'postgresql_%a.log'
    log_truncate_on_rotation: 'on'
    log_rotation_age: 1440

(Ответ для Andrew Vasilyev на комментарий #18)
> > %_sysconfdir/sysconfig/%name
> А почему не %_sysconfigdir/%name ?
Похоже, это достаточно свежий макрос -- я бы пока не закладывался.

(Ответ для ALexey Kostarev на комментарий #21)
> Мне в зависимостях для patroni писать общее имя из Provides этих пакетов?
> Там два кандидата
> /usr/bin/postgres
> postgresql-server
> Какой предпочnительный?

Я бы определённо ставил зависимость на postgresql-server (полагаю, она и сама ясней, и более чётко коррелирует с именами именно серверных пакетов).

> И да - в этом случае я могу рассчитывает на наличие пользователя postgres
> при запуске init-скриптов

Да; конкретно postgres:46 у нас вообще в пакете setup определён.

> Кстати сейчас встал в тупик - а где в пакетах описываются и создаются
> пользователи в случае нербходимости?
См. http://altlinux.org/Pseudo_User_Policy (важно не _удалять_ пользователей).

(Ответ для ALexey Kostarev на комментарий #22)
> Я его читаю в /etc/init.d/patroni через
> ENVFILE=/etc/sysconfig/patroni
> SourceIfNotEmpty $ENVFILE
Если $ENVFILE больше нигде не используется -- я бы упростил до
SourceIfNotEmpty /etc/sysconfig/patroni

> Зачем тогда функция 
> SourceIfNotEmpty
> ?
Чтобы проверить наличие и непустоту файлика, который предлагается зачитать:

---
SourceIfNotEmpty()
{
        local f
        f="$1"
        shift
        [ -s "$f" ] && . "$f" "$@"
}
--- /etc/init.d/functions

(Ответ для ALexey Kostarev на комментарий #23)
> Так как environments через su - не передаются добавил дополнительный
> shell-скрипт
> /usr/bin/patroni.sh 
> для инициализации переменных под пользователем postgres
> перед вызовом python-скрипта /usr/bin/patroni
"Передай patroni" ;-)

(Ответ для Michael Shigorin на комментарий #24)
> (Ответ для Andrew Vasilyev на комментарий #18)
> > > %_sysconfdir/sysconfig/%name
> > А почему не %_sysconfigdir/%name ?
> Похоже, это достаточно свежий макрос -- я бы пока не закладывался.
Да - не сначала не заметил разницы в написании
В настоящий момент %_sysconfigdir нет в
https://www.altlinux.org/Spec/%D0%9F%D1%80%D0%B5%D0%B4%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5_%D0%BC%D0%B0%D0%BA%D1%80%D0%BE%D1%81%D1%8B 

> 
> (Ответ для ALexey Kostarev на комментарий #21)
> > Мне в зависимостях для patroni писать общее имя из Provides этих пакетов?
> > Там два кандидата
> > /usr/bin/postgres
> > postgresql-server
> > Какой предпочnительный?
> 
> Я бы определённо ставил зависимость на postgresql-server (полагаю, она и
> сама ясней, и более чётко коррелирует с именами именно серверных пакетов).
> 
OK
Добавил в 
http://git.altlinux.org/people/kaf/packages/?p=patroni.git;a=blob;f=.gear/patroni.spec;h=2bfecaaba9e61e7b6371efa7585ff87bd499f69a;hb=HEAD

> > И да - в этом случае я могу рассчитывает на наличие пользователя postgres
> > при запуске init-скриптов
> 
> Да; конкретно postgres:46 у нас вообще в пакете setup определён.
> 
> > Кстати сейчас встал в тупик - а где в пакетах описываются и создаются
> > пользователи в случае нербходимости?
> См. http://altlinux.org/Pseudo_User_Policy (важно не _удалять_
> пользователей).
В моей ситуации так как patroni зависит от postgres-server пользователь postgres уже будет создан при установке postgres-server

> 
> (Ответ для ALexey Kostarev на комментарий #22)
> > Я его читаю в /etc/init.d/patroni через
> > ENVFILE=/etc/sysconfig/patroni
> > SourceIfNotEmpty $ENVFILE
> Если $ENVFILE больше нигде не используется -- я бы упростил до
> SourceIfNotEmpty /etc/sysconfig/patroni
> 
> > Зачем тогда функция 
> > SourceIfNotEmpty
> > ?
> Чтобы проверить наличие и непустоту файлика, который предлагается зачитать:
> 
> ---
> SourceIfNotEmpty()
> {
>         local f
>         f="$1"
>         shift
>         [ -s "$f" ] && . "$f" "$@"
> }
> --- /etc/init.d/functions
Да этоя просиотрел, правда не знал что в операиях
. <shell-scriop>
можно передавать параметры ($@)

> 
> (Ответ для ALexey Kostarev на комментарий #23)
> > Так как environments через su - не передаются добавил дополнительный
> > shell-скрипт
> > /usr/bin/patroni.sh 
> > для инициализации переменных под пользователем postgres
> > перед вызовом python-скрипта /usr/bin/patroni
> "Передай patroni" ;-)
Так и сделал

Испрововал несколько вариаентов

- использвоания python-модуля импортирующего shell ENV-файл в sys.environment python-скрипта 
  - надо создавать этот модуль в Sisiyphus

- смена типа скрипта /usr/bin/patrony с python3 на ырудд
#!/bin/sh
. /etc/sysconfog/patroni
exec /usr/bin/python3 <<EOF
...
EOF

  - patroni некорректно формируем имя стартового скрипта (добавляет <stdin> в имя) и сваливается

- добавление shell-скрипта /usr/bin/patroni.sh в котором после инициализации вызывается python скрипт /usr/bin/patroni

В итоге остановился на последнем варианте...

Коллеги - жду вердикта...

Прошу перевести на следующий уровень.
Только я уже не пойму, какой это, 4.1?
Мое решение - кандидат готов для вступления в team.
Жду подтверждения от второго ментора.

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

T/J/S -> 4.2.

Предложения и рекомендации:

1) http://git.altlinux.org/people/kaf/packages/?p=bootupd.git;a=commitdiff;h=d0453c70238fc8395cf5fc140e2ee4cd52503758

Советую использовать конструкцию "%define _unpackaged_files_terminate_build 1". 

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

Также, по совету ldv@, стоит по возможности использовать "%define _stripped_files_terminate_build 1" и "%set_verify_elf_method strict".

2) http://git.altlinux.org/people/kaf/packages/?p=bootupd.git;a=commitdiff;h=d0453c70238fc8395cf5fc140e2ee4cd52503758

Packager: Alexey Kostarev <kaf@altlinux.org>

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

3) http://git.altlinux.org/people/kaf/packages/?p=butane.git;a=commitdiff;h=1436e45c9ac35b6b163b937a90cdbca00bf57139

License: Apache License 2.0

По возможности лучше указывать лицензию так, как они называются в /usr/share/license. Об этом даже есть предупреждение при сборке пакета.
Для этой цели может быть полезна утилита nomossa из пакета fossology-nomos, которая должна быть доступна в Сизифе и p10.

4) http://git.altlinux.org/people/kaf/packages/?p=patroni.git;a=commitdiff;h=b52bb4b4ae90a4433d00887d3e75ff870bfbe368

%python3_sitelibdir/%name/
%python3_sitelibdir/*egg-info

Возможно лучше будет вынести эти файлы в отдельный пакет python3-module-%name: если у какого-то другого питоновского пакета появится зависимость на этот модуль питона, то он вытянет весь этот пакет. Или в таком случае нужно будет в том числе и всё что за пределами %python3_sitelibdir в данном пакете есть?

5) http://git.altlinux.org/people/kaf/packages/?p=patroni.git;a=commitdiff;h=b52bb4b4ae90a4433d00887d3e75ff870bfbe368

Странная комбинация .gear/rules и .gear/tags.

В .gear/rules:
tar: .
spec: .gear/patroni.spec
copy: .gear/*.yml
copy: .gear/*.init
copy: .gear/*.service
copy: .gear/*.sh
copy: .gear/*.py
copy: .gear/*.conf

Почти все файлы в директории .gear копируются дважды - в общий архив tar, и ещё раз отдельно.

А в одном из следующих коммитов

http://git.altlinux.org/people/kaf/packages/?p=patroni.git;a=commitdiff;h=aa332fd9afda892e5f1c8315e27af44993c6de11

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

Я считаю, что это стоит переделать: брать исходники из апстримного тэга вместо просто "tar: .", тогда не будет дублирования файлов, и заодно этот апстримный тэг сохранить в .gear/tags, и убрать оттуда находящийся там сейчас ненужный тэг.


Вопросы:

1) http://git.altlinux.org/people/kaf/packages/?p=butane.git;a=commitdiff;h=1436e45c9ac35b6b163b937a90cdbca00bf57139

BuildArch: x86_64

В связи с чем указаны такие строгие ограничения по архитектуре?

Насколько мне известно, для пакетов на golang обычно используется следующая конструкция:

ExclusiveArch: %go_arches
BuildRequires(pre): rpm-build-golang

2) http://git.altlinux.org/people/kaf/packages/?p=butane.git;a=summary

Здесь сначала идёт коммит, в котором добавляется почти весь spec-файл, затем merge с апстримным репозиторием, и затем добавляется запись в changelog. Почему сделано так? Почему нельзя было сделать просто 1 коммит поверх соответствующего тэга из апстрима?

В пакетах patroni, python3-module-pysyncobj и python3-module-ydiff обнаружил тоже самое.

3) http://git.altlinux.org/people/kaf/packages/?p=bootupd.git;a=commitdiff;h=d0453c70238fc8395cf5fc140e2ee4cd52503758

Чем не подходят макросы %rust_build / %rust_install / %rust_test из пакета rpm-macros-rust ?

4) http://git.altlinux.org/people/kaf/packages/?p=bootupd.git;a=commitdiff;h=d0453c70238fc8395cf5fc140e2ee4cd52503758

ExclusiveArch: x86_64 aarch64

А здесь почему выбрано такое ограничение на архитектуры? И в других пакетах на rust тоже такой вопрос. Насколько я знаю, rust доступен на большем количестве архитектур чем указано здесь. Для всех ли пакетов нужно такое строгое ограничение архитектур?

5) http://git.altlinux.org/people/kaf/packages/?p=patroni.git;a=commitdiff;h=b52bb4b4ae90a4433d00887d3e75ff870bfbe368

Скрипты patroni.py, patroni_aws.py, patroni_wale_restore.py, patronictl.py

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


Замечания:

1) git.altlinux.org/people/kaf/packages/?p=butane.git;a=commitdiff;h=1436e45c9ac35b6b163b937a90cdbca00bf57139

%pre / %post / %preun

Не стоит захламлять спек-файл пустыми секциями %pre / %post / %preun. Лучше их удалить. Если же они не должны быть пустыми, это надо поправить.

2) http://git.altlinux.org/people/kaf/packages/?p=coreos-installer.git;a=commitdiff;h=c5414e155e84508f88b1f7c08203d9cd3353fd17

Согласно https://www.altlinux.org/Spec#%description длина строк в поле %description не должна превышать 72 символа.

3) http://git.altlinux.org/people/kaf/packages/?p=patroni.git;a=commitdiff;h=b52bb4b4ae90a4433d00887d3e75ff870bfbe368

Пустая секция %pre.

4) http://git.altlinux.org/people/kaf/packages/?p=python3-module-prettytable.git;a=summary

Пакет явно не закончен, смотреть не на что.

5) В следующих пакетах неправильно указана лицензия в spec-файле:

http://git.altlinux.org/people/kaf/packages/?p=patroni.git;a=summary - в спеке указано GPLv2+, в репозитории - MIT
http://git.altlinux.org/people/kaf/packages/?p=python3-module-ydiff.git;a=summary - в спеке указано MIT, в репозитории - BSD-3-Clause

6) http://git.altlinux.org/people/kaf/packages/?p=zincati.git;a=commitdiff;h=e755cc4a5a531e9363e1afbd39d339d9f0e4519e

В директории .gear находится много файлов, которые при сборке и упаковке, похоже, не используются. Если они не нужны, то стоит их удалить.

7) http://git.altlinux.org/people/kaf/packages/?p=zincati.git;a=commitdiff;h=e755cc4a5a531e9363e1afbd39d339d9f0e4519e

%define zincati_user    zincati
%define zincati_group   zincati

...

%pre
if getent passwd zincati 
then
    userdel zincati
fi
if getent group zincati 
then
    groupdel zincati
fi
%_sbindir/useradd -c 'Zincati user for auto-updates' %name

Согласно https://www.altlinux.org/Pseudo_User_Policy, имена псевдопользователей и групп следует начинать с символа "_". Также там указаны рекомендуемые конструкции для создания таких пользователей и групп.

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

8) http://git.altlinux.org/people/kaf/packages/?p=zincati.git;a=commitdiff;h=e755cc4a5a531e9363e1afbd39d339d9f0e4519e

%define zincati_confdir3 /run/%name/config.d/
%define zincati_metrics_public_dir /run/zincati/public
%define zincati_metrics_private_dir /run/zincati/private
%define zincati_run_rpm_ostree /run/rpm-ostree/
%define zincati_run_ostree /run/ostree/

...

%files
...
%zincati_confdir3
%attr(-,zincati,zincati) %zincati_metrics_public_dir
%attr(-,zincati,zincati) %zincati_metrics_private_dir
%attr(-,zincati,zincati) %zincati_run_rpm_ostree
%attr(-,zincati,zincati) %zincati_run_ostree

Обычно /run является примонтированным tmpfs, всё её содержимое после перезагрузки пропадает. А это значит, что ничего туда упаковывать в пакеты нельзя, а если там всё-таки что-то нужно, и приложение там это само не создаёт, для создания стоит использовать tmpfiles.d:

https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html

Эту часть, похоже, поправили пока я смотрел. Но этот пункт всё равно оставлю.


Есть замечания, над которыми, я считаю, стоит поработать. Плюс пакеты zincati и patroni выглядят так, словно вступающий недостаточно освоился с .gear/rules и .gear/tags, поскольку везде используется конструкция "tar: ." даже если рядом ещё какие-то файлы копируются отдельно ещё раз, а в .gear/tags зачем-то добавляется неиспользуемый тэг, с именем, которое конфликтует с находящимся в репозитории тэгом.

kaf@ исправлены ли недостатки?

2 года нет движения. Неужели RESOLVED/TIMEOUT?

Актуально ли ещё?

Переоткройте, если будет актуально.

Доброго времени суток коллеги
Прошу прощения за остановку работ по моему JOIN 
В начале года я потерял доступ к почте kaf@nevod.ru по которой был зарегистрирован 
Кроме этого в начале года плотно занялся созданием набора пакетов podsec (podman security) для поддержки защиты policy в решениях podman, kubernetes и мониторинга нарушений защиты:
 https://git.altlinux.org/people/kaf/packages/?p=podsec.git
на основе собственного git-проекта 
https://github.com/kafnevod/podsec
https://github.com/alt-cloud/podsec

Кроме этого реализовал в рамках этого пакета rootless kubernetes
https://www.altlinux.org/Rootless_kubernetes

Эти пакеты включены в дистрибутив c10f1 и планируется включение последней версии  пакета 1.0.10 очередной релиз c10f2. Предыдущая версия 1.0.8 в октябре 2023 включена в релиз p10 
https://packages.altlinux.org/ru/search/?branch=sisyphus&q=podsec  

В связи с тем, что данная заявка закрыта я потерял 
доступ к  https://git.altlinux.org/people/kaf/packages/?p=podsec.git и
возможность вести пакет podsec  

Актуальность предыдущих вопросов по пакетам zincatti, bootupd пропала, так как эти пакеты портировал Андрей Соколов - https://packages.altlinux.org/ru/sisyphus/srpms/zincati/

В связи с эти прошу:
1. Открыть мою заявки в связи с необходимостью ведения группы пакетов podsec
https://packages.altlinux.org/ru/sisyphus/srpms/podsec/
2. Рассмотреть в рамках данной заявки реализованные группы пакетов podsec
3. В случае необходимости назначить мне для получения прав майнтейнера дополнительных пакетов для портирования

В данный момент все доступы отозваны, есть только email alias.
Постараюсь в ближайшие дни восстановить доступ к git.alt и gyle.alt.

ssh ключ на gitery.alt зарегистрирован.
ssh ключ на gyle.alt зарегистрирован.
Пакет alt-gpgkeys обновлён.
Адрес подписан на devel@.

Откатываю на стадию 3.6, мячик теперь на стороне ментора. :)

ping?

PONG

Добрый день
Я жду ответа на вопросы которые озвучил выше:
2. Рассмотреть в рамках данной заявки реализованные группы пакетов podsec
3. В случае необходимости назначить мне для получения прав майнтейнера дополнительных пакетов для портирования

Дополню, что в этом месяце 
- взял на сопровождение пакет podman-compose - https://git.altlinux.org/people/kaf/packages/?p=podman-compose.git;a=summary
- Оформил в рамках этого пакета pull request - https://github.com/containers/podman-compose/pull/820
и Issue - https://github.com/containers/podman-compose/issues/822
- так как приема pull request можно ждать довольно долго и не дождаться прорабатываю вариант добавления в наш пакет podman-compose скрипта конвертации podman-compose стека в kubernetes-маниесты:
  * https://www.altlinux.org/Podman-compose/kubernetes
  * https://github.com/alt-cloud/podman-compose/blob/pod-to-kubemanifests/bin/pod-to-kubemanifests
  * https://github.com/alt-cloud/podman-compose/blob/pod-to-kubemanifests/md/pod-to-kubemanifests.md
Планирую на этой и ближаыйшей неделе закончить написание, отладку и документирование скрипта

(Ответ для Gleb F-Malinovskiy на комментарий #37)
> ping?

Да
URL покета podsec - https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=summary