KDE apps crash
Duncan
1i5t5.duncan at cox.net
Thu Sep 12 20:01:13 BST 2013
P NIKOLIC posted on Thu, 12 Sep 2013 08:33:22 +0100 as excerpted:
> On Wed, 11 Sep 2013 10:46:44 +0000 (UTC)
> Duncan <1i5t5.duncan at cox.net> wrote:
>
>> P NIKOLIC posted on Wed, 11 Sep 2013 08:44:16 +0100 as excerpted:
>>
>> > On Wed, 11 Sep 2013 08:32:55 +0100 P NIKOLIC
>> > <p.nikolic1 at btinternet.com>
>> > wrote:
>> >
>> >> I have recently updated KDE to 4.11.1 on Arch Linux .
>> >>
>> >> Prior to the update almost everything worked fine now almost every
>> >> KDE application i attempt to run crashes instantly including the
>> >> Kcrash handler
>> >> all crash every time you try to start them that is just the few
>> >> quick ones but it happens to almost everything ( gtk based apps
>> >> not effected )
>> >>
> If i have the internet bandwidth i might have had a look at Gentoo but i
> am Dongal based so it makes it a non starter.
That would be a problem, indeed.
Tho I'm not actually sure how much more bandwidth gentoo would, as long
as you run stable so don't have the churn of ~arch updates, don't run
"deep" updates so deep dependencies are updated only when the current
version is masked or insufficient for something else you have installed,
and perhaps limit updates to say once a month or so. Even if the
tarballed sources take more bandwidth than the binary packages, they're
cached, and gentoo updates when the upstream version remains the same
will re-use the cached sources. Additionally, because compile-time
optional dependencies are exposed as USE flags and can be turned off, a
lot of otherwise unused dependencies don't need pulled in at all, saving
that bandwidth entirely.
However, I couldn't blame anyone running older systems, say a single-core
and/or under a gig of RAM, for not wishing to run gentoo. When I started
on gentoo (over a decade ago, before dual-cores) I had a dual socket
system, two (single-core) Opteron CPUs, and a gig of RAM. That was
doable, but it was a reasonably high-end system at the time, and I
honestly had quite a bit of respect for the single-core folks doing
gentoo, as I'm not sure I'd have stuck with it in that case.
Also, of course if you can share an Arch DVD or just the downloaded
updates with other users, and would be the only one on gentoo if you
chose it, I can see how that'd encourage sticking with what you can
share, too.
Regardless, I'm not a "distro bigot". While I don't believe there's a
better match for me than gentoo, I recognize it's not for everyone, for
any number of reasons. If it's not for you, good for you recognizing
that fact and choosing something that is! =:^)
>> Such crashes are very likely due to one of three things: Either your
>> user's kde config is screwed up, or you have an incompatible or missing
>> library, likely due to bad dependencies in the binary package you
>> installed, or if you compiled from source, probably due to one of the
>> depended libs in turn needing an incompatible library, conflicting with
>> the one kde itself was compiled against. The third possibility, as
>> reported by someone else on the list, is [dbus].
>> It's easy to rule out your user's kde config. Try a clean config.
> Tied that one several times no go .
That possibility eliminated...
>> Assuming a clean user config doesn't fix the problem, the next thing to
>> figure out is whether it's a qt library, a kde library, or something
>> lower in the system but used by pretty much anything kde that whoever
>> built that kde might have had a different version of, since you know
>> that gtk apps aren't affected.
>>
>> One simple and quick check is using ldd
> Cant find any missing libs , everything seems to be ok
Wasn't likely anyway, but would have been a simple fix if that were it.
>> If that comes up clean, then it's time to dig a bit further. Do you
>> know if you have any non-kde qt4-only apps on your system? SMPlayer
>> (or smplayer2, is one I have here, and another one is the kernel's
>> xconfig, invoked as make xconfig from within the kernel sources dir,
>> tho the actual binary is scripts/kconfig/qconf (you can ldd it as well
>> for a comparison, once it's created by the first make xconfig run).
>
> Other that Firefox Claws-mail Gftp and Bluefish which i always use
> and have been on every install for ages ,Everything else is native
> Arch Linux repo stuff all 64 bit .Oh and Barry Backup i believe it is
> a QT app for the Blackberry phone that runs ok .
No, barry is gtk and wxwidget based, not qt. I just checked the master
list of deps, here:
http://www.netdirect.ca/software/packages/barry/dependencies.php
Firefox, claws-mail and gftp are gtk-based also. As is bluefish, which I
had to check.
>> If a qt4-only app runs, then it's likely something wrong with kde
>> itself, or one of its mostly kde-only non-qt deps such as strigi or
>> nepomuk. If a qt4-only app doesn't run, then it's likely a qt4 issue.
>
> Now i wonder if that is possible all that is turned off i dont use it at
> all , now id it IS then the issue is how the *&^%^&** do you turn it
> back on when System settings will not run and dies the same as
> everything else
Turning it on and off wouldn't be the issue, as kde can run without it
on. The issue would be whether the libraries are compatible, because if
kde's built against them (the semantic-desktop stuff is a build-time
option that's turned off here altho strigi itself is still required to
build, and altho gentoo/kde recently forced it on, I generated ebuild
patches based on older gentoo/kde ebuilds versions that didn't require it
and apply them so as to continue to build entirely without it), they'll
need to be compatible even if the feature is turned off at run-time.
> Pity it is not to easy to go back to the working version of KDE ..
Indeed.
(On gentoo it's possible, even easy if you're saving off the binpkgs as
they are built and still have the old one around so you don't have to
rebuild it -- and I always keep the old package available at least until
I know the new one is working. Tho for kde I'm running 4.11 live-branch,
updating from git sources, and those overwrite the old ones, but 4.11 is
stable branch not development head, and I can always revert to an older
git commit if I need to. But you're not on gentoo, so...)
If I'm correct in my incompatible library hypothesis, however, eventually
the deps should be fixed and an update should solve your problem then,
but waiting isn't easy, for sure.
Meanwhile, as long as you still have the older packages saved somewhere
(as I already said I generally do here on gentoo), it should be possible
to revert, tho it may not be "easy".
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
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.
More information about the kde
mailing list