Bug 39627

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

Претендент готов посылать пакеты в сизиф.
Прошу призвать рецензента.
Для проверки кандидат подготовил сборочное задание #355139

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

T/J/S -> 4.2.

podsec:
1) changelog пакета немного не соответствует рекомендациям по написанию changelog'ов, принятых в ALT Linux Team (точка в конце предложения)
2) Не понял смысл этого задания: https://packages.altlinux.org/ru/tasks/350829/
3) changelog в https://packages.altlinux.org/ru/tasks/357651/ вообще жестокий, непонятно куда смотрел ментор.

Ну и надо бы ошибки на podsec разгрести. Я хотел бы посмотреть на работу над патчами.

Аппрув должен буду делать в этот раз я.

Что ещё посмотреть я не понял, но podsec меня ввёл в печаль.

(Ответ для Anton Farygin на комментарий #43)
> Что ещё посмотреть я не понял, но podsec меня ввёл в печаль.

Доброго времени суток

Вообще-то podsec не самая моя лучшая работа в плане соответствия стандартам портировния пакетов, но лучшая, по моему мнению, в плане функционала. На момент версии 1.0 в июне прошлого года это была первая в мире реализация поддержки rootless kubernetes с развертыванием через kubeadm. На тот момент надо было обеспечивать необходимый функционал для соответствия требований по сертификации rootless kubernetes для платформы c10f1. Обеспечивать соответствию требованиям портирования пакетов не была первоочередной задачей. 
Если есть конкретные замечания (кроме необходимости удалений точек в конце предложений), готов их устранять.

По поводу "что еще посмотреть" - в заявке был указан таск #355139
https://packages.altlinux.org/en/tasks/355139/

podsec (таск https://packages.altlinux.org/ru/tasks/357651/) в заявку не входил. 

Поэтому я не совсем понимаю, почему рецензент все внимание уделил НЕ ВХОДЯЩЕМУ В ЗАЯВКУ пакету podsec и ни слове не сказал о ВХОДЯЩЕМУ В ЗАЯВКУ набором из 8-ми пакетов для поддержки flux2?
При их реализации летом этого года я не был скован временными требованиями и пытался придерживаться стандартов портирования пакетов (хотя за точки в конце не поручусь).
Прошу предоставить замечания именно по заявленному таску https://packages.altlinux.org/en/tasks/355139/

(Ответ для Anton Farygin на комментарий #42)
> podsec:

> Аппрув должен буду делать в этот раз я.

Хотелось бы оперативно получить список замечений (наряду с отсутсвием точек в конце).

Пакет является одним из центральных, обсуждаемым в ходе еженедельных встреч по теме "Обсуждение ИК-01 Альт СП релиз 10". При наличии новых замечаний по функционалу  я буду вынужден реализовывать новые релизы и версии пакета podsec

В случае долгих блокировок я буду не способен проводить их на платформу c10f2.
Что может привести к задержке формирования окончательного ISO-образа для платформы c10f2.

Я готов оперативно устранять замечания рецензента, но не хотелось бы получать полную блокировку выхода очередных релизов и версия для платформы c10f2.

(Ответ для Anton Farygin на комментарий #43)
> Что ещё посмотреть я не понял, но podsec меня ввёл в печаль.

По основному заявленному таску
https://packages.altlinux.org/en/tasks/355139/
была собраны образы, проведено тестирование и подготовлена документация по разворачиванию:
https://packages.altlinux.org/en/tasks/355139/
Если есть замечания по wiki-статье готов проводить изменения

По podsec была подготовлена документация как в рамках самого пакета (в форматах markdown и man):
- https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=tree;f=podsec/md;h=aa2272d0ff37b4844e6c9938480884a1c3e47243;hb=HEAD
- https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=tree;f=podsec-k8s/md;h=fdc9ef45a27578948e1347003f2ddbbfceb7c813;hb=HEAD
- https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=tree;f=podsec-inotify/md;h=4042f78534e7a4040f85566419b624308ed51d5d;hb=HEAD
- https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=tree;f=podsec-k8s-rbac/md;h=8bfb277ed82e0b4f3a7c3acf34e017cfb194ecd3;hb=HEAD

так и по разворачиванию решения:
- https://github.com/alt-cloud/podsec/blob/master/usernetes/README.md
- https://www.altlinux.org/Rootless_kubernetes

вошедшая в состав документов для сертификации платформ c10f1, c10f2

Если есть замечания к оформлению готов в фоновом режиме дорабатывать документацию

Рецензент сам решает какую работу смотреть у кандидата.

Т.к. podsec собственная разработка, то предлагаю начать с неё.

первым делом предлагаю переписать весь changelog пакета, приведя его в порядок.
Все места, где в changelog указаны не изменения а version-release - раскрыть и написать в changelog сделанные изменения.

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

(Ответ для Anton Farygin на комментарий #47)
> Рецензент сам решает какую работу смотреть у кандидата.
> 
> Т.к. podsec собственная разработка, то предлагаю начать с неё.
> 
> первым делом предлагаю переписать весь changelog пакета, приведя его в
> порядок.
> Все места, где в changelog указаны не изменения а version-release - раскрыть
> и написать в changelog сделанные изменения.
> 
> Как только будет готово - присылайте номер сборочного задания.

OK
Задача понятна

(Ответ для Anton Farygin на комментарий #42)
> podsec:
> 1) changelog пакета немного не соответствует рекомендациям по написанию
> changelog'ов, принятых в ALT Linux Team (точка в конце предложения)

Прошу уточнить - точки в конце предложения ОБЯЗАТЕЛЬНЫ ии НЕОБЯЗАТЕЛЬНЫ
В документе https://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog указано
"Единообразно оформляйте предложения changelog’а: либо начинайте, либо не начинайте их все с большой буквы; либо заканчивайте, либо не заканчивайте их точкой."
речь идет об единообразии, а не об обязательности точек

В моем случае точки отсутствуют, что не нарушает указанное требование
Правда часть строк начинается с маленько буквы - исправлю на большие
Необходимо ли в этом случае ставить точки в конце?

По поводу требования оформления на английском языке
В самом начале развития проекта было принято решение (так как проект внутренний) писать логи на русском языке 
У меня в итоге смешанный формат оформления - часть логов на англмйском языка. Основная часть на русском
Допустимо ли оставить как есть?

(Ответ для ALexey Kostarev на комментарий #49)
> (Ответ для Anton Farygin на комментарий #42)
> > podsec:
> > 1) changelog пакета немного не соответствует рекомендациям по написанию
> > changelog'ов, принятых в ALT Linux Team (точка в конце предложения)
> 
> Прошу уточнить - точки в конце предложения ОБЯЗАТЕЛЬНЫ ии НЕОБЯЗАТЕЛЬНЫ
> В документе
> https://www.altlinux.org/
> %D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%
> BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog указано
> "Единообразно оформляйте предложения changelog’а: либо начинайте, либо не
> начинайте их все с большой буквы; либо заканчивайте, либо не заканчивайте их
> точкой."
> речь идет об единообразии, а не об обязательности точек

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

> 
> В моем случае точки отсутствуют, что не нарушает указанное требование
> Правда часть строк начинается с маленько буквы - исправлю на большие
> Необходимо ли в этом случае ставить точки в конце?

Да

> 
> По поводу требования оформления на английском языке
> В самом начале развития проекта было принято решение (так как проект
> внутренний) писать логи на русском языке 
> У меня в итоге смешанный формат оформления - часть логов на англмйском
> языка. Основная часть на русском
> Допустимо ли оставить как есть?

У нас уже достаточно давно есть правило оформлять всю разработку на одном английском языке. Т.к. мы не знаем что дальше будет с каким проектом и какие разработчики к нему подключатся в дальнейшем, а английский понятен всем.
Поэтому язык changelog'ов должен быть английский.

(Ответ для ALexey Kostarev на комментарий #49)
> (Ответ для Anton Farygin на комментарий #42)
> > podsec:
равда часть строк начинается с маленько буквы - исправлю на большие

> По поводу требования оформления на английском языке
> В самом начале развития проекта было принято решение (так как проект
> внутренний) писать логи на русском языке 
> У меня в итоге смешанный формат оформления - часть логов на англмйском
> языка. Основная часть на русском
> Допустимо ли оставить как есть?
Вопрос снимаю
Перевожу логи на английский

(Ответ для Anton Farygin на комментарий #50)

> > В моем случае точки отсутствуют, что не нарушает указанное требование
> > Правда часть строк начинается с маленько буквы - исправлю на большие
> > Необходимо ли в этом случае ставить точки в конце?
> 
> Да
Сделано

> 
> > 
> > По поводу требования оформления на английском языке
> > В самом начале развития проекта было принято решение (так как проект
> > внутренний) писать логи на русском языке 
> > У меня в итоге смешанный формат оформления - часть логов на англмйском
> > языка. Основная часть на русском
> > Допустимо ли оставить как есть?
> 
> У нас уже достаточно давно есть правило оформлять всю разработку на одном
> английском языке. Т.к. мы не знаем что дальше будет с каким проектом и какие
> разработчики к нему подключатся в дальнейшем, а английский понятен всем.
> Поэтому язык changelog'ов должен быть английский.
Да подзапамятовал
При наличии кирилических букв мой локальный hasher бинарные пакеты не собирает
Перевел на английский добавив к тексту точки
Локальный hasher бинарные пакеты собрал корректно

Поместил podsec c последней версией podsec-1.1.6-alt6 на https://git.altlinux.org/people/kaf/packages/?p=podsec.git 

Но в текущий момент к сожалению сервер https://git.altlinux.org/ не отвечает :-(
(504 Gateway Time-out
nginx)
и
и gyle (194.107.17.31)
хоть и пингуется, но обращение на порт 222 сваливаетcя по Timeout?
Коллеги говорят, что в выходные была аналогичная ситуация

Так что запустить задачу на сборку пока не могу :-(
Буду ждать оживления сервисов

> Буду ждать оживления сервисов
Сервисы заработали
Старый task к сожалению уже удален
Создал новый task
https://git.altlinux.org/tasks/358357/

 241 * Wed Sep 25 2024 Alexey Kostarev <kaf@altlinux.org> 1.1.6-alt6
 242 - Changelog of podsec.spec has been adjusted to comply with recommendations
 243 - Support for loading additional images into the archive

Точек нет.

Ещё правило хорошего тона, которое постоянно нарушается в этом пакете:
принято если изменение идёт только в спек-файле, то делать новый release.
если изменение в коде, меняющее функционал - то выпускать новую версию (увеличивая version).

(Ответ для Anton Farygin на комментарий #54)
>  241 * Wed Sep 25 2024 Alexey Kostarev <kaf@altlinux.org> 1.1.6-alt6
>  242 - Changelog of podsec.spec has been adjusted to comply with
> recommendations
>  243 - Support for loading additional images into the archive
> 
> Точек нет.

Как это нет - они стоят ровно в том месте, которое описано в  https://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog
В конце каждого пункта (- ...) и подпункта (+ ...)
Или что то другое имеется в виду

(Ответ для ALexey Kostarev на комментарий #56)
> (Ответ для Anton Farygin на комментарий #54)
> >  241 * Wed Sep 25 2024 Alexey Kostarev <kaf@altlinux.org> 1.1.6-alt6
> >  242 - Changelog of podsec.spec has been adjusted to comply with
> > recommendations
> >  243 - Support for loading additional images into the archive
> > 
> > Точек нет.
> 
> Как это нет - они стоят ровно в том месте, которое описано в 
> https://www.altlinux.org/
> %D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%
> BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog
> В конце каждого пункта (- ...) и подпункта (+ ...)
> Или что то другое имеется в виду

Н-да
В нескольких сотнях логов точки поставил
А во вновь добавленных 2-ч - нет :-)

Меня извиняет только то, что последние комментарии добавлял в конце рабочего дня
Переработаю

(Ответ для Anton Farygin на комментарий #55)
> Ещё правило хорошего тона, которое постоянно нарушается в этом пакете:
> принято если изменение идёт только в спек-файле, то делать новый release.
> если изменение в коде, меняющее функционал - то выпускать новую версию
> (увеличивая version).

Да - этот пункт я для мне объяснили, только несколько месяцев назад
Хотя в другой редакции

Если меняется функционал - увеличивается версия, если все остальное, то release

То есть правки ошибок, создание и добавление документов и т.п. вроде как не меняют функционал. Поэтому я в этом случае увеличивал release
Это правильно?

По увеличению версии тоже вопросы - когда менять патч, минор и мажор версии?
Тут хоть правила и есть, то границы довольно расплывчаты

В любом случае я не представляю как сейчас переработать структуру истории тегов
Часть тегов уже попала в ссылки сторонних документов и перемещать и менятьь их уже чревато

Хотя в дальнейшем развитии постараюсь придерживаться этого правила с учетом замечаний по вопросу выше (входит ли исправление ошибок и доьавление документации в правило увеличения Release или Version)

(Ответ для Anton Farygin на комментарий #54)
>  241 * Wed Sep 25 2024 Alexey Kostarev <kaf@altlinux.org> 1.1.6-alt6
>  242 - Changelog of podsec.spec has been adjusted to comply with
> recommendations
>  243 - Support for loading additional images into the archive
> 
> Точек нет.
Уф...

Добавил точки 
https://git.altlinux.org/tasks/358357/gears/400/git?p=git;a=blob;f=podsec.spec;h=ba9646a3996127a5e7cbc07212271949b1b37741;hb=HEAD#l241

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

https://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog#%D0%9B%D1%83%D1%87%D1%88%D0%B8%D0%B5_%D0%BF%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D0%BA%D0%B8_%D0%BE%D1%84%D0%BE%D1%80%D0%BC%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_changelog
Пункт 2

382 * Tue Nov 07 2023 Alexey Kostarev <kaf@altlinux.org> 1.0.10-alt1
...
399 - Improvements to the correct definition of the list and version of kuber images.
400 - Adding U7S_KUBEADFLAGS variable containing all additional kubeadm flags.
401 - Added analysis and processing of flags.
402 - Adding support for flags via getopt.
403 - Documenting kubeadm flags in /docs/kubead/README.md.
404 - Request for deletion of the /var/lib/podsec/u7s/etcd directory if it exists during init and join.
405 - Clarification of platform detection for sisyphus.
406 - More accurate automatic detection of environment variables U7S_PLATFORM, U7S_KUBEVERSION.
407 - Document kubeadm flags in /docs/kubeadm/README.md.
408 - Move tuneAudit after CNI startup, restart services after tuneAudit.
409 - Remove u7s.target and its dependencies.
410 - Replace u7s.target with /usr/libexec/podsec/u7s/bin/.

Здесь перечислены 4 формы отражения изменения:
Improvements - существительное
Adding - present continious
Added - Past simple
Move - Present simple

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

Григорий, спасибо. Согласен с замечаний. Алексей, просьба исправить и этот момент.

Традиционно, для коммитов (изменений в коде) у нас используется present simple, для записей changelog past simple.

(Ответ для Anton Farygin на комментарий #61)
> Григорий, спасибо. Согласен с замечаний. Алексей, просьба исправить и этот
> момент.
> 
> Традиционно, для коммитов (изменений в коде) у нас используется present
> simple, для записей changelog past simple.

Спасибо
Займусь

(Ответ для ALexey Kostarev на комментарий #58)
> (Ответ для Anton Farygin на комментарий #55)
> > Ещё правило хорошего тона, которое постоянно нарушается в этом пакете:
> > принято если изменение идёт только в спек-файле, то делать новый release.
> > если изменение в коде, меняющее функционал - то выпускать новую версию
> > (увеличивая version).
> 
> Да - этот пункт я для мне объяснили, только несколько месяцев назад
> Хотя в другой редакции
> 
> Если меняется функционал - увеличивается версия, если все остальное, то
> release
> 
> То есть правки ошибок, создание и добавление документов и т.п. вроде как не
> меняют функционал. Поэтому я в этом случае увеличивал release
> Это правильно?
> 
> По увеличению версии тоже вопросы - когда менять патч, минор и мажор версии?
> Тут хоть правила и есть, то границы довольно расплывчаты
> 
> В любом случае я не представляю как сейчас переработать структуру истории
> тегов
> Часть тегов уже попала в ссылки сторонних документов и перемещать и менятьь
> их уже чревато
> 
> Хотя в дальнейшем развитии постараюсь придерживаться этого правила с учетом
> замечаний по вопросу выше (входит ли исправление ошибок и доьавление
> документации в правило увеличения Release или Version)

Изменять старые версии пакета не нужно. Что бы не мучаться с выбором того или иного поведения при изменении пакета, я предлагаю использовать простой факт - меняется содержимое source tarball - меняем версию, меняется содержимое только spec и сопутствующих файлов без изменения source tarball - увеличивайте версию.

прошу прощения, корректировка:
Изменять старые версии пакета не нужно. Что бы не мучаться с выбором того или иного поведения при изменении пакета, я предлагаю использовать простой факт - меняется содержимое source tarball - меняем версию, меняется содержимое только spec и сопутствующих файлов без изменения source tarball - увеличивайте _release_.

(Ответ для Anton Farygin на комментарий #64)
> прошу прощения, корректировка:
> Изменять старые версии пакета не нужно. Что бы не мучаться с выбором того
> или иного поведения при изменении пакета, я предлагаю использовать простой
> факт - меняется содержимое source tarball - меняем версию, меняется
> содержимое только spec и сопутствующих файлов без изменения source tarball -
> увеличивайте _release_.

Спасибо
Принцип довольно строгий,
но для полной ясности у меня остается вопрос.

Если на текущий момент необходимо сделать изменения как в source tarball, так и в spec и сопутствующих файлов создавать ли промежуточные release-теги, по которым  не собираются бинарники ?

Например у меня текущий тег
1.2.3-alt2

Я добавил в source tarball файл и соответственно меняю spec

Создавать ли мне теги:
1.2.4-alt1 - добавление файла
1.2.4-alt2 - изменения spec
Ясно, что бинарные пакеты будут собираться только для 1.2.4-alt2, так как 1.2.4-alt1 нефункционален

Или достаточно создать
1.2.4-alt1 - добавление файла, изменения spec
?

1.2.4-alt1 - добавление файла, изменения spec

(Ответ для ALexey Kostarev на комментарий #62)
> (Ответ для Anton Farygin на комментарий #61)
> > Григорий, спасибо. Согласен с замечаний. Алексей, просьба исправить и этот
> > момент.
> > 
> > Традиционно, для коммитов (изменений в коде) у нас используется present
> > simple, для записей changelog past simple.
> 
> Спасибо
> Займусь

Добрый день
https://git.altlinux.org/tasks/358357/gears/500/git?p=git;a=blob;f=podsec.spec;h=b0c959b4a8793a5b38580923288889b4063c5b95;hb=HEAD#l240

Спасибо.
По спеку:
очень сложно сделан выбор файлов для упаковки, тяжело читается.
Вместо использования конструкций:
%_bindir/podsec*
%exclude %_bindir/podsec-save-oci
%exclude %_bindir/podsec-u7s-*
%exclude %_bindir/podsec-k8s-*
%exclude %_bindir/podsec-inotify-*
%_mandir/man?/podsec*
%exclude %_mandir/man?/podsec-k8s-*
%exclude %_mandir/man?/podsec-u7s-*
%exclude %_mandir/man?/podsec-save-oci*
%exclude %_mandir/man?/podsec-inotify-*

проще и правильнее (лучше читается) перечислить файлы, которые будут входить в подпакет.

Список там не очень большой и будет почти таким же по размерам как конструкции с exclude.

Идея упакетить домашний каталог с подкаталогами выглядит странно:
%dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir
%dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.local
%dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.cache
%dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.config
%dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.ssh
%dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %_localstatedir/podsec/u7s
%dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %_localstatedir/podsec/u7s/etcd
%config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.bashrc
%config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.bash_profile
%config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.bash_logout

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

(Ответ для Anton Farygin на комментарий #69)
> Идея упакетить домашний каталог с подкаталогами выглядит странно:
> %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir
> %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.local
> %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.cache
> %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.config
> %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.ssh
> %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %_localstatedir/podsec/u7s
> %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp)
> %_localstatedir/podsec/u7s/etcd
> %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp)
> %u7s_admin_homedir/.bashrc
> %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp)
> %u7s_admin_homedir/.bash_profile
> %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp)
> %u7s_admin_homedir/.bash_logout
> 
> и очень похоже на ошибку упаковки.
> По идее такие служебные домашние каталоги не должны предоставлять
> возможность пользователю в них работать.
В смысле речь идет о правах 0750 в каталогах (это права по умолчанию)
0750 в каталогах означает возможность перейти в каталог, а не право на выполнение
Если в них поставить 640, то пользователь не сможет не перейти в них, ни записывать в них файлы
Зачем они тогда нужны?

Пример:
kaf@host-87:~/tmp $ mkdir a

kaf@host-87:~/tmp$ ls -ld a
drwxr-xr-x 2 kaf kaf 4096 сен 26 14:04 a

kaf@host-87:~/tmp $ chmod 644 a
kaf@host-87:~/tmp $ ls -ld a
drw-r--r-- 2 kaf kaf 4096 сен 26 14:04 a

kaf@host-87:~/tmp $ cd a
bash: cd: a: Отказано в доступе
kaf@host-87:~/tmp $ >a/vvv
bash: a/vvv: Отказано в доступе

Или речь о другом?

(Ответ для Anton Farygin на комментарий #68)
> Спасибо.
> По спеку:
> очень сложно сделан выбор файлов для упаковки, тяжело читается.
> Вместо использования конструкций:
> %_bindir/podsec*
> %exclude %_bindir/podsec-save-oci
> %exclude %_bindir/podsec-u7s-*
> %exclude %_bindir/podsec-k8s-*
> %exclude %_bindir/podsec-inotify-*
> %_mandir/man?/podsec*
> %exclude %_mandir/man?/podsec-k8s-*
> %exclude %_mandir/man?/podsec-u7s-*
> %exclude %_mandir/man?/podsec-save-oci*
> %exclude %_mandir/man?/podsec-inotify-*
> 
> проще и правильнее (лучше читается) перечислить файлы, которые будут входить
> в подпакет.
> 
> Список там не очень большой и будет почти таким же по размерам как
> конструкции с exclude.

Ну он будет поболее и труднее в сопровождении - надо будет корректировать spec при каждом добавлении/удалении файлов 

Но раз резензент просит, то это закон :-)

Политику exclude сменю, но это потребует тестирования пакетов

+ сейчас разбираемся с коллегами с образом node-colector для trivy
Возможно это потребует добавление функционала в podsec с увеличение patch-версии

Так что новую версию podsec с исправлениями могу предоставить не ранее завтра :-(

речь о другом.
попросите своего ментора разъяснить голосом.

(Ответ для ALexey Kostarev на комментарий #70)
> (Ответ для Anton Farygin на комментарий #69)
> > Идея упакетить домашний каталог с подкаталогами выглядит странно:
> > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir
> > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.local
> > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.cache
> > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.config
> > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.ssh
> > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %_localstatedir/podsec/u7s
> > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp)
> > %_localstatedir/podsec/u7s/etcd
> > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp)
> > %u7s_admin_homedir/.bashrc
> > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp)
> > %u7s_admin_homedir/.bash_profile
> > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp)
> > %u7s_admin_homedir/.bash_logout
> > 
> > и очень похоже на ошибку упаковки.
> > По идее такие служебные домашние каталоги не должны предоставлять
> > возможность пользователю в них работать.
> В смысле речь идет о правах 0750 в каталогах (это права по умолчанию)
> 0750 в каталогах означает возможность перейти в каталог, а не право на
> выполнение
> Если в них поставить 640, то пользователь не сможет не перейти в них, ни
> записывать в них файлы
> Зачем они тогда нужны?
> 
> Пример:
> kaf@host-87:~/tmp $ mkdir a
> 
> kaf@host-87:~/tmp$ ls -ld a
> drwxr-xr-x 2 kaf kaf 4096 сен 26 14:04 a
> 
> kaf@host-87:~/tmp $ chmod 644 a
> kaf@host-87:~/tmp $ ls -ld a
> drw-r--r-- 2 kaf kaf 4096 сен 26 14:04 a
> 
> kaf@host-87:~/tmp $ cd a
> bash: cd: a: Отказано в доступе
> kaf@host-87:~/tmp $ >a/vvv
> bash: a/vvv: Отказано в доступе
> 
> Или речь о другом?

Про речь о другом - ответ на это сообщение.

(Ответ для ALexey Kostarev на комментарий #71)
> (Ответ для Anton Farygin на комментарий #68)
> > Спасибо.
> > По спеку:
> > очень сложно сделан выбор файлов для упаковки, тяжело читается.
> > Вместо использования конструкций:
> > %_bindir/podsec*
> > %exclude %_bindir/podsec-save-oci
> > %exclude %_bindir/podsec-u7s-*
> > %exclude %_bindir/podsec-k8s-*
> > %exclude %_bindir/podsec-inotify-*
> > %_mandir/man?/podsec*
> > %exclude %_mandir/man?/podsec-k8s-*
> > %exclude %_mandir/man?/podsec-u7s-*
> > %exclude %_mandir/man?/podsec-save-oci*
> > %exclude %_mandir/man?/podsec-inotify-*
> > 
> > проще и правильнее (лучше читается) перечислить файлы, которые будут входить
> > в подпакет.
> > 
> > Список там не очень большой и будет почти таким же по размерам как
> > конструкции с exclude.
> 
> Ну он будет поболее и труднее в сопровождении - надо будет корректировать
> spec при каждом добавлении/удалении файлов 
> 
> Но раз резензент просит, то это закон :-)
> 
> Политику exclude сменю, но это потребует тестирования пакетов
> 
> + сейчас разбираемся с коллегами с образом node-colector для trivy
> Возможно это потребует добавление функционала в podsec с увеличение
> patch-версии
> 
> Так что новую версию podsec с исправлениями могу предоставить не ранее
> завтра :-(

Ок.

Присылайте все изменения на review

(Ответ для Anton Farygin на комментарий #73)
> (Ответ для ALexey Kostarev на комментарий #70)
> > (Ответ для Anton Farygin на комментарий #69)
> > > Идея упакетить домашний каталог с подкаталогами выглядит странно:
> > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir
> > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.local
> > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.cache
> > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.config
> > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.ssh
> > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %_localstatedir/podsec/u7s
> > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp)
> > > %_localstatedir/podsec/u7s/etcd
> > > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp)
> > > %u7s_admin_homedir/.bashrc
> > > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp)
> > > %u7s_admin_homedir/.bash_profile
> > > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp)
> > > %u7s_admin_homedir/.bash_logout
> > > 
> > > и очень похоже на ошибку упаковки.
> > > По идее такие служебные домашние каталоги не должны предоставлять
> > > возможность пользователю в них работать.
> > В смысле речь идет о правах 0750 в каталогах (это права по умолчанию)
> > 0750 в каталогах означает возможность перейти в каталог, а не право на
> > выполнение
> > Если в них поставить 640, то пользователь не сможет не перейти в них, ни
> > записывать в них файлы
> > Зачем они тогда нужны?
> > 
> > Пример:
> > kaf@host-87:~/tmp $ mkdir a
> > 
> > kaf@host-87:~/tmp$ ls -ld a
> > drwxr-xr-x 2 kaf kaf 4096 сен 26 14:04 a
> > 
> > kaf@host-87:~/tmp $ chmod 644 a
> > kaf@host-87:~/tmp $ ls -ld a
> > drw-r--r-- 2 kaf kaf 4096 сен 26 14:04 a
> > 
> > kaf@host-87:~/tmp $ cd a
> > bash: cd: a: Отказано в доступе
> > kaf@host-87:~/tmp $ >a/vvv
> > bash: a/vvv: Отказано в доступе
> > 
> > Или речь о другом?
> 
> Про речь о другом - ответ на это сообщение.
Речь о том, что данные каталоги должны создаваться при создании пользователя в секцмм %pre
https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=blob;f=podsec.spec;h=b0c959b4a8793a5b38580923288889b4063c5b95;hb=HEAD#l146
?

Возможно Вы правы - эти изменения вносились на определенном этапе для корректной работы podsec rootless

Возможно сейчас уже не требуется...

Просмотрю функционал и %_localstatedir/podsec/u7s (/usr/libexec/ который по умолчанию не создается перенесу в секцию %pre