Что делать если в KDE не монтируется USВ диск?

Какое-то время назад в KDE 4.12 перестал монтироваться USB диск. Он определялся, но при клике на "Open with File Manager", KDE ругался что "Could not mount device...".

Ясное дело, что под root'ом проблем не было, все монтировалось и работало, но каждый раз вызывать kdesu dolphin при вставки флешки было неудобно и я решил разобраться в чем дело.

Все как всегда оказалось тривиально, KDE был не настроен для автоматического монтирования сменных накопителей. То есть для того, чтобы починить и заставить KDE монтировать USD диски нужно было просто зайти в System Settings -> Removable Devices и выбрать чекбокс Enable automatic mounting of removable media.

После нужно перезапустить сеанс и наслаждаться монтируемыми USB дисками и прочими сменными накопителями информации.

Как открыть новое окно в byobu с текущей директорией вместо домашней?

Я использую byobu с бэкендом tmux для упрощения работы с терминалом. byobu при помощи tmux позволяет делать много всего замечательного, но после того как tmux в openSUSE 13.2 обновился до версии 1.9 новое окно открывается в домашней директории вместо текущей (при нажатии F2) и это сильно замедляло рабочий процесс.

Но после небольшого поиска по интернету, я нашел в чем причина. Оказывается с версии 1.9 tmux открывает новое окно в домашней директории вместо текущей и убирает из списка доступных опций сервера default-path. Т.е. для того, чтоб вернуться к старому поведению tmux, надо будет явно задавать путь для нового окна, открываемого tmux.

Для этого нужно перебиндить нажатие F2-клавиши. И самый простой способ это сделать - это добавить строчку:

bind-key -n F2 new-window -c "#{pane_current_path}" \; rename-window "-"

в ~/.byobu/keybindings.tmux, ну или если byobu пользуется больше одного пользователя в системе то поправить биндинг в /usr/share/byobu/keybindings/f-keys.tmux.

После правки конфига и его сохранения, просто перезагрузите профиль byobu при помощи F5, изменения вступят в силу и новое окно будет опять открываться в текущей директории вместо домашней.

Как обновить openSUSE с 13.1 на 13.2?

Обновление openSUSE - задача довольно тривиальная, но так как она не так проста, как do-release-upgrade в случае Ubuntu, я хотел бы оставить краткий список пунктов, которые нужно сделать для того, чтоб обновить openSUSE на примере перехода с версии 13.1 на недавно вышедшую версию 13.2.

• Во-первых, нужно поменять версию для всех используемых репозиториев в системе, выполнив:

  # for file in /etc/zypp/repos.d/*.repo; do sed -i 's/13\.1/13\.2/g' "$file"; done

• Теперь нужно обновить кеш zypper'а:

  # zypper ref

  и повыключать все репозитории, которые еще не поддерживаются новой версией openSUSE.
• Далее следует обновить сам zypper:

  # zypper up zypper

  Так как при переходе с 13.1 на 13.2 возникают конфликты при обновлении zypper, лучше обновлять его в ручном, а не в автоматическом режиме.
• И наконец система готова к обновлению. Запускайте:

  # zypper dup

  решайте возникшие конфликты, проверяйте список пакетов, которые удалятся/обновлятся в вашей системе и вуаля, через некоторое время ваша система будет обновлена.

Дружим Chromium и Goolge Talk Plugin на openSUSE 13.1

Я давно пользуюсь Chromium, установленным с network:chromium репозитария и до недавнего времени все с ним было отлично. Однако проблемы начались, когда разработчики Chromium решили перейти на новый интерфейс для плагинов, сначала случились проблемы с Adobe Flash Player'ом, сейчас в Chromium перестал обнаруживаться googletalk-plugin, установленный из Google'овского репозитория.

Как оказалось вся радость в том, что пакет chromium, собранный через openSUSE Build Service, устанавливается в /usr/lib64/chromium, тогда как Google ожидает, что он будет установлен в /usr/lib64/chromium-browser и поэтому googletalk-plugin создает неправильные ссылки для такого вроде бы родного браузера.

Правится все просто, созданием правильной ссылки на плагин:

$ sudo ln -s /opt/google/talkplugin/ /usr/lib64/chromium/pepper

и перезапуском Chromium.

ps. Рецепт выше актуален для 64-битной системы, для 32-битной используйте /usr/lib/... вместо /usr/lib64/....

