Created attachment 17102 [details]
rsa-ключ

Created attachment 17103 [details]
gpg-ключ

Принимаю кандидата

Ментор есть, ключи в порядке.
T/J/S -> 1.3.

Кандидат готов к вступлению, прошу
* Создать email alias для кандидата
* Зарегистрировать SSH-ключ кандидата в gitery.alt.

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

T/J/S -> 2.3.

Готов собирать пакеты. Прошу предоставить доступ к сборочнице.

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

T/J/S -> 3.6.

К настоящему моменту опакетил:
1) grip-grab - https://packages.altlinux.org/ru/tasks/370633/
тест на сборочнице завершился успешно
2) gcli - https://packages.altlinux.org/ru/tasks/370563/
тест на сборочнице завершился успешно
3) oauth2-proxy - https://packages.altlinux.org/ru/tasks/370633/
тест на сборочнице завершился успешно

Обновил три пакета в одном задании (тест сборочницы пройден, одобрено shaba):
1) prometheus
2) prometheus-alertmanager
3) prometheus-snmp_exporter
https://packages.altlinux.org/ru/tasks/375085/

В качестве тренировки обновил пакет haproxy^ в сборочнице собрался для всех архитектур, но получил ошибку Gears inheritance check
https://packages.altlinux.org/ru/tasks/376303/

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

1) grip-grab
Не надо давать такие URL.
Vcs: git@github.com:alexpasmantier/grip-grab.git
Он подразумевает наличие аккаунта на github.
Надо указывать URL  с анонимным доступом.

2) prometheus-snmp_exporter
Ошибка
Vcs: https://{%import_path}.git

3) haproxy
напутаны commit message и вводят в заблуждение. Доверьте командам
git merge
git commit
самим написать сообщение о комите.

Выдан апрув на gcli, auth2-proxy.

Поправил:
Vcs:grib-grab https://packages.altlinux.org/ru/tasks/370681/
Vcs:prometheus-snmp_exporter https://packages.altlinux.org/ru/tasks/375085/
Историю коммитов:haproxy https://packages.altlinux.org/ru/tasks/376303/

Также собрал в качестве самообучения mkcert (программа висела в моём личном чек-листе с прошлого года, но Виталий Чикунов опередил меня на несколько месяцев):
https://packages.altlinux.org/tasks/376377
(но сборка для всех архитектур успешна)

haproxy собираем только LTS, поэтому 3.1 пожалуйста не собирай.

(Ответ для Artyom на комментарий #11)
> Поправил:
> Vcs:grib-grab https://packages.altlinux.org/ru/tasks/370681/
> Vcs:prometheus-snmp_exporter https://packages.altlinux.org/ru/tasks/375085/
> Историю коммитов:haproxy https://packages.altlinux.org/ru/tasks/376303/
> 
> Также собрал в качестве самообучения mkcert (программа висела в моём личном
> чек-листе с прошлого года, но Виталий Чикунов опередил меня на несколько
> месяцев):
> https://packages.altlinux.org/tasks/376377
> (но сборка для всех архитектур успешна)

в %build такого делать не надо.
/usr/src/RPM/BUILD/mkcert-1.4.4/.build/bin/mkcert -version

PS: задание можно удалить :)

Кандидат готов собирать пакеты в сизиф.
Прошу призвать рецензента.

Обновил четыре пакета:
- influxdb3
- oauth2-proxy
- gcli
- grip-grab
https://packages.altlinux.org/ru/tasks/393465/

Три первых - стандартное обновление версий. 
Четвёртый (grip-grab) решил обновить в связи с обновление rpm-build-rust и странички https://www.altlinux.org/RPM/Rust. Последнюю обновлял при участии @geochip и хочу добавить grip-grab в качестве примера сборки пакета, в котором имя пакета не совпадает с названием бинарника.

Обновил версию prometheus:
https://packages.altlinux.org/ru/tasks/393522/

