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.
Cheers, Mike.
--
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
This bug is fixed in git. It was a libart issue. Will be there in R14 On Jan 14, 2012 1:22 PM, "Darrell Anderson" humanreadable@yahoo.com wrote:
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
On 01/14/2012 10:38 AM, Calvin Morrison wrote:
This bug is fixed in git. It was a libart issue. Will be there in R14
I have the same problem on 2 different machines -- the only 2 installs of 3.5.13 I've done so far -- and it's been reported on the list at least twice since then. So I think it must be a common problem that lots of folks run into. I haven't tried the patch yet, but am about to do so.
But most who get to the website, install Trinity, and have this problem won't know there's a patch -- they'll just see a great big bug that's still there, and uninstall Trinity and never try it again. So I think it's a really bad idea to leave it unfixed until R14.
On 14/01/2012 19:22, Dan Youngquist wrote:
On 01/14/2012 10:38 AM, Calvin Morrison wrote:
This bug is fixed in git. It was a libart issue. Will be there in R14
I have the same problem on 2 different machines -- the only 2 installs of 3.5.13 I've done so far -- and it's been reported on the list at least twice since then. So I think it must be a common problem that lots of folks run into. I haven't tried the patch yet, but am about to do so.
But most who get to the website, install Trinity, and have this problem won't know there's a patch -- they'll just see a great big bug that's still there, and uninstall Trinity and never try it again. So I think it's a really bad idea to leave it unfixed until R14.
Ok, guys, thanks for the info. I probably should have searched a bit more before posting.
I'll track down the patch and see how things go.
On 01/14/2012 11:28 AM, Mike Howard wrote:
I'll track down the patch and see how things go.
Laurent Dard's instructions for the patch are here:
http://trinity-users.pearsoncomputing.net/?0::1948
On 01/14/2012 11:28 AM, Mike Howard wrote:
I'll track down the patch and see how things go.
Laurent Dard's instructions for the patch are here:
Even easier is to pull the fixed libart package from this link: https://quickbuild.pearsoncomputing.net/~trinity/+archive/trinity-nightly-bu...
Fair warning: do NOT try to use anything ese in that PPA on anything other than a test system. Just pull the appropriate libart .deb for your system, install it, and keep going. ;-)
If I get reports that this truly fixes the problem, and does not introduce any other problems, then I will update the 3.5.13 PPA for Debian and Ubuntu with the new library.
Tim
On 01/14/2012 11:37 AM, Timothy Pearson wrote:
Even easier is to pull the fixed libart package from this link: https://quickbuild.pearsoncomputing.net/~trinity/+archive/trinity-nightly-bu...
Yep, that's definitely easier. :)
If I get reports that this truly fixes the problem, and does not introduce any other problems, then I will update the 3.5.13 PPA for Debian and Ubuntu with the new library.
Doesn't fix it. Problem still there. Kicker still crashes on Settings and System menus.
On 01/14/2012 11:37 AM, Timothy Pearson wrote:
Even easier is to pull the fixed libart package from this link: https://quickbuild.pearsoncomputing.net/~trinity/+archive/trinity-nightly-bu...
Yep, that's definitely easier. :)
If I get reports that this truly fixes the problem, and does not introduce any other problems, then I will update the 3.5.13 PPA for Debian and Ubuntu with the new library.
Doesn't fix it. Problem still there. Kicker still crashes on Settings and System menus.
I assume you have restarted your machine? That library is a base system library that can stay cached in memory for some time after an upgrade...
If it still crashes please grab a backtrace.
Thanks!
Tim
On 01/14/2012 12:17 PM, Timothy Pearson wrote:
I assume you have restarted your machine?
Yep.. Twice now. :)
If it still crashes please grab a backtrace.
Can't. Crash handler says: "This backtrace appears to be of no use. This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash."
I'm going to wipe that machine and reinstall, as it needs to work now, and may or may not be able to provide answers from the other one with the problem before Monday. So if you need more details, hopefully someone else can provide them before that.
On 01/14/2012 12:17 PM, Timothy Pearson wrote:
I assume you have restarted your machine?
Yep.. Twice now. :)
If it still crashes please grab a backtrace.
Can't. Crash handler says: "This backtrace appears to be of no use. This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash."
Ubuntu Maverick or higher? The reason I ask is that Ubuntu locked down GDB from working as a normal user; see http://askubuntu.com/a/41656
Also, you will need the debugging symbol package kdebase-trinity-dbg installed for the backtrace to be of any use.
Tim
On Saturday 14 January 2012 10:22:22 am Dan Youngquist wrote:
On 01/14/2012 10:38 AM, Calvin Morrison wrote:
This bug is fixed in git. It was a libart issue. Will be there in R14
I have the same problem on 2 different machines -- the only 2 installs of 3.5.13 I've done so far -- and it's been reported on the list at least twice since then. So I think it must be a common problem that lots of folks run into. I haven't tried the patch yet, but am about to do so.
But most who get to the website, install Trinity, and have this problem won't know there's a patch -- they'll just see a great big bug that's still there, and uninstall Trinity and never try it again. So I think it's a really bad idea to leave it unfixed until R14.
The OP was building from source on a Wheezy system, this IS different than a user visiting the TDE website & installing the binaries on a Wheezy system.
AFAIK, TDE3.5.13 is compiled on a Squeeze box, for the Debian stuff, and I would not expect them to necessarily work 100% on Wheezy. The install instructions are for Lenny & Squeeze.
I have tested TDE3..5..13 & Wheezy in a Vbox instance and would not want to use on my production boxes.
Caveat, I don't think running a Wheezy guest on a Squeeze host is a valid test though. To many kernel & Xorg cahnges, to name a few, some stuff just won't work.
On 01/14/2012 01:30 PM, Greg Madden wrote:
The OP was building from source on a Wheezy system, this IS different than a user visiting the TDE website& installing the binaries on a Wheezy system.
Both of my occurrences of the problem were clean, fresh Ubuntu Oneiric installs.
On Saturday 14 January 2012 10:22:22 am Dan Youngquist wrote:
On 01/14/2012 10:38 AM, Calvin Morrison wrote:
This bug is fixed in git. It was a libart issue. Will be there in R14
I have the same problem on 2 different machines -- the only 2 installs of 3.5.13 I've done so far -- and it's been reported on the list at least twice since then. So I think it must be a common problem that lots of folks run into. I haven't tried the patch yet, but am about to do so.
But most who get to the website, install Trinity, and have this problem won't know there's a patch -- they'll just see a great big bug that's still there, and uninstall Trinity and never try it again. So I think it's a really bad idea to leave it unfixed until R14.
The OP was building from source on a Wheezy system, this IS different than a user visiting the TDE website & installing the binaries on a Wheezy system.
AFAIK, TDE3.5.13 is compiled on a Squeeze box, for the Debian stuff, and I would not expect them to necessarily work 100% on Wheezy. The install instructions are for Lenny & Squeeze.
I have tested TDE3..5..13 & Wheezy in a Vbox instance and would not want to use on my production boxes.
Caveat, I don't think running a Wheezy guest on a Squeeze host is a valid test though. To many kernel & Xorg cahnges, to name a few, some stuff just won't work.
My experience with Wheezy in a full VM has been terrible. Too much instability in core system libs--I strongly recommend that TDE users DO NOT UPGRADE TO WHEEZY unless they are prepared to lose access to TDE (and other software packages) until Wheezy is marked as stable.
Tim
On 14/01/2012 21:41, Timothy Pearson wrote:
On Saturday 14 January 2012 10:22:22 am Dan Youngquist wrote:
On 01/14/2012 10:38 AM, Calvin Morrison wrote:
This bug is fixed in git. It was a libart issue. Will be there in R14
I have the same problem on 2 different machines -- the only 2 installs of 3.5.13 I've done so far -- and it's been reported on the list at least twice since then. So I think it must be a common problem that lots of folks run into. I haven't tried the patch yet, but am about to do so.
But most who get to the website, install Trinity, and have this problem won't know there's a patch -- they'll just see a great big bug that's still there, and uninstall Trinity and never try it again. So I think it's a really bad idea to leave it unfixed until R14.
The OP was building from source on a Wheezy system, this IS different than a user visiting the TDE website& installing the binaries on a Wheezy system.
AFAIK, TDE3.5.13 is compiled on a Squeeze box, for the Debian stuff, and I would not expect them to necessarily work 100% on Wheezy. The install instructions are for Lenny& Squeeze.
I have tested TDE3..5..13& Wheezy in a Vbox instance and would not want to use on my production boxes.
Caveat, I don't think running a Wheezy guest on a Squeeze host is a valid test though. To many kernel& Xorg cahnges, to name a few, some stuff just won't work.
My experience with Wheezy in a full VM has been terrible. Too much instability in core system libs--I strongly recommend that TDE users DO NOT UPGRADE TO WHEEZY unless they are prepared to lose access to TDE (and other software packages) until Wheezy is marked as stable.
I'm a little confused now so please bear with me, or just ignore me as you choose :)
I'm not at all sure where libart comes into my equation. I have libart-2.0-2 & libart-2.0-dev installed on my system, as debs, but not libart-lgpl. Nor does libart-lgpl appear in the stable sources, except as an almost empty sub-folder of konstruct/libs or in apt on either Squeeze or Wheezy.
So, as a layman, what am I missing? I did say I was confused.
From a Wheezy point of view, yes, it's not marked as stable, but waiting for debian stable is like waiting for a bus on a Sunday. Besides, having experienced this build from source of 3.5.13, being marked as stable doesn't mean it really is stable. No insult or slight intended :)
Cheers, Mike.
--
On 14/01/2012 22:09, Mike Howard wrote:
On 14/01/2012 21:41, Timothy Pearson wrote:
On Saturday 14 January 2012 10:22:22 am Dan Youngquist wrote:
On 01/14/2012 10:38 AM, Calvin Morrison wrote:
This bug is fixed in git. It was a libart issue. Will be there in R14
I have the same problem on 2 different machines -- the only 2 installs of 3.5.13 I've done so far -- and it's been reported on the list at least twice since then. So I think it must be a common problem that lots of folks run into. I haven't tried the patch yet, but am about to do so.
But most who get to the website, install Trinity, and have this problem won't know there's a patch -- they'll just see a great big bug that's still there, and uninstall Trinity and never try it again. So I think it's a really bad idea to leave it unfixed until R14.
The OP was building from source on a Wheezy system, this IS different than a user visiting the TDE website& installing the binaries on a Wheezy system.
AFAIK, TDE3.5.13 is compiled on a Squeeze box, for the Debian stuff, and I would not expect them to necessarily work 100% on Wheezy. The install instructions are for Lenny& Squeeze.
I have tested TDE3..5..13& Wheezy in a Vbox instance and would not want to use on my production boxes.
Caveat, I don't think running a Wheezy guest on a Squeeze host is a valid test though. To many kernel& Xorg cahnges, to name a few, some stuff just won't work.
My experience with Wheezy in a full VM has been terrible. Too much instability in core system libs--I strongly recommend that TDE users DO NOT UPGRADE TO WHEEZY unless they are prepared to lose access to TDE (and other software packages) until Wheezy is marked as stable.
I'm a little confused now so please bear with me, or just ignore me as you choose :)
I'm not at all sure where libart comes into my equation. I have libart-2.0-2 & libart-2.0-dev installed on my system, as debs, but not libart-lgpl. Nor does libart-lgpl appear in the stable sources, except as an almost empty sub-folder of konstruct/libs or in apt on either Squeeze or Wheezy.
Or does libart-lgpl produce libart-2.0-2 & libart-2.0-dev? Figured that once Tim's link actually opened. Sorry.
On Saturday 14 January 2012 22:09:28 Mike Howard wrote:
From a Wheezy point of view, yes, it's not marked as stable, but waiting for debian stable is like waiting for a bus on a Sunday. Besides, having experienced this build from source of 3.5.13, being marked as stable doesn't mean it really is stable. No insult or slight intended :)
3.5.13 is not intended for Wheezy, so will not work on it. It is at least reasonably stable on Squeeze. (I haven't been running it long enough nor used it often enough to vouch for complete stability!)
Lisi
On 14/01/2012 22:17, Lisi wrote:
On Saturday 14 January 2012 22:09:28 Mike Howard wrote:
From a Wheezy point of view, yes, it's not marked as stable, but waiting for debian stable is like waiting for a bus on a Sunday. Besides, having experienced this build from source of 3.5.13, being marked as stable doesn't mean it really is stable. No insult or slight intended :)
3.5.13 is not intended for Wheezy, so will not work on it. It is at least reasonably stable on Squeeze. (I haven't been running it long enough nor used it often enough to vouch for complete stability!)
Intended? Debian wasn't intended for lots of devices but has replaced the original OS in many of them. I just want to stick with TDE _and_ want to go with Wheezy.. I can, and have, installed the debs from the Squeeze repository onto a Wheezy box. I'm not in the blame game here, I'm just trying to achieve my goals whilst learning as much as possible along the way.
Cheers, Mike.
--
On Saturday 14 January 2012 22:21:45 Mike Howard wrote:
On 14/01/2012 22:17, Lisi wrote:
On Saturday 14 January 2012 22:09:28 Mike Howard wrote:
From a Wheezy point of view, yes, it's not marked as stable, but waiting for debian stable is like waiting for a bus on a Sunday. Besides, having experienced this build from source of 3.5.13, being marked as stable doesn't mean it really is stable. No insult or slight intended :)
3.5.13 is not intended for Wheezy, so will not work on it. It is at least reasonably stable on Squeeze. (I haven't been running it long enough nor used it often enough to vouch for complete stability!)
Intended? Debian wasn't intended for lots of devices but has replaced the original OS in many of them. I just want to stick with TDE _and_ want to go with Wheezy.. I can, and have, installed the debs from the Squeeze repository onto a Wheezy box. I'm not in the blame game here, I'm just trying to achieve my goals whilst learning as much as possible along the way.
Whilst accusing TDE of not being stable:
<quote>
Besides, having experienced this build from source of 3.5.13, being marked as stable doesn't mean it really is stable. No insult or slight intended :)
</quote>
Lisi
On 15/01/2012 07:05, Lisi wrote:
On Saturday 14 January 2012 22:21:45 Mike Howard wrote:
On 14/01/2012 22:17, Lisi wrote:
On Saturday 14 January 2012 22:09:28 Mike Howard wrote:
From a Wheezy point of view, yes, it's not marked as stable, butwaiting for debian stable is like waiting for a bus on a Sunday. Besides, having experienced this build from source of 3.5.13, being marked as stable doesn't mean it really is stable. No insult or slight intended :)
3.5.13 is not intended for Wheezy, so will not work on it. It is at least reasonably stable on Squeeze. (I haven't been running it long enough nor used it often enough to vouch for complete stability!)
Intended? Debian wasn't intended for lots of devices but has replaced the original OS in many of them. I just want to stick with TDE _and_ want to go with Wheezy.. I can, and have, installed the debs from the Squeeze repository onto a Wheezy box. I'm not in the blame game here, I'm just trying to achieve my goals whilst learning as much as possible along the way.
Whilst accusing TDE of not being stable:
<quote> >>> Besides, having experienced this build from source of 3.5.13, being >>> marked as stable doesn't mean it really is stable. No insult or slight >>> intended :) </quote>
.. and my quote is correct, but I never stated that TDE was unstable. However, the _stable_ source isn't _stable_ in my view. Let me list some examples which are extant regardless of whether I'm using Wheezy or Squeeze;
1. avahi-tqt will not build;
make all-recursive make[1]: Entering directory `/data/build.0/avahi-tqt' Making all in avahi-tqt make[2]: Entering directory `/data/build.0/avahi-tqt/avahi-tqt' GEN qt-watch.moc3 Qt meta object compiler moc: Too many input files specified Usage: moc [options] <header-file> -o file Write output to file rather than stdout -f[file] Force #include, optional file name -p path Path prefix for included file -i Do not generate an #include statement -k Do not stop on errors -nw Do not display warnings -v Display version of moc make[2]: *** [qt-watch.moc3] Error 1 make[2]: Leaving directory `/data/build.0/avahi-tqt/avahi-tqt' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/data/build.0/avahi-tqt' make: *** [all] Error 2
... same every time.
2. kipi-plugins source requires patching before it will build.
3. aKode source not present but needed.
4. kdeadmin fails to build because it finds and uses the TDE installed dummy header, knetworkinterface.h, instead of it's own version. kpPty.cpp explicitly includes the system installed utils.h instead of it's own version.
5. kdevelop fails to build because the autogenerated listeditor.ui.h file includes a reference to App which should be tqApp.
and there's more.
Anyway, I'm not complaining just learning.
Mike.
--
.. and my quote is correct, but I never stated that TDE was unstable. However, the _stable_ source isn't _stable_ in my view. Let me list some examples which are extant regardless of whether I'm using Wheezy or Squeeze;
- avahi-tqt will not build;
make all-recursive make[1]: Entering directory `/data/build.0/avahi-tqt' Making all in avahi-tqt make[2]: Entering directory `/data/build.0/avahi-tqt/avahi-tqt' GEN qt-watch.moc3 Qt meta object compiler moc: Too many input files specified Usage: moc [options] <header-file> -o file Write output to file rather than stdout -f[file] Force #include, optional file name -p path Path prefix for included file -i Do not generate an #include statement -k Do not stop on errors -nw Do not display warnings -v Display version of moc make[2]: *** [qt-watch.moc3] Error 1 make[2]: Leaving directory `/data/build.0/avahi-tqt/avahi-tqt' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/data/build.0/avahi-tqt' make: *** [all] Error 2
... same every time.
- kipi-plugins source requires patching before it will
build.
aKode source not present but needed.
kdeadmin fails to build because it finds and uses the
TDE installed dummy header, knetworkinterface.h, instead of it's own version. kpPty.cpp explicitly includes the system installed utils.h instead of it's own version.
- kdevelop fails to build because the autogenerated
listeditor.ui.h file includes a reference to App which should be tqApp.
and there's more.
Anyway, I'm not complaining just learning.
Mike, join the club with respect to learning. :) I joined this project before 3.5.12 was released. I have learned much! Part of the learning has been a challenge. At times frustrating. Yet I am learning leaps and bounds. I'm teaching myself C++ right now. Of late I am learning a thing or two about how cmake works. Although I have only superficial knowledge of C++, I have submitted more than a few patches. I think I am actually having fun, but am too old and stubborn to admit as much. ;)
I'll add some observations that help me. None of these thoughts are directed to you. I'm just rambling out loud.
* Software is a moving target. Frustratingly so. Testing known stable software in a known untested or unstable environment, means shouldering the responsibility to find solutions. Ask questions like crazy but let others know that they are not the crazy one. :)
* Always check the bugzilla before posting bug or build related questions.
* Always check the web before posting bug or build related questions.
* Ask, ask, ask.
* There are only a few people working to keep Trinity going. That can be frustrating at times so I always "count to 10" before posting anything to the lists. We all have lives, families, responsibilities. We all need a large dose of patience to keep this project running.
* If no solutions, then post a bug report or enhancement request. I do. Often. :)
* Everybody involved is a creature of limited knowledge. That is a hard lesson I learned about life in general. We can't assume everybody knows, even subject matter experts don't know everything. When things arise like akode not being in the repository, just ask. Chances are that adding the package is as simple as asking.
* Trinity is a continuation of the KDE3 desktop style. Packages that were not part of the original KDE3 package suite need to be added to the Trinity repository.
* Many of us use different distros. That means each of us tests according to our limited perceptions of how our distro works. (See --- we all are creatures of limited knowledge. :) ) That means some features don't get built or tested by others. Recently Tim has been adding a WITH_ALL_OPTIONS to the cmake converted packages. That is good because everybody involved should use that option at least a few times to test the overall build process, even when they don't want to use all features for their distro.
* Occasionally a build feature or two will slip through the proverbial cracks with an automake to cmake conversion. Just let everybody know. An example is the current discussion about FAM/GAMIN support missing in kdelibs. Remember that everybody is a creature of limited knowledge and these things will happen.
Oh, I almost forgot --- with respect to some of the build errors you just shared, the bugs about kipi-plugins and kdevelop have patches in the bugzilla. :) I had better get off my soap box now.
Darrell
On 15/01/2012 18:31, Darrell Anderson wrote:
<snip> Anyway, I'm not complaining just learning.
Mike, join the club with respect to learning. :) I joined this project before 3.5.12 was released. I have learned much! Part of the learning has been a challenge. At times frustrating. Yet I am learning leaps and bounds. I'm teaching myself C++ right now. Of late I am learning a thing or two about how cmake works. Although I have only superficial knowledge of C++, I have submitted more than a few patches. I think I am actually having fun, but am too old and stubborn to admit as much. ;)
I'll add some observations that help me. None of these thoughts are directed to you. I'm just rambling out loud.
Software is a moving target. Frustratingly so. Testing known stable software in a known untested or unstable environment, means shouldering the responsibility to find solutions. Ask questions like crazy but let others know that they are not the crazy one. :)
Always check the bugzilla before posting bug or build related questions.
Always check the web before posting bug or build related questions.
Ask, ask, ask.
There are only a few people working to keep Trinity going. That can be frustrating at times so I always "count to 10" before posting anything to the lists. We all have lives, families, responsibilities. We all need a large dose of patience to keep this project running.
If no solutions, then post a bug report or enhancement request. I do. Often. :)
Everybody involved is a creature of limited knowledge. That is a hard lesson I learned about life in general. We can't assume everybody knows, even subject matter experts don't know everything. When things arise like akode not being in the repository, just ask. Chances are that adding the package is as simple as asking.
Trinity is a continuation of the KDE3 desktop style. Packages that were not part of the original KDE3 package suite need to be added to the Trinity repository.
Many of us use different distros. That means each of us tests according to our limited perceptions of how our distro works. (See --- we all are creatures of limited knowledge. :) ) That means some features don't get built or tested by others. Recently Tim has been adding a WITH_ALL_OPTIONS to the cmake converted packages. That is good because everybody involved should use that option at least a few times to test the overall build process, even when they don't want to use all features for their distro.
Occasionally a build feature or two will slip through the proverbial cracks with an automake to cmake conversion. Just let everybody know. An example is the current discussion about FAM/GAMIN support missing in kdelibs. Remember that everybody is a creature of limited knowledge and these things will happen.
Oh, I almost forgot --- with respect to some of the build errors you just shared, the bugs about kipi-plugins and kdevelop have patches in the bugzilla. :) I had better get off my soap box now.
Darrell
All valid points Darrell, thanks for sharing. As I said, I really am not complaining, I'm actually enjoying struggling through the process, because I am learning.
I have been going round in circles it seems, probably because of a failure on my part to document what I've done along the way.
I was hoping to provide Tim with a backtrace but because I hadn't installed the various debugging capabilities of qt, kdelibs and kdebase I decided to rebuild and reinstall but ended up in the situation I was a number of days ago whereby kdelibs would not build. Anyway, hopefully that has just been caused by my ignorance (mixing QT/TQT, stable/unstable etc) and I'll get it sorted tonight.
Cheers, Mike.
--
I'm a little confused now so please bear with me, or just ignore me as you choose :)
I'm not at all sure where libart comes into my equation. I have libart-2.0-2 & libart-2.0-dev installed on my system, as debs, but not libart-lgpl. Nor does libart-lgpl appear in the stable sources, except as an almost empty sub-folder of konstruct/libs or in apt on either Squeeze or Wheezy.
So, as a layman, what am I missing? I did say I was confused.
libart-2.0-2 is what you want installed, but it should be installed from the link that I posted earlier in this thread. Older versions of this package can cause a SIGABRT (a crash in layman's terms) due to a bug in this library.
From a Wheezy point of view, yes, it's not marked as stable, but waiting for debian stable is like waiting for a bus on a Sunday. Besides, having experienced this build from source of 3.5.13, being marked as stable doesn't mean it really is stable. No insult or slight intended :)
None taken. I can only say that in my experience, Squeeze is rock solid (with TDE as well), whereas Wheezy won't even compile TDE completely on armel due to mysterious segfaults in (non-TDE) core libraries. Additionally, Wheezy has some other problems that manifest as a lockup of build chroots. I have had it with Wheezy for now and won't support TDE on Wheezy until Debian at least has the guts to mark it stable. :-)
And I fully understand that Stable isn't always stable, but at least instability reports will be taken seriously after that moniker is applied.
I have personally experienced the frustration of waiting for Debian releases (hence my usage of Ubuntu on most of my servers), so I can understand why people are trying to "jump the gun" and use Wheezy before it is ready. On the other hand TDE has enough problems (just due to its size and complexity) that I don't need to be fighting prerelease distribution-specific problems on top of the bugs in the TDE source.
Tim
On 14/01/2012 22:22, Timothy Pearson wrote:
I'm a little confused now so please bear with me, or just ignore me as you choose :)
I'm not at all sure where libart comes into my equation. I have libart-2.0-2& libart-2.0-dev installed on my system, as debs, but not libart-lgpl. Nor does libart-lgpl appear in the stable sources, except as an almost empty sub-folder of konstruct/libs or in apt on either Squeeze or Wheezy.
So, as a layman, what am I missing? I did say I was confused.
libart-2.0-2 is what you want installed, but it should be installed from the link that I posted earlier in this thread. Older versions of this package can cause a SIGABRT (a crash in layman's terms) due to a bug in this library.
From a Wheezy point of view, yes, it's not marked as stable, but waiting for debian stable is like waiting for a bus on a Sunday. Besides, having experienced this build from source of 3.5.13, being marked as stable doesn't mean it really is stable. No insult or slight intended :)
None taken. I can only say that in my experience, Squeeze is rock solid (with TDE as well), whereas Wheezy won't even compile TDE completely on armel due to mysterious segfaults in (non-TDE) core libraries. Additionally, Wheezy has some other problems that manifest as a lockup of build chroots. I have had it with Wheezy for now and won't support TDE on Wheezy until Debian at least has the guts to mark it stable. :-)
And I fully understand that Stable isn't always stable, but at least instability reports will be taken seriously after that moniker is applied.
I have personally experienced the frustration of waiting for Debian releases (hence my usage of Ubuntu on most of my servers), so I can understand why people are trying to "jump the gun" and use Wheezy before it is ready. On the other hand TDE has enough problems (just due to its size and complexity) that I don't need to be fighting prerelease distribution-specific problems on top of the bugs in the TDE source.
Thanks Tim, for your reply & your efforts on this excellent project. I agree, TDE is rock solid on Squeeze and I'm happy to continue using it, I just wanted to try TDE on Wheezy. I do not expect support, though will willingly accept it, and to those kind people who are willing to respond to my posts I am very grateful.
Thanks to all who contribute.
Cheers, Mike.
--
On 14/01/2012 22:30, Mike Howard wrote:
On 14/01/2012 22:22, Timothy Pearson wrote:
I'm a little confused now so please bear with me, or just ignore me as you choose :)
I'm not at all sure where libart comes into my equation. I have libart-2.0-2& libart-2.0-dev installed on my system, as debs, but not libart-lgpl. Nor does libart-lgpl appear in the stable sources, except as an almost empty sub-folder of konstruct/libs or in apt on either Squeeze or Wheezy.
So, as a layman, what am I missing? I did say I was confused.
libart-2.0-2 is what you want installed, but it should be installed from the link that I posted earlier in this thread. Older versions of this package can cause a SIGABRT (a crash in layman's terms) due to a bug in this library.
From a Wheezy point of view, yes, it's not marked as stable, but waiting for debian stable is like waiting for a bus on a Sunday. Besides, having experienced this build from source of 3.5.13, being marked as stable doesn't mean it really is stable. No insult or slight intended :)
None taken. I can only say that in my experience, Squeeze is rock solid (with TDE as well), whereas Wheezy won't even compile TDE completely on armel due to mysterious segfaults in (non-TDE) core libraries. Additionally, Wheezy has some other problems that manifest as a lockup of build chroots. I have had it with Wheezy for now and won't support TDE on Wheezy until Debian at least has the guts to mark it stable. :-)
Sorry, forgot to say, on amd64, TDE, from stable has compiled (after sorting minor issues) and apart from the kicker crash is fine, or at least appears so for now. As for armel issues, from a user point of view I have never used a desktop environment on an ARM linux system but I would love to see see TDE on ARM.
Cheers,
--
Thanks Tim, for your reply & your efforts on this excellent project. I agree, TDE is rock solid on Squeeze and I'm happy to continue using it, I just wanted to try TDE on Wheezy.
<snip>
Quite understandable. Are you able to post a backtrace of the crash?
Tim
On 14/01/2012 22:54, Timothy Pearson wrote:
Thanks Tim, for your reply& your efforts on this excellent project. I agree, TDE is rock solid on Squeeze and I'm happy to continue using it, I just wanted to try TDE on Wheezy.
<snip>
Quite understandable. Are you able to post a backtrace of the crash?
My system is no longer in the same state. I re-installed libart from the link you provided and rebooted but it didn't cure it so I decided to rebuild the packages, with the new libart in place.
I'm just about to re-try now. If the problem persists is there anything specific you would like me to do prior to collecting a backtrace?
Mike.
--
On 14/01/2012 22:54, Timothy Pearson wrote:
Thanks Tim, for your reply& your efforts on this excellent project. I agree, TDE is rock solid on Squeeze and I'm happy to continue using it, I just wanted to try TDE on Wheezy.
<snip>
Quite understandable. Are you able to post a backtrace of the crash?
My system is no longer in the same state. I re-installed libart from the link you provided and rebooted but it didn't cure it so I decided to rebuild the packages, with the new libart in place.
I'm just about to re-try now. If the problem persists is there anything specific you would like me to do prior to collecting a backtrace?
Just make sure you have the kdebase, kdelibs, and qt3 debugging symbols installed...
Thanks!
Tim
On 15/01/2012 09:38, Timothy Pearson wrote:
On 14/01/2012 22:54, Timothy Pearson wrote:
Thanks Tim, for your reply& your efforts on this excellent project. I agree, TDE is rock solid on Squeeze and I'm happy to continue using it, I just wanted to try TDE on Wheezy.
<snip>
Quite understandable. Are you able to post a backtrace of the crash?
My system is no longer in the same state. I re-installed libart from the link you provided and rebooted but it didn't cure it so I decided to rebuild the packages, with the new libart in place.
I'm just about to re-try now. If the problem persists is there anything specific you would like me to do prior to collecting a backtrace?
Just make sure you have the kdebase, kdelibs, and qt3 debugging symbols installed...
Thanks!
Tim
Ok, backtrace attached.
Mike.
Ok, backtrace attached.
Mike.
Interesting. Are you building with libart support enabled or disabled? If libart is disabled I can easily see a potential crash.
The attached patch for kdelibs *should* fix the crash. Please let me know if it does so that I can commit it to GIT.
Tim
On 16/01/2012 19:13, Timothy Pearson wrote:
Ok, backtrace attached.
Mike.
Interesting. Are you building with libart support enabled or disabled? If libart is disabled I can easily see a potential crash.
The attached patch for kdelibs *should* fix the crash. Please let me know if it does so that I can commit it to GIT.
Tim
Thanks Tim I'll give it a try.
I have libart-2.0-2 & libart-2.0-dev installed from your link. I'm building with the option -DWITH_ARTS=ON.
Mike.
On 16/01/2012 19:13, Timothy Pearson wrote:
Ok, backtrace attached.
Mike.
Interesting. Are you building with libart support enabled or disabled? If libart is disabled I can easily see a potential crash.
The attached patch for kdelibs *should* fix the crash. Please let me know if it does so that I can commit it to GIT.
Tim
Hi Tim,
I can confirm that your patch has indeed fixed the crash. Thank you very much for sorting it out.
Mike.
--
On 01/16/2012 02:30 PM, Mike Howard wrote:
I can confirm that your patch has indeed fixed the crash. Thank you very much for sorting it out.
Cool. How soon will it make it into the repo?
On 01/16/2012 02:30 PM, Mike Howard wrote:
I can confirm that your patch has indeed fixed the crash. Thank you very much for sorting it out.
Cool. How soon will it make it into the repo?
The fix is in GIT as of hash e6b6f2e. What I am more interested in is why libart support was disabled in the first place; even though this may have fixed the crash, kiconloader cannot read SVG icons without libart.
Tim
On 01/16/2012 02:30 PM, Mike Howard wrote:
I can confirm that your patch has indeed fixed the crash. Thank you very much for sorting it out.
Cool. How soon will it make it into the repo?
The fix is in GIT as of hash e6b6f2e. What I am more interested in is why libart support was disabled in the first place; even though this may have fixed the crash, kiconloader cannot read SVG icons without libart.
Tim
The version of kdelibs that is in the v3.5.13 repository has libart enabled, so the crash fix is irrelevant and will not change the behaviour of the kdelibs package that is in that repository. If you are experiencing a crash from the v3.5.13 repository, please post the backtrace here.
Thanks!
Tim
On 01/16/2012 02:53 PM, Timothy Pearson wrote:
The fix is in GIT as of hash e6b6f2e. What I am more interested in is why libart support was disabled in the first place; even though this may have fixed the crash, kiconloader cannot read SVG icons without libart.
Most of that is a little above my pay grade. :)
How soon can I run an update and get the fix? Or do I need to get it another way?
-
Calvin Morrison -
Dan Youngquist -
Darrell Anderson -
Greg Madden -
Lisi -
Mike Howard -
Timothy Pearson