mkdir work cd work cp /usr/share/doc/kernel-build-tools-*/config.sh.sample config.sh $EDITOR config.sh
В рабочем каталоге находятся следующие подкаталоги:
В этом каталоге размещается git-репозиторий ядра.
В этом каталоге размещается git-репозиторий дополнительных модулей.
В подкаталог out/logs помещаются логи сборки модулей. Кроме того, при сборке без использования hasher собранные пакеты помещаются в подкаталоги out/RPMS и out/SRPMS.
Из этого каталога и его подкаталогов при сборке без использования hasher берутся собранные бинарные пакеты kernel-source-*, содержащие архивы с исходными текстами ядра и модулей.
В этом каталоге создаются подкаталоги для временных файлов, используемых при сборке:
Каталог, в который распаковываются бинарные пакеты kernel-source-* при сборке без использования hasher. Кроме того, в этом каталоге находится база данных RPM, используемая при такой сборке.
Каталог, в котором происходит сборка RPM-пакетов (соответствует макросу %_builddir).
Временный каталог для RPM (соответствует макросу %_tmppath).
Данная структура может быть частично переопределена с помощью переменных в файле config.sh (см. раздел “Настройка сборочной среды”).
Создать каталог и, возможно, файл config.sh для настройки дополнительных параметров сборки:
mkdir work cd work cp /usr/share/doc/kernel-build-tools-*/config.sh.sample config.sh $EDITOR config.sh
В подкаталоге kernel необходимо разместить git-репозиторий собираемого ядра:
git clone git://git.altlinux.org/people/vsu/packages/kernel-image-2.6.18 kernel (cd kernel && git fetch origin 'refs/heads/*:refs/heads/*')
В подкаталоге modules необходимо разместить git-репозиторий дополнительных модулей:
git clone git://git.altlinux.org/people/vsu/packages/kernel-modules modules (cd modules && git fetch origin 'refs/heads/*:refs/heads/*')
Для возможности собирать пакеты без использования hasher (что несколько ускоряет работу при выполнении большого количества сборок) необходимо скопировать в подкаталог sources бинарные пакеты kernel-source-*, содержащие архивы с исходными текстами ядра и модулей. В каталоге sources можно создавать любую структуру подкаталогов — при сборке будут использованы все находящиеся там пакеты *.noarch.rpm и *.ARCH.rpm, где ARCH — выбранная для сборки архитектура. Допускается использование символических ссылок на файлы пакетов (однако символические ссылки на каталоги не обрабатываются).
Скрипт buildkernel используется для сборки пакета ядра. Сборка может производиться как с использованием hasher, так и без него. Перед запуском этого скрипта в каталоге kernel должен быть размещён git-репозиторий ядра. Кроме того, в случае сборки без использования hasher в каталоге sources должен быть доступен пакет kernel-source-version-release.noarch.rpm с исходными текстами соответствующей версии ядра; при использовании hasher необходимые для сборки пакеты должны быть доступны в репозиториях APT.
Для сборки ядра необходимо запустить скрипт buildkernel с параметром, в котором указан тип собираемого ядра (flavour):
buildkernel std-smp
При этом для сборки вызывается gear с параметром -t kernel-image-flavour.
Дополнительно можно указывать опции:
Сборка с помощью hasher.
Архитектура, для которой собирается ядро.
Дополнительные опции для hsh. Эта строка передаётся в eval, поэтому при необходимости передачи параметров, содержащих пробелы или другие символы, имеющие специальное значение в shell, нужно использовать shell quoting.
Рабочий каталог для hasher.
Дополнительные опции для rpmbuild. Эта строка передаётся в eval, поэтому при необходимости передачи параметров, содержащих пробелы или другие символы, имеющие специальное значение в shell, нужно использовать shell quoting.
Скрипт buildmodules предназначен для сборки пакетов с модулями. Сборка может производиться как с использованием hasher, так и без него. В случае сборки без использования hasher в подкаталоге sources должны находиться пакеты с исходными текстами нужных модулей, а в подкаталоге out должны находиться собранные бинарные пакеты ядра, для которого будут собираться модули; при использовании hasher эти же пакеты должны быть доступны в одном из репозиториев APT, используемых hasher.
Вариант ядра (flavour), для которого собираются модули, задаётся через опцию -k flavour; эта опция может быть указана несколько раз, чтобы модули собирались для всех указанных ядер. Имена модулей, которые необходимо собрать, указываются в параметрах скрипта; если параметры отсутствуют, список модулей для сборки берётся из файла modules.build, который должен находиться в ветке kernel-image-flavour git-репозитория kernel.
Для совместимости поддерживается старый формат вызова, в котором опция -k flavour не используется, а тип ядра указывается первым обычным параметром (который в этом случае является обязательным); второй и последующие параметры содержат имена модулей для сборки.
Опции, поддерживаемые скриптом buildmodules:
Задать имя ветви репозитория (по умолчанию используется sisyphus; ветви для обновлений к дистрибутивам именуются в формате alt-linux-X.Y).
Собирать пакеты для указанного варианта ядра. Опция может использоваться несколько раз, при этом сборка будет выполнена для всех указанных вариантов ядра.
Создать в ветках для окончательных пакетов с модулями (kernel-modules-MODULE/BRANCH) коммиты для собираемых модулей, предназначенные для сборки пакетов с помощью gear.
Создать коммиты (как при указании опции --commit), а также теги вида kernel-modules-MODULE/VERSION-RELEASE для собираемых модулей. Теги создаются утилитой gear-create-tag и подписываются с помощью gpg; для удобства при создании тегов для большого количества модулей можно использовать gpg-agent, чтобы не вводить пароль при подписи каждого тега.
Не выполнять сборку пакетов. Эта опция может быть указана только совместно с --commit или --tag.
Собирать пакеты с модулями заново даже в том случае, если собранный пакет уже есть в out/RPMS, либо в ветке kernel-modules-MODULE/BRANCH для собираемого модуля уже есть коммит с совпадающими номерами версии и сборки, но с отличающимся содержимым. При использовании совместно с опцией --tag опция --force также разрешает замену созданных ранее тегов.
Сборка с помощью hasher.
Архитектура, для которой собираются пакеты.
Дополнительные опции для hsh. Эта строка передаётся в eval, поэтому при необходимости передачи параметров, содержащих пробелы или другие символы, имеющие специальное значение в shell, нужно использовать shell quoting.
Рабочий каталог для hasher.
Дополнительные опции для rpmbuild. Эта строка передаётся в eval, поэтому при необходимости передачи параметров, содержащих пробелы или другие символы, имеющие специальное значение в shell, нужно использовать shell quoting.
В файле config.sh при необходимости могут быть установлены значения следующих переменных:
Архитектура для сборки пакетов, используемая, если при запуске сборки явно не указана опция --target=ARCH. Значение по умолчанию определяется по выводу uname -m, причём для всех вариантов Intel x86 (32-bit) используется i586.
Каталог, в котором осуществляется сборка RPM (%_builddir, по умолчанию $TOP/tmp/BUILD).
Каталог для временных файлов RPM (%_tmppath, по умолчанию $TOP/tmp/TMP).
Каталог, в который распаковываются RPM-пакеты, содержащие архивы с исходными текстами ядра и модулей (по умолчанию $TOP/tmp/root).
Каталог, в который помещаются логи сборки пакетов с модулями (по умолчанию $TOP/out/logs).
Каталог, в который помещаются собранные src.rpm (по умолчанию $TOP/outdir/SRPMS).
Каталог, в который помещаются собранные бинарные пакеты (по умолчанию $TOP/outdir/RPMS).
Дополнительные опции, передаваемые hsh. При использовании опции --hsh-options=OPTIONS значение этой переменной заменяется значением, переданным в командной строке.
Дополнительные опции, передаваемые rpmbuild. При использовании опции --rpmbuild-options=OPTIONS значение этой переменной заменяется значением, переданным в командной строке.
Рабочий каталог для hasher. Значение по умолчанию определяется установками переменной prefix в файлах /etc/hasher-priv/system и /etc/hasher-priv/user.d/USER: используется каталог $prefix/$USER/hasher, кроме случая, когда для prefix установлено значение ~ — тогда используется каталог $HOME/hasher.
Шаблоны модулей размещаются в репозитории modules в ветках с именами template/MODULE/BRANCH, где MODULE — имя пакета без flavour ядра и kernel-modules-, BRANCH — имя ветви репозитория (sisyphus, alt-linux-4.0, …).
Шаблон spec-файла должен содержать строки вида:
%define module_name slmdm %define module_release alt13 %define module_version 2.7.10 %define kversion @kversion@ %define krelease @krelease@ %define flavour @kflavour@ Name: kernel-modules-%module_name-%flavour Version: %module_version Release: %module_release
На самом деле использование именно таких определений макросов не является обязательным — главное, чтобы поля Name/Version/Release в результате получали значения в нужном формате, однако в большинстве существующих шаблонов используются макросы с указанными в примере именами.
При сборке модуля следующие ключевые слова, используемые в шаблоне, заменяются на конкретные значения:
@kversion@ — версия ядра
@krelease@ — релиз ядра
@kflavour@ — flavour ядра
В предыдущем варианте шаблонов также использовалось ключевое слово @kreleasebuild@, которое добавлялось в конец поля Release (обычно в определении макроса %module_release). В текущем формате шаблонов ключевое слово @kreleasebuild@ не используется, и не должно присутствовать в файле шаблона (в случае, если оно присутствует в файле, считается, что шаблон имеет старый формат). При использовании нового формата шаблонов код версии и номер сборки ядра добавляются в конец первой из встреченных строк Release: в шаблоне, после чего вызывается add_changelog для добавления сообщения об автоматической сборке пакета.
В git-репозитории ядра должен содержаться файл modules.build, содержащий список пакетов с модулями, которые необходимо собрать. Например:
$ cat kernel/modules.build fglrx nvidia hostap drm