Tim, Darrell, All,
I rebuilt TDE yesterday on gcc47. Nothing else changed. Now, after updating my install and removing all /var/tmp/ ksyscoca files, I get module failure when trying to access kcm modules like kcontrol, knemo, kdesktop, etc.. I grabbed a couple of screenshots:
http://www.3111skyline.com/dl/dt/trinity/ss/kcontrol-module-failure.jpg
http://www.3111skyline.com/dl/dt/trinity/ss/kdesktop-module-failure.jpg
http://www.3111skyline.com/dl/dt/trinity/ss/knemo-error-window.jpg
Checking the command line with knemo, I get the following:
kio (KSycoca): Trying to open ksycoca from /var/tmp/tdecache-david/ksycoca kutils (KCModuleInfo): Could not find the service. kcontrol: Module '' not found. kutils (KCMultiDialog): KCMultiDialog::addModule Network Monitor kutils (KCModuleProxy): [void KCModuleProxy::init(const KCModuleInfo&)] kutils (KCMultiDialog): [void KCMultiDialog::slotAboutToShow(TQWidget*)] kutils (KCModuleProxy): [KCModule* KCModuleProxy::realModule() const] kutils (KCModuleProxy): Module not already loaded, loading module kutils (KCModuleProxy): [KCModule* KCModuleProxy::realModule() const] kutils (KCModuleProxy): [KCModule* KCModuleProxy::realModule() const] kutils (KCModuleProxy): [KCModule* KCModuleProxy::realModule() const] kutils (KCModuleProxy): [virtual void KCModuleProxy::showEvent(TQShowEvent*)] kutils (KCModuleProxy): [KCModule* KCModuleProxy::realModule() const] kutils (KCMultiDialog): [void KCMultiDialog::dialogClosed()]
I don't know where to look next. What gives?
Tim, Darrell, All,
I rebuilt TDE yesterday on gcc47. Nothing else changed. Now, after updating my install and removing all /var/tmp/ ksyscoca files, I get module failure when trying to access kcm modules like kcontrol, knemo, kdesktop, etc.. I grabbed a couple of screenshots:
http://www.3111skyline.com/dl/dt/trinity/ss/kcontrol-module-failure.jpg
http://www.3111skyline.com/dl/dt/trinity/ss/kdesktop-module-failure.jpg
http://www.3111skyline.com/dl/dt/trinity/ss/knemo-error-window.jpg
Checking the command line with knemo, I get the following:
kio (KSycoca): Trying to open ksycoca from /var/tmp/tdecache-david/ksycoca kutils (KCModuleInfo): Could not find the service. kcontrol: Module '' not found. kutils (KCMultiDialog): KCMultiDialog::addModule Network Monitor kutils (KCModuleProxy): [void KCModuleProxy::init(const KCModuleInfo&)] kutils (KCMultiDialog): [void KCMultiDialog::slotAboutToShow(TQWidget*)] kutils (KCModuleProxy): [KCModule* KCModuleProxy::realModule() const] kutils (KCModuleProxy): Module not already loaded, loading module kutils (KCModuleProxy): [KCModule* KCModuleProxy::realModule() const] kutils (KCModuleProxy): [KCModule* KCModuleProxy::realModule() const] kutils (KCModuleProxy): [KCModule* KCModuleProxy::realModule() const] kutils (KCModuleProxy): [virtual void KCModuleProxy::showEvent(TQShowEvent*)] kutils (KCModuleProxy): [KCModule* KCModuleProxy::realModule() const] kutils (KCMultiDialog): [void KCMultiDialog::dialogClosed()]
I don't know where to look next. What gives?
That's odd. What happens if you rebuild tdelibs and/or tdebase under gcc4.6?
Tim
On 04/12/2012 09:38 AM, Timothy Pearson wrote:
That's odd. What happens if you rebuild tdelibs and/or tdebase under gcc4.6?
Tim
I'll have to give that a go. I started another build to double check. When I first build under gcc47, I did get a desktop kcminit failure that prevented everything except the main window from loading.
It will take a bit of work to reset my build environment to gcc 4.6, but I'll let you know. Let me know if you have any other ideas.
On 04/12/2012 09:38 AM, Timothy Pearson wrote:
That's odd. What happens if you rebuild tdelibs and/or tdebase under gcc4.6?
Tim
I'll have to give that a go. I started another build to double check. When I first build under gcc47, I did get a desktop kcminit failure that prevented everything except the main window from loading.
It will take a bit of work to reset my build environment to gcc 4.6, but I'll let you know. Let me know if you have any other ideas.
-- David C. Rankin, J.D.,P.E.
Right now I'm thinking 1.) some kind of C++ ABI incompatibility 2.) An overlooked commit in GIT that broke kcmodules 3.) A gcc 4.7 bug
Tim
On 04/12/2012 11:52 AM, Timothy Pearson wrote:
On 04/12/2012 09:38 AM, Timothy Pearson wrote:
That's odd. What happens if you rebuild tdelibs and/or tdebase under gcc4.6?
Tim
I'll have to give that a go. I started another build to double check. When I first build under gcc47, I did get a desktop kcminit failure that prevented everything except the main window from loading.
It will take a bit of work to reset my build environment to gcc 4.6, but I'll let you know. Let me know if you have any other ideas.
-- David C. Rankin, J.D.,P.E.
Right now I'm thinking 1.) some kind of C++ ABI incompatibility 2.) An overlooked commit in GIT that broke kcmodules 3.) A gcc 4.7 bug
Tim
I just completed a complete rebuild on gcc46 - and the modules are still broken. You cannot launch kcontrol from the menu any longer. The only way to open it was via konsole and 'kcontrol' directly.
knemo no longer works - same kcm_shell issue...
screenshot:
http://www.3111skyline.com/dl/dt/trinity/ss/kcontrol-empty2.jpg
There were no build issues. In fact - great job pushing the patches. The only failures I had were attempts to revert a previously applied patch where I hadn't removed them from the scripts yet.
I don't know what changed since 3/29 and today that would break kcontrol, etc.. I'll leave this to you that know the code. I don't know where to begin. Let me know if you would like me to run some additional test and I'm happy to do it. I'm just not sure what to test.
I just completed a complete rebuild on gcc46 - and the modules are still broken. You cannot launch kcontrol from the menu any longer. The only way to open it was via konsole and 'kcontrol' directly.
knemo no longer works - same kcm_shell issue...
screenshot:
http://www.3111skyline.com/dl/dt/trinity/ss/kcontrol-empty2.jpg
There were no build issues. In fact - great job pushing the patches. The only failures I had were attempts to revert a previously applied patch where I hadn't removed them from the scripts yet.
I don't know what changed since 3/29 and today that would break kcontrol, etc.. I'll leave this to you that know the code. I don't know where to begin. Let me know if you would like me to run some additional test and I'm happy to do it. I'm just not sure what to test.
I just built everything here on Slackware 13.1 (gcc 4.4.4). No noticeable problems.
For problems like this, consider not building anything beyond the core packages because that minimal install provides sufficient evidence of what is working or breaking. I do that quite often when I want to test the basics. Doing similarly would save you much time as KControl will show most of the modules just by building tdelibs/tdebase. A few modules from the remaining packages will be missing, but you'll know right away whether KControl is broken.
I finally created Slackware 13.37 partitions so I can start testing Trinity with that release (gcc 4.5.2). I intend to do likewise with Slackware Current (the testing system for the next official release), which now uses gcc 4.7. With 13.37 I can provide confirmations of what builds and what doesn't. Moreso with Current and gcc 4.7.
The only kink with this plan is I can build only 13.37 or Current at one time. I only have two machines capable of doing this work and three Slackware systems to test. :( As 13.1 remains my primary system, my primary machine will remain tied to that. Virtual machines are great for usability testing but too slow for this amount of repetitive building.
Darrell
On Sat, 14 Apr 2012 16:41:55 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
I just completed a complete rebuild on gcc46 - and the modules are still broken. You cannot launch kcontrol from the menu any longer. The only way to open it was via konsole and 'kcontrol' directly.
knemo no longer works - same kcm_shell issue...
screenshot:
http://www.3111skyline.com/dl/dt/trinity/ss/kcontrol-empty2.jpg
There were no build issues. In fact - great job pushing the patches. The only failures I had were attempts to revert a previously applied patch where I hadn't removed them from the scripts yet.
I don't know what changed since 3/29 and today that would break kcontrol, etc.. I'll leave this to you that know the code. I don't know where to begin. Let me know if you would like me to run some additional test and I'm happy to do it. I'm just not sure what to test.
I just built everything here on Slackware 13.1 (gcc 4.4.4). No noticeable problems.
For problems like this, consider not building anything beyond the core packages because that minimal install provides sufficient evidence of what is working or breaking. I do that quite often when I want to test the basics. Doing similarly would save you much time as KControl will show most of the modules just by building tdelibs/tdebase. A few modules from the remaining packages will be missing, but you'll know right away whether KControl is broken.
I finally created Slackware 13.37 partitions so I can start testing Trinity with that release (gcc 4.5.2). I intend to do likewise with Slackware Current (the testing system for the next official release), which now uses gcc 4.7. With 13.37 I can provide confirmations of what builds and what doesn't. Moreso with Current and gcc 4.7.
The only kink with this plan is I can build only 13.37 or Current at one time. I only have two machines capable of doing this work and three Slackware systems to test. :( As 13.1 remains my primary system, my primary machine will remain tied to that. Virtual machines are great for usability testing but too slow for this amount of repetitive building.
You can also chroot into a Slackware partition and run the chrooted system under the kernel of the host system: http://slackworld.berlios.de/2007/chroot_howto.html (but with the apparition of KMS on modern systems, I'd rather use the X server of the host than the one of the chroot).
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 04/14/2012 06:41 PM, Darrell Anderson wrote:
The only kink with this plan is I can build only 13.37 or Current at one time. I only have two machines capable of doing this work and three Slackware systems to test. :( As 13.1 remains my primary system, my primary machine will remain tied to that. Virtual machines are great for usability testing but too slow for this amount of repetitive building.
Darrell
Darrell,
One of the benefits I've found of building in a clean chroot is the ability to have more than 1 build environment. Though I just got it figured out, I know have a /bld and /bldgcc46 build environment that will allow testing under both versions of gcc. I'm sure the same thing can be set up on slack.
On 04/14/2012 06:41 PM, Darrell Anderson wrote:
I just completed a complete rebuild on gcc46 - and the modules are still broken. You cannot launch kcontrol from the menu any longer. The only way to open it was via konsole and 'kcontrol' directly.
knemo no longer works - same kcm_shell issue...
screenshot:
http://www.3111skyline.com/dl/dt/trinity/ss/kcontrol-empty2.jpg
There were no build issues. In fact - great job pushing the patches. The only failures I had were attempts to revert a previously applied patch where I hadn't removed them from the scripts yet.
I don't know what changed since 3/29 and today that would break kcontrol, etc.. I'll leave this to you that know the code. I don't know where to begin. Let me know if you would like me to run some additional test and I'm happy to do it. I'm just not sure what to test.
I just built everything here on Slackware 13.1 (gcc 4.4.4). No noticeable problems.
For problems like this, consider not building anything beyond the core packages because that minimal install provides sufficient evidence of what is working or breaking. I do that quite often when I want to test the basics. Doing similarly would save you much time as KControl will show most of the modules just by building tdelibs/tdebase. A few modules from the remaining packages will be missing, but you'll know right away whether KControl is broken.
I finally created Slackware 13.37 partitions so I can start testing Trinity with that release (gcc 4.5.2). I intend to do likewise with Slackware Current (the testing system for the next official release), which now uses gcc 4.7. With 13.37 I can provide confirmations of what builds and what doesn't. Moreso with Current and gcc 4.7.
The only kink with this plan is I can build only 13.37 or Current at one time. I only have two machines capable of doing this work and three Slackware systems to test. :( As 13.1 remains my primary system, my primary machine will remain tied to that. Virtual machines are great for usability testing but too slow for this amount of repetitive building.
Darrell
I rebuilt tdelibs and tdebase again tonight removing all patches. The patches that were removed were:
kdelibs: # patch -Np0 -i ${pkgname#*-}-XDG-KDE-TDE.diff # patch -Np0 -i ${pkgname#*-}-KDE4-detect.diff # patch -Np0 -i ${pkgname#*-}-kdetcompmgr.diff # patch -Np0 -i ${pkgname#*-}-recentdocs.diff
kdebase: # patch -Np1 -i ${srcdir}/tdebase-feedbackdlg.diff
Upon tde start - knemo popped up like it should -- which was a good indication that kcontrol would be fixed as well. It was. So the issues is in one of the experimental patches. We don't want to push those until we can identify which one... For next week.
<snip>
I rebuilt tdelibs and tdebase again tonight removing all patches. The patches that were removed were:
kdelibs: # patch -Np0 -i ${pkgname#*-}-XDG-KDE-TDE.diff # patch -Np0 -i ${pkgname#*-}-KDE4-detect.diff # patch -Np0 -i ${pkgname#*-}-kdetcompmgr.diff # patch -Np0 -i ${pkgname#*-}-recentdocs.diff
kdebase: # patch -Np1 -i ${srcdir}/tdebase-feedbackdlg.diff
Upon tde start - knemo popped up like it should -- which was a good indication that kcontrol would be fixed as well. It was. So the issues is in one of the experimental patches. We don't want to push those until we can identify which one... For next week.
It took me ages to figure out why all my kcontrol modules had disappeared a while back; it turned out that TDE is far more reliant on a correct and intact menu structure being present on the system than I first realized.
Therefore my money's on patch *-XDG-KDE-TDE.diff being the problem.
Tim
I rebuilt tdelibs and tdebase again tonight removing
all patches. The patches that were removed were:
kdelibs: # patch -Np0 -i
${pkgname#*-}-XDG-KDE-TDE.diff
# patch -Np0 -i
${pkgname#*-}-KDE4-detect.diff
# patch -Np0 -i
${pkgname#*-}-kdetcompmgr.diff
# patch -Np0 -i
${pkgname#*-}-recentdocs.diff
kdebase: # patch -Np1 -i
${srcdir}/tdebase-feedbackdlg.diff
Upon tde start - knemo popped up like it should --
which was a good indication that kcontrol would be fixed as well. It was. So the issues is in one of the experimental patches. We don't want to push those until we can identify which one... For next week.
I was unaware you were testing the experimentals. I probably should comment my build script to warn people as such.
It took me ages to figure out why all my kcontrol modules had disappeared a while back; it turned out that TDE is far more reliant on a correct and intact menu structure being present on the system than I first realized.
Therefore my money's on patch *-XDG-KDE-TDE.diff being the problem.
Yes, kcontrol builds its tree based upon the *.desktop key entries.
The XDG-KDE-TDE patches all work here. The missing glue is something I shared a while back:
The user needs either to create a new profile or perform a sed search to replace all X-KDE references with X-TDE references:
find $TDEHOME -type f -exec sed -i 's|X-KDE|X-TDE|g' {} ; find $TDEHOME -type f -exec sed -i 's|KDE;|TDE;|g' {} ;
A while ago I asked how Trinity (nee KDE3) updates user profile files when there are changes in configuration file structures. I received no response. I know there is a way, but I don't know the mechanics of that process.
To use the XDG-KDE-TDE.diff patches, perform the two sed searches before starting the next session. A good idea is to delete the ksycoca cache because the kcontrol and menu structures are cached and the cache will deceive anybody from seeing changes.
The XDG-KDE-TDE.diff patches are part of bug report 892. I'm ready to push these patches, but have held off because I don't know how to automatically update the user's profile files. For those of us doing the testing the solution is the two sed searches, but that won't fly for normal users.
These changes are needed to avoid conflicts with that 'other' desktop.
BTW, don't use those tdelibs experimential patches. I toy with them every once in a while. The tdebase-feedbackdlg.diff patch for tdebase has been updated at the bug tracker and works just fine. That patch has nothing to do with the kcontrol errors you have seen. Those errors are caused by using the XDG-KDE-TDE.diff patches and then not knowing about updating the profile config files.
Darrell
On 04/16/2012 01:46 AM, Darrell Anderson wrote:
The XDG-KDE-TDE.diff patches are part of bug report 892. I'm ready to push these patches, but have held off because I don't know how to automatically update the user's profile files. For those of us doing the testing the solution is the two sed searches, but that won't fly for normal users.
I don't think simply deleting ksycoca cache files is enough. I deleted the complete /var/tmp/tde-cache files with each install of a new tdelibs/tdebase and I still had the kmenu entries and knemo fail each time the patches were used. I'm building on x86_64 and i686. The x86_64 builds are the ones I've been testing. They definitely show this failure even with the ksycoca removed.
I don't think simply deleting ksycoca cache files is enough. I deleted the complete /var/tmp/tde-cache files with each install of a new tdelibs/tdebase and I still had the kmenu entries and knemo fail each time the patches were used. I'm building on x86_64 and i686. The x86_64 builds are the ones I've been testing. They definitely show this failure even with the ksycoca removed.
Yes, read my previous post. The cache is only part of the cleanup. Users still need to update their profile configuration files as I mentioned with the two sed searches.
If you use an existing Trinity profile, then after applying the XDG-KDE-TDE patches and installing the updated packages, you have to delete the cache AND apply the sed searches.
Do not use the same profile used in a production environment because after applying the sed searches, the profile configuration files won't work with versions of Trinity that do not use the XDG-KDE-TDE updates.
Everything works after purging the cache and applying the sed searches.
This is why I ask for help in learning how to automate the process of updating the user's profile directory. Just like previous KDE point releases, this is a one way trip.
I do all of this only in a testing environment. When we go live with R14, updating the user's profile has to happen quietly for the user, just like with previous KDE3 updates.
Darrell
On 04/12/2012 09:53 AM, David C. Rankin wrote:
On 04/12/2012 09:38 AM, Timothy Pearson wrote:
That's odd. What happens if you rebuild tdelibs and/or tdebase under gcc4.6?
Tim
I'll have to give that a go. I started another build to double check. When I first build under gcc47, I did get a desktop kcminit failure that prevented everything except the main window from loading.
It will take a bit of work to reset my build environment to gcc 4.6, but I'll let you know. Let me know if you have any other ideas.
Tim,
Just completed another complete rebuild of TDE with gcc47 with NO makeflags at all (just to make sure building wasn't an issue) knemo shows the exact same behavior - no modules found. kcontrol opens and lists the main headings on the left, but it is completely empty:
http://www.3111skyline.com/dl/dt/trinity/ss/kcontrol-empty.jpg
I can't figure out what this could be. Everything that built, built without crashing. The only build failures I had were:
tde-kipi-plugins - error: redeclaration of 'TQListViewItemIterator it'
tde-tdepim - error: redeclaration of 'TQMap<TQGuardedPtr<KMFolder>, int>::Iterator it'
tde-k3b - error: redeclaration of 'K3bAudioEditorWidget::Range* r'
digiam - still dead with libpng15 issue.
There seems to be a common thread in the failures above. I have no idea how to solve redeclaration issues. The only thing I can think of for the current kcontrol and knemo, etc.. module failure issues is there is something similar going on that isn't being flagged as 'fatal' during the build but that is killing the modules in tdelibs nonetheless.
Need advise from the white wizard...
Just completed another complete rebuild of TDE with gcc47 with NO makeflags at all (just to make sure building wasn't an issue) knemo shows the exact same behavior - no modules found. kcontrol opens and lists the main headings on the left, but it is completely empty:
http://www.3111skyline.com/dl/dt/trinity/ss/kcontrol-empty.jpg
I can't figure out what this could be. Everything that built, built without crashing. The only build failures I had were:
tde-kipi-plugins - error: redeclaration of 'TQListViewItemIterator it'
tde-tdepim - error: redeclaration of 'TQMap<TQGuardedPtr<KMFolder>, int>::Iterator it'
tde-k3b - error: redeclaration of 'K3bAudioEditorWidget::Range* r'
digiam - still dead with libpng15 issue.
There seems to be a common thread in the failures above. I have no idea how to solve redeclaration issues. The only thing I can think of for the current kcontrol and knemo, etc.. module failure issues is there is something similar going on that isn't being flagged as 'fatal' during the build but that is killing the modules in tdelibs nonetheless.
Looks like gcc 4.7 will require some major code cleanup. However, today I ran across this response in a forum discussion:
https://www.linuxquestions.org/questions/slackware-14/zoneminder-1-25-0-wont... Perhaps some of the 4.7 problems will be resolved by manually adding unistd.h in the preprocessor includes.
This document explains the changes in gcc 4.7:
http://gcc.gnu.org/gcc-4.7/changes.html
Somebody more experienced with compilers could help by translating that information into a wiki how-to of what types of failures to expect, what types of cures will help, and when those cures need to be explicitly defined in the build process.
Darrell
On 04/12/2012 02:56 PM, Darrell Anderson wrote:
Looks like gcc 4.7 will require some major code cleanup. However, today I ran across this response in a forum discussion:
https://www.linuxquestions.org/questions/slackware-14/zoneminder-1-25-0-wont... Perhaps some of the 4.7 problems will be resolved by manually adding unistd.h in the preprocessor includes.
This document explains the changes in gcc 4.7:
http://gcc.gnu.org/gcc-4.7/changes.html
Somebody more experienced with compilers could help by translating that information into a wiki how-to of what types of failures to expect, what types of cures will help, and when those cures need to be explicitly defined in the build process.
Darrell
Good stuff - that's what several of my patches did. I'm no wizard at adjusting what happens after pushing the g++ 'x' button, but hopefully there is a good rabbit trail in the links...
On 04/12/2012 04:00 PM, David C. Rankin wrote:
On 04/12/2012 02:56 PM, Darrell Anderson wrote:
Looks like gcc 4.7 will require some major code cleanup. However, today I ran across this response in a forum discussion:
https://www.linuxquestions.org/questions/slackware-14/zoneminder-1-25-0-wont... Perhaps some of the 4.7 problems will be resolved by manually adding unistd.h in the preprocessor includes.
This document explains the changes in gcc 4.7:
http://gcc.gnu.org/gcc-4.7/changes.html
Somebody more experienced with compilers could help by translating that information into a wiki how-to of what types of failures to expect, what types of cures will help, and when those cures need to be explicitly defined in the build process.
Darrell
Good stuff - that's what several of my patches did. I'm no wizard at adjusting what happens after pushing the g++ 'x' button, but hopefully there is a good rabbit trail in the links...
This also shows a lot of promise for help:
http://gcc.gnu.org/gcc-4.7/porting_to.html
-
/dev/ammo42 -
Darrell Anderson -
David C. Rankin -
Timothy Pearson