Bugzilla Bug 158469

If you install gksu, you will get a "Root Terminal" menu item inside of
Accessories.  It attempts to use gksu to launch a terminal, but the executable
it tries to launch is `x-terminal-emulator`.  It looks like debian creates some
symlinks or something for this.  It might be good to patch it to use
gnome-terminal?

Just an update on this bug:

I tried to do this, and discovered that arm has no keywords for any
gnome-terminal.  This makes it a bit hard to depend on it...

My current thought is that I'll stop installing that misleading desktop file. 
I'm open to alternative suggestions.

yeah, this kinda a tough one, the only way I can think of is kinda a
headache...creating some sort of eselect module for it.  Or maybe just change
the default to xterm and let people change it manually if they want.

Why doesn't it respect the gnome preferred application's terminal as discussed
here:

http://forums.gentoo.org/viewtopic-t-524578.html

Yeah, I was just thinking about this.  One idea, is to change the Exec line of
the .desktop file and remove the gksu.  Then create an x-terminal-emulator
shell script that reads the gconf keys for the user and launches that with the
gksu command.


TERMINAL_APP=$(gconftool-2 --get "/desktop/gnome/applications/terminal/exec")

$(gksu ${TERMINAL_APP})

Seems fairly simple, and we already dep on gconf.  But there could be other
issues that haven't crossed my mind.

It's possible.  I'll look into what debian does, when I get a chance.  The
issue is what to do if that is set to gnome-terminal, but it's not installed,
for example.  There's no reason why the program in that setting should be
installed, unless we've depped on it.

*** Bug 164451 has been marked as a duplicate of this bug. ***

Okay, so Debian has some complex system for terminal emulators to register
themselves at various priorities.  That's not something I want to maintain.  At
this point, I see only a couple of possiblities: add a dep on gnome-terminal
under the gnome USE flag, and arm and sh have to deal; Remove the desktop file
entirely (I don't like this option, it's a useful thing to have); Move the
desktop file to some other package that deps on gksu, say gnome-terminal.

Anyone else come up with any possibilites?  Keep in mind, and program we run
*must* be depped on.

I've created a script file

'''
#!/bin/bash

TERMINAL_APP=$(gconftool-2 --get "/desktop/gnome/applications/terminal/exec")

TERMINAL_APP_EXEC_ARG=$(gconftool-2 --get
"/desktop/gnome/applications/terminal/exec_arg")

$(gksu ${TERMINAL_APP})

exit 0

'''

and saved this bad boy in /usr/sbin/<whatever you want>


Then I changed the .desktop file to launch the script (without gksu cause it
gets called in the script) and I'm happy.

That's no good.  We have to know what that script is calling, and ensure it's
installed via a dep.

