On 04/12/2012 09:38 AM, Timothy Pearson wrote: 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.

On 04/12/2012 11:52 AM, Timothy Pearson 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. -- David C. Rankin, J.D.,P.E.

On Sat, 14 Apr 2012 16:41:55 -0700 (PDT) Darrell Anderson <humanreadable(a)yahoo.com> wrote: 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).

On 04/14/2012 06:41 PM, Darrell Anderson wrote: 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. -- David C. Rankin, J.D.,P.E.

I was unaware you were testing the experimentals. I probably should comment my build script to warn people as such. 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

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

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-won… 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 04:00 PM, David C. Rankin wrote: This also shows a lot of promise for help: http://gcc.gnu.org/gcc-4.7/porting_to.html -- David C. Rankin, J.D.,P.E.