Локальный билдсервер для федоры

https://pagure.io/copr/copr

https://pagure.io/copr/copr/blob/master/f/copr-setup.txt

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

https://docs.fedoraproject.org/en-US/modularity/building-modules/local/building-modules-locally/

Но что-то по-моему простой mock с кешированием будет проще.

В чем «серверность» твоего билд-сервера?

В чем «серверность» твоего билд-сервера?

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

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

А не хочешь посмотреть чуть шире и добавить систему воспроизводимых сборок? Двое или более участников, компелять будут у себя и сверять хеши полученных rpm файлов.

Нет, не хочу. Это не входит в круг моих потребностей. Кроме того, я не убежден, что эта конкретная овчинка стоит выделки.

Мой use-case — пересборка некоторых пакетов из Rawhide для релизной ветки. В частности KDE, GNOME и им подобные.

не убежден, что эта конкретная овчинка стоит выделки.

Возможно и не стоит потраченного времени.

Есть клас атак которые можно легко поймать только системой воспроизводимых сборок, например недавний «SolarWinds»: https://reproducible-builds.org/reports/2020-12/

«This revelation is extremely relevant to Reproducible Builds project because, according to the SANS Institute, it appears that the source code and distribution systems were not compromised — instead, the build system was, and is therefore precisely the kind of attack that reproducible builds is designed to prevent.»

переходи на Gentoo, здесь это проще

В подходе с модулями тебе нужно ещё один dist-git добавить в yaml-файл. Модуль собирается в одном общем buildroot и позволяет тебе контролировать порядок пересборки и собирать приложение поверх пересобранных библиотек. Он также даёт возможность потом отделять внутренние пакеты от тех, которые хочется опубликовать в репозиторий.

В подходе с mock можно написать «простой bash-скрипт»(тм) который будет делать то же самое.

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

Но и там и там будет не совсем то что ты хочешь и придётся допиливать.

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

на Gentoo

А система воспроизводимых сборок в Gentoo когда будет?

А mock/rpkg умеет работать изнутри контейнера уже? А то в интернете на эту тему много плача, но весь он датирован где-то перед федорой 24 или 25.

Может в самом деле, ну его комбайн городить, пустить rpkg внутри мейкфайла или как-то так, да пусть работают.

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

Сейчас я делаю это в COPR, но там нельзя запустить цепочку пересборки в нужном порядке иначе, чем вручную. (Еще можно так: скопом пересобрать все, потом пересобирать упавшие билды, пока их количество не перестанет уменьшаться. Боюсь, однако, что за такой подход рано или поздно можно и по морде получить, учтя счет за AWS.)

Может тебе всё-таки модуль в copr залить тогда?

https://docs.fedoraproject.org/en-US/modularity/building-modules/copr/building-modules-in-copr/

По крайней мере вопрос с порядком сборки это решит. Да и вообще по описанию use-case у тебя прям вот совсем модульный.

А mock изнутри контейнера запускать не очень логично потому что mock сам по себе контейнер. То есть chroot. Из-за этого у него всякие проблемы и возникают. Судя по бложикам народ просто в готовом fedora-контейнере rpmbuild запускает для сборки

Типа такого

