Обсуждение участника:Nir: различия между версиями
Nir (обсуждение | вклад) |
Nir (обсуждение | вклад) м (→Процедура Join) |
||
Строка 64: | Строка 64: | ||
* [[User:MichaelShigorin|mike@]] | * [[User:MichaelShigorin|mike@]] | ||
* [[User:IvanMelnikov|iv@]] - только оффлайн менторинг | * [[User:IvanMelnikov|iv@]] - только оффлайн менторинг | ||
==== Проверка ключа ==== | ==== Проверка ключа ==== |
Версия от 17:17, 30 мая 2023
Руководство мейнтейнера ALT Linux
Введение
Данная статья предназначена для централизации всей информации о процессе работы над репозиторием Sisyphus и интеграции в сообщество ALT Linux Team.
Для индивида может существовать множество причин стать участником сообщества:
- желание внести свой вклад в развитие открытого ПО и сделать мир лучше;
- желание "отполировать резюме" и показать рекрутёрам свои навыки;
- желание решить вполне себе практическую проблему - например, воспользоваться конкретной программой;
- необходимость решения проблем эксплуатации дистрибутива в коммерческой или государственной структуре.
Кто такой мейнтейнер
Мейнтейнер (дистрибутива или пакета) - это человек, который занимается тем, что интегрирует ПО в дистрибутив и сопровождает его впоследствии. То есть делает пакет для установки программы из централизованного репозитория, чинит обнаруженные в программе баги, общается с разработчиками программы, старается реагировать на нужды пользователей (багрепорты, вопросы).
В понимании проекта ALT Linux - мейнтейнер должен быть членом ALT Linux Team (Команды ALT Linux).
Что такое ALT Linux Team
ALT Linux Team - команда независимых разработчиков, которые совместно работают над поддержкой наборов программ в репозитории Sisyphus и собирают дистрибутивы на основе этого репозитория.
Как стать членом ALT Linux Team
Существует процедура принятия в ALT Linux Team, описанная на странице Join (присоединение). Обычно, этот процесс происходит естественно, когда человек активно участвует в работе сообщества:
- тестирует ПО и заводит багрепорты о найденных багах;
- помогает чинить баги - присылает патчи;
- пакетирует новое ПО или помогает поддерживать существующие пакеты.
Взаимодействие членов команды осуществляется с помощью разнообразных средств связи (сложилось исторически):
- Sisyphus - репозиторий ПО;
- bugzilla.altlinux.org - багтрекер проекта;
- lists.altlinux.org - списки рассылки проекта;
- forum.altlinux.org - форум сообщества.
- #altlinux и #altlinux-devel - IRC каналы;
Процедура Join
Формально, Join выглядит как создание бага на ALT Linux Bugzilla в разделе Development, с параметрами:
- Product == Team Accounts
- Component == Join
К заявке надо приложить/указать:
- публичный ключ SSH - для доступа к ресурсам сборочницы;
- публичный GPG-ASCIIARMOR ключ для подписи коммитов;
- указать никнейм ментора из команды;
- указать желаемый почтовый адрес вида <nickname>@altlinux.org. Ник должен быть длиннее трёх символов. Посмотреть, занят ли выбранный адрес можно на странице http://git.altlinux.org/people/
В качестве теста на членство в команде принимается работа в виде Gear-репозитория новой программы или возрождение выпавшей из сборок.
Чтобы указать имя ментора (члена команды, который научит собирать и спопровождать пакеты), необходимо предварительно получить его согласие на менторинг. Оптимальный вариант - договориться об этом в личной переписке по e-mail.
Актуальный список менторов (вечно перегружены и плохо пингуются, при возможности лучше найти "своего"):
Проверка ключа
ssh-keygen -l -f ./id_ed25519.pub
Почта должна при этом совпадать с alias, выбранным для почты @altlinux.org.
gpg2 --import-options show-only ./pubring.pub
Почта должна совпадать с alias на altlinux.org. Также, и имя и почта должны совпадать с тем, что будет установлено в настройках Git.
Работа с пакетной базой
Экосистема ALT Linux обладает многими уникальными наработками и своей интересной историей и архитектурой.
Введение в Gear-репозитории
Gear-репозиторий представляет собой репозиторий Git DVCS, содержаший RPM specfile и специальную директорию .gear с инструкциями по сборке пакета для RPM. Практически всегда (но это не является неприкосновенным правилом) в репозитории также хранится и код программы.
К сожалению, Gear, как и Git - очень сложный и гибкий инструмент вида "всё наружу". Есть много вариантов хранения программ в gear repo, которые могут создать проблемы начинающему мейнтейнеру или заставить поломать голову опытного. Не существует однообразного рецепта работы с gear repo, так что не стесняйтесь посоветоваться с участниками сообщества по тем или иным вопросам (также специально создана рассылка devel-newbies@).
Есть некоторые общие рекомендации, которых можно придерживаться:
- хранить код программы с редкими исправлениями удобно в ветке master - там же, где находятся specfile и директория .gear;
- хранить код программы отдельно, в ветке upstream, удобно, когда в программу вносится много изменений и история правок specfile или правил Gear мешает следить за ходом работы.
Нюансы сборки пакетов
- При жалобах на зашитый в ПО RPATH на крайний случай удаляйте его при сборке с помощью программы chrpath. Раньше использование RPATH было очень популярно (особенно в системе сборки automake/libtool), но потом мейнтейнеры пришли к выводу, что это мешает искать библиотеки в стандартных путях. Потому, не оставляйте RPATH без особой необходимости.
- Если у программы есть плагины (особенно с развесистыми или взаимно противоречащими зависимостями), документация, заголовочные файлы библиотек - разместите их в отдельных подпакетах.
- Если у программы есть жёсткие опциональные зависимости (например, варианты зависимости от MySQL/MariaDB и от PostgreSQL) - соберите программу в нескольких вариантах, чтобы позволить пользователям не тянуть лишние зависимости, когда они не нужны.
- Если пользователям могут одновременно понадобиться обе версии программы - старая и новая - соберите два пакета с разными именами. Также обдумайте интеграцию с системой Alternatives и вариант небольшого скрипта-обёртки при таком подходе.
- Если программа предоставляет сервер/сервис - удостоверьтесь в наличии предоставляемых файлов .service для systemd и инитскрипта для sysvinit.
- Политика дистрибутива такова, что не должно быть программ с suid-битом (как sudo) "из коробки". Существует много вариантов решения проблемы, одним из которых является добавление поддержки control(8). В данном случае необходимо проконсультироваться с членами ALT Linux Team касательно разумного выхода из сложившейся ситуации.
- Если Вы импортировали RPM specfile из другого дистрибутива - оставьте прежний changelog, а свои изменения дописывайте отдельно - это дань уважения авторам.
- При сборке gear repo предлагается хранить исходный код отдельно от инструкций сборки в том случае, если проект активно развивается и необходимо видеть его "чистую" историю изменений в Git. В том случае, если проект неактивный, имеет много собственных специфичных патчей - предлагается хранить исходный код в одной ветке с правилами сборки.
- В случае сборки разделяемых библиотек и фреймворков необходимо поставлять .pc файлы
libtool
и файлы конфигурации .cmake дляCMake
. Также необходимо убедиться, что файлы конфигурации, будучи использованы соответствующими инструментами, позволят найти необходимые библиотеки и заголовочные файлы. Одним из оптимальных способов будет написание небольшого интеграционного теста, который будет запускаться после сборки пакета.
Подготовка локального сборочного окружения
Установка пакетов для разработки
Для разработки пакетов нам необходим сборочный тулчейн - rpm, hasher, gear и вспомогательные программы.
Обновите систему, чтобы получить свежие версии пакетов программ:
# apt-get update # apt-get dist-upgrade # reboot
и после перезагрузки установите следующие пакеты:
# apt-get install git \ gear \ hasher \ hasher-priv \ hasher-rich-chroot \ hasher-rich-chroot-user-utils \ rpm-utils \ rpm-build \ rpm-build-licenses \ rpm-macros-cmake \ rpm-macros-make \ rpm-macros-generic-compat \ apt-repo \ apt-repo-tools \ vim-plugin-spec_alt-ftplugin \ kernel-build-tools \ describe-specfile
Также могут понадобиться инструменты разработчика:
# apt-get install gcc gcc-c++ cmake
Настройка Git
Начальная настройка Git выполняется тремя командами:
$ git config --global user.name "Vasiliy Petrov" $ git config --global user.email "vasip@altlinux.org" $ git config --global user.signingkey <keyid>
keyid стоит указывать тот, который был сгенерирован для Join.
Настройка RPM
Добавьте в файл ~/.rpmmacros следующие строки, совпадающие с конфигурацией GPG2 и Git:
%packager Vasiliy Petrov <vasip@altlinux.org> %_gpg_name vasip@altlinux.org # Завершать сборку с ошибкой, если обнаружились незапакованные файлы %define _unpackaged_files_terminate_build 1
Настройка Hasher
Добавьте пользователя в группу rpm
, чтобы Hasher не выкачивал пакеты для chroot каждый раз заново:
# usermod -aG rpm <user>
Hasher использует двух пользователей внутри своего изолированного окружения, чтобы предотвратить атаки на хост-систему из пакетов. Нам необходимо сконфигурировать этих пользователей для аккаунта, от имени которого будет производиться процесс сборки пакетов. Сделать это можно следующей командой:
# hasher-useradd <user>
Где <user> - имя пользователя. Для того, чтобы изменения к пользователю (попадание в две вспомогательных группы hasher) вступили в силу, необходимо выйти из аккаунта и зайти снова. Иногда можно получить ошибку вида:
hsh: /usr/libexec/hasher-priv/getconf.sh: cannot access getconf helper
Если это происходит после перелогина в систему - значит, что новые настройки не были подхвачены. Может помочь перезагрузка машины.
Далее создайте директорию настроек Hasher и сборочную директорию с последующей их инициализацией:
$ mkdir ~/hasher $ mkdir ~/.hasher
Далее создайте файл ~/.hasher/config
примерно следующего содержания:
packager="`rpm --eval %packager`" no_sisyphus_check="packager,buildhost,gpg" allowed_mountpoints=/dev/pts,/proc,/dev/shm lazy_cleanup=1 # share_ipc=1 # Необходимо в случае, когда требуется разрешить доступ в сеть из Hasher chroot. # Данная опция не должна применяться без особой необходимости. # share_network=1 # нужен для сборки с репозиториями отличающимися от системного: # apt_config="$HOME/.hasher/apt.conf"
для завершения процесса настройки.
Можно проверить работоспособность hasher, создав сборочное окружение:
$ hsh --initroot-only ~/hasher
Создавать сборочное окружение каждый раз не обязательно -- оно будет создано автоматически при сборке пакета.
Также, для сборки больших пакетов может потребоваться много времени. Внутренняя утилита hasher-priv
имеет установленный по умолчанию таймаут бездействия в 600 секунд (10 минут). Это частая проблема, сообщение о которой может выглядеть так:
hasher-priv: master: time elapsed limit (600 seconds) exceeded
Чтобы избежать этой проблемы, на сборочной машине предлагается отредактировать файл /etc/hasher-priv/system
и добавить следующие настройки:
wlimit_time_elapsed=360000 wlimit_time_idle=360000
Достаточно большой таймаут позволит вам ждать окончания сборки до победы.
Настройка APT
В рамках локальной сборочной инфраструктуры создаётся так называемый aptbox
, который хранит собственную базу пакетов. Сделано это для того, чтобы пакеты, собираемые hasher
не зависели от системных репозиториев. И наоборот - чтобы системная база пакетов не включала в себя специфичные сборочные пакеты.
Чтобы APT при сборке использовал исключительно требуемую пакетную базу необходимо отключить поиск файлов sources.list
в системных директориях и указать собственные источники пакетов. Сделать это можно с помощью файла конфигурации APT для hasher
: ~/.hasher/apt.conf
:
// Осуществлять попытку перекачать файлы при сбоях APT::Acquire::Retries "3"; // Не вычитывать файл /etc/apt/sources.list Dir::Etc::main "/dev/null"; Dir::Etc::Parts "/var/empty"; Dir::Etc::SourceParts "/var/empty"; Dir::Etc::SourceList "/var/empty"; Dir::Etc::SourceList "~/.hasher/sources.list";
Настройка SSH
Управление заданиями в сборочной инфраструктуре осуществляется с помощью SSH. Для каноничного использования серверов SSH нужно прописать такие строки в ~/.ssh/config
:
# Sisyphus infrastructure Host git.alt HostName gitery.altlinux.org User git_<username> Port 222 IdentityFile ~/.ssh/id_rsa Host girar HostName gyle.altlinux.org User git_<username> Port 222 IdentityFile ~/.ssh/id_rsa
Создание Gear-репозитория из исходных кодов
Мы будем создавать Gear-репозиторий с хранением кода в отдельной ветви - upstream и несколькими зависимыми пакетами (документация, плагины).
Сначала создайте директорию проекта и инициализируйте её:
mkdir program cd program git init
В директории проекта могут быть следующие файлы:
- .gear/rules - файл "правил", согласно которым формируется архив для последущей сборки в Hasher;
- .gear/tags/list - описание тегов для Gear.
Перед продолжением работы стоит отметить, что в Gear-репозиториях может отсутствовать ветка master
. Зачастую ветки именуются на основании того, для какой платформы (версии репоизтория Sisyphus) они предназначены, так как разные срезы репозитория могут отличаться по структуре.
Далее нам необходимо задать базовую структуру репозитория. Создаём директорию настроек gear repo:
mkdir -p .gear touch .gear/rules
Также нам необходимо создать файл с инструкциями сборки приложения:
touch program.spec
Для продолжения работы следует принять к сведению следующую информацию:
Gear производит сборку пакета из Git tag. В связи с тем, что на сборку отправляется конкретный тег - в его истории должен быть доступен как исходный код, так и правила сборки. Потому при хранении исходного кода в отдельной ветке необходимо производить операцию
merge -s ours <code_branch>
в ветку с инструкциями сборки. Это позволит создать единую историю изменений из двух веток.
Файл .gear/tags/list
Файл .gear/tags/list
содержит информацию о соответствии хэшей Git тегам Gear.
Обычно создаётся командой gear-store-tags -avc и правится командой gear-update-tag
, результаты работы которой следует добавить в репозиторий отдельным коммитом, например, так: git commit -m 'gear-store-tags' .gear/tags/. Выглядеть файл list
может так:
cfbb5bba7b9d811ca4734973f5b68296ae305424 v1.2
Рядом с .gear/tags
в таком случае должен лежать файл с id коммита в качестве имени (.gear/tags/cfbb5bba7b9d811ca4734973f5b68296ae305424
) формата:
object 21c9b06871f49c57f770bce99ed4300df8ec7972 type commit tag v1.2 tagger Jeremy White <jwhite@codeweavers.com> 1591374242 +0000 Tag for version 1.2
Файл .gear/rules
Файл .gear/rules
содержит инструкции по упаковке исходного кода и патчей в архив, из которого будет производиться сборка RPM. В простейшем виде он может выглядеть так:
tar: .
Другой пример:
tar: KITScenarist name=@name@-@version@
указывает запаковать директорию KITScenarist из проекта. По умолчанию архив будет иметь имя директории: KITScenarist-1.0.0.tar. В то же время в specfile прописано имя:
%name-%version.tar
Чтобы два имени архива совпали, необходимо указать имя целевого архива в Gear rules. В противном случае макрос %setup
не сможет найти необходимый архив с исходниками.
Существует директива copy
(а также copy?
, которую не рекомендуется применять из-за неявности):
copy: fastfix.patch
Она необходима для прикладывания патчей из репозитория в архив. Директивы выполняются в порядке их чтения сверху вниз, потому она должна находиться перед директивой tar
. Применяется в случаях, когда код надо запатчить быстро, а апстрим проекта тянет с применением изменений.
Ещё одна интересная директива - spec
. Она указывает расположение specfile в том случае, если он находится в нестандартном месте (не в корне репозитория проекта). На текущий момент предлагается размещать specfile в директории .gear
и отправлять файлы в виде pull request в апстрим проектов. Таким образом можно будет сделать сборку не чем-то обособленным, а вполне себе публичной деятельностью. Файл rules
при этом будет выглядеть примерно так:
spec: .gear/nice-project.spec tar: .
specfile
Кроме метаинформации для Gear касательно версионирования изменений в репозитории необходимо также оформить .spec
файл. Данный файл содержит метаинформацию для результирующего пакета, changelog и инструкции по сборке ПО в виде shell-скриптов. Данный файл представляет из себя скрипт в особом формате.
Пример:
# Определяем макрос, который сигнализирует о том, что в случае обнаружения # незапакованных файлов сборка должна упасть с ошибкой %define _unpackaged_files_terminate_build 1 Name: cfengine Version: 3.12.0 Release: alt1 # Epoch: 1 Summary: Configuration management system License: %gpl2plus Group: Other Url: BuildArch: x86-64 Requires: gcc BuildRequires(pre): rpm-build-licenses BuildRequires: gcc Source0: %name-%version.tar %description: Configuration management system. %prep %setup -q %install %files %changelog
Типичный набор директив в specfile включает в себя (но не ограничивается этим):
%define | |
Name | Имя пакета. Регистрозависимо. Принято именовать пакеты в нижнем регистре не смотря на названия программ. |
Version | Версия программы. |
Release | |
Epoch | Обычно не используется. Вводится в новых сборках пакетов при необходимости даунгрейда пакета (например, когда в новой версии обнаружилась регрессия и надо обновить пакет на старую версию). |
Summary | Краткое описание пакета. |
License | Краткое название лицензии. Зачастую указывается в виде макроса из пакета rpm-build-licenses
|
Group | Группа пакетов |
Url | Ссылка на сайт проекта. |
BuildArch | Архитектура, для которой пакет предназначен или noarch , если пакет платформо-независимый (например, документация или картинки).
|
Requires | Зависимости пакета от других пакетов. Рекомендуется указывать по одной зависимости в строчке, так как их изменения удобно отслеживать в истории коммитов. |
BuildRequires | Сборочные зависимости пакета. Дополнительные зависимости, которые нужны только для сборки. |
BuildRequires(pre) | Сборочные зависимости пакета, которые будут установлены до разбора specfile. Зачастую в этой секции производится установка пакетов с RPM макросами. |
Source0 | Обычно выглядит как %name-%version.tar и представляет из себя название архива с исходниками, который будет распакован в сборочную директорию.
|
%description | |
%prep | |
%install | |
%files | |
%changelog |
= Директивы макропроцессора =
%define _unpackaged_files_terminate_build 1
- включает выход с кодом ошибки в случае, если в buildroot обнаружены файлы, не принадлежащие ни одному пакету. Это позволяет мейнтейнеру всегда быть предупреждённым о том, что появились новые файлы, на присутствие которых надо среагировать.
%define _allow_root_build 1
- установка данного макроса позволяет разрешить rpm-build работу от пользователя root. В общем случае данный макрос не нужен. Использовать его целесообразно при bootstrap на новых архитектурах, когда нативно собирается первая итерация пакетов, прямо на целевой rootfs. В таких случаях кроме root других пользователей может не быть и данная опция будет полезна.
Триггеры
Триггеры это специальные скрипты, выполнение которых происходит при соответствии некоторых условий. Например, срабатывание при обновлении, когда версия установленного пакета ниже определённой. См. /usr/share/doc/rpm-4.*/triggers.
%triggerin | Срабатывает после установки пакета. |
%triggerun | Срабатывает перед удалением пакета, если цель триггера установлена в системе. |
%triggerpostun | Данный триггер срабатывает в ситуации обновления пакета, после удаления предыдущей версии пакета. Не срабатывает при простом удалении пакета. |
Доработка существующего пакета
Источниками существующих пакетов могут быть:
- gears - Git-репозитории специально оформленные инструкциями по сборке пакетов RPM;
- srpms - Пакеты SRPM, зачастую импортированные из других RPM-based дистрибутивов. Также SRPM могут применяться в ситуациях очень больших проектов, когда работа с Git неоправданно замедляет процесс сборки. К таким проектам, например, относится LibreOffice.
Процесс работы над Gears
Первоначально необходимо сделать персональную копию репозитория (форк, в терминологии GitHub), над которой и вести дальнейшую работу. Далее будет рассмотрена работа над CFEngine 3 в качестве примера.
Копируем репозиторий себе:
ssh git.alt clone /gears/c/cfengine.git
В случае, если мы начинаем работу над новым пакетом, необходимо репозиторий создать командой:
ssh git.alt init-db cfengine
Клонируем репозиторий на локальную машину для дальнейшей работы:
git clone git.alt:/people/имя/packages/cfengine.git
Далее стоит попытаться собрать пакет в текущей конфигурации, чтобы убедиться, что локальная сборочная система работает корректно. Выполнить эту задачу возможно с помощью утилиты gear-hsh
. Она предназначена для сборки пакета в chroot и её успешное выполнение гарантирует 90% успеха при отправке пакета в сборочницу.
Переключитесь в директорию проекта:
cd cfengine
И выполните команду:
gear-hsh --verbose --lazy-cleanup --commit -- --verbose
Процесс может занять некоторое время, так как будут произведены следующие шаги:
- создан chroot для сборки;
- сформирован тарбол с исходным кодом программы и перемещён в chroot;
- будут скачаны и установлены пакеты сборочных зависимостей (указаны в spec файле в качестве BuildRequires директивы);
- будет запущен процесс распаковки тарбола с кодом, его сборки, тестирования и упаковки в RPM.
В случае проблем при сборке пакета в chroot иногда бывает необходимо доустановить пакеты, при том apt отсутствует внутри chroot. Сделать это можно командой:
hsh-install <package_name>
В случае, если нам необходимо добавить Git remote (например, git.alt) к существующему репозиторию, стоит воспользоваться следующей командой:
git remote add git.alt git.alt:/people/имя/packages/cfengine.git
Процесс работы над SRPMS
Существуют ситуации, когда работа над пакетом в виде git-репозитория может быть неудобна. Например, большое ПО типа LibreOffice может занимать огромный объём дискового пространства и иметь очень сложную историю. Вытягивание изменений и их отправка при этом сильно замедляются. К этому добавляются накладные расходы на создание тарбола для сборки пакета. В некотором роде данную проблему можно решить, если хранить исходный код в виде Source RPM - SRPM.
SRPM пакеты в ALT представлены Git репозиториями http://git.altlinux.org/srpms/ . История репозиториев отражает все успешные сборки SRPM. Происходит это в связи с процессом: SRPM распаковывается и собирается. Если сборка проходит успешно, то использованный исходный код автоматически коммитится в историю репозитория. Сами же SRPM пакеты лежат на зеркалах.
Отправка пакета в сборочницу
Сборка пакета осуществляется из определённого тега. После сборки пакет попадает в "карман" - мини-репозиторий. Один карман может содержать несколько пакетов. Это позволяет группировать пакеты по задачам для последующего тестирования.
Каждый пакет относится к платформе. Узнать список платформ для которых можно выполнить сборку пакета можно командой
ssh girar task new --help
Чтобы начать собирать пакеты необходимо создать сборочную "задачу" (которая станет карманом):
ssh girar task new sisyphus ssh girar task new p10
Чтобы попасть в стабильную ветку, пакет сначала должен пройти сборку в репозиторий Sisyphus, поэтому мы создаём две задачи.
Далее необходимо добавить репозитории для сборки. Отправить на сборку можно репозиторий, который находится в персональном подкаталоге packages на git.altlinux.org командой:
ssh girar task add <task id> repo cfengine.git 3.12.2-alt1
Далее необходимо собственно запустить процесс сборки указанных репозиториев (на тестовую сборку, без отправки в основной репозиторий):
ssh girar task run --test-only <task id>
Стоит отметить, что опция --test-only является умолчальной, но не для всех сборочниц (которые бывают разные), так что рекомендуется не забывать добавлять её. После успешной сборки, если не возникает вопросов по пакетам, возможно отправить задачу в репозиторий. Для этого необходимо сделать не-тестовую сборку командой:
ssh girar task run -m "Build_reason" --commit <task id>
или (для подробного сообщения с пробелами):
ssh girar task run --commit <task id> -m -
Где "build_reason" - сообщение о причинах отправки на сборку, без пробелов.
Команды сборочницы
Просмотр списка веток:
ssh girar acl --list
Просмотр списка членов группы:
ssh girar acl p10 @maint show
Развёртывание локальной сборочницы
Сборочница состоит из контрольных машин, которые управляют заданиями и сборочных нод.
Создание собственного репозитория
Для решения задачи предоставления собственного специфичного репозитория, например, в ситуации, когда производитель проприетарного ПО хочет также поставлять свои пакеты для дистрибутива, существует команда genbasedir
. Данная программа анализирует директорию с пакетами RPM и генерирует файлы метаданных. Для этого необходимо создать структуру каталогов, подобную описанной выше. Вы можете выбирать из следующих компонентов:
- CoolVendor/MyCoolProprietaryProduct - название подсистемы. Например, продукта или производителя. Может состоять из произвольной вложенности набора директорий. Этот уровень в дереве может отсутствовать (то есть, каталоги RPMS и base могут идти сразу следом за архитектурой);
- x86_64 - архитектура, под которую собраны пакет (совпадает с таковой в имени бинарных RPM-пакетов);
- RPMS - каталог, в котором размещены бинарные пакеты;
- SRPMS - каталог, в котором размещены пакеты с исходными текстами программ;
- RPMS.sisyphus - ссылка на каталог RPMS. При этом sisyphus заменяется на собственное название репозитория, например, local;
- base - служебный каталог, в котором размещается база данных APT;
Следующий шаг в создании своего репозитория заключается в помещении бинарных пакетов в каталог RPMS, а пакетов с исходными текстами — в каталог SRPMS и в генерации служебной информации для APT при помощи команды genbasedir
; ее формат:
$ genbasedir [опции] {название подсистемы} {репозиторий 1} [репозиторий 2...]
Из опций, список которых можно увидеть при запуске genbasedir без параметров, наиболее важной является опция --topdir, позволяющая указать путь к репозиторию. Все остальные параметры задаются относительно этого пути. Выглядит это следующим образом. Допустим, что наше дерево каталогов выглядит так:
/srv/repository/ |-- SRPMS |-- SRPMS.security |-- CoolVendor | |-- MyCoolPropietaryProduct | | |-- x86_64 | | | |-- RPMS | | | |-- RPMS.local -> RPMS | | | |-- RPMS.security | | | |-- SRPMS.local -> ../../SRPMS | | | |-- SRPMS.security -> ../../SRPMS.security | | | |-- base | | |-- noarch | | | |-- RPMS | | | |-- RPMS.local -> RPMS | | | |-- SRPMS.local -> ../../SRPMS | | | |-- base
Тогда строка запуска genbasedir будет выглядеть так:
$ genbasedir --topdir=/srv/repository CoolVendor/MyCoolProprietaryProduct/x86_64 local security
Этой командой мы создадим информацию для APT в двух репозиториях — local и security. Для того, чтобы воспользоваться этой информацией, необходимо прописать доступ к репозиториям в /etc/apt/sources.list
:
rpm file:/srv/repository CoolVendor/MyCoolProprietaryProduct/x86_64 local rpm-src file:/srv/repository CoolVendor/MyCoolProprietaryProduct/x86_64 local rpm file:/srv/repository CoolVendor/MyCoolProprietaryProduct/x86_64 security rpm-src file:/srv/repository CoolVendor/MyCoolProprietaryProduct/x86_64 security
Репозиторий MyCoolProprietaryProduct.security, хранящий пакеты с исправлениями ошибок в системе безопасности, имеет смысл подписывать PGP-ключом, чтобы при установке пакета можно было проверить подлинность репозитория и хранящихся в нем пакетов. Для этого необходимо создать соответствующий PGP-ключ, используя программу GnuPG (gpg2) и запомнить его отпечаток (fingerprint) на клиентских машинах в файле /etc/apt/vendors.list в формате:
simple-key "краткое название ключа" { Fingerprint "GNUPG KEY FINGERPRINT"; Name "GNUPG UID <user@email>"; }
Примером может служить ключ службы безопасности ALT Linux Team, которым подписаны пакеты репозитория Sisyphus и обновления безопасности для различных дистрибутивов ALTLinux:
simple-key "alt" { Fingerprint "BB1DD157A9722953847C5DB25B433A0EEAC91CA0"; Name "ALT Security Team <security@altlinux.ru>"; }
Для того, чтобы APT проверял подлинность подписи, необходимо указать, что соответствующий репозиторий подписан PGP-ключом в /etc/apt/sources.list
:
rpm [alt] file:/srv/repository CoolVendor/MyCoolProprietaryProduct/x86_64 security rpm-src [alt] file:/srv/repository CoolVendor/MyCoolProprietaryProduct/x86_64 security
Необходимо также сгенерировать информацию для APT в репозитории с указанием опции --sign
команды genbasedir
. Дополнительно, можно указать идентификатор ключа, если он отличается от ключа по умолчанию, используя опцию --uid=идентификатор
. Значением этой опции является идентификатор ключа в том виде, как он передается программе GnuPG в опции --default-key
:
$ genbasedir \ --topdir=/srv/repository \ --sign \ --uid='Proprietary Vendor ID' \ CoolVendor/MyCoolProprietaryProduct/x86_64 security
Операцию создания служебной информации для APT необходимо производить каждый раз, когда в репозиторий вносятся изменения. Результирующий репозиторий возможно отдать во внешний мир с помощью HTTP сервера.
Пакеты подписываются с помощью команды rpmsign
. Репозитории подписываются с помощью опции -s
утилиты genbasedir
. Для импорта публичного ключа в RPM keyring есть команда rpm --import
.
Сборка образов с помощью mkimage-profiles
Перед началом работы стоит отметить следующие положения касательно сборки образов с помощью mkimage-profiles
:
mkimage-profiles
не подхватывает собственный (локальный) репозиторийhasher
по умолчанию. Для его использования, или для использования иным образом локально собранных пакетов, необходимо прописать директорию с пакетами вsources.list
соответствующим образом.- Ветка
sisyphus
нужна только для сборки пакета. Бранчевание для разработки новых функций стоит проводить от веткиmaster
.
Пример команды сборки образа:
make DEBUG=1 ARCH=aarch64 BRANCH=p10 APTCONF=/etc/apt/apt.conf.aarch64 alt-server.iso
Сборка образов может занимать большой объём дискового пространства (например, порядка 100 Гб). Чтобы преодолеть проблему расхода дискового пространства возможно использовать системный файл настроек утилиты hasher-priv
- /etc/hasher-priv/system
:
prefix=/srv/tmp/image-build
Опция prefix
отвечает за локацию, где mkimage-profiles
будет проводить сборку образа.
Сборка rootfs для целевой платформы
Конфигурирование целевой rootfs
Установка QEMU-USER
apt-get install qemu-user-static-binfmt-aarch64 qemu-user-static-aarch64
Монтирование системных файловых систем в rootfs
for f in dev dev/pts sys proc run ; do mount --bind /$f /mnt/rootfs/$f ; done
Переключение в целевую rootfs
chroot /mnt/rootfs
Отключение системных ФС
for f in dev/pts dev sys proc run ; do umount /mnt/rootfs/$f ; done
Если вы хотите переключиться в целевой chroot
и поработать, это можно сделать следующим способом:
sudo cp /usr/bin/qemu-aarch64-static /mnt/rootfs sudo chroot /mnt/rootfs ./qemu-aarch64-static /bin/bash
Это позволит на текущей машине запустить шелл rootfs целевой архитеры.
Сборка ядра для целевой платформы
Количество потоков для сборки ядра рекомендуется устанавливать как nproc+1 или даже nproc+2 .
Для каждой команды необходимо устанавливать две переменных: ARCH и CROSS_COMPILE . В таком случае процедура будет выглядеть примерно так:
env ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- scripts/kconfig/merge_config.sh -m config config-aarch64 config-std ${EXTRACONFIGS} env ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make olddefconfig env ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make prepare make -j $(($(nproc) + 1)) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LOCALVERSION="" make -j $(($(nproc) + 1)) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LOCALVERSION="" modules make -j $(($(nproc) + 1)) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LOCALVERSION="" dtbs sudo make -j $(($(nproc) + 1)) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- INSTALL_MOD_STRIP=1 modules_install sudo make -j $(($(nproc) + 1)) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- install sudo make -j $(($(nproc) + 1)) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- INSTALL_PATH=/boot/dtb dtbs_install
make olddefconfig неинтерактивно устанавливает в умолчальные значения пропущенные опции в файле .config .
Опакечивание ядра
Для работы со .spec файлом ядра, в котором много сложных макросов и подстановок, необходимо установить пакет kernel-build-tools
и describe-specfile
(подпакет gear
).
Предварительно в файл .git/config
необходимо добавить секцию:
[gear "specsubst"] kflavour = flavourname
Сделать это можно с помощью команды:
git config --local gear.specsubst.kflavour flavourname
Чтобы сборка началась, необходимо добавить метаданные тега, относительно которого ведётся сборка. Сделать это можно командой:
gear-update-tag -avc
Сборка может производиться в текущем окружении:
gear-rpm -v --ba --commit --target=aarch64 --with cross_toolchain_aarch64
А также может производиться в Hasher chroot:
gear -v --commit --hasher -- hsh -v --target=aarch64 --build-args='--with cross_toolchain_aarch64' ~/hasher
Проблемы
Q :
BTF: .tmp_vmlinux.btf: pahole (pahole) is not available Failed to generate BTF for vmlinux Try to disable CONFIG_DEBUG_INFO_BTF
A :
# apt-get install dwarves
Q:
macro: %def_disable check not found
A:
Нет ответа.
ALT RPM Internals
RPM управляет базой данный пакетов и выполняет разрешение зависимостей при установке пакетов.
RPM не знает, что оно может быть получено путём кросс-компиляции.
В вот человек выполнял bootstrap для Fedora:
- https://fedoraproject.org/wiki/Architectures/RISC-V/Bootstrapping
- https://github.com/rwmjones/fedora-riscv-bootstrap
ALT APT-RPM Internals
APT-RPM управляет получением пакетов из различных источников и впоследствии передаёт пакеты в RPM для дальнейшей обработки. За работу по передаче данных с использованием различных протоколов отвечают подпрограммы-модули, называемые methods
.
Развёртывание сборочницы
ПО на Join
- https://github.com/Librum-Reader/Librum - Приложение для создания библиотеки, написано с использованием CMake, Qt5 и QML.
- https://github.com/KDAB/hotspot - Инструмент для анализа производительности построенный поверх perf, похож на flamegraph но на qt.
- https://github.com/KDAB/GammaRay - Утилита для анализа свойств Qt объектов в запущенном приложении, может дополнять отладчик, упрощая поиск проблем.
- https://github.com/dhendrix/flashmap - выдирает layout из дампов firmware.
- https://github.com/PabloCastellano/extract-dtb - выдирает DTB (FDT) из дампов firmware.
- https://gitlab.com/DavidGriffith/minipro/ - flasher для программатора TL866.
- https://github.com/sikthehedgehog/mdtools - утилиты для работы с блобами SEGA Mega Drive. Включает утилиту для "добивания нулями" бинарных блобов.
- https://github.com/flashrom/flashrom - В master репозитория flashrom появились функции для чтения статуса "Write Protect".
- https://github.com/YosysHQ - опенсорсный тулчейн для синтеза FPGA bitstream.
- https://github.com/SymbiFlow - опенсорсный тулчейн для работы с FPGA (прошивки, в частности, Lattice iCE40).
- https://github.com/cpb-/spi-tools - наши уже протухли, надо обновлять.
- https://github.com/mwelling/spi-test
- https://github.com/gschorcht/spi-ch341-usb - драйвер для цепляния SPI устройств через чип CH341A
- https://github.com/blacksphere/blackmagic - Управлящиее ПО и firmware для JTAG отладчика Black Magic Probe
- https://github.com/VUnit/vunit - фреймворк для Unit-тестов для Verilog.
- https://github.com/openhab - ПО для работы с хабами ZigBee
- https://github.com/rdiez/JtagDue - программный JTAG, который делает из Arduino Due эмуляцию Bus Pirate для совместимости с OpenOCD.
- https://github.com/ProgHQ/open-tl866 - Опенсорсная фирмварь для программаторов TL866.
- https://github.com/fritzing/fritzing-app - протухла в репозитории.
- https://github.com/ponyatov/matiec - transpiler для ПЛК.
- https://github.com/PaulStoffregen/SerialFlash - обвязочка для SPI bit-bang
- https://github.com/adrian-thurston/ragel - в репозитории версия 6.10, уже есть версия 7.0.4.
- https://github.com/dimkanovikov/KITScenarist - для написания сценариев, GUI
- https://github.com/nyousefi/Fountain - почти пром. стандарт для сценариев, CLI
- https://www.klayout.de/ - супер нужная штука для работы с форматами GDS/GDSII (маски чипов)
- https://github.com/LibreCAD/libdxfrw - нужна свежая версия для LibreCAD 3.
- https://github.com/LibreCAD/LibreCAD_3 - сабж.