man dbus-launch

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

Ух ты какой я динозавр. У меня просто

exec openbox-session

Никаких дэбусов и прочих лаунчей)

https://wiki.archlinux.org/index.php/Xinit#Preserving_the_session

Если у тебя systemd, то ck-launch-session не может быть. Оно нужно в основном для того, чтобы без рута работало выключение ПК (через dbus-пинок в сторону UPower и прочее).

Так, Gentoo Handbook же.

Я тоже так думаю, при попытке установить 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.

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

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

Размаскируйте нужную версию pambase.

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

Я правильно понял, что тебе всего-то нужно запускать 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

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

.xinitrc

/etc/inittab

.bash_profile

А потом они спрашивают, зачем нужен systemd.

Полегче Леннарт...

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

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

Кхм, вообще сейчас нужная версия 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

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> - применяется ко всем версиям пакета.

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

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

emerge -av1 sys-auth/pambase

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

Иногда приходится, ибо бывает, что 2 пакета имеют одинаковые названия, но в разных категориях :-)

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

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

Ну, это понятно же.

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

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

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

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

Пруф что ли.

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

У тебя тоже systemd?

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

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

rc-update add consolekit default && rc-update dbus default, не? нах сервисы запускать из xinitrc???

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

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

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

/home/Amet13/.bash_profile

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

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

еще забыл

.profile
.Xclients

Пруф что ли.

Можешь почитать здесь, зеркале почившей 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 фигачить?

Не понял.

Для 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

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

Есть живая же 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

Не понял.

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

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

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

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

Да, скоро все так жить будут.