Инструменты пользователя

Инструменты сайта



// Pacman: информация по пакетам, установленным как зависимости...

…и не нужные никакому пакету.

На случай, если что-то удалялось как pacman -R пакет вместо pacman -Rs пакет:
<ДЕЛ>

pacman -Qd | awk '{print $1}' | xargs -I{} bash -c 'cnt=$(LANG=C pacman -Qi {} | grep "Required By\|Optional For" | grep None | wc -l); (test $cnt -eq 2 && echo "{}")' | xargs -I{} bash -c '(pacman -Qi {};pacaur -Sii {};echo =================)' 2>&1 | less -R

</ДЕЛ>

Спасибо Романычу, просто список пакетов:

pacman -Qtdq

и с описанием, как в уродстве выше (без запроса к Sync базе или AUR можно просто: pacman -Qtdqi):

pacman -Qtdq | xargs -I{} bash -c '(pacman -Qi {};pacaur -Sii {};echo =================)' 2>&1 | less -R

pacaur используется, что бы запросить информацию для AUR пакетов.

Если какой-то пакет в этом списке уже нужен как самостоятельная единица, то можно снять пометку:

  pacman -S --asexplicit пакет

Теперь вопрос: а как проще?

ЗЫ пакеты, которые не требуются никаким другим пакетом можно получить просто выполнив pacman -Qt

// ArchLinux, systemd, run-level 3, startx, udisks и монтирование

Столкнулся с ситуацией: после перехода к systemd и его logind внезапно отказались монтироваться флешки средствами udisks и udisks2. При этом на соседнем компьютере всё нормально. Разница при этом между ними только одна: на одном иксы запускаются через kdm, на другом - startx. Вот там, где используется startx монтирование и не работает.

В ходе разбора наткнулся на эпичный тред, где поттеринг пытается убедить, что нужно апдейтить startx: https://bugzilla.redhat.com/show_bug.cgi?id=820675

Но оставим этого человека альтернативной ориентации и вернёмся к нашим баранам. А бараны такие: заставить без костылей или минимум оных монтировать накопители средствами udisks/udisks2 на машине, где используется startx.

Для начала выясняем, а в чём собственно соль проблемы. Выясняется, что когда мы запускаем иксы, они захватывают отдельный терминал и переключают пользователя на него, тем самым мы как бы переключаемся из сессии, созданной при логине в консоли, и она становится неактивной. Новой сессии для иксов при этом не создаётся. В результате этого в выводе команды

loginctl show-session $XDG_SESSION_ID

видим такие строчки:

Active=no

При этом, изучая конфиги polkit, мы можем увидеть, что мы можем регулировать права доступа для монтирования для активной сессии, неактивной и для остальных. Отсюда вытекает первый вариант исправления ошибки (и первый костыльный): править конфиги polkit и разрешать доступы с неактивных сессий для операций монтирования.

Проблема метода очевидна: ближайшее обновление и нам нужно мержить, или менять снова. Не гут.

Второй метод, запустить иксы на том же терминале, на котором мы залогинились. К примеру, мы зашли с первой консоли, команда tty выдаёт следующее:

/dev/tty1

тогда, что бы запустить иксы на этой консоли нам нужно выполнить следующую команду:

startx -- vt1

И видим, что в выводе loginctl Active стал yes. Viva!

В таком варианте есть свой плюс: если заблокировать экран, допустим, с помощью xscreensaver, то мы не сможем переключиться на первую текстовую консоль и, нажав Ctrl-C, убить иксы и получить доступ к залогиненому аккаунту. Здесь же кроется и минус: подвисшую сессию оперативно не убьёшь, особенно, если она отказывается реагировать на Ctrl-Alt-BS. Плюс как-то не классически.

Как последний штрих, добавляем в ~/.bashrc следующее:

stx()
{
	local vt=$(fgconsole)
	startx -- vt$vt
}
alias startx='stx'

и продолжать пользоваться просто командой startx.

Здесь же кроется забавный баг: теперь, если случайно нажать startx в окне терминала в запущенных иксах, поверх них запустится их вторая копия и переключиться между ними не получится ни при каких обстоятельствах. Так что будьте осторожны и бдительны.

Как заключение: подобные изменения лишний раз подтверждают правило: работает - не трожь! Особенно если это касается системообразующих функций, систем загрузки и пр.

Материалы которые помогли мне разобраться:

// Mime тип для GPX

Столкнулся с тем, что в файловых менеджерах в уютненьком Арчике GPX файлы отображаются просто как «Документ XML», соответственно если назначишь для открытия какую программу, это распространяется на все XML файлы.