podman -v ~/RPMBUILD/:/opt:Z run -it fedora rpmbuild /opt/*/*.spec

Я о контейнере интересуюсь в первую очередь потому, что всякое полусерверное у меня живет своей жизнью внутри контейнеров systemd-nspawn. Дико удобно же ж.

Дико удобно же ж.

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

Не, в принципе идею о сборке в rootless-контейнерах я полностью поддерживаю. Но у меня есть подозрение что это надо взять mock, выбросить и написать новую python-обертку уже заточенную под podman или systemd-nspawn.

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

То есть есть хост, на нем nspawn-контейнер с вот этим сборочным добром, а в нем уже mock собирает.

Мне просто сильно не хочется разводить бардак на десктопе.

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

Пробую модуль. Оказывается, что если моя локальная федора версии 33, то почему-то я не могу собрать модуль для федоры 32 (мне это нужно для определения порядка сборки, в 32 нету своих пакетов нужной версии, в 33 есть и они мешают). Потому как модуль platform:f32 билдсервису взять неоткуда (даже если я пропишу в /etc/yum.repos.d/ репозитории от f32).

При этом локально mbs-manager плачется, что модуль для платформы я должен указать стрим явно, так как он не в состоянии определить нужный. И не в состоянии заимпортировать любой, кроме той версии, что и сама система.

Ну почему все такое кривое?

Ну почему все такое кривое?

Это же open source :)

Оказывается, что если моя локальная федора версии 33, то почему-то я не могу собрать модуль для федоры 32

А как именно ты собираешь?

Я вот сейчас попробовала сделать как тут написано: https://docs.fedoraproject.org/en-US/modularity/building-modules/local/building-modules-locally/#_build_your_module_from_distgit

Поменяла в testmodule.yaml master на main и f33 на f32, запустила fedpkg module-build-local. Собрался:

perl-List-Compare-0.55-2.module+f32+2+14475c87.noarch.rpm

А mock/rpkg умеет работать изнутри контейнера уже?

Оно? https://github.com/rpm-software-management/mock/wiki#mock-inside-podman-fedora-toolbox-or-docker-container

Я собираю через mbs-manager, потому что fedpkg думает, что у моего репозитория с модулем должен быть remote. А его ведь нет! Вот эта директория, она и есть origin.

mbs-manager build_module_locally --offline  -r /etc/yum.repos.d/fedora.repo -r /etc/yum.repos.d/fedora-updates.repo --file my-module.yaml --stream main -s platform:f33

Когда я пробую сделать так:

mbs-manager build_module_locally --offline  -r /etc/yum.repos.d/fedora-32.repo -r /etc/yum.repos.d/fedora-32-updates.repo --file my-module.yaml --stream main -s platform:f32

ругается на

2021-02-14 18:24:34,728 - MainThread - MBS.utils - INFO - Module platform:f33:1:000000 imported
.... traceback snipped ....
module_build_service.common.errors.UnprocessableEntity: None of the base module (platform) streams in the buildrequires section could be found

Мне нужен был systemd-nspawn, а mock тоже хочет собирать в контейнерах systemd-nspawn. Я плюнул и собираю на хосте, так как лень разбираться, как вложенные контейнеры включать там.

mbs-manager build_module_locally –offline -r /etc/yum.repos.d/fedora-32.repo -r /etc/yum.repos.d/fedora-32-updates.repo –file my-module.yaml –stream main -s platform:f32

Там ещё должен быть fedora-modular.repo fedora-updates-modular.repo

Модули вынесли в отдельный отключаемый репозиторий же.

Дык вроде

 Mock is, though, able to automatically detect a container environment, and switch to --isolation=simple.

попробовать стоит, но я не пробовал.

Не, он у меня permission denied выкатил. Там какой-то капабилити ему не хватает.

Все едино, для f33 работает и так, и так, а для f32 ни так, ни так. Кроме того, platform оно как бы особый псевдомодуль.

У меня есть подозрение что надо убрать --offline, но я не пока не вижу никакой документации по поводу того что эта опция делает.

fedpkg module-build-local явно что-то тащит напрямую из koji в процессе сборки.

У меня есть подозрение что надо убрать –offline, но я не пока не вижу никакой документации по поводу того что эта опция делает.

Оно будет ходить в федоровское koji, что нежелательно, если билд приватный. И даже POST какой-то делать.

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

В модуле определяешь компоненты, вот так:

source-package:
  rationale: Because I say so
  repository: https://src.fedoraproject.org/rpms/source-package.git
  ref: rawhide

Так вот, оно смотрит, какой URL у меня в repository, чтобы знать, как достать пакет (ну, вдруг там Subversion, или не совсем dist-git). Потом оно собирает инфу о том, какая точно ревизия в указанном ref. При этом mbs-manager игнорирует, какой репозиторий я указал, а берет значение из ключа. То есть если у меня будет такая вот кривая запись:

source-package:
  rationale: Because I'm stupid
  repository: https://src.fedoraproject.org/rpms/completely-different-package.git
  ref: rawhide

то вначале mbs-manager пойдет в репозиторий source-package, сделает там git rev-parse rawhide, а при билде попробует вытащить найденный хеш из репозитория для completely-different-package. Что не имеет смысла вообще. Ну то есть без того ошибочную ситуацию MBS доводит до полнейшего сюра.

Ну а в багтрекере fm-orchestrator, конечно, всем багам года по два и открытых багов за сотню. Все всех устраивает.

Еще один источник проблем — это то, что сначала этот инструментарий прибивают гвоздями к RHEL, потом добавляют гвоздей для федоры, потом для локалхоста как тестовой площадки той же федоры. При этом гвозди редхатовской инфраструктуры торчат оттуда все время и мешают. Я не удивлен, что им так и не удалось сделать modularity нормально (https://lwn.net/Articles/805180/), тем более что одной из заявленных целей была помощь апстриму в публикации собственных модулей. Апстрим понюхал и ему не понравилось, потому что инструментарий широкого использования так не делают.

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

Если же на самом деле целью было затаскивание авторов ПО и пакетов в «сообщество»

Давай только без конспирологии :)

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

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

Не микросервисно ни разу.

Знаешь, я не конспирологичен, но когда-то давно Баллмер кричал Developers! Developers! Developers!, а сегодня слышно из всех тостеров Community! Community! Community!, ну и думается мне, что перекос в сторону «создания и курирования сообществ» — это такое подсознательное и умолчательное. Все побежали, ну и я побежал. Впрочем, это тема для другого разговора.

Отпишусь, когда найду, с чего это platform так криво делается (сейчас мне кажется, что он делается из смеси файлов .repo, которые ты ему даешь в параметре -r, и глобальных системных макросов, из которых делается, например, $releasever).

Самый простой по сложности, но не по времени, способ определить порядок сборки:

1. выставляешь всему buildorder: 10
2. собираешь весь модуль
3. несобравшимся пакетам увеличиваешь buildorder на 10
4. идешь на шаг 2

Впрочем, для таких штук Threadripper и покупался, бггггг

Ахахаха

For LocalResolver which is used only for Offline local builds, the base_module_mmd is ignored. Normally, the `base_module_mmd is used to filter out platform:streams which are not compatible with currently used stream version. But during offline local builds, we always have just single platform:stream derived from PLATFORM_ID in /etc/os-release.

Чото форкнуть надо… ну как так, что даже перекрыть это нельзя. Хоть бери и делай неймспейс, в который даешь свой собственный /etc/os-release и файлы с репами.

Чорд. А когда пакеты в модуле изменяют версию, надо версию модуля тоже подбивать?

Если ты module.md не менял, и у тебя там ref на master, то не надо.

Там версия автоматически генерится по таймстемпу при сборке же.

я тут начал подобное городить для местного сиая.. так как rpm-ки продукт побочный (основная дистрибуция - deb), я планирую в сиайе (гитлаб ранер с докер экзекутором) выполнять rpkg local, а результаты выгружать в pulp.

Пользуясь случаем, спрошу: у меня есть более удобные опции?

P.S.: процесс сиай уже настроен и отдельный билдовый сервак для рпм-ов городить не хочется..

Самый простой по сложности, но не по времени, способ определить порядок сборки:

выставляешь всему buildorder: 10

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

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

У меня mbs-manager вроде в yaml не лезет на запись. Разве что в repomd…