LINUX.ORG.RU

Правильная строка в ~/.xinitrc

 ,


0

2

Значится так. Свежая гента + awesome. Иксы работают, awesome тоже. Пишу в ~/.xinitrc строку:

exec ck-launch-session dbus-launch --sh-syntax --exit-with-session awesome
Ответ:

exec ck-launch-session: не найден

Убираю ck-launch-session, все отлично запускается. Кто-нибудь объяснит мне, почему так происходит. З.Ы. Запускал и от юзера и от рута, эффект одинаков.

★★★★★

man dbus-launch

там подробно, ck-launch это вроде console-kit, он есть?

qnikst ★★★★★
()
Ответ на: комментарий от x3al

Я тоже так думаю, при попытке установить consolekit:

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

sys-auth/pambase:0

  (sys-auth/pambase-20101024-r2::gentoo, installed) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (sys-auth/pambase-20120417-r2::gentoo, ebuild scheduled for merge) pulled in by
    sys-auth/pambase[consolekit] required by (sys-auth/polkit-0.110::gentoo, ebuild scheduled for merge)


!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific suggestion.

Amet13 ★★★★★
() автор топика

Сделал так, пока нормально:

exec dbus-launch --sh-syntax --exit-with-session awesome

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от kostik87

Можно подробнее? Я с гентой в первый раз, поэтому не все нюансы знаю. И еще, устанавливаю xdm, точно такая же картина.

Amet13 ★★★★★
() автор топика

Я правильно понял, что тебе всего-то нужно запускать awesome? Тогда ты всё делаешь не так.

Официально в Гентоо, авесоме запускается вот так:

-> /etc/env.d/90xsession (если нет, создать):

XSESSION="awesome"

-> /home/Amet13/.bash_profile :

 if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ] ; then
    startx
 fi

Выполнить от рута: source /etc/profile && env-update

Всё, никаких дбусов, .xinitrc (зачем он вообще нужен), xdm, consolekit, pambase и прочей шелупони. Иксы с сессией Авесоме стартует автоматически при логине пользователя.

Также, если нужно, удобно сделать автологин в авесоме: /etc/inittab :

 # TERMINALS
 c1:12345:respawn:/sbin/agetty -a Amet13 38400 tty1 linux
 c2:2345:respawn:/sbin/agetty 38400 tty2 linux
 c3:2345:respawn:/sbin/agetty 38400 tty3 linux
 c4:2345:respawn:/sbin/agetty 38400 tty4 linux
 c5:2345:respawn:/sbin/agetty 38400 tty5 linux
 c6:2345:respawn:/sbin/agetty 38400 tty6 linux

science ★★☆
()
Последнее исправление: science (всего исправлений: 3)
Ответ на: комментарий от science

Дело в том, что я хотел сделать автологин не терминальный, а потом запуск иксов, а сразу ГУЙ с окошком. Сейчас попробую ваш вариант.

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от science

Спасибо @science, этот метод хорош, все работает.

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Эмм. systemd как раз и причина. Топикстартер хочет запустить awesome в consolekit-сессии с нужными правами без DM. На данный момент это, кстати, невозможно в systemd-системе по причине смерти consolekit и конфликта его с logind. Впрочем, я не в курсе, ломается ли безрутовое выключение ПК в случае logind после startx.

x3al ★★★★★
()
Ответ на: комментарий от Amet13

Кхм, вообще сейчас нужная версия pambase уже находится в стабильной ветке:
http://packages.gentoo.org/package/sys-auth/pambase

Так что просто установите её:

emerge -av1 sys-auth/pambase

или можете заодно обновить и system:

emerge -auvDN system

Теперь, что такое размаскировать пакет, в Gentoo есть несколько состояний пакета, стабильный, тестовы и не стабильный.

У стабильного пакета значение keywords будет равно amd64, x86 и так далее, у тестового пакета значение keywords будет равно ~amd64, ~x86 и так далее, у не стабильного пакета значение keywords будет вообще пустое. Кроме всего прочего для одной архитектуры одна версия пакета может быть стабильной, а для другой тестовой.

Для размаскировки пакетов и управления опциями сборки (USE флагами) конкретного пакета используются специальные файлы (директории), создадим их:

mkdir -p /etc/portage/package.keywords
mkdir -p /etc/portage/package.use
mkdir -p /etc/portage/package.unmask

