/*
-Мальцик, мальцик сам виноват!
/вопль судьи (после речи обвиняемого) на слушании дела по изнасилованию несовершеннолетнего.../
всех со всеми, всего, того же и туда же... надеюсь, что НГ удался на славу и вы можете по крупицам восстанавливать хронологию событий в ближайшем будущем. эта заметка планировалась как "последняя" в "цикле" про OBS, но, планы эт одно, а каменная жопа реальности - совсем другое дело. к тому же один мой друг скоро должен академическим языком (в отличие от аффтара) изложить свои мысли и наработки по OBS - должно быть весьма занимательно, пропиарю, не сумлевайтесь.
поскольку сей очерк содержит несколько ключевых "идей" (сиречь посланий, что должны быть где-то зафиксированы как минимум), то выстроить логическую цепочку изложения материала проблематично. возможно, что материал будет жестоко корректироваться после публикации.
предыдущие серии нашего "опуса" можно считать "обзорными" - сиречь обо всём и ни о чём. тут же - другое дело. сугубо практика и описание "ухабов" на легендарном пути "из Петербурга в Маскву". будем задавать себе вопросы и искать на них пральные ответы (тихо сам с собою, умным человеком, я веду беседу...). вопрос первый:
1. Какого хуя при локальной сборке пакета (rpmbuild -bb file.spec) всё путём, а OBS не может понять, что все зависимости заданы корректно?!
т.е. Вы, как пионэр, в "BuildRequires:" прописали всё, что надо (и даже больше), но сборка сыпется с сообщениями, что требуемого пакета в "сборочном окружении" нет (хотя лог показывает, что сей пакет корректно установлен!). в 99% случаев это жестокий "прикол" утилиты "/usr/bin/pkg-config", связанный с разблядовкой собранной программы на "-devel" и прочие "обычные" пакеты. OBS/(rpm в частности) самостоятельно отслеживает динамических линковку либ/бинарей и выставляет корректный "Requires:" (прямые зависимости пакета) для результата. но, это, сцуко, только для "non devel related" пакетов! соответственно команда:
> rpm -qR имя_пакета
выдаст вам на гора список прямых зависимостей. поэтому ежели вы ваяете "devel" пакет, то "аз, буки, веди" - вхуярить в спек файл следующее:
%devel [-n новое_имя]
Group: чего-то там
Summary: И вас туда же (да-да-да, с Заглавной, мать её, буквы!)
Requires: %{name} = %{version}
то, что дано в квадратных скобках - [] - опционально. но пример выше лишь указывает, что при установке "devel" пакета в систему надо обязательно тащить и "основной пакет". "прямые" зависимости на "devel" пакеты OBS/rpm НЕ ОТСЛЕЖИВАЕТ! и у "pkg-config" (который работает исключительно с "devel" пакетами) сносит крышу, когда, допустим, требуется для сборки "curl", в "сборочное окружение" "libcurl" установлен, но, "/usr/lib/pkgconfig/libcurl.pc" файла-то НЕТ! ибо надо ручками, самому, в секцию "%devel" дорисовывать:
Requires: пакет1-devel пакет2-devel .....
т.е. риска для "хомячков" (которым spec-файл и в кошмарном сне не привидится) нет никакого, а вот "господа мейнтейнеры" огребают по полной (причём справедливо, по результатам теста на IQ).
как это ловить:
если "rpmbuild -bb[-ba] файл.spec" проходит на ура, а в OBS - жопа, то даём команду:
> osc build
в результате у нас в "/var/tmp/build-root/" будет сформировано окружение для сборки. можно сделать:
> sudo chroot /var/tmp/build-root/
> pkg-config --modversion имя_требуемого_пакета
если всё путём - то последняя команда выдаст версию установленного пакета, если нет - то вы хоть поймёте где накосячили. соответственно исправляем/(пинаем мейнтейнера) косяки.
очень полезно в данном случае вдумчиво ознакомиться с политикой Партии по обновлению пакетов, да!
2. Бля, всё собралось, репо не обновляется! Шозахуйня?!
сынок, не ссы, всё путём! одна из "фишек" OBS именно в том, что репо не будет обновлено до тех пор, пока не произойдёт удовлетворение ВСЕХ зависимых пакетов (хомячки в восторге писают гранулированным кипятком, их системы всегда будут в рабочем состоянии)! поясню. допустим мы вносим изменения в пакет А, от которого зависят пакеты B и С. репо не будет обновлено до тех пор, пока пакеты B и С не отрапортуют об успешной пересборке с ИЗМЕНИВШИМСЯ пакетом А. это вам не "ебиан" и не "федорино горе" - привыкайте заботиться о Пользователях, Господа хорошие! одним из следствий этого являются "большие" номера "релизов" в SLE/SUSE ("Release: №"), ибо значение этого поля состоит из двух цифр, разделённых точкой (.). первая цифирь - судит о том, как долго вы ебались со спеком, прежде чем он собрался в OBS, вторая - сколько раз перехуяривали зависимости к вашему пакету... кроме того, есть такая штука, как scheduler - это некий виртуальный администратор на раздачу заданий в OBS - он может быть завален работой по самое ни-ни и не стоит требовать в данном случае от него немедленного удовлетворения ваших низменных потребностей.
3. Ёб вашу мать! Пакет в порядке, какого хуя сборка упала?!
"shit happens, you know..." будьте готовы к тому, что некоторые "сборочные цеха" примут ваш заказ на исполнение и уйдут в запой немедленно. результат - "failed" статус для полностью корректного пакета по причине того, что виртуальный "XEN-build-host" наебнулся с ошибкой в собственной конфигурации. ничего страшного, кроме того, что рестартовать сборку надо вручную (оно само пока не способно себя же контролировать). хомячки этого даже не заметят.
4. А-а-а! Демоны! Демоны!
как правило подобные "эмоции" характерны для товарищей, не осиливших макросы при сборке rpm-пакетов. это особенно актуально для модулей пистона (python), жемчужины (perl) и прочих скриптовых языков. с версии openSUSE-11.2 идёт тенденция спихнуть это всё на "noarch" архитектуру (ибо скрипты одинаковы для всех), что порождает порой забавные ситуации (забавные - эт если со стороны смотреть...). совет тут один - "читайте книжки"...
5. Слышь, начальник, я это, свой OBS хочу намутить! Шо делать надо?
читать! здеся:
Build_Service всё и неоднократно...
*************
вскоре вместо этих "звёздочек" появится материал по работе с модулями ядра при Code11 или же ознакомьтесь с подробной документацией, пжалста....
кроме того могу проинформировать всех SLE/SUSE пользователей Enlightenment Desktop Shell об успешном апдейте репов на E-svn-20100103_r44860 и о сборке python-EFL "bindings" для openSUSE-11.2. там же вы можете найти кучу новых пакетов, типа виртуальной клавиатуры на EFL/elementary или же медиа-центра "Canola" (который пока не пашет должным образом, ибо EFL у нас дюже "новэнький", а "canola" хочет более старых версий...)
всем удачи и творческих узбеков в новом, 2010-ом, году!
*/
Показаны сообщения с ярлыком OBS. Показать все сообщения
Показаны сообщения с ярлыком OBS. Показать все сообщения
пятница, 8 января 2010 г.
суббота, 14 ноября 2009 г.
reiser4 для openSUSE-11.2
/*
И вновь продолжается бой,
И сердцу тревожно в груди.
И Ленин - такой молодой,
И юный Октябрь впереди!
/Н. Добронравов, 1974/
собсно продолжение "весёлой (1)" "истории (2)" с ура-патриотическим шовинистским наклоном.
потихоньку перечисляем причины, по которым задерживается/откладывается/херится компиляция рабочего софта для openSUSE-11.2:
* в текущей версии "binutils-2.19.51" кто-то умный (ОЧЕНЬ умный, да-да-да!) взял и догадался запретить "ld" делать статическую линковку бинарей по умолчанию.
абзац. передай CFLAGS параметр "-static" и можешь быть свободен (вопрос на засыпку: "а сколько проверок тех же autotools применяют статику для тестирования окружения?!"). из-за этого в Factory накрылась сборка "reiser4progs" и ваш покорный слуга "осилил" первым (damn, i'm good!) поднять "Титаник" из глубин:
пруфлинк :)
после чего встал раком вопрос о прикрутке ядрёного модуля для полноты ощущений. есть три варианта успешного развития событий:
1) тянем с kernel.org сырцы ядра, патчим по своему усмотрению, ставим;
2) ковыряем текущие исходники от SuSE (с учётом того, что некоторые патчи из "обоймы" reiser4 уже наложены);
3) берём diff-ы reiser4 и, радостные, лепим из них сырцы ядрёного модуля для последующей сборки по фэн-шую, выкладываем в OBS, лепим src.rpm и развлекаемся по полной программе матёрого эксгибициониста.
* история нумеро уно (светлая и радостная)
теперь по-порядку. при любых раскладах нам понадобятся исходники ядра от SuSE (чтобы припухнуть от количества патчей, выбрать нужные и хоть немного, но сообразить, почему ядро от SuSE заведётся даже на Gentoo, установленной на Mac Book, с поддержкой всего найденного оборудования):
> sudo zypper si kernel-source
для простоты из "/usr/src/packages/SOURCES/patches.suse.tar.bz2#utar/patches.suse/" дёргаем лишь файл "bootsplash" как пример. вам что-то ещё нужно?! - не стесняйтесь. можно себе позволить и правой рукой, и левой и обеими одновременно. именно тот случай.
частенько встречаются индивидуумы с синдромом "мля, это говно нибуя не компилиццо!". им может помочь (в плане уменьшения расхода нервных клеток ессно, IQ приходит с опытом/возрастом... правда не ко всем... и не всегда...) простенький конструкт (дёшево и сердито, рекомендую кстати):
> sudo zypper in ccache
> mkdir $HOME/bin
> ln -s /usr/bin/ccache $HOME/bin/cc
> ln -s /usr/bin/ccache $HOME/bin/gcc
> ln -s /usr/bin/ccache $HOME/bin/g++
> export PATH="$HOME/bin:$PATH"
если вы уже упёрли kernel-2.6.31.6 (налетай, падхады!), а с офсайта оттяпали набор reiser4 патчей для пионэров - то удача близка, как никогда ранее! осталось всего-ничего: состыковать это богатство в единое целое (Кама-Сутра нам поможет), компильнуть, инстальнуть и ребутнуться.
некоторые индивидуумы перед оправлением большой нужды не заботятся о наличии "облагораживающих рулонов бумаги" поблизости. "не наш метод"(с). выбор каталога для исходников ядра (KERNELSOURCEDIR) и выбор каталога для собранных, но не установленных, файлов (KERNELBUILDDIR) очень важен. хотя бы потому, что в процессе сборки они могут занять до 4-ёх Gb дискового пространства, а то и поболее (если мы лепим модули для разных вариантов настроек ядра). все детали очень хорошо описаны в файле "Linux-2.6*/README" - изучите. и подумайте о добавлении команд "make prepare && make scripts" в рутинный процесс компиляции.
для простоты эксперимента не будем мудрить (распакуем исходники ядра в "/usr/src/"):
> export KERNELSOURCEDIR=/usr/src/linux-2.6.31.6
> export KERNELBUILDDIR=/usr/src/linux-2.6.31.6
готовимся отпатчить исходники по самое "не балуй!":
> mkdir /usr/src/patch_reiser4
> cd /usr/src/patch_reiser4/
> tar xf $PATH_TO_SOURCE/reiser4-for-2.6.31.patch.bz2
> cd /usr/src/patch_reiser4/linux-2.6.3?/
> mkdir my_additional_patches
> cd ./my_additional_patches/
> cp $PATH_TO_SOURCE/bootsplash ./bootsplash.diff
решаем шкурный вопрос о патчах reiser4 *.diff файлов. либо делаем:
> mv /usr/src/linux-2.6.31.6 /usr/src/linux-2.6.31 # и корректируем переменные KERNEL*DIR
либо
> cd /usr/src/patch_reiser4/linux-2.6.31/
> find ./ -type f -exec sed -i 's|\ linux\-2\.6\.31|\ linux\-2\.6\.31\.6|' {} \;
приводим в порядок "bootsplash.diff" заменяя аморфные " a/" и " b/" на имя каталога с нашим новым ядром - "linux-2.6.31.6" или что-там-у-вас-получилось.
настал торжественный момент! "собирайтесь, девки, в кучу, я вам чучу отчебучу!" (наше дерево патчей - в "/usr/src/patch_reiser4/linux-2.6.31/"!)
> cd /usr/src/patch_reiser4/
> find ./linux-2.6.31/ -type f -exec cat {} \; | patch -d /usr/src/ -p0 -i -
если вас устраивает текущее ядро и нет желания изображать из себя "великого оптимизатора" - пришло время расслабиться:
> cd $KERNELSOURCEDIR/
> zcat /proc/config.gz > ./.config
> make oldconfig
> make O="$KERNELBUILDDIR"
> sudo make O="$KERNELBUILDDIR" modules_install install
новые записи уже добавились в меню grub-а, хотя можно и проверить/поправить дефолт:
> sudo vim /boot/grub/menu.lst
можно (и нужно) перегрузить машину на новое ядро и (ежели таки оргазм) - прислать аффтару пиффка для рыффка. последние штрихи:
> sudo depmod -a # на всякий...
> modprobe -v reiser4
insmod /lib/modules/2.6.31.6-0.1-desktop/kernel/lib/zlib_deflate/zlib_deflate.ko
insmod /lib/modules/2.6.31.6-0.1-desktop/kernel/lib/lzo/lzo_compress.ko
insmod /lib/modules/2.6.31.6-0.1-desktop/kernel/lib/lzo/lzo_decompress.ko
insmod /lib/modules/2.6.31.6-0.1-desktop/kernel/fs/reiser4/reiser4.ko
гы :). "Отдохнул - убери за собой!"(с):
> cd $KERNELSOURCEDIR/
> make clean
> zcat /proc/config.gz > ./.config
> make oldconfig
> make prepare
> make scripts
в остатке у нас няшный latest-kernel-stable с поддержкой bootsplash (выглядит как "родной"!) и reiser4 (надеюсь, что мои пакетики с "reiser4progs" уже установлены, да?). дерево исходников очищено от мусора и можно переходить к
* истории второй, печальной и тупой...
хвастать, признаю, пока нечем. первый яростный натиск потерпел фиаско. финал был комичен - загруженная машина где ничерта не работало, пришлось ядро переставлять с dvd (ибо модуль сетевой карточки тоже не загружалсо...). много про себя думал. в разных позах, обстоятельно. итак, на ваш суд выносим "тернистый путь ошибок трудных..."
засада начинается с разблядовки ядра на составляющие по-умолчанию (примерно так это выглядит):
> rpm -qa | grep kernel | sort
kernel-debug-devel-2.6.31.5-0.1.1.i586
kernel-default-devel-2.6.31.5-0.1.1.i586
kernel-desktop-2.6.31.5-0.1.1.i586
kernel-desktop-base-2.6.31.5-0.1.1.i586
kernel-desktop-devel-2.6.31.5-0.1.1.i586
kernel-firmware-20090821-4.1.noarch
kernel-pae-devel-2.6.31.5-0.1.1.i586
kernel-source-2.6.31.5-0.1.1.noarch
kernel-syms-2.6.31.5-0.1.1.i586
kernel-xen-devel-2.6.31.5-0.1.1.i586
linux-kernel-headers-2.6.31-3.4.noarch
получается, что алгоритм решения задачи должен быть примерно следующим:
a) "совместить" "объектные" файлы текущего ядра с основным деревом исходников - т.е. получить единое дерево исходников без разбивок на flavors (pae, xen, default, desktop, etc...) для ТЕКУЩЕГО! работающего ядра! т.е. сделать так, чтобы модуль мог быть подгружен в работающее ядро от SuSE!
b) удостовериться, что новое дерево стабильно и функционально (т.е. можно смело собирать бинари)
c) пропатчить новое дерево reiser4 diff-ами
d) собрать модуль reiser4, загрузить в текущее рабочее ядро
e) испытать оргазм
либо сразу отказаться от выпендрёжа и перейти к "третьему варианту" - подготовке исходников для нового модуля ядра и сборке в соответствии с CODE11.
нетрудно догадаться, что в творческом порыве аффтар не стал выполнять пункты a) и b), после чего ухитрился накомпилять ядро с новыми модулями, перетереть, старое, ребутнуться и "качнуть глибцов" по самые гланды. если кто-то думает, что всё прошло без сучка и задоринки (без разбора rej файлов, дополнительных патчей исходников...) - то он "наивный чукотский юноша". аффтар вспомнил всё и всех.
на вторую попытку силёнок не хватило. энтузиастам предложу ознакомиться с:
> ls /usr/src/linux-2.6.*-obj/$ARCH/$YOUR_FLAVOR
на предмет "соединения" с основным деревом исходников. иначе "не пойдёт!"(c). патчи - аналогично, НО:
N.B.: просмотрите в файлах (желательно пройтись по всем уже наложенным ессно)
/usr/src/packages/SOURCES/patches.suse.tar.bz2
/usr/src/packages/SOURCES/patches.fixes.tar.bz2
какие из патчей для "reiser4" уже присутствуют я ядре openSuSE и измените содержимое reiser4 diff-ов соответственно! иначе... будете как аффтар - ССЗБ.
делать "make install" не надо, тупо скопируйте "reiser4.ko" в "/lib/modules/"`uname -r`"/updates/" и, если всё хорошо, сделайте:
> sudo depmod -a
> modprobe -v reiser4
ня! (или как там получится по обстоятельствам...)
* история третья, коротенькая, но оптимистичная...
есть у меня махонький такой репо для экспериментов в часы досуга:
drivers
как только - так сразу там всё и появится. кому оно надо - загрузят "*.src.rpm" и разберутся без соплей. остальные упрут "reiser4-kmp-$FLAVOR" и будут похрюкивать от удовольствия.
* послесловие:
для модулей ядра стоит быть очень аккуратным с командой "strip". сделайте копию модуля, удалите debug символы, проверьте, загружается ли модуль после этого и только потом "режьте по живому". если нет ОСТРЕЙШЕЙ необходимости - оставьте модули как "not stripped".
вот такая вот музыка, такая, блин, Вечная Молодость...
на закуску перечислим прочие "заслуги" перед "родиной":
* в Enlightenment repo собрали новый снэпшот "fltk2" и "Dillo-2.1.1" (с поддержкой https/ssl - можно даже на gmail.com почту мусолить)
* там же в процессе грандиозная чистка spec-файлов от мусора
* там же обновлены практически все пакеты на текущие версии (включая git/svn/etc...)
* в игрушечном репо собрана новая версия "freetype2-lcd" и "igmpproxy" пропатчен для сборки/работы на openSUSE-11.2
* продолжаем готовить релиз SOAD Linux на базе oS-11.2 - тут всё грустно, ибо многие компоненты, что работают на openSUSE-11.1 в OBS не "портированы" на oS-11.2. да и прочих забот хватает.
пока так. поживём, а там видно будет.
всем удачи!
*/
И вновь продолжается бой,
И сердцу тревожно в груди.
И Ленин - такой молодой,
И юный Октябрь впереди!
/Н. Добронравов, 1974/
собсно продолжение "весёлой (1)" "истории (2)" с ура-патриотическим шовинистским наклоном.
потихоньку перечисляем причины, по которым задерживается/откладывается/херится компиляция рабочего софта для openSUSE-11.2:
* в текущей версии "binutils-2.19.51" кто-то умный (ОЧЕНЬ умный, да-да-да!) взял и догадался запретить "ld" делать статическую линковку бинарей по умолчанию.
абзац. передай CFLAGS параметр "-static" и можешь быть свободен (вопрос на засыпку: "а сколько проверок тех же autotools применяют статику для тестирования окружения?!"). из-за этого в Factory накрылась сборка "reiser4progs" и ваш покорный слуга "осилил" первым (damn, i'm good!) поднять "Титаник" из глубин:
пруфлинк :)
после чего встал раком вопрос о прикрутке ядрёного модуля для полноты ощущений. есть три варианта успешного развития событий:
1) тянем с kernel.org сырцы ядра, патчим по своему усмотрению, ставим;
2) ковыряем текущие исходники от SuSE (с учётом того, что некоторые патчи из "обоймы" reiser4 уже наложены);
3) берём diff-ы reiser4 и, радостные, лепим из них сырцы ядрёного модуля для последующей сборки по фэн-шую, выкладываем в OBS, лепим src.rpm и развлекаемся по полной программе матёрого эксгибициониста.
* история нумеро уно (светлая и радостная)
теперь по-порядку. при любых раскладах нам понадобятся исходники ядра от SuSE (чтобы припухнуть от количества патчей, выбрать нужные и хоть немного, но сообразить, почему ядро от SuSE заведётся даже на Gentoo, установленной на Mac Book, с поддержкой всего найденного оборудования):
> sudo zypper si kernel-source
для простоты из "/usr/src/packages/SOURCES/patches.suse.tar.bz2#utar/patches.suse/" дёргаем лишь файл "bootsplash" как пример. вам что-то ещё нужно?! - не стесняйтесь. можно себе позволить и правой рукой, и левой и обеими одновременно. именно тот случай.
частенько встречаются индивидуумы с синдромом "мля, это говно нибуя не компилиццо!". им может помочь (в плане уменьшения расхода нервных клеток ессно, IQ приходит с опытом/возрастом... правда не ко всем... и не всегда...) простенький конструкт (дёшево и сердито, рекомендую кстати):
> sudo zypper in ccache
> mkdir $HOME/bin
> ln -s /usr/bin/ccache $HOME/bin/cc
> ln -s /usr/bin/ccache $HOME/bin/gcc
> ln -s /usr/bin/ccache $HOME/bin/g++
> export PATH="$HOME/bin:$PATH"
если вы уже упёрли kernel-2.6.31.6 (налетай, падхады!), а с офсайта оттяпали набор reiser4 патчей для пионэров - то удача близка, как никогда ранее! осталось всего-ничего: состыковать это богатство в единое целое (Кама-Сутра нам поможет), компильнуть, инстальнуть и ребутнуться.
некоторые индивидуумы перед оправлением большой нужды не заботятся о наличии "облагораживающих рулонов бумаги" поблизости. "не наш метод"(с). выбор каталога для исходников ядра (KERNELSOURCEDIR) и выбор каталога для собранных, но не установленных, файлов (KERNELBUILDDIR) очень важен. хотя бы потому, что в процессе сборки они могут занять до 4-ёх Gb дискового пространства, а то и поболее (если мы лепим модули для разных вариантов настроек ядра). все детали очень хорошо описаны в файле "Linux-2.6*/README" - изучите. и подумайте о добавлении команд "make prepare && make scripts" в рутинный процесс компиляции.
для простоты эксперимента не будем мудрить (распакуем исходники ядра в "/usr/src/"):
> export KERNELSOURCEDIR=/usr/src/linux-2.6.31.6
> export KERNELBUILDDIR=/usr/src/linux-2.6.31.6
готовимся отпатчить исходники по самое "не балуй!":
> mkdir /usr/src/patch_reiser4
> cd /usr/src/patch_reiser4/
> tar xf $PATH_TO_SOURCE/reiser4-for-2.6.31.patch.bz2
> cd /usr/src/patch_reiser4/linux-2.6.3?/
> mkdir my_additional_patches
> cd ./my_additional_patches/
> cp $PATH_TO_SOURCE/bootsplash ./bootsplash.diff
решаем шкурный вопрос о патчах reiser4 *.diff файлов. либо делаем:
> mv /usr/src/linux-2.6.31.6 /usr/src/linux-2.6.31 # и корректируем переменные KERNEL*DIR
либо
> cd /usr/src/patch_reiser4/linux-2.6.31/
> find ./ -type f -exec sed -i 's|\ linux\-2\.6\.31|\ linux\-2\.6\.31\.6|' {} \;
приводим в порядок "bootsplash.diff" заменяя аморфные " a/" и " b/" на имя каталога с нашим новым ядром - "linux-2.6.31.6" или что-там-у-вас-получилось.
настал торжественный момент! "собирайтесь, девки, в кучу, я вам чучу отчебучу!" (наше дерево патчей - в "/usr/src/patch_reiser4/linux-2.6.31/"!)
> cd /usr/src/patch_reiser4/
> find ./linux-2.6.31/ -type f -exec cat {} \; | patch -d /usr/src/ -p0 -i -
если вас устраивает текущее ядро и нет желания изображать из себя "великого оптимизатора" - пришло время расслабиться:
> cd $KERNELSOURCEDIR/
> zcat /proc/config.gz > ./.config
> make oldconfig
> make O="$KERNELBUILDDIR"
> sudo make O="$KERNELBUILDDIR" modules_install install
новые записи уже добавились в меню grub-а, хотя можно и проверить/поправить дефолт:
> sudo vim /boot/grub/menu.lst
можно (и нужно) перегрузить машину на новое ядро и (ежели таки оргазм) - прислать аффтару пиффка для рыффка. последние штрихи:
> sudo depmod -a # на всякий...
> modprobe -v reiser4
insmod /lib/modules/2.6.31.6-0.1-desktop/kernel/lib/zlib_deflate/zlib_deflate.ko
insmod /lib/modules/2.6.31.6-0.1-desktop/kernel/lib/lzo/lzo_compress.ko
insmod /lib/modules/2.6.31.6-0.1-desktop/kernel/lib/lzo/lzo_decompress.ko
insmod /lib/modules/2.6.31.6-0.1-desktop/kernel/fs/reiser4/reiser4.ko
гы :). "Отдохнул - убери за собой!"(с):
> cd $KERNELSOURCEDIR/
> make clean
> zcat /proc/config.gz > ./.config
> make oldconfig
> make prepare
> make scripts
в остатке у нас няшный latest-kernel-stable с поддержкой bootsplash (выглядит как "родной"!) и reiser4 (надеюсь, что мои пакетики с "reiser4progs" уже установлены, да?). дерево исходников очищено от мусора и можно переходить к
* истории второй, печальной и тупой...
хвастать, признаю, пока нечем. первый яростный натиск потерпел фиаско. финал был комичен - загруженная машина где ничерта не работало, пришлось ядро переставлять с dvd (ибо модуль сетевой карточки тоже не загружалсо...). много про себя думал. в разных позах, обстоятельно. итак, на ваш суд выносим "тернистый путь ошибок трудных..."
засада начинается с разблядовки ядра на составляющие по-умолчанию (примерно так это выглядит):
> rpm -qa | grep kernel | sort
kernel-debug-devel-2.6.31.5-0.1.1.i586
kernel-default-devel-2.6.31.5-0.1.1.i586
kernel-desktop-2.6.31.5-0.1.1.i586
kernel-desktop-base-2.6.31.5-0.1.1.i586
kernel-desktop-devel-2.6.31.5-0.1.1.i586
kernel-firmware-20090821-4.1.noarch
kernel-pae-devel-2.6.31.5-0.1.1.i586
kernel-source-2.6.31.5-0.1.1.noarch
kernel-syms-2.6.31.5-0.1.1.i586
kernel-xen-devel-2.6.31.5-0.1.1.i586
linux-kernel-headers-2.6.31-3.4.noarch
получается, что алгоритм решения задачи должен быть примерно следующим:
a) "совместить" "объектные" файлы текущего ядра с основным деревом исходников - т.е. получить единое дерево исходников без разбивок на flavors (pae, xen, default, desktop, etc...) для ТЕКУЩЕГО! работающего ядра! т.е. сделать так, чтобы модуль мог быть подгружен в работающее ядро от SuSE!
b) удостовериться, что новое дерево стабильно и функционально (т.е. можно смело собирать бинари)
c) пропатчить новое дерево reiser4 diff-ами
d) собрать модуль reiser4, загрузить в текущее рабочее ядро
e) испытать оргазм
либо сразу отказаться от выпендрёжа и перейти к "третьему варианту" - подготовке исходников для нового модуля ядра и сборке в соответствии с CODE11.
нетрудно догадаться, что в творческом порыве аффтар не стал выполнять пункты a) и b), после чего ухитрился накомпилять ядро с новыми модулями, перетереть, старое, ребутнуться и "качнуть глибцов" по самые гланды. если кто-то думает, что всё прошло без сучка и задоринки (без разбора rej файлов, дополнительных патчей исходников...) - то он "наивный чукотский юноша". аффтар вспомнил всё и всех.
на вторую попытку силёнок не хватило. энтузиастам предложу ознакомиться с:
> ls /usr/src/linux-2.6.*-obj/$ARCH/$YOUR_FLAVOR
на предмет "соединения" с основным деревом исходников. иначе "не пойдёт!"(c). патчи - аналогично, НО:
N.B.: просмотрите в файлах (желательно пройтись по всем уже наложенным ессно)
/usr/src/packages/SOURCES/patches.suse.tar.bz2
/usr/src/packages/SOURCES/patches.fixes.tar.bz2
какие из патчей для "reiser4" уже присутствуют я ядре openSuSE и измените содержимое reiser4 diff-ов соответственно! иначе... будете как аффтар - ССЗБ.
делать "make install" не надо, тупо скопируйте "reiser4.ko" в "/lib/modules/"`uname -r`"/updates/" и, если всё хорошо, сделайте:
> sudo depmod -a
> modprobe -v reiser4
ня! (или как там получится по обстоятельствам...)
* история третья, коротенькая, но оптимистичная...
есть у меня махонький такой репо для экспериментов в часы досуга:
drivers
как только - так сразу там всё и появится. кому оно надо - загрузят "*.src.rpm" и разберутся без соплей. остальные упрут "reiser4-kmp-$FLAVOR" и будут похрюкивать от удовольствия.
* послесловие:
для модулей ядра стоит быть очень аккуратным с командой "strip". сделайте копию модуля, удалите debug символы, проверьте, загружается ли модуль после этого и только потом "режьте по живому". если нет ОСТРЕЙШЕЙ необходимости - оставьте модули как "not stripped".
вот такая вот музыка, такая, блин, Вечная Молодость...
на закуску перечислим прочие "заслуги" перед "родиной":
* в Enlightenment repo собрали новый снэпшот "fltk2" и "Dillo-2.1.1" (с поддержкой https/ssl - можно даже на gmail.com почту мусолить)
* там же в процессе грандиозная чистка spec-файлов от мусора
* там же обновлены практически все пакеты на текущие версии (включая git/svn/etc...)
* в игрушечном репо собрана новая версия "freetype2-lcd" и "igmpproxy" пропатчен для сборки/работы на openSUSE-11.2
* продолжаем готовить релиз SOAD Linux на базе oS-11.2 - тут всё грустно, ибо многие компоненты, что работают на openSUSE-11.1 в OBS не "портированы" на oS-11.2. да и прочих забот хватает.
пока так. поживём, а там видно будет.
всем удачи!
*/
четверг, 12 ноября 2009 г.
не было печали...
/*
- Вовочка, выйди из класса и зайди, как это делает твой папа!
- ... ща.
пинком выносит дверь с коробкой, рвёт пуговицы на рубашке и орёт в охуевший и притихший класс:
- Шо, с-суки, не ждали?!
история не нова. в очередной раз "тихо и незаметно" на весь OBS спустили новые проверочные пресеты из Factory. "... как это мило...". вроде бы радоваться надо, но... смотрим:
кривые зависимости в пакете
проблемы с автоконфигурацией устройств (заметим мимоходом, что alsaconf теперь "магёт" только ISA карточки и легко ломает нормальную рабочую настройку)
Top 100 - наши, мля, чемпионы...
на этом весёленьком, в цветочек, фоне новые проверки иначе как издевательскими не назовёшь. о начале этой вечеринки можно пофтыкать в одной из моих старых заметок. новый "хит сезона":
+ /usr/lib/rpm/suse_update_desktop_file.sh -r elementary_test Utility Accessibility
ERROR: //tmp/elementary-svn_20091112_r43627-build/usr/share/applications/elementary_test.desktop is not an UTF-8 file
+ exit 1
error: Bad exit status from /var/tmp/rpm-tmp.26363 (%install)
5 баллов. т.е.:
1) мы имеем АБСОЛЮТНО КОШЕРНЫЙ "elementary_test.desktop" файл
2) скармливаем его макросу "%suse_update_desktop_file ", чтобы эта тварь добавила строку "X-SuSE-translate=true" (исключительно специфика SuSE)
3) мы выучили все freedesktop-овы спеки на desktop файло для меню и всё делаем без косяков и по фэн-шую!
4) мы всё равно идём нахуй, ибо файл не UTF-8! (патамучта, бля, все символы "внутри" этого файла в пределах ASCII таблицы и ессно, что он и определяется как ASCII text! yeah baby, yeah!)
если кто-то решит ещё и "*.spec" файлы на UTF проверять - буду старательно рисовать матерные камменты. понятно, что по сути это мелочи, что было/есть благое намерение как-то поправить дела с локализацией и т.п. и т.д.. но на фоне существующих багов в ПО подобные "тонкости и политесы" явно не к месту (да и не ко времени).
возврат в Linux восле OpenBSD проходит тяжело. куда ни глянь - всюду бардак и нихера толком не работает как положено. примеры:
1) в OpenBSD-current моя wi-fi карточка (RT2500 802.11g - RaLink) - на wpa2 выдала "честные" 802.11g и держала канал как трактор накатанную колею - на полную. Linux - сперва прыгаешь с патчами, чтобы monitor mode нормально заработал (aircrack2), потом...
2) звук: в OpenBSD-current всё из коробки согласно списку поддерживаемого оборудования. Linux - ... (отсоси, потом проси...)
3) экспансия xml-конфигов в Linux без удобных средств для их редактирования (достаточно один раз поработать в Mac OS X чтобы понять, как это "для людей" делать надо)
4) Linux: бардак с hal/devkit/polkit/etc... - песнь. есть спеки - но хер поймёшь, что из этих спеков ноне работает. пример: требуется при помощи hal монтировать все "ufs" партиции с опцией "ufstype=44bsd". раньше было просто. добавляем в policy:
<merge key="storage.policy.default.mount_option.ufstype=44bsd" type="bool">true</merge>
<append key="volume.policy.mount_option.ufstype=44bsd" type="bool">true</append>
и мы в шоколаде. все строго по спекам. но нет, именно эти опции надо похерить и отдать на откуп DE (Desktop Environment), а то, что многие предпочитают не использовать DE и обходиться простыми WM-ами (Window Manager) - никого не парит.
и т.д. и т.п.. в результате получается, что c удовольствием рисуешь вот такие странички wiki, и смотришь на Linux чуток... по-другому. enterprise-то конечно из OpenBSD никакой, но...
скоро в моих репо будет всем обновление Enlightenment-DR17-svn (очень удачный и стабильный снэпшот получился) - пользуйте.
на этой мажорной ноте позвольте поздравить всех с релизом openSuSE-11.2 и откланяться.
удачи.
*/
- Вовочка, выйди из класса и зайди, как это делает твой папа!
- ... ща.
пинком выносит дверь с коробкой, рвёт пуговицы на рубашке и орёт в охуевший и притихший класс:
- Шо, с-суки, не ждали?!
история не нова. в очередной раз "тихо и незаметно" на весь OBS спустили новые проверочные пресеты из Factory. "... как это мило...". вроде бы радоваться надо, но... смотрим:
кривые зависимости в пакете
проблемы с автоконфигурацией устройств (заметим мимоходом, что alsaconf теперь "магёт" только ISA карточки и легко ломает нормальную рабочую настройку)
Top 100 - наши, мля, чемпионы...
на этом весёленьком, в цветочек, фоне новые проверки иначе как издевательскими не назовёшь. о начале этой вечеринки можно пофтыкать в одной из моих старых заметок. новый "хит сезона":
+ /usr/lib/rpm/suse_update_desktop_file.sh -r elementary_test Utility Accessibility
ERROR: //tmp/elementary-svn_20091112_r43627-build/usr/share/applications/elementary_test.desktop is not an UTF-8 file
+ exit 1
error: Bad exit status from /var/tmp/rpm-tmp.26363 (%install)
5 баллов. т.е.:
1) мы имеем АБСОЛЮТНО КОШЕРНЫЙ "elementary_test.desktop" файл
2) скармливаем его макросу "%suse_update_desktop_file ", чтобы эта тварь добавила строку "X-SuSE-translate=true" (исключительно специфика SuSE)
3) мы выучили все freedesktop-овы спеки на desktop файло для меню и всё делаем без косяков и по фэн-шую!
4) мы всё равно идём нахуй, ибо файл не UTF-8! (патамучта, бля, все символы "внутри" этого файла в пределах ASCII таблицы и ессно, что он и определяется как ASCII text! yeah baby, yeah!)
если кто-то решит ещё и "*.spec" файлы на UTF проверять - буду старательно рисовать матерные камменты. понятно, что по сути это мелочи, что было/есть благое намерение как-то поправить дела с локализацией и т.п. и т.д.. но на фоне существующих багов в ПО подобные "тонкости и политесы" явно не к месту (да и не ко времени).
возврат в Linux восле OpenBSD проходит тяжело. куда ни глянь - всюду бардак и нихера толком не работает как положено. примеры:
1) в OpenBSD-current моя wi-fi карточка (RT2500 802.11g - RaLink) - на wpa2 выдала "честные" 802.11g и держала канал как трактор накатанную колею - на полную. Linux - сперва прыгаешь с патчами, чтобы monitor mode нормально заработал (aircrack2), потом...
2) звук: в OpenBSD-current всё из коробки согласно списку поддерживаемого оборудования. Linux - ... (отсоси, потом проси...)
3) экспансия xml-конфигов в Linux без удобных средств для их редактирования (достаточно один раз поработать в Mac OS X чтобы понять, как это "для людей" делать надо)
4) Linux: бардак с hal/devkit/polkit/etc... - песнь. есть спеки - но хер поймёшь, что из этих спеков ноне работает. пример: требуется при помощи hal монтировать все "ufs" партиции с опцией "ufstype=44bsd". раньше было просто. добавляем в policy:
<merge key="storage.policy.default.mount_option.ufstype=44bsd" type="bool">true</merge>
<append key="volume.policy.mount_option.ufstype=44bsd" type="bool">true</append>
и мы в шоколаде. все строго по спекам. но нет, именно эти опции надо похерить и отдать на откуп DE (Desktop Environment), а то, что многие предпочитают не использовать DE и обходиться простыми WM-ами (Window Manager) - никого не парит.
и т.д. и т.п.. в результате получается, что c удовольствием рисуешь вот такие странички wiki, и смотришь на Linux чуток... по-другому. enterprise-то конечно из OpenBSD никакой, но...
скоро в моих репо будет всем обновление Enlightenment-DR17-svn (очень удачный и стабильный снэпшот получился) - пользуйте.
на этой мажорной ноте позвольте поздравить всех с релизом openSuSE-11.2 и откланяться.
удачи.
*/
вторник, 24 марта 2009 г.
OBS. ловкость рук и никакого мошенства...
/*
Господа и Дамы,
мы продолжаем крайне непопулярную серию заметок, посвящённых openSUSE Build Service. ежели Вам оно не надо - самое время заняться чем-то другим. а мы продолжим, с Божьей помощью...
Боже, Царя храни!
Сильный, державный,
Царствуй на славу нам;
Царствуй на страх врагам,
Царь православный!
Боже, Царя храни!
/1833, Василий Андреевич Жуковский/
поводом к этим зарисовкам послужил трэд забавного форума, где раком встал очевидный недостаток информации как таковой. трэд в принципе "ни-о-чём", но кое-что можно вытянуть и оттуда. сразу же оговорюсь - учите английский и не надейтесь на локализацию АКТУАЛЬНОЙ документации. то, что присутствует на "нащих" официальных сайтах (примерчик), зачастую вызывает желание громко расхохотаться от умиления (на самом деле привыкайте рыть доки самостоятельно).
итак, давайте прикинем, что входит в "краткий перечень инструкций по работе с OBS" (дополнения приветствуются):
* вводная в OBS
* инструкция, как компилять для разных дистрибутивов
* ликбез, краткая версия
* ликбез, версия для любознательных
* Tips and Tricks - эт уже пойдёт веселее
* базовые приёмы работы из командной строки
вроде как всё, но это только затравка. есть отдельные документы, представляющие определённую ценность (по крайней мере на первых этапах). вы можете "стоять на своём" (любимая пытка Бормана кстати), но таки приведу списочек:
* статейка о махровом коллаборационизме или как работать над проектом сообща
* "чёрная метка" одноглазого Сильвера - обязательно к ознакомлению. если Вам это не подходит - лучше приложите свои силы в Пакман-е
* проверки rpmlint
* правила для пакетов с shared libraries. по хорошему в дистрибутиве не должно быть статически слинкованных библилтек/бинарей, поэтому если вы собрались "упаковать" какую-нить завалящую либку, то обязательно прочтите это.
* глобальная дока "по всему", что касается специфики создания пакетов в openSUSE - желательно, чтобы вы хоть краем глаза пробежались по содержанию.
* работа с модулями ядра. если кто недопёр о чём речь, то шаблоны Code9 и Code10 выкладываю отдельно. также выкладываю линк на дивный скриптец - extract_kABI. коли вы ни ухом ни рылом ап чём речь, то замечу, что kABI - это аббревиатура от "kernel Application Binary Interface". дивная штуковина. иногда бывают чудеса и енто самое kABI не меняется при смене версии ядра для какого-то модуля, что позволяет ему (модулю) сукесфули функционировать на благо Царя и Отечества без перекомпиляции. в такие моменты понимаешь, что оргазм - ничто, по сравнению с ... таким работающим модулем...
для начала вроде должно хватить. поскольку комментариев на первую заметку не было, то сделал вывод, что тема нахуй никому не впёрлась. не обессудьте.
некоторые товарищи продвигают идею, что комфоргная работа с OBS возможна при помощи "простого" браузера. лукавят сцуки, хотя... по мне так для работы необходим и браузер и "osc" - инструмент работы в командной строке. браузер как правило открывается на странице "Status Monitor" - мониторинг состояния всего проекта, чертовски удобно, а всё остальное делается при помощи командной строки. да и возможностей у "osc" на порядок больше.
вполне нормально, что при рисовании своего первого пакета/спек-файла и попытках разобраться с ошибками вы, вероятно, слегонца охуеете от количества найденных недочётов в двух строчках Вашего неповторимого спека. поэтому кратенько пробегусь по наиболее часто встречающимся макросам/(переменным), способным облегчить Ваш тяжкий труд (или свести Вас в могилу, ежели нет понимания, как оно работает и нахуя оно нам надо).
%{_tmppath} - макрос, который принято использовать при указании каталога, где будет происходить сборка. например BuildRoot: %{_tmppath}/%{name}-%{version}-build
%{name} - этот макрос содержит строку, что вы ввели как имя пакета
%{version} - соответственно версия пакета
%{_libdir} - в зависимости от архитектуры (x86; x86-64) и в соответствии с FHS (Filesystem Hierarchy Standard) указывает на директорию для установки библиотек (либок). в нашем случае это /usr/lib или /usr/lib64
%{_datadir} - директория для "данных" - /usr/share
%{_sysconfdir} - директория для конфигурационных файлов - /etc
%{_bindir} - бинарники - /usr/bin
%{_sbindir} - бинарники суперпользователя (рутовые) - /usr/sbin
%{_initrddir} - директория для скриптов, управляющих запуском/(остановкой, мониторингом и т.п.) сервисов/служб - /etc/init.d
%{_docdir} - для документации. обычно это - /usr/share/doc/packages/
%{_mandir} - наши "мэны" - /usr/share/man
%{buildroot} == $RPM_BUILD_ROOT == %{_tmppath}/%{name}-%{version}-build (это именно то, что вы внесли в BuildRoot: секцию спек-файла)
%{SOURCE} == $RPM_SOURCE_DIR/%{name}-%{version}.tar.* (Ваши исходники), соответственно если исходников (Source: ...) несколько, то %{SOURCE1} , %{SOURCE2} .... %{SOURCEn}
$RPM_SOURCE_DIR - в нашем случае это /usr/src/packages/SOURCES
%{py_ver} - версия установленного в системе пакета python. очень полезно использовать при сборке для разных платформ. например: %{_libdir}/python%{py_ver}/site-packages/* (пример из секции %files)
"прогрепать" все (ну или большинство) доступных вариантов можно в следующих файлах:
> rpm -ql rpm | grep macro
вот ещё статейка с более подробным описанием макросов - RPM_Macros.
перед тем, как вы будете рисовать строку "Group: blah-blah-blah", потрудитесь ознакомиться с RPM_Groups - регламентированными группами для rpm пакетов. если вам повезло и в пакете есть "*.desktop" файл, то учите макрос %suse_update_desktop_file и freedesktop-овы спеки на desktop файло для меню.
ежели кто подумал, что "это - пиздец, детка...", то чел круто ошибся, ибо о работе с модулями ядра мы поговорим в другой раз. сейчас чуток отсебятины.
допустим, что вы таки заколбасили пакетик в OBS, он собрался и краткий миг оргазма потряс ваши чресла. теперь предположим, что ваши исходники состоят всего из двух файлов (да, мы, бля, живём в идеальном мире!) - собсно затаренных сырцов и спек-файла. и тут возникла идея сделать апдейт. не знаю кто как, а я заебался в первый раз тыкать на кнопочки в броузере, ждать пока оно "прохавает", что пора что-то делать и т.п. поэтому поставил "osc" и потихоньку осваиваю эту команду по мере необходимости.
> osc help
> osc help НЕПОНЯТНАЯ_КОМАНДА
ну эт как-бы ясно. аз, буки, веди, глаголь и т.п.
> osc co PROJECT [PACKAGE] [FILE]
вытащит на локальный диск копию из OBS и далее развлекайтесь. для удобства лучше тащить сразу весь проект и делать бэкапы регулярно (на всякий). для себя набросал пару-тройку консольных команд для упрощения рутинных действий:
* апдейт OBS (то есть мы наколбасили что-то в локальной копии и хотим чтобы в OBS стало именно так, как и у нас на диске) для одного пакета. "становимся" (>cd) в PROJECT/PACKAGE и выполняем "> osc_up":
> cat `which osc_up `
#!/bin/sh
osc addremove && osc ci -m "updates, honey!"
#EOF
* смотрим логи (для openSUSE репозиториев!):
> cat `which osc_wl `
#!/bin/sh
if [ "$2" == "" ] ; then
arch="i586"
else
arch="x86_64"
fi
osc bl openSUSE_$1 $arch
#EOF
то есть "> osc_wl 11.1 1" покажет нам полный лог сборки пакета для openSUSE-11.1 (x86-64).
* глобальный апдейт проекта (из "локальной копии" -> в OBS, игнорируя мои служебные директории "snapshots" и "test"):
> cat update_from_local_to_OBS
#!/bin/sh
export components="`find ./ -maxdepth 1 -type d | sed 's/\.\///' | grep -v snapshots | grep -v test `"
for a1 in $components ; do
cd $a1
osc addremove && osc ci -m "sweet updates are roll-in!"
cd ../
done
#EOF
и последнее о чём хотел попиздеть - это о создании "One Click Install" файлов. что-то там на эту тему в приведённых ранее сцылках уже пробегало, так что коли не интересно - неволить не смею. пример, как это выглядит:
Тыц по сцылке!
и там красуются такие все из себя крутые файлы: E17_Base.ymp и E17_Metapackage.ymp. стоит только "клацнуть" по ним, как вылезет ненавязчивое предложение установить в систему хуеву тонну нужного и полезного софта. нра? то-то!
если кто-то думает, что надо локально создать именно "*.ymp" файлик по образу и подобию, а потом просто "закинуть" в репо - то этот кто-то безнадёжный романтик. время читать секцию Create_Patterns и пробовать свои силы.
единственное, что меня ломает учить - это OBS API. зарекаться не буду, хотя...
продолжение следует...
*/
Господа и Дамы,
мы продолжаем крайне непопулярную серию заметок, посвящённых openSUSE Build Service. ежели Вам оно не надо - самое время заняться чем-то другим. а мы продолжим, с Божьей помощью...
Боже, Царя храни!
Сильный, державный,
Царствуй на славу нам;
Царствуй на страх врагам,
Царь православный!
Боже, Царя храни!
/1833, Василий Андреевич Жуковский/
поводом к этим зарисовкам послужил трэд забавного форума, где раком встал очевидный недостаток информации как таковой. трэд в принципе "ни-о-чём", но кое-что можно вытянуть и оттуда. сразу же оговорюсь - учите английский и не надейтесь на локализацию АКТУАЛЬНОЙ документации. то, что присутствует на "нащих" официальных сайтах (примерчик), зачастую вызывает желание громко расхохотаться от умиления (на самом деле привыкайте рыть доки самостоятельно).
итак, давайте прикинем, что входит в "краткий перечень инструкций по работе с OBS" (дополнения приветствуются):
* вводная в OBS
* инструкция, как компилять для разных дистрибутивов
* ликбез, краткая версия
* ликбез, версия для любознательных
* Tips and Tricks - эт уже пойдёт веселее
* базовые приёмы работы из командной строки
вроде как всё, но это только затравка. есть отдельные документы, представляющие определённую ценность (по крайней мере на первых этапах). вы можете "стоять на своём" (любимая пытка Бормана кстати), но таки приведу списочек:
* статейка о махровом коллаборационизме или как работать над проектом сообща
* "чёрная метка" одноглазого Сильвера - обязательно к ознакомлению. если Вам это не подходит - лучше приложите свои силы в Пакман-е
* проверки rpmlint
* правила для пакетов с shared libraries. по хорошему в дистрибутиве не должно быть статически слинкованных библилтек/бинарей, поэтому если вы собрались "упаковать" какую-нить завалящую либку, то обязательно прочтите это.
* глобальная дока "по всему", что касается специфики создания пакетов в openSUSE - желательно, чтобы вы хоть краем глаза пробежались по содержанию.
* работа с модулями ядра. если кто недопёр о чём речь, то шаблоны Code9 и Code10 выкладываю отдельно. также выкладываю линк на дивный скриптец - extract_kABI. коли вы ни ухом ни рылом ап чём речь, то замечу, что kABI - это аббревиатура от "kernel Application Binary Interface". дивная штуковина. иногда бывают чудеса и енто самое kABI не меняется при смене версии ядра для какого-то модуля, что позволяет ему (модулю) сукесфули функционировать на благо Царя и Отечества без перекомпиляции. в такие моменты понимаешь, что оргазм - ничто, по сравнению с ... таким работающим модулем...
для начала вроде должно хватить. поскольку комментариев на первую заметку не было, то сделал вывод, что тема нахуй никому не впёрлась. не обессудьте.
некоторые товарищи продвигают идею, что комфоргная работа с OBS возможна при помощи "простого" браузера. лукавят сцуки, хотя... по мне так для работы необходим и браузер и "osc" - инструмент работы в командной строке. браузер как правило открывается на странице "Status Monitor" - мониторинг состояния всего проекта, чертовски удобно, а всё остальное делается при помощи командной строки. да и возможностей у "osc" на порядок больше.
вполне нормально, что при рисовании своего первого пакета/спек-файла и попытках разобраться с ошибками вы, вероятно, слегонца охуеете от количества найденных недочётов в двух строчках Вашего неповторимого спека. поэтому кратенько пробегусь по наиболее часто встречающимся макросам/(переменным), способным облегчить Ваш тяжкий труд (или свести Вас в могилу, ежели нет понимания, как оно работает и нахуя оно нам надо).
%{_tmppath} - макрос, который принято использовать при указании каталога, где будет происходить сборка. например BuildRoot: %{_tmppath}/%{name}-%{version}-build
%{name} - этот макрос содержит строку, что вы ввели как имя пакета
%{version} - соответственно версия пакета
%{_libdir} - в зависимости от архитектуры (x86; x86-64) и в соответствии с FHS (Filesystem Hierarchy Standard) указывает на директорию для установки библиотек (либок). в нашем случае это /usr/lib или /usr/lib64
%{_datadir} - директория для "данных" - /usr/share
%{_sysconfdir} - директория для конфигурационных файлов - /etc
%{_bindir} - бинарники - /usr/bin
%{_sbindir} - бинарники суперпользователя (рутовые) - /usr/sbin
%{_initrddir} - директория для скриптов, управляющих запуском/(остановкой, мониторингом и т.п.) сервисов/служб - /etc/init.d
%{_docdir} - для документации. обычно это - /usr/share/doc/packages/
%{_mandir} - наши "мэны" - /usr/share/man
%{buildroot} == $RPM_BUILD_ROOT == %{_tmppath}/%{name}-%{version}-build (это именно то, что вы внесли в BuildRoot: секцию спек-файла)
%{SOURCE} == $RPM_SOURCE_DIR/%{name}-%{version}.tar.* (Ваши исходники), соответственно если исходников (Source: ...) несколько, то %{SOURCE1} , %{SOURCE2} .... %{SOURCEn}
$RPM_SOURCE_DIR - в нашем случае это /usr/src/packages/SOURCES
%{py_ver} - версия установленного в системе пакета python. очень полезно использовать при сборке для разных платформ. например: %{_libdir}/python%{py_ver}/site-packages/* (пример из секции %files)
"прогрепать" все (ну или большинство) доступных вариантов можно в следующих файлах:
> rpm -ql rpm | grep macro
вот ещё статейка с более подробным описанием макросов - RPM_Macros.
перед тем, как вы будете рисовать строку "Group: blah-blah-blah", потрудитесь ознакомиться с RPM_Groups - регламентированными группами для rpm пакетов. если вам повезло и в пакете есть "*.desktop" файл, то учите макрос %suse_update_desktop_file и freedesktop-овы спеки на desktop файло для меню.
ежели кто подумал, что "это - пиздец, детка...", то чел круто ошибся, ибо о работе с модулями ядра мы поговорим в другой раз. сейчас чуток отсебятины.
допустим, что вы таки заколбасили пакетик в OBS, он собрался и краткий миг оргазма потряс ваши чресла. теперь предположим, что ваши исходники состоят всего из двух файлов (да, мы, бля, живём в идеальном мире!) - собсно затаренных сырцов и спек-файла. и тут возникла идея сделать апдейт. не знаю кто как, а я заебался в первый раз тыкать на кнопочки в броузере, ждать пока оно "прохавает", что пора что-то делать и т.п. поэтому поставил "osc" и потихоньку осваиваю эту команду по мере необходимости.
> osc help
> osc help НЕПОНЯТНАЯ_КОМАНДА
ну эт как-бы ясно. аз, буки, веди, глаголь и т.п.
> osc co PROJECT [PACKAGE] [FILE]
вытащит на локальный диск копию из OBS и далее развлекайтесь. для удобства лучше тащить сразу весь проект и делать бэкапы регулярно (на всякий). для себя набросал пару-тройку консольных команд для упрощения рутинных действий:
* апдейт OBS (то есть мы наколбасили что-то в локальной копии и хотим чтобы в OBS стало именно так, как и у нас на диске) для одного пакета. "становимся" (>cd) в PROJECT/PACKAGE и выполняем "> osc_up":
> cat `which osc_up `
#!/bin/sh
osc addremove && osc ci -m "updates, honey!"
#EOF
* смотрим логи (для openSUSE репозиториев!):
> cat `which osc_wl `
#!/bin/sh
if [ "$2" == "" ] ; then
arch="i586"
else
arch="x86_64"
fi
osc bl openSUSE_$1 $arch
#EOF
то есть "> osc_wl 11.1 1" покажет нам полный лог сборки пакета для openSUSE-11.1 (x86-64).
* глобальный апдейт проекта (из "локальной копии" -> в OBS, игнорируя мои служебные директории "snapshots" и "test"):
> cat update_from_local_to_OBS
#!/bin/sh
export components="`find ./ -maxdepth 1 -type d | sed 's/\.\///' | grep -v snapshots | grep -v test `"
for a1 in $components ; do
cd $a1
osc addremove && osc ci -m "sweet updates are roll-in!"
cd ../
done
#EOF
и последнее о чём хотел попиздеть - это о создании "One Click Install" файлов. что-то там на эту тему в приведённых ранее сцылках уже пробегало, так что коли не интересно - неволить не смею. пример, как это выглядит:
Тыц по сцылке!
и там красуются такие все из себя крутые файлы: E17_Base.ymp и E17_Metapackage.ymp. стоит только "клацнуть" по ним, как вылезет ненавязчивое предложение установить в систему хуеву тонну нужного и полезного софта. нра? то-то!
если кто-то думает, что надо локально создать именно "*.ymp" файлик по образу и подобию, а потом просто "закинуть" в репо - то этот кто-то безнадёжный романтик. время читать секцию Create_Patterns и пробовать свои силы.
единственное, что меня ломает учить - это OBS API. зарекаться не буду, хотя...
продолжение следует...
*/
среда, 18 марта 2009 г.
OBS - openSUSE Build Service или "Одна Баба Сказала..."
/*
дамы и господа,
это - первая заметка о некоторых трюках при работе с замечательным сервисом openSUSE/Novell - openSUSE Build Service. если Вас интересуют какие-то детали или Вы желаете задать вопрос - оставляйте комментарии. постараюсь ответить.
недавно прислали очень поучительный экспромт о занятиях с детишками в детском саду. его и буду использовать в качестве "оглавления". поехали...
Занятие для организованных детских групп ДДОУ "Детский садик Светлячок".
Тема: "Автодорожное движение".
Учитель громким голосом четко произносит фразу, оканчивая ее вопросительной интонацией.
Дети хором произносят ответ.
УЧИТЕЛЬ: Кто король далеких трасс?
ДЕТИ: КАМАЗ!
абсолютно верно и пгавильно подмечено! формат rpm - наше фсио! остальное - от лукавого. а как же убунту и ".deb"? - очень неудобно разбираться откуда ноги растут у "dh_make". другими словами: spec файл - это святая Библия, где всё написано от и до. если встретился непонятный макрос - например %configure - набираем:
> rpmbuild --eval %configure
и смотрим что именно он означает. хотим написать свой макрос? - легко! читаем:
man rpm
vim /usr/share/doc/packages/rpm/manual/macros
и заглянем в "/usr/share/doc/packages/rpm/manual/" из чистого любопытства - там таки есть что почитать перед сном. по сравнению с rpm другие форматы пакетов выглядят как набор костылей. и не надо мне рассказывать, что EBUILD (Gentoo) рулит. любое использование USE флага автоматом означает невозможность стандартизировать результат и, как следствие, непригодность этого поделия в Production. а все типа "оптимизации", получаемые при "гибкой" сборке, можно спустить в унитаз чуток обновив железо. кроме того, rpm никоим разом не мешает делать спецсборки софта для тех же кластерных вычислений или же для работы с видео (как пример).
Что же такое этот OBS (openSUSE Build Service)? это система, которая позволяет создавать пакеты для всех основных дистрибутивов Linux, включая RH, Debian, Ubuntu и иже с ними. ежели по-простому, то внутрь ты пихаешь исходники и инструкцию по сборке, а на выходе получаешь готовые красивые КОШЕРНЫЕ пакеты. кошерные - ибо существуют некоторые наборы правил, которые мейнтейнер (далее буду пользовать термин "упаковщик") обязан соблюдать. под правилами также подразумевается наличие систем проверок готовых пакетов. то бишь устанавливая пакет из OBS лузер (в теории) имеет возможность полностью проконтролировать сборку и увериться, что ставит "кошерный продукт".
УЧИТЕЛЬ: Кто гремит и весь в пыли?
ДЕТИ: Жигули!
УЧИТЕЛЬ: Кто проедет грязь игриво?
ДЕТИ: Нива!
УЧИТЕЛЬ: Кушай кашу "Геркулес", купит папа?
ДЕТИ: Мерседес!
для пользования OBS необходимо наличие учётной записи в Novell и посещение стартовой страницы для получения базовых инструкций. скорее всего вводная в OBS более подойдёт для первого знакомства с системой. нет ни малейшего желания пересказывать "бояны", поэтому сделаю следующие допущения:
* вы прониклись мощью и красотой решения, получили учётку в Novell, создали свой домашний проект и, при помощи Web-gui (броузера) сваяли свой первый пакет.
* пакет этот нихуя не собирался как надо до тех пор, пока вы не прорюхали великий смысл в строках "BuildRequires: список DEVEL-пакетов (через пробел), необходимых для сборки Вашего первенца"
* всё собралось, но не везде. вы ещё раз пофтыкали инструкцию как компилять для разных дистрибутивов, обматерили всех "умников", дающих разное название одинаковым сущностям/пакетвм, взмолились о глобальной стандартизации, но таки сваяли новый spec файл.
* оно даже собралось, но проверки собранного пакета сказали Вам, что сборка прошла не по фэн-шую и предложилисходить нахуй набраться побольше опыта и исправить замеченные недостатки.
* у Вас оформилось светлая мечта уебать аффторов "проверок" чем-нить тяжёлым по умной голове, послать всю затею с OBS куда подальше и "включить идиота" на полную катушку - "Какие мейнтейнеры? "ПРЕВЕД" надо говорить разработчикам. Очнитесь. Задача мейтейнеров проста как 2x2- собрать из сырцов бинарики, собрать их в пакеты с учетом зависимостей, и положить их правильную ветку. Они вобще не должны "допиливать" что то до ума." - это высказывание одного из неофитов, отрицающих очевидное. "незнание законов не освобождает от ответственности"©
УЧИТЕЛЬ: За рулем бандитский тип, а машина эта?
ДЕТИ: Джип!
УЧИТЕЛЬ: Оштрафует, хоть ты тресни - это дядя?
ДЕТИ: ДэПээС-ник!
УЧИТЕЛЬ: Кто не дружит с головой? Это дядя...
ДЕТИ: Постовой!
дабы не уподобляться "дяде, что не дружит с головой" таки стоит осознать несколько прописных истин, как то:
* любые правила упорядочивают хаос;
* в данном контексте существующие проверки ставят целью обезопасить конечного Пользователя и указать "упаковщику" на некоторые очевидные оплошности в пакете;
* врага надо знать "в лицо"!
изучением этого "врага" и предлагаю заняться далее.
текущая система проверок уже готовых пакетов состоит из двух независимых друг от друга уровней (другими словами: в какой хронологической последовательности собранные пакеты проходят эти проверки - совершенно не важно). первый - это rpmlint проверки. детальное описание оных вы найдёте по ранее приведённой ссылке. мы можем полностью их контролировать. в секции "Supressing False Positives" описана методика подавления "фиктивных" ошибок. но, как всегда собственно, есть "нюансы"... о них и поговорим.
перво-наперво читаем:
> man rpmlint
после чего смотрим на детали (если нам жуть как интересен сам механизм проверок):
> rpm -ql rpmlint
потом начинаем разбираться в том, "виноват" ли rpmlint в ошибке со сборкой нашего пакета. понять это очень просто. если проверка говорит, что "(Badness: 10000)" (допустим) - то это "наш" rpmlint. также он очень вежливо пишет какая именно из множества предусмотренных проверок "отоварила" нас выигрышем в джекпот:
permissions-file-setuid-bit (Badness: 10000) /usr/bin/БИНАРЬ is packaged with setuid/setgid bits (04555)
вежливо благодарим за предоставленную информацию и чешем репу. в данном конкретном примере нам сделали серьёзную предъяву, что собираемый нами пакет есть злобное некошерное чудовище, которому не место на системах добропорядочных граждан. однако, иногда (в ОЧЕНЬ редких случаях) наличие SUID-bit оправдано. предположим, что это именно такой случай. задача - поблагодарить OBS за предоставленную информацию и вежливо попросить заткнуться на будущее (не навешивать пакету штрафных очков).
* создаём в "исходниках" файл с расширением ".rpmlintrc". допустим Ваш спек называется "ПЕРВЕНЕЦ.spec", тогда созданный только что файл должен называться "ПЕРВЕНЕЦ.rpmlintrc"
* добавляем инструкцию насчёт нашего "проблемного" (по мнению OBS) бинаря:
addFilter("permissions-file-setuid-bit.*.*")
мы только что поставили монолитную могильную плиту над всеми попытками rpmlint-а заорать, что наш пакет имеет плохой SUID-bit на бинарнике. это конечно же неправильно. конечно же надо разобраться в вопросе и попытаться как-то обойтись без подобных крайностей. поэтому всем рекомендую перечитать одну из моих прежних заметок, где история именно с этой проверкой "моего" пакета расписана от "А" до "Я". кроме того, там есть пример "умной" brp проверки, о которой наша речь пойдёт далее. фраза "as responsive as a wall" почему-то постоянно приходит мне в голову применимо к данному случаю... интересно, что бы сказал по этому поводу дедушка Фрейд?
обращаю внимание публики, что файл "ПЕРВЕНЕЦ.rpmlintrc" не обязательно вносить в "ПЕРВЕНЕЦ.spec" как "Source?:". это конечно же диктуется правилами хорошего тона, но... увы и ах.
мы все, к сожалению, живём в реальном мире, а любые проверки подразумевают некий "идеальный мир" (сугубо с позиций АВТОРА проверок), к которому надо стремиться. это и есть суть возможных конфликтов. "What we've got here is a failure to communicate..." /Guns'n'Roses/
УЧИТЕЛЬ: Десять трупов, все в кисель, в ДТП у нас?
ДЕТИ: Газель!
УЧИТЕЛЬ: Кто на встречной всякий раз?
ДЕТИ: Пида@ас!
УЧИТЕЛЬ: Мигалки, @ляди и понты, за пивом ехали?
ДЕТИ: Менты!
второй эшелон "обороны" - это появившиеся в версии openSUSE-11.1 так называемые "brp" проверки. информации о них - море (попробуйте найти хоть одно внятное описание в openSUSE Wiki). как пример можно сразу смело давить на эту ссылку поиска и чесать репу до полного просветления. удачи.
официальная точка зрения по этому вопросу такова (несколько упрощённый вариант ессно): "brp проверки - наше фсио! отключить их нельзя! все пакеты должны проходить проверку brp!" лучше всего об этом скажут воспитанники детской группы ДДОУ "Детский садик Светлячок":
УЧИТЕЛЬ: Красный свет горит не зря, нету хода?
ДЕТИ: ни @уя!
на данный момент все пакеты для openSUSE-11.1/Factory проходят "brp" проверки в обязательном порядке. к чему приводит подобный подход - уже описывал. "благими намерениями вымощена дорога в ад"© - что есть, то есть. в основе-то своей идея стоящая. разработать правила, которым должны следовать все. только реализация хромает. наличие неких "белых списков" для якобы "кошерных" пакетов, куда всем прочим никогда не попасть, ставит на этой идее могильный крестик. махонький такой, ибо есть "нюансы", о которых и поговорим ниже.
суть "brp" проверок очень бледно отражена в трёх пакетах:
brp-check-suse | build root policy check scripts | package
brp-check-suse | relaxed build checks | patch
librpcsecgss | Library Implementing GSSAPI Security for ONC RPC | package
сами же "проверки" уже "зашиты" в пакет "rpm" ("зашиты" - это неправда!). можно на них полюбоваться кстати:
> rpm -ql rpm | grep brp | grep -w "rpm"
или
> find `rpm -ql rpm | grep brp | grep -w "rpm" ` \
-print -exec cat {} \;
делов-то. а на самом деле посмотреть на механизм проверок можно (imho) только в случае установки и запуска локально сервера OBS. "brp" проверки именно "зашивают" в конфигурацию проекта/платформы. например: в openSUSE-10.3/11.0 их нет, а в openSUSE-11.1/Factory они есть.
другими словами, разрешено всё, что не запрещено. спектр проверок довольно широк. от "правильно" (по мнению авторов ессно) сформированного "*.desktop" файла и до уже упомянутых ранее "некошерных" сервисов D-BUS (без которых повторюсь не будут работать пакеты типа "Wicd", "Exalt" и прочие). с одной стороны это здорово - нахуя в openSUSE лишние пакеты? да и если Вы хотите собирать для openSUSE Community - то есть же Packman! (в Packman Community communication skills более развиты кстати...) с другой же стороны это вполне может привести к тому, что в OBS в первую очередь будут собирать пакеты для RH/Ubuntu/MDK, а потом чесать репу насчёт сборки для текущей версии openSUSE. именно эту картину все и наблюдали в момент релиза версии openSUSE-11.1. доступного софта по сравнению с версией 11.0 было значительно меньше, ибо "упаковщики" в течение следующего полугода старались "вытянуть" свои проекты на уровень 11.0.
на сегодня о сути проверок можно догадываться по именам файлов, их содержащим. в скобках - моё imho:
00-check-install-rpms (этот пакет вообще может быть установлен... производится реальная установка пакета в chroot-е)
01-check-debuginfo (проверка на "пустоту" в пакете -debug)
02-check-gcc-output (насколько серьёзны были предупреждения компилятора во время сборки. для проверки используется реальный лог сборки пакета)
03-check-binary-kernel-log (что-то связанное с корректной установкой бинарей, хотя хз, запамятовал)
04-check-filelist (собсно проверка содержимого пакета на соответствие его "таможенной декларации")
05-check-invalid-requires (ибо нехер рисовать кривые зависимости ручками, да!)
06-check-installtest (если вы думаете, что вы тут самый умный и наколбасили левые %pre*/%pos* скрипты/макросы - то самое времясходить нахуй)
08-check-permissions (весьма здравая идея, но сам тест - мог быть и получше...)
09-check-packaged-twice (безобидный тест на "декларирование" в %files файла дважды/трижды/etc)
10-check-lanana (хз)
11-check-pkgconfig-deps (если Ваши "*.pc" файлы - файлы для "pkg-config" - содержат некорректную информацию - пришло время ревизии!)
12-check-libtool-deps (очень тупой и бесполезный тест, ибо правила хорошего тона рекомендуют к буям вырезать из пакета все {*.a;*.la} файлы - мамо, оно нам не надо...)
13-check-invalid-provides (на тему излишнего усердия при ручном заполнении строк "Provides:" - эти поля очень неплохо заполняются автоматически и не надо тут особо вы@бываться)
14-check-gconf-scriptlets (хз, не попадались)
99-check-remove-rpms (проверка на успешное удаление пакета с реальной деинсталляцией из chroot)
всё, что приведено выше, на первый взгляд пропитано самой Добротой и Заботой о ближнем (и о дальнем, что характерно), но в реальной жизни появляются... да-да-да! "нюансы"...
одно из отличий "brp" от "rpmlint"-а в том, что "плохие отметки" (Badness: X) "brp" тебе не ставит. ежели чего не так - ты сразу жеидёшь нахуй в пролёте вместе со своим собранным пакетом под звуки фанфар, бурные апплодисменты и без лишних объяснений.
разберём типовую ситуацию. есть дивный блок проверки "*.desktop" файлов, который иногда неимоверно бесит. одна из "выдающихся" проверок может не найдя иконки (упомянутой в пресловутом *.desktop файле!) допустим в %{_datadir}/pixmaps/ сказать:
ERROR: Icon file not installed:
и отправить тебя вместе с пакетом в путешествие пешком. как минимум есть два случая, при которых эта "проверка" абсолютно бесполезна:
1) если иконка установлена в %{_datadir}/icons/ (да, не по фэн-шую, но работает!)
2) если мы не хотим рисовать свою иконку и тянуть в зависимостях к нашему пакету какую-то из доступных тем иконок (что imho абсолютно оправдано и разумно. ну не будет в xdg менюшке у нашего горе-приложения иконки, и что?).
пишем письмо по адресу, упомянутому в OBS, предназначенному для решения подобных "неувязок" - stbinner@suse.de . идём нахуй, ибо ещё в октябре-декабре прошлого года этот Товарищ поменял e-mail, а о новом ящике простые смертные не знают ничегошеньки. естественно, что после этого мы получаем нехилую мотивациюпослать "brp" ф пизду исправить в пакете все недочёты, обнаруженные милыми "brp" проверками. такая возможность конечно же есть (пока что).
универсальный рецепт прост: внимательно изучаем логи сборки с найденными ошибками и исправляем их, собирая Ваш пакет в гармонии с окружающей средой. если же Вы внимательно прочитали заметку (сходив по всем приведённым ссылкам), то "секретный код" как отключить все "brp" проверки Вами уже найден.
удачи.
P.S. планируется в недалёком будущем рассмотреть некоторые аспекты работы с OBS при помощи Web-gui и командной строки, описать процесс создания "One-Click-Install" файлов, рассмотреть создание модулей ядра и просто попиздеть о том о сём... пишите камменты, они рулят!
*/
дамы и господа,
это - первая заметка о некоторых трюках при работе с замечательным сервисом openSUSE/Novell - openSUSE Build Service. если Вас интересуют какие-то детали или Вы желаете задать вопрос - оставляйте комментарии. постараюсь ответить.
недавно прислали очень поучительный экспромт о занятиях с детишками в детском саду. его и буду использовать в качестве "оглавления". поехали...
Занятие для организованных детских групп ДДОУ "Детский садик Светлячок".
Тема: "Автодорожное движение".
Учитель громким голосом четко произносит фразу, оканчивая ее вопросительной интонацией.
Дети хором произносят ответ.
УЧИТЕЛЬ: Кто король далеких трасс?
ДЕТИ: КАМАЗ!
абсолютно верно и пгавильно подмечено! формат rpm - наше фсио! остальное - от лукавого. а как же убунту и ".deb"? - очень неудобно разбираться откуда ноги растут у "dh_make". другими словами: spec файл - это святая Библия, где всё написано от и до. если встретился непонятный макрос - например %configure - набираем:
> rpmbuild --eval %configure
и смотрим что именно он означает. хотим написать свой макрос? - легко! читаем:
man rpm
vim /usr/share/doc/packages/rpm/manual/macros
и заглянем в "/usr/share/doc/packages/rpm/manual/" из чистого любопытства - там таки есть что почитать перед сном. по сравнению с rpm другие форматы пакетов выглядят как набор костылей. и не надо мне рассказывать, что EBUILD (Gentoo) рулит. любое использование USE флага автоматом означает невозможность стандартизировать результат и, как следствие, непригодность этого поделия в Production. а все типа "оптимизации", получаемые при "гибкой" сборке, можно спустить в унитаз чуток обновив железо. кроме того, rpm никоим разом не мешает делать спецсборки софта для тех же кластерных вычислений или же для работы с видео (как пример).
Что же такое этот OBS (openSUSE Build Service)? это система, которая позволяет создавать пакеты для всех основных дистрибутивов Linux, включая RH, Debian, Ubuntu и иже с ними. ежели по-простому, то внутрь ты пихаешь исходники и инструкцию по сборке, а на выходе получаешь готовые красивые КОШЕРНЫЕ пакеты. кошерные - ибо существуют некоторые наборы правил, которые мейнтейнер (далее буду пользовать термин "упаковщик") обязан соблюдать. под правилами также подразумевается наличие систем проверок готовых пакетов. то бишь устанавливая пакет из OBS лузер (в теории) имеет возможность полностью проконтролировать сборку и увериться, что ставит "кошерный продукт".
УЧИТЕЛЬ: Кто гремит и весь в пыли?
ДЕТИ: Жигули!
УЧИТЕЛЬ: Кто проедет грязь игриво?
ДЕТИ: Нива!
УЧИТЕЛЬ: Кушай кашу "Геркулес", купит папа?
ДЕТИ: Мерседес!
для пользования OBS необходимо наличие учётной записи в Novell и посещение стартовой страницы для получения базовых инструкций. скорее всего вводная в OBS более подойдёт для первого знакомства с системой. нет ни малейшего желания пересказывать "бояны", поэтому сделаю следующие допущения:
* вы прониклись мощью и красотой решения, получили учётку в Novell, создали свой домашний проект и, при помощи Web-gui (броузера) сваяли свой первый пакет.
* пакет этот нихуя не собирался как надо до тех пор, пока вы не прорюхали великий смысл в строках "BuildRequires: список DEVEL-пакетов (через пробел), необходимых для сборки Вашего первенца"
* всё собралось, но не везде. вы ещё раз пофтыкали инструкцию как компилять для разных дистрибутивов, обматерили всех "умников", дающих разное название одинаковым сущностям/пакетвм, взмолились о глобальной стандартизации, но таки сваяли новый spec файл.
* оно даже собралось, но проверки собранного пакета сказали Вам, что сборка прошла не по фэн-шую и предложили
* у Вас оформилось светлая мечта уебать аффторов "проверок" чем-нить тяжёлым по умной голове, послать всю затею с OBS куда подальше и "включить идиота" на полную катушку - "Какие мейнтейнеры? "ПРЕВЕД" надо говорить разработчикам. Очнитесь. Задача мейтейнеров проста как 2x2- собрать из сырцов бинарики, собрать их в пакеты с учетом зависимостей, и положить их правильную ветку. Они вобще не должны "допиливать" что то до ума." - это высказывание одного из неофитов, отрицающих очевидное. "незнание законов не освобождает от ответственности"©
УЧИТЕЛЬ: За рулем бандитский тип, а машина эта?
ДЕТИ: Джип!
УЧИТЕЛЬ: Оштрафует, хоть ты тресни - это дядя?
ДЕТИ: ДэПээС-ник!
УЧИТЕЛЬ: Кто не дружит с головой? Это дядя...
ДЕТИ: Постовой!
дабы не уподобляться "дяде, что не дружит с головой" таки стоит осознать несколько прописных истин, как то:
* любые правила упорядочивают хаос;
* в данном контексте существующие проверки ставят целью обезопасить конечного Пользователя и указать "упаковщику" на некоторые очевидные оплошности в пакете;
* врага надо знать "в лицо"!
изучением этого "врага" и предлагаю заняться далее.
текущая система проверок уже готовых пакетов состоит из двух независимых друг от друга уровней (другими словами: в какой хронологической последовательности собранные пакеты проходят эти проверки - совершенно не важно). первый - это rpmlint проверки. детальное описание оных вы найдёте по ранее приведённой ссылке. мы можем полностью их контролировать. в секции "Supressing False Positives" описана методика подавления "фиктивных" ошибок. но, как всегда собственно, есть "нюансы"... о них и поговорим.
перво-наперво читаем:
> man rpmlint
после чего смотрим на детали (если нам жуть как интересен сам механизм проверок):
> rpm -ql rpmlint
потом начинаем разбираться в том, "виноват" ли rpmlint в ошибке со сборкой нашего пакета. понять это очень просто. если проверка говорит, что "(Badness: 10000)" (допустим) - то это "наш" rpmlint. также он очень вежливо пишет какая именно из множества предусмотренных проверок "отоварила" нас выигрышем в джекпот:
permissions-file-setuid-bit (Badness: 10000) /usr/bin/БИНАРЬ is packaged with setuid/setgid bits (04555)
вежливо благодарим за предоставленную информацию и чешем репу. в данном конкретном примере нам сделали серьёзную предъяву, что собираемый нами пакет есть злобное некошерное чудовище, которому не место на системах добропорядочных граждан. однако, иногда (в ОЧЕНЬ редких случаях) наличие SUID-bit оправдано. предположим, что это именно такой случай. задача - поблагодарить OBS за предоставленную информацию и вежливо попросить заткнуться на будущее (не навешивать пакету штрафных очков).
* создаём в "исходниках" файл с расширением ".rpmlintrc". допустим Ваш спек называется "ПЕРВЕНЕЦ.spec", тогда созданный только что файл должен называться "ПЕРВЕНЕЦ.rpmlintrc"
* добавляем инструкцию насчёт нашего "проблемного" (по мнению OBS) бинаря:
addFilter("permissions-file-setuid-bit.*.*")
мы только что поставили монолитную могильную плиту над всеми попытками rpmlint-а заорать, что наш пакет имеет плохой SUID-bit на бинарнике. это конечно же неправильно. конечно же надо разобраться в вопросе и попытаться как-то обойтись без подобных крайностей. поэтому всем рекомендую перечитать одну из моих прежних заметок, где история именно с этой проверкой "моего" пакета расписана от "А" до "Я". кроме того, там есть пример "умной" brp проверки, о которой наша речь пойдёт далее. фраза "as responsive as a wall" почему-то постоянно приходит мне в голову применимо к данному случаю... интересно, что бы сказал по этому поводу дедушка Фрейд?
обращаю внимание публики, что файл "ПЕРВЕНЕЦ.rpmlintrc" не обязательно вносить в "ПЕРВЕНЕЦ.spec" как "Source?:". это конечно же диктуется правилами хорошего тона, но... увы и ах.
мы все, к сожалению, живём в реальном мире, а любые проверки подразумевают некий "идеальный мир" (сугубо с позиций АВТОРА проверок), к которому надо стремиться. это и есть суть возможных конфликтов. "What we've got here is a failure to communicate..." /Guns'n'Roses/
УЧИТЕЛЬ: Десять трупов, все в кисель, в ДТП у нас?
ДЕТИ: Газель!
УЧИТЕЛЬ: Кто на встречной всякий раз?
ДЕТИ: Пида@ас!
УЧИТЕЛЬ: Мигалки, @ляди и понты, за пивом ехали?
ДЕТИ: Менты!
второй эшелон "обороны" - это появившиеся в версии openSUSE-11.1 так называемые "brp" проверки. информации о них - море (попробуйте найти хоть одно внятное описание в openSUSE Wiki). как пример можно сразу смело давить на эту ссылку поиска и чесать репу до полного просветления. удачи.
официальная точка зрения по этому вопросу такова (несколько упрощённый вариант ессно): "brp проверки - наше фсио! отключить их нельзя! все пакеты должны проходить проверку brp!" лучше всего об этом скажут воспитанники детской группы ДДОУ "Детский садик Светлячок":
УЧИТЕЛЬ: Красный свет горит не зря, нету хода?
ДЕТИ: ни @уя!
на данный момент все пакеты для openSUSE-11.1/Factory проходят "brp" проверки в обязательном порядке. к чему приводит подобный подход - уже описывал. "благими намерениями вымощена дорога в ад"© - что есть, то есть. в основе-то своей идея стоящая. разработать правила, которым должны следовать все. только реализация хромает. наличие неких "белых списков" для якобы "кошерных" пакетов, куда всем прочим никогда не попасть, ставит на этой идее могильный крестик. махонький такой, ибо есть "нюансы", о которых и поговорим ниже.
суть "brp" проверок очень бледно отражена в трёх пакетах:
brp-check-suse | build root policy check scripts | package
brp-check-suse | relaxed build checks | patch
librpcsecgss | Library Implementing GSSAPI Security for ONC RPC | package
сами же "проверки" уже "зашиты" в пакет "rpm" ("зашиты" - это неправда!). можно на них полюбоваться кстати:
> rpm -ql rpm | grep brp | grep -w "rpm"
или
> find `rpm -ql rpm | grep brp | grep -w "rpm" ` \
-print -exec cat {} \;
делов-то. а на самом деле посмотреть на механизм проверок можно (imho) только в случае установки и запуска локально сервера OBS. "brp" проверки именно "зашивают" в конфигурацию проекта/платформы. например: в openSUSE-10.3/11.0 их нет, а в openSUSE-11.1/Factory они есть.
другими словами, разрешено всё, что не запрещено. спектр проверок довольно широк. от "правильно" (по мнению авторов ессно) сформированного "*.desktop" файла и до уже упомянутых ранее "некошерных" сервисов D-BUS (без которых повторюсь не будут работать пакеты типа "Wicd", "Exalt" и прочие). с одной стороны это здорово - нахуя в openSUSE лишние пакеты? да и если Вы хотите собирать для openSUSE Community - то есть же Packman! (в Packman Community communication skills более развиты кстати...) с другой же стороны это вполне может привести к тому, что в OBS в первую очередь будут собирать пакеты для RH/Ubuntu/MDK, а потом чесать репу насчёт сборки для текущей версии openSUSE. именно эту картину все и наблюдали в момент релиза версии openSUSE-11.1. доступного софта по сравнению с версией 11.0 было значительно меньше, ибо "упаковщики" в течение следующего полугода старались "вытянуть" свои проекты на уровень 11.0.
на сегодня о сути проверок можно догадываться по именам файлов, их содержащим. в скобках - моё imho:
00-check-install-rpms (этот пакет вообще может быть установлен... производится реальная установка пакета в chroot-е)
01-check-debuginfo (проверка на "пустоту" в пакете -debug)
02-check-gcc-output (насколько серьёзны были предупреждения компилятора во время сборки. для проверки используется реальный лог сборки пакета)
03-check-binary-kernel-log (что-то связанное с корректной установкой бинарей, хотя хз, запамятовал)
04-check-filelist (собсно проверка содержимого пакета на соответствие его "таможенной декларации")
05-check-invalid-requires (ибо нехер рисовать кривые зависимости ручками, да!)
06-check-installtest (если вы думаете, что вы тут самый умный и наколбасили левые %pre*/%pos* скрипты/макросы - то самое время
08-check-permissions (весьма здравая идея, но сам тест - мог быть и получше...)
09-check-packaged-twice (безобидный тест на "декларирование" в %files файла дважды/трижды/etc)
10-check-lanana (хз)
11-check-pkgconfig-deps (если Ваши "*.pc" файлы - файлы для "pkg-config" - содержат некорректную информацию - пришло время ревизии!)
12-check-libtool-deps (очень тупой и бесполезный тест, ибо правила хорошего тона рекомендуют к буям вырезать из пакета все {*.a;*.la} файлы - мамо, оно нам не надо...)
13-check-invalid-provides (на тему излишнего усердия при ручном заполнении строк "Provides:" - эти поля очень неплохо заполняются автоматически и не надо тут особо вы@бываться)
14-check-gconf-scriptlets (хз, не попадались)
99-check-remove-rpms (проверка на успешное удаление пакета с реальной деинсталляцией из chroot)
всё, что приведено выше, на первый взгляд пропитано самой Добротой и Заботой о ближнем (и о дальнем, что характерно), но в реальной жизни появляются... да-да-да! "нюансы"...
одно из отличий "brp" от "rpmlint"-а в том, что "плохие отметки" (Badness: X) "brp" тебе не ставит. ежели чего не так - ты сразу же
разберём типовую ситуацию. есть дивный блок проверки "*.desktop" файлов, который иногда неимоверно бесит. одна из "выдающихся" проверок может не найдя иконки (упомянутой в пресловутом *.desktop файле!) допустим в %{_datadir}/pixmaps/ сказать:
ERROR: Icon file not installed:
и отправить тебя вместе с пакетом в путешествие пешком. как минимум есть два случая, при которых эта "проверка" абсолютно бесполезна:
1) если иконка установлена в %{_datadir}/icons/ (да, не по фэн-шую, но работает!)
2) если мы не хотим рисовать свою иконку и тянуть в зависимостях к нашему пакету какую-то из доступных тем иконок (что imho абсолютно оправдано и разумно. ну не будет в xdg менюшке у нашего горе-приложения иконки, и что?).
пишем письмо по адресу, упомянутому в OBS, предназначенному для решения подобных "неувязок" - stbinner@suse.de . идём нахуй, ибо ещё в октябре-декабре прошлого года этот Товарищ поменял e-mail, а о новом ящике простые смертные не знают ничегошеньки. естественно, что после этого мы получаем нехилую мотивацию
универсальный рецепт прост: внимательно изучаем логи сборки с найденными ошибками и исправляем их, собирая Ваш пакет в гармонии с окружающей средой. если же Вы внимательно прочитали заметку (сходив по всем приведённым ссылкам), то "секретный код" как отключить все "brp" проверки Вами уже найден.
удачи.
P.S. планируется в недалёком будущем рассмотреть некоторые аспекты работы с OBS при помощи Web-gui и командной строки, описать процесс создания "One-Click-Install" файлов, рассмотреть создание модулей ядра и просто попиздеть о том о сём... пишите камменты, они рулят!
*/
Подписаться на:
Сообщения (Atom)
