Проблема, похоже, возникает из-за того, что кто-то начал запускать gnome-keyring, даже когда kwalletd уже запущен. Если прибить gnome-keyring, все начинает работать как надо.

Можно попробовать починить добавлением DBus Service файла.

Вообще, service файл для org.freedesktop.secrets для kwallet уже был, но я его не приложил после прохождения Secret Service в апстрим, т.к. все работало из без него. В любом случае этот service файл мало поможет. Чтобы надежно избежать конфликтов kwalletd/gnome-keyring нам нужен какой-то явный механизм переключения бэкендов.

(Ответ для Slava Aseev на комментарий #1)
> Можно попробовать починить добавлением DBus Service файла.

Неа, проверил, это не помогает. Тут вообще запускаются сразу два org.freedesktop.secrets сервиса.
К тому же, баг https://bugzilla.altlinux.org/42507 воспроизводится и на старой версии, где у kwallet'а еще был dbus-service файл (но там активируется только один сервис, а именно gnome-keyring).

В общем, нужно либо решать проблему конфликтом gnome-keyring/kwalletd, либо:
> Чтобы надежно избежать конфликтов kwalletd/gnome-keyring нам нужен какой-то
> явный механизм переключения бэкендов.

Как я понял, в dbus-daemon все активируемые сервисы хранятся в хэш-таблице, где в качестве ключа используется название сервиса (например, org.freedesktop.secrets).
Соответственно, никаких дублей там быть не может, а порядок попадания сервисов в эту таблицу нигде не регламентирован (разве что самим кодом). Надо посмотреть, возможно получится сделать так, чтобы перед записью данных в эту хэш-таблицу все service-конфиги сортировались по дате изменения. В таком случае, мы сможем явно задавать сервис-конфиг, в котором указанный там исполняемый файл возымеет приоритет при dbus-активации (и можно будет приделать какую-нибудь настройку/control для этого).

(In reply to Slava Aseev from comment #1)
> Проблема, похоже, возникает из-за того, что кто-то начал запускать
> gnome-keyring, даже когда kwalletd уже запущен. Если прибить gnome-keyring,
> все начинает работать как надо.
> 
> Можно попробовать починить добавлением DBus Service файла.
Значит, всё-таки зря его убрали.

Когда был service-файл KDE-шный, вроде проблемы не было, значит порядок запуска был подходящий. Надо вернуть файл, а потом, если будет проблема, уже думать над порядком.

(Ответ для Sergey V Turchin на комментарий #4)
> Когда был service-файл KDE-шный, вроде проблемы не было, значит порядок
> запуска был подходящий. Надо вернуть файл, а потом, если будет проблема, уже
> думать над порядком.

Попробовал с файлом - разницы нет. Запускаются сразу и gnome-keyring и kwalletd при логине. gnome-keyring запускает xdg-desktop-portal.service. Если остановить gnome-keyring-daemon, и перезапустить xdg-desktop-portal.service, gnome-keyring-daemon снова запускается/активируется. Причем это происходит даже если service-файл для kwalletd на месте.

(Ответ для Slava Aseev на комментарий #5)
> Попробовал с файлом - разницы нет. Запускаются сразу и gnome-keyring и
> kwalletd при логине. gnome-keyring запускает xdg-desktop-portal.service.
> Если остановить gnome-keyring-daemon, и перезапустить
> xdg-desktop-portal.service, gnome-keyring-daemon снова
> запускается/активируется. Причем это происходит даже если service-файл для
> kwalletd на месте.

Хотя, если перезапустить уже kwalletd, а потом повторить всю процедуру, gnome-keyring не будет запускаться. Видимо, при входе в систему получается гонка, что-то вроде такого:
- Запускается kwalletd
- Запускается gnome-keyring (т.к. org.freedesktop.secrets еще нету на шине)
- gnome-keyring регистрирует org.freedesktop.secrets
- kwalletd пытается тоже, но уже не может, и при этом продолжает работать

Кстати, если создать org.freedesktop.secrets.service для kwalletd в /usr/local/share/dbus-1/services, то он возымеет приоритет над gnome-keyring. Похоже, это потому что в XDG_DATA_DIRS /usr/local/share стоит перед /usr/share. /usr/share/kf5 тоже, но с ним это не работает, почему-то.

(In reply to Slava Aseev from comment #7)
> /usr/local/share/dbus-1/services
Низя туда.

(In reply to Slava Aseev from comment #7)
> Похоже, это потому что в XDG_DATA_DIRS /usr/local/share стоит
> перед /usr/share. /usr/share/kf5 тоже, но с ним это не работает, почему-то.
Скорее, потому, что
<standard_session_servicedirs />
обрабатывается до
<includedir>/etc/dbus-1/session.d</includedir>

(Ответ для Sergey V Turchin на комментарий #8)
> (In reply to Slava Aseev from comment #7)
> > /usr/local/share/dbus-1/services
> Низя туда.
Да оно понятно, это я для примера. Проблема там в том, что dbus запускается раньше того, как startplasma прокинет переменную XDG_DATA_DIRS, поэтому /usr/share/kf5 там не оказывается. Прокинуть ее туда потом не представляется возможным, только если перезапустить dbus.service (и после перезапуска начинает активироваться kwalletd вместо gnome-keyring)

> Скорее, потому, что
> <standard_session_servicedirs />
> обрабатывается до
> <includedir>/etc/dbus-1/session.d</includedir>

Попробовал поднять строку с <includedir>/etc/dbus-1/session.d</includedir> наверх и у меня заработало, активироваться стал kwalletd.

(In reply to Slava Aseev from comment #9)
> Попробовал поднять строку с <includedir>/etc/dbus-1/session.d</includedir>


> наверх и у меня заработало, активироваться стал kwalletd.
Это понятно, но, скорее всего, неправильно.
Может, у мантейнера dbus есть мысль на этот счёт?

Я бы поменял порядок. Сейчас поломки со стороны мантейнера стала небольшой. Да и тестирвоание работает.

P.S.
Добавлять в dbus возможность обновить переменные смысла не вижу, т.к. после этого придется его перезапускать по сути. Если нет проблем, чтобы он сам перезапустился после такого, то может и так лучше.

(Ответ для Sergey V Turchin на комментарий #10)
> P.S.
> Добавлять в dbus возможность обновить переменные смысла не вижу, т.к. после
> этого придется его перезапускать по сути. Если нет проблем, чтобы он сам
> перезапустился после такого, то может и так лучше.

Перезапускать может и не придется, т.к. у dbus есть метод ReloadConfig(), его можно вызвать после задания /usr/share/kf5 в startplasma. Проблема в том, что к моменту, когда это будет вызвано, gnome-keyring уже может быть запущен. Ну и также в том, что сейчас нет никакой возможности прокинуть переменную окружения в сам dbus.

(Ответ для Sergey V Turchin на комментарий #10)
> Я бы поменял порядок. Сейчас поломки со стороны мантейнера стала небольшой.
> Да и тестирвоание работает.

Может добавить /usr/share/kf5/dbus-1/session.d для KDE? И впихнуть его как раз в самое начало, ну и перенести туда kf5.conf

пока есть /usr/share/dbus-1/services/org.freedesktop.secrets.service врятли kwalletd5 можно бедет запустить раньше gnome-keyring-daemon

(In reply to Valery Inozemtsev from comment #13)
> пока есть /usr/share/dbus-1/services/org.freedesktop.secrets.service врятли
> kwalletd5 можно бедет запустить раньше gnome-keyring-daemon
Можно без проблем, как выше обсуждалось. И без изменений в gnome-keyring.

(In reply to Slava Aseev from comment #12)
> Может добавить /usr/share/kf5/dbus-1/session.d для KDE?
В момент запуска пользовательского dbus ещё не дополнен XDG_DATA_DIRS KDE-шным каталогом. А так бы я давно это сделал.

Надо посмотреть, как оно с systemd, а то уже всё готово для автозапуска пользовательской сессии через systemd.

Попробовал сделать рестарт dbus в startplasma сразу после того, как в systemd1 пробросятся переменные и ему пошлется Reload: https://git.altlinux.org/people/ptrnine/packages/?p=plasma5-workspace.git;a=commit;h=5b8493055fbe785400f22ba182eeb30ffaa00256

В итоге все начинает работать как надо, gnome-keyring больше не запускается.
По /proc/PID/environ у dbus-daemon видно, что XDG_DATA_DIRS до него долетел.
Так что остается только включить systemd boot в плазме по-умолчанию, и можно будет отправлять.

Т.е. zerg таки был прав, больше ничего делать не надо, gnome-keyring после этих действий уже не будет запускаться (я до этого, оказывается, просто впихнул рестарт dbus'а не в то место).

Воспроизводится на виртуальной машине:

[sisyphus] kworkstation-10.2.1-x86-64
evolution-3.50.2-alt1.x86_64
kf5-kwallet-5.113.0-alt1.x86_64
kde5-kwalletmanager-23.08.4-alt1.x86_64
pam0_kwallet5-5.27.10-alt1.x86_64

Не воспроизводится на виртуальной машине:

[p10] kworkstation-10.2.1-x86-64
evolution-3.44.0-alt1.x86_64
kf5-kwallet-5.112.0-alt2.x86_64
kde5-kwalletmanager-23.04.3-alt1.x86_64
pam0_kwallet5-5.27.9-alt1.x86_64

При этом:

* Если открывать evolution в sisyphus несколько раз, уже на шаге 7 воспроизводится повторный запрос пароля почты. А на шаге 5 создаётся новый кошелёк, даже если не удалять "kdewallet" (т.е. не делать шаг 2).

* В p10 в kwalletmanager5 только "kdewallet", в sisyphus - список из "kdewallet" и "Связка ключей по умолчанию", причём пароль от почты сохраняется именно в "Связка ключей по умолчанию", а не в "kdewallet", как в p10.

* "Запрашивать подтверждение при обращении приложений к бумажнику" не требует пароль бумажника в p10, просто просит разрешить или запретить доступ. В sisyphus запрашивается пароль бумажника, а затем уже начинает запрашивать пароль от почты много раз.