Устанавливаем Adobe Flash Plugin для Chromium 34 и выше

Так как Chromium с версии 34 переходит с использования интерфейса для плагинов NPAPI на интерфейс Aura, вполне возможно что после обновления на YouTube и прочих сайтах, требующих Adobe Flash Plugin, будет показываться сообщение про отсутсвующий Flash плагин, даже при наличии установленного flash-player. В таком случае надо просто установить chromium-pepper-flash с репозитория Packman (для openSUSE 12.3 и выше):

# zypper ar -f http://ftp.fau.de/packman/suse/13.1/ Packman
# zypper ref
# zypper in -y chromium-pepper-flash

И после перезагрузки Chromium опять вернется возможность просматривать видео или играть в игры, требующие Flash.

Внимание: pepper-flash-plugin совместим только с новыми версиями Chromium, так что для работы Flash в Firefox или других браузерах, поддерживающих NPAPI интерфейс вам все так же будет необходим установленный flash-player.

Заставляем bluetooth работать в openSUSE 12.2

С интересной особенностью столкнулся, после перехода на новую версию openSUSE на своем стационарном компьютере - bluetooth-клавиатура отказывалась работать, blueman не запускался, a # service bluetooth start ругался no such service bluetooth. Не порядок подумал я и пошел изучать systemctl, как оказалось все починить было очень просто:

# systemctl enable bluetooth.service
...
# systemctl start bluetooth.service

После этих нехитрых телодвижений синезуб-клавиатура заработала, а blueman-applet начал загружаться автоматически после каждой перезагрузки. Вот такие вот дела.

Добавляем поддержку iconv в rsync на Mac OS X

После приобретения MacBook Air с установленной на нем Mac OS X Lion у меня появилось несколько проблем. И главной была проблема с кодировками. Дело в том, что в макос используется не стандартный UTF-8, а так называемый UTF-8-MAC (подробное описание проблемы на странице rsync) и это порождает сложности в простом использовании sshfs или rsync (а сервер то с openSUSE у меня никуда не делся :)), ведь без iconv их использование будет не полноценным.

Да вот беда, в стандартной версии rsync поставляемой со львом нет поддержки iconv:

rsync: --iconv=UTF-8,UTF-8-MAC: unknown option
rsync error: syntax or usage error (code 1) at /SourceCache/rsync/rsync-42/rsync/main.c(1333) [client=2.6.9]

Так что прийдется варить его :) И хоть оффициальной формулы для rsync не видать, расстраиваться не стоит, потому что на помощь приходит homebrew-alt репозиторий и формула оттуда:

$ brew install https://github.com/adamv/homebrew-alt/raw/master/duplicates/rsync.rb

После установки у нас появится rsync версии 3.0.9 с поддержкой опции iconv и все станет хорошо. Теперь при копировании на макос с линукса я просто добавляю --iconv=UTF-8-MAC,UTF-8 к опциям rsync'a.

зы. И чтоб два раза не вставть, для того чтобы использовать iconv в sshfs убедитесь что он установлен при помощи brew и просто добавьте --omodules=iconv,from_code=UTF-8,to_code=UTF-8-MAC в строку маунта или запуска sshfs.

зыы. Не знаю, что там предлогают MacPorts или Fink, но мой выбор сразу пал на homebrew.

Стартуем PostgreSQL 9.1

Если при старте PostgreSQL 9.1 (или любого другого) вы ловите что-то похожее:

# service postgresql start
Starting PostgreSQL2011-10-11 14:12:19 EEST   LOG:  could not bind IPv6 socket: Cannot assign requested address
2011-10-11 14:12:19 EEST   HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
2011-10-11 14:12:19 EEST   WARNING:  could not create listen socket for "localhost"
2011-10-11 14:12:19 EEST   FATAL:  could not create any TCP/IP sockets
pg_ctl: could not start server
Examine the log output.

то решение проблемы - очень тривиально: просто поправить listen_addresses директиву в конфигурационном файле postgresql.conf (он может распологаться в /var/lib/pgsql/data или /Library/PostgreSQL/9.1/data) c:

# - Connection Settings -

#listen_addresses = 'localhost'  # what IP address(es) to listen on;
     # comma-separated list of addresses;
     # defaults to 'localhost', '*' = all
     # (change requires restart)