Выход: сделать описание Mime типа

Рассмотрю вариант индивидуальный для пользователя, общесистемно - домашнее задание.

Шаг первый, создаём файл $HOME/.local/share/mime/packages/application-gpx+xml.xml:

application-gpx+xml.xml
<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
    <mime-type type="application/gpx+xml">
        <comment>Geoinformation data (waypoints, tracks and so on) in GPX format</comment>
        <glob-deleteall/>
        <glob pattern="*.gpx"/>
    </mime-type>
</mime-info>

Для ленивых, качаем в одну команду:

wget -O $HOME/.local/share/mime/packages/application-gpx+xml.xml http://htrd.su/wiki/_export/code/zhurnal/2012/07/07/mime_tip_dlja_gpx?codeblock=0

После чего выполняем команду:

update-mime-database $HOME/.local/share/mime

Усё.

Для быстрого просмотра удобна программа Viking, в Арчике есть в стандартных репозиториях.

// Набор для кросс-компиляции для Linux на ARM

Потребовалось сделать окружение для отстройки приложений для системы Linux, запущенной на платформе с процессором ARM.

Внутри есть eglibc, поэтому решено было попробовать сделать окружение с этой библиотекой Си, а не повсеместно используемой newlib.

Процесс чтения манов, проб, нервов занял около двух дней. Помогли разобраться следующие документы:

Особо поразило мозг решение проблемы «кто первый: курица или яйцо?»

В результате получился набор правил для сборки окружение под ArchLinux (пакеты идут в порядке сборки):

Ну и несколько библиотек сразу в придачу:

// Новый GTK+ и падение Opera

После очередного обновления, заметил, что Опера перестала стартовать. При запуске из терминала, вываливает следующее:

$ opera

(opera:13093): Gtk-CRITICAL **: IA__gtk_widget_unrealize: assertion `GTK_IS_WIDGET (widget)' failed

(opera:13093): Gtk-CRITICAL **: IA__gtk_widget_is_toplevel: assertion `GTK_IS_WIDGET (widget)' failed
opera [crash logging]: CRASH!!
/usr/lib/opera/opera got signal SIGSEGV at address B6B26E77

Log was created here:
/var/tmp/crash20111110210615.txt
Убито

Для столкнувшихся с этой же проблемой в ArchLinux:

// ArchLinux: geda-gaf в community

Собственно - радость! :)

Там же теперь и разводчик pcb. Двойная радость!

К сожалению, утилита xgsch2pcb (менеджер проектов-интегратор gschem и pcb) до community ещё не добралась, но уже не плохо.

// Автомонтирование udev+udisks

Повторять весь текст не буду, авторство и так моё: http://groups.google.com/group/archlinux-ru/browse_thread/thread/33c0d288bd05823d

Тут как реминдер

// OpenSource #066

Вышел 66 выпуск электронного приложения к журналу «Системный администратор», а в нем и моя третья статья из цикла «Схемотехника в Linux с помощью gEDA», в которой рассмотрено создание условного обозначения компонент для gschem. Так же сделано небольшое отступление и рассказано о интеграции gschem и pcb при помощи менеджера проектов xgschm2pcb. В общем качаем и читаем: http://osa.samag.ru/get/OpenSource066.zip

// Arduino как программатор для контроллеров Atmel и сопутствующий софт

За последние дни окончательно убедился, что Arduino не просто игрушка, а настроящие ворота для начинающих постигать мир программирования микроконтроллеров Atmel.

К чему это я, а к тому, что плата Arduino может выступить в роли программатора для самостоятельных конструкций на контроллерах. Как минимум существует два варианта, про которые можно прочитать на сайте http://freeduino.ru: http://freeduino.ru/arduino/isp.html.

Меня больше заинтересовал вариант BitBang программатора, т.к. не нужно каждый раз заливать прошивку в Arduino, когда нужно прошить внешний контроллер. Кроме того, можно прошить сам контроллер в кроватке (допустим если вышел из строя, количество же циклов перезаписи ограничено или залить обновленный boot loader).

В статье выше сказано, что подходят не все платы, это верно, но главное, что бы это была USB плата и на ней был чип FT232R/FT232RL, а вот разьём X3 можно распаять и самому (как это сделал Я - при помощи олово-отсоса очистил отверстия, поставил планочку и пропаял).

