Bug 835313 - ibus-init.el flaw: forgets to test whether it runs under X
Summary: ibus-init.el flaw: forgets to test whether it runs under X
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs-ibus
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Daiki Ueno
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-26 00:19 UTC by aeb
Modified: 2012-07-10 16:31 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-10 16:27:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description aeb 2012-06-26 00:19:26 UTC
Description of problem:
start emacs and see error messages printed by ibus

Version-Release number of selected component (if applicable):
emacs-ibus-0.3.1-1.fc16.noarch (bug in emacs-ibus.spec, not upstream)

How reproducible:

Steps to Reproduce:
1. do a remote login to a Fedora 16 machine
2. start emacs -nw on an xterm
3. see error messages
  
Actual results:
% emacs -nw
IBus: Xlib.error.DisplayConnectionError: Can't connect to display "...": [Errno 113] No route to host
IBus: Process ibus-agent exited abnormally with code 1
IBus: error: ("process: ibus-agent  status: exit")

Expected results:
Correct emacs startup.

Additional info:
Clearly ibus expects to be started only on X. But emacs-ibus.spec creates a 2-line file ibus-init.el that starts ibus unconditionally, without testing (equal window-system 'x) or so.

Comment 1 Daiki Ueno 2012-06-27 01:29:51 UTC
ibus.el itself has such a check in ibus-mode-on:

(defun ibus-mode-on ()
  "Turn ibus-mode on."
  (interactive)
  (if (not (or (eq window-system 'x) ; X frame
               (getenv "DISPLAY")))  ; non-X frame under X session
      (ibus-mode-quit)
  ...)

so I can't reproduce the problem.  Python backtrace from abrt would be helpful.

Comment 2 aeb 2012-06-27 01:53:38 UTC
IBus: Surrounding text support enabled
IBus: Traceback (most recent call last):
IBus:   File "/usr/libexec/ibus-el-agent", line 223, in <module>
IBus:     display = Xlib.display.Display()
IBus:   File "/usr/lib/python2.7/site-packages/Xlib/display.py", line 83, in __init__
IBus:     self.display = _BaseDisplay(display)
IBus:   File "/usr/lib/python2.7/site-packages/Xlib/display.py", line 65, in __init__
IBus:     apply(protocol.display.Display.__init__, (self, ) + args, keys)
IBus:   File "/usr/lib/python2.7/site-packages/Xlib/protocol/display.py", line 49, in __init__
IBus:     self.socket = connect.get_socket(name, host, displayno)
IBus:   File "/usr/lib/python2.7/site-packages/Xlib/support/connect.py", line 79, in get_socket
IBus:     return mod.get_socket(dname, host, dno)
IBus:   File "/usr/lib/python2.7/site-packages/Xlib/support/unix_connect.py", line 92, in get_socket
IBus:     raise error.DisplayConnectionError(dname, str(val))
IBus: Xlib.error.DisplayConnectionError: Can't connect to display "foobar:0.0": [Errno 113] No route to host
IBus:
IBus: Process ibus-agent exited abnormally with code 1
IBus: error: ("process: ibus-agent  status: exit")

Comment 3 Daiki Ueno 2012-06-27 03:00:42 UTC
(In reply to comment #2)

> IBus: Xlib.error.DisplayConnectionError: Can't connect to display
> "foobar:0.0": [Errno 113] No route to host

So, you set the invalid value to $DISPLAY on the remote server.
I think this is a user error.

Comment 4 aeb 2012-06-27 06:21:59 UTC
The value of $DISPLAY was caused by a different bug.
But emacs was started as "emacs -nw", so DISPLAY is irrelevant,
emacs was told not to use X.

Comment 5 Daiki Ueno 2012-06-27 06:32:28 UTC
As you see "non-X frame under X session" in the code quoted in comment 1, it is the situation supported by upstream.  Even if you start emacs with "emacs -nw", you can still create an X frame with M-x make-frame-on-display :0.

Comment 6 aeb 2012-06-27 13:46:13 UTC
I do not mind that ibus supports this situation. But I mind that the RedHat ibus-init that is loaded by default tries to access some X server. If the user asks for something, then the consequences are for the user. If RedHat init files are such that emacs -nw tries to open a window on some remote machine, that is a serious security risk. (Situation: login from outside to a gateway machine. Then login from the gateway to an internal machine. Start emacs -nw on the internal machine. Now emacs tries to connect to X on the gateway. Ach.)

Comment 7 Daiki Ueno 2012-06-28 01:29:01 UTC
OK, now I think calling ibus-mode-on in ibus-init.el is too much for users regardless of -nw option.  Instead I would add autoloads for ibus-mode-on.

Comment 8 Fedora Update System 2012-06-28 08:20:38 UTC
emacs-ibus-0.3.1-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/emacs-ibus-0.3.1-2.fc17

Comment 9 Fedora Update System 2012-06-28 08:20:58 UTC
emacs-ibus-0.3.1-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/emacs-ibus-0.3.1-2.fc16

Comment 10 Fedora Update System 2012-06-30 08:26:28 UTC
Package emacs-ibus-0.3.1-2.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing emacs-ibus-0.3.1-2.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-10045/emacs-ibus-0.3.1-2.fc16
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2012-07-10 16:27:27 UTC
emacs-ibus-0.3.1-2.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Fedora Update System 2012-07-10 16:31:42 UTC
emacs-ibus-0.3.1-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.