On 05/20/2011 09:17 AM, Duncan wrote:
> I was waiting for someone who hopefully had a clue about slackware to
> respond, as I don't, /and/ I have little idea what's wrong with kde
> either. However, as nobody else is taking a shot, I guess I'll post what
> vaguely possibly helpful ideas I have that might help...
You were right in thinking that the answer might lie with some Slackware
expertise - I asked / searched on Slackware forums as well and was
pointed in the direction of the version 13.37 release notes where it
says : "If KDE crashes on startup, try disabling the Composite
extension". It then tell you how to do this in the X11 configuration".
Did that and it solved the immediate problem. KDE does now start up OK
and I have opted for re-configuring it rather than putting ~/.kde back
(either all at once or selectively) since there appear to have been some
changes to KDE which make my previous config not fully compatible.
What I don't quite understand is why compositing is a problem now when
it was not previously under KDE 4.4.3 with the same video card and an
updated latest nvidia (binary) driver. [I guess I should pause here
while you provide your brief customary "servantware" lecture (: ].
I will probably keep the system as it is for a while and then look at
re-introducing compositing. 90% of the eye-candy is of little interest,
but the visual feedback supplied by the various transitions between
virtual desktops and activities can be quite helpful.
> First, the akonadi errors shouldn't be the problem -- akonadi's only the
> pim/contacts/organizer type service. If you were having kontact/kmail/
> korganizer type issues, that might be related, but it's not the problem
> here, since kde would still start in that case, tho it's possible the
> errors you see are /due/ to the same root problem.
>
> That it was a kde 4.4 to 4.5 upgrade indicates that it's not a hal to u*
> (udev/upower/udisks, and friends) conversion issue, my next thought for
> permissions issues, since the hal to u* transition only happened with the
> kde 4.5 to 4.6 upgrade.
>
> That it works as root but not as a normal user indicates it's a privileges/
> permissions issue of /some/ kind.
I probably turned off compositing *within* KDE system settings [pause
again for your rant about what this should really be called] for the
root user. So the clue here that it was to do with privileges and
permissions turned out to be a false trail.
> That it fails equally with your normal and a new user indicates that it's
> not your user config.
>
> That it worked fine on two other PCs indicates that it's not a generic
> distro issue. Question: Were the two that it worked fine on, on the same
> slack 13.1 (not some other version) before, to 13.37 now, all three
> running kde equally well, on the old version? If so, then we know it's
> not an issue specific to that specific upgrade.
>
> Beyond that, we don't have much to go on. But, we DO know that it's a
> system (not user config) problem, that it works on two other machines, and
> that its almost certainly a permissions/privileges problem. That's a
> start.
>
> OK. From the is it kde itself or X, side of things...
>
> Do you have any other X environments on the machine? Can you install one
> if not? We're not looking for anything fancy, so icewm or *box (for
> instance) as a wm and an xterm will do, as long as you know how to get it
> running from a text login using startx or the like. The first thing to do
> is see if the user can start an X session with anything else BUT kde.
> Keep in mind that you can install the same environment to one of the
> working machines and try it there, so you know what should work on the bad
> machine...
>
I had xfce working fine, but did not get around to your suggested tests
with other KDE apps under xfce (strongly suspect they would have worked
fine).
> Assuming that works, the next thing to do is see if you can run a kde app
> under that other environment. Try running konsole or dolphin, or
> something simple like kpat. Alternatively, if you regularly use other
> environments and run kde apps (like say k3b or amarok) from them so you
> know it worked before, test with them. If you try launching the app from
> xterm, the debug info it spits out as it dies might be useful. HOWEVER,
> kde apps OFTEN spit out a huge amount of alarming looking but apparently
> harmless information, so assuming the kde app won't run, again, it could
> be quite useful to compare against doing the same thing on a working
> system, so you have some idea what lines in the output are simply noise
> and not useful for troubleshooting.
>
> If normal kde apps do work, you can borrow a trick I used back when I was
> upgrading from kde3 to kde4. Run a bit more and a bit more of kde4, until
> there's little left that's NOT running. plasma-desktop is the kde4
> desktop shell. You can try running that. And you can run kwin, replacing
> whatever window manager you were using in the non-kde environment, using
> kwin --replace. If both kwin and plasma-desktop run without issue... it's
> something pretty core to kde, indeed!
>
> And if kde apps do NOT work, what about qt4 but NOT kde apps? To test
> that, you'll need a non-kde but qt4 app. I only use a couple here, one
> rather specialized (qmpdclient, a qt-based mpd front-end), the other
> rather... large and possibly lots of dependencies if you don't have mplayer
> installed (smplayer, a power-user qt-based mplayer front-end similar to
> what kaffeine was for xine in kde3... the kde4 kaffeine wasn't even close,
> last time I checked, tho that was kde 4.3 era I believe so a couple years
> ago), so you may have to search for one, but if you already have mplayer
> installed, smplayer shouldn't be /too/ bad, dependency-wise.
>
>
Thanks for putting so much thought into this for me.
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