Но на этом наши приключения не заканчиваются. Возникает вопрос - чем шить? Ведь BitBang («ножкодрыгание») это достаточно не стандартная для общепринятых API процедура. Соответственно этим нужно заниматься через специализированные библиотеки, коих под Linux я раскопал две для чипов от FTDI:

  • libftd2xx - закрытая (проприетарная) библиотека от производителя, есть в вариантах для i686 и x86_64 (и естественно для Windows), скачать можно тут: http://www.ftdichip.com/Drivers/D2XX.htm, там в же в архиве есть заголовочные файлы, а на сайте можно скачать PDF с руководтством программиста. Вообще, там же рекомендую скачать и документацию на саму микросхему FT232R/FT232RL и информацию про работу в BitBang режиме (дальше потребуется). Библиотека доступна в ArchLinux через AUR.
  • libftdi - библиотека с открытыми исходными кодами, из зависимостей только libusb, а так как последняя может быть собрана и для Windows, теоретически и данная библиотека тоже. Домашняя страница: http://www.intra2net.com/en/developer/libftdi/download.php, имеется так же в репозитории extra в ArchLinux.

Для первой библиотеки (libftd2xx), есть набор патчей для avrdude. На сайте FreeDuino есть ссылка на сборку для Windows. Я выложил в AUR правила для сборки последней версии avrdude с этими патчами: avrdude-serjtag (потому как патчи изначально родились в недрах проекта serjtag).

На сайте libftdi лежит патч для древней версии uisp, поэтому подумав, и потратив 1.5 дня сделал на основе патчей serjtag свой патч ftdi-bitbang-5.10-1.patch, который использует эту библиотеку. Проверил прошивая и устанавливая fuse-биты на ATTiny2313. Естественно сделал правила для сборки и поместил в AUR: avrdude-ftdi. Вариант, если нужно отстроить на архитектуру отличную от x86/x86_64 или если бинарная версия проприетарной библиотеки рушится на вашей системе (тем более, что обновлялась она с 2008 года).

Вот тут товарищ Di Halt более подробно рассказывает про программатор на такой же микросхеме, которая стоит на Arduino. Там он говорит об одной неприятной особенности: после прошивки не отпускается линия RESET и решает проблему аппаратно. Можете поступить так же, но оказалось что, что в исходных кодах avrdude достаточно добавить одну строчку - выставление высокого уровня на линии RESET перед закрытием порта и выходом. Патч делающий это для использования с libftd2xx и набором патчей serjtag можно поглядеть тут: http://aur.archlinux.org/packages/avrdude-serjtag/avrdude-serjtag/clean-reset-pin.diff. При сборке пакетов avrdude-serjtag и avrdude-ftdi изменения отраженные в этом патче уже применены, так что, счастливым обладателям ArchLinux достаточно просто собрать и поставить пакет :)

Немножно хотел бы остановиться на описании программатора в конфигурационном файле avrdude.conf, особенно назначение цифр для задания линий. Выглядит это примерно так:

#arduino duemilanove
programmer
  id    = "duemilanove";
  desc  = "FT232R Synchronous BitBang";
  type  = ft245r;
  miso  = 3;  # CTS X3(1)
  sck   = 5;  # DSR X3(2)
  mosi  = 6;  # DCD X3(3)
  reset = 7;  # RI X3(4)
;

programmer
  id    = "ft245r";
  desc  = "FT245R Synchronous BitBang";
  type  = ft245r;
  miso  = 1; # D1
  sck   = 0; # D0
  mosi  = 2; # D2
  reset = 4; # D4
;

Не мог понять, пока не почитал внимательно приложение к даташиту FT232R подробно рассказывающее про Bit Bang режимы этой микросхемы. Если коротко: для программатора нужно 4 линии, микросхема предоставляет 8 линий, на которых можно играться уровнями. Естественно в каждом конкретном программаторе могут использоваться любые 4 из этих 8ми линий.

Каждая линия отражает бит с номером от 0 до 7. На Arduino на разъем X3 выведены контакты микросхемы с номерами 11, 9, 10, 6, подключаемых по следущей схеме:

11 - MISO
 9 - SCK
10 - MOSI
 6 - RESET

В документации находим табличку, в которой представлены номера выводов и какой бит они предоставляют, и получаем такую таблицу соответствий:

Имя линии Номер вывода микросхемы Имя вывода Номер вывода разъема X3 Номер/Имя бита (согласно таблицы)
MISO 11 CTS 1 D3
SCK 9 DSR 2 D5
MOSI 10 DCD 3 D6
RESET 6 RI 4 D7

