>to resolve bug report 853 is ready a patch that selects between
>"sudo su"
>and "su" depending on the build option WITH_SUDO_TDESU_BACKEND.
>
>But as we have noticed, also on Ubuntu is used
>WITH_SUDO_TDESU_BACKEND=OFF.
>This would mean that even Ubuntu would not be used "sudo".
>
>That's why I asked what solution to choose for Ubuntu packaging?
>
>1) Apply the patch and leave WITH_SUDO_TDESU_BACKEND=OFF
>2) Apply the patch, but change WITH_SUDO_TDESU_BACKEND=ON
>3) Make a separate build option WITH_SUDO_KONSOLE_BACKEND
>
>See: http://bugs.pearsoncomputing.net/show_bug.cgi?id=853
I'm not an Ubuntu user but I'm fine with adding
WITH_SUDO_KONSOLE_BACKEND as a new option.
Would the default be WITH_SUDO_KONSOLE_BACKEND=OFF, meaning sudo-
based disto packagers would have to explicitly change that option
to WITH_SUDO_KONSOLE_BACKEND=ON?
Darrell
Hi all,
to resolve bug report 853 is ready a patch that selects between "sudo su"
and "su" depending on the build option WITH_SUDO_TDESU_BACKEND.
But as we have noticed, also on Ubuntu is used WITH_SUDO_TDESU_BACKEND=OFF.
This would mean that even Ubuntu would not be used "sudo".
That's why I asked what solution to choose for Ubuntu packaging?
1) Apply the patch and leave WITH_SUDO_TDESU_BACKEND=OFF
2) Apply the patch, but change WITH_SUDO_TDESU_BACKEND=ON
3) Make a separate build option WITH_SUDO_KONSOLE_BACKEND
See: http://bugs.pearsoncomputing.net/show_bug.cgi?id=853
Thank you
Slavek
>Agreed, the behavior should be as you described and should be
>consistent all the times.
>Since you can reproduce the problem several times, I think there
>is enough material to open a new bug report.
Tim implied the witnessed behavior is correct. One of you gurus
would have to walk through the code to determine whether locking is
expected when not explicitly selected from the menu.
Darrell
>Darrell, how long did you work in one session before switching to
>the other one? Just wondering if there is some kind of inactivity
>timer that locks a session when not being used for a while. That
>may explain the different behavior you have seen, even though it
>sounds a little weird to say the least
Not long, about 5 seconds. Another person suggested there might be
a timeout of some sort regulating when the lock dialog appears.
Yet I'm confused. Seems to me there should be no password required
when using 'Start New Session' --- that is what the 'Lock Current &
Start New Session' option should be for.
Darrell
>AFAIK "Start New Session" does not lock the current session,
>whereas
>selecting an existing session will lock the current session. On my
>systems
>there is a second menu entry for "Lock Current & Start New
>Session" if it
>is desired to lock the screen before starting the new session.
That is confusing behavior to me. I'll guess confusing to others
too.
Darrell
>I don't know whether this is a security glitch or PEBKAC.
>
>I was testing the graphical login with TDM:
>
>* I logged in as User 1.
>* From the TDE menu I selected Switch User->Start New Session.
>* I logged in as User 2.
>* I switched to User 1 *without* needing a password.
>* I switched to User 2 and needed a password.
>* I typed the password, switched to User 1, and needed a password.
>
>I repeated this exercise three times with a system reboot each
>time. Each time the first instance of switching did not require a
>password.
>
>Further, I was not always asked for a password on subsequent
>switching, especially when I used the keyboard toggles of Ctrl-Alt-
>
>F7 and Ctrl-Alt-F8.
>
>SAK is disabled.
>
>I only used Switch User->Start New Session. I did not use Switch
>User->Lock Current & Start New Session.
>
>Thoughts?
BTW, seems to me there should be no password required when using
'Start New Session' --- that is what the 'Lock Current & Start New
Session' option should be for?
Darrell
All,
I don't know whether this is a security glitch or PEBKAC.
I was testing the graphical login with TDM:
* I logged in as User 1.
* From the TDE menu I selected Switch User->Start New Session.
* I logged in as User 2.
* I switched to User 1 *without* needing a password.
* I switched to User 2 and needed a password.
* I typed the password, switched to User 1, and needed a password.
I repeated this exercise three times with a system reboot each
time. Each time the first instance of switching did not require a
password.
Further, I was not always asked for a password on subsequent
switching, especially when I used the keyboard toggles of Ctrl-Alt-
F7 and Ctrl-Alt-F8.
SAK is disabled.
I only used Switch User->Start New Session. I did not use Switch
User->Lock Current & Start New Session.
Thoughts?
Darrell
All,
After resolving bug report 1704 I searched the Trinity source tree
for additional occurrences of 'kde-'. I found several instances of
some XDG mimetype references that have not been converted to TDE
nomenclature. The list:
x-kde-internaluid
x-kde-type
x-kde-cutselection
x-kde-urilist
A short list, yet I'm curious whether any of these instances could
be causing or are related to reported problems in Trinity.
To see these instances in context, grep tdebase, tdelibs, tdepim,
krusader, basket.
Should these instances be converted to x-tde-*?
Darrell
Hi all,
after commit 99b03be6 I have on a test machine in .xsession-errors many
such reports. Note that it is the testing machine, on which is now the
only active screen saver.
TQThreadInstance::finish: In TQThreadInstance::finish for thread 0x1508ad0
TQThreadInstance::finish: In TQThreadInstance::finish for thread 0x150b400
TQThreadInstance::finish: In TQThreadInstance::finish for thread 0x150afb0
TQThreadInstance::finish: In TQThreadInstance::finish for thread 0x1508af0
TQThreadInstance::finish: In TQThreadInstance::finish for thread 0x150b420
To this I have two questions:
1) How can such a report be useful when there is no knowing what
applications are affected?
2) Tim, why you use in such reports, a new lines with "\r"?
Thanks
Slavek
