On Mon, 2010-09-06 at 17:45 +0200, Will Stephenson wrote:

On Thursday 02 September 2010 07:58:38 Roger Oberholtzer wrote:

...

(I am posting this to you as I have not set up a file exchange. Other than DropBox.)

Here are the screen shots. It is a new install of 11.2. The disk is new, so there is nothing from any previous OS. The update that 11.2 offers to do was not done, so this is what you get with the install DVD. I have other systems where the update had been done, and it makes no difference.

The graphics card is a new nvidia card. I can get the details. But I have seen this on other systems with other cards. For example, I have a different system with an ATI Rage XL that does the same thing.

As you will see in the screen shots, it is ok for root, but no one else. This is consistent in all installs with this issue. Which, for us, is 50% of them. Up until now this was bearable as we have been using internal systems. But now some of our customers want to update to openSUSE 11.2 and, and we have experienced this problem on those systems as well.

If you need me to try anything I can.

Hi Roger

I thought this issue was going to be easy but I have installed a clean, un- updated 11.2 and it didn't reproduce the issue as I expected.

Basically, we saw this behaviour on openSUSE 11.3 due to a wrong splitting of the kdebase4-runtime package into kdebase4-runtime and kdebase4-runtime- branding-upstream. This is not the case in openSUSE 11.2, either default 4.3.1 or updated to 4.3.5.

However it looks so similar to the 11.3 issue that I want to double check on your affected systems and exclude it.

*

It all revolves around files in /usr/share/kde4/apps/desktoptheme. These are the elements used by the Plasma workspaces for theming. The default theme (currently 'Air') lives in 'default' under this path. The configured theme provides its own theming elements and defines a theme it falls back to to locate elements that the theme does not replace, eg air-netbook falls back to default (Air). If an element is not found in either of these locations, Plasma has a hardcoded fallback to oxygen. This is apparently where your screenshots are getting the black theme elements from.

There is "Air" and "Air openSUSE". Which is the default? I have chosen "Air openSUSE" here. The porclem exists no matter which one I choose. With oxygen, I can at least read text as it is white, With the others, it is black on a black background.

A theme is defined including its fallback in /usr/share/kde4/apps/desktoptheme/<themename>/metadata.desktop

*

The configured theme is stored in ~/.kde4/share/config/plasmarc in the Theme group eg

[Theme] name=air-netbook

This is a plasmarc on an offending system: [$Version] update_info=plasma_popupapplet_fix_groups.upd:PlasmaPopupAppletFixGroups2 [Theme] name=openSUSEdefault

This name comes from the contents of the /usr/share/kde4/apps/desktoptheme/openSUSEdefault/metadata.desktop file.

Mine looks like this: [Desktop Entry] X-SuSE-translate=t Name=Air openSUSE Comment=A breath of fresh air X-KDE-PluginInfo-Author=The Oxygen Project X-KDE-PluginInfo-Email=kde-artists@kde.org X-KDE-PluginInfo-Name=openSUSEdefault X-KDE-PluginInfo-Version=0.9 X-KDE-PluginInfo-Website=http://plasma.kde.org X-KDE-PluginInfo-Category= X-KDE-PluginInfo-Depends= X-KDE-PluginInfo-License=GPL X-KDE-PluginInfo-EnabledByDefault=true

*

With this in mind, my failure hypothesis is that somehow the theme is not readable to your affected users. To check this, see what theme is configured in their plasmarc, look in its metadata.desktop and see what fallback theme this is. If the settings are default, it should be 'openSUSEdefault' which has no fallback defined (it provides a full set of elements). Check that this is readable to the user. Then check if /usr/share/kde4/apps/desktoptheme/<themename> is readable for your affected users. If there is a fallback theme (eg default) check that /usr/share/kde4/apps/desktoptheme/default is populated (contains eg widgets/panel-background.svgz) and contains a readable metadata.desktop.

I have checked all the files/directories in /usr/share/kde4/apps/desktoptheme/ and they are readable by ugo I also did "find /usr/share/kde4 ! -readable" as an unlucky user, and nothing was listed.

*

If there is no smoking gun here and the default theme is present and readable, try making Air openSUSE fallback to default, by adding

[Settings] FallbackTheme=default

to

/usr/share/kde4/apps/desktoptheme/openSUSEdefault/metadata.desktop as root, then restarting plasma-desktop with

kquitapp plasma-desktop && sleep 2 && plasma-desktop

