Created attachment 17052 [details] Ключи rsa и gpg одним архивом Псевдоним: writers Текущая почта: sinjuginas@basealt.ru Ментор: Алексей Шабалин Цели: - создание новых приложений для sisyphus; - опакечивание полезных и интересных программ.
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.
Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства!
