/*
-М-м-м-у-у-у-у!!!
-Шо за "му"?! Опять нажрался, свинота?!
начну с элементарного - русификации консоли (tty/mingetty) в современных SLE/SuSE. где-то с версии SuSE-9.1 "проблема" как-бы исчезла полностью благодаря поддержке UTF-8, но как и что делать вроде никто в отдельную заметку не выносил. по поводу русификации ранних версий есть отличная статейка:
Русификация SuSE 9
но увы и ах - "бойянЪ". задача раскладывается на три составляющие (при условии, что Ваша "локаль" уже задана в /etc/sysconfig/language как RC_LANG="en_US.UTF-8" или RC_LANG="ru_RU.UTF-8"):
1) выбрать "правильный" шрифт (содержащий UTF-8 символы кириллицы как минимум).
чешем в "/usr/share/kbd/consolefonts/" и выбираем тот, который нравится больше всего. после чего вносим его в "/etc/sysconfig/console" как шрифт по умолчанию (пример):
CONSOLE_FONT="UniCyr_8x16.psf.gz"
CONSOLE_MAGIC="(K"
2) задаём UTF-8 кодировку терминала для вывода символов, отличных от ASCII, в "/etc/sysconfig/console":
CONSOLE_ENCODING="UTF-8"
3) выбираем подходящую "раскладку" и "переключалку" (доступные варианты можно просмотреть в /usr/share/kbd/keymaps/i386/qwerty/) и вносим её в "/etc/sysconfig/keyboard" (пример с переключением по правому ALT-у):
KEYTABLE="ru1_win-utf.map.gz"
кроме этого тут же можно установить "шорткат" для переключения между активными терминалами (например по кнопке "Win"):
COMPOSETABLE="clear winkeys"
завершающий штрих - рестарт сервиса "kbd":
/sbin/service kbd restart
после чего можно смело переключиться в "чистую" консоль (Ctl+Alt+F1) и оценить результат.
mission сукесфули комплитед.
Девушки бывают разные:
чёрные, белые, красные...
SuSE/SLE довольно специфичный дистрибутив, ибо содержит огромное количество "вкусностей", недоступных остальным "из коробки". это требует от пользователя определённого знания системы и вырианты решений тех или иных задач могут существенно отличаться (в этом-то и проявляется специфика). где-то эдак годика с 2005-го SuSE включила в базовую поставку системы свою собственную "надстройку" (называйте как хотите - "морда", гуй и т.п.) для управления пакетным фильтром iptables - SuSEfirewall, что до сих пор, imho, остаётся лучшим решением по управлению трафиком.
вся настройка идёт путём правки единственного файла:
$ sudo vim /etc/sysconfig/SuSEfirewall2
файл отлично документирован комментариями и поверхностного знания английского языка будет вполне достаточно. для применения новых значений используем связку:
$ sudo /sbin/SuSEfirewall2 stop
$ sudo /sbin/SuSEfirewall2 start
анализ эффективных цепочек правил легче всего делать при помощи:
$ sudo /usr/sbin/iptables-save | less
"черновую" настройку можно набросать в "гуях" YAST-а:
$ gksu yast2 -> Security and Users -> Firewall
после чего настоятельно рекомендую ввести изменения в силу и в дальнейшем редактировать "/etc/sysconfig/SuSEfirewall2" вручную. особая ценность решения от SuSE в том, что оно не накладывает никаких ограничений "творческой мысли" при редактировании цепочек. если Вы не осилили предлагаемые готовые "пресеты", то никто не запрещает указать:
FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"
и подгрузить из файла "SuSEfirewall2-custom" свои собственные правила. причём ситуаций, которые требуют подобного вмешательства - масса. в указанном выше файле содержатся примеры с кратким описанием ситуаций для их применения.
основным преимуществом использования SuSEfirewall можно считать чётко структурированный подход к работе цепочек фильтрации. по сути это одно большое наглядное практическое пособие о том, как Правильно работать с iptables. весь трафик сперва делится на "зоны" - DMZ, "внешний"/external, "внутренний"/internal, lo - с возможностью определить дополнительные при желании - wlan и т.п.. после чего для каждой "зоны" создаётся отдельная "цепочка" эффективных правил, фильтрующая весь трафик. также идёт прямое указание на загрузку необходимых Вам модулей ядра (пример):
FW_LOAD_MODULES="nf_conntrack_netbios_ns xt_conntrack xt_owner \
xt_iprange xt_CONNMARK xt_limit xt_TCPMSS xt_state\
nf_conntrack_ftp nf_nat_ftp"
в результате мы получаем красивую и логичную схему действующих правил, которая ещё и минимизирует издержки при обработке трафика благодаря stateful природе пакетного фильтра. суть stateful пожалуй можно перевести как установление "статуса" активного соединения и разбору дальнейших пакетов на его основе. т.е. если какое-то соединение признано валидным/состоявшимся, то оно получает статус ESTABLISHED/(установлено), после чего весь соответствующий ему трафик обрабатывается на основе этого статуса, "минуя" цепочки фильтрации. рассмотрим простой пример, наглядно демонстрирующий преимущества решений SuSE:
> sudo iptables-save -t raw
*raw
:PREROUTING ACCEPT [38828:15020523]
:OUTPUT ACCEPT [36327:4135365]
-A PREROUTING -i lo -j NOTRACK
-A OUTPUT -o lo -j NOTRACK
COMMIT
(параметр FW_LO_NOTRACK="yes")
вроде бы "мелочь" - вывод всего трафика lo из под "опёки" цепочек фильтрации, а на загруженных машинах это ой как приятно. или:
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
здесь мы "синхронизируем" активное соединение с MSS (Maximum Segment Size in TCP), тем самым предотвращая пересылку слишком больших пакетов, требующих насильственного "деления".
рассмотрим далее упрощённый вариант того, что у нас творится в основных "цепочках" таблицы filter (как пример, без наворотов типа DMZ или специальных "зон" - ситуация "из коробки" так сказать...):
> sudo iptables-save -t filter | less
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:forward_ext - [0:0]
:forward_int - [0:0]
:input_ext - [0:0]
:input_int - [0:0]
:reject_func - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m state --state RELATED -j ACCEPT
-A INPUT -i tap0 -j input_int
-A INPUT -i eth1 -j input_ext
-A INPUT -i wlan1 -j input_ext
-A INPUT -i wmaster0 -j input_ext
-A INPUT -j input_ext
-A INPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-IN-ILL-TARGET " --log-tcp-options --log-ip-options
-A INPUT -j DROP
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -i tap0 -j forward_int
-A FORWARD -i eth1 -j forward_ext
-A FORWARD -i wlan1 -j forward_ext
-A FORWARD -i wmaster0 -j forward_ext
-A FORWARD -m limit --limit 3/min -j LOG --log-prefix "SFW2-FWD-ILL-ROUTING " --log-tcp-options --log-ip-options
-A FORWARD -j DROP
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-OUT-ERROR " --log-tcp-options --log-ip-options
*********************
**** прочее обрезано
*********************
нет никакого бардака. определены пять "функции" (отдельные цепочки правил для обработки трафика):
:forward_ext - [0:0]
:forward_int - [0:0]
:input_ext - [0:0]
:input_int - [0:0]
:reject_func - [0:0]
и весь траф поделён на "зоны":
int - "внутренний" - внутри локальной сети
ext - "внешний" - трафик из сетей, которые мы не контролируем (интернет и т.п.)
нетрудно заметить, что к "внутренней" зоне отнесён лишь один сетевой интерфейс - tap0. все остальные интерфейсы работают с "внешним" трафиком. нра? то-то...
для "краткого курса молодого бойца" необходимо и достаточно ознакомиться со следующим файлом:
> vim /usr/share/doc/packages/SuSEfirewall2/EXAMPLES
где дают исчерпывающие примеры по начальной конфигурации пакетного фильтра путём редактирования любимого файла "/etc/sysconfig/SuSEfirewall2". описывают восемь "сценариев":
1. Simple dialup
2. Small home network
3. Small home network with additional WLAN
4. Small company with external mail and web server
5. Company with IPsec tunnel to subsidiary
6. Company with web server in DMZ
7. Complex scenario
8. Laptop in private network but with additional public IP adresses
поскольку копипастить содержимое этого файла смысла нет, то пожалуй остановлюсь на некоторых деталях. начну с типовой ситуации для хомячков:
ISP предлагает тариф, позволяющий "качать" порно на скорости 768kbit/s, а вот "отдавать" трафик можно лишь на скорости в 256kbit/s. при этом возможна ситуация, когда при активной "отдаче" вы заметите "паралич" загружаемых файлов. лечение (при условии, что Вы на впн соединении с интерфейсом dsl0):
FW_HTB_TUNE_DEV="dsl0,250"
тут мы при помощи HTB режем исходящий трафик и резервируем 6kbit/s на "технические" нужды (пакеты TCP ACK или interactive SSH).
по умолчанию (для EXT зоны) зарезан broadcast и multicast. это может быть неудобно, поэтому внимательно смотрим на следующие переменные:
FW_ALLOW_FW_BROADCAST_EXT="no"
FW_ALLOW_FW_BROADCAST_INT="no"
FW_ALLOW_FW_BROADCAST_DMZ="no"
# ниже мы игнорируем логирование "дропнутых" ранее броадкастов
FW_IGNORE_FW_BROADCAST_EXT="yes"
FW_IGNORE_FW_BROADCAST_INT="yes"
FW_IGNORE_FW_BROADCAST_DMZ="yes"
для broadcast пакетов имеет смысл лишь открыть определённые порты, т.е. разрешить лишь выбранным приложениям принимать их. для multicast сперва надо ознакомиться с содержимым файла /etc/protocols, после чего уже разрешать определённые протоколы (например):
FW_SERVICES_EXT_IP="GRE MTP PIM"
и/или цепляем FW_CUSTOMRULES=файл_с_ручными_правками_правил, где рисуем:
iptables -A INPUT -j ACCEPT -d 224.0.0.0/24
тем самым разрешая "входящий" мультикаст на все протоколы/интерфейсы.
не будет лишним обратить внимание на:
FW_KERNEL_SECURITY="yes"
этот параметр включает некоторые скрытые защитные механизмы ядра (icmp_ignore_bogus_error_responses, icmp_echoreply_rate, icmp_destunreach_rate, icmp_paramprob_rate, icmp_timeexeed_rate, ip_local_port_range, log_martians, rp_filter, routing flush, bootp_relay, proxy_arp, secure_redirects, accept_source_route, icmp_echo_ignore_broadcasts, ipfrag_time)
если у вас большая и "шаловливая" локалка, то имеет смысл сделать:
FW_REJECT="no"
FW_REJECT_INT="no"
тем самым любителям сканить порты представится шанс сходить за чашечкой чая в ожидании отклика от портсканера.
имеет смысл как страховку от тупого DDOS-а выставить
FW_ALLOW_FW_SOURCEQUENCH="no"
тут мы "вырезаем" атаку по icmp которая возможна, при следующем условии:
-A input_ext -p icmp -m icmp --icmp-type 4 -j ACCEPT
но теряем на оповещении о статусе соединения от ISP (ежели он соизволит оное раздать ессно, что далеко не факт...)
последняя стадия "Enlightenment-а"/(сиречь Просветления, Мудрости и Духовной Силы) - это прямое редактирование скрипта, ведающего формированием цепочек правил:
> sudo vim /sbin/SuSEfirewall2
тут уж "вольному - воля". кто смел духом - дерзайте (бэкап оригинала не забудьте сохранить на всякий).
Use SuSE, Luke!
Показаны сообщения с ярлыком SuSE. Показать все сообщения
Показаны сообщения с ярлыком SuSE. Показать все сообщения
пятница, 5 февраля 2010 г.
вторник, 17 ноября 2009 г.
upgrade to openSUSE-11.2
/*
пуркуа бы и не па?
основные принципы остаются теми же, что и были описаны ранее:
схема проведения апгрейда
есть несколько уточнений. расписывать в деталях нет желания. по шагам:
1) определяем количество "вендоров" ПО в текущей системе:
> rpm -qai | grep Vendor | awk -FVendor '{ print $2 }' | sort | uniq
2) желательно все полученные выше линии внести через запятую в файл:
> sudo vim /etc/zypp/vendors.d/openSUSE
также можно создать несколько файлов в каталоге "/etc/zypp/vendors.d/". формат файла:
> cat /etc/zypp/vendors.d/openSUSE
[main]
vendors=openSUSE,SUSE LINUX Products GmbH,none,openSUSE Build Service,Packman,packman.links2linux.de,openSUSE Education,openSUSE-Education,(none),j.engelh,obs://build.opensuse.org/Emulators,obs://build.opensuse.org/home:anubisg1,obs://build.opensuse.org/home:dmitry_serpokryl,obs://build.opensuse.org/Moblin:UI,obs://build.opensuse.org/network:utilities,obs://build.opensuse.org/OpenOffice.org:EXTRAS,obs://build.opensuse.org/OpenOffice.org:STABLE,obs://build.opensuse.org/openSUSE:Factory,obs://build.opensuse.org/openSUSE:Tools,obs://build.opensuse.org/server:database,obs://build.opensuse.org/Virtualization:Appliances,obs://build.opensuse.org/X11,http://packman.links2linux.de
3) правим репы на версию 11.2:
> cd /etc/zypp/repos.d/
> sudo sed -i 's|11.1|11.2|g' *
4) проверяем содержимое каталога "/etc/zypp/repos.d/" на предмет того, что все "url=" вылидны.
5) выполняем сам апгрейд. можно в два прохода (сперва качаем контент, сохраняем локально, потом ставим):
> sudo zypper mr -k --all #optional
> sudo zypper mr --all --no-refresh #optional
> sudo zypper dup -D #optional
> sudo zypper dup
> sudo zypper clean #optional
6) перезагрузка.
в зависимости от скорости соединения и общей захламлённости системы процесс может занять достаточно длительное время. впрочем, даже на машинах с более чем 60-ю активными репо финал порадовал хорошими результатами. стоит обновляться сейчас или подождать - зависит от вас и того набора ПО, которым вы пользуетесь. далеко не все репы в OBS (включая и "официальные") "проапгрейдили" контент до openSuSE-11.2 (владельцы ATI как обычно с завистью смотрят на хозяев NVIDIA).
imho - обновиться стоит обязательно. очень много новых вкусных плюшек в виде поддержки файловых систем, переработанное ядро и т.п.
удачи.
*/
пуркуа бы и не па?
основные принципы остаются теми же, что и были описаны ранее:
схема проведения апгрейда
есть несколько уточнений. расписывать в деталях нет желания. по шагам:
1) определяем количество "вендоров" ПО в текущей системе:
> rpm -qai | grep Vendor | awk -FVendor '{ print $2 }' | sort | uniq
2) желательно все полученные выше линии внести через запятую в файл:
> sudo vim /etc/zypp/vendors.d/openSUSE
также можно создать несколько файлов в каталоге "/etc/zypp/vendors.d/". формат файла:
> cat /etc/zypp/vendors.d/openSUSE
[main]
vendors=openSUSE,SUSE LINUX Products GmbH,none,openSUSE Build Service,Packman,packman.links2linux.de,openSUSE Education,openSUSE-Education,(none),j.engelh,obs://build.opensuse.org/Emulators,obs://build.opensuse.org/home:anubisg1,obs://build.opensuse.org/home:dmitry_serpokryl,obs://build.opensuse.org/Moblin:UI,obs://build.opensuse.org/network:utilities,obs://build.opensuse.org/OpenOffice.org:EXTRAS,obs://build.opensuse.org/OpenOffice.org:STABLE,obs://build.opensuse.org/openSUSE:Factory,obs://build.opensuse.org/openSUSE:Tools,obs://build.opensuse.org/server:database,obs://build.opensuse.org/Virtualization:Appliances,obs://build.opensuse.org/X11,http://packman.links2linux.de
3) правим репы на версию 11.2:
> cd /etc/zypp/repos.d/
> sudo sed -i 's|11.1|11.2|g' *
4) проверяем содержимое каталога "/etc/zypp/repos.d/" на предмет того, что все "url=" вылидны.
5) выполняем сам апгрейд. можно в два прохода (сперва качаем контент, сохраняем локально, потом ставим):
> sudo zypper mr -k --all #optional
> sudo zypper mr --all --no-refresh #optional
> sudo zypper dup -D #optional
> sudo zypper dup
> sudo zypper clean #optional
6) перезагрузка.
в зависимости от скорости соединения и общей захламлённости системы процесс может занять достаточно длительное время. впрочем, даже на машинах с более чем 60-ю активными репо финал порадовал хорошими результатами. стоит обновляться сейчас или подождать - зависит от вас и того набора ПО, которым вы пользуетесь. далеко не все репы в OBS (включая и "официальные") "проапгрейдили" контент до openSuSE-11.2 (владельцы ATI как обычно с завистью смотрят на хозяев NVIDIA).
imho - обновиться стоит обязательно. очень много новых вкусных плюшек в виде поддержки файловых систем, переработанное ядро и т.п.
удачи.
*/
суббота, 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 и откланяться.
удачи.
*/
пятница, 6 ноября 2009 г.
кратенько об openSuSE-11.2
/*
- Мы выдержали, мы выстояли, мы победили!
/Брежнев/
негоже сомневаться, что этот релиз будет принят на "ура" поклонникамисвистелко-рюшегного kde, ибо теперь "галочка" kde-desktop стоит в инсталлере по умолчанию. удачи. речь пойдёт не о том. релиз намечен на 12 ноября, но кодовая база уже стабильна и Enlightenment-DR17 доступен для новой версии:
репо1 ("extended" set of available components)
репо2 ("official" minimum) - сборка для i586 в процессе
kde не понравился своей аляповатостью, тормозами и невменяемыми настройками (эт кроме багов ессно. тут отдельная история, даже писать не хочу - воротит, хотя не могу не отметить отсутствие Mono в базовом шаблоне установки kde - радует). "/etc/enlightenment/sysactions.conf" - наше всё (там элементарно настраиваются suspend, hibernate и прочие системные процедуры, помимо прочего), да и возможность устанавливать приоритет для ВСЕХ приложений/окон, контролируемых E (Settings -> Advanced -> Performance -> Application Priority) - очень радует. это гораздо более логичный подход для настройки "отзывчивости" иксов, чем перепил кода ядра (ждём, когда и эту идею адаптируют для быдломасс...).
посему, Дамы и Господа, смело можно накатить базовую систему или воспользоваться netinstall диском, если нет желания смотреть, как "-!...! плазма не падает, ЧЯДНТ!?"(c).
ядро - 2.6.31.5
e2fsprogs - 1.41.9 (можно ставить на ext4)
autoconf - 2.63
automake - 1.11
grub - 0.97 (grub-legacy)
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)
java-1_6_0-openjdk - 1.6.0.0_b16 (Java 6 compatible Java Runtime Environment is based on OpenJDK 6 and IcedTea 6 - праздник!)
xorg-x11 - 7.4
OBS проекты, являющиеся основой openSuSE-11.2 (нужен Novell account!):
из новшеств - появление сборки ядра kernel-desktop (что ставится по умолчанию). это вариант kernel-pae cо следующими нюансами (заявлена оптимизация для десктопа, но "bfs" нам из коробки не светит...):
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_NO_HZ=y
CONFIG_SMP=y
CONFIG_X86_BIGSMP=y
CONFIG_HIGHMEM64G=y
ничего сверхестественного. в остальном линейка ядер стандартна для oS (openSuSE): kernel-debug, kernel-default, kernel-pae, kernel-rt, kernel-trace (это вариант real-time ядра), kernel-vanilla, kernel-xen. тут только не забыть, что ядро разбито на субпакеты, в которых возможно наличие модулей для вашего железа. например:
i | kernel-desktop | Kernel optimized for the desktop | package
i | kernel-desktop-base | Kernel optimized for the desktop - base modules| package
i | kernel-desktop-devel | Development files necessary for building kernel modules
т.е. "kernel-desktop-base" по умолчанию не устанавливается, а в нём "есть многое, Горацио...". и дивный пакетик - "kernel-firmware" - многих обрадует.
после быстрой установки RC2 на ext2 (да! ибо у нас есть OpenBSD... и ext4 идёт....) начались долгожданные "приколы":
1) описанный ранее способ по прикрутке reiser4 не прокатил (WARNING: /lib/modules/2.6.31.5-0.1-desktop/updates/reiser4.ko needs unknown symbol breakpoint) - чешем на офсайт и чуток развлекаемся :)
2) многим (особенно встроенным!) звуковым картам резко поплохеет (звука не будет, феерично, ибо в OpenBSD-current/4.6 ВСЁ работает!), из дефолтного ядра модули вырезали, а к альсе пока не прикрутили (репо с kmp):
http://download.opensuse.org/repositories/multimedia:/audio:/KMP/
надеюсь, что это временная мера и за оставшиеся 6 дней появится репо/пакет с недостающими модулями. но, если оно не будет работать и дальше, - не удивлюсь ни капли. стоит заметить, что собранный вручную vanilla kernel 2.6.30.6 со звуком проблем не имел.
пересобрал для "kernel-desktop" (мне нужен "via82xx" например) из alsa-driver-kmp - соснул тунца, ибо alsaconf не увидел карточки даже с подгруженным модулем. ппц. надо попробовать откатиться на рабочий вариант из openSuSE-11.1.
рецепт лечения элементарен (выкидываем альсу, не пожалеете, в референсных мониторах разница очень хорошо различима):
* ставим:
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-source-2.6.31.5-0.1.1.noarch
kernel-syms-2.6.31.5-0.1.1.i586
linux-kernel-headers-2.6.31-3.4.noarch
gcc
make
"autotools"
* чешем за пряниками:
скачать OSS
* ставим:
> sudo rpm -Uhv --nodeps ./oss-linux-v4.2-2002.i386.rpm #(надо тупо обойти проверку на отсутствие kernel-devel пакета, ибо у нас он называется чуток по иному)
* стартуем "ossxmix" и кладём с пробором на alsa, pulse и прочие заморочки :)
3) смена раскладки клавиатуры непринуждённо настраивается засовыванием в автозагрузку чего-то похожего на:
#!/bin/sh
setxkbmap -layout us,ru -option grp:lctrl_lshift_toggle,grp_led:scroll -variant winkeys -model "pc(pc104)"
4) "официальные" репо для ATI/NVIDIA пока не готовы - ставим вручную (что даже лучше для целевой системы, что бы не возражали на это утверждение сторонники "пакетов").
5) хорошо, что не выкинули gfxboot с заменой на splashy (то ещё поделие...)
несмотря на статус RC2 система "сыровата". возможно это связано с новыми версиями "autotools"/devel пакетов, может аляповатость и тормознутость kde вызывают неприятие (хотя в моём случае вина на ублюдочной поддержке аудиокарточек, где openSuSE-11.2 соснула у OpenBSD-4.6). очень достойным шагом будет выкинуть нах Firefox из репо openSuSE и поставить с офсайта Mozilla - тем самым вы получите возможность обновляться без задержек и избавитесь от некоего "подтормаживания" при скроллинге страниц (хз почему, подозреваю какие-то косяки с pango - можно проверить параметры сборки, но Mozilla official и так работает без нареканий). единственное, что придётся поправить руками - пару симлинков на плагины.
многие OBS репо пока не готовы к выходу 11.2 - времени до релиза осталось не так много. ситуация повторяется. пинайте мейнтейнеров - самое время, пора прочухаться.
хвалебные оды уменьшению времени загрузки системы (и какая к буям разница, стартанёт оно за минуту или за 5 секунд - суть-то не в этом, а в том, как РАБОТАТЬ будет) и новому "гламурному" дизайну (не понравился) оставим другим. наше дело - прикрыть бронеплитой родную задницу и гарантировать спокойный сон за рабочим столом (подготовить достойный релиз SOAD Linux, лишённый недостатков "родителя")!
удачи!
P.S. недавно сравнивал последний midori и FF от Mozilla - FF откушал примерно на 5-15% больше памяти (10 вкладок, flash, JS и прочая) и субъективно уделал midori по всем остальным критериям. странно, что тест peacekeeper говорит об ином...
*/
- Мы выдержали, мы выстояли, мы победили!
/Брежнев/
негоже сомневаться, что этот релиз будет принят на "ура" поклонниками
репо1 ("extended" set of available components)
репо2 ("official" minimum) - сборка для i586 в процессе
kde не понравился своей аляповатостью, тормозами и невменяемыми настройками (эт кроме багов ессно. тут отдельная история, даже писать не хочу - воротит, хотя не могу не отметить отсутствие Mono в базовом шаблоне установки kde - радует). "/etc/enlightenment/sysactions.conf" - наше всё (там элементарно настраиваются suspend, hibernate и прочие системные процедуры, помимо прочего), да и возможность устанавливать приоритет для ВСЕХ приложений/окон, контролируемых E (Settings -> Advanced -> Performance -> Application Priority) - очень радует. это гораздо более логичный подход для настройки "отзывчивости" иксов, чем перепил кода ядра (ждём, когда и эту идею адаптируют для быдломасс...).
посему, Дамы и Господа, смело можно накатить базовую систему или воспользоваться netinstall диском, если нет желания смотреть, как "-!...! плазма не падает, ЧЯДНТ!?"(c).
ядро - 2.6.31.5
e2fsprogs - 1.41.9 (можно ставить на ext4)
autoconf - 2.63
automake - 1.11
grub - 0.97 (grub-legacy)
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)
java-1_6_0-openjdk - 1.6.0.0_b16 (Java 6 compatible Java Runtime Environment is based on OpenJDK 6 and IcedTea 6 - праздник!)
xorg-x11 - 7.4
OBS проекты, являющиеся основой openSuSE-11.2 (нужен Novell account!):
| openSUSE:11.2 |
| openSUSE:11.2:Contrib |
| openSUSE:11.2:Live |
| openSUSE:11.2:NonFree |
| openSUSE:11.2:Update |
из новшеств - появление сборки ядра kernel-desktop (что ставится по умолчанию). это вариант kernel-pae cо следующими нюансами (заявлена оптимизация для десктопа, но "bfs" нам из коробки не светит...):
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_NO_HZ=y
CONFIG_SMP=y
CONFIG_X86_BIGSMP=y
CONFIG_HIGHMEM64G=y
ничего сверхестественного. в остальном линейка ядер стандартна для oS (openSuSE): kernel-debug, kernel-default, kernel-pae, kernel-rt, kernel-trace (это вариант real-time ядра), kernel-vanilla, kernel-xen. тут только не забыть, что ядро разбито на субпакеты, в которых возможно наличие модулей для вашего железа. например:
i | kernel-desktop | Kernel optimized for the desktop | package
i | kernel-desktop-base | Kernel optimized for the desktop - base modules| package
i | kernel-desktop-devel | Development files necessary for building kernel modules
т.е. "kernel-desktop-base" по умолчанию не устанавливается, а в нём "есть многое, Горацио...". и дивный пакетик - "kernel-firmware" - многих обрадует.
после быстрой установки RC2 на ext2 (да! ибо у нас есть OpenBSD... и ext4 идёт....) начались долгожданные "приколы":
1) описанный ранее способ по прикрутке reiser4 не прокатил (WARNING: /lib/modules/2.6.31.5-0.1-desktop/updates/reiser4.ko needs unknown symbol breakpoint) - чешем на офсайт и чуток развлекаемся :)
2) многим (особенно встроенным!) звуковым картам резко поплохеет (звука не будет, феерично, ибо в OpenBSD-current/4.6 ВСЁ работает!), из дефолтного ядра модули вырезали, а к альсе пока не прикрутили (репо с kmp):
http://download.opensuse.org/repositories/multimedia:/audio:/KMP/
надеюсь, что это временная мера и за оставшиеся 6 дней появится репо/пакет с недостающими модулями. но, если оно не будет работать и дальше, - не удивлюсь ни капли. стоит заметить, что собранный вручную vanilla kernel 2.6.30.6 со звуком проблем не имел.
пересобрал для "kernel-desktop" (мне нужен "via82xx" например) из alsa-driver-kmp - соснул тунца, ибо alsaconf не увидел карточки даже с подгруженным модулем. ппц. надо попробовать откатиться на рабочий вариант из openSuSE-11.1.
рецепт лечения элементарен (выкидываем альсу, не пожалеете, в референсных мониторах разница очень хорошо различима):
* ставим:
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-source-2.6.31.5-0.1.1.noarch
kernel-syms-2.6.31.5-0.1.1.i586
linux-kernel-headers-2.6.31-3.4.noarch
gcc
make
"autotools"
* чешем за пряниками:
скачать OSS
* ставим:
> sudo rpm -Uhv --nodeps ./oss-linux-v4.2-2002.i386.rpm #(надо тупо обойти проверку на отсутствие kernel-devel пакета, ибо у нас он называется чуток по иному)
* стартуем "ossxmix" и кладём с пробором на alsa, pulse и прочие заморочки :)
3) смена раскладки клавиатуры непринуждённо настраивается засовыванием в автозагрузку чего-то похожего на:
#!/bin/sh
setxkbmap -layout us,ru -option grp:lctrl_lshift_toggle,grp_led:scroll -variant winkeys -model "pc(pc104)"
4) "официальные" репо для ATI/NVIDIA пока не готовы - ставим вручную (что даже лучше для целевой системы, что бы не возражали на это утверждение сторонники "пакетов").
5) хорошо, что не выкинули gfxboot с заменой на splashy (то ещё поделие...)
несмотря на статус RC2 система "сыровата". возможно это связано с новыми версиями "autotools"/devel пакетов, может аляповатость и тормознутость kde вызывают неприятие (хотя в моём случае вина на ублюдочной поддержке аудиокарточек, где openSuSE-11.2 соснула у OpenBSD-4.6). очень достойным шагом будет выкинуть нах Firefox из репо openSuSE и поставить с офсайта Mozilla - тем самым вы получите возможность обновляться без задержек и избавитесь от некоего "подтормаживания" при скроллинге страниц (хз почему, подозреваю какие-то косяки с pango - можно проверить параметры сборки, но Mozilla official и так работает без нареканий). единственное, что придётся поправить руками - пару симлинков на плагины.
многие OBS репо пока не готовы к выходу 11.2 - времени до релиза осталось не так много. ситуация повторяется. пинайте мейнтейнеров - самое время, пора прочухаться.
хвалебные оды уменьшению времени загрузки системы (и какая к буям разница, стартанёт оно за минуту или за 5 секунд - суть-то не в этом, а в том, как РАБОТАТЬ будет) и новому "гламурному" дизайну (не понравился) оставим другим. наше дело - прикрыть бронеплитой родную задницу и гарантировать спокойный сон за рабочим столом (подготовить достойный релиз SOAD Linux, лишённый недостатков "родителя")!
удачи!
P.S. недавно сравнивал последний midori и FF от Mozilla - FF откушал примерно на 5-15% больше памяти (10 вкладок, flash, JS и прочая) и субъективно уделал midori по всем остальным критериям. странно, что тест peacekeeper говорит об ином...
*/
вторник, 18 августа 2009 г.
К вопросу о update/upgrade
/*
... если Ваша программа таки
заработала - то это просто СЧАСТЬЕ...
/Linus Torvalds, вольный перевод/
на сей опус подвигли многочисленные заявления о сокращении сроков поддержки релизов и т.п.. плохо это или хорошо - не мне судить, но ключевой выбор openSUSE/SuSE/SLE* как платформы для изучения/использования/экспериментов в основном обусловлен КАЧЕСТВОМ самого дистрибутива и схемой поддержки (включая латание дыр и т.п.).
на кону у нас очередной "multiple guess question": - "а стоит ли переползать на грядущую openSUSE-11.2?" imho - настоящие джедаи делают "zypper dup" только после kernel upgrade-а в новой версии, или же спустя 2-3 месяца после выхода (да и то по обстоятельствам). о том, каково оно - "переход на новую версию" - писал ранее.
на данный момент в openSUSE-11.1 (oS-11.1) используется стабильная версия ядра 2.6.27.* и для многих пользователей "фишки" новых ядер представляются более предпочтительными. "не вопрос!" с недавних пор в OBS появились новые чудные репо:
Moblin Base
Moblin
где предлагают Вашему вниманию довольно сырой и нестабильный интерфейс, основанный на clutter. это собсно прообраз gnome-3.* и до выхода релиза пользовать его не рекомендуется (ессно для незаинтересованных граждан).
по сути своей интерфейс Moblin очень напоминает "illume" модуль Enlightenment-DR17 по заложенным концепциям. по крайней мере все принципы построения интерфейса "честно" слизаны с illume, что не может не радовать. после добавления указанных выше репо есть возможность поставить себе kernel-2.6.30.5 (последний стабильный релиз) и попробовать его как основу для своей системы. есть пара-тройка моментов, не более. теперь по-порядку:
1) для сукесфули (successfully) ребута в "/etc/modprobe.d/*" все файлы должны иметь расширение "*.conf" (тупенько ручками пририсуем к имени файла это расширение...).
2) убедиться, что поставили "полный фарш":
kernel-default-2.6.30.5-16.1
kernel-default-base-2.6.30.5-16.1
kernel-default-devel-2.6.30.5-16.1
kernel-default-extra-2.6.30.5-16.1
kernel-firmware-20090421.1-5.1
kernel-source-2.6.30.5-16.1
kernel-syms-2.6.30.5-16.1
3) поддержка reiserfs4 чарующе элегантна (как обычно впрочем...):
> wget http://download.opensuse.org/repositories/home:/jeff_mahoney/openSUSE_Factory/src/reiser4-0.1-29.2.src.rpm
> rpmbuild --rebuild ./reiser4-0.1-29.2.src.rpm
> sudo rpm -Uhv /usr/src/packages/RPMS/$ARCH/reiser4-kmp-default-0.1_2.6.30.5_16-29.2.i586.rpm
4) крайне желательно проапгрейдить "e2fsprogs":
> rm /usr/src/packages/RPMS/$ARCH/e2fsprogs*
> wget http://prdownloads.sourceforge.net/e2fsprogs/e2fsprogs-1.41.8.tar.gz
> tar xfm ./e2fsprogs-1.41.8.tar.gz
> cd ./e2fsprogs-1.41.8 && ./configure && cd ../
> ln -s "`pwd`"/e2fsprogs-1.41.8.tar.gz /usr/src/packages/SOURCES/
> cd ./e2fsprogs-1.41.8 && rpmbuild -bb ./e2fsprogs.spec
> sudo rpm -Uhv --force /usr/src/packages/RPMS/$ARCH/e2fsprogs*.rpm
последняя операция проходит "грязно" (с ключём --force) поскольку возможен банальный конфликт базовых утилит. не страшно.
5) зато с "btrfs" у нас "просто Праздник какой-то"!
> zcat /proc/config.gz | grep -i btr
CONFIG_IPV6_SUBTREES=y
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
6) также надо учесть, что конфиг ядра отличается чуток от "канонического". некоторые модули тупо вкомпилены в ядро. например:
'processor', 'thermal', 'fan', 'jbd', 'ext3', 'sd_mod', 'usbcore', 'ohci_hcd', 'uhci-hcd', 'ehci_hcd', 'usbhid' (может что-то ещё, список не полный, только очевидные вещи).
эт всё к тому, что не забудьте (при желании ессно) отрихтовать "/etc/sysconfig/kernel" на придмет "initrd" и всего, что с этим связано. это совершенно не критично, но, если вы конвертнули ext2/3 в ext4 - то пропишите модулёк. udev конечно придумали трусы, но мало ли. не помешает. ессно, что после подобных телодвижений стоит набрать (как минимум):
> sudo mkinitrd
7) NVIDIA-Linux-x86-185.18.31-pkg1.run прекрасно работает с нашим новым ядром (2.6.30.5)
8) AppArmor не портирован (пока).
9) стоит также помнить, что ALSA в новых ядрах "своя". не пугайтесь, если звук пропадёт и "alsaconf" пошлёт вас в известном направлении. откройте "alsamixer" с выводом всех "регуляторов" и пройдитесь по всем "ползункам". например, в случае "via82xx" помогают "*DXS*" и т.д. и т.п..
10) кроме ядра из указанный репо у вас должно пройти обновление до gtk2-2.16, что не может не радовать.
теперь со спокойной душой и чистой совестью можно понаблюдать за "хомячками" и их плясками с openSUSE-11.2.
N.B. если у вас всё работает и вы просто желаете "развлечься", то стоит оставить возможность загрузки системы с её "родных" ядер. для этого скачайте "kernel*2.6.30.5*.rpm" в локальную директорию и проведите команду установки тупо в лоб:
> rpm -i ./kernel*.rpm
так вы сохраните в системе ядра версии 2.6.27.*
удачи.
*/
... если Ваша программа таки
заработала - то это просто СЧАСТЬЕ...
/Linus Torvalds, вольный перевод/
на сей опус подвигли многочисленные заявления о сокращении сроков поддержки релизов и т.п.. плохо это или хорошо - не мне судить, но ключевой выбор openSUSE/SuSE/SLE* как платформы для изучения/использования/экспериментов в основном обусловлен КАЧЕСТВОМ самого дистрибутива и схемой поддержки (включая латание дыр и т.п.).
на кону у нас очередной "multiple guess question": - "а стоит ли переползать на грядущую openSUSE-11.2?" imho - настоящие джедаи делают "zypper dup" только после kernel upgrade-а в новой версии, или же спустя 2-3 месяца после выхода (да и то по обстоятельствам). о том, каково оно - "переход на новую версию" - писал ранее.
на данный момент в openSUSE-11.1 (oS-11.1) используется стабильная версия ядра 2.6.27.* и для многих пользователей "фишки" новых ядер представляются более предпочтительными. "не вопрос!" с недавних пор в OBS появились новые чудные репо:
Moblin Base
Moblin
где предлагают Вашему вниманию довольно сырой и нестабильный интерфейс, основанный на clutter. это собсно прообраз gnome-3.* и до выхода релиза пользовать его не рекомендуется (ессно для незаинтересованных граждан).
по сути своей интерфейс Moblin очень напоминает "illume" модуль Enlightenment-DR17 по заложенным концепциям. по крайней мере все принципы построения интерфейса "честно" слизаны с illume, что не может не радовать. после добавления указанных выше репо есть возможность поставить себе kernel-2.6.30.5 (последний стабильный релиз) и попробовать его как основу для своей системы. есть пара-тройка моментов, не более. теперь по-порядку:
1) для сукесфули (successfully) ребута в "/etc/modprobe.d/*" все файлы должны иметь расширение "*.conf" (тупенько ручками пририсуем к имени файла это расширение...).
2) убедиться, что поставили "полный фарш":
kernel-default-2.6.30.5-16.1
kernel-default-base-2.6.30.5-16.1
kernel-default-devel-2.6.30.5-16.1
kernel-default-extra-2.6.30.5-16.1
kernel-firmware-20090421.1-5.1
kernel-source-2.6.30.5-16.1
kernel-syms-2.6.30.5-16.1
3) поддержка reiserfs4 чарующе элегантна (как обычно впрочем...):
> wget http://download.opensuse.org/repositories/home:/jeff_mahoney/openSUSE_Factory/src/reiser4-0.1-29.2.src.rpm
> rpmbuild --rebuild ./reiser4-0.1-29.2.src.rpm
> sudo rpm -Uhv /usr/src/packages/RPMS/$ARCH/reiser4-kmp-default-0.1_2.6.30.5_16-29.2.i586.rpm
4) крайне желательно проапгрейдить "e2fsprogs":
> rm /usr/src/packages/RPMS/$ARCH/e2fsprogs*
> wget http://prdownloads.sourceforge.net/e2fsprogs/e2fsprogs-1.41.8.tar.gz
> tar xfm ./e2fsprogs-1.41.8.tar.gz
> cd ./e2fsprogs-1.41.8 && ./configure && cd ../
> ln -s "`pwd`"/e2fsprogs-1.41.8.tar.gz /usr/src/packages/SOURCES/
> cd ./e2fsprogs-1.41.8 && rpmbuild -bb ./e2fsprogs.spec
> sudo rpm -Uhv --force /usr/src/packages/RPMS/$ARCH/e2fsprogs*.rpm
последняя операция проходит "грязно" (с ключём --force) поскольку возможен банальный конфликт базовых утилит. не страшно.
5) зато с "btrfs" у нас "просто Праздник какой-то"!
> zcat /proc/config.gz | grep -i btr
CONFIG_IPV6_SUBTREES=y
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
6) также надо учесть, что конфиг ядра отличается чуток от "канонического". некоторые модули тупо вкомпилены в ядро. например:
'processor', 'thermal', 'fan', 'jbd', 'ext3', 'sd_mod', 'usbcore', 'ohci_hcd', 'uhci-hcd', 'ehci_hcd', 'usbhid' (может что-то ещё, список не полный, только очевидные вещи).
эт всё к тому, что не забудьте (при желании ессно) отрихтовать "/etc/sysconfig/kernel" на придмет "initrd" и всего, что с этим связано. это совершенно не критично, но, если вы конвертнули ext2/3 в ext4 - то пропишите модулёк. udev конечно придумали трусы, но мало ли. не помешает. ессно, что после подобных телодвижений стоит набрать (как минимум):
> sudo mkinitrd
7) NVIDIA-Linux-x86-185.18.31-pkg1.run прекрасно работает с нашим новым ядром (2.6.30.5)
8) AppArmor не портирован (пока).
9) стоит также помнить, что ALSA в новых ядрах "своя". не пугайтесь, если звук пропадёт и "alsaconf" пошлёт вас в известном направлении. откройте "alsamixer" с выводом всех "регуляторов" и пройдитесь по всем "ползункам". например, в случае "via82xx" помогают "*DXS*" и т.д. и т.п..
10) кроме ядра из указанный репо у вас должно пройти обновление до gtk2-2.16, что не может не радовать.
теперь со спокойной душой и чистой совестью можно понаблюдать за "хомячками" и их плясками с openSUSE-11.2.
N.B. если у вас всё работает и вы просто желаете "развлечься", то стоит оставить возможность загрузки системы с её "родных" ядер. для этого скачайте "kernel*2.6.30.5*.rpm" в локальную директорию и проведите команду установки тупо в лоб:
> rpm -i ./kernel*.rpm
так вы сохраните в системе ядра версии 2.6.27.*
удачи.
*/
вторник, 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" файлов, рассмотреть создание модулей ядра и просто попиздеть о том о сём... пишите камменты, они рулят!
*/
Сила Маркетинга (или чуток о том, как выдавать желаемое за действительное...)
/*
Что толку быть собой не ведая стыда,
Когда 15 баб резвятся у пруда...
/БГ/
чистота - залог здоровья, порядок - прежде всего, а стабильно работающая система - эт собсно наше всё. какого-то лешего в очередной раз решил проапгрейдить систему с openSUSE-11.0 до openSUSE-11.1 без форматирования рутового раздела. другими словами - апгрейд "на живую", при помощи "волшебной" команды:
sudo zypper dup
собственно решил проверить насколько рекомендации ведущих собаководов соответствуют истине. одну такую попытку Ваш покорный слуга уже описывал ранее. всё конечно же было сукесфули комплитэд (successfully completed), но, дай Бог памяти, текущую систему (11.0) таки ставил с чистого листа, с форматированием рутового раздела. итак нюансы:
1) даже если Вы в добром уме и трезвом здравии буква в буковку следовали "рекомендациям" - в результате (после первой перезагрузки) получится вариант, далёкий от идеала. почему? потому, что логика команды "zypper dup" -говно заточена на минимизацию трафика при апгрейде системы, а не на получение 100% стабильного результата (по крайней мере для openSUSE-11.0). но! всё это легко контролируется и не менее легко и очаровательно приводится в норму. об этом правда многие почему-то умалчивают, либо не обоняя "родное амбрэ", либо не владея техникой постановки любого вопроса раком для последующего сукесфули решения.
2) imho - если Вы можете позволить себе скачать/купить дистрибутив и поставить систему "с нуля" - то именно так и надобно поступать. к тому же форматирование партиции есть суть операция весьма и весьма пользительная...
3) ещё раз перечитайте пункт первый и будьте морально готовы к разгребанию Авгиевых конюшен...
а в чём же тогда смысл апгрейда системы подобным образом? элементарно, Уотсон! если вы - ньюб или неопытный лузер, которому худо-бедно каким-то макаром но удалось настроить систему (или же вы думаете, что она работает так, как Вам надо...), то подобная процедура (Вы не поверите!) сохранит ВСЕ Ваши конфиги! да-да-да! от grub-а и до vsftpd (до настроек в Вашем "хомяке" - $HOME каталоге) - всё останется как было, без глобальных изменений. поэтому суть есть собсно выбор: или Вы способны за 5-15 минут откатить конфиги из бэкапа и подрихтовать их для новой системы, или Вы намерены чуток поебаться с "мягким" апгрейдом. Вам выбирать...
собсно создать бэкап настроек можно при помощи шаблона ниже:
#!/bin/sh
mkdir -p ~/tmp/backup
cd ~/tmp/backup/
sudo tar -cvvjf "`date +%m%d%Y`_etc.tar.bz2" /etc
sudo tar -cvvjf "`date +%m%d%Y`_var_lib_rpm.tar.bz2" /var/lib/rpm
find ~ -maxdepth 1 -type f > ./"$USER"_home_rc && \
tar -cvvjf "`date +%m%d%Y`_home_rc.tar.bz2" -T ./"$USER"_home_rc
итак, вернёмся к нашим "баранам". Вы таки решились не травмировать свою нежную душу восстановлением конфигов, перебили адреса всех репозиториев на новую версию, зашли в консольку, дрожжащими ручонками накорябали (махнув 150 для смелости):
sudo zypper dup
и отправились баиньки, дабы за ночь системка выкачала пару-тройку гигабайт обновлений. урок нумеро уно: не надо обновлять "помойку". сперва откройте тот же YaST (если у Вас толстый канал и хороший провайдер) или воспользуйтесь "rpm -e $packages" и постарайтесь убрать лишнее. так будет проще. поскольку поднятый мной вопрос о компиляции драйверов вызвал оживлённую дискуссию и все мейнтейнеры модулей ядра сразу же добавили "Update" репозитории в свои проекты, то если Вы решились обновиться до текущего стабильного состояния 11.1 - останетесь без пакетов драйверов для ATI/NVIDIA (как минимум, ибо ядро уже обновилось, может ещё что-то "сломается"...). оно конечно же можно и ручками дрова прикрутить, потом, вспомнив, что надо доставить пакеты "kernel-source", "kernel-syms", "linux-kernel-headers", "gcc", "make" и напечатав "init 3" в строке логина. а первым делом забэкапьте и обнулите "/etc/zypp/locks" файл! какого буя об этом молчат "известные собаководы" - непонятно...
sudo cp /etc/zypp/locks /etc/zypp/locks.old
su
(введите Ваш рутовый пароль)
echo "" > /etc/zypp/locks
exit
после чего ещё раз проверьте новые репо и давите на педальку:
sudo zypper ref && sudo zypper dup
как только безобразие закончится - не спешите в ребут. если вам нужно поставить драйвер ATI/NVIDIA - убедитесь, что как минимум стоят упомянутые выше пакеты. также можно до перезагрузки открыть YaST -> Software Management и установить все апдейты, которые он предложит. перегружаемся. если надо ставить дрова - уходим в "init 3" и ставим. возвращаемся в "init 5" и оцениваем "масштаб катастрофы". на первый взбляд всё будет тип-топ. новое ядро, типа новые пакеты, новая система... сверху - шоколадка, а внутри - кокос. сразу было сладко, а теперь приступим к изучению того, что нам оставила команда "zypper dup".
* мантра первая: если вы были уверены в том, что имеете полное право собирать программы из исходников и устанавливать их при помощи "sudo make install" - с результатами разбирайтесь сами. это подтолкнёт вас к изучению формата rpm и написанию кошерных spec файлов в будущем...
* мантра вторая: "не ссы, прорвёмся". всё на самом деле не так уж и плохо, скорее даже наоборот.
* мантра третья: думай своей головой. если с чем-то не согласен и это у тебя работает - есть смысл так и оставить.
* мантра четвёртая:
"Жаль, подмога не пришла
Подкрепленья не прислали
Нас осталось только два
Нас с тобою наебали..."
/БГ/
чтобы в этом убедиться далеко ходить не надо. выполняем команды:
export OLD_VERSION="11.0"
rpm -qai | grep -w "Distribution:" | grep -w "$OLD_VERSION" | wc -l
результат нам покажет сколько пакетов осталось в системе от старой версии. но это не всё.
export OLD_VERSION="(none)"
rpm -qai | grep -w "Distribution:" | grep -w "$OLD_VERSION" | wc -l
это покажет сколько пакетов имеют сомнительное происхождение. может вы собирали их сами, может ставили хз откуда - всё надо перепроверить. осмелюсь предложить вариант.
cd /tmp
rpm -qai > ./packages1
less ./packages1
находим по шаблону "11.0" старый пакет, смотрим как оно называется и рисуем (с правами рута!):
export pac="zsnes llvm llvm-devel" && rpm -e --nodeps $pac ; zypper in $pac
вот таким вот нехитрым макаром надо пройтись по всем пакетам и добиться, чтобы
export OLD_VERSION="11.0"
rpm -qai | grep -w "Distribution:" | grep -w "$OLD_VERSION" | wc -l
в результате в системе не осталось следов от старой версии. с export OLD_VERSION="(none)" проще. в данном случае большинство пакетов есть не что иное как ключи шифрования. оставить их или убрать зависит от Вас и вашего поведения. обращайте внимание на все сообщения при
export pac="PACKAGES" && rpm -e --nodeps $pac ; zypper in $pac
это очень важно! например:
export pac="libx264-60" && rpm -e --nodeps $pac ; zypper in $pac
команда просто удалит x264 бинарь из вашей новой системы и напишет, что для версии 11.1 такого пакета (libx264-60) нет. и правильно, ибо есть пакет/ы libx264-67 и libx264-65! то есть вам надо после сообщения, что "пакет типа не найден нихуя" нарисовать в консоли
sudo zypper se libx264
и посмотреть на "варианты". дело это довольно муторное, должен признать. кроме того есть "нюансы" другого плана...
предположим, что Вы питаете нежную любовь к дивному "продукту" - Pulseaudio и, также как и я, не видите в нём никакого смысла. если в версии openSUSE-11.0 можно было извернуться и не ставить/(не запускать) это быдлоподелие, то в 11.1 без подобного "костыля" не запустится например "Stardict" и ряд других программ. кушать, так сказать, подано, Господа...
ну а в целом оно конечно же очень пиздато. перебил репы, нарисовал "zypper ref && zypper dup" и получил полный апгрейд! без проблем! во как!
*/
Что толку быть собой не ведая стыда,
Когда 15 баб резвятся у пруда...
/БГ/
чистота - залог здоровья, порядок - прежде всего, а стабильно работающая система - эт собсно наше всё. какого-то лешего в очередной раз решил проапгрейдить систему с openSUSE-11.0 до openSUSE-11.1 без форматирования рутового раздела. другими словами - апгрейд "на живую", при помощи "волшебной" команды:
sudo zypper dup
собственно решил проверить насколько рекомендации ведущих собаководов соответствуют истине. одну такую попытку Ваш покорный слуга уже описывал ранее. всё конечно же было сукесфули комплитэд (successfully completed), но, дай Бог памяти, текущую систему (11.0) таки ставил с чистого листа, с форматированием рутового раздела. итак нюансы:
1) даже если Вы в добром уме и трезвом здравии буква в буковку следовали "рекомендациям" - в результате (после первой перезагрузки) получится вариант, далёкий от идеала. почему? потому, что логика команды "zypper dup" -
2) imho - если Вы можете позволить себе скачать/купить дистрибутив и поставить систему "с нуля" - то именно так и надобно поступать. к тому же форматирование партиции есть суть операция весьма и весьма пользительная...
3) ещё раз перечитайте пункт первый и будьте морально готовы к разгребанию Авгиевых конюшен...
а в чём же тогда смысл апгрейда системы подобным образом? элементарно, Уотсон! если вы - ньюб или неопытный лузер, которому худо-бедно каким-то макаром но удалось настроить систему (или же вы думаете, что она работает так, как Вам надо...), то подобная процедура (Вы не поверите!) сохранит ВСЕ Ваши конфиги! да-да-да! от grub-а и до vsftpd (до настроек в Вашем "хомяке" - $HOME каталоге) - всё останется как было, без глобальных изменений. поэтому суть есть собсно выбор: или Вы способны за 5-15 минут откатить конфиги из бэкапа и подрихтовать их для новой системы, или Вы намерены чуток поебаться с "мягким" апгрейдом. Вам выбирать...
/* лирическое отступление */
собсно создать бэкап настроек можно при помощи шаблона ниже:
#!/bin/sh
mkdir -p ~/tmp/backup
cd ~/tmp/backup/
sudo tar -cvvjf "`date +%m%d%Y`_etc.tar.bz2" /etc
sudo tar -cvvjf "`date +%m%d%Y`_var_lib_rpm.tar.bz2" /var/lib/rpm
find ~ -maxdepth 1 -type f > ./"$USER"_home_rc && \
tar -cvvjf "`date +%m%d%Y`_home_rc.tar.bz2" -T ./"$USER"_home_rc
/* звиздец лирического отступления */
итак, вернёмся к нашим "баранам". Вы таки решились не травмировать свою нежную душу восстановлением конфигов, перебили адреса всех репозиториев на новую версию, зашли в консольку, дрожжащими ручонками накорябали (махнув 150 для смелости):
sudo zypper dup
и отправились баиньки, дабы за ночь системка выкачала пару-тройку гигабайт обновлений. урок нумеро уно: не надо обновлять "помойку". сперва откройте тот же YaST (если у Вас толстый канал и хороший провайдер) или воспользуйтесь "rpm -e $packages" и постарайтесь убрать лишнее. так будет проще. поскольку поднятый мной вопрос о компиляции драйверов вызвал оживлённую дискуссию и все мейнтейнеры модулей ядра сразу же добавили "Update" репозитории в свои проекты, то если Вы решились обновиться до текущего стабильного состояния 11.1 - останетесь без пакетов драйверов для ATI/NVIDIA (как минимум, ибо ядро уже обновилось, может ещё что-то "сломается"...). оно конечно же можно и ручками дрова прикрутить, потом, вспомнив, что надо доставить пакеты "kernel-source", "kernel-syms", "linux-kernel-headers", "gcc", "make" и напечатав "init 3" в строке логина. а первым делом забэкапьте и обнулите "/etc/zypp/locks" файл! какого буя об этом молчат "известные собаководы" - непонятно...
sudo cp /etc/zypp/locks /etc/zypp/locks.old
su
(введите Ваш рутовый пароль)
echo "" > /etc/zypp/locks
exit
после чего ещё раз проверьте новые репо и давите на педальку:
sudo zypper ref && sudo zypper dup
как только безобразие закончится - не спешите в ребут. если вам нужно поставить драйвер ATI/NVIDIA - убедитесь, что как минимум стоят упомянутые выше пакеты. также можно до перезагрузки открыть YaST -> Software Management и установить все апдейты, которые он предложит. перегружаемся. если надо ставить дрова - уходим в "init 3" и ставим. возвращаемся в "init 5" и оцениваем "масштаб катастрофы". на первый взбляд всё будет тип-топ. новое ядро, типа новые пакеты, новая система... сверху - шоколадка, а внутри - кокос. сразу было сладко, а теперь приступим к изучению того, что нам оставила команда "zypper dup".
* мантра первая: если вы были уверены в том, что имеете полное право собирать программы из исходников и устанавливать их при помощи "sudo make install" - с результатами разбирайтесь сами. это подтолкнёт вас к изучению формата rpm и написанию кошерных spec файлов в будущем...
* мантра вторая: "не ссы, прорвёмся". всё на самом деле не так уж и плохо, скорее даже наоборот.
* мантра третья: думай своей головой. если с чем-то не согласен и это у тебя работает - есть смысл так и оставить.
* мантра четвёртая:
"Жаль, подмога не пришла
Подкрепленья не прислали
Нас осталось только два
Нас с тобою наебали..."
/БГ/
чтобы в этом убедиться далеко ходить не надо. выполняем команды:
export OLD_VERSION="11.0"
rpm -qai | grep -w "Distribution:" | grep -w "$OLD_VERSION" | wc -l
результат нам покажет сколько пакетов осталось в системе от старой версии. но это не всё.
export OLD_VERSION="(none)"
rpm -qai | grep -w "Distribution:" | grep -w "$OLD_VERSION" | wc -l
это покажет сколько пакетов имеют сомнительное происхождение. может вы собирали их сами, может ставили хз откуда - всё надо перепроверить. осмелюсь предложить вариант.
cd /tmp
rpm -qai > ./packages1
less ./packages1
находим по шаблону "11.0" старый пакет, смотрим как оно называется и рисуем (с правами рута!):
export pac="zsnes llvm llvm-devel" && rpm -e --nodeps $pac ; zypper in $pac
вот таким вот нехитрым макаром надо пройтись по всем пакетам и добиться, чтобы
export OLD_VERSION="11.0"
rpm -qai | grep -w "Distribution:" | grep -w "$OLD_VERSION" | wc -l
в результате в системе не осталось следов от старой версии. с export OLD_VERSION="(none)" проще. в данном случае большинство пакетов есть не что иное как ключи шифрования. оставить их или убрать зависит от Вас и вашего поведения. обращайте внимание на все сообщения при
export pac="PACKAGES" && rpm -e --nodeps $pac ; zypper in $pac
это очень важно! например:
export pac="libx264-60" && rpm -e --nodeps $pac ; zypper in $pac
команда просто удалит x264 бинарь из вашей новой системы и напишет, что для версии 11.1 такого пакета (libx264-60) нет. и правильно, ибо есть пакет/ы libx264-67 и libx264-65! то есть вам надо после сообщения, что "пакет типа не найден нихуя" нарисовать в консоли
sudo zypper se libx264
и посмотреть на "варианты". дело это довольно муторное, должен признать. кроме того есть "нюансы" другого плана...
предположим, что Вы питаете нежную любовь к дивному "продукту" - Pulseaudio и, также как и я, не видите в нём никакого смысла. если в версии openSUSE-11.0 можно было извернуться и не ставить/(не запускать) это быдлоподелие, то в 11.1 без подобного "костыля" не запустится например "Stardict" и ряд других программ. кушать, так сказать, подано, Господа...
ну а в целом оно конечно же очень пиздато. перебил репы, нарисовал "zypper ref && zypper dup" и получил полный апгрейд! без проблем! во как!
*/
пятница, 19 декабря 2008 г.
чудище обло, озорно, огромно, стозевно и лаяй... (часть третья)
/*
часть третья, самая короткая... слил релиз, поставил. пофиксили создание initrd с автоконфигурацией, fetchmail+procmail забирают почту, wmmixer не сегфолтится, косяки со сборкой пакетов правда остались, иксы с драйвером nv ни к чёрту (превед ноутам со встроенной графикой от NVIDIA, в SOAD Linux мы это говно постараемся пофиксить), zypper без "--no-recommends" в сеть выпускать нельзя, даунгрейд версий пакетов без скачивания на локальный диск не прокатывает...
наконец-то столкнулся с тормозами и рывками при воспроизведении MPlayer-а. по всей видимости дело в ядре. может порою чуток для понимания с какого буя это происходит. вроде как ядра от Яна Энгельхардта (используемые в SOAD Linux) избавляют систему от этого досадного недоразумения (для 11.1 сборок пока нет).
файл /etc/zypp/locks появляется при использовании опции "taboo" или же "вручную". по большому счёту первый релиз, целиком подготовленный в OBS, на удивление удачен. релиз эволюционный, очень сбалансированный. стоит ли апдейтиться с 11.0? скорее всего нет. особенно если у вас уже подключены дополнительные специализированные репозитории и нет проблем с оборудованием. это - imho, ибо повторюсь, что от системы мне нужна только база - всё остальное ставлю из своего же репо. то есть всевозможные глюки кед/гнома/мыши и т.п. меня не касаются. в откликах на форуме кто-то недоволен, кто-то рад, но все сходятся в том, что новая схема управления дисками в гуях (она же и в ncurses) - говно. будет лучше, если одумаются и вернут всё как было. если субъективно - то "старая" 11.0 на ext3 винте, которую "и в хвост и в гриву" и много-много-много раз гораздо более "отзывчива" на какие-то мои действия, чем свежеустановленная на reiser3 11.1 (и это при том, что ext3 в Суське - тормозит страшно из-за "mount -o barrier=1" по умолчанию, для проверок контрольных сумм при записи журнала). отчасти это связано с использованием ядра г-на Энгельхардта, но также явно, что дело не только в нём.
огромная работа проведена по формированию новых специализированных репозиториев. хочется отметить фантастическую работу по:
Education
Mozilla
OpenOffice
и прочим, включая games и packman:).
вердиктъ - нормуль! мну ожидал намного более мрачной картины. но с 11.0 "слазить" не буду.
*/
часть третья, самая короткая... слил релиз, поставил. пофиксили создание initrd с автоконфигурацией, fetchmail+procmail забирают почту, wmmixer не сегфолтится, косяки со сборкой пакетов правда остались, иксы с драйвером nv ни к чёрту (превед ноутам со встроенной графикой от NVIDIA, в SOAD Linux мы это говно постараемся пофиксить), zypper без "--no-recommends" в сеть выпускать нельзя, даунгрейд версий пакетов без скачивания на локальный диск не прокатывает...
наконец-то столкнулся с тормозами и рывками при воспроизведении MPlayer-а. по всей видимости дело в ядре. может порою чуток для понимания с какого буя это происходит. вроде как ядра от Яна Энгельхардта (используемые в SOAD Linux) избавляют систему от этого досадного недоразумения (для 11.1 сборок пока нет).
файл /etc/zypp/locks появляется при использовании опции "taboo" или же "вручную". по большому счёту первый релиз, целиком подготовленный в OBS, на удивление удачен. релиз эволюционный, очень сбалансированный. стоит ли апдейтиться с 11.0? скорее всего нет. особенно если у вас уже подключены дополнительные специализированные репозитории и нет проблем с оборудованием. это - imho, ибо повторюсь, что от системы мне нужна только база - всё остальное ставлю из своего же репо. то есть всевозможные глюки кед/гнома/мыши и т.п. меня не касаются. в откликах на форуме кто-то недоволен, кто-то рад, но все сходятся в том, что новая схема управления дисками в гуях (она же и в ncurses) - говно. будет лучше, если одумаются и вернут всё как было. если субъективно - то "старая" 11.0 на ext3 винте, которую "и в хвост и в гриву" и много-много-много раз гораздо более "отзывчива" на какие-то мои действия, чем свежеустановленная на reiser3 11.1 (и это при том, что ext3 в Суське - тормозит страшно из-за "mount -o barrier=1" по умолчанию, для проверок контрольных сумм при записи журнала). отчасти это связано с использованием ядра г-на Энгельхардта, но также явно, что дело не только в нём.
огромная работа проведена по формированию новых специализированных репозиториев. хочется отметить фантастическую работу по:
Education
Mozilla
OpenOffice
и прочим, включая games и packman:).
вердиктъ - нормуль! мну ожидал намного более мрачной картины. но с 11.0 "слазить" не буду.
*/
среда, 17 декабря 2008 г.
чудище обло, озорно, огромно, стозевно и лаяй... (часть вторая)
/*
"терпенье и труд всё перетрут!" - веками утверждают уважаемые анонимные авторы и они, безусловно, правы. но давайте не будем забывать и оппозицию, нашедшую весомый аргумент для опровержения этой догмы:
"сидит милый на скамейке,
хуем долбит три копейки...
хочет сделать три рубля -
не выходит нихуя!"
другими словами терпенье и труд стоят затрачиваемых усилий только если есть хоть какой-то результат (желательно канечно же чтобы он оправдывал или превосходил ожидания).
"снова с Вами мишки Гамми" - таки убедил RC1, что мне нужна установленная новая система, а заниматься багоописательством нонче не намерен. поскольку репо моё многострадальноё уже второй или третий день никак не может завершить "процесс компиляции" - вломил WindowMaker на скорую руку:
нормуль, жить можно. теперь картинка с предупреждением. если хотите, чтобы установка версии 11.1 прошла нормально - снимите флажок, обведённый красным кружочком.
и сделайте как показано ниже:
это (IMHO, если никто не пофиксил в релизе) актуально, если у вас более одного винчестера в компе, и вы используете в биосе порядок загрузки этих винтов, отличный от дефолтного. вероятно, что и в других случаях это поможет предотвратить ошибку "Unable to create 'initrd' for your installed system". при конфиге "автоматом" идёт сбой в порядке именования винтов, после чего нормально проходит инсталляция, а в конце её довольный "дедушка Пиздец"(c) тихонько щёлкает пальцами и вежливо предлагает вам высказаться по этому поводу в багзилле компании Novell.
если раньше любимой страшилкой и пугалкой для народа можно было считать идиотскую фразу про феерические "тормоза YaST-а", то теперь наши политические противники могут с пеной у рта вопеть о тормозах самого установщика (чей интерфейс показан на картинках выше). эт да. что-то в этом есть. кроме того, новый стиль/метод/подход при экспертной работе с дисками (Custom Partitioning) бесит неимоверно. крайне неудобен, медлителен, непривычен. поэтому выбрать текстовый режим установки системы - самое оно. там все хоткеи сразу подсвечены (очень удобно) и тормозов нет и в помине.
дальнейшее требует определённой скидки на факт работы с RC1, а не с релизом, но всё же... тут просто набросано на скорую руку с чем успел столкнуться от момента логина в голую консоль и до момента подъёма иксов. мелочёвка в расчёт не принималась вообще.
1) впервые за 5 или сколько-там-лет связка 'fetchmail+procmail' не смогла забрать почту. логи:
> ~/bin/my_mail
fetchmail: ../sysdeps/posix/getaddrinfo.c:1463: rfc3484_sort: Assertion `src->results[i].native == -1 || src->results[i].native == a2_native' failed.
/home/sda/bin/my_mail: line 2: 4962 Aborted /usr/bin/fetchmail -av -m "/usr/bin/procmail -d %T"
если отбросить здравую идею, что это, блядь, явно происки врагов и шпиёнов - что прикажете думать?
2) есть spec файл, есть OBS, есть логи сборки, где нам сообщают, что пресловутый пакет "wicd" не может быть собран ПАТАМУЧТА.... (смотри первую заметку). есть тот же spec файл и свежеустановленный 11.1-RC1. сборка пакета обрывается на середине, оно "не всасывает" элементарную конструкцию:
%__install -Dm 755 %{SOURCE1} %{buildroot}%{_initrddir}/wicd
логи:
creating /var/tmp/wicd-1.5.6-build/etc/init.d
error: can't copy '/etc/init.d/wicd': doesn't exist or not a regular file
error: Bad exit status from /var/tmp/rpm-tmp.50878 (%install)
спишем на RC1?
3) zypper очень плохо себя ведёт. опцию "--no-recommends" надо вбивать руками, если вы не хотите превратить свою систему в первостатейную свалку. кроме того он отказался с ключом "force" произвести "даунгрейд" версии пакета (пробовал "зиппером" из своих репо поставить нормальный freetype2 без предварительного скачивания и конструкции вида 'rpm -Uhv --nodeps --force ./freet*.rpm' - неудачно...).
4) к вопросу о том, что новые проверки охраняют Лузера от говённых пакетов - полностью с этим согласен после того, как впервые на моей памяти апплет WindowMaker-а "wmmixer" (который, блядь, даже в OpenBSD работает на ура!) разродился сегфолтом, не осилив тяжкий процесс запуска...
примечание: "Ужесточение мер по проверке пакетов, это всётаки хорошо, меньше будет мусора в системе и кривых пакетов." /lexa/ - Лёха, ты не прав... ты очень круто тут не прав, если не понимаешь, что любое исключение в правилах (а таких исключений ноне в ветке 11.1 - море. достаточно лишь в whitelist-ы глянуть...) как-бы намекает на то, что само правило - хуёвое слегонца... до тех пор, пока для openSUSE существуют сторонние репозитории с которых народ ставит себе практически все мультимедиа прилады, и пока будут эти самые "исключения" из общих правил для всех - ситуация будет близка к маразму. посмотрите на OpenBSD - там партия сказала открытым текстом: "идите в жопу со своей виртуализацией и закрытыми спеками на железо!" - и все несогласные проследовали в указанном направлении. кроме того, тебя, Лёха, лишили возможности заценить работу очень крутого пакета - "wicd" - который во многих дистрибутивах используется как основное средство по управлению настройками сети. это не ты решил, что wicd - говно. так решил кто-то за тебя. а ты это схавал и поддакиваешь в догонку...
5) разительного отличия в "джентельменском наборе софта" по сравнению с веткой 11.0 (и даже 10.3) пока не заметил - полное тестирование со всеми феньками делать не охота, бо и так всё работает. оно конечно же приятственно свежую системку на отформатированный третий рейзер закатать - благодать. да, новый кернел, и чо? какое железо мне надо прикупить, чтобы оправдать апгрейд со старых проверенных, оттестированных версий? ладно, хер с ним, с железом, перееду, но мне что, для чтения почты самому fetchmail+procmail собирать? эх...
6) с иксами вопросов не возникло никаких (логин в третий ранлевел по умолчанию для любой новой системы многое "урезает" на корню. ну и естественно, что набор компиляторов, make, autotools, libtool и исходники ядра с симсами и хэдерами очень упрощают жизнь в подавляющем большинстве случаев). файло /etc/X11/xorg.conf обнаружено не было (это уже ни для кого не новость). карточка GF6600gt со свободным драйвером "nv" завесила Xorg с его дивными "внутренними" конфигами наглухо, тварь сдохла на конструкции "kill -9 `pgrep X `", после чего проприетарный драйвер NVIDIA 177.80 разрулил ситуацию ни капельки не напрягаясь (с чем его и поздравили боты в третьем квейке). ручками только дорисовал переключение раскладки клавиатуры.
вот вроде и всё на сегодня. иксы стартанули, раскладка что в иксах, что в консоли меняется, vim и urxvt стоят - нормуль. пожалуй сделаю из 11.1 тестовую помойку. нахапаю себе всё и сразу - и гном, и мышу, и кеды, и моно с биглем, и ещё одни кеды и всё-всё-всё что увижу. уёбкиты там всяческие, фаноны-маноны-флэшоны и прочую галиматью... потом форматну диск ещё раз и накачу из своего репо Ешку, Tracker, ROX, linuxdcpp (с мультипотоковой закачкой на ядре 707), SciTE, aria2, нормальный pidgin, xchm, jwm и пойду на ЛОР тупить о том, как это охуительно - убрать плазмоид из центра/середины второго амарока, ибо после этого амарок просто летает...
to be continued...
*/
"терпенье и труд всё перетрут!" - веками утверждают уважаемые анонимные авторы и они, безусловно, правы. но давайте не будем забывать и оппозицию, нашедшую весомый аргумент для опровержения этой догмы:
"сидит милый на скамейке,
хуем долбит три копейки...
хочет сделать три рубля -
не выходит нихуя!"
другими словами терпенье и труд стоят затрачиваемых усилий только если есть хоть какой-то результат (желательно канечно же чтобы он оправдывал или превосходил ожидания).
"снова с Вами мишки Гамми" - таки убедил RC1, что мне нужна установленная новая система, а заниматься багоописательством нонче не намерен. поскольку репо моё многострадальноё уже второй или третий день никак не может завершить "процесс компиляции" - вломил WindowMaker на скорую руку:
нормуль, жить можно. теперь картинка с предупреждением. если хотите, чтобы установка версии 11.1 прошла нормально - снимите флажок, обведённый красным кружочком.
и сделайте как показано ниже:
это (IMHO, если никто не пофиксил в релизе) актуально, если у вас более одного винчестера в компе, и вы используете в биосе порядок загрузки этих винтов, отличный от дефолтного. вероятно, что и в других случаях это поможет предотвратить ошибку "Unable to create 'initrd' for your installed system". при конфиге "автоматом" идёт сбой в порядке именования винтов, после чего нормально проходит инсталляция, а в конце её довольный "дедушка Пиздец"(c) тихонько щёлкает пальцами и вежливо предлагает вам высказаться по этому поводу в багзилле компании Novell.
если раньше любимой страшилкой и пугалкой для народа можно было считать идиотскую фразу про феерические "тормоза YaST-а", то теперь наши политические противники могут с пеной у рта вопеть о тормозах самого установщика (чей интерфейс показан на картинках выше). эт да. что-то в этом есть. кроме того, новый стиль/метод/подход при экспертной работе с дисками (Custom Partitioning) бесит неимоверно. крайне неудобен, медлителен, непривычен. поэтому выбрать текстовый режим установки системы - самое оно. там все хоткеи сразу подсвечены (очень удобно) и тормозов нет и в помине.
дальнейшее требует определённой скидки на факт работы с RC1, а не с релизом, но всё же... тут просто набросано на скорую руку с чем успел столкнуться от момента логина в голую консоль и до момента подъёма иксов. мелочёвка в расчёт не принималась вообще.
1) впервые за 5 или сколько-там-лет связка 'fetchmail+procmail' не смогла забрать почту. логи:
> ~/bin/my_mail
fetchmail: ../sysdeps/posix/getaddrinfo.c:1463: rfc3484_sort: Assertion `src->results[i].native == -1 || src->results[i].native == a2_native' failed.
/home/sda/bin/my_mail: line 2: 4962 Aborted /usr/bin/fetchmail -av -m "/usr/bin/procmail -d %T"
если отбросить здравую идею, что это, блядь, явно происки врагов и шпиёнов - что прикажете думать?
2) есть spec файл, есть OBS, есть логи сборки, где нам сообщают, что пресловутый пакет "wicd" не может быть собран ПАТАМУЧТА.... (смотри первую заметку). есть тот же spec файл и свежеустановленный 11.1-RC1. сборка пакета обрывается на середине, оно "не всасывает" элементарную конструкцию:
%__install -Dm 755 %{SOURCE1} %{buildroot}%{_initrddir}/wicd
логи:
creating /var/tmp/wicd-1.5.6-build/etc/init.d
error: can't copy '/etc/init.d/wicd': doesn't exist or not a regular file
error: Bad exit status from /var/tmp/rpm-tmp.50878 (%install)
спишем на RC1?
3) zypper очень плохо себя ведёт. опцию "--no-recommends" надо вбивать руками, если вы не хотите превратить свою систему в первостатейную свалку. кроме того он отказался с ключом "force" произвести "даунгрейд" версии пакета (пробовал "зиппером" из своих репо поставить нормальный freetype2 без предварительного скачивания и конструкции вида 'rpm -Uhv --nodeps --force ./freet*.rpm' - неудачно...).
4) к вопросу о том, что новые проверки охраняют Лузера от говённых пакетов - полностью с этим согласен после того, как впервые на моей памяти апплет WindowMaker-а "wmmixer" (который, блядь, даже в OpenBSD работает на ура!) разродился сегфолтом, не осилив тяжкий процесс запуска...
примечание: "Ужесточение мер по проверке пакетов, это всётаки хорошо, меньше будет мусора в системе и кривых пакетов." /lexa/ - Лёха, ты не прав... ты очень круто тут не прав, если не понимаешь, что любое исключение в правилах (а таких исключений ноне в ветке 11.1 - море. достаточно лишь в whitelist-ы глянуть...) как-бы намекает на то, что само правило - хуёвое слегонца... до тех пор, пока для openSUSE существуют сторонние репозитории с которых народ ставит себе практически все мультимедиа прилады, и пока будут эти самые "исключения" из общих правил для всех - ситуация будет близка к маразму. посмотрите на OpenBSD - там партия сказала открытым текстом: "идите в жопу со своей виртуализацией и закрытыми спеками на железо!" - и все несогласные проследовали в указанном направлении. кроме того, тебя, Лёха, лишили возможности заценить работу очень крутого пакета - "wicd" - который во многих дистрибутивах используется как основное средство по управлению настройками сети. это не ты решил, что wicd - говно. так решил кто-то за тебя. а ты это схавал и поддакиваешь в догонку...
5) разительного отличия в "джентельменском наборе софта" по сравнению с веткой 11.0 (и даже 10.3) пока не заметил - полное тестирование со всеми феньками делать не охота, бо и так всё работает. оно конечно же приятственно свежую системку на отформатированный третий рейзер закатать - благодать. да, новый кернел, и чо? какое железо мне надо прикупить, чтобы оправдать апгрейд со старых проверенных, оттестированных версий? ладно, хер с ним, с железом, перееду, но мне что, для чтения почты самому fetchmail+procmail собирать? эх...
6) с иксами вопросов не возникло никаких (логин в третий ранлевел по умолчанию для любой новой системы многое "урезает" на корню. ну и естественно, что набор компиляторов, make, autotools, libtool и исходники ядра с симсами и хэдерами очень упрощают жизнь в подавляющем большинстве случаев). файло /etc/X11/xorg.conf обнаружено не было (это уже ни для кого не новость). карточка GF6600gt со свободным драйвером "nv" завесила Xorg с его дивными "внутренними" конфигами наглухо, тварь сдохла на конструкции "kill -9 `pgrep X `", после чего проприетарный драйвер NVIDIA 177.80 разрулил ситуацию ни капельки не напрягаясь (с чем его и поздравили боты в третьем квейке). ручками только дорисовал переключение раскладки клавиатуры.
вот вроде и всё на сегодня. иксы стартанули, раскладка что в иксах, что в консоли меняется, vim и urxvt стоят - нормуль. пожалуй сделаю из 11.1 тестовую помойку. нахапаю себе всё и сразу - и гном, и мышу, и кеды, и моно с биглем, и ещё одни кеды и всё-всё-всё что увижу. уёбкиты там всяческие, фаноны-маноны-флэшоны и прочую галиматью... потом форматну диск ещё раз и накачу из своего репо Ешку, Tracker, ROX, linuxdcpp (с мультипотоковой закачкой на ядре 707), SciTE, aria2, нормальный pidgin, xchm, jwm и пойду на ЛОР тупить о том, как это охуительно - убрать плазмоид из центра/середины второго амарока, ибо после этого амарок просто летает...
to be continued...
*/
вторник, 16 декабря 2008 г.
чудище обло, озорно, огромно, стозевно и лаяй... (часть первая)
/*
Disclaimer: all written below are just my thoughts and they are not intended to offend or hurt any one. may be this thoughts are the result of my stupidity. who knows... IMHO in and out Ladies and Gents!
заява типа: начальника, я - виноват, дурак, исправлюсь! только пожрать дай, а?!
заметка сия, братие, есть пасквиль гнустный, поклёп, донос и прообраз мыслишек, что умыслил под рождество Христово автор блога сего (стервец преизрядный и мерзавецъ) вывалить на благостныя тучныя поля сообщества openSUSE иноземного. токмо сомненья грызуть - надо ли? а посему ассоциативный ряд поручика Ржевского в цветочной лаке, рюхающего, что именно ему должно прикупить для Дамы, как никогда мне близок и понятен (для тех, кто запамятовал - "... э-э-э... м-м-м.. Могу ли я?.... Хочу ли я?... э-э-э... Говно ли я?...О! ... МАГНОЛИЯ!!!").
вот-вот увидит свет очередной релиз openSUSE - 11.1, которая наше фсио и всё такое. в кои-то веки решился на установку и тестирование RC1 - один херъ кроме базовой системы остальное собираю в своём OBS репо, что собственно и сподвигло на эксперимент.
оду восхваления нового релиза первым прокукарекал слэшдот (вроде как). моё же "знакомство" с ним началось с "изнанки". с того самого момента, как в OBS (OpenSUSE Build Service) подключил новые репозитории для ветки 11.1 и... магнолия... понятно, что мои спек-файлы далеки от идеала (были далеки до недавнего времени). ибо зрела задумка по минимальному использованию специфических rpm-макросов для более лёгкого портирования на другие дистрибутивы. с выходом 11.1 енто "рацпредложение" с треском провалилось. "учите матчасть, Шура, и пилите гири! они, Шура, золотые..."(c)(tm)
- Ну что, милок, оргазм?!
-... лучше....
это самое "лучше" было и у мну опосля взгляда на своё репо для 11.1. "шок! это - по-нашему!"(c)(tm). с момента ввода в строй OBS партия шла намеченным курсом на подготовку всех будущих релизов при помощи этой службы/(этого сервиса). результат перед нами - openSUSE-11.1 (по ссылке смогут пройти только те, кто имеет Novell account и доступ в OBS). все пакеты собраны в OBS. на первый взгляд - круть! можно без выкачивания сырцов ломануться и глянуть, кто собирал, как собирал, что и нахуя патчил и какие логи вылетели при компиляции пакета (то есть практически получить все сведения о пакете с минимальными усилиями в глаза его не видя). теперь давайте вспомним о сильных сторонах Суськи: качество, надёжность, поддержка официального дистрибутива 7/24, мейнтейнер/инженер Novell/SUSE за любым пакетом, эталонная "база" (glibc, kernel, cureutils и т.п.). токмо любая палка - о двух концах. вот второй-то "конец" взвился и вдарил по мейнтейнерам, чьи пакеты в "home:/" репозиториях не имеют отношения к официальной дистрибуции. для обеспечения упомянутого выше качества сборки (и не только) внутренние пресеты механизмов проверок Novell/SUSE автоматом скинули в OBS на всю ветку 11.1/Factory и в дополнение к rpmlint-у влепили brp проверки, которые в теории отключить никак нельзя. то бишь ноне в ветках 11.1/Factory действуют двое полицейских (rpmlint и brp). первый - "хороший", полностью контролируем мейнтейнером, можно при желании выключить ту или иную проверку или отключить их все. с brp на данный момент всё "гораздо, блядь, мрачней"(c)(tm). отключить/обойти brp по официальной версии низзя (на практике - мона, но требует нехуёвых познаний в механике OBS и специфике формата rpm как такового. как именно обходить - не скажу, шукайте сами, коли приспичило. причём не стану описывать способы обхода brp не потому, что жаль - отнюдь. просто подозреваю, что если эта информация будет растиражирована, то выебут не "манагеров", вломивших пресеты проверок без адаптации для всех разом и спровоцировавших тем самым приступ неуёмной любознательности, а каких-нить работяг, кто эти пресеты на коленке рисовал с верой в светлое будущее). официальная "версия" почему нам всем пиздец как нужен brp в дополнение к rpmlint-у в грубом переводе на великий и могучий звучит где-то так: "мы конвейром повышаем производительность труда!" они де способствуют улучшению качества собираемых пакетов, помогают предотвращать всевозможные ошибки и т.п. и т.д. из серии "взялся за грудь - так скажи что-нибудь!" разбор всех зашитых шаблонов brp займёт многовато времени, посему ограничусь "шедеврами коллекции" (сугубо на мой взгляд):
* Warning: This package installs an unknown D-BUS autostart/system service. Please contact security-team@suse.de: wicd.conf
error: Bad exit status from /var/tmp/rpm-tmp.1086 (%install)
пояснение: сборка пакетов "wicd", "exalt" и всех прочих, что устанавливают файло, не внесённое в "белый список" (эт типа список разрешённых файлов в каталоге /etc/dbus-1/system.d/ с конфигом политик hal+dbus+udev) идёт нахуй. такие пакеты openSUSE не нужны by default. как пионэр написал об этой досадной оплошности по указанному адресу. обещали разобраться. ждём-с. а некоторые индивидуумы (якобы сотрудники Novell/SUSE) вот в этом трэде форума объявили меня "господином соврамши-с". с другой стороны в каждой шутке есть доля шутки. может и правда такие пакеты нахуй никому, кроме меня/прочих мейнтейнеров, не нужны...
* ERROR: translation is neither enabled nor disabled for this file: /tmp/scite-1.77-build//usr/share/applications/SciTE.desktop
пояснение: теперь ошибка в содержании лаунчера приложения (.desktop файл, устанавливаемый как правило в $XDG_DATA_DIRS/applications/ и подхватываемый xdg-menu) может легко похерить компиляцию. с ветки 11.1 все подобные desktop файлы трэба скармливать на убой rpm макросу %suse_update_desktop_file и как "Отче Наш" учить не только группы rpm пакетов, но и freedesktop-овы спеки на desktop файло для меню. если кто-то думает, что чудо-макрос хитрым вывертом организует автоматический перевод/трансляцию на все локали, установленные в системе, где собираем пакет - "а вот хуй!"(c)(tm). он лишь скромненько так добавит в конец файла строку: "X-SuSE-translate=" (после знака равенства идёт значение булевой переменной true или false).
* wicd: "/usr/share/locale/no/LC_MESSAGES/wicd.mo" is not allowed anymore in SuSE Linux.
Please use nb or nb_NO (and nn for nynorsk)
see https://bugzilla.novell.com/show_bug.cgi?id=42748
пояснение: из разряда "no comments". достаточно пройти по ссылке выше и почитать перлы в багзилле и обратите внимание на дату создания самого багрепорта и его богатую историю.
этого кому-то показалось "маловато будет" и вколотили явное объявление только тех файлов и каталогов, которые специфичны для компилируемого пакета. "эт ты, Степан, мощно задвинул! внушает!" (Хрюн tm). проиллюстрируем. все любители в %files (секция спек-файла где перечисляют какие именно файлы должны входить в собираемый пакет) рисовать универсальный "глобальный" паттерн вида "/*" отныне идут нахуй без задержек и волокиты (что есть правильно по большому-то счёту). но если переводчики/локализаторы софтинки расстарались не на шутку и сделали адаптацию для локали, не учтённой в корневом пакете "filesystem" - то вам придётся декларировать отдельно как минимум два каталога: собсно локаль и локаль/LC_MESSAGES (меж тем файло локализации "локаль/LC_MESSAGES/пакет.mo" определяется макросом %find_land и вроде как уже учтено в составе пакета, ежели с этим макросом вы в друзьях).
%find_land - это отдельная песнь... его задача крайне проста: прошарить %{buildroot}%{_datadir}/locale на предмет '*.mo' файлов и составить их список для последующего включения в %files. удивлению не было предела, когда выяснилось, что имеет значение МЕСТО вызова этого макроса. если упростить до предела, то это чудо работает только если вызывать стоя в /usr/src/packages/BUILD/ (место куда по-умолчанию распаковывают исходники пакета для последующей сборки). "листья тополя падали с ясеня..."(c)
апофеозом этого праздника потихоньку становится моя переписка с openSUSE Security Team. паттерны проверок rpmlint-ом тоже ужесточили и подумалось мне - грешно проявлять самодеятельность. коли OBS настаивает связаться с Security Team - то нехер выёбываться. стучать - так стучать! по полной. достучался... (причём сижу щас и думаю, плюнуть или довести историю до образца эталонного маразма...). начало было весьма скромным:
E17.i586: E: permissions-file-setuid-bit (Badness: 10000) /usr/bin/enlightenment_sys is packaged with setuid/setgid bits (04555)
E17.i586: E: permissions-file-setuid-bit (Badness: 10000) /usr/lib/enlightenment/modules/cpufreq/linux-gnu-i686/freqset is packaged with setuid/setgid bits (04555)
Please remove the setuid/setgid bits or contact security@suse.de for review.
OBS просекла (проверка rpmlint-а), что указанные бинари идут с "суицидом" и не помечены в потрохах проверок как благонадёжные, а посему сборку надо резко и быстро прекращать. и тут я лоханулся. вместо тихого удушения rpmlint-ика (шоб и мявкать не смел, скотина) взял сдуру и настучал куда просили. аки патриот приложил подробные объяснения зачем и почему суидник тут нужон. приходит ответ (грубый перевод, всем желающим почитать оригинал - сюда): "используй то, что под рукою и не ищи себе другое!"(c) с указанием пользовать прогу "powersave" и механизм DBUS для реализации требуемого функционала без суида. в конце ссылки с орининалом ответа наглядно показано, что рекомендации в чистом виде не стоят и ломанного гроша, ибо "из коробки" не работают. они, как минимум, требуют рутового вмешательства для перехуяривания дефолтных политик на hal+udev+dbus (очень занятие нескучное кстати). не забываем, что если кто-то найдёт в том же hal-е ошибку переполнения буфера - то с тихой улыбкой вздрючит систему по самые гланды. глобальная разблядовка под юзера интерфейсов hal-а тоже как-то... хуёво выглядит со всех сторон. что-то подсказывает, что форсировать эту тему не стоит. сделаю вид, что подобным ответом вполне доволен.
переполненный до краёв положительными эмоциями, весь из себя такой позитивный и патриотичный, лью дивидишку с RC1, прожигаю wodim-ом (знаю, жесть и олдскул, но ни одной болванки пока не запорол таким макаром), тыкаю в кнопочки гламурного инсталлера и иду нахуй с ошибкой о невозможности создать initrd для только что установленной системы. плюс эдакое ненавязчивое предложение оформить баг в багзиллу... довыёбывался...
сажусь писать эту заметку, дабы как-то структурировать бурлящие флюиды радости и вычленить рациональное из эмоционального хаоса. перечитываю. думаю, стоит ли уточнять, что в данном контексте термин "взгляд с изнанки" не вполне отражает место откуда и куда сей "взгляд" идёт...
часть вторая будет как поставлю себе это диво. пока калялкал заметку - зарядил апдейт своего репозитория. чую, что в связи с предстоящим релизом пакетики пересоберутся ой как не скоро (в OBS аншлаг). не страшно. я - спокоен как удав, взор мой светел и рожа моя радостно ухмыляется своему отражению в глянцевой поверхности монитора...
to be continued...
*/
Disclaimer: all written below are just my thoughts and they are not intended to offend or hurt any one. may be this thoughts are the result of my stupidity. who knows... IMHO in and out Ladies and Gents!
заява типа: начальника, я - виноват, дурак, исправлюсь! только пожрать дай, а?!
заметка сия, братие, есть пасквиль гнустный, поклёп, донос и прообраз мыслишек, что умыслил под рождество Христово автор блога сего (стервец преизрядный и мерзавецъ) вывалить на благостныя тучныя поля сообщества openSUSE иноземного. токмо сомненья грызуть - надо ли? а посему ассоциативный ряд поручика Ржевского в цветочной лаке, рюхающего, что именно ему должно прикупить для Дамы, как никогда мне близок и понятен (для тех, кто запамятовал - "... э-э-э... м-м-м.. Могу ли я?.... Хочу ли я?... э-э-э... Говно ли я?...О! ... МАГНОЛИЯ!!!").
вот-вот увидит свет очередной релиз openSUSE - 11.1, которая наше фсио и всё такое. в кои-то веки решился на установку и тестирование RC1 - один херъ кроме базовой системы остальное собираю в своём OBS репо, что собственно и сподвигло на эксперимент.
оду восхваления нового релиза первым прокукарекал слэшдот (вроде как). моё же "знакомство" с ним началось с "изнанки". с того самого момента, как в OBS (OpenSUSE Build Service) подключил новые репозитории для ветки 11.1 и... магнолия... понятно, что мои спек-файлы далеки от идеала (были далеки до недавнего времени). ибо зрела задумка по минимальному использованию специфических rpm-макросов для более лёгкого портирования на другие дистрибутивы. с выходом 11.1 енто "рацпредложение" с треском провалилось. "учите матчасть, Шура, и пилите гири! они, Шура, золотые..."(c)(tm)
- Ну что, милок, оргазм?!
-... лучше....
это самое "лучше" было и у мну опосля взгляда на своё репо для 11.1. "шок! это - по-нашему!"(c)(tm). с момента ввода в строй OBS партия шла намеченным курсом на подготовку всех будущих релизов при помощи этой службы/(этого сервиса). результат перед нами - openSUSE-11.1 (по ссылке смогут пройти только те, кто имеет Novell account и доступ в OBS). все пакеты собраны в OBS. на первый взгляд - круть! можно без выкачивания сырцов ломануться и глянуть, кто собирал, как собирал, что и нахуя патчил и какие логи вылетели при компиляции пакета (то есть практически получить все сведения о пакете с минимальными усилиями в глаза его не видя). теперь давайте вспомним о сильных сторонах Суськи: качество, надёжность, поддержка официального дистрибутива 7/24, мейнтейнер/инженер Novell/SUSE за любым пакетом, эталонная "база" (glibc, kernel, cureutils и т.п.). токмо любая палка - о двух концах. вот второй-то "конец" взвился и вдарил по мейнтейнерам, чьи пакеты в "home:/" репозиториях не имеют отношения к официальной дистрибуции. для обеспечения упомянутого выше качества сборки (и не только) внутренние пресеты механизмов проверок Novell/SUSE автоматом скинули в OBS на всю ветку 11.1/Factory и в дополнение к rpmlint-у влепили brp проверки, которые в теории отключить никак нельзя. то бишь ноне в ветках 11.1/Factory действуют двое полицейских (rpmlint и brp). первый - "хороший", полностью контролируем мейнтейнером, можно при желании выключить ту или иную проверку или отключить их все. с brp на данный момент всё "гораздо, блядь, мрачней"(c)(tm). отключить/обойти brp по официальной версии низзя (на практике - мона, но требует нехуёвых познаний в механике OBS и специфике формата rpm как такового. как именно обходить - не скажу, шукайте сами, коли приспичило. причём не стану описывать способы обхода brp не потому, что жаль - отнюдь. просто подозреваю, что если эта информация будет растиражирована, то выебут не "манагеров", вломивших пресеты проверок без адаптации для всех разом и спровоцировавших тем самым приступ неуёмной любознательности, а каких-нить работяг, кто эти пресеты на коленке рисовал с верой в светлое будущее). официальная "версия" почему нам всем пиздец как нужен brp в дополнение к rpmlint-у в грубом переводе на великий и могучий звучит где-то так: "мы конвейром повышаем производительность труда!" они де способствуют улучшению качества собираемых пакетов, помогают предотвращать всевозможные ошибки и т.п. и т.д. из серии "взялся за грудь - так скажи что-нибудь!" разбор всех зашитых шаблонов brp займёт многовато времени, посему ограничусь "шедеврами коллекции" (сугубо на мой взгляд):
* Warning: This package installs an unknown D-BUS autostart/system service. Please contact security-team@suse.de: wicd.conf
error: Bad exit status from /var/tmp/rpm-tmp.1086 (%install)
пояснение: сборка пакетов "wicd", "exalt" и всех прочих, что устанавливают файло, не внесённое в "белый список" (эт типа список разрешённых файлов в каталоге /etc/dbus-1/system.d/ с конфигом политик hal+dbus+udev) идёт нахуй. такие пакеты openSUSE не нужны by default. как пионэр написал об этой досадной оплошности по указанному адресу. обещали разобраться. ждём-с. а некоторые индивидуумы (якобы сотрудники Novell/SUSE) вот в этом трэде форума объявили меня "господином соврамши-с". с другой стороны в каждой шутке есть доля шутки. может и правда такие пакеты нахуй никому, кроме меня/прочих мейнтейнеров, не нужны...
* ERROR: translation is neither enabled nor disabled for this file: /tmp/scite-1.77-build//usr/share/applications/SciTE.desktop
пояснение: теперь ошибка в содержании лаунчера приложения (.desktop файл, устанавливаемый как правило в $XDG_DATA_DIRS/applications/ и подхватываемый xdg-menu) может легко похерить компиляцию. с ветки 11.1 все подобные desktop файлы трэба скармливать на убой rpm макросу %suse_update_desktop_file и как "Отче Наш" учить не только группы rpm пакетов, но и freedesktop-овы спеки на desktop файло для меню. если кто-то думает, что чудо-макрос хитрым вывертом организует автоматический перевод/трансляцию на все локали, установленные в системе, где собираем пакет - "а вот хуй!"(c)(tm). он лишь скромненько так добавит в конец файла строку: "X-SuSE-translate=" (после знака равенства идёт значение булевой переменной true или false).
* wicd: "/usr/share/locale/no/LC_MESSAGES/wicd.mo" is not allowed anymore in SuSE Linux.
Please use nb or nb_NO (and nn for nynorsk)
see https://bugzilla.novell.com/show_bug.cgi?id=42748
пояснение: из разряда "no comments". достаточно пройти по ссылке выше и почитать перлы в багзилле и обратите внимание на дату создания самого багрепорта и его богатую историю.
этого кому-то показалось "маловато будет" и вколотили явное объявление только тех файлов и каталогов, которые специфичны для компилируемого пакета. "эт ты, Степан, мощно задвинул! внушает!" (Хрюн tm). проиллюстрируем. все любители в %files (секция спек-файла где перечисляют какие именно файлы должны входить в собираемый пакет) рисовать универсальный "глобальный" паттерн вида "/*" отныне идут нахуй без задержек и волокиты (что есть правильно по большому-то счёту). но если переводчики/локализаторы софтинки расстарались не на шутку и сделали адаптацию для локали, не учтённой в корневом пакете "filesystem" - то вам придётся декларировать отдельно как минимум два каталога: собсно локаль и локаль/LC_MESSAGES (меж тем файло локализации "локаль/LC_MESSAGES/пакет.mo" определяется макросом %find_land и вроде как уже учтено в составе пакета, ежели с этим макросом вы в друзьях).
%find_land - это отдельная песнь... его задача крайне проста: прошарить %{buildroot}%{_datadir}/locale на предмет '*.mo' файлов и составить их список для последующего включения в %files. удивлению не было предела, когда выяснилось, что имеет значение МЕСТО вызова этого макроса. если упростить до предела, то это чудо работает только если вызывать стоя в /usr/src/packages/BUILD/ (место куда по-умолчанию распаковывают исходники пакета для последующей сборки). "листья тополя падали с ясеня..."(c)
апофеозом этого праздника потихоньку становится моя переписка с openSUSE Security Team. паттерны проверок rpmlint-ом тоже ужесточили и подумалось мне - грешно проявлять самодеятельность. коли OBS настаивает связаться с Security Team - то нехер выёбываться. стучать - так стучать! по полной. достучался... (причём сижу щас и думаю, плюнуть или довести историю до образца эталонного маразма...). начало было весьма скромным:
E17.i586: E: permissions-file-setuid-bit (Badness: 10000) /usr/bin/enlightenment_sys is packaged with setuid/setgid bits (04555)
E17.i586: E: permissions-file-setuid-bit (Badness: 10000) /usr/lib/enlightenment/modules/cpufreq/linux-gnu-i686/freqset is packaged with setuid/setgid bits (04555)
Please remove the setuid/setgid bits or contact security@suse.de for review.
OBS просекла (проверка rpmlint-а), что указанные бинари идут с "суицидом" и не помечены в потрохах проверок как благонадёжные, а посему сборку надо резко и быстро прекращать. и тут я лоханулся. вместо тихого удушения rpmlint-ика (шоб и мявкать не смел, скотина) взял сдуру и настучал куда просили. аки патриот приложил подробные объяснения зачем и почему суидник тут нужон. приходит ответ (грубый перевод, всем желающим почитать оригинал - сюда): "используй то, что под рукою и не ищи себе другое!"(c) с указанием пользовать прогу "powersave" и механизм DBUS для реализации требуемого функционала без суида. в конце ссылки с орининалом ответа наглядно показано, что рекомендации в чистом виде не стоят и ломанного гроша, ибо "из коробки" не работают. они, как минимум, требуют рутового вмешательства для перехуяривания дефолтных политик на hal+udev+dbus (очень занятие нескучное кстати). не забываем, что если кто-то найдёт в том же hal-е ошибку переполнения буфера - то с тихой улыбкой вздрючит систему по самые гланды. глобальная разблядовка под юзера интерфейсов hal-а тоже как-то... хуёво выглядит со всех сторон. что-то подсказывает, что форсировать эту тему не стоит. сделаю вид, что подобным ответом вполне доволен.
переполненный до краёв положительными эмоциями, весь из себя такой позитивный и патриотичный, лью дивидишку с RC1, прожигаю wodim-ом (знаю, жесть и олдскул, но ни одной болванки пока не запорол таким макаром), тыкаю в кнопочки гламурного инсталлера и иду нахуй с ошибкой о невозможности создать initrd для только что установленной системы. плюс эдакое ненавязчивое предложение оформить баг в багзиллу... довыёбывался...
сажусь писать эту заметку, дабы как-то структурировать бурлящие флюиды радости и вычленить рациональное из эмоционального хаоса. перечитываю. думаю, стоит ли уточнять, что в данном контексте термин "взгляд с изнанки" не вполне отражает место откуда и куда сей "взгляд" идёт...
часть вторая будет как поставлю себе это диво. пока калялкал заметку - зарядил апдейт своего репозитория. чую, что в связи с предстоящим релизом пакетики пересоберутся ой как не скоро (в OBS аншлаг). не страшно. я - спокоен как удав, взор мой светел и рожа моя радостно ухмыляется своему отражению в глянцевой поверхности монитора...
to be continued...
*/
Подписаться на:
Комментарии (Atom)