Опакетил дебаггер под x64_86 для разработки на Rust:
https://packages.altlinux.org/ru/tasks/393944/

Обновил пакет promu.git
https://packages.altlinux.org/ru/tasks/394486/

Заодно написал руководство по сборке на Golang:
https://www.altlinux.org/RPM/Golang

(In reply to writers@altlinux.org from comment #18)
> Обновил пакет promu.git
> https://packages.altlinux.org/ru/tasks/394486/
> 
> Заодно написал руководство по сборке на Golang:
> https://www.altlinux.org/RPM/Golang

Хорошее руководство. Стоит добавить в него BuildRequires: /proc, потому что без /proc модули не соберутся.

10 в(Ответ для Andrey Cherepanov на комментарий #19)
> Хорошее руководство. Стоит добавить в него BuildRequires: /proc, потому что
> без /proc модули не соберутся.

10 августа 2023 года Алексей Шабалин установил в пакете golang зависимость 'Requires: /proc'. Таким образом, после этого в пакетах на golang прописывать BuildRequires: /proc не нужно.

(Ответ для Andrey Cherepanov на комментарий #19)
> без /proc модули не соберутся.

Обновил: добавил раздел "Сборка на локальном компьютере"

Добавляю systemd service и autocomplete для oauth2-proxy:
https://packages.altlinux.org/ru/tasks/394630/

Опакечиваю discovery-service-rs, который переписал с Go на Rust для проекта Alt Orchestra:
https://packages.altlinux.org/ru/tasks/395633/

взял на себя кандидата, начинаю review.

по новой спецификации стадия review = 4.2

Артём, пока я смотрю ваши проекты - соберите пожалуйста какую-то библиотеку в соответствии с SharedLibsPolicy. Можно из FTBFS или новую.
https://git.altlinux.org/beehive/logs/Sisyphus-x86_64/latest/error/

https://git.altlinux.org/tasks/414682/gears/200/git?p=git;a=commitdiff;h=94fd5290609d3e0fa52fb249d1b69560bd32b630

непонятно зачем делается такое изменение ? в commit message ничего не написано, а по факту вендоринг бинарей.

В этом же influexdb в .gear/rules делает дифф:
 3 diff: v@version@:. .

в него попадает всё дерево, надо исключить то, что не должно быть в diff.

https://packages.altlinux.org/ru/tasks/417869/
вендоринг лучше таскать тарболлом а не патчем. а в .gear/rules делать exclude для patch для .gear, что бы ваши изменения в проекте были чистые в патче.

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


[00:00:03] + echo 'Patch #0 (sops-3.12.1-alt1.patch):'
[00:00:03] Patch #0 (sops-3.12.1-alt1.patch):
[00:00:03] + /usr/bin/patch -p1
[00:00:03] patching file .gear/rules
[00:00:03] patching file .gear/sops.spec
[00:00:03] patching file .gear/tags/731259fd5f7ca60068e9f4211de6d34a9e43d88c
[00:00:03] patching file .gear/tags/list
[00:00:03] patching file .gear/upstream/remotes
[00:00:03] patching file .github/workflows/cli.yml
[00:00:03] patching file .github/workflows/codeql.yml
[00:00:03] patching file .github/workflows/release.yml
[00:00:03] patching file cmd/sops/edit.go
[00:00:03] patching file cmd/sops/encrypt.go
[00:00:03] patching file cmd/sops/main.go
[00:00:03] patching file cmd/sops/set.go
[00:00:03] patching file functional-tests/Cargo.lock
[00:00:03] patching file functional-tests/Cargo.toml
[00:00:03] patching file go.mod
[00:00:03] patching file go.sum
[00:00:03] patching file vendor/cel.dev/expr/.bazelversion
[00:00:03] patching file vendor/cel.dev/expr/.gitattributes
[00:00:03] patching file vendor/cel.dev/expr/.gitignore
[00:00:03] patching file vendor/cel.dev/expr/BUILD.bazel
[00:00:03] patching file vendor/cel.dev/expr/CODE_OF_CONDUCT.md
[00:00:03] patching file vendor/cel.dev/expr/CONTRIBUTING.md
[00:00:03] patching file vendor/cel.dev/expr/GOVERNANCE.md
[00:00:03] patching file vendor/cel.dev/expr/LICENSE
[00:00:03] patching file vendor/cel.dev/expr/MAINTAINERS.md

(Ответ для Anton Farygin на комментарий #28)
> В этом же influexdb в .gear/rules делает дифф:
>  3 diff: v@version@:. .
> 
> в него попадает всё дерево, надо исключить то, что не должно быть в diff.

Спасибо за комментарий!
Коротко по каждому пункту:
1. Библиотека с SharedLibPolicy:
https://packages.altlinux.org/ru/tasks/418756/

2. В коммите influxdb3 дал развёрнутый комментарий, почему добавлены бинарники:
https://git.altlinux.org/people/writers/packages/?p=influxdb3.git&a=commit&h=dda32145d13bf3c97e98e4bb42786dec724b0cd2

3. exclude там же добавил, но пока не отправил в gyle, так как хотел посоветоваться. У меня появилась идея сделать так:
tar: v@version@:. exclude=.github/** exclude=docker/** exclude=Dockerfile exclude=Dockerfile.dockerignore exclude=.circleci/** exclude=.cloude/**
diff: v@version@:. . exclude=.gear/**
Это не чересчур? Проверял сборку на x86_64, всё собирается, в tar исключённые каталоги не попадают. 

4. В моих пакетах diff в rules часто существует именно для того, чтобы накатить папку vendor через патч, в Golang и Rust проектах. Кажется, что так делать достаточно удобно. Кроме того, заметил, что по такому же принципу собирается огромное количество пакетов на packages.altlinux.org. Попробовал найти связанные с этим политики, но не нашёл. На размер tar разница в подходах не влияет... Может быть разрешите продолжить такую практику?

(Ответ для writers@altlinux.org на комментарий #31)
> (Ответ для Anton Farygin на комментарий #28)
> > В этом же influexdb в .gear/rules делает дифф:
> >  3 diff: v@version@:. .
> > 
> > в него попадает всё дерево, надо исключить то, что не должно быть в diff.
> 
> Спасибо за комментарий!
> Коротко по каждому пункту:
> 1. Библиотека с SharedLibPolicy:
> https://packages.altlinux.org/ru/tasks/418756/

Почти всё хорошо, но вот это:
+Url: https://github.com/google/sentencepiece
+Vcs: %url.git

зачем использовать макросы непонятно.
Парсерам spec придётся делать лишние операции для добывания адреса. И сейчас все парсеры умеют понимать что если URL идёт на github, то Vcs не обязателен. Просто не указывайте его, а если указываете, то без макросов.

> 
> 2. В коммите influxdb3 дал развёрнутый комментарий, почему добавлены
> бинарники:
> https://git.altlinux.org/people/writers/packages/?p=influxdb3.
> git&a=commit&h=dda32145d13bf3c97e98e4bb42786dec724b0cd2

Это очень плохая практика, лучше скачать исходники и собрать их в проекте.

> 
> 3. exclude там же добавил, но пока не отправил в gyle, так как хотел
> посоветоваться. У меня появилась идея сделать так:
> tar: v@version@:. exclude=.github/** exclude=docker/** exclude=Dockerfile
> exclude=Dockerfile.dockerignore exclude=.circleci/** exclude=.cloude/**
> diff: v@version@:. . exclude=.gear/**
> Это не чересчур? Проверял сборку на x86_64, всё собирается, в tar
> исключённые каталоги не попадают. 

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


> 
> 4. В моих пакетах diff в rules часто существует именно для того, чтобы
> накатить папку vendor через патч, в Golang и Rust проектах. Кажется, что так
> делать достаточно удобно. Кроме того, заметил, что по такому же принципу
> собирается огромное количество пакетов на packages.altlinux.org. Попробовал
> найти связанные с этим политики, но не нашёл. На размер tar разница в
> подходах не влияет... Может быть разрешите продолжить такую практику?

Надо зафиксировать политику что так делать плохо. плоха практика тем, что сложнее анализировать сделанные вами изменения, в том числе не только нам но и людям со стороны.

- sentencepiece пересобрал без Vcs
https://packages.altlinux.org/ru/tasks/418756/

- influxdb3
https://packages.altlinux.org/ru/tasks/414682/
Поправил rules, vendor теперь добавляется через tar. 

Но с бинарниками проблема. Просто скачать исходники datafusion-udf-wasm и собрать их в проекте пока не получится: здесь всё упирается в wasm32-wasip2 - очень проблемную зависимость для rustc, собрать которую для altlinux пока не получилось. 

- насчёт vendor -> tar мысль понял. Но у меня почти все пакеты на Rust и Golang и собраны по принципу накатывания vendor через diff - потихоньку буду пересобирать по новому принципу.

(Ответ для writers@altlinux.org на комментарий #33)
> - sentencepiece пересобрал без Vcs
> https://packages.altlinux.org/ru/tasks/418756/
> 
> - influxdb3
> https://packages.altlinux.org/ru/tasks/414682/
> Поправил rules, vendor теперь добавляется через tar. 
> 
> Но с бинарниками проблема. Просто скачать исходники datafusion-udf-wasm и
> собрать их в проекте пока не получится: здесь всё упирается в wasm32-wasip2
> - очень проблемную зависимость для rustc, собрать которую для altlinux пока
> не получилось. 

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

> 
> - насчёт vendor -> tar мысль понял. Но у меня почти все пакеты на Rust и
> Golang и собраны по принципу накатывания vendor через diff - потихоньку буду
> пересобирать по новому принципу.

хорошо.

(Ответ для Anton Farygin на комментарий #34)
> ну я не готов аппрувить такой пакет, надо всё-таки попытаться. а в чём там
> конкретно проблема ?

Извиняюсь, неправильно выразился. Здесь скорее речь про трудозатратность, нужно сперва собирать wasi-sdk с рекурсивными зависимостями, а потом лезть в сборку Rust. Я как-то хотел этим заняться, когда были проблемы с плагинами для Zed, но передумал. Очень проблемную здесь скорее в том плане, что в разных проектах иногда всплывает необходимость в пакете wasm32-wasip2, но никто пока за него не взялся.

(Ответ для Anton Farygin на комментарий #32)
> +Url: https://github.com/google/sentencepiece
> +Vcs: %url.git
> 
> зачем использовать макросы непонятно.
> Парсерам spec придётся делать лишние операции для добывания адреса. И сейчас
> все парсеры умеют понимать что если URL идёт на github, то Vcs не
> обязателен. Просто не указывайте его, а если указываете, то без макросов.

  Так советовал классик: https://bugzilla.altlinux.org/show_bug.cgi?id=50906#c16

(Ответ для Andrew Vasilyev на комментарий #36)
> (Ответ для Anton Farygin на комментарий #32)
> > +Url: https://github.com/google/sentencepiece
> > +Vcs: %url.git
> > 
> > зачем использовать макросы непонятно.
> > Парсерам spec придётся делать лишние операции для добывания адреса. И сейчас
> > все парсеры умеют понимать что если URL идёт на github, то Vcs не
> > обязателен. Просто не указывайте его, а если указываете, то без макросов.
> 
>   Так советовал классик:
> https://bugzilla.altlinux.org/show_bug.cgi?id=50906#c16

Классики тоже иногда ошибаются ;)

Очень много классиков и у каждого особое мнение.

Подготовил обновление двух пакетов:
https://packages.altlinux.org/ru/tasks/418882/
https://packages.altlinux.org/ru/tasks/418897/

(Ответ для writers@altlinux.org на комментарий #38)
> Очень много классиков и у каждого особое мнение.
> 
> Подготовил обновление двух пакетов:
> https://packages.altlinux.org/ru/tasks/418882/
> https://packages.altlinux.org/ru/tasks/418897/

Спасибо, заапрувил.

(Ответ для writers@altlinux.org на комментарий #35)
> (Ответ для Anton Farygin на комментарий #34)
> > ну я не готов аппрувить такой пакет, надо всё-таки попытаться. а в чём там
> > конкретно проблема ?
> 
> Извиняюсь, неправильно выразился. Здесь скорее речь про трудозатратность,
> нужно сперва собирать wasi-sdk с рекурсивными зависимостями, а потом лезть в
> сборку Rust. Я как-то хотел этим заняться, когда были проблемы с плагинами
> для Zed, но передумал. Очень проблемную здесь скорее в том плане, что в
> разных проектах иногда всплывает необходимость в пакете wasm32-wasip2, но
> никто пока за него не взялся.

да, но если много где нужно то наверное осмысленно влезть.

в пакете oauth2-proxy

775 для %_localstatedir/%name не слишком ?

  68 %dir %attr(775, root, %name) %_localstatedir/%name

(Ответ для Anton Farygin на комментарий #41)
> в пакете oauth2-proxy
> 
> 775 для %_localstatedir/%name не слишком ?
> 
>   68 %dir %attr(775, root, %name) %_localstatedir/%name

Погорячился, обновил пакет в задании:
https://packages.altlinux.org/ru/tasks/418931/

изменение прав на этот каталог - важная информация для пользователей/администраторов. надо обязательно упоминать такие изменения в changelog

(Ответ для Anton Farygin на комментарий #43)
> изменение прав на этот каталог - важная информация для
> пользователей/администраторов. надо обязательно упоминать такие изменения в
> changelog

Поправил
https://packages.altlinux.org/tasks/418931

(Ответ для writers@altlinux.org на комментарий #44)
> (Ответ для Anton Farygin на комментарий #43)
> > изменение прав на этот каталог - важная информация для
> > пользователей/администраторов. надо обязательно упоминать такие изменения в
> > changelog
> 
> Поправил
> https://packages.altlinux.org/tasks/418931

спасибо, заапрувил.

prometheus:
1) по умолчанию процесс слушает на всех адресах, это плохо. надо ограничить локалхостом.
2) BuildRequires: golang >= 1.21 но в go.mod требуется golang 1.24 и выше
3) Харденинг в юните можно улучшить.
4) prometheus.tmpfiles d /run/prometheus 0775 root prometheus - непонятно зачем такие широкие права. 0750 prometheus prometheus было бы достаточно по идее
5) права доступа к конфигам, содержащим приватную информацию - слишком широкие.
6) в /var/lib/prometheus тоже с правами слишком вольготно.

судя по https://packages.altlinux.org/ru/tasks/418931/fixes/ надо ещё в p11 обновление закинуть

(Ответ для Anton Farygin на комментарий #47)
> судя по https://packages.altlinux.org/ru/tasks/418931/fixes/ надо ещё в p11
> обновление закинуть

В p11 отправил: https://packages.altlinux.org/ru/tasks/419192/
Prometheus в работе

Собираю prometheus в задании:
https://packages.altlinux.org/ru/tasks/419241/

Но есть затруднение. Сейчас в проекте создаётся prebuilt frontend, так как нода вендорит архитектурно зависимые бинарники в качестве исходников. После make assets локально у меня появляются каталоги web/ui/node_modules, web/ui/mantine-ui/node_modules, web/ui/react-app/node_modules, web/ui/static

По факту нужен только каталог static. 

Каталоги */node_modules сейчас для сборки в хешере вообще не нужны. Но они сохранены в истории git исторически, когда, наверное, не было в исходниках бинарных файлов и ui собирали в хешере (в upsteam такого нет). 

В связи с этим рассматриваю два варианта:
1) после выполнения make assets вообще удалить каталоги node_modules отдельным коммитом (думаю сделать так);
2) перенести node_modules в отдельные source-tar, но не понимаю, зачем так делать, если эти source-файлы не нужны в сборке (разве только для чистоты истории и некой прозрачности сборки пакетов)

(Ответ для writers@altlinux.org на комментарий #49)
> Собираю prometheus в задании:
> https://packages.altlinux.org/ru/tasks/419241/
> 
> Но есть затруднение. Сейчас в проекте создаётся prebuilt frontend, так как
> нода вендорит архитектурно зависимые бинарники в качестве исходников. После
> make assets локально у меня появляются каталоги web/ui/node_modules,
> web/ui/mantine-ui/node_modules, web/ui/react-app/node_modules, web/ui/static

Т.е. - в проекте собирается на какой-то локальной машине web UI и уже собранный перекладывается в RPM ? а можно ли саму сборку делать в hasher на серверной стороне, завендорив только нужные зависимости ?

(Ответ для Anton Farygin на комментарий #50)
> Т.е. - в проекте собирается на какой-то локальной машине web UI и уже
> собранный перекладывается в RPM ? а можно ли саму сборку делать в hasher на
> серверной стороне, завендорив только нужные зависимости ?

Да. Как я понимаю ситуацию, проблема всего npm и nodejs в том, что в зависящих от них проектах вендоринг практически всегда предполагает скачивание архитектурно-зависимых бинарников. Редко когда обходится без них. Поэтому проекты nodejs у нас так не любят. В проектах prometheus и prometheus-alertmanager во время вендоринга скачиваются именно такие бинарники. Без них сборка frontend не проходит.

То есть после такого "вендоринга" сборочница gyle соберёт prometheus и alertmanager только на той архитектуре, на какой делался вендоринг. 

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

(Ответ для writers@altlinux.org на комментарий #52)
> То есть после такого "вендоринга" сборочница gyle соберёт prometheus и
> alertmanager только на той архитектуре, на какой делался вендоринг. 
> 
> Инструменты npm и их альтернативы не предлагают решение этому, так как
> разработчики вообще не видят проблемы в таком порядке вещей.

да, это понятно. но я бы всё-таки завендорил всё по максимум а саму сборку сделал в hasher на girar.

Стоит ли это того? 

В папке static с собранным фронтэндом все файлы текстовые, за исключением пары ttf и icon. Их легко проверить, прочитать, понять. 

С другой стороны, вендоринг, который из-за мультиархитектурности увеличивает сложность сборки в геометрической прогрессии. В проекте prometheus три папки node_modules, чтобы случайно архитектурные файлы не перетёрли друг друга, желательно делать source под каждую архитектуру. В итоге теоретически получаем девять каталогов для tar source. И это при том, что не факт npm ci с флагом --cpu работает как надо.

Вопрос с воспроизводимостью сборки.

(Ответ для writers@altlinux.org на комментарий #54)
> Стоит ли это того? 
> 
> В папке static с собранным фронтэндом все файлы текстовые, за исключением
> пары ttf и icon. Их легко проверить, прочитать, понять. 
А они являются архитектурно независимыми? Подозреваю, что да, но было бы неплохо явно это доказать.

(Ответ для writers@altlinux.org на комментарий #52)
> То есть после такого "вендоринга" сборочница gyle соберёт prometheus и
> alertmanager только на той архитектуре, на какой делался вендоринг.

Нет, не обязательно. На машине разработчика в архитектурно зависимой части готовится сборка "сайта" (всякие webpack, sass и тому подобное). Этот собранный .js в общем-то тоже "в исходном" виде, просто склеенный из кучи других js. И он уже позволяет собрать пакет на любых архитектуках, потому-что архитектуро-зависимая часть сборки этого js пропускается.

Я не говорю что это хорошо, используется как обходное решение, потому что красивого, быстрого и удобного на сегодня нет.
 
> 
> Инструменты npm и их альтернативы не предлагают решение этому, так как
> разработчики вообще не видят проблемы в таком порядке вещей.

может быть тогда хотя бы хуки для zoryn положить в репозиторий, которые это будут делать при обновлении версии ?

Там есть небольшая изоляция окружения. конечно не панацея, но всё-таки.

Выключил падение fish из-за ошибки в тестах - он периодически падает сейчас в сборочнице из-за этого.

https://packages.altlinux.org/ru/tasks/421848/

(Ответ для writers@altlinux.org на комментарий #59)
> Выключил падение fish из-за ошибки в тестах - он периодически падает сейчас
> в сборочнице из-за этого.
> 
> https://packages.altlinux.org/ru/tasks/421848/

Лучше попробовать исправить флапающие тесты.

(Ответ для Anton Farygin на комментарий #60)
> Лучше попробовать исправить флапающие тесты.

Я достаточно долго пытался решить проблему тестов в fish. Но они нестабильны, завязаны на какие-то терминальные приложения разработчиков, страдают от многопоточности и прочего. 

Сами разработчики называют их нестабильными (flakey)
https://github.com/fish-shell/fish-shell/blob/4.7.1/tests/checks/tmux-complete.fish#L4-L5

Причём если я сейчас отключу этот конкретный тест, нет гарантии, что в какой-то момент не упадёт другой тест, и мы снова увидим оповещение beekeeper.

(Ответ для Anton Farygin на комментарий #60)
> (Ответ для writers@altlinux.org на комментарий #59)
> > Выключил падение fish из-за ошибки в тестах - он периодически падает сейчас
> > в сборочнице из-за этого.
> > 
> > https://packages.altlinux.org/ru/tasks/421848/
> 
> Лучше попробовать исправить флапающие тесты.
Привет!

Это достаточно частая проблема для утилит с тестами пишущими что-либо в потоки ввода/вывода. Порой проблема проявляется случайно и не воспроизводится вручную ни локально ни на сборочнице. Иногда падающие тесты связаны каким-то образом с версией компилятора (привет nushell). По-моему опыту, проще либо обновить пакет (если возможно) либо определить конкретную категорию тестов которая работает нестабильно, проверить локально и если проблем нет, то лучше исключить эти тесты. Иначе можно потратить в пустую недели водя вилами по воде.

Полагаю падающие тесты fish могут иметь схожую природу с такими же тестами из nushell... Возможно в сборочную среду стоит добавить дополнительные пакеты для работы с unicode и цветным текстом, но пока у меня нет конкретных кандидатов на примете.

(Ответ для writers@altlinux.org на комментарий #61)
> (Ответ для Anton Farygin на комментарий #60)
> > Лучше попробовать исправить флапающие тесты.
> 
> Я достаточно долго пытался решить проблему тестов в fish. Но они
> нестабильны, завязаны на какие-то терминальные приложения разработчиков,
> страдают от многопоточности и прочего. 
> 
> Сами разработчики называют их нестабильными (flakey)
> https://github.com/fish-shell/fish-shell/blob/4.7.1/tests/checks/tmux-
> complete.fish#L4-L5
> 
> Причём если я сейчас отключу этот конкретный тест, нет гарантии, что в
> какой-то момент не упадёт другой тест, и мы снова увидим оповещение
> beekeeper.

А почему вас смущает оповещение beekeeper ?
я бы отключил просто флапающие тесты.

(Ответ для Anton Farygin на комментарий #63)
> (Ответ для writers@altlinux.org на комментарий #61)
> 
> А почему вас смущает оповещение beekeeper ?
> я бы отключил просто флапающие тесты.

Меня смущает постоянное оповещение на ошибки тестов, которые никак не влияют на качество конечной сборки. До версии 4.7.1-alt1 ошибки тестов игнорировались и всё было нормально. Подготавливая версию 4.7.1-alt1, я очень долго возился с тестами, чтобы они не падали. Добившись какого-то результата, я убрал ||: из check. В итоге сейчас опять раз в неделю падает очередной случайный тест.

Смущает, что тесты падают рандомно. Что падают рандомные тесты. Это не тот случай, когда отключил один-два падающих теста и всё хорошо. В случае с fish тесты могут упасть просто потому, что gyle перегружена, что какой-то timeout раньше проходил в 0.3 секунды, а теперь нет. Можно ему выставить таймаут 1 секунду, но не факт, что он не упадёт, требуя запас в 1.1 секунды. 

Смущает, что сейчас я повышаю релиз до alt2, а через две недели другой тест упадёт и нужно будет повышать до alt3. 

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

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

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

(Ответ для Anton Farygin на комментарий #66)
> Но если вы настаиваете то я заапрувлю, это решение за ментейнером конечно.
> Жаль просто терять информацию и о том, что работа пакета ломается при
> обновлении каких-то компонент,тем более что по тестам проведена большая
> работа.

Я прошу заапрувить. Разве постоянные ошибки сборки на сборочнице не приводят к тому, что пакет в перспективе удаляется из репозитория? Не хочется, чтобы такое случилось с fish. Кто знает, когда у них следующий релиз будет - завтра или через полгода.

(Ответ для writers@altlinux.org на комментарий #67)
> (Ответ для Anton Farygin на комментарий #66)
> > Но если вы настаиваете то я заапрувлю, это решение за ментейнером конечно.
> > Жаль просто терять информацию и о том, что работа пакета ломается при
> > обновлении каких-то компонент,тем более что по тестам проведена большая
> > работа.
> 
> Я прошу заапрувить. Разве постоянные ошибки сборки на сборочнице не приводят
> к тому, что пакет в перспективе удаляется из репозитория? Не хочется, чтобы
> такое случилось с fish. Кто знает, когда у них следующий релиз будет -
> завтра или через полгода.

Готово

Перевёл prometheus и prometheus-alertmanager на пайплайн через zoryn

https://git.altlinux.org/people/writers/packages/?p=prometheus.git&a=commit&h=b9b55ac993c585fc0dbdbfc92c0f1ed7fa3ea514

https://git.altlinux.org/people/writers/packages/?p=prometheus-alertmanager.git&a=tag&h=e96700a5b0a38f12ed8875c7b420e7ea9f65ce60

Локально, включаю сборку, у меня прошло как по маслу. Но я не уверен в хуках и пока не стал в gyle отправлять.

(Ответ для writers@altlinux.org на комментарий #69)
> Перевёл prometheus и prometheus-alertmanager на пайплайн через zoryn

Обновил в задании пакеты, провёл локальный тест - всё работает. 
https://packages.altlinux.org/ru/tasks/419241/

спасибо, смотрю

Всё неплохо, но мне не понравился выбор 
User=prometheus
Group=prometheus

всё-таки prometheus может быть вполне именем пользователя реальным.

(Ответ для Anton Farygin на комментарий #72)
> всё-таки prometheus может быть вполне именем пользователя реальным.

Замечание понял, но, боюсь, если поменять имя на _prometheus, то это вызовет проблемы при обновлении версии: перезапуск сломается из-за неправильных старых конфигов, которые сейчас под noreplace. У нас такая конфигурация используется минимум с 2018 года. 

Кроме того, у меня ощущение, что похожая ситуация исторически сложилась во всех дистрибутивах linux, вот что я нашёл:
https://gitlab.archlinux.org/archlinux/packaging/packages/prometheus/-/raw/main/prometheus.service
https://sources.debian.org/src/prometheus/2.53.5%2Bds1-5/debian/prometheus.service


Интересно, что такой порядок вещей есть и в мануалах по запуску пакета через systemd, например:
https://janakiev.com/blog/prometheus-setup-systemd/
https://timeweb.cloud/tutorials/servers/ustanovka-i-nastrojka-prometheus

ok, понятно.

Кандидат готов к самостоятельной работе в ALT Linux Team.

Пользователь добавлен в группу мейнтейнеров.

Желаю удачного мейнтейнерства!