Присутствие большого числа российских предприятий на авиасалоне в Ле Бурже, несмотря на введенный в прошлом году запрет в отношении России на импорт и экспорт военной техники, удивил многих участников самого крупного и престижного аэрокосмического салона. Об этом пишет французское издание L’OBS. Разрешение на участие российских компаний в Ле Бурже является признаком того, что в угоду … Читать далее L’OBS: участие России в салоне Ле Бурже — удар для европейцев и украинцев →

Разработчик: OpenBroadcasterSoftware Cтатус: Бесплатно Windows: Windows 8, 7, Vista Версия: 0.592 Beta Дата выхода: 28.12.2013 Разрядность: x32 — x64 Язык: Русский СКАЧАТЬ: (Здесь)Версия: 0.592 Beta ***************************** Open Broadcaster Software – или упрощенно OBS, это программа с открытым исходным кодом ней можно записать игровое видео (например для видеообзора или просто так) С помощью имеющихся в OBS опций можно настроить качество передаваемого […]

/*

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

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

*/

/*
И вновь продолжается бой,
И сердцу тревожно в груди.
И Ленин - такой молодой,
И юный Октябрь впереди!
/Н. Добронравов, 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. да и прочих забот хватает.

пока так. поживём, а там видно будет.

всем удачи!

*/

/*
- Вовочка, выйди из класса и зайди, как это делает твой папа!
- ... ща.
пинком выносит дверь с коробкой, рвёт пуговицы на рубашке и орёт в охуевший и притихший класс:
- Шо, с-суки, не ждали?!

история не нова. в очередной раз "тихо и незаметно" на весь 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 и откланяться.

удачи.

*/