У кого нибудь получилось избавиться от этого каталога в корневом разделе? У меня он появляется в трех точках.
1. В корневом /
2. $HOME/.config
3. /root/.config
Или этот баг все еще так и не обработан?
Только вот я не пойму, что там по этой ссылке то, читал я про неё, но решения так и не нашлось. Типо того что пересобирать пакеты без флага iconv, это же не помогает, не в этом дело, не так ли?
А мои эксперименты показали, что, наоборот, после редактирования этих настроек этот каталог перестал появляться.
Видимо, есть какая-то комбинация настроек (в том числе настройки kdm по умолчанию, похоже), вызывающая этот "баг".
Кстати, раз уж речь зашла о kdm. Почему при любом обновлении kdm etc-update предлагает исправить kdmrc? При этом неважно - вносились в него вручную изменения или нет. Такое ощущение, что этот файл самим kdm-ом постоянно переписывается. Какое-то неправильное поведение.
В моем случае каталог появляется всякий раз, как появляется окно ввода рутового пароля для выполнения действий, которые требуют повышенных привилегий. Суть в том, что процесс, который обеспечивает возможность авторизации, запускается, естественно, от рута. Причем каким-то особенным образом: для этого процесса не определены некоторые переменные окружения. В т.ч. и HOME. Сам этот процесс подгружает плагины. Естественно, средствами Qt. А Qt для того, чтоб увеличить скорость загрузки плагинов, сохраняет средствами QSettings путь до плагинов, временные метки, и пр. Сам QSettings, сохраняет это в ~/.config/Trolltech.cong. Но, так как HOME не определен, ~ обращается просто в пустую строку. Имеем каталог в корне. Проблема может возникнуть и при других обстоятельствах, когда программа, использующая метод homePath(), будет запущена в окружении без переменной HOME. Насколько такая ситуация реальна — трудно сказать. Точнее, насколько типична. Реальность мы наблюдаем тут )
Один из разработчиков Qt уже сказал, что это баг kde. Кде-шники пока молчат. Ждемс....
Я ничего сказать не хочу, мне интересно, если этот файл создаёт qt, а оно так и есть,то откуда он у меня? QT не было никогда.
Всё, я понял, откуда у меня этот файл.
Новый вариант патча. Теперь домашний каталог вычитывается из passwd только если переменная HOME не установлена. В предыдущей версии, не было разницы, установлена ли HOME="", либо вообще не установлена.
Я, правда, не берусь предполагать, насколько это корректно (dbus-launch специально очищает окружение, так что не знаю, уместна ли там HOME), но проблему топика это тоже решает. Как вариант.
eegorov, ты молодец: прошёл путь от "Меня он тоже раздражает, но пока забил на него" до однострочного патча, который, похоже, всех устраивает. Поздравляю!
Меня он тоже раздражает, но
Меня он тоже раздражает, но пока забил на него. Похоже, это kdm гадит
http://www.gentoo.ru/node/141
http://www.gentoo.ru/node/14159
Только вот я не пойму, что
Только вот я не пойму, что там по этой ссылке то, читал я про неё, но решения так и не нашлось. Типо того что пересобирать пакеты без флага iconv, это же не помогает, не в этом дело, не так ли?
FreeBSD для работы, а Linux для души.
Это зависит от кармы, у меня
Это зависит от кармы, у меня в kde 4.6-4.6.5 такого не было.
А кеды как запускал? Через
А кеды как запускал? Через kdm?
Да.
Да.
USE-флаг polycikit у kdelibs
USE-флаг polycikit у kdelibs присутствовал?
Да, он обязателен до 4.7.
Да, он обязателен до 4.7.
чем он мешает собственно?
чем он мешает собственно?
mke2fs написал(а): чем он
Тем что FSSTND смотрит на него как на говно.
.
+1
Мы тоже не всего читали Шнитке!.. © В. Вишневский
Похоже, это проблема в
Похоже, это проблема в qt-core:
QString userPath; char *env = getenv("XDG_CONFIG_HOME"); if (env == 0) { userPath = homePath; userPath += QLatin1Char('/'); #ifdef Q_WS_QWS userPath += QLatin1String("Settings"); #else userPath += QLatin1String(".config"); #endif } else if (*env == '/') { userPath = QLatin1String(env); } else { userPath = homePath; userPath += QLatin1Char('/'); userPath += QLatin1String(env); } userPath += QLatin1Char('/');UPD. Точнее не в самом Qt, а в том, что при определенных обстоятельствах неопределена переменная окружения HOME
Поэкспериментировал. каталог
Поэкспериментировал. каталог появляется после редактирование настроек "Вход в систему" в systemsettings
А мои эксперименты показали,
А мои эксперименты показали, что, наоборот, после редактирования этих настроек этот каталог перестал появляться.
Видимо, есть какая-то комбинация настроек (в том числе настройки kdm по умолчанию, похоже), вызывающая этот "баг".
Кстати, раз уж речь зашла о kdm. Почему при любом обновлении kdm etc-update предлагает исправить kdmrc? При этом неважно - вносились в него вручную изменения или нет. Такое ощущение, что этот файл самим kdm-ом постоянно переписывается. Какое-то неправильное поведение.
В моем случае каталог
В моем случае каталог появляется всякий раз, как появляется окно ввода рутового пароля для выполнения действий, которые требуют повышенных привилегий. Суть в том, что процесс, который обеспечивает возможность авторизации, запускается, естественно, от рута. Причем каким-то особенным образом: для этого процесса не определены некоторые переменные окружения. В т.ч. и HOME. Сам этот процесс подгружает плагины. Естественно, средствами Qt. А Qt для того, чтоб увеличить скорость загрузки плагинов, сохраняет средствами QSettings путь до плагинов, временные метки, и пр. Сам QSettings, сохраняет это в ~/.config/Trolltech.cong. Но, так как HOME не определен, ~ обращается просто в пустую строку. Имеем каталог в корне. Проблема может возникнуть и при других обстоятельствах, когда программа, использующая метод homePath(), будет запущена в окружении без переменной HOME. Насколько такая ситуация реальна — трудно сказать. Точнее, насколько типична. Реальность мы наблюдаем тут )
Один из разработчиков Qt уже сказал, что это баг kde. Кде-шники пока молчат. Ждемс....
https://bugs.kde.org/show_bug
https://bugs.kde.org/show_bug.cgi?id=249217
UPD. Возможно, эта проблема не будет проявляться, если kdelibs собран с USE=-policykit. Проверить не могу.
Удалось выяснить, что данный
Удалось выяснить, что данный каталог создается процессом
/usr/lib64/kde4/libexec/kcmkdmhelper! 501 $ ls -l .config | grep
KDE нету и никогда не было.
Это в корне?
Это в корне?
17:18:48 oleg@newbox
Этот случай не интересен
Этот случай неинтересен. Тут все в норме
как раз, наличие этого файла
как раз, наличие этого файла в домашней папке никого не напрягает.
Меня этот файл тоже абсолютно
Меня этот файл тоже абсолютно не напрягает, речь о том, что в моём случае кедами не пахнет.
Что у вас говорит: ls
Что у вас говорит: ls /.config/Trolltech.conf ?
Этот файл создает Qt.
Этот файл создает Qt.
Нет у меня ничего на Qt.
Нет у меня ничего на Qt.
Ну значит когда-то было. Ты
Ну значит когда-то было. Году так в 1398. Ты нам что сказать то хочешь?
Я ничего сказать не хочу, мне
Я ничего сказать не хочу, мне интересно, если этот файл создаёт qt, а оно так и есть,то откуда он у меня? QT не было никогда.
Всё, я понял, откуда у меня этот файл.
https://bugs.kde.org/show_bug
https://bugs.kde.org/show_bug.cgi?id=249217#c16
Пересобрал kdelibs c флагом
Пересобрал kdelibs c флагом USE="-policykit" emerge kdelibs, но после пересборки флаг все равно присутствует, только значение его в скобках.
Например:
Или
- и + отмечены жирным
FreeBSD для работы, а Linux для души.
Это все-равно не вариант.
Это все-равно не вариант. Просто с -policykit проблема, возможно, не проявлялась бы, только и всего. Попробую Qt пропатчить.
UPD. Патч ниже
.
Пересобрал kdelibs-4.7.0 без policykit -> бага исчезла
Мы тоже не всего читали Шнитке!.. © В. Вишневский
В названии темы описка.
В названии темы описка. Исправь на
/.config/...Новый вариант патча. Теперь
Новый вариант патча. Теперь домашний каталог вычитывается из passwd только если переменная HOME не установлена. В предыдущей версии, не было разницы, установлена ли HOME="", либо вообще не установлена.
diff -uNr qt-everywhere-opensource-src-4.7.3_orig/src/corelib/io/qfsfileengine_unix.cpp qt-everywhere-opensource-src-4.7.3/src/corelib/io/qfsfileengine_unix.cpp --- qt-everywhere-opensource-src-4.7.3_orig/src/corelib/io/qfsfileengine_unix.cpp 2011-03-30 12:19:08.000000000 +0700 +++ qt-everywhere-opensource-src-4.7.3/src/corelib/io/qfsfileengine_unix.cpp 2011-08-03 13:33:47.000000000 +0700 @@ -53,6 +53,7 @@ #include <sys/mman.h> #include <stdlib.h> +#include <unistd.h> #include <limits.h> #if defined(Q_OS_SYMBIAN) # include <sys/syslimits.h> @@ -624,8 +625,28 @@ #if defined(Q_OS_SYMBIAN) QString home = rootPath(); #else - QString home = QFile::decodeName(qgetenv("HOME")); - if (home.isNull()) + QByteArray home_ba = qgetenv("HOME"); + if (home_ba.isNull()) + { +#if !defined(QT_NO_THREAD) && defined(_POSIX_THREAD_SAFE_FUNCTIONS) && !defined(Q_OS_OPENBSD) + int size_max = sysconf(_SC_GETPW_R_SIZE_MAX); + if (size_max == -1) + size_max = 1024; + QVarLengthArray<char, 1024> buf(size_max); +#endif + struct passwd *pw = 0; + uid_t user_id = getuid(); + pw = getpwuid(user_id); +#if !defined(QT_NO_THREAD) && defined(_POSIX_THREAD_SAFE_FUNCTIONS) && !defined(Q_OS_OPENBSD) + struct passwd entry; + getpwuid_r(user_id, &entry, buf.data(), buf.size(), &pw); +#else + pw = getpwuid(user_id); +#endif + home_ba = QByteArray(pw->pw_dir); + } + QString home = QFile::decodeName(home_ba); + if (home.isEmpty()) home = rootPath(); #endif return home;UPD. Баг на Qt-шном треккере: https://bugreports.qt.nokia.com/browse/QTBUG-4862
Если не хотите патчить Qt,
Если не хотите патчить Qt, можно пропатчить kde:
Находим следующие файлы:
и в каждом из них меняем строку с
Execследующим образомна
есть мнение, логичней дбас
есть мнение, логичней дбас настроить, или то, что их запускает
guest написал(а): есть
Сдается мне, настроить не получится. Придется тоже исходники ковырять. Так что уже не сегодня.
Кого "их"?
Хотели D-Bus,
Хотели D-Bus? Пожалуйста:
diff -uNr dbus-1.4.12_orig/bus/activation-helper.c dbus-1.4.12/bus/activation-helper.c --- dbus-1.4.12_orig/bus/activation-helper.c 2011-02-25 19:25:30.000000000 +0600 +++ dbus-1.4.12/bus/activation-helper.c 2011-08-05 11:05:17.000000000 +0700 @@ -344,6 +344,7 @@ "cannot setuid user %i", pw->pw_uid); return FALSE; } + _dbus_setenv ("HOME", pw->pw_dir); #endif return TRUE; }Я, правда, не берусь предполагать, насколько это корректно (dbus-launch специально очищает окружение, так что не знаю, уместна ли там HOME), но проблему топика это тоже решает. Как вариант.
UPD. https://bugs.freedesktop.org/show_bug.cgi?id=39857
Good Job
eegorov, ты молодец: прошёл путь от "Меня он тоже раздражает, но пока забил на него" до однострочного патча, который, похоже, всех устраивает. Поздравляю!
*kdelibs-4.10.5-r1 (22 Jul