В директории (файле) package.keywords можно размаскировать пакет с keywords отличным от того, с которым устанавливаются пакеты в системе. По умолчанию ставяся пакеты только со стабильным keywords, x86, amd64 и так далее, если вам нужно поставить пакет с тестовым keywords, например тестовую версию компилятора для ветки ~amd64, то вам нужно внести такие строки в файл:

=sys-devel/gcc-4.7.2-r1 ~amd64
Можно выполнить такую команду, что бы не редактировать файл в ручную:
=sys-devel/gcc-4.7.2-r1 ~amd64 >> /etc/portage/package.keywords/gcc

В package.unmask размаскируются не стабильные версии пакетов, например вы хотите поставить не стабильную версию компилятора:

echo =sys-devel/gcc-4.8.1 >> /etc/portage/package.unmask/gcc
Кроме всего прочего эту версию нужно размаскировать и в keywords:
echo =sys-devel/gcc-4.8.1 ** >> /etc/portage/package.keywords/gcc

Если вам нужно указать собирать компилятор с определённым флагом, напрмер vanilla, но вы не хотите этот флаг задействовать глобально в make.conf, то вам нужно указать это в package.use:

echo sys-devel/gcc vanilla >> /etc/portage/package.keywords/gcc

Кроме всего прочего можно указывать определённые версии пакетов, посредством использование модификаторов при указании версии:

=<cat>/<atom> - точное указание версии пакетов, например =sys-devel/gcc-4.8.1 
><cat>/<atom> - указание пакетов больше определённой версии, например >sys-devel/gcc-4.7.0
><cat>/<atom> - указание пакетов меньше определённой версии, например <sys-devel/gcc-4.7.0
<cat>/<atom> - применяется ко всем версиям пакета.
Модификаторы можно смешивать, >=, <=.

kostik87 ★★★★★
()
Ответ на: комментарий от kostik87

Спасибо. Очень полезная заметка.

Amet13 ★★★★★
() автор топика

короче когда systemd стоит то всей этой шляпы не надо.
просто exec xmonad и всё
колнечно если все системд модули для дбасов и прочих настроены и включены

Bad_ptr ★★★★★
()
Последнее исправление: Bad_ptr (всего исправлений: 1)
Ответ на: комментарий от fragmentor

Это для наглядности.

Кроме всего прочего, при установке midnight commander придётся в любом случае указывать имя группы и имя атома, app-misc/mc, т.к. простое указание 'mc' не подойдёт, т.к. есть пакет sci-libs/mc .

kostik87 ★★★★★
()
Ответ на: комментарий от Bad_ptr

Без systemd нужно всего-лишь: echo XSESSION="awesome" >> /etc/env.d/90xsession и всё.

Зацени: без systemd.

science ★★☆
()
Ответ на: комментарий от x3al

Не только. Без него автомонтирование всяких USB не будет работать. Подробнее есть тут.

Deleted
()
Ответ на: комментарий от science

Официально в Гентоо, авесоме запускается вот так:

Пруф что ли.

Всё, никаких дбусов

У тебя тоже systemd?

.xinitrc (зачем он вообще нужен)

Во-первых, потому, что это путь, описаный самими разработчиками Xorg для определения приложения, которое будет запущено xinit. Без ковыряния корявыми ручонками системых файлов типа тех что ты указал в /etc. Прелесть Xorg как раз в том, что всю конфигурацию можно перевесить на пользователя и таскать в его хомяке, за небольшим исключением.
Во-вторых, как ты предлагаешь перенаправлять stdout и stderr от своего WM в логи, если надо подебажить? А компоновку конфигов перед стартом сессии ты предлагаешь на lua фигачить?

Deleted
()
Ответ на: комментарий от NeverLoved

У меня была проблема с установкой consolekit (см. выше).

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от science

зачем он вообще нужен

Обычно помимо старта windows manager'а в нём указывается запуск нескольких других приложений. То есть, это некий аналог автостарта.

/home/Amet13/.bash_profile

Для zsh это ~/.zsh_profile?

И где в указанном /etc/inittab указан автологин в авесоме?

dmitry_malikov ★★
()
Ответ на: комментарий от Deleted

Пруф что ли.

Можешь почитать здесь, зеркале почившей en.gentoo-wiki.com.

