39627 2021-01-30 17:42:29 +0300 [4.2] join kaf@ 2025-03-13 14:54:36 +0300 1 1 4 Development Team Accounts join unspecified x86_64 Linux ASSIGNED https://www.altlinux.org/Team/Join/Secretary P5 normal --- 1 kaf glebfm arseny darktemplaralt glebfm grenka ldv mike obirvalger rider shaba cas oldest_to_newest 195883 0 9166 kaf 2021-01-30 17:42:29 +0300 Created attachment 9166 SSH-ключ Алексей Костарев E-mail: kaf@nevod.ru Ментор: Алексей Шабалин shaba@basealt.ru Направление разработок: Контейнерная виртуализация Начальные цели - приобрести опыт в сборке пакетов В частности как любитель базы ClickHouse было бы интересно собрать пакет для него До настоящего времени занимаюсь поддержкой docker-образа flexberry/clickhouse-official https://hub.docker.com/r/flexberry/clickhouse-official 195884 1 9167 kaf 2021-01-30 17:43:15 +0300 Created attachment 9167 GPG Key 195885 2 shaba 2021-01-30 18:27:22 +0300 Принял. Готовлю тестовое задание. 195908 3 glebfm 2021-02-01 15:01:00 +0300 (Ответ для Alexey Shabalin на комментарий #2) > Принял. Готовлю тестовое задание. (Ответ для ALexey Kostarev на комментарий #0) > Создано вложение 9166 [подробности] > SSH-ключ (Ответ для ALexey Kostarev на комментарий #1) > Создано вложение 9167 [подробности] > GPG Key Ok. 195966 4 shaba 2021-02-03 02:48:08 +0300 Прошу создать учетную запись на git.altlinux.org и предоставить возможность тестовой сборки на сборочном сервере. 195997 5 shaba 2021-02-03 19:16:16 +0300 Предлагаю переделать gpg ключ. Если устраивает логин kaf, то в gpg ключе укажите email kaf@altlinux.org. В описании ключа упоминать сторонний email kaf@nevod.ru совсем лишнее. Оставьте только "Alexey Kostarev". Для ключа можно добавить дополнительные email. PS: ssh ключ можно не переделывать, там комментарий не существенный, при добавлении на сервер его все равно поправят, я так думаю. 196001 6 9177 kaf 2021-02-03 21:49:35 +0300 Created attachment 9177 Новый GPG-ключ для E-mall kaf@altlinux.org 196083 7 glebfm 2021-02-08 18:24:39 +0300 ssh ключ на gitery.alt зарегистрирован. ssh ключ на gyle.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.4. 196157 8 9191 kaf 2021-02-10 18:28:27 +0300 Created attachment 9191 Новый ssh-ключ Коллеги к сожалению я запятовал свой пароль к ssh-ключу Есть ли возможность заменить открытый ключ на приложенный? 196281 9 9198 kaf 2021-02-16 16:25:14 +0300 Created attachment 9198 Подписанный новый ssh-ключ 196283 10 glebfm 2021-02-16 17:31:16 +0300 (Ответ для ALexey Kostarev на комментарий #8) > Создано вложение 9191 [подробности] > Новый ssh-ключ > > Коллеги к сожалению я запятовал свой пароль к ssh-ключу > Есть ли возможность заменить открытый ключ на приложенный? (Ответ для ALexey Kostarev на комментарий #9) > Создано вложение 9198 [подробности] > Подписанный новый ssh-ключ Да, так можно предположить, что этот ssh-ключ и gpg-ключ чуть выше сделал один и тот же человек. :) Ключи на серверах обновил, проверяйте. 196344 11 shaba 2021-02-19 01:42:17 +0300 Прошу добавить gpg ключ на сборочницу для сборки тестовых заданий. 196356 12 mike 2021-02-20 00:51:01 +0300 (Ответ для ALexey Kostarev на комментарий #0) > как любитель базы ClickHouse было бы интересно собрать пакет для него Этот? :) http://packages.altlinux.org/clickhouse 196370 13 kaf 2021-02-20 13:54:28 +0300 Да спасибо - я его уже обнаружил и попытался собрать у себя Но сходу не получилось Версия там довольно старая - 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 196371 14 kaf 2021-02-20 13:56:52 +0300 Да коллеги мой 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 196388 15 ldv 2021-02-20 17:35:39 +0300 (In reply to Alexey Shabalin from comment #11) > Прошу добавить gpg ключ на сборочницу для сборки тестовых заданий. T/J/S -> 3.0. 196722 16 glebfm 2021-03-05 14:06:01 +0300 Пакет alt-gpgkeys обновлён. T/J/S -> 3.4. 197924 17 shaba 2021-04-15 14:45:33 +0300 Кандидат уже успешно собрал пару простых заданий (обновление существующих пакетов с помощью 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 у меня претензий нет. 197933 18 andy 2021-04-15 18:28:38 +0300 (Ответ для Alexey Shabalin на комментарий #17) > - вместо %_sysconfdir/%{name}_env.conf надо использовать > %_sysconfdir/sysconfig/%name А почему не %_sysconfigdir/%name ? 197935 19 mike 2021-04-15 18:40:52 +0300 (Ответ для Alexey Shabalin на комментарий #17) > - patroni.init надо адаптировать на основе альтовых шаблонов По этой части могу попробовать содействовать в качестве со-ментора. 197941 20 kaf 2021-04-16 07:36:45 +0300 (Ответ для Andrew Vasilyev на комментарий #18) > (Ответ для Alexey Shabalin на комментарий #17) > > - вместо %_sysconfdir/%{name}_env.conf надо использовать > > %_sysconfdir/sysconfig/%name > > А почему не %_sysconfigdir/%name ? Исходя из того, что $_sysconfdir = /etc Алексей Шабалин прав %_sysconfdir/sysconfig/%name 197943 21 kaf 2021-04-16 09:51:29 +0300 (Ответ для 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-скриптов Кстати сейчас встал в тупик - а где в пакетах описываются и создаются пользователи в случае нербходимости? 197947 22 kaf 2021-04-16 11:17:31 +0300 > - вместо %_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 ? 197982 23 kaf 2021-04-18 12:44:27 +0300 (Ответ для 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 197985 24 mike 2021-04-18 19:10:47 +0300 (Ответ для 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" ;-) 198000 25 kaf 2021-04-20 09:44:13 +0300 (Ответ для 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 В итоге остановился на последнем варианте... 198001 26 kaf 2021-04-20 09:44:44 +0300 Коллеги - жду вердикта... 201751 27 shaba 2021-08-17 18:25:35 +0300 Прошу перевести на следующий уровень. Только я уже не пойму, какой это, 4.1? Мое решение - кандидат готов для вступления в team. Жду подтверждения от второго ментора. 202232 28 glebfm 2021-09-02 15:12:34 +0300 Призван ещё один человек (darktemplar@) для независимой оценки готовности кандидата. T/J/S -> 4.2. 202300 29 darktemplaralt 2021-09-03 13:49:33 +0300 Предложения и рекомендации: 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 зачем-то добавляется неиспользуемый тэг, с именем, которое конфликтует с находящимся в репозитории тэгом. 204408 30 shaba 2021-11-02 16:32:06 +0300 kaf@ исправлены ли недостатки? 235154 31 arseny 2023-10-18 18:41:16 +0300 2 года нет движения. Неужели RESOLVED/TIMEOUT? 236595 32 glebfm 2023-11-08 13:31:13 +0300 Актуально ли ещё? 238656 33 glebfm 2023-12-07 23:31:19 +0300 Переоткройте, если будет актуально. 239342 34 kaf 2023-12-20 20:34:37 +0300 Доброго времени суток коллеги Прошу прощения за остановку работ по моему 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. В случае необходимости назначить мне для получения прав майнтейнера дополнительных пакетов для портирования 239343 35 glebfm 2023-12-20 20:53:40 +0300 В данный момент все доступы отозваны, есть только email alias. Постараюсь в ближайшие дни восстановить доступ к git.alt и gyle.alt. 239543 36 glebfm 2023-12-25 19:30:10 +0300 ssh ключ на gitery.alt зарегистрирован. ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. Адрес подписан на devel@. Откатываю на стадию 3.6, мячик теперь на стороне ментора. :) 240436 37 glebfm 2024-01-22 16:35:17 +0300 ping? 240440 38 kaf 2024-01-22 16:53:58 +0300 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 Планирую на этой и ближаыйшей неделе закончить написание, отладку и документирование скрипта 240442 39 kaf 2024-01-22 17:08:13 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #37) > ping? Да URL покета podsec - https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=summary 250083 40 shaba 2024-08-15 13:46:59 +0300 Претендент готов посылать пакеты в сизиф. Прошу призвать рецензента. Для проверки кандидат подготовил сборочное задание #355139 252099 41 glebfm 2024-09-24 19:33:52 +0300 Призван рецензент (rider@) для независимой оценки готовности кандидата. T/J/S -> 4.2. 252101 42 rider 2024-09-24 19:53:44 +0300 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 разгрести. Я хотел бы посмотреть на работу над патчами. Аппрув должен буду делать в этот раз я. 252102 43 rider 2024-09-24 19:56:55 +0300 Что ещё посмотреть я не понял, но podsec меня ввёл в печаль. 252103 44 kaf 2024-09-24 21:09:31 +0300 (Ответ для 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/ 252105 45 kaf 2024-09-24 21:20:16 +0300 (Ответ для Anton Farygin на комментарий #42) > podsec: > Аппрув должен буду делать в этот раз я. Хотелось бы оперативно получить список замечений (наряду с отсутсвием точек в конце). Пакет является одним из центральных, обсуждаемым в ходе еженедельных встреч по теме "Обсуждение ИК-01 Альт СП релиз 10". При наличии новых замечаний по функционалу я буду вынужден реализовывать новые релизы и версии пакета podsec В случае долгих блокировок я буду не способен проводить их на платформу c10f2. Что может привести к задержке формирования окончательного ISO-образа для платформы c10f2. Я готов оперативно устранять замечания рецензента, но не хотелось бы получать полную блокировку выхода очередных релизов и версия для платформы c10f2. 252106 46 kaf 2024-09-24 21:57:09 +0300 (Ответ для 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 Если есть замечания к оформлению готов в фоновом режиме дорабатывать документацию 252116 47 rider 2024-09-25 07:06:43 +0300 Рецензент сам решает какую работу смотреть у кандидата. Т.к. podsec собственная разработка, то предлагаю начать с неё. первым делом предлагаю переписать весь changelog пакета, приведя его в порядок. Все места, где в changelog указаны не изменения а version-release - раскрыть и написать в changelog сделанные изменения. Как только будет готово - присылайте номер сборочного задания. 252118 48 kaf 2024-09-25 08:00:31 +0300 (Ответ для Anton Farygin на комментарий #47) > Рецензент сам решает какую работу смотреть у кандидата. > > Т.к. podsec собственная разработка, то предлагаю начать с неё. > > первым делом предлагаю переписать весь changelog пакета, приведя его в > порядок. > Все места, где в changelog указаны не изменения а version-release - раскрыть > и написать в changelog сделанные изменения. > > Как только будет готово - присылайте номер сборочного задания. OK Задача понятна 252137 49 kaf 2024-09-25 13:42:06 +0300 (Ответ для 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’а: либо начинайте, либо не начинайте их все с большой буквы; либо заканчивайте, либо не заканчивайте их точкой." речь идет об единообразии, а не об обязательности точек В моем случае точки отсутствуют, что не нарушает указанное требование Правда часть строк начинается с маленько буквы - исправлю на большие Необходимо ли в этом случае ставить точки в конце? По поводу требования оформления на английском языке В самом начале развития проекта было принято решение (так как проект внутренний) писать логи на русском языке У меня в итоге смешанный формат оформления - часть логов на англмйском языка. Основная часть на русском Допустимо ли оставить как есть? 252147 50 rider 2024-09-25 14:58:47 +0300 (Ответ для 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'ов должен быть английский. 252149 51 kaf 2024-09-25 16:12:34 +0300 (Ответ для ALexey Kostarev на комментарий #49) > (Ответ для Anton Farygin на комментарий #42) > > podsec: равда часть строк начинается с маленько буквы - исправлю на большие > По поводу требования оформления на английском языке > В самом начале развития проекта было принято решение (так как проект > внутренний) писать логи на русском языке > У меня в итоге смешанный формат оформления - часть логов на англмйском > языка. Основная часть на русском > Допустимо ли оставить как есть? Вопрос снимаю Перевожу логи на английский 252154 52 kaf 2024-09-25 17:15:57 +0300 (Ответ для 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? Коллеги говорят, что в выходные была аналогичная ситуация Так что запустить задачу на сборку пока не могу :-( Буду ждать оживления сервисов 252158 53 kaf 2024-09-25 18:00:12 +0300 > Буду ждать оживления сервисов Сервисы заработали Старый task к сожалению уже удален Создал новый task https://git.altlinux.org/tasks/358357/ 252159 54 rider 2024-09-25 18:57:40 +0300 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 Точек нет. 252160 55 rider 2024-09-25 18:59:20 +0300 Ещё правило хорошего тона, которое постоянно нарушается в этом пакете: принято если изменение идёт только в спек-файле, то делать новый release. если изменение в коде, меняющее функционал - то выпускать новую версию (увеличивая version). 252163 56 kaf 2024-09-25 19:56:15 +0300 (Ответ для 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 В конце каждого пункта (- ...) и подпункта (+ ...) Или что то другое имеется в виду 252164 57 kaf 2024-09-25 19:59:40 +0300 (Ответ для 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-ч - нет :-) Меня извиняет только то, что последние комментарии добавлял в конце рабочего дня Переработаю 252165 58 kaf 2024-09-25 20:10:29 +0300 (Ответ для Anton Farygin на комментарий #55) > Ещё правило хорошего тона, которое постоянно нарушается в этом пакете: > принято если изменение идёт только в спек-файле, то делать новый release. > если изменение в коде, меняющее функционал - то выпускать новую версию > (увеличивая version). Да - этот пункт я для мне объяснили, только несколько месяцев назад Хотя в другой редакции Если меняется функционал - увеличивается версия, если все остальное, то release То есть правки ошибок, создание и добавление документов и т.п. вроде как не меняют функционал. Поэтому я в этом случае увеличивал release Это правильно? По увеличению версии тоже вопросы - когда менять патч, минор и мажор версии? Тут хоть правила и есть, то границы довольно расплывчаты В любом случае я не представляю как сейчас переработать структуру истории тегов Часть тегов уже попала в ссылки сторонних документов и перемещать и менятьь их уже чревато Хотя в дальнейшем развитии постараюсь придерживаться этого правила с учетом замечаний по вопросу выше (входит ли исправление ошибок и доьавление документации в правило увеличения Release или Version) 252168 59 kaf 2024-09-25 22:08:28 +0300 (Ответ для 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 252169 60 grenka 2024-09-25 22:37:12 +0300 Я позволю себе влезть в процесс и напомнить Вам и рецензенту, что тексты изменений, будь то в ченджлоге, будь то в коммитах хорошо бы оформлять в единой временной форме. 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 Читать такой ченджлог как минимум неприятно, а быстро найти глазами интересующий момент ещё и сложно. Править это всё или нет решайте с рецензентом, но как минимум в будущем неплохо было бы определить единый стиль. 252172 61 rider 2024-09-26 07:16:46 +0300 Григорий, спасибо. Согласен с замечаний. Алексей, просьба исправить и этот момент. Традиционно, для коммитов (изменений в коде) у нас используется present simple, для записей changelog past simple. 252173 62 kaf 2024-09-26 07:19:22 +0300 (Ответ для Anton Farygin на комментарий #61) > Григорий, спасибо. Согласен с замечаний. Алексей, просьба исправить и этот > момент. > > Традиционно, для коммитов (изменений в коде) у нас используется present > simple, для записей changelog past simple. Спасибо Займусь 252174 63 rider 2024-09-26 07:20:21 +0300 (Ответ для ALexey Kostarev на комментарий #58) > (Ответ для Anton Farygin на комментарий #55) > > Ещё правило хорошего тона, которое постоянно нарушается в этом пакете: > > принято если изменение идёт только в спек-файле, то делать новый release. > > если изменение в коде, меняющее функционал - то выпускать новую версию > > (увеличивая version). > > Да - этот пункт я для мне объяснили, только несколько месяцев назад > Хотя в другой редакции > > Если меняется функционал - увеличивается версия, если все остальное, то > release > > То есть правки ошибок, создание и добавление документов и т.п. вроде как не > меняют функционал. Поэтому я в этом случае увеличивал release > Это правильно? > > По увеличению версии тоже вопросы - когда менять патч, минор и мажор версии? > Тут хоть правила и есть, то границы довольно расплывчаты > > В любом случае я не представляю как сейчас переработать структуру истории > тегов > Часть тегов уже попала в ссылки сторонних документов и перемещать и менятьь > их уже чревато > > Хотя в дальнейшем развитии постараюсь придерживаться этого правила с учетом > замечаний по вопросу выше (входит ли исправление ошибок и доьавление > документации в правило увеличения Release или Version) Изменять старые версии пакета не нужно. Что бы не мучаться с выбором того или иного поведения при изменении пакета, я предлагаю использовать простой факт - меняется содержимое source tarball - меняем версию, меняется содержимое только spec и сопутствующих файлов без изменения source tarball - увеличивайте версию. 252175 64 rider 2024-09-26 07:21:43 +0300 прошу прощения, корректировка: Изменять старые версии пакета не нужно. Что бы не мучаться с выбором того или иного поведения при изменении пакета, я предлагаю использовать простой факт - меняется содержимое source tarball - меняем версию, меняется содержимое только spec и сопутствующих файлов без изменения source tarball - увеличивайте _release_. 252179 65 kaf 2024-09-26 08:19:02 +0300 (Ответ для 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 ? 252180 66 rider 2024-09-26 08:20:02 +0300 1.2.4-alt1 - добавление файла, изменения spec 252198 67 kaf 2024-09-26 11:16:42 +0300 (Ответ для 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 252199 68 rider 2024-09-26 11:38:18 +0300 Спасибо. По спеку: очень сложно сделан выбор файлов для упаковки, тяжело читается. Вместо использования конструкций: %_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. 252200 69 rider 2024-09-26 11:39:10 +0300 Идея упакетить домашний каталог с подкаталогами выглядит странно: %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 и очень похоже на ошибку упаковки. По идее такие служебные домашние каталоги не должны предоставлять возможность пользователю в них работать. 252202 70 kaf 2024-09-26 12:12:06 +0300 (Ответ для 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: Отказано в доступе Или речь о другом? 252205 71 kaf 2024-09-26 12:18:17 +0300 (Ответ для 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 с исправлениями могу предоставить не ранее завтра :-( 252206 72 rider 2024-09-26 12:18:49 +0300 речь о другом. попросите своего ментора разъяснить голосом. 252207 73 rider 2024-09-26 12:19:45 +0300 (Ответ для 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: Отказано в доступе > > Или речь о другом? Про речь о другом - ответ на это сообщение. 252208 74 rider 2024-09-26 12:20:29 +0300 (Ответ для 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 252211 75 kaf 2024-09-26 12:32:20 +0300 (Ответ для 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 252336 76 kaf 2024-09-30 14:17:30 +0300 (Ответ для 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 > > и очень похоже на ошибку упаковки. > По идее такие служебные домашние каталоги не должны предоставлять > возможность пользователю в них работать. Добрый день Замечания исправил https://git.altlinux.org/tasks/358357/ 252337 77 rider 2024-09-30 14:31:58 +0300 https://git.altlinux.org/tasks/358357/logs/events.6.1.log В логах очень много unowned files 252347 78 kaf 2024-09-30 17:13:56 +0300 (Ответ для Anton Farygin на комментарий #77) > https://git.altlinux.org/tasks/358357/logs/events.6.1.log > > В логах очень много unowned files Добавил описание каталогов https://git.altlinux.org/tasks/358357/logs/events.11.1.log Каталоги /usr/libexec/podsec/u7s /var/lib/u7s-admin /var/lib/u7s-admin/.bashrc /var/lib/u7s-admin/.cache /var/lib/u7s-admin/.local /var/lib/u7s-admin/.local/share /var/lib/u7s-admin/.local/share/usernetes /var/lib/u7s-admin/.local/share/usernetes/containers так как это подкаталоги домашнего каталога системного пользователя u7s-admin и они создаются на этапе %pre k8s Если добавлю, то снова получу от Вас замечание описанное выше 252369 79 rider 2024-10-01 10:04:55 +0300 Не должно быть файлов из skel для пользователя сервиса. Зачем они нужны ? И ещё - в логе про unowned files есть фа https://packages.altlinux.org/ru/sisyphus/binary/nagwad-service/noarch/files/3120979963681020020 252370 80 rider 2024-10-01 10:05:25 +0300 Каталог /var/lib/u7s-admin должен принадлежать какому-то пакету. 252372 81 kaf 2024-10-01 10:26:22 +0300 (Ответ для Anton Farygin на комментарий #79) > Не должно быть файлов из skel для пользователя сервиса. Зачем они нужны ? > https://packages.altlinux.org/ru/sisyphus/binary/nagwad-service/noarch/files/ > 3120979963681020020 При добавлении системного пользователя (в отличии от обычного) не используется skel, а мне нужны файлы - .bash_profile - .bashrc Если точнее мне нужно доопределить переменную PATH: export PATH=/usr/libexec/podsec/u7s/bin/:$PATH Обычно это делается в .bashrc А для его вызова требуется .bash_profile Я конечно могу их скопировать в пакет Это было сделано до этого и что Вам не понравилось: > и очень похоже на ошибку упаковки. > По идее такие служебные домашние каталоги не должны предоставлять > возможность пользователю в них работать. Так что единственным выходом в условиях в которые меян поставили было использование /etc/skel 252375 82 kaf 2024-10-01 10:32:35 +0300 (Ответ для Anton Farygin на комментарий #80) > Каталог /var/lib/u7s-admin должен принадлежать какому-то пакету. Он принадлежал пакету podsec-k8s, но попал в список каталогов, https://bugzilla.altlinux.org/show_bug.cgi?id=39627#c69 > Идея упакетить домашний каталог с подкаталогами выглядит странно: > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir > ... Можно как то более точно определить замечание #c69 Иначе я вижу противоречие между двумя замечаниями 252377 83 rider 2024-10-01 10:39:40 +0300 (Ответ для ALexey Kostarev на комментарий #81) > (Ответ для Anton Farygin на комментарий #79) > > Не должно быть файлов из skel для пользователя сервиса. Зачем они нужны ? > > https://packages.altlinux.org/ru/sisyphus/binary/nagwad-service/noarch/files/ > > 3120979963681020020 > > При добавлении системного пользователя (в отличии от обычного) не > используется skel, а мне нужны файлы > - .bash_profile > - .bashrc > > Если точнее мне нужно доопределить переменную PATH: > export PATH=/usr/libexec/podsec/u7s/bin/:$PATH > > Обычно это делается в .bashrc > А для его вызова требуется > .bash_profile > > Я конечно могу их скопировать в пакет > Это было сделано до этого и что Вам не понравилось: > > и очень похоже на ошибку упаковки. > > По идее такие служебные домашние каталоги не должны предоставлять > > возможность пользователю в них работать. > > Так что единственным выходом в условиях в которые меян поставили было > использование /etc/skel Ну зачем же так сложно. путь к скриптам можно переопределить в самих скриптах, а не в домашнем каталоге. сделать что-то вроде functions, в котором будет переопределяться путь и этот functions инклюдить в каждом скрипте. 252378 84 rider 2024-10-01 10:40:40 +0300 (Ответ для ALexey Kostarev на комментарий #82) > (Ответ для Anton Farygin на комментарий #80) > > Каталог /var/lib/u7s-admin должен принадлежать какому-то пакету. > > Он принадлежал пакету podsec-k8s, но попал в список каталогов, > https://bugzilla.altlinux.org/show_bug.cgi?id=39627#c69 > > Идея упакетить домашний каталог с подкаталогами выглядит странно: > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir > > ... > Можно как то более точно определить замечание #c69 > Иначе я вижу противоречие между двумя замечаниями Сам домашний каталог должен быть упакечен с нужными правами, но пустой. Не надо его создавать вместе с пользователем. 252379 85 kaf 2024-10-01 10:43:19 +0300 (Ответ для Anton Farygin на комментарий #79) > И ещё - в логе про unowned files есть фа > https://packages.altlinux.org/ru/sisyphus/binary/nagwad-service/noarch/files/ > 3120979963681020020 Можно уточнить о каком именно файле идет речь (в тексте не закрнчено)? В логах https://git.altlinux.org/tasks/358357/logs/events.11.1.log я не вижу имени файла из пакета nagwad-service И вроде это как не мой пакет Мои из области протоколирования логов: - podsec-nagios - podsec-icings 252380 86 rider 2024-10-01 10:45:06 +0300 (Ответ для ALexey Kostarev на комментарий #85) > (Ответ для Anton Farygin на комментарий #79) > > И ещё - в логе про unowned files есть фа > > https://packages.altlinux.org/ru/sisyphus/binary/nagwad-service/noarch/files/ > > 3120979963681020020 > > Можно уточнить о каком именно файле идет речь (в тексте не закрнчено)? > В логах https://git.altlinux.org/tasks/358357/logs/events.11.1.log > я не вижу имени файла из пакета nagwad-service > И вроде это как не мой пакет > > Мои из области протоколирования логов: > - podsec-nagios > - podsec-icings x86_64: podsec=1.1.8-alt2 post-install unowned files: /etc/nagwad возможно просто не хватает какой-то зависимости 252389 87 kaf 2024-10-01 11:14:32 +0300 (Ответ для Anton Farygin на комментарий #83) > (Ответ для ALexey Kostarev на комментарий #81) > > (Ответ для Anton Farygin на комментарий #79) > > > Не должно быть файлов из skel для пользователя сервиса. Зачем они нужны ? > > > https://packages.altlinux.org/ru/sisyphus/binary/nagwad-service/noarch/files/ > > > 3120979963681020020 > > > > При добавлении системного пользователя (в отличии от обычного) не > > используется skel, а мне нужны файлы > > - .bash_profile > > - .bashrc > > > > Если точнее мне нужно доопределить переменную PATH: > > export PATH=/usr/libexec/podsec/u7s/bin/:$PATH > > > > Обычно это делается в .bashrc > > А для его вызова требуется > > .bash_profile > > > > Я конечно могу их скопировать в пакет > > Это было сделано до этого и что Вам не понравилось: > > > и очень похоже на ошибку упаковки. > > > По идее такие служебные домашние каталоги не должны предоставлять > > > возможность пользователю в них работать. > > > > Так что единственным выходом в условиях в которые меян поставили было > > использование /etc/skel > > Ну зачем же так сложно. путь к скриптам можно переопределить в самих > скриптах, а не в домашнем каталоге. > > сделать что-то вроде functions, в котором будет переопределяться путь и этот > functions инклюдить в каждом скрипте. И это Вы называете просто? Вместо того, чтобы определить переменную PATH при запуске любого скрипта из под пользователя u7s-admin определять эту переменную в десятке скриптов https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=tree;f=usernetes/bin;h=7621bc56acfab9c3fa6606a8ad9d44a82ea8d1c0;hb=HEAD ? + отлаживать ситуации когда переменная PATH корректно не определяется У нас с Вами разные представления о сложности :-) > По идее такие служебные домашние каталоги не должны предоставлять возможность пользователю в них работать. Обычному пользователю да - не должны Но администратору kubernetes (ну и разработчику и тестеру) вроде как сильно не помещают Часто возникает при отладке и эксплуатации необходимость выполнить команду в namespace окружении пользователя u7s-admin: # machinectl shell u7s-admin@ $ nsenter_u7s # <команды в namespace-окружении>: iptables ..., ip ..., crictl, ... # less <файл> # просмотр файлов логов и т.пю которые видны ТОЛЬКО в namespace-окружении Я как бывший (и текущий) администратор считаю некорректным каждый раз еще добавлять в этот сложный процесс еще и переопределение переменной PATH перед запуском команды nsenter_u7s 252392 88 rider 2024-10-01 11:37:42 +0300 из 20 тысяч пакетов bashrc присутствует в совсем небольшом количестве: https://packages.altlinux.org/ru/sisyphus/files/?q=.bashrc и сразу в двух пакетах это ошибка. да, архитектура приложения не должна полагаться на PATH в окружении, а системный пользователь не предназначен для рядовой работы под ним. 252399 89 kaf 2024-10-01 14:43:09 +0300 (Ответ для Anton Farygin на комментарий #88) > из 20 тысяч пакетов bashrc присутствует в совсем небольшом количестве: > https://packages.altlinux.org/ru/sisyphus/files/?q=.bashrc > > и сразу в двух пакетах это ошибка. > > > > да, архитектура приложения не должна полагаться на PATH в окружении, а > системный пользователь не предназначен для рядовой работы под ним. Я про рядовую работу не говорю Я говорю про работу администратора kubernetes в нестандартных ситуациях Это как я понимаю из неписанных правил. Ждал от Вас замечания, что в /etc/password должен быть /bin/false в качестве интепретатора Ожидать в дальнейшем или указание /bin/bash в системных пользователя допустимо? Данные предложения приведут к: - серъезной переработке кода - отладке на моей стадии - поиск регрессий на стадии тестирования - обсуждения и добавления механизма для администратора kubernetes заходить в namespace пользователя u7s-admin - доработке документации для администратора kubernetes - смене минорной версии пакета на podsec 1.2 Я не против этих изменений, но сейчас коллеги по сертификации платформы c10f2 ждут от меня изменений по обнаруженным в рамках тестирования недоработкам для podsec этой платформы. Так как при описанных доработках срок реализации этих изменений и прохождения полного тестирования на регресии составит 1-2 недели я буду вынужден сегодня в 16:00 MSK на обсуждении в рамках "Обсуждение ИК-01 Альт СП релиз 10" обрисовать эту ситуацию. Как альтернативу предлагаю все таки пропустить текущий релиз (в доработками unowners files) в sisyphus, а "пропускать" меня на дальнейшую стадию join после реализации podsec-1.2.x Обсудить можно с Игорем Корчагиным, Владимиром Черным, Денисом Медведевым, ... А делать то что? 252400 90 kaf 2024-10-01 14:44:24 +0300 (Ответ для ALexey Kostarev на комментарий #89) > (Ответ для Anton Farygin на комментарий #88) > > из 20 тысяч пакетов bashrc присутствует в совсем небольшом количестве: > > https://packages.altlinux.org/ru/sisyphus/files/?q=.bashrc > > > > и сразу в двух пакетах это ошибка. > > > > > > > > да, архитектура приложения не должна полагаться на PATH в окружении, а > > системный пользователь не предназначен для рядовой работы под ним. > > Я про рядовую работу не говорю > > Я говорю про работу администратора kubernetes в нестандартных ситуациях > > Это как я понимаю из неписанных правил. > Ждал от Вас замечания, что в /etc/password должен быть /bin/false в качестве > интепретатора > Ожидать в дальнейшем или указание /bin/bash в системных пользователя > допустимо? > > Данные предложения приведут к: > - серъезной переработке кода > - отладке на моей стадии > - поиск регрессий на стадии тестирования > - обсуждения и добавления механизма для администратора kubernetes заходить в > namespace пользователя u7s-admin > - доработке документации для администратора kubernetes > - смене минорной версии пакета на podsec 1.2 > > Я не против этих изменений, но сейчас коллеги по сертификации платформы > c10f2 ждут от меня изменений по обнаруженным в рамках тестирования > недоработкам для podsec этой платформы. > > Так как при описанных доработках срок реализации этих изменений и > прохождения полного тестирования на регресии составит 1-2 недели я буду > вынужден сегодня в 16:00 MSK на обсуждении в рамках "Обсуждение ИК-01 Альт > СП релиз 10" обрисовать эту ситуацию. > > Как альтернативу предлагаю все таки пропустить текущий релиз (в доработками > unowners files) в sisyphus, а "пропускать" меня на дальнейшую стадию join > после реализации podsec-1.2.x > > Обсудить можно с Игорем Корчагиным, Владимиром Черным, Денисом Медведевым, > ... > > > > А делать то что? Последняя фраза вне контекста Игнорируйте :-) 252405 91 kaf 2024-10-01 15:39:32 +0300 > x86_64: podsec=1.1.8-alt2 post-install unowned files: > /etc/nagwad > > > возможно просто не хватает какой-то зависимости Я почему то не могу найти этой строки в log'ах Но описания каталога действительно нет в spec Добавил В логах (снова :-)) не вижу https://git.altlinux.org/tasks/358357/logs/events.12.1.log 252408 92 rider 2024-10-01 15:59:19 +0300 (Ответ для ALexey Kostarev на комментарий #91) > > x86_64: podsec=1.1.8-alt2 post-install unowned files: > > /etc/nagwad > > > > > > возможно просто не хватает какой-то зависимости > > Я почему то не могу найти этой строки в log'ах > > Но описания каталога действительно нет в spec > > Добавил Это не правильно. На мой взгляд должна была быть зависимость на пакет, в котором живёт этот каталог. 252409 93 kaf 2024-10-01 16:01:15 +0300 (Ответ для Anton Farygin на комментарий #92) > (Ответ для ALexey Kostarev на комментарий #91) > > > x86_64: podsec=1.1.8-alt2 post-install unowned files: > > > /etc/nagwad > > > > > > > > > возможно просто не хватает какой-то зависимости > > > > Я почему то не могу найти этой строки в log'ах > > > > Но описания каталога действительно нет в spec > > > > Добавил > > Это не правильно. > > На мой взгляд должна была быть зависимость на пакет, в котором живёт этот > каталог. OK Возможно Обсужу в @manowar Он занимался этой частью пакета 252411 94 rider 2024-10-01 16:04:41 +0300 (Ответ для ALexey Kostarev на комментарий #89) > Так как при описанных доработках срок реализации этих изменений и > прохождения полного тестирования на регресии составит 1-2 недели я буду > вынужден сегодня в 16:00 MSK на обсуждении в рамках "Обсуждение ИК-01 Альт > СП релиз 10" обрисовать эту ситуацию. > > Как альтернативу предлагаю все таки пропустить текущий релиз (в доработками > unowners files) в sisyphus, а "пропускать" меня на дальнейшую стадию join > после реализации podsec-1.2.x > > Обсудить можно с Игорем Корчагиным, Владимиром Черным, Денисом Медведевым, Алексей, мы здесь про JOIN в ALT Linux Team. JOIN ничего не знает про ваши сложности с СП релиз 10, Чёрного, Корчагина и остальных коллег. для того, что бы задание в Sisyphus не держало ваши задачи по c10f2, я удаляю пакет podsec из Sisyphus и теперь в репозиторий c10f2 можно отправлять задания не дожидаясь их прохождения в Sisyphus. Но это не убирает необходимости в рамках JOIN поднять качество пакету. 252418 95 kaf 2024-10-01 21:27:32 +0300 (Ответ для Anton Farygin на комментарий #94) > (Ответ для ALexey Kostarev на комментарий #89) > > > Так как при описанных доработках срок реализации этих изменений и > > прохождения полного тестирования на регресии составит 1-2 недели я буду > > вынужден сегодня в 16:00 MSK на обсуждении в рамках "Обсуждение ИК-01 Альт > > СП релиз 10" обрисовать эту ситуацию. > > > > Как альтернативу предлагаю все таки пропустить текущий релиз (в доработками > > unowners files) в sisyphus, а "пропускать" меня на дальнейшую стадию join > > после реализации podsec-1.2.x > > > > Обсудить можно с Игорем Корчагиным, Владимиром Черным, Денисом Медведевым, > > Алексей, мы здесь про JOIN в ALT Linux Team. > JOIN ничего не знает про ваши сложности с СП релиз 10, Чёрного, Корчагина и > остальных коллег. > > для того, что бы задание в Sisyphus не держало ваши задачи по c10f2, я > удаляю пакет podsec из Sisyphus и теперь в репозиторий c10f2 можно > отправлять задания не дожидаясь их прохождения в Sisyphus. > > Но это не убирает необходимости в рамках JOIN поднять качество пакету. Да конечно Спасибо, за вышеприведенные замечания и то, что вошли в текущую ситуацию... Я, как Вы рекомендовали, проконсультируюсь по оставшимся разногласиями у своего менторы Алексей Шабалина Думаю по итогам обсуждения продолжим движение дальше в рамках этой задачи 252507 96 kaf 2024-10-03 22:37:29 +0300 (Ответ для Anton Farygin на комментарий #94) > (Ответ для ALexey Kostarev на комментарий #89) > > > Так как при описанных доработках срок реализации этих изменений и > > прохождения полного тестирования на регресии составит 1-2 недели я буду > > вынужден сегодня в 16:00 MSK на обсуждении в рамках "Обсуждение ИК-01 Альт > > СП релиз 10" обрисовать эту ситуацию. > > > > Как альтернативу предлагаю все таки пропустить текущий релиз (в доработками > > unowners files) в sisyphus, а "пропускать" меня на дальнейшую стадию join > > после реализации podsec-1.2.x > > > > Обсудить можно с Игорем Корчагиным, Владимиром Черным, Денисом Медведевым, > > Алексей, мы здесь про JOIN в ALT Linux Team. > JOIN ничего не знает про ваши сложности с СП релиз 10, Чёрного, Корчагина и > остальных коллег. > > для того, что бы задание в Sisyphus не держало ваши задачи по c10f2, я > удаляю пакет podsec из Sisyphus и теперь в репозиторий c10f2 можно > отправлять задания не дожидаясь их прохождения в Sisyphus. > > Но это не убирает необходимости в рамках JOIN поднять качество пакету. Доброго времени суток podsec-пакеты прошли тестирование в c10f2. Спасибо Сформировал 1.1.8-alt4: - переопределение переменной PATH перенесено из .bashrc в функцию podsec-u7s-function - флаг -m (создать домашний каталог) в useradd заменен на -M (не создавать) - кроме домашнего каталога ~u7s-admin в пакет podsec-k8s включены подкаталоги .local, .local/share, .local/share/usernetes. .local/share/usernetes/containers. Это связано с необходимостью объединения каталогов контейнеров и образов обычного и namespaced окружения пользователя u7s-admin. Это обеспечивает корректную работу команды trivy для анализа уязвимостей в контейнерах и образах в пакете podsec-inotify Логи сборки образа https://git.altlinux.org/tasks/358357/logs/events.18.1.log 252526 97 rider 2024-10-04 15:42:48 +0300 Алексей, я настоятельно рекомендую придерживаться выпуска новой версии при изменении исходного кода проекта. Т.е. - здесь явно напрашивается 1.1.9-alt1 (в последнем коммите) 252527 98 rider 2024-10-04 15:44:42 +0300 Права 0755 для домашнего каталога выглядят несекьюрно: %dir %attr(0755,%u7s_admin_usr,%u7s_admin_grp) %_localstatedir/podsec/u7s %dir %attr(0755,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir 252529 99 kaf 2024-10-04 17:14:12 +0300 (Ответ для Anton Farygin на комментарий #97) > Алексей, я настоятельно рекомендую придерживаться выпуска новой версии при > изменении исходного кода проекта. > > Т.е. - здесь явно напрашивается 1.1.9-alt1 (в последнем коммите) Инерция привычки :-( Пока бросает в крайности Я и точки в комитах то пока с трудом ставлю со второго раза :-) Исправлюсь 252565 100 kaf 2024-10-07 10:35:13 +0300 (Ответ для ALexey Kostarev на комментарий #99) > (Ответ для Anton Farygin на комментарий #97) > > Алексей, я настоятельно рекомендую придерживаться выпуска новой версии при > > изменении исходного кода проекта. > > > > Т.е. - здесь явно напрашивается 1.1.9-alt1 (в последнем коммите) > > Инерция привычки :-( > Пока бросает в крайности > Я и точки в комитах то пока с трудом ставлю со второго раза :-) > Исправлюсь Добрый день! https://git.altlinux.org/tasks/358357/: - изменил историю на версию 1.1.9-alt1 - изменил права доступа ~u7s-admin/.local/ с 0755 на 0700 - для скриптов, запускаемых под пользователем u7s-admin сменил владельца на u7s-admin и права доступа на 0700 - проверил разворачивание - версия рабочая 252567 101 rider 2024-10-07 11:12:10 +0300 В specfile осталось ещё много, очень много каталогов с правами 0755 Вероятно этот список надо посмотреть весь и там, где не нужны такие права - сделать их более ограниченными по умолчанию. 252593 102 kaf 2024-10-07 14:01:39 +0300 (Ответ для Anton Farygin на комментарий #101) > В specfile осталось ещё много, очень много каталогов с правами 0755 > Вероятно этот список надо посмотреть весь и там, где не нужны такие права - > сделать их более ограниченными по умолчанию. OK Посмотрю Возможно для части каталогов и файлов стоит поменять и владельца с root на u7s-admin У меня на очереди в sisyphus еще висят 8 пакетов flux2 https://packages.altlinux.org/en/tasks/355139/ Для 6-ти из них надо создавать docker-образы. Но пока они не попадут в sisyphus собрать образы нет возможности Какова дальнейшая судьба этих пакетов? 252598 103 rider 2024-10-07 14:23:47 +0300 (Ответ для ALexey Kostarev на комментарий #102) > (Ответ для Anton Farygin на комментарий #101) > > В specfile осталось ещё много, очень много каталогов с правами 0755 > > Вероятно этот список надо посмотреть весь и там, где не нужны такие права - > > сделать их более ограниченными по умолчанию. > > OK > Посмотрю > Возможно для части каталогов и файлов стоит поменять и владельца с root на > u7s-admin > > У меня на очереди в sisyphus еще висят 8 пакетов flux2 > https://packages.altlinux.org/en/tasks/355139/ > > Для 6-ти из них надо создавать docker-образы. > Но пока они не попадут в sisyphus собрать образы нет возможности > > Какова дальнейшая судьба этих пакетов? Я не хотел бы в bugzilla смешивать и предлагаю сначала довести до завершения однй задачу. Я отвечаю быстро. И если оперативно и качественно, не делая новых ошибок, вносить исправления - это всё можно закончить за день. 252605 104 kaf 2024-10-07 15:34:47 +0300 (Ответ для Anton Farygin на комментарий #103) > (Ответ для ALexey Kostarev на комментарий #102) > > (Ответ для Anton Farygin на комментарий #101) > > > В specfile осталось ещё много, очень много каталогов с правами 0755 > > > Вероятно этот список надо посмотреть весь и там, где не нужны такие права - > > > сделать их более ограниченными по умолчанию. > > > > OK > > Посмотрю > > Возможно для части каталогов и файлов стоит поменять и владельца с root на > > u7s-admin > > > > У меня на очереди в sisyphus еще висят 8 пакетов flux2 > > https://packages.altlinux.org/en/tasks/355139/ > > > > Для 6-ти из них надо создавать docker-образы. > > Но пока они не попадут в sisyphus собрать образы нет возможности > > > > Какова дальнейшая судьба этих пакетов? > > Я не хотел бы в bugzilla смешивать и предлагаю сначала довести до завершения > однй задачу. > > Я отвечаю быстро. И если оперативно и качественно, не делая новых ошибок, > вносить исправления - это всё можно закончить за день. OK Я просто пока мгновенно реагировать не могу - отвлекают работы по c10f2 Но постараюсь оперативно реагировать на замечания. 252665 105 kaf 2024-10-07 22:25:39 +0300 (Ответ для Anton Farygin на комментарий #103) > (Ответ для ALexey Kostarev на комментарий #102) > > (Ответ для Anton Farygin на комментарий #101) > > > В specfile осталось ещё много, очень много каталогов с правами 0755 > > > Вероятно этот список надо посмотреть весь и там, где не нужны такие права - > > > сделать их более ограниченными по умолчанию. > > > > OK > > Посмотрю > > Возможно для части каталогов и файлов стоит поменять и владельца с root на > > u7s-admin > > > > У меня на очереди в sisyphus еще висят 8 пакетов flux2 > > https://packages.altlinux.org/en/tasks/355139/ > > > > Для 6-ти из них надо создавать docker-образы. > > Но пока они не попадут в sisyphus собрать образы нет возможности > > > > Какова дальнейшая судьба этих пакетов? > > Я не хотел бы в bugzilla смешивать и предлагаю сначала довести до завершения > однй задачу. > > Я отвечаю быстро. И если оперативно и качественно, не делая новых ошибок, > вносить исправления - это всё можно закончить за день. Уточнил владельцев и права доступа для скриптов выполняемых при разворачивании rootless kubernetes узла, располагаемых в каталоге /usr/libexec/podsec/u7s/bin/ В свое время выбрал этот каталог, как рекомендуемый. Но не вчитался в детали. Его необходимо добавлять в тропу PATH Сейчас обратил внимание но то, что для выполняемых файлов пользователя есть каталог $HOME/bin. ПРичем он автоматически добавляется в /etc/profiles при выполнении скриптов под пользователей u7s-admin Может стоит перенести выполняемые скрипты из /usr/libexec/podsec/u7s/bin/ в ~u7s-admin/bin ? В этом случае и необходимость модификации PATH отпадает при разворачивании rootless kuber (podsec-k8s). 252672 106 rider 2024-10-08 07:41:39 +0300 точно не стоит. FHS придумали как раз для того, что бы таких идей не возникало. 252674 107 kaf 2024-10-08 08:40:47 +0300 (Ответ для Anton Farygin на комментарий #106) > точно не стоит. FHS придумали как раз для того, что бы таких идей не > возникало. Меня как раз и смутило 1. Внимаетельное прочтение FHS-документа: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html /usr/libexec includes internal binaries that are not intended to be EXECUTED DIRECTLY by users or shell scripts. В нашем случае часть скриптов из /usr/libexec/podsec/bin вызываются непосредственно из окружения пользователя при разворачивании rootless-kubernetes по схемам в скобках пользователи: /usr/libexec/podsec/bin/kubeadm (root) -> /usr/libexec/podsec/bin/kubeadm.sh (u7s-admin) -> системная_команда_или_podsec-скрипт /usr/libexec/podsec/bin/kubeadm (root) -> /usr/libexec/podsec/bin/kubeadm.sh (u7s-admin) -> nsenter (переход в namespace u7s-admin с правами превдо-root) -> системная_команда_или_podsec-скрипт (превдо-root пользователя u7s-admin) shell (u7s-admin) -> системная_команда_или_podsec-скрипт (u7s-admin) shell (u7s-admin) -> nsenter (переход в namespace u7s-admin с правами превдо-root) -> системная_команда_или_podsec-скрипт (превдо-root пользователя u7s-admin) То есть часть скриптов вызывается НЕПОСРЕДСТВЕННО ПОЛЬЗОВАТЕДЕМ u7s-admin 2. $HOME/bin хоть и не сходит в FHS, но в RPM-дистрибутивах (в которым вроде как принажлежит дистрибутив ALTLinux) является практически стандартом де-факто и автоматически добавляется в тропе HOME в начало в /etc/profile: https://unix.stackexchange.com/questions/507829/what-binaries-are-stored-in-home-username-bin However, having /home/username/bin/ is something you can encounter on RPM-based distributions, such as Fedora, Red Hat Entreprise Linux or Suse. Именно эти соображения и сподвигли меня оформить это предложение PS Может для оперативного решения части вопросов и дискуссии использовать telegram? 252675 108 rider 2024-10-08 08:48:53 +0300 Лучше обсудить этот вопрос с ментором (Алексеем Шабалиным). 252682 109 grenka 2024-10-08 09:23:51 +0300 (Ответ для ALexey Kostarev на комментарий #107) > Может для оперативного решения части вопросов и дискуссии использовать > telegram? По-моему, оперативнее, чем отвечает rider@ уже некуда. Мне вот интересно понаблюдать за вашим джойном. Мне интересно и как ментору некоторых кандидатов и как уже состоявшемуся мейнтейнеру. Возможно кто-то ещё наблюдает:) 252700 110 kaf 2024-10-08 15:58:19 +0300 (Ответ для Anton Farygin на комментарий #101) > В specfile осталось ещё много, очень много каталогов с правами 0755 > Вероятно этот список надо посмотреть весь и там, где не нужны такие права - > сделать их более ограниченными по умолчанию. Добрый вечер Поправил и доьавил права и владельцев файлов и каталогов https://git.altlinux.org/tasks/358357/logs/events.19.1.log Большинству файлов и каталогов установил владельца и группу u7s-admin, с правами 0700 для каталогов и 0600 для файлов, так как они используются при запуске rootless-kubernetes при работа в среде пользователя u7s-admin. Часть скриптов запускаются при работа непосредственно в пользователе u7s-admin. Часть в его namespace от имени предво-root, который в HOST_системе имеет права пользователя u7s-admin Для файлов и каталогов пользователя u7s-admin права выставил 0700 для каталогов и скриптов, 0600 для обычных файлов и файлов конфигураций Сторонний пользователеь в этом случае их не прочтет, не изменит и не выполнит А пользователь root в любом случае имеет права аналогичные пользователю u7s-admin Для скриптов, запускаемых только под root (/usr/bin/podsec-u7s-kubeadm) выставил права 0700 с владельцем root Для скриптов, запускаемых как от root, так и от любого пользователя (это в основном скрипты для работы с кластером и RBAC) указывать права доступа и владельца root не стал Как я понимаю по умолчанию установится то что надо: %attr(0755,root,root) Защищенность данного решения от доступа к скриптам и файлам сторонним пользователем значительно возросла Что очень полезно для защищенного решения в рамках платформ c10f Спасибо за совет! 252709 111 rider 2024-10-08 17:32:27 +0300 +- Removed unuser script podsec-k8s-create-master. выглядит как опечатка. Всё остальное (я детально права не проверял) стало заметно лучше. спасибо. 252710 112 rider 2024-10-08 17:35:18 +0300 Ещё вот тут: https://git.altlinux.org/tasks/358357/build/2300/x86_64/srpm.log заметил: warning: Macro %min_kube_minor_version not found warning: Macro %min_kube_minor_version not found в changelog нужно писать как %%min_kube_minor_version (экранировать макрос). Иначе он раскроется в полноценный макрос, который будет написан прямо в changelog 252720 113 kaf 2024-10-08 21:21:57 +0300 (Ответ для Anton Farygin на комментарий #112) > Ещё вот тут: > https://git.altlinux.org/tasks/358357/build/2300/x86_64/srpm.log > заметил: > warning: Macro %min_kube_minor_version not found > warning: Macro %min_kube_minor_version not found > > в changelog нужно писать как %%min_kube_minor_version (экранировать макрос). > Иначе он раскроется в полноценный макрос, который будет написан прямо в > changelog https://git.altlinux.org/tasks/358357/ Опечатку испрвил Спасибо за %min_kube_minor - не мог найти место Для единообразия не стал экранировать %, а удалил 252737 114 rider 2024-10-09 11:39:12 +0300 (In reply to ALexey Kostarev from comment #113) > Спасибо за %min_kube_minor - не мог найти место > > Для единообразия не стал экранировать %, а удалил Только об этом не надо делать записи в changelog пакета. Просто коммит с фиксом и всё. И не надо увеличивать релиз лишний раз, если пакет ещё не был собран в репозиторий. 252801 115 kaf 2024-10-09 20:38:27 +0300 (Ответ для Anton Farygin на комментарий #114) > (In reply to ALexey Kostarev from comment #113) > > Спасибо за %min_kube_minor - не мог найти место > > > > Для единообразия не стал экранировать %, а удалил > > > Только об этом не надо делать записи в changelog пакета. Просто коммит с > фиксом и всё. > > И не надо увеличивать релиз лишний раз, если пакет ещё не был собран в > репозиторий. DONE 252808 116 rider 2024-10-10 08:13:24 +0300 я бы, конечно, рекомендовал для этих мелких изменений использовать отдельный git commit без изменения specfile и версии. Т.е. - просто commit, в котором поправить кривую запись changelog. Ещё что заинтересовало в specfile, коль мы уж решили дальше работать над его качеством - зачем-то фильтруются зависимости. Когда так делают, то обычно это или ошибка, или непонимание работы алгоритмов поиска зависимостей. Предлагаю прокомментировать каждый из фильтров. 252862 117 kaf 2024-10-11 08:54:43 +0300 (Ответ для Anton Farygin на комментарий #116) > я бы, конечно, рекомендовал для этих мелких изменений использовать отдельный > git commit без изменения specfile и версии. > > Т.е. - просто commit, в котором поправить кривую запись changelog. https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=summary Постарался обеспечить в последних комитах между 1.1.9-alt1, 1.1.10-alt1 252863 118 kaf 2024-10-11 09:12:58 +0300 (Ответ для Anton Farygin на комментарий #116) > > Ещё что заинтересовало в specfile, коль мы уж решили дальше работать над его > качеством - зачем-то фильтруются зависимости. Когда так делают, то обычно > это или ошибка, или непонимание работы алгоритмов поиска зависимостей. > Предлагаю прокомментировать каждый из фильтров. https://git.altlinux.org/tasks/358357/ Добавил комментарии https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=blob;f=podsec.spec;h=87d9d05c5dd51bbc6948c55d769a6ab0dd93fc68;hb=HEAD#l59 Дело в том, что kubernetes достаточно активно развивается За последние 1.5 года что существует podsec уже вышло 6 минорных версий kubernetes: 1.26, 1.27, 1.28, 1.29, 1.30, 1.31 В рамках каждой минорной версии 3-10 патчевых Мы для каждой минорной версии создаем отдельный версионный набор kubernetes-пакетов kubernetes-1.22, kubernetes1.23, .., kubernetes-1.33 См. https://packages.altlinux.org/ru/search/?branch=sisyphus&q=kubernetesВ рамках каждой минорной версии собирается несколько патчевых версий образов Поэтому нет особого смысла в RPM-пакет добавлять зависимости на последнюю минорную версию kubernetes. Во время установки пакета она может быть намного старше Поэтому сейчас поддерживается режим, когда последняя версия kubernetes определяется и устанавливается в момент разворачивания кластера podsec-скриптом kubeadm init ... в функции installKubeadm https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=blob;f=podsec-k8s/bin/podsec-u7s-functions;h=5ec158f92068bbca51e89b2a0b15edb399fea7bd;hb=HEAD#l354 Кроме этого эта функция позволяет устновить версию kubeadm, указанную в переменной U7S_KUBEVERSION См. https://www.altlinux.org/Rootless_kubernetes#%D0%92%D1%8B%D0%B1%D0%BE%D1%80_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B8_kubernetes,_%D0%B8%D0%BC%D0%B5%D0%BD%D0%B8_%D1%80%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%BE%D1%80%D0%B0_%D0%B8_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D1%8B Поэтому нет смысла в пакет podsec-k8s добавлять при сборке пакета зависимость от последней минорной версии kubernetes В момент разворачивания кластера она может быть другой 252868 119 rider 2024-10-11 10:40:59 +0300 > В момент разворачивания кластера она может быть другой Ну так отлично, можно не удалять зависимость на /usr/bin/kubeadm, который предоставится одним из: https://packages.altlinux.org/ru/sisyphus/files/?q=%2Fusr%2Fbin%2Fkubeadm Т.е. - она универсальная и при установке podsec-k8s вытянется самый свежий пакет с /usr/bin/kubeadm, а если он уже установлен в системе, то ничего не произойдёт. 252869 120 rider 2024-10-11 10:44:53 +0300 И ещё я очень не хочу заглядывать внутрь скриптов, но просто мимо проходя в коммите dbeb9ca9b8cfb4fcd20005fbf7dff9d0048e6d74 Заметил что весь вывод текста идёт на русском языке. Это ошибка, весь вывод нужно делать по умолчанию на английском и в зависимости от локали переводить на русский через gettext На мой взгляд ментор должен был рассказать про это при ревью кода. 252870 121 rider 2024-10-11 10:47:25 +0300 (In reply to ALexey Kostarev from comment #117) > (Ответ для Anton Farygin на комментарий #116) > > я бы, конечно, рекомендовал для этих мелких изменений использовать отдельный > > git commit без изменения specfile и версии. > > > > Т.е. - просто commit, в котором поправить кривую запись changelog. > https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=summary > > Постарался обеспечить в последних комитах между > 1.1.9-alt1, 1.1.10-alt1 Спасибо, с этим я уже проблем не вижу. 252871 122 kaf 2024-10-11 11:10:45 +0300 (Ответ для Anton Farygin на комментарий #119) > > В момент разворачивания кластера она может быть другой > > Ну так отлично, можно не удалять зависимость на /usr/bin/kubeadm, который > предоставится одним из: > https://packages.altlinux.org/ru/sisyphus/files/?q=%2Fusr%2Fbin%2Fkubeadm > > Т.е. - она универсальная и при установке podsec-k8s вытянется самый свежий > пакет с /usr/bin/kubeadm, а если он уже установлен в системе, то ничего не > произойдёт. По моему уже пошла вкусовщина :-) При разворачивании kuber часто необходимо бывает установить не последнюю минорную версию Это необходимо как при тестировании, так и при разворачивании у клиента Дело в том, что kuber разрешает только последовательные обновления То есть, если у клиента стоял kuber-1.26, то он должен последовательно обновиться 1.26 -> 1.27 -> 1.28 -> 1.29 -> 1.30 -> 1.31 Это решается путем установки переменной среды U7S_KUBEVERSION В этой ситуации произойдет двойная загрузка kuber-пакетов - последней при apt-get install - указанной при kubeadm init/join на каждом из 6-ти шагов перечесленных выше на каждом из многочисленных узлов кластера (десятки, сотни) kuber-пакеты не маленькие Время на загрузку-перезагрузку уходит приличное Зачем при apt-get install podsec-k8s ставить последнюю версию kuber, если далее (при обновлении со старых версий) ее придется заменять на другую на многочисленных узлах кластера? Это только вызовет раздражение у клиента и ничего более... Я смысла не вижу... 252872 123 kaf 2024-10-11 11:16:52 +0300 (Ответ для ALexey Kostarev на комментарий #122) > (Ответ для Anton Farygin на комментарий #119) > > > В момент разворачивания кластера она может быть другой > > > > Ну так отлично, можно не удалять зависимость на /usr/bin/kubeadm, который > > предоставится одним из: > > https://packages.altlinux.org/ru/sisyphus/files/?q=%2Fusr%2Fbin%2Fkubeadm > > > > Т.е. - она универсальная и при установке podsec-k8s вытянется самый свежий > > пакет с /usr/bin/kubeadm, а если он уже установлен в системе, то ничего не > > произойдёт. > > По моему уже пошла вкусовщина :-) > При разворачивании kuber часто необходимо бывает установить > не последнюю минорную версию > Это необходимо как при тестировании, так и при разворачивании у клиента > Дело в том, что kuber разрешает только последовательные обновления > То есть, если у клиента стоял kuber-1.26, то он должен последовательно > обновиться > 1.26 -> 1.27 -> 1.28 -> 1.29 -> 1.30 -> 1.31 > > Это решается путем установки переменной среды U7S_KUBEVERSION > > В этой ситуации произойдет двойная загрузка kuber-пакетов > - последней при apt-get install > - указанной при kubeadm init/join на каждом из 6-ти шагов перечесленных выше > на каждом из многочисленных узлов кластера (десятки, сотни) > > kuber-пакеты не маленькие > Время на загрузку-перезагрузку уходит приличное > > Зачем при > apt-get install podsec-k8s > ставить последнюю версию kuber, если далее (при обновлении со старых версий) > ее придется заменять на другую на многочисленных узлах кластера? > Это только вызовет раздражение у клиента и ничего более... > > Я смысла не вижу... Тем более при установке последней версии при apt-get install podsec-k8s могут установиться файлы конфигурации которые не нужны в предыдущих версиях При установке предыдущих может возникнуть какие-то конфликты с ними Зачем себе и администратору создавать эти проблемы, которых могло бы не быть при последовательном обновлении с установленной у клиента версии, когда и других проблем достаточно? Чтобы мучались? :-) 252873 124 kaf 2024-10-11 11:21:39 +0300 (Ответ для Anton Farygin на комментарий #120) > И ещё я очень не хочу заглядывать внутрь скриптов, но просто мимо проходя в > коммите dbeb9ca9b8cfb4fcd20005fbf7dff9d0048e6d74 > > Заметил что весь вывод текста идёт на русском языке. > Это ошибка, весь вывод нужно делать по умолчанию на английском и в > зависимости от локали переводить на русский через gettext > > На мой взгляд ментор должен был рассказать про это при ревью кода. Причину я уже объяснял выше Если бы не успели к указанному сроку этого пакеты не было вообще - за ненадобностью Замечание принимаю Но исправление займет немало времени Сейчас вроде проблем с версии 1.1.8-alt3 для сертификации нет Надеюсь не будет и на дало будет удалять временно таск из сизифа 252874 125 rider 2024-10-11 11:23:56 +0300 (In reply to ALexey Kostarev from comment #122) > По моему уже пошла вкусовщина :-) > При разворачивании kuber часто необходимо бывает установить > не последнюю минорную версию > Это необходимо как при тестировании, так и при разворачивании у клиента > Дело в том, что kuber разрешает только последовательные обновления > То есть, если у клиента стоял kuber-1.26, то он должен последовательно > обновиться > 1.26 -> 1.27 -> 1.28 -> 1.29 -> 1.30 -> 1.31 > > Это решается путем установки переменной среды U7S_KUBEVERSION > > В этой ситуации произойдет двойная загрузка kuber-пакетов > - последней при apt-get install > - указанной при kubeadm init/join на каждом из 6-ти шагов перечесленных выше > на каждом из многочисленных узлов кластера (десятки, сотни) > > kuber-пакеты не маленькие > Время на загрузку-перезагрузку уходит приличное > > Зачем при > apt-get install podsec-k8s > ставить последнюю версию kuber, если далее (при обновлении со старых версий) > ее придется заменять на другую на многочисленных узлах кластера? > Это только вызовет раздражение у клиента и ничего более... > > Я смысла не вижу... Да вообще без проблем. В коде замаскируйте вызов утилит через переменную и не надо будет чистить зависимости. 252877 126 kaf 2024-10-11 11:33:08 +0300 > Тем более при установке последней версии при > apt-get install podsec-k8s > могут установиться файлы конфигурации которые не нужны в предыдущих версиях > При установке предыдущих может возникнуть какие-то конфликты с ними > Зачем себе и администратору создавать эти проблемы, которых могло бы не быть > при последовательном обновлении с установленной у клиента версии, когда и > других проблем достаточно? > > Чтобы мучались? :-) Да и последний как мне кажется неоспоримый аргумент Если у клиента стоит kuber 1.26 - 1.29, а он при обновлении автоматически по зависимостям поставит 1.31 (перескок как минимум через 1.30), то данный узел кластера гарантированно ляжет и вряд ли его можно будет после этого вернуть в кластер Только путем полной переустановки системы И то же факт 252880 127 rider 2024-10-11 11:34:22 +0300 (In reply to ALexey Kostarev from comment #126) > > Тем более при установке последней версии при > > apt-get install podsec-k8s > > могут установиться файлы конфигурации которые не нужны в предыдущих версиях > > При установке предыдущих может возникнуть какие-то конфликты с ними > > Зачем себе и администратору создавать эти проблемы, которых могло бы не быть > > при последовательном обновлении с установленной у клиента версии, когда и > > других проблем достаточно? > > > > Чтобы мучались? :-) > Да и последний как мне кажется неоспоримый аргумент > > Если у клиента стоит kuber 1.26 - 1.29, а он при обновлении автоматически по > зависимостям поставит 1.31 (перескок как минимум через 1.30), то данный > узел кластера гарантированно ляжет и вряд ли его можно будет после этого > вернуть в кластер > > Только путем полной переустановки системы > И то же факт Откуда информация о том, что наличие зависимости на /usr/bin/kubeadm притащит самый свежий kubernetes при наличии одинаковых provides ? 252885 128 kaf 2024-10-11 14:19:54 +0300 (Ответ для Anton Farygin на комментарий #125) > > > > Я смысла не вижу... > > Да вообще без проблем. В коде замаскируйте вызов утилит через переменную и > не надо будет чистить зависимости. Нет конечно вариант для того, чтобы майнтейнер на заметил :-) Но не совсем понятно зачем запрещать использовать какие то rpm-spec-операторы которые вроде как предназначены для решения возникающих проблем Подумаю... 252886 129 kaf 2024-10-11 14:22:07 +0300 (Ответ для Anton Farygin на комментарий #127) > Откуда информация о том, что наличие зависимости на /usr/bin/kubeadm > притащит самый свежий kubernetes при наличии одинаковых provides ? Ну пока притаскивал самый свежий Но проблеме не в том, чтобы притащить свежий Проблема в том, чтобы вообще не притаскивал 252887 130 rider 2024-10-11 14:22:30 +0300 Ну наверное потому что эти макросы бьют из пушки и прячут все зависимости на данные бинарники 252888 131 rider 2024-10-11 14:23:07 +0300 (In reply to ALexey Kostarev from comment #129) > (Ответ для Anton Farygin на комментарий #127) > > > Откуда информация о том, что наличие зависимости на /usr/bin/kubeadm > > притащит самый свежий kubernetes при наличии одинаковых provides ? > > Ну пока притаскивал самый свежий > Но проблеме не в том, чтобы притащить свежий > Проблема в том, чтобы вообще не притаскивал Самый свежий притаскивает только тогда, когда ничего другого не установлено. 252889 132 kaf 2024-10-11 14:29:07 +0300 (Ответ для ALexey Kostarev на комментарий #128) > (Ответ для Anton Farygin на комментарий #125) > > > > > > > Я смысла не вижу... > > > > Да вообще без проблем. В коде замаскируйте вызов утилит через переменную и > > не надо будет чистить зависимости. > Нет конечно вариант для того, чтобы майнтейнер на заметил :-) > > Но не совсем понятно зачем запрещать использовать какие то > rpm-spec-операторы которые вроде как предназначены для решения возникающих > проблем > > Подумаю... В замене переменной есть думаю ньюанс Алгоритм по которому hasher добавляет зависимости по контексу исходного кода мне неизвестен и нет никакой гарантии, что hasher вытащит зависимость из значениея переменной В общем на эти эксперементы может уйти куча времени и в итоге напороться на замечания другого майнтейнера нафига такие выкрутасы реализованы. Как то у меня ослабленная мотивация на реализацию этого подхода... 252890 133 rider 2024-10-11 14:31:10 +0300 Нет нюансов. Посоветуйтесь с вашим ментором. 252891 134 kaf 2024-10-11 15:29:17 +0300 (Ответ для Anton Farygin на комментарий #133) > Нет нюансов. Посоветуйтесь с вашим ментором. Если мне не изменят память именно Алексей Шабалин предложил этот ( %filter_from_requires) выход из возникшей ситуации OK Внимательно еще раз продумаю Тем более пока мы еще не отлаживали и не документировали механизм upgrade с версии на версию По итогам примем решение... 253063 135 kaf 2024-10-16 07:30:22 +0300 (Ответ для Anton Farygin на комментарий #120) > И ещё я очень не хочу заглядывать внутрь скриптов, но просто мимо проходя в > коммите dbeb9ca9b8cfb4fcd20005fbf7dff9d0048e6d74 > > Заметил что весь вывод текста идёт на русском языке. > Это ошибка, весь вывод нужно делать по умолчанию на английском и в > зависимости от локали переводить на русский через gettext > Доброе утро https://git.altlinux.org/tasks/358357/ Локализовал скрипты Добавил зависимости от kubernetes-пакетов 253066 136 rider 2024-10-16 08:35:57 +0300 В последнем коммите Makefile случайно попал, его надо в отдельный (или в предыдущие) перенести. 253067 137 kaf 2024-10-16 09:06:43 +0300 (Ответ для Anton Farygin на комментарий #136) > В последнем коммите Makefile случайно попал, его надо в отдельный (или в > предыдущие) перенести. https://git.altlinux.org/tasks/358357/ DONE 253072 138 rider 2024-10-16 10:40:39 +0300 Ещё заметил (раньше на это не посмотрел) - локализованные man страницы должны лежать в другом каталоге. А у вас все страницы на русском языке. Надо: 1) добавить man на английском 2) переложить страницы на русском в другой каталог Если сложно писать страницы на английском, то можно просто переложить существующие в другой каталог. 253075 139 kaf 2024-10-16 11:25:28 +0300 (Ответ для Anton Farygin на комментарий #138) > Ещё заметил (раньше на это не посмотрел) - локализованные man страницы > должны лежать в другом каталоге. > > А у вас все страницы на русском языке. Надо: > 1) добавить man на английском > 2) переложить страницы на русском в другой каталог > > Если сложно писать страницы на английском, то можно просто переложить > существующие в другой каталог. Постараюсь первести Доводить до ума, так доводить Вопрос Я формирую man'ы из MD-файлов Напр https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=blob;f=podsec/md/podsec-create-imagemakeruser.md;h=6708c8a47fa651aaecb19cedb07a7094c129c00c;hb=HEAD конвертируя с помощью ronn в man'ы Перевод я тоже буду делать в в MD-фйалах Есть ли смысл включить MD-файлы в rpm-пакеты и если да где их размещать в файловой системе? 253077 140 rider 2024-10-16 11:56:18 +0300 если MD файлы исходники, то зачем ? Но лучше с ментором обсудить. 253096 141 grenka 2024-10-16 15:08:48 +0300 Я мельком глянул, что тут происходит, рецензент рецензирует хорошо, надеюсь использование тэгов Requires ещё обсудите. Что рецензент может не заметить, так это использование команды rm в спеке. Не знаю записано у нас это где-то или нет, но лучше вместо флага -f использовать флаг -v. Я в своей практике утомился вычищать мусорные удаления из спеков. К тому же с флагом -v и лог сборки становится более информативным. 253109 142 kaf 2024-10-17 08:23:41 +0300 (Ответ для Anton Farygin на комментарий #138) > Ещё заметил (раньше на это не посмотрел) - локализованные man страницы > должны лежать в другом каталоге. > Доброе утро > Если сложно писать страницы на английском, то можно просто переложить > существующие в другой каталог. После вытаскивая текста комитов за полтора года из git, перевода их на английский и приведения к стандартному виду перевод man'ов на английский существенно более простая задача :-) > А у вас все страницы на русском языке. Надо: > 1) добавить man на английском > 2) переложить страницы на русском в другой каталог > Сделано https://git.altlinux.org/tasks/358357/ Так как podsec прошел довольно глубокую локализацию, изменения прав доступа к файлам и потребует довольно глубокого тестирования на предмет наличия регрессий, то решил перейти на новую минорную версию 1.2 253110 143 kaf 2024-10-17 08:24:30 +0300 (Ответ для Grigory Ustinov на комментарий #141) > Я мельком глянул, что тут происходит, рецензент рецензирует хорошо, надеюсь > использование тэгов Requires ещё обсудите. > > Что рецензент может не заметить, так это использование команды rm в спеке. > Не знаю записано у нас это где-то или нет, но лучше вместо флага -f > использовать флаг -v. Я в своей практике утомился вычищать мусорные удаления > из спеков. К тому же с флагом -v и лог сборки становится более информативным. Доброе утро Спасибо Флаг добавил... 253111 144 rider 2024-10-17 08:42:08 +0300 (In reply to ALexey Kostarev from comment #142) > (Ответ для Anton Farygin на комментарий #138) > > Ещё заметил (раньше на это не посмотрел) - локализованные man страницы > > должны лежать в другом каталоге. > > > > Доброе утро > > Если сложно писать страницы на английском, то можно просто переложить > > существующие в другой каталог. > После вытаскивая текста комитов за полтора года из git, > перевода их на английский и приведения к стандартному виду > перевод man'ов на английский существенно более простая задача :-) > > > А у вас все страницы на русском языке. Надо: > > 1) добавить man на английском > > 2) переложить страницы на русском в другой каталог > > > Сделано > https://git.altlinux.org/tasks/358357/ > > Так как podsec прошел довольно глубокую локализацию, изменения прав доступа > к файлам и потребует довольно глубокого тестирования на предмет наличия > регрессий, то решил перейти на новую минорную версию 1.2 Спасибо. Выглядит неплохо. 253112 145 rider 2024-10-17 08:46:01 +0300 (In reply to Grigory Ustinov from comment #141) > Я мельком глянул, что тут происходит, рецензент рецензирует хорошо, надеюсь > использование тэгов Requires ещё обсудите. > > Что рецензент может не заметить, так это использование команды rm в спеке. > Не знаю записано у нас это где-то или нет, но лучше вместо флага -f > использовать флаг -v. Я в своей практике утомился вычищать мусорные удаления > из спеков. К тому же с флагом -v и лог сборки становится более информативным. Да, у нас нет нигде правил написания удаления. Это просто совет от более опытного ментейнера. Наверное его стоит где-то зафиксировать на www.altlinux.org Что касается зависимостей - я сразу заметил перегруженность по requires, но пока не задавался вопросом - зачем. Предлагаю начать с полного удаления всех зависимостей из requires, за исключением проверенных и межпакетных. Например, Requires: sh - явно не нужен, у нас автопоиск зависимостей отлично находит sh. И т.д. - в спекфайле нужно оставить только те зависимости, которые автоматический поиск не нашёл. Привязка к версиям тоже выглядит довольно странно - например nginx указан Requires: nginx >= 1.22.1 но я уверен что с более младшими версиями nginx проблем не будет. 253113 146 rider 2024-10-17 08:47:41 +0300 (In reply to Anton Farygin from comment #144) > (In reply to ALexey Kostarev from comment #142) > > (Ответ для Anton Farygin на комментарий #138) > > > Ещё заметил (раньше на это не посмотрел) - локализованные man страницы > > > должны лежать в другом каталоге. > > > > > > > Доброе утро > > > Если сложно писать страницы на английском, то можно просто переложить > > > существующие в другой каталог. > > После вытаскивая текста комитов за полтора года из git, > > перевода их на английский и приведения к стандартному виду > > перевод man'ов на английский существенно более простая задача :-) > > > > > А у вас все страницы на русском языке. Надо: > > > 1) добавить man на английском > > > 2) переложить страницы на русском в другой каталог > > > > > Сделано > > https://git.altlinux.org/tasks/358357/ > > > > Так как podsec прошел довольно глубокую локализацию, изменения прав доступа > > к файлам и потребует довольно глубокого тестирования на предмет наличия > > регрессий, то решил перейти на новую минорную версию 1.2 > > Спасибо. Выглядит неплохо. Но если уж делать совсем хорошо, то генерацию man страниц стоит сделать во время сборки пакета (в Makefile, например), а из дерева сгенерённые man убрать. 253117 147 kaf 2024-10-17 10:39:43 +0300 > > Но если уж делать совсем хорошо, то генерацию man страниц стоит сделать во > время сборки пакета (в Makefile, например), а из дерева сгенерённые man > убрать. https://git.altlinux.org/tasks/358357/ Удалили из дерева man-файлы Перенес генерацию из md-файлов в Makefile Так как нового функционала не добавилось, то решил не увеличивать Release увеличив Version до alt2 253123 148 rider 2024-10-17 14:24:19 +0300 (In reply to ALexey Kostarev from comment #147) > > > > Но если уж делать совсем хорошо, то генерацию man страниц стоит сделать во > > время сборки пакета (в Makefile, например), а из дерева сгенерённые man > > убрать. > https://git.altlinux.org/tasks/358357/ > Удалили из дерева man-файлы > Перенес генерацию из md-файлов в Makefile > > Так как нового функционала не добавилось, то решил не увеличивать > Release > увеличив > Version > до alt2 Только наоборот. Надо было увеличить Version до 1.2.1 а release оставить alt1 253124 149 rider 2024-10-17 14:26:21 +0300 Ещё раз повторю правило версионирования и рекомендую прямо записать его в README проекта: при изменении исходного кода - увеличиваем version при изменении только specfile - увеличиваем release Поменялся код и спек - увеличиваем version и сбрасываем release на alt1 поменялся только спек - увеличиваем release на 1 253153 150 kaf 2024-10-18 10:25:53 +0300 (Ответ для Anton Farygin на комментарий #148) > (In reply to ALexey Kostarev from comment #147) > > > > > > Но если уж делать совсем хорошо, то генерацию man страниц стоит сделать во > > > время сборки пакета (в Makefile, например), а из дерева сгенерённые man > > > убрать. > > https://git.altlinux.org/tasks/358357/ > > Удалили из дерева man-файлы > > Перенес генерацию из md-файлов в Makefile > > > > Так как нового функционала не добавилось, то решил не увеличивать > > Release > > увеличив > > Version > > до alt2 > > Только наоборот. Надо было увеличить Version до 1.2.1 а release оставить alt1 https://git.altlinux.org/tasks/358357/ Сейчас снова необходимо внести изменения в ветку платформы c10f2 (обнаружены баги) Я попросил у Дениса Медведева инструкцию как это сделать в текущей ситуации (ветки к сожалению расходятся), но пока пока ответа не получил Как потом сливать ветки (через git rebase?) тоже вопрос Так что немного "подвешен" в текущей ситуации 253161 151 rider 2024-10-18 13:44:45 +0300 Не вижу изменений с Requires. 253162 152 kaf 2024-10-18 13:48:04 +0300 (Ответ для Anton Farygin на комментарий #151) > Не вижу изменений с Requires. Как это? https://git.altlinux.org/tasks/358357/gears/4100/git?p=git;a=blob;f=podsec.spec;h=b7eeb12c72a7a481a56107ea21406f3b38201746;hb=HEAD#l60 Requires: kubernetes-kubeadm Requires: kubernetes-client Requires: kubernetes-kubelet 253163 153 rider 2024-10-18 13:52:35 +0300 (In reply to ALexey Kostarev from comment #152) > (Ответ для Anton Farygin на комментарий #151) > > Не вижу изменений с Requires. > > Как это? > https://git.altlinux.org/tasks/358357/gears/4100/git?p=git;a=blob;f=podsec. > spec;h=b7eeb12c72a7a481a56107ea21406f3b38201746;hb=HEAD#l60 > Requires: kubernetes-kubeadm > Requires: kubernetes-client > Requires: kubernetes-kubelet из 145 комментария в этом issue 253165 154 kaf 2024-10-18 14:15:32 +0300 (Ответ для Anton Farygin на комментарий #153) > (In reply to ALexey Kostarev from comment #152) > > (Ответ для Anton Farygin на комментарий #151) > > > Не вижу изменений с Requires. > > > > Как это? > > https://git.altlinux.org/tasks/358357/gears/4100/git?p=git;a=blob;f=podsec. > > spec;h=b7eeb12c72a7a481a56107ea21406f3b38201746;hb=HEAD#l60 > > Requires: kubernetes-kubeadm > > Requires: kubernetes-client > > Requires: kubernetes-kubelet > > из 145 комментария в этом issue OK Тут есть вопрос При автоматическом поиске вставляется зависимость от последний версий пакетов что по мне не есть хорошо Я бы оставил зависимости с ограниченими версий package>=version и >= %EVR 253166 155 rider 2024-10-18 14:44:15 +0300 при автоматичкеском поиске версии вообще никакие не проставляются. обсудите это, пожалуйста, со своим ментором. 253183 156 kaf 2024-10-18 16:00:28 +0300 (Ответ для Anton Farygin на комментарий #155) > при автоматичкеском поиске версии вообще никакие не проставляются. > обсудите это, пожалуйста, со своим ментором. https://git.altlinux.org/tasks/358357/ Убрал Requires без указания версий Алексей Шабалин сейчас на встрече - оперативно ответить не может Договорились, что в выходные примет окончательное решение Но чтобы процесс не простаивал выложу пока этот вариант 253194 157 rider 2024-10-18 19:31:14 +0300 https://git.altlinux.org/tasks/358357/gears/4200/git?p=git;a=commitdiff;h=b217cba37bf65a7713cce41f7de5bd27388fed17 тут ошибка в содержимом коммита 253195 158 rider 2024-10-18 19:31:48 +0300 там вообще в коммитах ошибки. Как приведёте в порядок - напишите. 253294 159 kaf 2024-10-22 13:18:16 +0300 (Ответ для Anton Farygin на комментарий #155) > при автоматичкеском поиске версии вообще никакие не проставляются. > обсудите это, пожалуйста, со своим ментором. Обсудили вчера с Алексеем Шабалиным 1. За счет добавления defattr упорядочил каталоги и файлы с разными правами доступа 2. Оставил только те Requires, которые не добавляются при автоматическом сканировании зависимостей https://git.altlinux.org/tasks/358357/ 253378 160 rider 2024-10-24 09:09:20 +0300 (In reply to ALexey Kostarev from comment #159) > (Ответ для Anton Farygin на комментарий #155) > > при автоматичкеском поиске версии вообще никакие не проставляются. > > обсудите это, пожалуйста, со своим ментором. > > Обсудили вчера с Алексеем Шабалиным > > 1. За счет добавления > defattr > упорядочил каталоги и файлы с разными правами доступа > > 2. Оставил только те Requires, которые не добавляются при автоматическом > сканировании зависимостей > > https://git.altlinux.org/tasks/358357/ Всё очень неплохо, надо только убрать лишнюю пустую строчку в changelog в последнем коммите (переписав сам коммит) и можно будет коммитить в репозиторий. 253385 161 kaf 2024-10-24 14:50:07 +0300 (Ответ для ALexey Kostarev на комментарий #159) > (Ответ для Anton Farygin на комментарий #155) > > при автоматичкеском поиске версии вообще никакие не проставляются. > > обсудите это, пожалуйста, со своим ментором. > > Обсудили вчера с Алексеем Шабалиным > > 1. За счет добавления > defattr > упорядочил каталоги и файлы с разными правами доступа > > 2. Оставил только те Requires, которые не добавляются при автоматическом > сканировании зависимостей > > https://git.altlinux.org/tasks/358357/ Добрый день Поправил 253387 162 rider 2024-10-24 15:17:20 +0300 Заапрувил, спасибо. Можно коммитить и отправлять в стабильные ветки. 253389 163 kaf 2024-10-24 15:29:42 +0300 (Ответ для Anton Farygin на комментарий #162) > Заапрувил, спасибо. Можно коммитить и отправлять в стабильные ветки. Спасибо Отличный подарок на мой день рождения! 253424 164 kaf 2024-10-25 15:07:12 +0300 (Ответ для ALexey Kostarev на комментарий #163) > (Ответ для Anton Farygin на комментарий #162) > > Заапрувил, спасибо. Можно коммитить и отправлять в стабильные ветки. > > Спасибо > Отличный подарок на мой день рождения! Добрый день коллеги podsec 1.2.2-alt1 дошел до sisyphus https://packages.altlinux.org/ru/sisyphus/srpms/podsec/ Теперь у меня вопрос по Чернышевскому "Что делать?" (дальще) Какой мой текущий статус? Какие еще телодвижения с моей стороны требуются для завершения JOIN? Мне бы довести до sisyphus пакеты - flux2 - https://git.altlinux.org/people/kaf/packages/?p=flux2.git;a=summary https://git.altlinux.org/tasks/355139/logs/events.2.1.log - podman-compose-to-kube - https://git.altlinux.org/people/kaf/packages/?p=podman-compose-to-kube.git;a=summary По последнему буквально вчера появился запрос со стороны Чернобривченко Елена Васильевна (chernobrivchenkoev@basealt.ru) Также судя по всему согласно последним разговорам появится необходимость портировать в ALT kompose - https://github.com/kubernetes/kompose 253426 165 shaba 2024-10-25 15:22:31 +0300 Все хотел написать раньше, но что-то останавливало :) Алексей, не надо из багзилы устаивать чатик. Не надо тут писать что кто-то недоступен, в командировке, на встрече, и т.п. Никому это не интересно. Не надо указывать какие-то другие производственные причины и требование. Не важно где Вы работаете. Join про другое. Давайте тут описывать и рассматривать исключительно технические вопросы. По делу. В каком виде отправлять в стабильные бранчи пакет podsec, решать исключительно Вам. Будете ли вы сопровождать несколько веток в git или нет, тоже решать Вам. Если текущую версию из сизифа можно один-в-один отправить в стабильные бранчи, то сделайте такое задание. Обойти наследование истории я подскажу как. 253427 166 shaba 2024-10-25 15:23:25 +0300 И еще, отправка пакетов в стабильные бранчи, никак не касается процедуры Join. 253505 167 rider 2024-10-28 10:22:21 +0300 Что касается завершения JOIN - мы исправили (с большим трудом, на мой взгляд) один пакет. Я вижу колоссальную недоработку со стороны ментора и это надо исправлять. https://git.altlinux.org/people/kaf/packages/?p=flux2.git;a=blob;f=flux2.spec;h=8423dd64e86eecc3dec00670afa8f94e9e9b5289;hb=ec48bb36e33f1a935c09bb30bbe647ec63a6c6fd Вот тут: 1) spec файл лучше перенести в .gear - так будет проще в дальнейшем переезжать на другую апстримную ветку 2) первая запись в changelog рекомендуется другая 3) не включены тесты 253506 168 rider 2024-10-28 10:24:04 +0300 https://git.altlinux.org/people/kaf/packages/?p=podman-compose-to-kube.git;a=commitdiff;h=3e7fce88c4699be46ea1a4bed14de70411420b42 - тут опять содержимое изменений не полностью соответствует тексту в message 253507 169 rider 2024-10-28 10:25:20 +0300 https://git.altlinux.org/people/kaf/packages/?p=podman-compose-to-kube.git;a=commitdiff;h=4c918dc8fb28c5d9ae62aac22ab48344547022f7 тут тоже самое, плюс тарболл лучше делать из апстримного тэга и прикладывать альтовый патч, что бы было явно видно ваши изменения. 253618 170 shaba 2024-10-30 01:26:38 +0300 (In reply to Anton Farygin from comment #167) > Вот тут: > 1) spec файл лучше перенести в .gear - так будет проще в дальнейшем > переезжать на другую апстримную ветку Нет, не лучше. Пусть остается в корне. Но давай об этом не будем спорить. Это абсолютно не важно при сборке этого пакета. > 2) первая запись в changelog рекомендуется другая Согласен. И тоже устал на это указывать. > 3) не включены тесты И не должны. Они для работы требуют выхода в Интернет. 253624 171 kaf 2024-10-30 09:08:53 +0300 Доброе утро! (Ответ для Alexey Shabalin на комментарий #170) > (In reply to Anton Farygin from comment #167) > > > Вот тут: > > 1) spec файл лучше перенести в .gear - так будет проще в дальнейшем > > переезжать на другую апстримную ветку > > Нет, не лучше. Пусть остается в корне. Но давай об этом не будем спорить. > Это абсолютно не важно при сборке этого пакета. Я к этому моменту уже перенес Так что в этом пакете оставлю его в .gear/flux2.spec Конфликт, насколько я помню, у меня был тогда, когда я работал с пакетом patroni и в нем уже был в корне файл patroni.spec, принадлежащий самому проекту patroni В состав flux2 входят еще 6-ть пакетов-контроллеров - см https://git.altlinux.org/tasks/355139/ Тут как скажете Но, думаю, после Approve пакета flux2, чтобы удовлетворить самые строгие требования перенесу в них файлы *.spec в .gear > > > 2) первая запись в changelog рекомендуется другая > > Согласен. И тоже устал на это указывать. Этот chanhelog был сделан еще ДО подробной работа с пакетами podsec Посмотрите https://git.altlinux.org/tasks/361134/ Все ли я учел 253625 172 rider 2024-10-30 09:32:15 +0300 (In reply to ALexey Kostarev from comment #171) > Доброе утро! > > (Ответ для Alexey Shabalin на комментарий #170) > > (In reply to Anton Farygin from comment #167) > > > > > Вот тут: > > > 1) spec файл лучше перенести в .gear - так будет проще в дальнейшем > > > переезжать на другую апстримную ветку > > > > Нет, не лучше. Пусть остается в корне. Но давай об этом не будем спорить. > > Это абсолютно не важно при сборке этого пакета. > Я к этому моменту уже перенес > Так что в этом пакете оставлю его в .gear/flux2.spec > Конфликт, насколько я помню, у меня был тогда, когда я работал с пакетом > patroni > и в нем уже был в корне файл patroni.spec, принадлежащий самому проекту > patroni Спасибо. В дальнейшем тоже лучше размещать в .gear, это облегчает переезд с ветки на ветку - достаточно перетащить содержимое .gear что бы перетащить всё, имеющее отношение к altlinux > > В состав flux2 входят еще 6-ть пакетов-контроллеров - см > https://git.altlinux.org/tasks/355139/ > > Тут как скажете > Но, думаю, после Approve пакета flux2, > чтобы удовлетворить самые строгие требования перенесу в них файлы *.spec в > .gear Да, лучше сразу сделать. Необходимость размещения всего, что имеет отношение к альту в .gear выработалась годами. > > > > > > 2) первая запись в changelog рекомендуется другая > > > > Согласен. И тоже устал на это указывать. > Этот chanhelog был сделан еще ДО подробной работа с пакетами podsec > Посмотрите > https://git.altlinux.org/tasks/361134/ > Все ли я учел Точки в %changelog пакета указаны не во всех записях. Остальное всё нормально. 253626 173 kaf 2024-10-30 10:15:52 +0300 (Ответ для Anton Farygin на комментарий #172) ... > Точки в %changelog пакета указаны не во всех записях. > Остальное всё нормально. Исправил https://git.altlinux.org/tasks/361134/ 253700 174 rider 2024-10-31 09:19:07 +0300 (In reply to ALexey Kostarev from comment #173) > (Ответ для Anton Farygin на комментарий #172) > ... > > Точки в %changelog пакета указаны не во всех записях. > > Остальное всё нормально. > Исправил > https://git.altlinux.org/tasks/361134/ task not found 253705 175 kaf 2024-10-31 09:54:41 +0300 (Ответ для Anton Farygin на комментарий #174) > (In reply to ALexey Kostarev from comment #173) > > (Ответ для Anton Farygin на комментарий #172) > > ... > > > Точки в %changelog пакета указаны не во всех записях. > > > Остальное всё нормально. > > Исправил > > https://git.altlinux.org/tasks/361134/ > > task not found Добрый день Я сейчас пересобираю все 8 пакетов входящих в flux2 https://git.altlinux.org/tasks/361226/ Есть еще недоработки - пустые строки в конце changelog Сегодня как только исправлю - сообщу 253724 176 kaf 2024-10-31 12:41:25 +0300 (Ответ для Anton Farygin на комментарий #174) > (In reply to ALexey Kostarev from comment #173) > > (Ответ для Anton Farygin на комментарий #172) > > ... > > > Точки в %changelog пакета указаны не во всех записях. > > > Остальное всё нормально. > > Исправил > > https://git.altlinux.org/tasks/361134/ > > task not found Собрал до уровня EPERM набор пакетов для flux2 https://git.altlinux.org/tasks/361256/ flux2, kustomize - команды HOST-системы остальные используются для сборки соответствующих docker-образов См. мою документацию на Вики https://www.altlinux.org/Flux2 253753 177 rider 2024-10-31 16:56:36 +0300 +%changelog +* Thu Oct 31 2024 Alexey Kostarev <kaf@altlinux.org> 1.0.1-alt1 +- Initial build. +- Added vendor modules. А Added vendor modules зачем в changelog ? разве без них можно собрать ? 253756 178 kaf 2024-10-31 17:01:21 +0300 (Ответ для Anton Farygin на комментарий #177) > +%changelog > +* Thu Oct 31 2024 Alexey Kostarev <kaf@altlinux.org> 1.0.1-alt1 > +- Initial build. > +- Added vendor modules. > > А Added vendor modules зачем в changelog ? разве без них можно собрать ? Как я понял мы вроде как в changelog включаем текст основных промежуточных комитов Я исходил из этого принципа Если для 1-го changlog это не работает, то удалю 253760 179 grenka 2024-10-31 17:39:19 +0300 (Ответ для ALexey Kostarev на комментарий #178) > Как я понял > мы вроде как в changelog включаем текст основных промежуточных комитов > Я исходил из этого принципа Коммиты для разработчиков, ченджлог больше для людей. Это то куда смотрит "пользователь" в первую очередь. То есть в первую очередь в ченджлоге пишется что-то значимое для пользователя. Обновили, убрали сервис, добавили десктоп-файл и прочее. Если ничего значимого не произошло, например отрефакторили спек, то приходится писать это, чтобы пользователь обновив пакет не ломал голову над тем, почему пакет обновился, а функционал нет. Общая логика такая. 253770 180 kaf 2024-10-31 19:43:00 +0300 (Ответ для Anton Farygin на комментарий #177) > +%changelog > +* Thu Oct 31 2024 Alexey Kostarev <kaf@altlinux.org> 1.0.1-alt1 > +- Initial build. > +- Added vendor modules. > > А Added vendor modules зачем в changelog ? разве без них можно собрать ? Исправлено https://git.altlinux.org/tasks/361320/ 253793 181 rider 2024-11-01 08:52:28 +0300 Пустая строка вставлена не в том месте (две в одном, ноль в другом) +BuildRequires: /proc + + +%description +This controller automates updates to YAML +when new container images are available. +%prep +%setup 253794 182 rider 2024-11-01 08:55:17 +0300 (In reply to ALexey Kostarev from comment #180) > (Ответ для Anton Farygin на комментарий #177) > > +%changelog > > +* Thu Oct 31 2024 Alexey Kostarev <kaf@altlinux.org> 1.0.1-alt1 > > +- Initial build. > > +- Added vendor modules. > > > > А Added vendor modules зачем в changelog ? разве без них можно собрать ? > Исправлено > https://git.altlinux.org/tasks/361320/ А почему задание сборочное изменилось ? я про номер. 253795 183 kaf 2024-11-01 08:59:43 +0300 (Ответ для Anton Farygin на комментарий #182) > (In reply to ALexey Kostarev from comment #180) > > (Ответ для Anton Farygin на комментарий #177) > > > +%changelog > > > +* Thu Oct 31 2024 Alexey Kostarev <kaf@altlinux.org> 1.0.1-alt1 > > > +- Initial build. > > > +- Added vendor modules. > > > > > > А Added vendor modules зачем в changelog ? разве без них можно собрать ? > > Исправлено > > https://git.altlinux.org/tasks/361320/ > > А почему задание сборочное изменилось ? я про номер. Надо было удалять все 8-м subtask'ов в текущем, добавлять новые Я посчитал что проще удалить текущую и создать новую задачу Вот если бы дело касалось исправление отдельного subtask'а, тогда имеет смысл оставлять остальные Или это принципиально - оставлять task? 253810 184 kaf 2024-11-01 11:32:45 +0300 (Ответ для Anton Farygin на комментарий #181) > Пустая строка вставлена не в том месте (две в одном, ноль в другом) > > +BuildRequires: /proc > + > + > +%description > +This controller automates updates to YAML > +when new container images are available. > +%prep > +%setup Исправлено https://git.altlinux.org/tasks/361320/gears/1100/git?p=git;a=blob;f=.gear/image-automation-controller.spec;h=6b8d65e627dab8d032ad1f759f24bb049c1e15c4;hb=HEAD#l18 Рискую нарваться на замечания Алексея Шабалина, но все же спрошу :-) А есть ли у нас linter для проверки корректности spec-файла? Или каждый сам кузнец своего счастья? Нашел rpmlint, но он на наличие нескольких пустых строк не реагирует Похоже надо писать шаблон на этот случай. Никто у нас этим не занимался? Номер задачи не сменил - удалил текущую подзадачу и добавил новые. Правда так как в ssh gyle task run ... нет возможности указать подзадачу, выигрыша нет Приходиться собирать все и тратить все то же свое и процессорное время :-( 253837 185 rider 2024-11-01 16:32:18 +0300 (In reply to ALexey Kostarev from comment #184) > (Ответ для Anton Farygin на комментарий #181) > > Пустая строка вставлена не в том месте (две в одном, ноль в другом) > > > > +BuildRequires: /proc > > + > > + > > +%description > > +This controller automates updates to YAML > > +when new container images are available. > > +%prep > > +%setup > > Исправлено > https://git.altlinux.org/tasks/361320/gears/1100/git?p=git;a=blob;f=.gear/ > image-automation-controller.spec;h=6b8d65e627dab8d032ad1f759f24bb049c1e15c4; > hb=HEAD#l18 > > Рискую нарваться на замечания Алексея Шабалина, но все же спрошу :-) > > А есть ли у нас linter для проверки корректности spec-файла? > Или каждый сам кузнец своего счастья? > Нашел rpmlint, но он на наличие нескольких пустых строк не реагирует > Похоже надо писать шаблон на этот случай. > Никто у нас этим не занимался? > > Номер задачи не сменил - удалил текущую подзадачу и добавил новые. > Правда так как в > ssh gyle task run ... > нет возможности указать подзадачу, выигрыша нет > Приходиться собирать все и тратить все то же свое и процессорное время :-( А не надо удалять все подзадания. Можно же удалить одно и добавить тоже одно в нужное место task'а. 253838 186 rider 2024-11-01 16:32:43 +0300 20 %description 21 This controller automates updates to YAML 22 when new container images are available. 23 %prep 24 %setup Всё равно сливается. 253842 187 kaf 2024-11-01 16:41:36 +0300 (Ответ для Anton Farygin на комментарий #185) > (In reply to ALexey Kostarev from comment #184) > > (Ответ для Anton Farygin на комментарий #181) > > > Пустая строка вставлена не в том месте (две в одном, ноль в другом) > > > > > > +BuildRequires: /proc > > > + > > > + > > > +%description > > > +This controller automates updates to YAML > > > +when new container images are available. > > > +%prep > > > +%setup > > > > Исправлено > > https://git.altlinux.org/tasks/361320/gears/1100/git?p=git;a=blob;f=.gear/ > > image-automation-controller.spec;h=6b8d65e627dab8d032ad1f759f24bb049c1e15c4; > > hb=HEAD#l18 > > > > Рискую нарваться на замечания Алексея Шабалина, но все же спрошу :-) > > > > А есть ли у нас linter для проверки корректности spec-файла? > > Или каждый сам кузнец своего счастья? > > Нашел rpmlint, но он на наличие нескольких пустых строк не реагирует > > Похоже надо писать шаблон на этот случай. > > Никто у нас этим не занимался? > > > > Номер задачи не сменил - удалил текущую подзадачу и добавил новые. > > Правда так как в > > ssh gyle task run ... > > нет возможности указать подзадачу, выигрыша нет > > Приходиться собирать все и тратить все то же свое и процессорное время :-( > > А не надо удалять все подзадания. Можно же удалить одно и добавить тоже одно > в нужное место task'а. Так я в этом случае я и не удалял все, а удалил второе и добавил в конец В следующий раз добавлю по месту, но сдается мне, что gyle run все одно будет все пакеты пересобирать Проверю 253844 188 rider 2024-11-01 16:49:55 +0300 конечно будет все пересобирать, но отслеживать состояние таких заданий гораздо удобнее. К тому же я аппрувлю и дизаппрувлю подзадания, которые прошли или не прошли проверку. 253900 189 kaf 2024-11-02 13:28:54 +0300 (Ответ для Anton Farygin на комментарий #188) > конечно будет все пересобирать, но отслеживать состояние таких заданий > гораздо удобнее. > > К тому же я аппрувлю и дизаппрувлю подзадания, которые прошли или не прошли > проверку. Исправлено https://git.altlinux.org/tasks/361320/ subtask'и оставил на месте Для уже прошедших до этого сборку вижу, что взяты из кэшей 2024-Nov-02 09:35:05 :: [x86_64] #300 image-reflector-controller.git 0.32.0-alt1: build OK (cached) ... https://git.altlinux.org/tasks/361320/logs/events.4.1.log Так что да - стоит придерживаться этой схемы Спасибо 253946 190 rider 2024-11-04 09:38:58 +0300 в пакете flux https://packages.altlinux.org/ru/sisyphus/srpms/flux2/specfiles/3136990227885862690 не включены тесты. 253947 191 rider 2024-11-04 09:43:01 +0300 https://packages.altlinux.org/ru/sisyphus/srpms/kustomize/specfiles/3136994127366774890 Замена %RELEASE% на %release выглядит как ошибка. 253949 192 rider 2024-11-04 09:45:32 +0300 https://git.altlinux.org/tasks/361320/gears/1200/git?p=git;a=tree;f=.gear;h=e73556b8d33fcdda1389d1a3bebfcb2c7df32838;hb=7557b7d8b21c10d7633cbaf93d00b7e7f6b8aa3d В этом пакете specfile лучше назвать одноимённо с именем пакета, так просто чуть чуть удобнее. 253950 193 kaf 2024-11-04 10:49:57 +0300 (Ответ для Anton Farygin на комментарий #190) > в пакете flux > https://packages.altlinux.org/ru/sisyphus/srpms/flux2/specfiles/ > 3136990227885862690 > > не включены тесты. Добрый день Алексей Шабалин выше прокомментировал же это замечание https://bugzilla.altlinux.org/show_bug.cgi?id=39627#c170 > > 3) не включены тесты > И не должны. Они для работы требуют выхода в Интернет. 253954 194 rider 2024-11-05 08:59:07 +0300 (In reply to ALexey Kostarev from comment #193) > (Ответ для Anton Farygin на комментарий #190) > > в пакете flux > > https://packages.altlinux.org/ru/sisyphus/srpms/flux2/specfiles/ > > 3136990227885862690 > > > > не включены тесты. > > Добрый день > > Алексей Шабалин выше прокомментировал же это замечание > https://bugzilla.altlinux.org/show_bug.cgi?id=39627#c170 > > > > 3) не включены тесты > > > И не должны. Они для работы требуют выхода в Интернет. ok. 254013 195 kaf 2024-11-06 12:13:35 +0300 (Ответ для Anton Farygin на комментарий #191) > https://packages.altlinux.org/ru/sisyphus/srpms/kustomize/specfiles/ > 3136994127366774890 > > Замена %RELEASE% на %release выглядит как ошибка. Эта ошибка в модуле vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob;f=kustomize/vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go;h=c637ac2e1ac09baa3915905c2196c52e649757f5;hb=HEAD#l50 GitCommit: "unknown", Из за этого в бинарном коде возвращает при вызове kustomize version возвращает unknown Я в add-alt-release-to-GitConfig.patch https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob;f=add-alt-release-to-GitConfig.patch;h=e9af1c5ae24a3b7df76726cca0ee4d0d8c231c60;hb=HEAD заменяю на GitCommit: "%RELEASE%", А затем в SPEC на текущую версию kustomize 254014 196 kaf 2024-11-06 12:15:29 +0300 (Ответ для ALexey Kostarev на комментарий #195) > (Ответ для Anton Farygin на комментарий #191) > > https://packages.altlinux.org/ru/sisyphus/srpms/kustomize/specfiles/ > > 3136994127366774890 > > > > Замена %RELEASE% на %release выглядит как ошибка. > > Эта ошибка в модуле vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob; > f=kustomize/vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go; > h=c637ac2e1ac09baa3915905c2196c52e649757f5;hb=HEAD#l50 > > GitCommit: "unknown", > > Из за этого в бинарном коде возвращает при вызове > kustomize version > возвращает > unknown > > Я в add-alt-release-to-GitConfig.patch > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob;f=add-alt- > release-to-GitConfig.patch;h=e9af1c5ae24a3b7df76726cca0ee4d0d8c231c60;hb=HEAD > заменяю на > GitCommit: "%RELEASE%", > > А затем в SPEC на текущую версию kustomize Сейчас уже точно не припомню (было почти полгода назад), на замена unknown сразу на %release создавало проблемы 254015 197 rider 2024-11-06 12:18:07 +0300 (In reply to ALexey Kostarev from comment #195) > (Ответ для Anton Farygin на комментарий #191) > > https://packages.altlinux.org/ru/sisyphus/srpms/kustomize/specfiles/ > > 3136994127366774890 > > > > Замена %RELEASE% на %release выглядит как ошибка. > > Эта ошибка в модуле vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob; > f=kustomize/vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go; > h=c637ac2e1ac09baa3915905c2196c52e649757f5;hb=HEAD#l50 > > GitCommit: "unknown", > > Из за этого в бинарном коде возвращает при вызове > kustomize version > возвращает > unknown > > Я в add-alt-release-to-GitConfig.patch > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob;f=add-alt- > release-to-GitConfig.patch;h=e9af1c5ae24a3b7df76726cca0ee4d0d8c231c60;hb=HEAD > заменяю на > GitCommit: "%RELEASE%", > > А затем в SPEC на текущую версию kustomize В этом месте должен быть sha1 git commit'а. 254016 198 kaf 2024-11-06 12:23:03 +0300 (Ответ для Anton Farygin на комментарий #197) > (In reply to ALexey Kostarev from comment #195) > > (Ответ для Anton Farygin на комментарий #191) > > > https://packages.altlinux.org/ru/sisyphus/srpms/kustomize/specfiles/ > > > 3136994127366774890 > > > > > > Замена %RELEASE% на %release выглядит как ошибка. > > > > Эта ошибка в модуле vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go > > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob; > > f=kustomize/vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go; > > h=c637ac2e1ac09baa3915905c2196c52e649757f5;hb=HEAD#l50 > > > > GitCommit: "unknown", > > > > Из за этого в бинарном коде возвращает при вызове > > kustomize version > > возвращает > > unknown > > > > Я в add-alt-release-to-GitConfig.patch > > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob;f=add-alt- > > release-to-GitConfig.patch;h=e9af1c5ae24a3b7df76726cca0ee4d0d8c231c60;hb=HEAD > > заменяю на > > GitCommit: "%RELEASE%", > > > > А затем в SPEC на текущую версию kustomize > > В этом месте должен быть sha1 git commit'а. Можно поподробнее в каком месте и какого комита? 254017 199 rider 2024-11-06 12:23:46 +0300 подробности если не понятны то лучше уточнить в апстриме. 254018 200 kaf 2024-11-06 12:31:52 +0300 (Ответ для Anton Farygin на комментарий #192) > https://git.altlinux.org/tasks/361320/gears/1200/git?p=git;a=tree;f=.gear; > h=e73556b8d33fcdda1389d1a3bebfcb2c7df32838; > hb=7557b7d8b21c10d7633cbaf93d00b7e7f6b8aa3d > > В этом пакете specfile лучше назвать одноимённо с именем пакета, так просто > чуть чуть удобнее. Да я могу и потерпеть Менять придется во всех -controller пакетах В имени этих пакетов добавлен префикс flux2- , чтобы они случайно не пересеклись с названиями других пакетов Например пакет notification-controller может быть в составе и других систем По договоренности с Алексеем Шабалиным был добавлен этот префикс А имя speс-файла не является глобальным Оно должно быть уникальным только в рамках каталога .gear Пакеты flux2*-controller не применяется вне пакета flux2 Все они собираются в отдельные docker-образы и используются только в составе docker-образов Так что я не вижу смысла менять имя спек-файла 254219 201 kaf 2024-11-11 08:24:17 +0300 (Ответ для Anton Farygin на комментарий #197) > (In reply to ALexey Kostarev from comment #195) > > (Ответ для Anton Farygin на комментарий #191) > > > https://packages.altlinux.org/ru/sisyphus/srpms/kustomize/specfiles/ > > > 3136994127366774890 > > > > > > Замена %RELEASE% на %release выглядит как ошибка. > > > > Эта ошибка в модуле vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go > > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob; > > f=kustomize/vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go; > > h=c637ac2e1ac09baa3915905c2196c52e649757f5;hb=HEAD#l50 > > > > GitCommit: "unknown", > > > > Из за этого в бинарном коде возвращает при вызове > > kustomize version > > возвращает > > unknown > > > > Я в add-alt-release-to-GitConfig.patch > > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob;f=add-alt- > > release-to-GitConfig.patch;h=e9af1c5ae24a3b7df76726cca0ee4d0d8c231c60;hb=HEAD > > заменяю на > > GitCommit: "%RELEASE%", > > > > А затем в SPEC на текущую версию kustomize > > В этом месте должен быть sha1 git commit'а. Доброе утро https://git.altlinux.org/tasks/361320/ 1170 kustomize.git 5.4.2-alt1 Прошу прощения затупил Долго не мог понять о каком месте идет речь :-) + пытался избежать patch'а файла kustomize/vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go пытаюсь передать значение комита (vcs.revision=%commit) в переменную info, возвращаемую методом ReadBuildInfo() Сколько не копал Инет метод передачи найти не удалось :-( Так что остановился на добавление в provenance.go переменной gitCommit, передачей ей значения %commit при сборке и присвоение этого значения в Provenance.GitCommit Это будет работать как при сборке вне среды git, так и (как запрограммировано в исходном варианте) при сборке в среде git(github) при наличии элемента vcs.revision в возвращаемом значении функцией ReadBuildInfo() 254221 202 rider 2024-11-11 09:20:38 +0300 ну и совсем по мелочи - опять потерялась точка в changelog. просьба быть внимательнее и смотреть свой спекфайл перед отправкой 254223 203 kaf 2024-11-11 09:58:50 +0300 (Ответ для Anton Farygin на комментарий #202) > ну и совсем по мелочи - опять потерялась точка в changelog. > > просьба быть внимательнее и смотреть свой спекфайл перед отправкой Речь про kustomize? https://git.altlinux.org/tasks/361320/gears/1170/git?p=git;a=blob;f=.gear/kustomize.spec;h=97306e7cb22c0f584a0a929b7527c4af83b43110;hb=HEAD %changelog * Sun Nov 10 2024 Alexey Kostarev <kaf@altlinux.org> 5.4.2-alt1 - Initial build. Специально смотрел, чтобы не пропустить точку при сборке Или речь о другом SPEC? 254493 204 rider 2024-11-14 17:26:52 +0300 Всё хорошо, возможно я куда-то не туда посмотрел. Заапрувил задание. Патч с gitCommit напрашивается на отправку в upstream 260972 205 kaf 2025-03-13 14:19:15 +0300 (Ответ для ALexey Kostarev на комментарий #34) > Доброго времени суток коллеги > ... я потерял доступ к почте kaf@nevod.ru по которой был > зарегистрирован Добрый день, коллеги Судя по всему я не указал куда мне необходимо переадресовывать почту посылаемую на kaf@altlinux.org Прошу настроить переадресацию почты посылаемую на kaf@ltlinux.org на kaf@basealt.ru Заранее благодарю... 260974 206 glebfm 2025-03-13 14:41:48 +0300 (In reply to ALexey Kostarev from comment #205) > Прошу настроить переадресацию почты посылаемую на kaf@ltlinux.org на > kaf@basealt.ru Пересылка уже сейчас такая. 260975 207 kaf 2025-03-13 14:54:36 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #206) > (In reply to ALexey Kostarev from comment #205) > > Прошу настроить переадресацию почты посылаемую на kaf@ltlinux.org на > > kaf@basealt.ru > Пересылка уже сейчас такая. Добрый день Михаил Да проверил действительно работает Просто у меня одноразово от автомата не пришло письмо Возможно я ошибся с адресом Спасибо 9166 2021-01-30 17:42:29 +0300 2021-02-10 18:28:27 +0300 SSH-ключ id_ed25519.pub application/vnd.ms-publisher 104 kaf c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSUdKaHBKQmFVL2J2YW1sY0tMeGd6 R3ExQ1JKaDFHRW9WZlltNnBobHp2K2Uga2FmYWx0QGthZi5sb2NhbGRvbWFpbgo= 9167 2021-01-30 17:43:15 +0300 2023-12-25 19:12:27 +0300 GPG Key gpgkey.txt text/plain 3098 kaf LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkdBVkFiUUJFQUMxQjBs eG5kNk9GN1VVZFJkaUtCYWFMeHYwTkRmaGt3NFNrSUpVUzZLM2Z3VTkybkdXCkNwa2toNVRwWHJn Z3cyVU9wdko5VHo2cnF4SUV0QjgvY2c5QldLRFlodmdOR2ZiWXhPa3Q5UWg5aTlFc1lMVFEKaDVz YlB2T2xVY1RVV3I5NDk4MUxHTlJBT3B2TUpDRDdOWENXTFVrTEYyWHk2VEpPV01wMDc4clFEdE1F ZnJBVgpCM05iZVFzNFlmVFNUM0FRS20raDV5Mmg3QXZURGNZdkRpU015VHoxUWp5MTNneVFKWnpU WWpOTG9qazNHVTdJCnBqcldyd1BYVENkYXZVZFd4YzZjUjB4eXJoOFFVd2dqVTlCQ2Z1YzN2ejdC ZG9hZDkwbW43bm5sczJLeTlIV3MKYkV5VHVQT28wUFd6Q0luVk1BL0dHeGx4ZDJKMkQ0c0xua29W d21rZFNlVVBneitidldod2ZLcS81TmdGczJkcQpTSHQyMWlzU0Jyaks3TjRZUzZYL3A1dUM4VStP Y2FkQzVEWW5hZXI2bFVQNXJmVDNCN0NjT2lpSEtGbjFzMWpLClExcXNqTmhKcnZSOTAxbXR0VHN1 VUJSdWlwZ3BRZlFicGNzdjgzKzlMRWVXU3dlMmtweWRvM2Y0YmhVQ0RyU1oKaHZqU2NDRldiYytB RnhjU1ZXZ1VFeGlPM1hRYUhNZ0cwZnBHNm9icFRMUnc4bGJIYm8wemg2dGdRN2VBSDcyWgpBcDlT WWoyS290SFhybkVxNVJjT1U3eFg2SXZ0UHkyVVc5RzJHN0ZBQ1U2V2Q1T1liZEpNaDlqd2JTb0sv bkVZCmNQWmFFQitiYmZaclgvMWg0ZDBPdHBzZ2RpRnc3Nlozd1VUdVpGNkk0M3ZvL2VRd0hUMnNn S2g4VlFBUkFRQUIKdERSQmJHVjRaWGtnUzI5emRHRnlaWFlnS0d0aFprQnVaWFp2WkM1eWRTa2dQ R3RoWm1Gc2RFQmhiSFJzYVc1MQplQzV2Y21jK2lRSTRCQk1CQWdBaUJRSmdGUUcwQWhzREJnc0pD QWNEQWdZVkNBSUpDZ3NFRmdJREFRSWVBUUlYCmdBQUtDUkRzb1ZjWWZOV0J4SlZGRC85djhkaVFi Y2pabzBGLzRadjE3NWUwOUxYSDJCb1A0T1VXemdTeExZbXgKTWxXeWxqc2JXcHVGU3NhZ21nTUt2 ektUQ0Frem1oa3VpbEZpNTNoWkRnd0h6M2prcklxNER6WnBQaDBrUDFaQwpBc2dNb0pwZGgrUHJD UDZqWFNXL1RwYWhJdkhLRm5hNzNiNEgyUDdmVHYzUnFJWGZHdlpvcWNmM04vamQ1TjZPClYzWk9V ZElaVmVxQlVIcEY1bDlRMXVxNVk3YzJlZnBxWHp0dGttNUc0RjBDUlhlMWJNTWU3Uk12QVgzanRi OXkKcmk4WGMvOStLanVub2h1Y0x4Z0FFLzRIR0ZzbytwcVlUQ1RSQTNOSmFGSG1PSkhNTS9nakQv cXNnaTBMcDFFMgorSG41bVBjanp0OFRqUmhkQXEySDNDU1ZMYnZkdUhCTmpRejF6MFZkVnFTc2xw ODBNOXpvVzNrcGd5WWhZYnFxCjJZZ1VjTmlBanlBT25Ea0F1SmlHOVppM1llZlV1Y1pObys0NWVF UE5PdDFRZmdqcFNVL1NrajV5VExhK3llN2cKTTFiTkREaXhSamJnVlZrT0pRTFQxWStHVjJJczlS bXNOT1BmUFgrTWNtZkwrNGhGdmZHREU0NFVJMTNTcHJVUAoyV05TaG5iK0ppT3M1NDI1aTh2VzBu TFlnWHp3M0lrV09xWi9mNnZDMElaVFQ3L0FlQ0FKazhkRnc0THpHeHFTCmg5cUlEYmY2UjBjMno0 UUIzQU5nQ1g4cFpYZVlKeDdwaHJIdkg2eGY3em9mTnFHQ0tMcC93M3VEQUorcTFyOGoKNnNKY05N S21Xcm5IOXphdjRsUDhCSmtxWGtEWGovRW45S3NPaTBET2hrSUdMMTNpVVhpdURRT2tIUjVGWnBF NAp6cmtDRFFSZ0ZRRzBBUkFBc0lyTWNRVWN1YTViNXNnZ2E3VG5UNkM5TGRqbUdSR2dXa2hrd0tK SHE0c1lLUzNZCitzQkx6RTlvZWRFVm5RbWN4MXcvZ29DSlNHWVY2MEFCWUErZFZDbWNzYzdzU0lS dmNQQXYrSHlXdmtvcjE5V0IKRTdqTS9rKytmWEJmWkNtemFvVURUMFdoVDZkZEhieWx1SC9QMVRv NGFuMzZaalN0NW42aVRTVEgyUUVFQXlRagpZdEwrbWNYWTdCSW16MnpvUHQrY2p1dlRZV2xkNEFa TnIvZ0c4UU52QitKU3ZTaGxFUTFEbEFwS0cyQWdrd0JsCmthYkxFM3B4WUR2T3htZENBU0llSkF2 eXhaS2V0M1dxQ3E2dHJnVExMam90VllONXpNOVg2c3RuTEQyVnV6aEcKcUlZSGFZa3plclBSdVND VFRPR1RkZDVJWWhaeW1wUy9oRXZJeTNRQkV5Wk5jeEVxU0tXR3ZtRnQrTFpIMG8vTQp6L3dIT0w1 emdwc0lsYTNkelBEeUNyN3huN2R3SHg1L09Wa2dGVWlsdFZVaHkyMnpDY1ZrZ2JtT1ozYmxxM0JP CmRQNHZHNDhQZ2VWbGNRbjk4NE1XMEQxeHJLTHl0aE14SVhXTjBSSUtJbVBSYWF0M3NCMnp2dU5J YVJjanhvV1gKWEdpOEN3cnJxZ0ZkV3BSaEx2RkhXY1JEcUtMUU9idU5oZnowN1NicGVBbFY4RDds V3ZzSkUzSVN0UHlsSXoxUAorVGlROVFLd0tZNXRIdS9NbS9ENEVBWkpxa2JneFVWVHhjSUpJeFlO VEZHOTVVSndQM21aZEx0NUVVR3hwZ0xiCmxkZGZHY01vVDk3QUUxMnJnWnFJZ0VrN1dvVktPckRr NVNYcjhVNG5rdnZhdjJFSVRUODAwUm83Y21VQUVRRUEKQVlrQ0h3UVlBUUlBQ1FVQ1lCVUJ0QUli REFBS0NSRHNvVmNZZk5XQnhBdVhFQUN2VncyNTZSUUhQRXV1SEZIQgpiYi9BanF2NjRXVzVaTDZl OHlHR2Q3TGlpanFoa1l0YmFReFJjTkUvdGdvRmlDYkRMTlQ0VldNOUtXcmMrOFN5Cmp4Kzd3aG1p bytnbTA2aWtBdEEwTDZtVS9zTWxTbjh3M09iUE9ZNlRCSndDWnJZeSs3MU5NczhvQytYQ1lNb1oK dWw1MmlBQlpNQ3FiTnFZSmczRXVzMEMvTXdJMTVsZWJucWxFR0JFWFhPOVNPeDJ6TmJFSHdxUWVG dGNhQUozUQptWi9NNlBBUlZVZkpXQ0luVzAxUXdaOTBzcHduc0tCM04vZ0Y0c3AwOW81dW1Lb0ZW Mmx0dThDVjdhdGNJV20vCkhqRDhJYlpRV1gxbkl2TEdHM2hGTFBPS1Nma0owN2xuUXNFNEZ3UVRO Zm5oYkw5SjJ2RzJEYTBLekFnNHRxS1oKZ0FzOUp6amVIeVdtR0NiQkxCT0Z0N25JeklURCt6N0ZC azlsYXd0dVEyK0p2ZUg5Rk45c3JFQnc1YU1kT1d0ZQo0QXN6eWNwT3BTOU5NNE1QbS8vek83eTVD QUdYMjNWck9QcW5uWkhySk9kZWtzQkJiTlFnNnlDcy9RVEYxM0tLCmlQVFBuTkJybWVKdnZhNzdh QmRBRG5SRzdFRkkrMDlnTDNCSGppbEJiOGZQUkpPdEZySUIrcUp3THJqNXB1bW8KbWpnbDlwRThZ c0lhWHRBZitTVGtsOE1JRjEzT0xsRW9pZ1VVT3VkWk9OU05CTUdjUDBqWms4U1c3SjNzaWlkSQpx b2g3cTljMGt2NTNnMWNCbmtMUnQzc2xnQnMvc3hoYXFkdmgyOENuMnJLT2xZY3RLa2diM01nWGx1 d3lyWDFKCkVRNUk4MFo1ZmVGNnVFaFZLMjZoVGFkM0FnPT0KPTNpZGoKLS0tLS1FTkQgUEdQIFBV QkxJQyBLRVkgQkxPQ0stLS0tLQo= 9177 2021-02-03 21:49:35 +0300 2021-02-03 21:49:35 +0300 Новый GPG-ключ для E-mall kaf@altlinux.org gpgkey_kaf@altlinux.org text/plain 3074 kaf LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkdBYTRoNEJFQURrTHV1 NjNrMTllMm1Zc29QMnhLSFhIOGM2VW1TV3BJQXphQ3FTdjNWekNZczNtK2Y3Ck9TZmRoWUhBWWNK dWNjclYxM2xiN2dMcVd3bVNIR25oTWNmcXJlTnQ5SkN0NTkvazJuREk3TEJnVURCaHBGc3kKOVg1 bWRCSFhhTHdvYjkyV0FJTDI3ZzZnZGY5OUhpczl5MzZSTUNQTmZKNVluNStHMnpackh0SG1hN1lw YllWVQp3b0RWblVPNEx2a1ZZMkNoVmkra3JCMlQzdWJ5VWEyRW1ZbkF0R0pMclpuY0MyMVFLWExT WnVocEhwczFSeUdpCm9MNWp1RjRSVHN2YTFHNysrSlNrV3JmR1BmU2M1QjJidnJ0RGhsVThmQ1px eUxQNVlJRFlMYVB0am95eitYaUkKL3ZyTUVJamlycGpxeHlDUVpGdzVaUkZRSGRWRTcybVFLNEFn NENlS3FRVkljTkVlb2xHMVVxaFFOT2FRMDBEVAo0NnFwQTRpSFRSTTVtUDl5MW1ZTENVREk0SlQ4 dFU5VG01TUxoSTlJbFpCV1hlRG55NTRDRlR1TUFEM3B1WGNYCjh6cWRqMEFHRS84VDRJTjBZaDhF cERVaUtJRzdOZzZCSWJXLzlzQnJOSll4VEFlSmdQaWFvUUhOM0xnVDJRNVYKUnBDc3FUZmJLemxu TEd2SmhnT0dRYTRpSVFvOUMwQ3NCcVZSN1d5dzlxTEplZXBzb2lKU0JvTzQrWXNwYjBmRApveTh0 M090ZThnTHRFbFozbVhmSGlRMEQ4eFB0WUQzaFRjUXU0SWZNQ1dmV2s5aGI4eTR1eEVZckJhd1Zh YklmCkQ2ZmVBcE9JMEVZbmFiOUV1MEJaR0dYelcyMGZYNm5Md2U2VlFPWE9XMndZTXRkU2xMa2hz WmxndXdBUkFRQUIKdENKQmJHVjRaWGtnUzI5emRHRnlaWFlnUEd0aFprQmhiSFJzYVc1MWVDNXZj bWMraVFJNEJCTUJBZ0FpQlFKZwpHdUllQWhzREJnc0pDQWNEQWdZVkNBSUpDZ3NFRmdJREFRSWVB UUlYZ0FBS0NSQU4wN1Q1RW55cEJnRTRELzlBCm5Wb1VBckdMclpxWU5mOXlvYXNUY0t1VGRHQmNz WkpOQ2w2WTZIZlVOalRyYjY5czZOK0RmbFMvczNGcjJqVTYKNFBvR3dXRnVBU0o4cmlvaEdhV3R1 YkZnYVE3KzFuM0dUamVMZGtOR3VLOFp6Qk9VMm1qdUhPeS9CQzVReTVUWgpmbVJSWno3RFgzZHNl T2dsUXJxK3cyYTJYQUo3bVI2cVhUdDBDNjZaNmZuRVc3eXpTWTdWYVF3WGVGczFBQXJWCkVJVDNM TG5yYUQ5dlA0SUQwRWRjVklWNzVhVnJYTkVUMU9qbGVBZnNIekU0a2pSZi94YXhXOUgycmU2TUFJ cUgKZi9WQnpVTWIzK3N6aS83b21OZGo1VGxVVytLYU40TnpSZG9aNy9jZ2E1SkRORVB6NEsvUnlV WFFwOVVRV2dnQwpzMjJuYkxXNTJOL3BCL3J2WXNIZXowUHNuSmMvNFo5VzJoUjVtcjVxM2pPT1E2 aWZxS1JBUFRHTWdZZnRpWXFPClo4dUlWUzZCSkRkV1V4OFkvVWFuOENjQXFRL2I3clAxVng1Wi9E aml2MmFNZ0NYVE5iL3JQQmFsMU5xY1Jta2wKSnFIakV4WU0yRWoyd1dwTGRnbGxTY0duaWZtMmYv dmNGR001QjhUbGg1MG54THZ4bzdKRk9SZmNpZXgvakpGUgpiY1NITkV2cW1OaUtXWnhadUYyMFR3 cTFYR1JyZGZha1BDcnJ5UVc3UE4vS1F6c1orM3pDdzFvQmNCWFBOeHF6ClB6cytkcEV2OXNxUDhJ U0NhbWE0MVBydXdCclFoWjBUeFJUSTRSZlh3U1dmSUp0NGRkNzFOdXJvbHA5RERCd1kKL2Z4VmZs SHlranZFemFhdmVKdFU5WjVzbHI2T3F4cXF4MFR2cjRUZ3dya0NEUVJnR3VJZUFSQUFydGFjKzlu Sgp2TUorR0IwRnA3Mm1ucFNSOHdiRHNDSVY2Q1Z6VUNQVE5EVG12aTJTc2ZCWjFiNnZLMFRSVFVT eWJZYVNEVHQyCkxTZzBpNkVpUUZ6bERCd1hkbDc2WFErbGR0VE5yM2VuRjVtUHVFdEEzU0prRGpM L2lLZ0RJT2t2bDVtSnZlT0gKSUo5cFBPMFZzOVhWUnFQdXM4UDV5ZElMcFpnRllDZ3cyaEU3UHJs MDNwOGxmT0dhcVJ5L1hKeGZmR3Z3V3F1Mwo1SDRXWG1QY2lRQWhDUkV6akJPOUxka1lXZTV1UzVU YWQ2Q0IwWDlGYzJscWRyTm5wMlEvdFNMTkdKK1RxMFk1Ci9peTJkMGVjZDhySFAwdG56ZGZsTUw1 Ukg1U24reldXb0hXRGFXQmVTQVZZRU9nQ0dBRHEwME9EeVgybkgyMCsKbkVoYUdOL2w4VGt4RXM0 MS93VGVad1o1T0Mrc1JZQnkrcEx2TnFyZ2xWNjZ2WURLM2tHUklBamlYalZvMEg4Mgp0eWczbVVy RytKdHU4cHB4V0FKOTZhSHc4dGdBQ3VGRUJaYVBEbHR1QkNkSitaQnM4dEsrYSthZFJlWTltcWx5 CnB2VGNSL1RhdVhSWk5aY3FHVkFqbjRsYUxmNkRFbVBiTkdDYXpjT1RneGVMTm5Pakt1MmtueFJZ ZTNWQVNNajIKK0pKMCsySXRoU3VBVldEcnZvdVVEK08yNUQrK1BEVDQ0ZDBjQXZ4R1BTdDNPNHpE dUoxSDdQQW9ERHpZamdzNApBR0JDMCtabERJc29aUU1hcEthOHZEZ1hIWDhydkFDZkFrMUxtMVAv ZWxIU0pjeHoyWFFvSDBxMzhlZERqSVBUCk50Um1mODdLOXhrTUQ2RFdQR3dTVi84Tjk5WlV3YUdE ajVFQUVRRUFBWWtDSHdRWUFRSUFDUVVDWUJyaUhnSWIKREFBS0NSQU4wN1Q1RW55cEJrM3NFQURW a2xPQ29hRHBibkY3NnRzODFuOEFPdk90SllweUxiY2xrMXFuSCtkTwpySmNMSWlVTEFtVm5wM1da YmlVZVBXb2pNUkxBZGI1RjF4YldDbmF0QzdzRGdGMzUvZlA3b24yaWZsKzFOcnhGCjFxcVloc2tE dzU2aHFNdGh5azRXdDRWS08ydlRuZjBxQ0lIRmJ4QndKaUp6Yy9JM1lTbDBveFRCd0phc2NRVHUK cGFnQVd2ZU94MzFNQ3JnejBFZ09NWG9UWndCbmwrcUI3Zm9ybEhIR29ESUhXV0RlSjBpNHBzalZh VzVBcDBlLwpnSFBWZG5HUXpyWGZETi84cW5YRWlPWm5NZWFEam1IeHBoUGdNaVVwTW4vTjFBam1B bmdkSktLcVJWa09FUk94CkhqMHptd2VwUEF4SnJDN0VPMkErSTJjVC9rTDFDRzVkdEh1VnVIc210 OVh5ZWJFRHVXUGtpRG9hcFI0OE1LZ2EKM1pORE5rSEJ2V28veS9nYnJZbnFPN1ZOc0ZaSXBDTGd2 MncxU1YvQ2dOZE9QZjVPUVkzVnJ4T0JHOEprbGl6RwpWSFRqaUFJNjBzamZMMDQyd0NtUEFWM1d3 QkdlVG5Mc2VPNVRmOExJOThRMVdYYzhCQkpGTzBmbXBzVWl2VUpTCmNOV0xXZTFoQ09LSCtoRGwy bzBDSWFsZVlZbm90VEEvUzcyMEFtQ2k2b2ZEWlBQdmUxTDNoeHpSL3JSR2lmK2kKVTdNaTA5Nzkw TUVlZG9ZR1htZW1reWV6b0xCQWtuZzB6cTBoTlZ2WHpmQmoweXUrbzlXcWdJRE5RODNKSFY4Zwpj MlEyVkh5eVVtdDZtUUxUUFpWaEl6ODF5WHdObWdCeWJVcTBMMndoSWhKWEhBNEJmNEJyQ01BWS92 dWVxVHBZCkxnPT0KPWxDc1EKLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxPQ0stLS0tLQo= 9191 2021-02-10 18:28:27 +0300 2021-02-10 18:28:27 +0300 Новый ssh-ключ id_ed25519.pub application/vnd.ms-publisher 104 kaf c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSUtJN1R4MVhXSTIxN1o4VlcwYmh3 c0tjRlpud0diT0xPVyt1TlpFZWZRM2gga2FmYWx0QGthZi5sb2NhbGRvbWFpbgo= 9198 2021-02-16 16:25:14 +0300 2021-02-16 16:25:14 +0300 Подписанный новый ssh-ключ id_ed25519.pub.asc text/plain 801 kaf LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSWNCQUFCQWdBR0JRSmdLOFlUQUFvSkVB M1R0UGtTZktrR083UVFBSUdVZGZtM2M3VjNZdUZVTks2d2Z4RngKdk41SnRUV1JJSHU3V0lTeEZU N3E5dlBjcnQzSWlPTFB6T1BKVCtvOWNaejc4OVlqTk9CbkFqTVVEaElyaGkzcgp6b2V4Ti8zY3FG NkhZVStweHRQbVBJbUg3bDIzNXZUdjJnY3liMDl4eDdrSGFSbXNPN0hJZks1b25OMkdzQmhICnF1 QmowRkVLcUl2Wml2OHp4TXlVbmcwcStVUVFaeDZkMVFIZDI5Tngrd1RRWmJzZ0p4MjJkdTA3Rkk3 YkdXQk8KQW9zSlNhR0VCMHp1cWlYMURMQVUzeU5Zc29ncXpOSTc1ejhwV1dvakRrOVBBaTc3TDJK U1NVQUFtbDFuNVhaLwpuUzJCMVl4WTg4eVlEZ0JWZTdBdDNNcm1zSzArQklsckRJMWFscDZScGJY bWJMc0hoM2RuUGFjVmZhc3JNaUtiClhLSU9RQzA3N2lCZ0wxVUYwa3lMT3Z3VGxkRm05WjcreXNU UWt2WkNVYW5CcnlCc3VKZXI5SjNSZXZPZm5kUksKWDdCaGtLWGJBMDFSUkJUcUtUNFNYVStsUitJ YnlYMVh5ZGtBZmxIUFZXS21kQTdjUmFpSWJ0UHlpck1LTFVGcgpHZHdUaWtSK3hGOXArMkxWeTI3 Q1VReGtESEJZcUdiSXRBN2Q3emRVUmd5UzFSS0NFblg2anhqN1ZwN28rOU1xCm5QMyt3Q3d4V3da dFM1VXJEdGZDV0pQdTVndzh2OXVCWEhuelJzODFnald4ZFNjam9vdDdsQnFaWkU2TDRKMUUKcmVy cFBaaFE0OWdGUmVUeTEwM0RXRVp6Z2pKa3UrVkZ0dzlIZ3pGdHFLTksrcVZkVFFjUzFsSWc1OE5C YjhibQprL2V0ekQ0ZnFtcm00ZkZuaHdqWAo9cklMYQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0t LS0K