Mailinglist Archive: opensuse (1501 mails)

< Previous Next >
Re: [opensuse] Re: [opensuse-kde] Black background with Suse 11.2 and KDE4
  • From: Roger Oberholtzer <roger@xxxxxx>
  • Date: Thu, 09 Sep 2010 08:52:00 +0200
  • Message-id: <1284015120.11267.3.camel@xxxxxxxxxxxx>
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@xxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups