Just and fyi, haven't had much chance to look more, but kde-4.0.98 (built for F-9 here), falls over with many-a-error of the form: kdeinit4: preparing to launch /usr/libexec/kde4/klauncher ASSERT: "d" in file /builddir/build/BUILD/kdelibs-4.0.98/kdecore/kernel/kcomponentdata.cpp, line 158 kdeinit4: (klauncher /usr/libexec/kde4/klauncher) Pipe closed unexpectedlykdeinit4: Pipe closed unexpectedly: No such file or director
Argh, sounds badly broken!
The context: 156 KStandardDirs *KComponentData::dirs() const 157 { 158 Q_ASSERT(d); 159 d->lazyInit(*this); 160 161 return d->dirs; 162 } The code of KComponentData hasn't changed since September 2007. I think we need a backtrace for this assertion failure.
Confirmed going back to kde-4.0.85 is ok, so seems to be something particular to 4.0.98. I'm tempted to try rebuilding everything again, to confirm it's just not a quirk in my own builds (at least until we have any confirmation of folks seeing this on rawhide too). Once I confirm that, I'll get to work on getting a backtrace. Fwiw, the 4.0.98 F-9 builds I'm using here are currently in repos at http://apt.kde-redhat.org/apt/kde-redhat/mock/fedora-9-i386-kde/ http://apt.kde-redhat.org/apt/kde-redhat/mock/fedora-9-x86_64-kde/
How most folks will experience this is that login will fail with error: can not start ksmserver
I've confirmed that a kdelibs build omitting our nocache and kstandarddirs patches still exhibits this problem (so I'm hoping that means that those patches don't contribute to it).
Any chance you can get a stack trace for that? It might help figuring out what's going wrong.
(For those who haven't followed the discussion on IRC: I have fixed this in 4.0.98-2.fc10 by reverting a recent kinit change which triggered this bug, but I think the kinit change was only uncovering a latent bug and want the real issue to be fixed.)
I just committed a clean fix in 4.1.1-2. Details forthcoming in an upstream bug report.
Upstream bug report: https://bugs.kde.org/show_bug.cgi?id=170043