Смотрим на последнюю колонку: вот они откуда и берутся эти самые 3, 5, 6, 7 в описании программатора в avrdude.conf. Т.е. эти номера - это номера битов. С остальными программаторами дело обстоит схожим образом. Одного я не понял, почему этого нет в документации? Или плохо искал?

На этом пока все, сейчас обощаю идеи о среде разработки (на данный момент на базе Makefile) и опубликую заметку.

// pacman 3.4.0

Все подробности тут: http://www.archlinux.org/news/503/

От себя, на что стоит обратить внимание:

  1. -U теперь в большинстве случаев работает как -S, а точнее:
    • обработка зависимостей
    • обработка конфликтов (если пакет заменяет какой-то пакет, раньше нужно было сначала удалить установленный, потом ставить локальный новый)
  2. makepkg теперь завершает свою работу с ошибкой, если какая-то вызываемая программа завершается не с нулевым кодом возврата. Таким образом не нужно больше писать «|| return 1» после команды, если дальнейшая сборка при ошибке не имеет смысла. С другой стороны, когда завершение программы с не нулевым кодом возврата это нормальное поведение (предположим наложение патчей с опцией -N, когда патч был уже наложен), нужно будет после команды поставить «|| true» что бы сборка не завершилась с ошибкой.

// Долго запускаются Xlib/Xt приложения

Столкнулся давно с проблемой: приложения написанные с использованием только Xlib и Xt, например,xclock, xfontsel, или удобная тюнинговалка xvidtune, или мелкая оповещалка xmessage, очень долго запускаются, до 15-20 секунд, при этом давая значительную нагрузку на процессор. Если запускать в терминале, то обычно получаем, среди прочего, такую строку:

Warning: Missing charsets in String to FontSet conversion

Так как эти приложения использовал достаточно редко, то не обращал внимание, но сегодня что-то достало, решил разобраться. Беглый поиск привел на эту страницу: http://www.holoweb.net/~liam/fonts/common-linux-font-problems.html (искать по фразе «Everything starts up really slowly»). Информация старая, ещё для XFree86, ориентировочно 2002 года, но, с небольшими поправками, не потерявшая актуальность и сегодня.

В общих чертах: проблема в fontconfig и локалях Xorg, где указаны кодировки для шрифтов, которых нет в системе. Путей решения получается три:

  1. Запускать через приведенный там скрипт nolocale, добавив туда ещё сточку:
    export LANG=
  2. Поставить шрифты со всеми нужными кодировками
  3. Отредактировать файл локали, убрав (закоментировав) использование несуществующих кодировок

Так как первый способ неудобен, а второй накладен, решил сделать по последнему варианту. Итак, рецепт для ArchLinux (с небольшой адаптацией последнего пункта подходит и для любого другого дистрибутива)

Для начала нужно понять шрифтов в каких кодировках у нас нет.

Для этого бредём в директорию /usr/share/X11/locale/<ВАША_ЛОКАЛЬ>. У меня локаль ru_RU.UTF-8, поэтому директория: /usr/share/X11/locale/ru_RU.UTF-8 и выполним там команду:

cat XLC_LOCALE | grep name | grep -v 'object_name\|encoding_name'

В результате получим примерно такой вывод:

		name	ISO8859-1:GL
		name	ISO8859-1:GR
		name	KOI8-R:GR
		name	MICROSOFT-CP1251:GR
		name	ISO8859-5:GR
		name	JISX0208.1983-0:GL
		name	KSC5601.1987-0:GL
		name	GB2312.1980-0:GL
		name	JISX0201.1976-0:GR
		name	ISO10646-1

