/*
here we go:
openSUSE Lizards
Download page
Happy New Year!
*****************************
всех - с Наступающим! ссылки на очередной релиз даны выше.
удачи.
*/
четверг, 25 декабря 2008 г.
пятница, 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...
*/
понедельник, 15 декабря 2008 г.
tips and tricks - this song will last forever...
/*
в общем тема реально вечная. чем больше "приколов" ты узнаёшь - тем больше понимаешь, какой баран ты есть на самом деле. так что в этой заметке буду время от времени добрасывать ссылки на всякие прикольные "феньки" с использованием командной строки с кратенькими комментариями (коли в оных будет нужда).
поехали...
советы французского товарища Эрика на все случаи жизни
узнать все доступные методы DBUS-а:
dbus-send --system --print-reply --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer org.freedesktop.DBus.Introspectable.Introspect
получить список DBUS интерфейсов, с которыми потом можно "пообщаться" при помощи dbus-send --dest=INTERFACE:
dbus-send --system --print-reply --dest=org.freedesktop.DBus /org/freedesktop/Hal/devices/computer org.freedesktop.DBus.ListNames
to be continued...
*/
в общем тема реально вечная. чем больше "приколов" ты узнаёшь - тем больше понимаешь, какой баран ты есть на самом деле. так что в этой заметке буду время от времени добрасывать ссылки на всякие прикольные "феньки" с использованием командной строки с кратенькими комментариями (коли в оных будет нужда).
поехали...
советы французского товарища Эрика на все случаи жизни
узнать все доступные методы DBUS-а:
dbus-send --system --print-reply --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer org.freedesktop.DBus.Introspectable.Introspect
получить список DBUS интерфейсов, с которыми потом можно "пообщаться" при помощи dbus-send --dest=INTERFACE:
dbus-send --system --print-reply --dest=org.freedesktop.DBus /org/freedesktop/Hal/devices/computer org.freedesktop.DBus.ListNames
to be continued...
*/
вторник, 9 декабря 2008 г.
я родился в таможне, когда выпал на пол...
/*
сегодня очнулся от коматоза, анабиоза и якоря на шее. шаманил с OBS - OpenSUSE Build Service - глобально убирая форсированный strip с бинарей и добавляя debuginfo пакеты (то есть теперь можно будет при желании и дебажить от души если я в спеках не напутал). тут как охуел от вот этой картинки:
здесь показан неполный список архитектур/платформ, под которые я могу собирать свои пакетики. неполный, потому, что armv5el не хватает. о-да... они таки сделали это! реальный и конкретный PPC + PPC64 + ARM + SH4 ! если учесть, что в OBS можно (и нужно) собирать пакеты практически для всех мейнстрим/основных дистрибутивов - то со спокойной улыбкой можно кивая и поддакивая соглашаться, что вот именно <ВСТАВЬТЕ СЮДА НАЗВАНИЕ ЛЮБОГО ДИСТРИБУТИВА> - самый-самый, а Суська, да что там Суська по сравнению с <СМ. ВЫШЕ>... что вообще сравнивать-то... ежу понятно, что ONLY SUSE IS GOOD ENOUGH :).
резюме: ... хм... а надо ли?
сегодня очнулся от коматоза, анабиоза и якоря на шее. шаманил с OBS - OpenSUSE Build Service - глобально убирая форсированный strip с бинарей и добавляя debuginfo пакеты (то есть теперь можно будет при желании и дебажить от души если я в спеках не напутал). тут как охуел от вот этой картинки:
здесь показан неполный список архитектур/платформ, под которые я могу собирать свои пакетики. неполный, потому, что armv5el не хватает. о-да... они таки сделали это! реальный и конкретный PPC + PPC64 + ARM + SH4 ! если учесть, что в OBS можно (и нужно) собирать пакеты практически для всех мейнстрим/основных дистрибутивов - то со спокойной улыбкой можно кивая и поддакивая соглашаться, что вот именно <ВСТАВЬТЕ СЮДА НАЗВАНИЕ ЛЮБОГО ДИСТРИБУТИВА> - самый-самый, а Суська, да что там Суська по сравнению с <СМ. ВЫШЕ>... что вообще сравнивать-то... ежу понятно, что ONLY SUSE IS GOOD ENOUGH :).
резюме: ... хм... а надо ли?
новые плюшки и старые радости...
/*
Ешкин кот...
что ни день - то новые "плюшки" достаем с полочки. модуль Enlightenment-а "Places" практически сразу после доработки улетел из google code в E-trunk (обновил репо для openSUSE). также в E-trunk заметил два новых модуля: 'diskio' (на картинке ниже)
и 'drawer' (на данный момент не блещущий функционалом, но задумка там очень интересная). 'diskio' мониторит активность выбранного диска. на картинке зелёный - чтение данных, красный - запись, но это конечно же легко меняется при желании и умении редактировать edj файл. да и шрифты/(подпись диска) по умолчанию - не радуют.
Vim
хоть это и боян боянистый, но таки пришло время чуток помахать напильником в потрохах vim-а. по ссылке ниже можно прочитать о прикрутке проверки орфографии:
vim: Настройка проверки орфографии (opennet.ru)
кроме того достал писк бипером при ошибках и чуток подрихтовал ~/.vimrc (ничего особенного, конфиг обычного лузера):
> cat ~/.vimrc
pastebin
но это всё - цветочки. для редактирования edc файлов не лишне иметь под рукой подсветку синтаксиса в стиле C. включается и выключается это чудо командами ":sy on/off". наш vim-чик позволяет разбирать тип рабочего файла и осталось лишь его пнуть на загрузку сишного синтаксиса на edc файл. поехали...
mkdir -p ~/.vim/syntax
cd ~/.vim/syntax
ln -s /usr/share/vim/vim71/syntax/c.vim ./edc.vim
эт мы создали типа правила подсветки синтаксиса для edc файлов. этот шаг опционален и без него можно прекрасно обойтись. ниже покажу как. чешем дальше...
mkdir -p ~/.vim/ftdetect
cat ~/.vim/ftdetect/edc.vim
au BufRead,BufNewFile *.edc setfiletype edc
эт мы заколбасили правило, что если edc файлы не определены глобально ранее, то принимать их за самих себя. можно было бы просто нарисовать "setfiletype c" и не париться с "созданием" специального файла для edc. поэтому первые три строки - для самообразования. осталось понять как вырубить пищалку на заставке grub-а без отсоединения проводков на матплате или вырезания спикера в бивисе (ибо не интересно).
суета сует и прочая суета...
забубенил для openSUSE экспериментальную версию linuxdcpp-0707core:
брать тута...
тама же и обычный релиз. из новшеств - долгожданная мультипотоковая закачка. работает, проверил.
тема hal+dbus+udev оказалась неожиданно популярной. вот тут:
да-да-да, прям тут, на ЛОР-е
мну разорялсо об особенностях настройки этой махинушки, если скомпилено оно без PolicyKit и без ConsoleKit (рыть надо /etc/dbus-1/system.d/hal.conf при таком раскладе). ничего сложного. после общения с Mac OS X все эти xml-конфиги как-то воспринимаются без истерики. да, xml, не приятно. с другой стороны эт лишний повод соорудить какой-нить гуй (+плюс быстрый парсер) на подобие тех, что в Mac OS X разбираются с этим форматом (в Маке все практически конфиги с его использованием нарисованы, даже конфиг бутлоадера). думаю, что скоро всё будет.
жду выхода openSUSE-11.1 для подготовки очередного релиза SOAD Linux. есть пара замечательных идей, над которыми и работаю (хотя, может они только мне кажутся замечательными, хз).
что делать, чтобы как-то организовать массовое тестирование пакета 'wicd' в openSUSE для настройки беcпроводных интерфейсов - не знаю. все попытки натыкаются на непробиваемую тупую стену молчания. сделал тему на линупсфоруме-точка-ру - тема утонула без единого отклика (что впрочем характерно, учитывая "интеллектуальный уровень" сего "ресурса"). остаётся просить о помощи на ЛОР-е. посоветуйте пожалуйста, как наиболее грамотно организовать это мероприятие.
запросил официального разрешения при сохранении копирайтов пользовать вот такие иконки:
ждём-с, нет ответа, нет ответа, нет ответа... грустно... а иконки-то пиздатые, Господа... эх...
*/
Ешкин кот...
что ни день - то новые "плюшки" достаем с полочки. модуль Enlightenment-а "Places" практически сразу после доработки улетел из google code в E-trunk (обновил репо для openSUSE). также в E-trunk заметил два новых модуля: 'diskio' (на картинке ниже)
и 'drawer' (на данный момент не блещущий функционалом, но задумка там очень интересная). 'diskio' мониторит активность выбранного диска. на картинке зелёный - чтение данных, красный - запись, но это конечно же легко меняется при желании и умении редактировать edj файл. да и шрифты/(подпись диска) по умолчанию - не радуют.
Vim
хоть это и боян боянистый, но таки пришло время чуток помахать напильником в потрохах vim-а. по ссылке ниже можно прочитать о прикрутке проверки орфографии:
vim: Настройка проверки орфографии (opennet.ru)
кроме того достал писк бипером при ошибках и чуток подрихтовал ~/.vimrc (ничего особенного, конфиг обычного лузера):
> cat ~/.vimrc
pastebin
но это всё - цветочки. для редактирования edc файлов не лишне иметь под рукой подсветку синтаксиса в стиле C. включается и выключается это чудо командами ":sy on/off". наш vim-чик позволяет разбирать тип рабочего файла и осталось лишь его пнуть на загрузку сишного синтаксиса на edc файл. поехали...
mkdir -p ~/.vim/syntax
cd ~/.vim/syntax
ln -s /usr/share/vim/vim71/syntax/c.vim ./edc.vim
эт мы создали типа правила подсветки синтаксиса для edc файлов. этот шаг опционален и без него можно прекрасно обойтись. ниже покажу как. чешем дальше...
mkdir -p ~/.vim/ftdetect
cat ~/.vim/ftdetect/edc.vim
au BufRead,BufNewFile *.edc setfiletype edc
эт мы заколбасили правило, что если edc файлы не определены глобально ранее, то принимать их за самих себя. можно было бы просто нарисовать "setfiletype c" и не париться с "созданием" специального файла для edc. поэтому первые три строки - для самообразования. осталось понять как вырубить пищалку на заставке grub-а без отсоединения проводков на матплате или вырезания спикера в бивисе (ибо не интересно).
суета сует и прочая суета...
забубенил для openSUSE экспериментальную версию linuxdcpp-0707core:
брать тута...
тама же и обычный релиз. из новшеств - долгожданная мультипотоковая закачка. работает, проверил.
тема hal+dbus+udev оказалась неожиданно популярной. вот тут:
да-да-да, прям тут, на ЛОР-е
мну разорялсо об особенностях настройки этой махинушки, если скомпилено оно без PolicyKit и без ConsoleKit (рыть надо /etc/dbus-1/system.d/hal.conf при таком раскладе). ничего сложного. после общения с Mac OS X все эти xml-конфиги как-то воспринимаются без истерики. да, xml, не приятно. с другой стороны эт лишний повод соорудить какой-нить гуй (+плюс быстрый парсер) на подобие тех, что в Mac OS X разбираются с этим форматом (в Маке все практически конфиги с его использованием нарисованы, даже конфиг бутлоадера). думаю, что скоро всё будет.
жду выхода openSUSE-11.1 для подготовки очередного релиза SOAD Linux. есть пара замечательных идей, над которыми и работаю (хотя, может они только мне кажутся замечательными, хз).
что делать, чтобы как-то организовать массовое тестирование пакета 'wicd' в openSUSE для настройки беcпроводных интерфейсов - не знаю. все попытки натыкаются на непробиваемую тупую стену молчания. сделал тему на линупсфоруме-точка-ру - тема утонула без единого отклика (что впрочем характерно, учитывая "интеллектуальный уровень" сего "ресурса"). остаётся просить о помощи на ЛОР-е. посоветуйте пожалуйста, как наиболее грамотно организовать это мероприятие.
запросил официального разрешения при сохранении копирайтов пользовать вот такие иконки:
ждём-с, нет ответа, нет ответа, нет ответа... грустно... а иконки-то пиздатые, Господа... эх...
*/
воскресенье, 7 декабря 2008 г.
сумбурно обо всём
/*
часть 1-я, мелочная
"взмах крыла бабочки может породить бурю", так и в этот раз одна приятная мелочь (sic!) потянула за собой хуеву тучу изменений. имя этой "мелочи" - модуль E17-го "Places":
модуль написан товарищем DaveMDS и сегодня мы его довели в svn до идеального состояния. цель - гуй для мониторинга носителей и операций с ними при помощи связки dbus+udev+hal от лица простого юзера. тыканьё на иконку носителя конфигурируется и может запускать как любимый ФМ (после монтирования), так и любые скрипты на ваш выбор (естественно без эскалации привилегий).
для этого нужно было понять как именно работает махина "dbus+udev+hal" и разобраться в дивных xml настройках сего хозяйства. дальнейшее повествование будет чуток специфично относительно дистрибутива OpenSUSE, но может кому-то и пригодится. началось с попыток взнуздать гугл, но "пейсателей" развелось... посему клич "поможите люди добрые" был брошен на ЛОР-е:
поможите люди добрые
и уважаемый товарищ "анонимус" привёл абсолютно фантастические ссылки на статьи, помогающие понять именно основы этого безобразия. резюме:
1) основные правила определяются .fdi файлами. искать тут:
/usr/share/hal/fdi
/etc/hal/fdi
2) информацию о девайсах, которыми можно управлять (это в принципе инструмент очень тонкой настройки) вам выдаст команда (пакет 'hal'):
/usr/bin/hal-device
"рулить" можно как составляя свои правила, так и при помощи команд:
/usr/bin/hal-get-property (получение сведений/свойств)
/usr/bin/hal-set-property (установка новых свойств устройству)
3) man PolicyKit - ОБЯЗАТЕЛЬНО к прочтению и пониманию почему (может блокироваться) блокируется то или иное свойство/действие, заданное/разрешённое в правилах. сам 'polkit' - тема отдельного разговора. зело мощная дубинушка и махать ей направо-налево надобно крайне осторожно (как впрочем и любыми инструментами, непосредственно работающими с железом).
4) (самое болезненное по крайней мере для меня обстоятельство) работа с dbus+udev+hal требует отказа от всех старых проверенных методов обращения с девайсами. если вы (как и я) привыкли к kernel automounter-у и autofs (где всё настраивается двумя линиями внятного текста в конфиге) - пришло время от этого отказаться. также если вы хотите монтировать/демонтировать диски при помощи hal, то /etc/fstab не должен содержать записей о них.
5) внимательно читайте инструкции/маны ибо (например) если сделать 'eject' на partition диска - не удивляйтесь если "отвалится" весь диск :).
итак, начинаем с того, что разрешаем пользователю оперировать с девайсамм от лица юзера через hal при явном указании "полкану" не мешать (это по сути самая важная часть):
> cat /etc/PolicyKit/PolicyKit.conf
pastebin.com
после этого выбираем только те партиции/диски, которые хотим видеть в этом модуле. для этого необходимо присвоить "ключу" 'volume.ignore' параметр 'false' (если желаем мониторить) или параметр 'true' (если хотим скрыть партицию/диск). пример команды (для мониторинга партиции):
sudo hal-set-property --udi '/org/freedesktop/Hal/devices/volume_uuid_80A8_1512' --key volume.ignore --bool false
также подобным макаром можно проставить метку/label на партицию (любой носитель):
sudo hal-set-property --udi '/org/freedesktop/Hal/devices/volume_uuid_80A8_1512' --key volume.label --string AUDIO
выше мы проставили метку 'AUDIO'. на этом собственно всё. модуль сегодня допилили и теперь пользователи Enlightenment-DR17 имеют в своём распоряжении отличный гуй для управления съёмными и фиксированными носителями. адрес проекта:
Dave's blog
адрес Google code
пользователи E в OpenSUSE могут просто пересобрать src.rpm и установить пакет, скомпиленный из current svn (в репо слегка устаревшая версия, что не позволяет отмонтирование пользованием локальных партиций по щелчку на кнопке).
часть 2-я, галопом по европам
починили 'esmart text object' - теперь E/ETK/EWL корректно реагирует на символы при переключении клавиатурной раскладки Xorg-ом. надеюсь, что починят и scim input method (базовый код уже в Ешке присутствует) и пофиксят глупый баг с нерабочим 'language' модулем (гуйня для переключения раскладок клавиатуры на лету). эх, лень моя... самому-бы надо...
активно дорабатывают новую дефолтную тему 17-го "Black&White". панель настроек унифицировали с illume (по крайней мере идёт активный поиск оптимальных диалогов конфигурации).
описать в двух словах все новости проекта Enlightenment не получится. при этом "допиливается" не только 17-ый, но и Enlightenment-DR16, что весьма радует. именно так и надо организовывать поддержку Продуктов. горд и доволен. завтра обещают прикрутить online интерфейс для скачивания тем/обоев не только с get-e.org, но и с E-Exchange. ждём-с.
часть 3-я, око-ёко-OpenMOKO...
выслушал упрёки анонимного пользователя телефона Free Runner о невозможности кастомизации интерфейса и подстойке его "под себя". удивился, заново полез в qemu и хватило ума обновиться без бэкапа (чего даже во хмелю не допускаю). инструкции по поводу запуска openmoko в qemu можете почитать тут:
общая инструкция
с использованием MokoMakefile
если будете этим заниматься прям сейчас - то во-первых нихуя у вас не заработает, а во-вторых последние development версии FR-а всё больше тяготеют к интерфейсу Qt/Qtopia (куда даже терминал засунуть не потрудились, что характерно - нахуя в Qt консоль?). другими словами Вам понадобится энное количество времени, чтобы:
1) найти рабочий билд кернела/лоадера
2) найти rootfs (корневую систему с дистрибутивом/ПО) с E17+illume в качестве GUI
3) прорюхать нужную команду для старта самого qemu (в целом предлагаемые шаблоны задают правильное направление поиска, но ... "есть нюансы", как говаривал Чапай).
скриншоты ниже сделаны "в ленивую", на qemu, слегонца "обточенном" даже без подключённой usb клавиатуры. всё сделано в гуях illume и 17-го:
как видим UI можно отстроить от и до. группировка приложений - в соответствии с xdg freedesktop спеками, темы оформления можно брать из E17-го, кастомизация интерфейса - такая же, как и в 17-ом (другими словами можно отстроить всё и вся. от виртуальных столов и до размера шрифта и типа его рендеринга). если вам интересна эта тема - оставьте здесь свой комментарий/пожелание и будем разбираться вместе.
к слову готовится новая редакция FR-а - gta03. будем надеяться, что аппаратная часть будет получше. в сегодняшних моделях (gta01 и gta02) шина обмена данными не блещет скоростью, из-за чего слышим справедливые упрёки о "тормозах". также дистрибутивы/сборки оптимальными как-то пока назвать не готов (есть вещи, которые не нравятся, но нет понимания пока насколько они критичны).
в целом это очень интересный и достойный продукт для энтузиастов Linux. сегодня там вроде как пофиксили GPS и пресловутые SMS-ки (в очередной раз? :)). всем же советую начинать именно с qemu. заодно некоторые могут узнать много нового о кросс/нативной-компиляции для ARM и специфике ARM-а как такового. в общем есть в этом мире, друг Горацио, множество забавных штукенций...
*/
часть 1-я, мелочная
"взмах крыла бабочки может породить бурю", так и в этот раз одна приятная мелочь (sic!) потянула за собой хуеву тучу изменений. имя этой "мелочи" - модуль E17-го "Places":
модуль написан товарищем DaveMDS и сегодня мы его довели в svn до идеального состояния. цель - гуй для мониторинга носителей и операций с ними при помощи связки dbus+udev+hal от лица простого юзера. тыканьё на иконку носителя конфигурируется и может запускать как любимый ФМ (после монтирования), так и любые скрипты на ваш выбор (естественно без эскалации привилегий).
для этого нужно было понять как именно работает махина "dbus+udev+hal" и разобраться в дивных xml настройках сего хозяйства. дальнейшее повествование будет чуток специфично относительно дистрибутива OpenSUSE, но может кому-то и пригодится. началось с попыток взнуздать гугл, но "пейсателей" развелось... посему клич "поможите люди добрые" был брошен на ЛОР-е:
поможите люди добрые
и уважаемый товарищ "анонимус" привёл абсолютно фантастические ссылки на статьи, помогающие понять именно основы этого безобразия. резюме:
1) основные правила определяются .fdi файлами. искать тут:
/usr/share/hal/fdi
/etc/hal/fdi
2) информацию о девайсах, которыми можно управлять (это в принципе инструмент очень тонкой настройки) вам выдаст команда (пакет 'hal'):
/usr/bin/hal-device
"рулить" можно как составляя свои правила, так и при помощи команд:
/usr/bin/hal-get-property (получение сведений/свойств)
/usr/bin/hal-set-property (установка новых свойств устройству)
3) man PolicyKit - ОБЯЗАТЕЛЬНО к прочтению и пониманию почему (может блокироваться) блокируется то или иное свойство/действие, заданное/разрешённое в правилах. сам 'polkit' - тема отдельного разговора. зело мощная дубинушка и махать ей направо-налево надобно крайне осторожно (как впрочем и любыми инструментами, непосредственно работающими с железом).
4) (самое болезненное по крайней мере для меня обстоятельство) работа с dbus+udev+hal требует отказа от всех старых проверенных методов обращения с девайсами. если вы (как и я) привыкли к kernel automounter-у и autofs (где всё настраивается двумя линиями внятного текста в конфиге) - пришло время от этого отказаться. также если вы хотите монтировать/демонтировать диски при помощи hal, то /etc/fstab не должен содержать записей о них.
5) внимательно читайте инструкции/маны ибо (например) если сделать 'eject' на partition диска - не удивляйтесь если "отвалится" весь диск :).
итак, начинаем с того, что разрешаем пользователю оперировать с девайсамм от лица юзера через hal при явном указании "полкану" не мешать (это по сути самая важная часть):
> cat /etc/PolicyKit/PolicyKit.conf
pastebin.com
после этого выбираем только те партиции/диски, которые хотим видеть в этом модуле. для этого необходимо присвоить "ключу" 'volume.ignore' параметр 'false' (если желаем мониторить) или параметр 'true' (если хотим скрыть партицию/диск). пример команды (для мониторинга партиции):
sudo hal-set-property --udi '/org/freedesktop/Hal/devices/volume_uuid_80A8_1512' --key volume.ignore --bool false
также подобным макаром можно проставить метку/label на партицию (любой носитель):
sudo hal-set-property --udi '/org/freedesktop/Hal/devices/volume_uuid_80A8_1512' --key volume.label --string AUDIO
выше мы проставили метку 'AUDIO'. на этом собственно всё. модуль сегодня допилили и теперь пользователи Enlightenment-DR17 имеют в своём распоряжении отличный гуй для управления съёмными и фиксированными носителями. адрес проекта:
Dave's blog
адрес Google code
пользователи E в OpenSUSE могут просто пересобрать src.rpm и установить пакет, скомпиленный из current svn (в репо слегка устаревшая версия, что не позволяет отмонтирование пользованием локальных партиций по щелчку на кнопке).
часть 2-я, галопом по европам
починили 'esmart text object' - теперь E/ETK/EWL корректно реагирует на символы при переключении клавиатурной раскладки Xorg-ом. надеюсь, что починят и scim input method (базовый код уже в Ешке присутствует) и пофиксят глупый баг с нерабочим 'language' модулем (гуйня для переключения раскладок клавиатуры на лету). эх, лень моя... самому-бы надо...
активно дорабатывают новую дефолтную тему 17-го "Black&White". панель настроек унифицировали с illume (по крайней мере идёт активный поиск оптимальных диалогов конфигурации).
описать в двух словах все новости проекта Enlightenment не получится. при этом "допиливается" не только 17-ый, но и Enlightenment-DR16, что весьма радует. именно так и надо организовывать поддержку Продуктов. горд и доволен. завтра обещают прикрутить online интерфейс для скачивания тем/обоев не только с get-e.org, но и с E-Exchange. ждём-с.
часть 3-я, око-ёко-OpenMOKO...
выслушал упрёки анонимного пользователя телефона Free Runner о невозможности кастомизации интерфейса и подстойке его "под себя". удивился, заново полез в qemu и хватило ума обновиться без бэкапа (чего даже во хмелю не допускаю). инструкции по поводу запуска openmoko в qemu можете почитать тут:
общая инструкция
с использованием MokoMakefile
если будете этим заниматься прям сейчас - то во-первых нихуя у вас не заработает, а во-вторых последние development версии FR-а всё больше тяготеют к интерфейсу Qt/Qtopia (куда даже терминал засунуть не потрудились, что характерно - нахуя в Qt консоль?). другими словами Вам понадобится энное количество времени, чтобы:
1) найти рабочий билд кернела/лоадера
2) найти rootfs (корневую систему с дистрибутивом/ПО) с E17+illume в качестве GUI
3) прорюхать нужную команду для старта самого qemu (в целом предлагаемые шаблоны задают правильное направление поиска, но ... "есть нюансы", как говаривал Чапай).
скриншоты ниже сделаны "в ленивую", на qemu, слегонца "обточенном" даже без подключённой usb клавиатуры. всё сделано в гуях illume и 17-го:
как видим UI можно отстроить от и до. группировка приложений - в соответствии с xdg freedesktop спеками, темы оформления можно брать из E17-го, кастомизация интерфейса - такая же, как и в 17-ом (другими словами можно отстроить всё и вся. от виртуальных столов и до размера шрифта и типа его рендеринга). если вам интересна эта тема - оставьте здесь свой комментарий/пожелание и будем разбираться вместе.
к слову готовится новая редакция FR-а - gta03. будем надеяться, что аппаратная часть будет получше. в сегодняшних моделях (gta01 и gta02) шина обмена данными не блещет скоростью, из-за чего слышим справедливые упрёки о "тормозах". также дистрибутивы/сборки оптимальными как-то пока назвать не готов (есть вещи, которые не нравятся, но нет понимания пока насколько они критичны).
в целом это очень интересный и достойный продукт для энтузиастов Linux. сегодня там вроде как пофиксили GPS и пресловутые SMS-ки (в очередной раз? :)). всем же советую начинать именно с qemu. заодно некоторые могут узнать много нового о кросс/нативной-компиляции для ARM и специфике ARM-а как такового. в общем есть в этом мире, друг Горацио, множество забавных штукенций...
*/
Подписаться на:
Сообщения (Atom)
