Tmenu/settings/regional & accessibility/keyboard shortcuts gives a segfault SIGSEGV.
Running *kcmshell keys* opens the panel successfully.
Can someone else confirm this?
Jay
Tmenu/settings/regional & accessibility/keyboard shortcuts gives a segfault SIGSEGV.
Running kcmshell keys opens the panel successfully.
Can someone else confirm this?
What release? GIT? 3.5.13? 3.5.12?
I'm using the latest GIT. Both the TDE menu selection and mini cli work without incident.
Darrell
On Saturday 28 of April 2012 05:44:18 Darrell Anderson wrote:
Tmenu/settings/regional & accessibility/keyboard shortcuts gives a segfault SIGSEGV.
Running kcmshell keys opens the panel successfully.
Can someone else confirm this?
What release? GIT? 3.5.13? 3.5.12?
I'm using the latest GIT. Both the TDE menu selection and mini cli work without incident.
Darrell
I tried 3.5.12 and 3.5.13 and both working properly.
Slavek --
Thanks for testing. I am using git from around 1 week ago. Will pull latest and retest. Havn't had much time for testing during last month but back into it now.
Jay
On Sat, Apr 28, 2012 at 10:17 AM, Slávek Banko slavek.banko@axis.cz wrote:
On Saturday 28 of April 2012 05:44:18 Darrell Anderson wrote:
Tmenu/settings/regional & accessibility/keyboard shortcuts gives a segfault SIGSEGV.
Running kcmshell keys opens the panel successfully.
Can someone else confirm this?
What release? GIT? 3.5.13? 3.5.12?
I'm using the latest GIT. Both the TDE menu selection and mini cli work without incident.
Darrell
I tried 3.5.12 and 3.5.13 and both working properly.
Slavek
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
Thanks for testing. I am using git from around 1 week ago. Will pull latest and retest. Havn't had much time for testing during last month but back into it now.
When testing with GIT builds often I uninstall all previous packages. Clean house. Cleaning house means looking for orphaned files, such as scripts in etc/profile.d. Then I rebuild my complete set again starting with TQt3. Right now I build almost everything to /opt/trinity. When I perform a full uninstall I end up with no /opt/trinity directory --- nominal evidence of a good uninstall.
When I 'git pull' tdebase I always check tdelibs too. If tdelibs has changed then I rebuild that module before building tdebase to continue testing. Those two modules go hand-in-hand.
Being methodical like this is somewhat a PITA, but I seem to avoid problems. GIT is too much of a moving target and rebuilding everything every several days seems saner for me in the long run. :-)
Darrell
I always rebuild from scratch. Starting from tqt3 and working down. I have a build script that lets me press the button and go away for a couple of hours ... hopefully without error.
BTW: I am building everything to /usr with no sign of KDE4. So far the base (that i need) builds nicely ... just a few niggling runtime errors.
Jay
On Sat, Apr 28, 2012 at 4:28 PM, Darrell Anderson humanreadable@yahoo.comwrote:
Thanks for testing. I am using git from around 1 week ago. Will pull
latest and
retest. Havn't had much time for testing during last month but back into
it now.
When testing with GIT builds often I uninstall all previous packages. Clean house. Cleaning house means looking for orphaned files, such as scripts in etc/profile.d. Then I rebuild my complete set again starting with TQt3. Right now I build almost everything to /opt/trinity. When I perform a full uninstall I end up with no /opt/trinity directory --- nominal evidence of a good uninstall.
When I 'git pull' tdebase I always check tdelibs too. If tdelibs has changed then I rebuild that module before building tdebase to continue testing. Those two modules go hand-in-hand.
Being methodical like this is somewhat a PITA, but I seem to avoid problems. GIT is too much of a moving target and rebuilding everything every several days seems saner for me in the long run. :-)
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
I always rebuild from scratch. Starting from tqt3 and working down. I have a build script that lets me press the button and go away for a couple of hours ... hopefully without error. BTW: I am building everything to /usr with no sign of KDE4. So far the base (that i need) builds nicely ... just a few niggling runtime errors.
Because I am building packages for other Slackware users I have been building to /opt/trinity. Another reason is to test compatibility with KDE4, although I have not been doing that lately.
When I rebuilt KDE3 for others, I built the packages to /usr and just warned everybody. When R14 is close to official release likely I will build a set of Trinity packages to /usr for myself. I don't use KDE4.
One question: when installing to /usr where do you install TQt3 to avoid collisions with Qt4? I need the latter to run VirtualBox and can't remove Qt4. Do you rename the TQt3/bin files?
Darrell
On Sat, 28 Apr 2012 17:19:17 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
I always rebuild from scratch. Starting from tqt3 and working down. I have a build script that lets me press the button and go away for a couple of hours ... hopefully without error. BTW: I am building everything to /usr with no sign of KDE4. So far the base (that i need) builds nicely ... just a few niggling runtime errors.
Because I am building packages for other Slackware users I have been building to /opt/trinity. Another reason is to test compatibility with KDE4, although I have not been doing that lately.
When I rebuilt KDE3 for others, I built the packages to /usr and just warned everybody. When R14 is close to official release likely I will build a set of Trinity packages to /usr for myself. I don't use KDE4.
One question: when installing to /usr where do you install TQt3 to avoid collisions with Qt4? I need the latter to run VirtualBox and can't remove Qt4. Do you rename the TQt3/bin files?
In Slackware the real Qt4 files are in /usr/lib/qt IIRC.
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
While i havn't yet built Virtualbox under tqt3 i have had no trouble running Virtualbox in any previous release using qt3. Virtualbox is released alongside our official release (Porteus).
Jay
On Sun, Apr 29, 2012 at 12:29 AM, /dev/ammo42 mickeytintincolle@yahoo.frwrote:
On Sat, 28 Apr 2012 17:19:17 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
I always rebuild from scratch. Starting from tqt3 and working down. I have a build script that lets me press the button and go away for a couple of hours ... hopefully without error. BTW: I am building everything to /usr with no sign of KDE4. So far the base (that i need) builds nicely ... just a few niggling runtime errors.
Because I am building packages for other Slackware users I have been building to /opt/trinity. Another reason is to test compatibility with KDE4, although I have not been doing that lately.
When I rebuilt KDE3 for others, I built the packages to /usr and just warned everybody. When R14 is close to official release likely I will build a set of Trinity packages to /usr for myself. I don't use KDE4.
One question: when installing to /usr where do you install TQt3 to avoid collisions with Qt4? I need the latter to run VirtualBox and can't remove Qt4. Do you rename the TQt3/bin files?
In Slackware the real Qt4 files are in /usr/lib/qt IIRC.
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
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
It's the strangest thing! I can start kcontrol from guest terminal and the 'keyboard shortcuts' opens without incident. I can also start the 'keyboard shortcut' screen directly from guest terminal with: kcmshell keys
If i use the tmenu to start control center, it segfaults when i click on 'keyboard shortcuts'. If i use tmenu to start 'keyboard shortcuts' directly it also crashes. Not even sure where to begin looking into the cause of this.
Jay
On Sun, Apr 29, 2012 at 1:38 PM, Jay jayflood@gmail.com wrote:
While i havn't yet built Virtualbox under tqt3 i have had no trouble running Virtualbox in any previous release using qt3. Virtualbox is released alongside our official release (Porteus).
Jay
On Sun, Apr 29, 2012 at 12:29 AM, /dev/ammo42 mickeytintincolle@yahoo.frwrote:
On Sat, 28 Apr 2012 17:19:17 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
I always rebuild from scratch. Starting from tqt3 and working down. I have a build script that lets me press the button and go away for a couple of hours ... hopefully without error. BTW: I am building everything to /usr with no sign of KDE4. So far the base (that i need) builds nicely ... just a few niggling runtime errors.
Because I am building packages for other Slackware users I have been building to /opt/trinity. Another reason is to test compatibility with KDE4, although I have not been doing that lately.
When I rebuilt KDE3 for others, I built the packages to /usr and just warned everybody. When R14 is close to official release likely I will build a set of Trinity packages to /usr for myself. I don't use KDE4.
One question: when installing to /usr where do you install TQt3 to avoid collisions with Qt4? I need the latter to run VirtualBox and can't remove Qt4. Do you rename the TQt3/bin files?
In Slackware the real Qt4 files are in /usr/lib/qt IIRC.
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
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
It's the strangest thing! I can start kcontrol from guest terminal and the 'keyboard shortcuts' opens without incident. I can also start the 'keyboard shortcut' screen directly from guest terminal with: kcmshell keys
If i use the tmenu to start control center, it segfaults when i click on 'keyboard shortcuts'. If i use tmenu to start 'keyboard shortcuts' directly it also crashes. Not even sure where to begin looking into the cause of this.
Porteus is based on Slackware, correct?
I just posted my experience with kwrite in Slackware Current. Broken.
I will need to reboot to test, but I'll report back how kcmshell works in that new environment.
Darrell
While i havn't yet built Virtualbox under tqt3 i have had no trouble running Virtualbox in any previous release using qt3. Virtualbox is released alongside our official release (Porteus).
Are you saying that more recent versions of VirtualBox can be built against Qt3? I was under the impression that after version 2.2.4 or thereabouts only Qt4 could be used.
Hence my question. If Qt4 is installed in /usr and I want to build (T)Qt3 to /usr, how do I avoid conflicts?
Darrell
On Sun, 29 Apr 2012 13:58:26 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
While i havn't yet built Virtualbox under tqt3 i have had no trouble running Virtualbox in any previous release using qt3. Virtualbox is released alongside our official release (Porteus).
Are you saying that more recent versions of VirtualBox can be built against Qt3? I was under the impression that after version 2.2.4 or thereabouts only Qt4 could be used.
Hence my question. If Qt4 is installed in /usr and I want to build (T)Qt3 to /usr, how do I avoid conflicts?
In Slackware Qt4 is *not* installed in /usr but in /usr/lib/qt, with many symlinks in /usr. Just don't put conflicting symlinks in /usr.
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
Yes Porteus is slackware based.
*Are you saying that more recent versions of VirtualBox can be built against Qt3?* Yes. I am currently using Virtualbox 4.1.8 built (on Porteus) from Trinity with no KDE4. Virtualbox supplies its own qt libraries in /opt/Virtualbox
libQtCoreVBox.so.4 libQtGuiVBox.so.4 libQtNetworkVBox.so.4 libQtOpenGLVBox.so.4
Jay
On Sun, Apr 29, 2012 at 9:11 PM, /dev/ammo42 mickeytintincolle@yahoo.frwrote:
On Sun, 29 Apr 2012 13:58:26 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
While i havn't yet built Virtualbox under tqt3 i have had no trouble running Virtualbox in any previous release using qt3. Virtualbox is released alongside our official release (Porteus).
Are you saying that more recent versions of VirtualBox can be built against Qt3? I was under the impression that after version 2.2.4 or thereabouts only Qt4 could be used.
Hence my question. If Qt4 is installed in /usr and I want to build (T)Qt3 to /usr, how do I avoid conflicts?
In Slackware Qt4 is *not* installed in /usr but in /usr/lib/qt, with many symlinks in /usr. Just don't put conflicting symlinks in /usr.
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
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
Yes Porteus is slackware based.
I just finished running some nominal tests of kcmshell in Trinity in Current. Everything worked as expected (except kwrite, reported in a different thread). I used all of the different methods do open the keyboard shortcut dialog and they all worked. No crashes.
Are you saying that more recent versions of VirtualBox can be built against Qt3?
Yes. I am currently using Virtualbox 4.1.8 built (on Porteus) from Trinity with no KDE4. Virtualbox supplies its own qt libraries in /opt/Virtualbox
libQtCoreVBox.so.4 libQtGuiVBox.so.4 libQtNetworkVBox.so.4 libQtOpenGLVBox.so.4
Ah, I see. Thank you. I'm using 3.2.12 OSE on 13.1. I don't like playing the bleeding edge game. Once I get my production system running to taste I tend to leave things alone. Thus, I don't keep pace with VirtualBox releases.
In my Trinity build environments for Slackware I don't install the Qt4 and KDE4 packages to avoid potential conflicts during the builds. I have a Qt4/KDE4 installed in virtual machines where I want to test Trinity but that is all run-time. Regardless, that VirtualBox can be built without Qt4 is good to know.
Darrell
Thanks for testing the 'keyboard shortcuts' i will start digging elsewhere for the cause. FYI, I am building under gcc-4.5.2 and have no such kwrite crashes.
Jay
On Sun, Apr 29, 2012 at 10:08 PM, Darrell Anderson humanreadable@yahoo.comwrote:
Yes Porteus is slackware based.
I just finished running some nominal tests of kcmshell in Trinity in Current. Everything worked as expected (except kwrite, reported in a different thread). I used all of the different methods do open the keyboard shortcut dialog and they all worked. No crashes.
Are you saying that more recent versions of VirtualBox can be built against Qt3?
Yes. I am currently using Virtualbox 4.1.8 built (on Porteus) from Trinity with no KDE4. Virtualbox supplies its own qt libraries in /opt/Virtualbox
libQtCoreVBox.so.4 libQtGuiVBox.so.4 libQtNetworkVBox.so.4 libQtOpenGLVBox.so.4
Ah, I see. Thank you. I'm using 3.2.12 OSE on 13.1. I don't like playing the bleeding edge game. Once I get my production system running to taste I tend to leave things alone. Thus, I don't keep pace with VirtualBox releases.
In my Trinity build environments for Slackware I don't install the Qt4 and KDE4 packages to avoid potential conflicts during the builds. I have a Qt4/KDE4 installed in virtual machines where I want to test Trinity but that is all run-time. Regardless, that VirtualBox can be built without Qt4 is good to know.
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
Thanks for testing the 'keyboard shortcuts' i will start digging elsewhere for the cause.
Please let us know what you find.
FYI, I am building under gcc-4.5.2 and have no such kwrite crashes.
Ok. Good. That is reasonable confirmation that 13.37 is "clean."
Darrell
Hence my question. If Qt4 is installed in /usr and I want to build (T)Qt3 to /usr, how do I avoid conflicts?
In Slackware Qt4 is *not* installed in /usr but in /usr/lib/qt, with many symlinks in /usr. Just don't put conflicting symlinks in /usr.
Yes, I know /usr is not /usr/lib, but that is not what I meant. :-) I meant /usr in a generic sense, which is where /usr/lib resides. I'll have to study how Qt4 is installed and the old way Qt3 was installed too. If I recall, Qt3 was installed in /usr/lib/qt3.
Darrell
On Sun, 29 Apr 2012 13:58:26 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
While i havn't yet built Virtualbox under tqt3 i have had no trouble running Virtualbox in any previous release using qt3. Virtualbox is released alongside our official release (Porteus).
Are you saying that more recent versions of VirtualBox can be built against Qt3? I was under the impression that after version 2.2.4 or thereabouts only Qt4 could be used.
Fishing through the ebuild shows that QT4 is definitely optional (switch --disable-qt4). However, I'm not sure what kind of GUI, if any, you'd get without it—the other deps specified for a non-QT4, non-headless build don't include a widget set, just SDL, OpenGL, and some X libs. An SDL-based GUI is possible, I suppose, but it's a bit peculiar.
-
/dev/ammo42 -
Darrell Anderson -
E. Liddell -
Jay -
Slávek Banko