Т.е. ~/.xinitrc это user, а xsession - system wide настройка wm'а. Лично я нахожу второе более удобным.

У тебя тоже systemd?

Нет, я же выше указал, что этого не держим такого. Dbus безусловно нужен для многих вещей, если осом собран с его юзом.

Во-вторых, как ты предлагаешь перенаправлять stdout и stderr от своего WM в логи, если надо подебажить?

Лог awesome пишет, согласно ебилдовому /usr/portage/x11-wm/awesome/files/awesome-session , в ~/.awesome-errors пользователя, от которого он запущен.

А компоновку конфигов перед стартом сессии ты предлагаешь на lua фигачить?

Не понял.

science ★★☆
()
Ответ на: комментарий от dmitry_malikov

Для zsh это ~/.zsh_profile?

Наверное, если зишел - дефолтный шелл.

И где в указанном /etc/inittab указан автологин в авесоме?

c1:12345:respawn:/sbin/agetty -a Amet13 38400 tty1 linux

где -a Amet13 == автологин в шелл пользователя Amet13, при этом сразу читается .bash_profile, где указан startx, а иксы, в свою очередь, читают системный /etc/env.d/90xsession с указанным авесоме или любым другим wm/DE

science ★★☆
()
Ответ на: комментарий от science

Можешь почитать здесь, зеркале почившей

Есть живая же http://wiki.gentoo.org/wiki/Awesome#Starting

Т.е. ~/.xinitrc это user

Вообще, не только ~/.xinitrc, ну да ладно.

а xsession - system wide настройка wm'а. Лично я нахожу второе более удобным.
system-wide
более удобным

Чем удобно-то? System-wide удобен, когда пользователей куча и всем надо обязательно иметь такую настройку, может даже, по дефолту. У тебя большая семья, где все логинятся в твой комп, чтобы разделить твою любовь к awesome, или ты на нём лдап для какого-нибудь офиса с тонкими клиентами поддерживаешь?

Dbus безусловно нужен для многих вещей, если осом собран с его юзом.

То-то же.

Лог awesome пишет, согласно ебилдовому /usr/portage/x11-wm/awesome/files/awesome-session , в ~/.awesome-errors пользователя

Ага, вижу

exec > "$errfile" 2>&1
Выхлоп stdout слит с выхлопом stderr, это просто потрясающие возможности для поиска ошибок. Я уж молчу о том, что все приложения, запущенные непосредственно из конфига awesome, тоже имеют потенциальную возможность послать свой выхлоп в этот файл. Пойди разберись там, где лиса запускалась, а где WM глючил.

Не понял.

Ну вот у меня есть конфиг для mpd, который я хочу запускать на большом компе и на нетбуке. На буке мне не надо например стримать в локалку, да и если такая возможность понадобится, IP всё равно перевбивать придётся. Поэтому разумно разбить конфиг на основную часть, которая подойдёт к обеим машинам, и персональные. И, до запуска самого mpd среди прочих в авторане, взять основной кусок и к нему приклеить один из двух дополнительных. А так как приложений, которые не поддерживают инклюд в своих конфигах, достаточно много, предварительная склейка стала довольно популярной для тех, кто ищет способы разнесения конфигов, но в то же время хранения их в одном месте.

Deleted
()
Ответ на: комментарий от Deleted

Ну вот у меня есть конфиг для mpd, который я хочу запускать на большом компе и на нетбуке. На буке мне не надо например стримать в локалку, да и если такая возможность понадобится, IP всё равно перевбивать придётся. Поэтому разумно разбить конфиг на основную часть, которая подойдёт к обеим машинам, и персональные. И, до запуска самого mpd среди прочих в авторане, взять основной кусок и к нему приклеить один из двух дополнительных. А так как приложений, которые не поддерживают инклюд в своих конфигах, достаточно много, предварительная склейка стала довольно популярной для тех, кто ищет способы разнесения конфигов, но в то же время хранения их в одном месте.

Препарируй конфиг из темплейта в ходе установки дотфаелсов.

dmitry_malikov ★★
()
Ответ на: комментарий от dmitry_malikov

В смысле ложить готовым конфигом сразу после распаковки dotfiles? Но тогда если захочется поправить конфиг, это придётся делать два раза — один в подготовленном и ещё один — в конфиге из dotfiles, который шаблон.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.