This is a shot in the dark.

I get this: % kquitapp plasma-desktop && sleep 2 & plasma-desktop [1] 8558 Invalid D-BUS interface name 'org.kde.plasma-desktop.PlasmaApp' found while parsing introspection and no desktop at all. My console window is all that is left. So I logged out/in. The desktop started now, but still no joy. Black remained popular. So I removed these lines jic.

*

My other failure hypothesis is that there is a bug in the plasma cache (used to speed up drawing SVG elements). There are a number of bugs in the cache code which are hard to backport to KDE 4.3 since the code was replaced in 4.4. and 4.5. You could try forcing the cache to be recreated by logging the user out, removing /var/tmp/kdecache-$USER/kpc and logging back in again.

I deleted all the user's kde files in /tmp and /var/tmp. It made no difference. I did the same again, and deleted the user's .kde4 directory. No difference. I have verified that it works ok for root. It is only non-root users that have this issue.

HTH

It was educational. But the problem remains. It does really act like a permission problem. But where? I checked if the contents of /usr are readable by a non-root user, and I see some files are not readable. Aside from some html docs, this is what I get: /usr/bin/keygen /usr/bin/Xorg /usr/bin/sperl5.10.0 /usr/bin/X /usr/sbin/klogconsole /usr/sbin/glibc_post_upgrade /usr/lib/mpi/gcc/openmpi/share/man/man1/mpiCC.1 /usr/lib/python2.6/ssl.pyc /usr/lib/PolicyKit/polkit-grant-helper-pam /usr/lib/lsb/remove_initd /usr/lib/lsb/install_initd /usr/lib/ooo3/share/uno_packages/cache/uno_packages/5JWFva /usr/lib/ooo3/share/uno_packages/cache/uno_packages/wg7jmG /usr/lib/ooo3/share/uno_packages/cache/uno_packages/nAC1OJ /usr/lib/ooo3/share/uno_packages/cache/uno_packages/M3U2VJ /usr/lib/ooo3/share/uno_packages/cache/uno_packages/jnkvHX /usr/lib/cups/backend/hpfax /usr/lib/cups/backend/http /usr/lib/cups/backend/lpd /usr/lib/cups/backend/ipp /usr/lib/qt4/examples/painting/svgviewer/svgviewer /usr/lib/qt4/demos/browser/browser Not so unexpected. I really do not know what to do. I can't ignore lots of rather standard machines that I am trying to do these installs on. I really cannot see how the hardware could result in the desktop acting differently for non-root users. I have looked at the .xsession-errors files for root and others. I see one complaint in the non-root user file that is not in the root file: kdeinit4: preparing to launch /usr/lib/libkdeinit4_klipper.so Traceback (most recent call last): File "/usr/bin/hp-systray", line 35, in <module> from base import utils, module File "/usr/share/hplip/base/module.py", line 30, in <module> import tui, utils, device File "/usr/share/hplip/base/device.py", line 25, in <module> import gzip File "/usr/lib/python2.6/gzip.py", line 9, in <module> import zlib ImportError: /usr/lib/python2.6/lib-dynload/zlib.so: undefined symbol: inflateCopy Object::connect: No such signal SystemTray::Manager::jobStateChanged(SystemTray::Job*) [/usr/bin/nepomukservicestub] (Soprano::Redland::BackendPlugin) creating model of type "hashes" with options "hash-type='bdb',contexts='yes',dir='/home/rst/.kde4/share/apps/nepomuk/repository/main/data/redland',new='yes'" kdeinit4: preparing to launch /usr/lib/kde4/kio_desktop.so kdeinit4: preparing to launch /usr/lib/kde4/kio_trash.so [/usr/bin/nepomukservicestub] (Soprano::Redland::BackendPlugin) creating model of type "hashes" with options "hash-type='bdb',contexts='yes',dir='/home/rst/.kde4/share/apps/nepomuk/repository/main/',new='yes'" "/usr/bin/kdeinit4(13802)" Error in thread 3044128512 : "org.freedesktop.DBus.Error.UnknownObject - No such object path '/org/soprano/Server'" "/usr/bin/kdeinit4(13802)" Error in thread 3044128512 : "QLocalSocket::connectToServer: Invalid name" Not sure if this is where the theme is involved. But I guess any detail might help. I have on-site access to a machine that exhibits this problem until early Thursday afternoon. After that it gets more difficult to try things. But I will do my best to try any further suggestions you might have.! -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org