на:

# - Connection Settings -

listen_addresses = '*'   # what IP address(es) to listen on;
     # comma-separated list of addresses;
     # defaults to 'localhost', '*' = all
     # (change requires restart)

и перезапустить PostgreSQL.

Заставляем guake работать в openSUSE 11.4

Если после установки guake c Packman'а вы ловите:

playpauseandstop@octave:~> DISPLAY=:0 guake
Traceback (most recent call last):
  File "/usr/lib64/guake/guake.py", line 27, in 
    import vte
ImportError: could not import gobject (could not find _PyGObject_API object)
playpauseandstop@octave:/srv/files/RPMs> DISPLAY=:0 guake
Traceback (most recent call last):
  File "/usr/lib64/guake/guake.py", line 29, in 
    import pynotify
  File "/usr/lib64/python2.7/site-packages/gtk-2.0/pynotify/__init__.py", line 21, in 
    from _pynotify import *
ImportError: could not import gobject (could not find _PyGObject_API object)
playpauseandstop@octave:~> DISPLAY=:0 guake-prefs
Traceback (most recent call last):
  File "/usr/lib64/guake/prefs.py", line 25, in 
    import gconf
ImportError: could not import gobject (could not find _PyGObject_API object)

Не спешите расстраиваться, решение есть, для начала подключаем репозитарий с Python-библиотеками и устанавливаем оттуда python-gobject2:

$ sudo -s
# zypper ar -f http://download.opensuse.org/repositories/devel:/languages:/python/openSUSE_11.4 Python
# zypper ref Python
# zypper in python-gobject2

А потом скачиваем с Factory обновленные пакеты python-gconf, python-notify и python-zte и обновляем их (для python-notify понадобятся более свежие версии libnotify-tools и libnotify4, а для python-vte - более свежие версии libvte9 и gnome-pty-helper):

$ cd /path/to/RPMs
$ wget http://download.opensuse.org/factory/repo/oss/suse/x86_64/python-gconf-2.28.1-11.5.x86_64.rpm
$ wget http://download.opensuse.org/factory/repo/oss/suse/x86_64/python-notify-0.1.1-19.5.x86_64.rpm
$ wget http://download.opensuse.org/factory/repo/oss/suse/x86_64/libnotify4-0.7.4-1.1.x86_64.rpm
$ wget http://download.opensuse.org/factory/repo/oss/suse/x86_64/libnotify-tools-0.7.4-1.1.x86_64.rpm
$ wget http://download.opensuse.org/factory/repo/oss/suse/x86_64/python-vte-0.28.1-2.3.x86_64.rpm
$ wget http://download.opensuse.org/factory/repo/oss/suse/x86_64/libvte9-0.28.1-2.3.x86_64.rpm
$ wget http://download.opensuse.org/factory/repo/oss/suse/x86_64/gnome-pty-helper-0.28.1-2.3.x86_64.rpm
$ sudo -s
# rpm -Uvh python-gconf-2.28.1-11.5.x86_64.rpm
# rpm -Uvh libnotify4-0.7.4-1.1.x86_64.rpm libnotify-tools-0.7.4-1.1.x86_64.rpm python-notify-0.1.1-19.5.x86_64.rpm
# rpm -Uvh gnome-pty-helper-0.28.1-2.3.x86_64.rpm libvte9-0.28.1-2.3.x86_64.rpm python-vte-0.28.1-2.3.x86_64.rpm

Все, готово, теперь и gconf, и pynotify, и vte библиотеки успешно импортируются питоном, а guake спокойно открывается и работает!

зы. Если честно, в итоге решение не особо красивым получилось, но удалось заставить guake (а также другие Python-приложения, использующие обозначенные библиотеки, работать).

Joli OS 1.2 и HP LaserJet M1005MFP

На самом деле, рассказ не стоит и выеденного яйца ибо все известно и так, что для работы HP LaserJet M1005MFP в Linux надо установить foo2xqx, входящий в пакет foo2zjs. Но помня, что во времена Jolicloud 1.1 я так и не подружил систему с сетевым принтером, решил добавить эту заметку.

Итак, первым делом:

$ sudo aptitude update
$ sudo aptitude install foo2zjs

Затем, для облегчения управления принтерами было бы неплохо установить в Joli App Center Printing Add-on, или:

