Would somebody who does not use a sudo based distro please test whether this happens on your system?
1. Start kate as normal user.
2. Start a separate kate session as root using 'tdesu kate'.
Two separate sessions should be open. In the second session you should be able to view the contents of /root.
If only one session is open then you are experiencing the same problem.
No other app seems affected by this behavior.
Thanks much.
Darrell
Would somebody who does not use a sudo based distro please test whether this happens on your system?
Start kate as normal user.
Start a separate kate session as root using 'tdesu kate'.
Two separate sessions should be open. In the second session you should be able to view the contents of /root.
If only one session is open then you are experiencing the same problem.
No other app seems affected by this behavior.
Thanks much.
I found the problem. I don't know the correct long-term solution.
The problem is caused by the patch pushed in GIT hash 2b178a53, 2011-10-26 (SVN revision 1260900). The patch was pushed to resolve bug report 394.
I rebuilt tdebase with that patch reversed. Now I have no problems whatsoever using kate as normal user and concurrently as root through tdesu. The patches from bug report 692 have no ill effects either as I now have both my normal user kate and root's kate configured to use Calvin's patch for MDI usage. When I first start kate as root and then concurrently run kate from konsole as normal user, I no longer see the weird dcop warnings.
Thus far I do not notice any xsession "Klauncher could not be reached via dcop" errors as originally reported in the bug report.
Reversing the patch restores the code to 3.5.10 status. I run both KDE3 and TDE and in KDE3 I notice none of these problems. With the reversed patch, behavior is now the same in both desktops.
Yet as I mentioned, I don't know whether the patch is correct. If the patch is required, then the change has nasty effects and needs resolution elsewhere.
Darrell
Would somebody who does not use a sudo based distro please test whether this happens on
your system?
Start kate as normal user.
Start a separate kate session as root using 'tdesu kate'.
Two separate sessions should be open. In the second session you should be able to view the contents of /root.
If only one session is open then you are experiencing the same problem.
No other app seems affected by this behavior.
Thanks much.
I found the problem. I don't know the correct long-term solution.
The problem is caused by the patch pushed in GIT hash 2b178a53, 2011-10-26 (SVN revision 1260900). The patch was pushed to resolve bug report 394.
I rebuilt tdebase with that patch reversed. Now I have no problems whatsoever using kate as normal user and concurrently as root through tdesu. The patches from bug report 692 have no ill effects either as I now have both my normal user kate and root's kate configured to use Calvin's patch for MDI usage. When I first start kate as root and then concurrently run kate from konsole as normal user, I no longer see the weird dcop warnings.
Thus far I do not notice any xsession "Klauncher could not be reached via dcop" errors as originally reported in the bug report.
Reversing the patch restores the code to 3.5.10 status. I run both KDE3 and TDE and in KDE3 I notice none of these problems. With the reversed patch, behavior is now the same in both desktops.
Yet as I mentioned, I don't know whether the patch is correct. If the patch is required, then the change has nasty effects and needs resolution elsewhere.
David,
As you participated in bug report 394, would you please include the reversed patch as part of your testing to help notice whether reversing this patch resurrects any of the issues reported back then?
This will need to be a long-term observation. Just plug the patch into your other patches and let time tell the story.
I am including the reversed patch in my builds. Thus far I have not noticed any of the problems originally reported.
Thanks.
Darrell
On 04/10/2012 12:29 PM, Darrell Anderson wrote:
David,
As you participated in bug report 394, would you please include the reversed patch as part of your testing to help notice whether reversing this patch resurrects any of the issues reported back then?
This will need to be a long-term observation. Just plug the patch into your other patches and let time tell the story.
I am including the reversed patch in my builds. Thus far I have not noticed any of the problems originally reported.
Thanks.
OK,
I'll digest what you are saying (along with lunch) and report back :) I did just re-read 394 and I just tested in my current build and I do NOT experience the same problem that was originally reported in 394. I can open System->Super User->File Manager-Super User Mode, then do stuff, then close it and open all my apps as a normal user.
I'll find the commit and undo the patch for testing, but it looks like the original patch worked (sure hate to throw the baby out with the bath water :)
Will report back...
I'll digest what you are saying (along with lunch) and report back :) I did just re-read 394 and I just tested in my current build and I do NOT experience the same problem that was originally reported in 394. I can open System->Super User->File Manager-Super User Mode, then do stuff, then close it and open all my apps as a normal user.
I'll find the commit and undo the patch for testing, but it looks like the original patch worked (sure hate to throw the baby out with the bath water :)
No problems seen here. I'm thinking the original problem was caused by something else, possibly some of those inadvertent "tq" conversions. Almost all of that has since been scrubbed.
Here is the patch:
http://www.trinitydesktop.org/patches/1319655787:2b178a5398a22960e048c2d1030...
If things blow up again on your system then note that in the 394 bug report. :)
Darrell
On Tuesday 10 of April 2012 22:39:57 Darrell Anderson wrote:
I'll digest what you are saying (along with lunch) and report back :) I did just re-read 394 and I just tested in my current build and I do NOT experience the same problem that was originally reported in 394. I can open System->Super User->File Manager-Super User Mode, then do stuff, then close it and open all my apps as a normal user.
I'll find the commit and undo the patch for testing, but it looks like the original patch worked (sure hate to throw the baby out with the bath water :)
No problems seen here. I'm thinking the original problem was caused by something else, possibly some of those inadvertent "tq" conversions. Almost all of that has since been scrubbed.
Here is the patch:
http://www.trinitydesktop.org/patches/1319655787:2b178a5398a22960e048c2d103 095cb312a8039c.diff
If things blow up again on your system then note that in the 394 bug report. :)
Darrell
The revert seems to be interesting for prepared updates for the R13. But I hesitate whether I can risk to include it?
Slávek --
Here is the patch:
http://www.trinitydesktop.org/patches/1319655787:2b178a5398a22960e048c2d1030...
If things blow up again on your system then note that
in the 394 bug report. :)
The revert seems to be interesting for prepared updates for the R13. But I hesitate whether I can risk to include it?
Yeah, the patch was committed 2011-10-26 and 3.5.13 was released 2011-11-1.
You folks have a better grasp of those things than me. :)
I suppose somebody could back port the patch to a 3.5.13 test system and test for several days. My guess is the errors/warnings reported in the bug report will reappear because whatever was the true cause of those messages was not really fixed with that patch. I think this one of those moments when one problem masked another. Therefore reverting that one patch in 3.5.13 without the other unknown fixes is likely to resurrect those messages.
I'm guessing something else changed along side of or after that one patch that actually resolved the messages.
Possibly browsing through the Commit Patches web page might reveal possible candidates. Anything related to dcop is possible, but if the cause was due to some tq/TQ cleanup then we are unlikely to ever know.
If I was an admin or distro maintainer, unless I could find the other fix that likely resolved the problem, I'd leave 3.5.13 as is and revert the patch only in GIT builds.
I can only offer that reverting the patch in GIT solved "my" problem of running kate concurrently as normal and root users. Nobody else has yet confirmed the same problem exists for them.
Darrell
Darrell Anderson wrote:
Yeah, the patch was committed 2011-10-26 and 3.5.13 was released 2011-11-1.
You folks have a better grasp of those things than me. :)
I suppose somebody could back port the patch to a 3.5.13 test system and test for several days. My guess is the errors/warnings reported in the bug report will reappear because whatever was the true cause of those messages was not really fixed with that patch. I think this one of those moments when one problem masked another. Therefore reverting that one patch in 3.5.13 without the other unknown fixes is likely to resurrect those messages.
I'm guessing something else changed along side of or after that one patch that actually resolved the messages.
Possibly browsing through the Commit Patches web page might reveal possible candidates. Anything related to dcop is possible, but if the cause was due to some tq/TQ cleanup then we are unlikely to ever know.
If I was an admin or distro maintainer, unless I could find the other fix that likely resolved the problem, I'd leave 3.5.13 as is and revert the patch only in GIT builds.
I can only offer that reverting the patch in GIT solved "my" problem of running kate concurrently as normal and root users. Nobody else has yet confirmed the same problem exists for them.
Darrell
I can confirm I'm not getting this issue on my 3.5.13 system running on Debian Squeeze with official packages. kdesu starts a new kate session.
-
Darrell Anderson -
David C. Rankin -
Old Laptop -
Slávek Banko