This bug is fixed in git. It was a libart issue. Will be there in R14
> I've just completed a TDE build from
> scratch on a fresh Debian Wheezy system, from the stable
> source.
>
> There were a number of issues to do with the source, which
> I'll document separately, in case it's useful to others.
>
> One problem that I have so far found with the resulting
> installation is 'kicker' crashing when attempting to select
> the 'System' sub menu option. In more detail, using the
> mouse to select 'K Menu' and then moving the mouse pointer
> to the 'System' entry in the upper, 'All Applications'
> portion of the menu, _always_ results in a crash, bringing
> up the 'KDE Panel - The KDE Crash Handler' dialog box.
>
> Any body any ideas?
>
> Is there a way to determine what, if any, options should be
> available on the sub menu on this system? Obviously there
> will be different options available on different systems.
> Maybe it's crashing cos it's empty.
I seem to recall similar reports a while back. I thought those bugs were resolved. You might want to check the bugzilla. Maybe also check the web for similar bugs with KDE3.
Just a side thought: if you build local development/testing packages with debugging enabled, then you'll be able to produce backtraces for the gurus to evaluate. I use the following in my master build script:
if [ "$DEBUG" = "true" ]; then
DEBUG_AUTOTOOL_OPT="--enable-debug=full"
DEBUG_CMAKE_OPT="-ggdb"
else
DEBUG_AUTOTOOL_OPT="--disable-debug"
DEBUG_CMAKE_OPT=""
fi
export DEBUG_CMAKE_OPT
export DEBUG_AUTOTOOL_OPT
The individual package build scripts look like this:
cmake:
cmake
...
-DCMAKE_CXX_FLAGS:STRING="$CPUOPT $DEBUG_CMAKE_OPT" \
...
auomake:
./configure \
...
$DEBUG_AUTOTOOL_OPT \
...
I enable $DEBUG to true as the default and can override when wanted. When I post packages for other people, I create separate debugging symbol packages. For local testing purposes, the debugging symbols can remain a part of the overall package.
Debugging support makes much larger packages, but is more useful for testing, which I think all developers and packagers should be using with unofficial packages. :)
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net
Read list messsages on the Web archive: http://trinity-users.pearsoncomputing.net/
Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting