О том, как строили Ступу Просветления Эксклюзивный репортаж! Наш автор побывала в столице Калмыкии, посетила «Золотую обитель Будды Шакьямуни», возведение которой контролировал сам Далай-Лама, видела приготовленную для него комнату и даже поучаствовала в строительстве Ступы Просветления. ТЕКСТ: Елена Жиркова   Оказывается, в Калмыкии течёт Волга. Единственный выход к реке есть в небольшом степном посёлке Цаган-Аман, […]

Голограммы людей на фоне разрушений. Арт-проект фотографа Fabrice Wittner «Enlightened Souls«.

/*

-Мальцик, мальцик сам виноват!
/вопль судьи (после речи обвиняемого) на слушании дела по изнасилованию несовершеннолетнего.../

всех со всеми, всего, того же и туда же... надеюсь, что НГ удался на славу и вы можете по крупицам восстанавливать хронологию событий в ближайшем будущем. эта заметка планировалась как "последняя" в "цикле" про 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-ом, году!

*/

/*

Ladies and Gents,

the new SOAD-Linux based on openSUSE-11.2 is out:

Download page
List of installed packages
README
Version 3.3.1 download link

It's a hybrid "iso" image capable to run in VM (qemu, etc.), to be burned on CD/DVD or to be "dumped" to USB-sticks. We're providing the extended set of a drivers for devices/filesystems along with the extended set of WM's for your convenience. Please be aware that we can not assure the correct behavior of "Ecomorph" despite on installed NVIDIA driver (you need to build from official "NVIDIA*.run" sources to avoid "White screen" compiz bug for a modern NVIDIA GPU's). Also due to a "lzma+squashfs" compression method we can't provide the small "xdelta" patches yet.

You're always welcome to leave your comments here.

Have fun!


Дамы и Господа,

предлагаем Вашему вниманию новую версию SOAD-Linux, основанную на openSUSE-11.2:

Страница загрузки
Список предустановленных пакетов
README
Скачать образ

С удовольствием учтём Ваши пожелания при подготовке следующих релизов.

Удачи!

*/

/*

Страна замечательная, томики законов сразу рассылают в публичные дома, чтобы любой желающий мог повертеть на ..ю за символическую сумму.
/ЛОР/

сильнее всего мешает отсутствие поддержки multibyte encoding (utf8), что уже реализовано в NetBSD и FreeBSD. ждём-с, а пока каждый "строит коммунизм в отдельно взятой стране". ничего сложного. рассмотрим на примере терминала Eterm:

1) ставим "vim" и "w3m" (это наши будущие редактор и просмотрщик файлов/каталогов по умолчанию)

2) собсно обозначаем наши благие намерения:

> echo 'export PAGER=/usr/local/bin/w3m' >> ~/.profile
> echo 'export EDITOR=/usr/local/bin/vim' >> ~/.profile

w3m нам нужен хотя бы для просмотра (в Eterm) примонтированных партиций, поскольку команда ":edit ++enc=utf-8" в vim-е прекрасно работает с файлами, но сбоит на каталогах. EFM (Enlightenment File Manager) справляется с отображением UTF-8 на ура (особенно если evas собран с fribidi). после определения переменной PAGER это значение используется и для просмотра man-ов, что гораздо удобнее, чем дефолт ("more").

3) отучаем "mc" использовать "mcview" (рихтуем "~/.mc/ini"):

use_internal_View=0

тут же можно избавиться и от "mcedit", заменив его на $EDITOR

use_internal_edit=0

4) читаем "каноны":

http://www.openbsd.ru/docs/howto-cyrillic.html

5) делаем alias для запуска Eterm в нужной нам конфигурации:

alias eterm="Eterm -F -*-fixed-medium-r-normal-*-15-*-*-*-*-*-koi8-r"

после чего вызываем терминал по только что указанному "паттерну":

> eterm

6) опционально читаем "man w3m" и учимся эффективно использовать этот замечательный консольный браузер.

к этому моменту имеем полностью русифицированную рабочую систему, осталось лишь навести лоск в соответствии с личными предпочтениями (используем Enlightenment-DR17). рихтуем "/etc/enlightenment/sysactions.conf":

action: halt /sbin/halt -p
action: reboot /sbin/reboot
action: suspend /usr/sbin/zzz
action: hibernate /usr/sbin/zzz
user: $USER allow: *

с suspend и hibernate поосторожнее, может и не заработать. ставим из пакетов всё, что относится к "xdg*" и добавляем в "~/.profile" требуемые переменные:

export XDG_CACHE_HOME=$HOME/.cache
export XDG_CONFIG_DIRS=/etc/xdg
export XDG_CONFIG_HOME=$HOME/.config
export XDG_DATA_DIRS=/usr/share:/usr/local/share:/usr/X11R6/share
export XDG_DATA_HOME=$HOME/.local/share

после чего не мудрствуя лукаво копируем из openSuSE весь каталог "/etc/xdg/menu" (кто самый смелый - может рисовать xml-ные "менюшки" руками, автор - слабак, не осилил...). теперь мы имеем нормальное XDG/FDO Applications-menu. мелочь - а приятно.

последний штрих - не стоит менять настройки окружения root-а. как показывает практика успешная миграция на OpenBSD-current (это когда тащим cvs-ом исходники и компиляем всё сами) возможна только при буквальном соблюдении "канонов". т.е. если вы не имеете желания разбираться, какого буя сборка падает при "gcc version 4.2.4", но всё путём для "gcc version 3.3.5 (propolice)" - то не трогайте рутовое окружение (а падает оно патамучта gcc4 из пакетов имеет Thread model: posix и "_atomic_lock.c" из "libpthread" да и прочие аналогичные вещи ещё никто не рихтовал. у gcc3 Thread model: single).

всем - удачи!

*/