$ sudo aptitude install jolicloud-addons-printing

Дальше, все элементарно, заходим в Printing Add-on, нажимаем Add -> Printer, выбираем тип принтера локальный или сетевой (для сетевых принтеров не забудьте расрешить доступ к нему на сервере), находим принтер, верифицируем, нажимаем Forward, наименовуем принтер, как нравится и нажимая еще раз Forward получаем предложение о печати тестовой страницы, игнорируем это предложение.

Теперь мы видим добавленный принтер в главной области Printing Add-on, вызываем контекстное меню и нажимаем Properties, находим Make and Model и нажимаем Change, ждем пока оно еще раз "найдет" доступные драйвера, и в появившемся окне выбираем производитель HP, кнопка Forward, драйвер LaserJet M1005 MFP (HP LaserJet M1005 MFP Foomatic/foo2xqx), нажимаем последний раз Forward и получаем рабочий сетевой принтер, о чем убеждаемся напечатав тестовую страницу или что-либо еще.

Если же после, описанных мною манипуляций вы все еще получаете:

**** Unable to open the initial device, quitting.

убедитесь еще раз, что вы выбрали драйверы для принтера из пакета foo2zjs, а не из стандартного hpjs.

Пишем в Skype используя не Latin-1 символы на 64-битной системе

Сегодня столкнулся с довольно таки забавной проблемой. Установил последнюю бету Skype для Linux под свой openSUSE 11.4 x86_64 и он мне кодировал все символы русской и украинской раскладки в крякозабры во всех полях ввода. Странно, подумал я и решил явно указать локаль в которой следует работать Skype, однако это ничего не дало. И после:

$ LOCALE=ru_RU.utf8 skype &

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

QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv failed for BOM: Bad file descriptor
QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open failed
QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open failed
QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv failed for BOM: Bad file descriptor

и именно по ним я вышел на решение моей проблемы. Оказалось, что надо всего-то доустановить glibc-locale-32bit из стандартного репозитория, перезапустить Skype и настанет счастье.

Остается только загадкой почему эту зависимость разработчики скайпа не добавили в RPM-пакет и почему упоминание про нее отсутствует на официальной странице по установке Skype в openSUSE.

Итак, не возможно напечатать не Latin-1 символы в полях ввода в Skype? В консоли выполняем:

$ sudo zypper in glibc-locale-32bit

И проблема решена!

Убираем строку "wine core exe" из меню "Открыть с помощью" в Dolphin, Konqueror, Nautilus, etc

Какое-то время назад, во время пользования Jolicloud установил себе Wine для пощупывания Spotify и чего-то еще. Spotify и это что-то еще совершенно не впечатлил, Wine снес, а через какое-то время вернулся и на openSUSE 11.3 в этот раз с KDE 4. Посидел, более менее привык и тут заметил раздражающую проблему, вызывая контекстное меню в Dolphin или Konqueror для любого рисунка (*.jpg, *.png, etc) вижу "wine core exe" в пункте "Открыть с помощью" (Open with...).

В системе Wine не установлен, более того ~/.wine тоже давно отправлен утиль, а "wine core exe" все так же гордо распологаются в контекстном меню. Оказывается, проблема в том, что при установке какой-то программы Wine понасоздавал кучу расширений в ~/.local/share/applications и ясное дело после удаления Wine эти расширения все так же остались в системе и как следствие в контекстном меню.

Что ж, удаляем все расширения:

$ rm ~/.local/share/applications/wine-extension-*

И даже без перезапуска Dolphin или Konqueror видим, что наше меню "Открыть с помощью" приобрело цивилизованный вид и избавилось от ненужных строк "wine core exe".

ps. Как говорит интернет этот способ помагает и для Nautilus'а.

Отмечаем опцию "Enable Wireless" в NetworkManager апплете программно

В последнее время на разных дистрибутивах (openSUSE 11.3, Jolicloud 1.1) заметил интересную проблему. В апплете NetworkManager'а по дефолту не выбрана опция "Enable Wireless", хотя все необходимые драйвера и прошивки для работы устройства беспроводной связи были установлены. И если в openSUSE 11.3 я не особо размышлял о решении этой проблемы и вручную включал устройство, то пересев на Jolicloud мне захотелось понять почему так происходит и найти решение.