На то, что после двоеточия не обращаем внимания, итого, кодировка состоит из двух частей, разделенных «-»: CHARSET_REGISTRY и CHARSET_ENCODING (за подробностями сюда: http://lesstif.sourceforge.net/doc/super-ux/g1ae04e/chap5.html)

Теперь запускаем программку xfontsel, придется подождать малость (с чем собственно мы сейчас и боремся).

Итак, шрифты в X11 издревле задавались хитрой строчкой, поля в которой были разделены знаком «-», последние два элемента как раз и есть CHARSET_REGISTRY и CHARSET_ENCODING (в терминах xfontsel: rgstry и encdng соответственно). Теперь просто проверяем по последним двум полям, что есть все комбинации из вышеполученных rgstry-encdng (на регистр внимания не обращаем), те, которые не находим помечаем.

Теперь возвращаемся в каталог с локалью, открываем файл XLC_LOCALE на редактирование находим секцию с несуществующей кодировкой и комментируем её.

У себя я не нашел шрифтов в кодировке microsoft-cp1251 (есть только cp1252), поэтому полностью закомментированная секция выглядит теперь так:

#	fs3 class (MICROSOFT-CP1251)
#fs3	{
#	charset	{
#		name	MICROSOFT-CP1251:GR
#	}
#	font	{
#		primary	MICROSOFT-CP1251:GR
#	}
#}

Все, сохраняемся и выходим. Проверяем, приложения должны стартовать практически мгновенно.

Ну и последний штрих для ArhLinux. Дабы уберечь от перезаписывания этого файла при обновлениях пакета libx11 (а именно ему принадлежат эти файлы локали), его нужно «замаскировать». Для чего открываем на редактирование файл /etc/pacman.conf, находим параметр NoUpgrade и приводим его примерно к такому виду:

NoUpgrade    =  usr/share/X11/locale/ru_RU.UTF-8/XLC_LOCALE

Теперь при обновлениях, если файл в пакете изменился, он будет ставиться под именем XLC_LOCALE.pacnew и соответствующим предупреждением на экране и в логе. Дальнейшие шаги по поддержанию в актуальном состоянии зависят от вас.

Ну и последнее замечание, описанной процедурой можно и просто найти шрифтов в каких кодировках нет в системе и просто поставить их, если они у вас имеются :)

// Xorg 1.8 в extra

Собственно сабж, подробности: http://www.archlinux.org/news/502/

Для пользователей старых карт nVidia небольшая засада.

// epssplit & jpeg2ps

Про эти утилиты писал года три назад в статье: Резка большеформатных изображений на листы формата А4 для последующего склеивания

Сейчас дошли руки приготовить пакеты для AUR: epssplit, jpeg2ps, так что, в ArchLinux с установкой стало проще :)

По поводу преобразование растра в PS/EPS можно почитать в статье Евгения Балдина в «Linux Format»: LaTeX. Часть 4: Графика

// Странная проблема с WiFi на EeePC 1000HA

Проблема сводится к тому, что при запуске Xorg связь начинает умирать. Для восстановления достаточно переключиться в консоль. Причины и связи мне не понятны, и вообще фантастически выглядит решение проблемы: перепрошивка точки доступа. Вот где тут связь???

Пока разбирался, научился запускать драйвер ath5k - просто для его включения нужно активизировать 2 rfkill устройсва:

  1. сначала eeepc-wlan (см вывод rfkill list)
  2. после появится ещё одно - phy0, и активировать его
  3. затем, в обязательном порядке - ifconfig wlan0 up

после чего можно начинать работать.

Точка доступа (DWL-G700AP) же, была последним шагом - нет нормальной связи, так хоть поэксперементирую. Прошивку туда залил Wive-ng, она на базе ядра Linux 2.4, и очень значительно расширяет возможности точки, превращая её в полноценный маленький сервер с управлением по ssh/telnet:

  • pppoe-client
  • pptp-client
  • dhcp
  • iptables/nat
  • балансировка трафика
  • роуминг (прозрачный переход от точки доступа к точке доступа)
  • vlan
  • широкий диапазон регулировки мощности (больше чем в базовой поставке, но для значений больше 20, следует применять принудительное охлаждение)
  • smbclient (но… не могу представить для чего :) если бы было память побольше, можно было бы туда запихнуть rtorrent с веб-интерфейсом (или даже без оного), а так…)
  • и ещё всего и вся по мелочи

В результате и связь при запущенных Xorg поднялась. Хитрая уличная магия.

По прошивке и вообще точке доступа:

General:

Wive:

Wive-ng:

// Emacs и пустые меню

Столкнулся с проблемой: в некоторых модах, которые добавляют пункты меню в Emacs, эти самые пукнты меню оказываются пустыми, причем, при последующем перезапуске, бывают оказываются и не пустыми.

Собственно вот так это выглядит, открыт C-файл и выбран пункт меню C:

Поиск привел на английски форум ArchLinux: http://bbs.archlinux.org/viewtopic.php?id=83860, собственно от туда варианты решения:

  1. выполнять команду:
    M-x accelerate-menu
  2. установить переменную окружения GDK_NATIVE_WINDOWS перед запуском Emacs:
    export GDK_NATIVE_WINDOWS=1

И сразу на правах рекомендации: Doxymacs

И ещё одна рекомендация, статья Алекса Отта по настройке CEDET: http://alexott.net/ru/writings/emacs-devenv/EmacsCedet.html