(In reply to comment #9)
> That's no good.  We have to know what that script is calling, and ensure it's
> installed via a dep.
> 

well it doesn't work at all currently and if we do that, then the user might
just be pointed to how to change the setting in gconf like what evolution
ebuild does for non-gnome users. @herd, what do you think ?

(In reply to comment #0)
> If you install gksu, you will get a "Root Terminal" menu item inside of
> Accessories.  It attempts to use gksu to launch a terminal, but the executable
> it tries to launch is `x-terminal-emulator`.  It looks like debian creates some
> symlinks or something for this.  It might be good to patch it to use
> gnome-terminal?
> 

Easy workaround "ln -s /usr/bin/gnome-terminal /usr/bin/x-terminal-emulator"

(In reply to comment #10)
> (In reply to comment #9)
> > That's no good.  We have to know what that script is calling, and ensure it's
> > installed via a dep.
> > 
> 
> well it doesn't work at all currently and if we do that, then the user might
> just be pointed to how to change the setting in gconf like what evolution
> ebuild does for non-gnome users. @herd, what do you think ?

The message idea sounds good. In addition to this, how about:

x-terminal-emulator can be a little package that does the gconf magic, and if
that program doesn't exist, fires up gnome-terminal. If gnome-terminal doesn't
exist, it displays a message like the one in the ebuild (it can also use zenity
to throw the popup up if it's present).

I can hack up this x-terminal-emulator if it sounds okay. Also,
x-terminal-emultaor is probably wrong nomenclature if we want to use
gconf/gnome-terminal as the default. g-terminal-emulator or something like that
probably makes more sense. :)

*** Bug 223251 has been marked as a duplicate of this bug. ***

Okay, I've just taken the simple out for this.  If USE gnome, then the .desktop
will refer to gnome-terminal, and there's a dep.  If ! USE gnome, then the
.desktop isn't installed at all.  If someone is willing to knock up a good
script to do this (preferably with eselect) I'm more than willing to take it.

(In reply to comment #14)
> Okay, I've just taken the simple out for this.  If USE gnome, then the .desktop
> will refer to gnome-terminal, and there's a dep.  If ! USE gnome, then the
> .desktop isn't installed at all.  If someone is willing to knock up a good
> script to do this (preferably with eselect) I'm more than willing to take it.

May I suggest that the Icon in the ".desktop" be changed to "gnome-terminal"?
It is much better looking than the default one.

I agree it looks better, but it's probably a good thing that the root terminal
icon looks different, so I'll leave it for now.

gksu-2.0.0-r1:

Gnome-terminal's default profile (for root) determines what it does when gksu
opens it.  On my system this default profile starts a shell as an unprivilaged
user, thus defeating the whole purpose of gksu.  

Not knowing what root's default profile would do, it's possibly incorrect for
gksu to invoke gnome-terminal--unless there's some way of disabling the profile
mechanism. I wish gnome-terminal had a "--no-default-profile" option, but
couldn't find anything like that.

gksu "/usr/bin/gnome-terminal -e su - " gives the desired result; but that's so
redundant.

*** Bug 254213 has been marked as a duplicate of this bug. ***

(In reply to comment #17)
> gksu-2.0.0-r1:
> 
> Gnome-terminal's default profile (for root) determines what it does when gksu
> opens it.  On my system this default profile starts a shell as an unprivilaged
> user, thus defeating the whole purpose of gksu.  
> 
> Not knowing what root's default profile would do, it's possibly incorrect for
> gksu to invoke gnome-terminal--unless there's some way of disabling the profile
> mechanism. I wish gnome-terminal had a "--no-default-profile" option, but
> couldn't find anything like that.
> 
> gksu "/usr/bin/gnome-terminal -e su - " gives the desired result; but that's so
> redundant.
> 

This (gksu "/usr/bin/gnome-terminal -e su - ") does NOT give me the desired /
expected result. 

$ gksu "/usr/bin/gnome-terminal -e su - "
Xlib:  extension "RANDR" missing on display "127.0.0.1:2.0".
Xlib: connection to "127.0.0.1:2.0" refused by server
Xlib: Client is not authorized to connect to Server
Cannot open display: 
Run '/usr/bin/gnome-terminal --help' to see a full list of available command
line options.

> (In reply to comment #17)
> > gksu-2.0.0-r1:
> > 
> $ gksu "/usr/bin/gnome-terminal -e su - "
> Xlib:  extension "RANDR" missing on display "127.0.0.1:2.0".
> Xlib: connection to "127.0.0.1:2.0" refused by server
> Xlib: Client is not authorized to connect to Server
> Cannot open display: 

The display tried was ":2.0" and there was an authorization problem connecting
to it.  

Is this is a case of logging in to a remote system from X running on another
system?  The display is usually ":0.0" when running locally?  If this is a
remote session, then some combination of the xhost command and use of the
DISPLAY environment variable should help.  Something similar may arise from
having multiple X servers on the local host.

Also, running  gksu "/usr/bin/gnome-terminal -e su" without the final hyphen,
avoiding a new session and preserving the DISPLAY variable, might help; the
resulting environment (PATH, etc.) in gnome-terminal would be mostly the user's
instead of root's.

(In reply to comment #20)
> > (In reply to comment #17)
> > > gksu-2.0.0-r1:
> > > 
> > $ gksu "/usr/bin/gnome-terminal -e su - "
> > Xlib:  extension "RANDR" missing on display "127.0.0.1:2.0".
> > Xlib: connection to "127.0.0.1:2.0" refused by server
> > Xlib: Client is not authorized to connect to Server
> > Cannot open display: 
> 
> The display tried was ":2.0" and there was an authorization problem connecting
> to it.  
> 
> Is this is a case of logging in to a remote system from X running on another
> system?  The display is usually ":0.0" when running locally?  If this is a
> remote session, then some combination of the xhost command and use of the
> DISPLAY environment variable should help.  Something similar may arise from
> having multiple X servers on the local host.
> 
> Also, running  gksu "/usr/bin/gnome-terminal -e su" without the final hyphen,
> avoiding a new session and preserving the DISPLAY variable, might help; the
> resulting environment (PATH, etc.) in gnome-terminal would be mostly the user's
> instead of root's.
> 

The display number is correct: my client connects to Xvnc server session
running on remote server.

Running command gksu "/usr/bin/gnome-terminal -e su" without the final hyphen
as you suggested does bring up the terminal, as wanted.
There are warning messages, but they don't mattter to me as long as I get
result.
Thank you.

$ gksu "/usr/bin/gnome-terminal -e su"
Xlib:  extension "RANDR" missing on display "127.0.0.1:2.0".
Xlib:  extension "RANDR" missing on display "127.0.0.1:2.0".

(gnome-terminal:31256): GnomeUI-WARNING **: While connecting to session
manager:
Authentication Rejected, reason : None of the authentication protocols
specified are supported and host-based authentication failed.