Не скажу, что я понял, почему NetworkManager 0.8 автоматически выключает эту опцию, но зато я нашел, как этому противостоять. Решение оказалось очень простым, просто нужно отправить сообщение по dbus, которое включит "Enable Wireless":

dbus-send --system --type=method_call --dest=org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager org.freedesktop.DBus.Properties.Set \
string:org.freedesktop.NetworkManager string:WirelessEnabled variant:boolean:true

Дальше я добавил эту команду в автозагрузку ДЕ (System -> Preferences -> Startup Applications в Jolicloud, например) и при входе в систему теперь получаю автоматически работающее беспроводное соединение. Мелочь, а приятно!

зы. Если вы наоборот хочете автоматически выключить устройство беспроводной связи, то посылайте это же сообщение, только с false вместо true в конце.

зыы. Решение подсмотрел здесь и здесь.

Добавляем сторонние PPA репозитории в Jolicloud 1.1 или Joli OS 1.2

Последнюю неделю играюсь на своем Lenovo S12 с Jolicloud 1.1. Впечатления практически сугубо положительные. Очень удобный дистрибутив для людей, проводящих очень много времени в интернете.

Единственное, что раздражало пару дней было отсутствие нового Gajim'а. Не секрет, что Jolicloud 1.1 построен на основе Ubuntu Lucid Lynx, а в нем версия Gajim'a уж очень стара на текущий момент - 0.13.2 (да и иконка не поддерживала полупрозначности и выбивалась из общего стиля системного лотка). В то же время, новая версия этого замечательного джаббер-клиента была доступна в репозитории ppa:gajim/gajim-ppa. Пойдя путем найменьшего сопротивления, я было попытался добавить этот репозиторий, стандартно для Убунту:

# add-apt-repository ppa:gajim/gajim-ppa

но меня ожидал облом:

Traceback (most recent call last):
  File "/usr/bin/add-apt-repository", line 40, in 
    sp = SoftwareProperties(options) 
  File "/usr/lib/python2.6/dist-packages/softwareproperties/SoftwareProperties.py", line 90, in __init__
    self.reload_sourceslist()
  File "/usr/lib/python2.6/dist-packages/softwareproperties/SoftwareProperties.py", line 538, in reload_sourceslist
    self.distro.get_sources(self.sourceslist)    
  File "/usr/lib/python2.6/dist-packages/aptsources/distro.py", line 90, in get_sources
    raise NoDistroTemplateException("Error: could not find a "
aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template

Вручную задать версию Убунту add-apt-repository не позволяет. Потому пришлось идти долгим путем. Для начала добавляем репозиторий в файл /etc/apt/sources.list.d/ubuntu.list (удобно в конце файла создать условный блок для всех сторонних репозиториев):

deb http://ppa.launchpad.net/gajim/gajim-ppa/ubuntu lucid main 
deb-src http://ppa.launchpad.net/gajim/gajim-ppa/ubuntu lucid main

А затем вручную добавляем ключ (находится на странице репо, блок Signing key) при помощи:

# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 00EECF10

Дальше, все легко, на арену выходит aptitude и без проблем обновляет gajim, который после обновления получает иконку в системном лотке с прозрачностью, ну и возможность общаться голосом/видео посредством вашего Jabber-аккаунта.

Аналогично вы можете добавлять и любые другие репозитории, которые совместимы с Lucid Lynx. И это позволяет превратить Jolicloud в операционную систему общего предназначения, а не только для интернет-сёрферов :)

---

Добавлено 15 апреля 2011 г. Описанный в посте метод работает и для новой Joli OS 1.2, которая все также построена на пакетной базе Ubuntu 10.04 Lucid Lynx.

Будим или отправляем в сон монитор программно

Иногда бывает нужно разбудить спящий монитор, скажем удаленного медиа центра, без нажатий каких-либо клавиш или шевелений мышкой, имея под рукой только ssh доступ к медиа центру.

Как это сделать? На самом деле, проще простого. Нужно просто набрать в консоли:

$ xset dpms force on

и Х-сервер включит монитор. Для выключения монитора, используйте:

$ xset dpms force off

Если при исполнении команд вам выпадет ошибка:

xset:  unable to open display ""

просто укажите необходимый дисплей:

$ DISPLAY=:0 xset dpms force on|off

Одной строкой

Привет! Перед вами еще один блог про свободное програмное обеспечение.