Recently David shared some issues with starting Trinity. In his case the probable cause seemed to be stale profile cache file or profile cache files using the old prefix names.
Today I stumbled across a way to stall the session startup. I changed some settings in KControl.
What caught my eye with this bug is the xsession log error, which David saw as well:
ksmserver: '<wm>' missing. ksmserver: Use --help to get a list of available command line options.
I traced the cause to these lines in my profile twinrc:
[ThirdPartyWM] WMAdditionalArguments= WMExecutable=twin
Those lines and group do not exist in a twinrc backup file and is the only difference between the files.
This is not a hard freeze. Trinity exits gracefully back to the command line, which is how I start X/Trinity.
The problem is with tdeinit_phase1. I commented out that command in starttde. I successfully substituted all of the following:
kwrapper ksmserver --windowmanager twin --windowmanageraddargs ""
kwrapper ksmserver --windowmanager twin
kwrapper ksmserver
Looking at the tdeinit_phase1 source code, I see that when WMExecutable is undefined/empty then tdeinit_phase1 defaults to "kwrapper ksmserver." As my previous twinrc contained no ThirdPartyWM group in twinrc, that is how tdeinit_phase1 always started.
When I changed some settings in KControl to cause twinrc to update with including the ThirdPartyWM group, tdeinit_phase1 instead starts with "kwrapper ksmserver --windowmanager %1 --windowmanageraddargs %2."
Changing the twinrc WMAdditionalArguments to WMAdditionalArguments=--lock allowed Trinity to start using tdeinit_phase1.
I think the solution then is to add the following condition test to tdeinit_phase1:
else if (wmArguments == "") { return_code = system((TQString("kwrapper ksmserver --windowmanager %1").arg(wmToLaunch)).ascii());
Comments?
Darrell
On 03/22/2012 12:20 AM, Darrell Anderson wrote:
Recently David shared some issues with starting Trinity. In his case the probable cause seemed to be stale profile cache file or profile cache files using the old prefix names.
Today I stumbled across a way to stall the session startup. I changed some settings in KControl.
What caught my eye with this bug is the xsession log error, which David saw as well:
ksmserver: '<wm>' missing. ksmserver: Use --help to get a list of available command line options.
I traced the cause to these lines in my profile twinrc:
[ThirdPartyWM] WMAdditionalArguments= WMExecutable=twin
Those lines and group do not exist in a twinrc backup file and is the only difference between the files.
This is not a hard freeze. Trinity exits gracefully back to the command line, which is how I start X/Trinity.
The problem is with tdeinit_phase1. I commented out that command in starttde. I successfully substituted all of the following:
kwrapper ksmserver --windowmanager twin --windowmanageraddargs ""
kwrapper ksmserver --windowmanager twin
kwrapper ksmserver
Looking at the tdeinit_phase1 source code, I see that when WMExecutable is undefined/empty then tdeinit_phase1 defaults to "kwrapper ksmserver." As my previous twinrc contained no ThirdPartyWM group in twinrc, that is how tdeinit_phase1 always started.
When I changed some settings in KControl to cause twinrc to update with including the ThirdPartyWM group, tdeinit_phase1 instead starts with "kwrapper ksmserver --windowmanager %1 --windowmanageraddargs %2."
Changing the twinrc WMAdditionalArguments to WMAdditionalArguments=--lock allowed Trinity to start using tdeinit_phase1.
I think the solution then is to add the following condition test to tdeinit_phase1:
else if (wmArguments == "") { return_code = system((TQString("kwrapper ksmserver --windowmanager %1").arg(wmToLaunch)).ascii());
Comments?
Darrell
This is starting to make sense. On the session before I started experiencing crashes with startted, I had updated the background to be displayed in kcontrol -> login manager. I suspect what you were able to traceback more thoroughly that I was the root cause of the crashes I experienced as well. Good catch!
Recently David shared some issues with starting
Trinity. In his case the probable cause seemed to be stale profile cache file or profile cache files using the old prefix names.
Today I stumbled across a way to stall the session
startup. I changed some settings in KControl.
What caught my eye with this bug is the xsession log
error, which David saw as well:
ksmserver: '<wm>' missing. ksmserver: Use --help to get a list of available
command line options.
I traced the cause to these lines in my profile
twinrc:
[ThirdPartyWM] WMAdditionalArguments= WMExecutable=twin
Those lines and group do not exist in a twinrc backup
file and is the only difference between the files.
This is not a hard freeze. Trinity exits gracefully
back to the command line, which is how I start X/Trinity.
The problem is with tdeinit_phase1. I commented out
that command in starttde. I successfully substituted all of the following:
kwrapper ksmserver --windowmanager twin
--windowmanageraddargs ""
kwrapper ksmserver --windowmanager twin
kwrapper ksmserver
Looking at the tdeinit_phase1 source code, I see that
when WMExecutable is undefined/empty then tdeinit_phase1 defaults to "kwrapper ksmserver." As my previous twinrc contained no ThirdPartyWM group in twinrc, that is how tdeinit_phase1 always started.
When I changed some settings in KControl to cause
twinrc to update with including the ThirdPartyWM group, tdeinit_phase1 instead starts with "kwrapper ksmserver --windowmanager %1 --windowmanageraddargs %2."
Changing the twinrc WMAdditionalArguments to
WMAdditionalArguments=--lock allowed Trinity to start using tdeinit_phase1.
I think the solution then is to add the following
condition test to tdeinit_phase1:
else if (wmArguments == "") { return_code =
system((TQString("kwrapper ksmserver --windowmanager %1").arg(wmToLaunch)).ascii());
Comments?
Darrell
This is starting to make sense. On the session before I started experiencing crashes with starttde, I had updated the background to be displayed in kcontrol -> login manager. I suspect what you were able to traceback more thoroughly that I was the root cause of the crashes I experienced as well. Good catch!
I have a patch that I ask somebody either test or provide a peer review signoff.
I added new code, albeit only a single "else if" test.
I have tested the patch in both a VM and physical machine. No more halts in the session startup.
Here is the patch:
http://humanreadable.nfshost.com/trinity/patches/tdebase/tdebase-tdeinit_pha...
If testing the patch then do so like this:
* Before patching and updating tdebase, start a Trinity session. * Open KControl, Appearance & Themes, Window Decorations. * Toggle any nominal setting and select the Apply button. * Exit the session. * Login to start a new session. * Verify the session stalls and won't start. * Restore twinrc: edit twinrc config file and delete the group section "ThirdPartyWM." * Login to verify that once again Trinity starts. * Log out. * Install the patched tdebase. * Start the session and repeat the KControl exercise. * Exit the session. * Start the session. * Verify Trinity now starts without stalling.
Thanks!
Darrell
On 03/22/2012 12:43 PM, Darrell Anderson wrote:
I have a patch that I ask somebody either test or provide a peer review signoff.
I added new code, albeit only a single "else if" test.
I have tested the patch in both a VM and physical machine. No more halts in the session startup.
Here is the patch:
http://humanreadable.nfshost.com/trinity/patches/tdebase/tdebase-tdeinit_pha...
If testing the patch then do so like this:
- Before patching and updating tdebase, start a Trinity session.
- Open KControl, Appearance& Themes, Window Decorations.
- Toggle any nominal setting and select the Apply button.
- Exit the session.
- Login to start a new session.
- Verify the session stalls and won't start.
- Restore twinrc: edit twinrc config file and delete the group section "ThirdPartyWM."
- Login to verify that once again Trinity starts.
- Log out.
- Install the patched tdebase.
- Start the session and repeat the KControl exercise.
- Exit the session.
- Start the session.
- Verify Trinity now starts without stalling.
Thanks!
Darrell
I'll rebuild tonight and test.
I have a patch that I ask somebody either test or
provide a peer review signoff.
I added new code, albeit only a single "else if" test.
I have tested the patch in both a VM and physical
machine. No more halts in the session startup.
Here is the patch:
http://humanreadable.nfshost.com/trinity/patches/tdebase/tdebase-tdeinit_pha...
If testing the patch then do so like this:
- Before patching and updating tdebase, start a Trinity session.
- Open KControl, Appearance& Themes, Window Decorations.
- Toggle any nominal setting and select the Apply button.
- Exit the session.
- Login to start a new session.
- Verify the session stalls and won't start.
- Restore twinrc: edit twinrc config file and delete the group section "ThirdPartyWM."
- Login to verify that once again Trinity starts.
- Log out.
- Install the patched tdebase.
- Start the session and repeat the KControl exercise.
- Exit the session.
- Start the session.
- Verify Trinity now starts without stalling.
Anybody?
Darrell
On 03/24/2012 03:36 PM, Darrell Anderson wrote:
I have a patch that I ask somebody either test or
provide a peer review signoff.
I added new code, albeit only a single "else if" test.
I have tested the patch in both a VM and physical
machine. No more halts in the session startup.
Here is the patch:
http://humanreadable.nfshost.com/trinity/patches/tdebase/tdebase-tdeinit_pha...
If testing the patch then do so like this:
- Before patching and updating tdebase, start a Trinity session.
- Open KControl, Appearance& Themes, Window Decorations.
- Toggle any nominal setting and select the Apply button.
- Exit the session.
- Login to start a new session.
- Verify the session stalls and won't start.
- Restore twinrc: edit twinrc config file and delete the group section "ThirdPartyWM."
- Login to verify that once again Trinity starts.
- Log out.
- Install the patched tdebase.
- Start the session and repeat the KControl exercise.
- Exit the session.
- Start the session.
- Verify Trinity now starts without stalling.
Anybody?
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
Not for gotten,
Just wrapping up the rebuild (had to back out the libcaldav patches - already in GIT :)
Beginning build of: dependencies/tqt3 - Mar 24 01:48:31 Completed build of: dependencies/tqt3 - Mar 24 02:20:46 Beginning build of: dependencies/tqtinterface - Mar 24 02:20:46 Completed build of: dependencies/tqtinterface - Mar 24 02:23:49 Beginning build of: dependencies/arts - Mar 24 02:23:49 Completed build of: dependencies/arts - Mar 24 02:28:24 Beginning build of: dependencies/dbus-tqt - Mar 24 02:28:24 Completed build of: dependencies/dbus-tqt - Mar 24 02:28:37 Beginning build of: dependencies/dbus-1-tqt - Mar 24 02:28:37 Completed build of: dependencies/dbus-1-tqt - Mar 24 02:29:16 Beginning build of: dependencies/tqca-tls - Mar 24 02:29:16 Completed build of: dependencies/tqca-tls - Mar 24 02:29:30 Beginning build of: dependencies/libart-lgpl - Mar 24 02:29:30 Completed build of: dependencies/libart-lgpl - Mar 24 02:30:03 <crash libcaldav - patch in GIT> Beginning build of: dependencies/libcaldav - Mar 24 10:13:46 Completed build of: dependencies/libcaldav - Mar 24 10:15:01 Beginning build of: dependencies/libcarddav - Mar 24 10:15:01 Completed build of: dependencies/libcarddav - Mar 24 10:15:29 <crash sip4-tqt - '-W' from somewhere> Beginning build of: dependencies/sip4-tqt - Mar 24 10:17:06 Completed build of: dependencies/sip4-tqt - Mar 24 10:17:51 Beginning build of: dependencies/python-tqt - Mar 24 10:20:12 Completed build of: dependencies/python-tqt - Mar 24 10:33:53 Beginning build of: tdelibs - Mar 24 10:33:53 Completed build of: tdelibs - Mar 24 11:16:21 Beginning build of: tdebase - Mar 24 11:16:21 Completed build of: tdebase - Mar 24 11:59:33 Beginning build of: libraries/libksquirrel - Mar 24 11:59:33 Completed build of: libraries/libksquirrel - Mar 24 12:04:33 Beginning build of: libraries/libkdcraw - Mar 24 12:04:33 Completed build of: libraries/libkdcraw - Mar 24 12:06:05 Beginning build of: libraries/libkexiv2 - Mar 24 12:06:05 Completed build of: libraries/libkexiv2 - Mar 24 12:07:06 Beginning build of: libraries/libkipi - Mar 24 12:07:06 Completed build of: libraries/libkipi - Mar 24 12:08:30 Beginning build of: libraries/kipi-plugins - Mar 24 12:08:30 Completed build of: libraries/kipi-plugins - Mar 24 12:16:21 Beginning build of: tdeutils - Mar 24 12:16:22 Completed build of: tdeutils - Mar 24 12:30:02 Beginning build of: tdemultimedia - Mar 24 12:30:02 Completed build of: tdemultimedia - Mar 24 12:31:55 Beginning build of: tdenetwork - Mar 24 12:31:55 Completed build of: tdenetwork - Mar 24 12:47:58 Beginning build of: tdeartwork - Mar 24 12:47:58 Completed build of: tdeartwork - Mar 24 12:51:57 Beginning build of: tdegames - Mar 24 12:51:57 Completed build of: tdegames - Mar 24 13:07:03 Beginning build of: tdetoys - Mar 24 13:07:03 Completed build of: tdetoys - Mar 24 13:09:49 Beginning build of: tdeedu - Mar 24 13:09:49 Completed build of: tdeedu - Mar 24 13:38:32 Beginning build of: tdegraphics - Mar 24 13:38:32 Completed build of: tdegraphics - Mar 24 14:07:33 Beginning build of: tdevelop - Mar 24 14:07:33 Completed build of: tdevelop - Mar 24 14:24:22 Beginning build of: tdeaddons - Mar 24 14:24:22 Completed build of: tdeaddons - Mar 24 14:31:39 Beginning build of: tdepim - Mar 24 14:31:39 Completed build of: tdepim - Mar 24 15:24:41 Beginning build of: tdewebdev - Mar 24 15:24:41 Completed build of: tdewebdev - Mar 24 15:32:49 Beginning build of: applications/dolphin - Mar 24 15:32:49 Completed build of: applications/dolphin - Mar 24 15:34:11 Beginning build of: applications/gtk-qt-engine - Mar 24 15:34:11 Completed build of: applications/gtk-qt-engine - Mar 24 15:34:47 Beginning build of: applications/kgtk-qt3 - Mar 24 15:34:47 Completed build of: applications/kgtk-qt3 - Mar 24 15:35:04 Beginning build of: applications/kio-locate - Mar 24 15:35:04 Completed build of: applications/kio-locate - Mar 24 15:35:32 Beginning build of: applications/rosegarden - Mar 24 15:35:32 Completed build of: applications/rosegarden - Mar 24 15:57:07 Beginning build of: applications/tde-style-qtcurve - Mar 24 15:57:07 Completed build of: applications/tde-style-qtcurve - Mar 24 15:58:08 Beginning build of: applications/tdesvn - Mar 24 15:58:08 Completed build of: applications/tdesvn - Mar 24 16:02:21 Beginning build of: applications/kpowersave - Mar 24 16:02:21 Completed build of: applications/kpowersave - Mar 24 16:04:00 Beginning build of: applications/wlassistant - Mar 24 16:04:00 Completed build of: applications/wlassistant - Mar 24 16:04:37 Beginning build of: applications/abakus - Mar 24 16:04:37 Completed build of: applications/abakus - Mar 24 16:05:29
Script Execution Time: 345 minutes
Testing after dinner...
On 03/24/2012 03:36 PM, Darrell Anderson wrote:
I have a patch that I ask somebody either test or
provide a peer review signoff.
I added new code, albeit only a single "else if" test.
I have tested the patch in both a VM and physical
machine. No more halts in the session startup.
Here is the patch:
http://humanreadable.nfshost.com/trinity/patches/tdebase/tdebase-tdeinit_pha...
If testing the patch then do so like this:
- Before patching and updating tdebase, start a Trinity session.
- Open KControl, Appearance& Themes, Window Decorations.
- Toggle any nominal setting and select the Apply button.
- Exit the session.
- Login to start a new session.
- Verify the session stalls and won't start.
- Restore twinrc: edit twinrc config file and delete the group section "ThirdPartyWM."
- Login to verify that once again Trinity starts.
- Log out.
- Install the patched tdebase.
- Start the session and repeat the KControl exercise.
- Exit the session.
- Start the session.
- Verify Trinity now starts without stalling.
Anybody?
Darrell
Darrell,
I just ran into this error again on an i686 install:
[tdeinit] Launched KLauncher, pid = 1479 result = 0 [tdeinit] opened connection to :0 [tdeinit] Launched KDED, pid = 1480 result = 0 [kded] KDE Daemon (kded) already running. [tdeinit] Got EXT_EXEC 'kbuildsycoca' from launcher. [kbuildsycoca] kbuildsycoca running... [kbuildsycoca] Reusing existing ksycoca. [tdeinit] PID 1482 terminated. [tdeinit] PID 1480 terminated. [tdeinit] Launched 'kcminit_startup', pid = 1483 result = 0 [tdeinit] Got SETENV 'TDE_MULTIHEAD=false' from klauncher. [tdeinit] PID 1483 terminated. [starttde] tdeinit started successfully. [tdeinit] Got KWRAPPER 'ksmserver' from socket. [tdeinit] PID 1487 terminated. ksmserver: '<wm>' missing. ^^^^^^^^ ksmserver: Use --help to get a list of available command line options. [starttde] Shutting down Trinity...
I'm rebuilding tdebase now with patch and will let you know.
I just ran into this error again on an i686 install:
[tdeinit] Launched KLauncher, pid = 1479 result = 0 [tdeinit] opened connection to :0 [tdeinit] Launched KDED, pid = 1480 result = 0 [kded] KDE Daemon (kded) already running. [tdeinit] Got EXT_EXEC 'kbuildsycoca' from launcher. [kbuildsycoca] kbuildsycoca running... [kbuildsycoca] Reusing existing ksycoca. [tdeinit] PID 1482 terminated. [tdeinit] PID 1480 terminated. [tdeinit] Launched 'kcminit_startup', pid = 1483 result = 0 [tdeinit] Got SETENV 'TDE_MULTIHEAD=false' from klauncher. [tdeinit] PID 1483 terminated. [starttde] tdeinit started successfully. [tdeinit] Got KWRAPPER 'ksmserver' from socket. [tdeinit] PID 1487 terminated. ksmserver: '<wm>' missing. ^^^^^^^^ ksmserver: Use --help to get a list of available command line options. [starttde] Shutting down Trinity...
I'm rebuilding tdebase now with patch and will let you know.
The is good/expected. The first part of the test is only to confirm that the tester experiences the same failure. :)
Hopefully after the patch and you repeat the test the error does not occur. Just make sure to edit twinrc before starting the new rebuilt tdebase. :)
Darrell
On 03/27/2012 09:33 PM, Darrell Anderson wrote:
I just ran into this error again on an i686 install:
[tdeinit] Launched KLauncher, pid = 1479 result = 0 [tdeinit] opened connection to :0 [tdeinit] Launched KDED, pid = 1480 result = 0 [kded] KDE Daemon (kded) already running. [tdeinit] Got EXT_EXEC 'kbuildsycoca' from launcher. [kbuildsycoca] kbuildsycoca running... [kbuildsycoca] Reusing existing ksycoca. [tdeinit] PID 1482 terminated. [tdeinit] PID 1480 terminated. [tdeinit] Launched 'kcminit_startup', pid = 1483 result = 0 [tdeinit] Got SETENV 'TDE_MULTIHEAD=false' from klauncher. [tdeinit] PID 1483 terminated. [starttde] tdeinit started successfully. [tdeinit] Got KWRAPPER 'ksmserver' from socket. [tdeinit] PID 1487 terminated. ksmserver: '<wm>' missing. ^^^^^^^^ ksmserver: Use --help to get a list of available command line options. [starttde] Shutting down Trinity...
I'm rebuilding tdebase now with patch and will let you know.
The is good/expected. The first part of the test is only to confirm that the tester experiences the same failure. :)
Hopefully after the patch and you repeat the test the error does not occur. Just make sure to edit twinrc before starting the new rebuilt tdebase. :)
Darrell
Darrell,
push it! Confirmed. Built with patch, restored twinrc containing:
[ThirdPartyWM] WMAdditionalArguments= WMExecutable=twin
Installed patched tdebase, startx -> no hang! Good catch. It would have taken me a week to figure out the problem preventing start was the 3 spurious lines in twinrc!
Now if you can pull the same rabbit out of the hat with png15, we are in business :)
push it! Confirmed. Built with patch, restored twinrc containing:
[ThirdPartyWM] WMAdditionalArguments= WMExecutable=twin
Installed patched tdebase, startx -> no hang! Good catch. It would have taken me a week to figure out the problem preventing start was the 3 spurious lines in twinrc!
Now if you can pull the same rabbit out of the hat with png15, we are in business :)
I'm no magician. Just stubborn. :)
If you find some libpng 1.5 patches then I'll help test, troubleshoot, and massage them as necessary for the tqt layer.
Darrell
push it! Confirmed. Built with patch, restored twinrc containing:
[ThirdPartyWM] WMAdditionalArguments= WMExecutable=twin
Installed patched tdebase, startx
-> no hang! Good catch. It would have taken
me a week to figure out the problem preventing start
was the 3 spurious lines in twinrc!
Pushed in GIT hash 1c479363908f1967347f51ba8f4044bdb321d31c.
Darrell
-
Darrell Anderson -
David C. Rankin