Description of problem: run ibus-setup produces IBUS-CRITICAL ** Traceback. Version-Release number of selected component (if applicable): ibus-1.4.99.20120203-3.fc17.x86_64 How reproducible: 100% Steps to Reproduce: 1. Install Fedora17 Desktop from http://alt.fedoraproject.org/pub/alt/nightly-composes/ 2. Select 'No Input Method' from Input Method Selector. 3. run ibus-setup from Terminal. Actual results: run ibus-setup produces IBUS-CRITICAL ** Traceback. Expected results: Should no traceback. Additional info: produce on en_US.
Created attachment 564865 [details] ibus-setup traceback
Created attachment 564900 [details] ibus-daemon --verbose
if run im-chooser and select ibus, then ibus-setup run properly, if run ibus-setup by disable ibus with im-chooser (No Input Method), then there is crash produced.
Created attachment 565169 [details] patch to fix ibus-setup crash when ibus-daemon is not running Though maybe I guess fujiwara-san already knows the cause, I'm attaching a patch as I recently encountered a similar issue with ibus-setup-hangul gi port :)
(In reply to comment #4) > Created attachment 565169 [details] > patch to fix ibus-setup crash when ibus-daemon is not running > > Though maybe I guess fujiwara-san already knows the cause, I'm attaching a > patch as I recently encountered a similar issue with ibus-setup-hangul gi port > :) Thanks but maybe it's one of the issues due to attachment 564900 [details] through the yesterday's discussion. Maybe need to check how %posttrans could work on readonly iso. I will try the nightly iso today.
It seems I don't see any problems after I run ibus-daemon. Do you have any problems after you run ibus-dameon?
(In reply to comment #6) > It seems I don't see any problems after I run ibus-daemon. > Do you have any problems after you run ibus-dameon? fujiwara, That's right, there are not any problems after run ibus-dameon, I just Log Out and Log in the session to verify it, but for ibus-dameon --verbose still had the IBUS-WARNING message, and the second issue, run ibus-setup, the "IBus daemon is not started. Do you want to start it now?" dialog should prompt when ibus-daemon is not running. Thanks.
Created attachment 565187 [details] ibus-setup works fine when ibus-daemon is running
Created attachment 565188 [details] ibus-daemon --verbose IBUS-WARNING
OK, I understood your problem is only the case ibus-daemon doesn't run. BTW, text attachments would be more useful for the log messages when you will file a bug next time. What I was surprised yesterday is that the dconf key '[general:engines_order]' does not exist in the attachment 564900 [details] but it seems a small bug and ibus dconf db exists correctly.
--- ibus-phuang/setup/main.py.orig +++ ibus-phuang/setup/main.py @@ -338,9 +338,11 @@ class Setup(object): # self.__bus.config_add_watch("/general/hotkey") # self.__bus.config_add_watch("/panel") except: - while self.__bus == None: + pass + finally: + while self.__bus == None or not self.__bus.is_connected(): message = _("IBus daemon is not started. Do you want to start it now?") - dlg = Gtk.MessageDialog(type = Gtk.MESSAGE_QUESTION, + dlg = Gtk.MessageDialog(type = Gtk.MessageType.QUESTION, buttons = Gtk.ButtonsType.YES_NO, message_format = message) id = dlg.run()
(In reply to comment #11) > + dlg = Gtk.MessageDialog(type = Gtk.MessageType.QUESTION, > buttons = Gtk.ButtonsType.YES_NO, > message_format = message) > id = dlg.run() Have you tested the change? There is also Gtk.MESSAGE_INFO below which should be Gtk.MessageType.INFO. Also, it seems that self.__bus.destroy() is necessary to get self.__bus.is_connected() condition is True.
(In reply to comment #12) > (In reply to comment #11) > > + dlg = Gtk.MessageDialog(type = Gtk.MessageType.QUESTION, > > buttons = Gtk.ButtonsType.YES_NO, > > message_format = message) > > id = dlg.run() > > Have you tested the change? I think this part is ok. > > There is also Gtk.MESSAGE_INFO below which should be Gtk.MessageType.INFO. > Also, it seems that self.__bus.destroy() is necessary to get > self.__bus.is_connected() condition is True. Yes, I noticed Gtk.MESSAGE_INFO after I updated this yesterday. But no self.__bus.destroy() is ok in my test. --- ibus-phuang/setup/main.py.orig +++ ibus-phuang/setup/main.py @@ -338,9 +338,11 @@ class Setup(object): # self.__bus.config_add_watch("/general/hotkey") # self.__bus.config_add_watch("/panel") except: - while self.__bus == None: + pass + finally: + while self.__bus == None or not self.__bus.is_connected(): message = _("IBus daemon is not started. Do you want to start it now?") - dlg = Gtk.MessageDialog(type = Gtk.MESSAGE_QUESTION, + dlg = Gtk.MessageDialog(type = Gtk.MessageType.QUESTION, buttons = Gtk.ButtonsType.YES_NO, message_format = message) id = dlg.run() @@ -351,6 +353,8 @@ class Setup(object): pid = os.spawnlp(os.P_NOWAIT, "ibus-daemon", "ibus-daemon", "--xim") time.sleep(1) try: + if self.__bus != None: + self.__bus.destroy() self.__bus = IBus.Bus() except: continue @@ -360,7 +364,7 @@ class Setup(object): " export XMODIFIERS=@im=ibus\n" " export QT_IM_MODULE=ibus" ) - dlg = Gtk.MessageDialog(type = Gtk.MESSAGE_INFO, + dlg = Gtk.MessageDialog(type = Gtk.MessageType.INFO, buttons = Gtk.ButtonsType.OK, message_format = message) id = dlg.run()
(In reply to comment #13) > Yes, I noticed Gtk.MESSAGE_INFO after I updated this yesterday. But no > self.__bus.destroy() is ok in my test. IBusBus is actually a singleton (see "_bus" variable in ibusbus.c) and need to be destroyed to trigger reconnect. > try: > + if self.__bus != None: > + self.__bus.destroy() > self.__bus = IBus.Bus() > except: > continue Hmm, this part still looks wrong. Since IBus.Bus() does not raise any exception when bus is not connected, you need to check self.__bus.is_connected() and continue if it returns False. Otherwise you will see a successful message dialog even if ibus-daemon fails to start. try: if self.__bus != None: self.__bus.destroy() self.__bus = IBus.Bus() if not self.__bus.is_connected(): continue except: continue
(In reply to comment #14) > Hmm, this part still looks wrong. Since IBus.Bus() does not raise any > exception when bus is not connected, you need to check > self.__bus.is_connected() and continue if it returns False. Otherwise you will > see a successful message dialog even if ibus-daemon fails to start. > > try: > if self.__bus != None: > self.__bus.destroy() > self.__bus = IBus.Bus() > if not self.__bus.is_connected(): > continue > except: > continue OK, revised. --- ibus-phuang/setup/main.py.orig +++ ibus-phuang/setup/main.py @@ -338,9 +338,13 @@ class Setup(object): # self.__bus.config_add_watch("/general/hotkey") # self.__bus.config_add_watch("/panel") except: - while self.__bus == None: + pass + finally: + if self.__bus != None and self.__bus.is_connected(): + return + while self.__bus == None or not self.__bus.is_connected(): message = _("IBus daemon is not started. Do you want to start it now?") - dlg = Gtk.MessageDialog(type = Gtk.MESSAGE_QUESTION, + dlg = Gtk.MessageDialog(type = Gtk.MessageType.QUESTION, buttons = Gtk.ButtonsType.YES_NO, message_format = message) id = dlg.run() @@ -351,21 +355,23 @@ class Setup(object): pid = os.spawnlp(os.P_NOWAIT, "ibus-daemon", "ibus-daemon", "--xim") time.sleep(1) try: + if self.__bus != None: + self.__bus.destroy() self.__bus = IBus.Bus() except: continue - message = _("IBus has been started! " - "If you can not use IBus, please add below lines in $HOME/.bashrc, and relogin your desktop.\n" - " export GTK_IM_MODULE=ibus\n" - " export XMODIFIERS=@im=ibus\n" - " export QT_IM_MODULE=ibus" - ) - dlg = Gtk.MessageDialog(type = Gtk.MESSAGE_INFO, - buttons = Gtk.ButtonsType.OK, - message_format = message) - id = dlg.run() - dlg.destroy() - self.__flush_gtk_events() + message = _("IBus has been started! " + "If you can not use IBus, please add below lines in $HOME/.bashrc, and relogin your desktop.\n" + " export GTK_IM_MODULE=ibus\n" + " export XMODIFIERS=@im=ibus\n" + " export QT_IM_MODULE=ibus" + ) + dlg = Gtk.MessageDialog(type = Gtk.MessageType.INFO, + buttons = Gtk.ButtonsType.OK, + message_format = message) + id = dlg.run() + dlg.destroy() + self.__flush_gtk_events() def __shortcut_button_clicked_cb(self, button, name, section, _name, entry): buttons = (Gtk.STOCK_CANCEL, Gtk.ResponseType.CANCEL,
(In reply to comment #15) > > Hmm, this part still looks wrong. Since IBus.Bus() does not raise any > > exception when bus is not connected, you need to check > > self.__bus.is_connected() and continue if it returns False. Otherwise you will > > see a successful message dialog even if ibus-daemon fails to start. > OK, revised. > > try: > + if self.__bus != None: > + self.__bus.destroy() > self.__bus = IBus.Bus() > except: > continue It has not changed from the previous version? Anyway, I would suggest that you should test it at least. That shouldn't be hard I guess. Though this bug sounds not that important for you, I wonder if it isn't the case of the final release criteria: https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria * All applications listed under the Applications menu or category must start successfully
(In reply to comment #16) > (In reply to comment #15) > > > Hmm, this part still looks wrong. Since IBus.Bus() does not raise any > > > exception when bus is not connected, you need to check > > > self.__bus.is_connected() and continue if it returns False. Otherwise you will > > > see a successful message dialog even if ibus-daemon fails to start. > > > OK, revised. > > > > > try: > > + if self.__bus != None: > > + self.__bus.destroy() > > self.__bus = IBus.Bus() > > except: > > continue > > It has not changed from the previous version? Anyway, I would suggest that you This was fixed in the previous one. I also suggest to close your cl on upstream by yourself and I will update it.
(In reply to comment #17) > > It has not changed from the previous version? > This was fixed in the previous one. No, the following check which I pointed out in comment #14 is missing (in neither the version posted here nor your upstream cl): if not self.__bus.is_connected(): continue You can easily reproduce the wrong behavior with: 1. stop ibus-daemon 2. sudo chmod -x /usr/bin/ibus-daemon 3. ibus-setup Then you will see "IBus has been started! ..." message. > I also suggest to close your cl on upstream by yourself and I will update it. Just filed: https://codereview.appspot.com/5716045/
(In reply to comment #18) > (In reply to comment #17) > > > It has not changed from the previous version? > > This was fixed in the previous one. > > No, the following check which I pointed out in comment #14 is missing (in > neither the version posted here nor your upstream cl): > > if not self.__bus.is_connected(): > continue > > You can easily reproduce the wrong behavior with: > > 1. stop ibus-daemon > 2. sudo chmod -x /usr/bin/ibus-daemon > 3. ibus-setup > > Then you will see "IBus has been started! ..." message. I don't see any problems. > > > I also suggest to close your cl on upstream by yourself and I will update it. > > Just filed: https://codereview.appspot.com/5716045/ Not sure why you're working on this while I accept this.
(In reply to comment #19) > I don't see any problems. Ah! You are right, I didn't notice the indentation change that moved the code showing the successful dialog out of the loop. Sorry for the noise. > > > I also suggest to close your cl on upstream by yourself and I will update it. > > Just filed: https://codereview.appspot.com/5716045/ > > Not sure why you're working on this while I accept this. ? perhaps I didn't understand your suggestion above.
I think your changes are not important at all. Personally I feel you just try to push your motivations instead of the bug fixes or feature implementations. Anyway I think your work is out of this issue and I don't like to review that again.
(In reply to comment #21) > I think your changes are not important at all. > Personally I feel you just try to push your motivations instead of the bug > fixes or feature implementations. > Anyway I think your work is out of this issue and I don't like to review that > again. I would apologize if you feel like I infringed on your play ground. However, I can't understand why you started working on your own patch before reviewing my patch. It didn't contain any flaw that I pointed out in comment #12. Anyway, I will file a bug at upstream first instead of the bugzilla from the next time.
(In reply to comment #22) > (In reply to comment #21) > > I think your changes are not important at all. > > Personally I feel you just try to push your motivations instead of the bug > > fixes or feature implementations. > > Anyway I think your work is out of this issue and I don't like to review that > > again. > > I would apologize if you feel like I infringed on your play ground. However, I > can't understand why you started working on your own patch before reviewing my > patch. It didn't contain any flaw that I pointed out in comment #12. That was the example fix and I didn't say it's finished and I don't think your patch is good for this easy fix. > Anyway, I will file a bug at upstream first instead of the bugzilla from the > next time.
ibus-fbterm-0.9.1-14.fc17, ibus-qt-1.3.1-8.fc17, ibus-handwrite-2.1.4-4.fc17, sunpinyin-2.0.3-4.fc17, ibus-input-pad-1.4.0-7.fc17, eekboard-1.0.5-4.fc17, ibus-skk-1.4.0-3.fc17, ibus-sayura-1.3.1-4.fc17, ibus-rawcode-1.3.1.20100707-7.fc17, ibus-m17n-1.3.3-9.fc17, ibus-hangul-1.4.0-5.fc17, ibus-chewing-1.3.10-3.fc17, ibus-pinyin-1.4.0-14.fc17, ibus-1.4.99.20120304-3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/FEDORA-2012-3532/ibus-fbterm-0.9.1-14.fc17,ibus-qt-1.3.1-8.fc17,ibus-handwrite-2.1.4-4.fc17,sunpinyin-2.0.3-4.fc17,ibus-input-pad-1.4.0-7.fc17,eekboard-1.0.5-4.fc17,ibus-skk-1.4.0-3.fc17,ibus-sayura-1.3.1-4.fc17,ibus-rawcode-1.3.1.20100707-7.fc17,ibus-m17n-1.3.3-9.fc17,ibus-hangul-1.4.0-5.fc17,ibus-chewing-1.3.10-3.fc17,ibus-pinyin-1.4.0-14.fc17,ibus-1.4.99.20120304-3.fc17
Package ibus-fbterm-0.9.1-14.fc17, ibus-qt-1.3.1-8.fc17, ibus-handwrite-2.1.4-4.fc17, sunpinyin-2.0.3-4.fc17, ibus-input-pad-1.4.0-7.fc17, eekboard-1.0.5-4.fc17, ibus-skk-1.4.0-3.fc17, ibus-sayura-1.3.1-4.fc17, ibus-rawcode-1.3.1.20100707-7.fc17, ibus-m17n-1.3.3-9.fc17, ibus-hangul-1.4.0-5.fc17, ibus-chewing-1.3.10-3.fc17, ibus-pinyin-1.4.0-14.fc17, ibus-1.4.99.20120304-3.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ibus-fbterm-0.9.1-14.fc17 ibus-qt-1.3.1-8.fc17 ibus-handwrite-2.1.4-4.fc17 sunpinyin-2.0.3-4.fc17 ibus-input-pad-1.4.0-7.fc17 eekboard-1.0.5-4.fc17 ibus-skk-1.4.0-3.fc17 ibus-sayura-1.3.1-4.fc17 ibus-rawcode-1.3.1.20100707-7.fc17 ibus-m17n-1.3.3-9.fc17 ibus-hangul-1.4.0-5.fc17 ibus-chewing-1.3.10-3.fc17 ibus-pinyin-1.4.0-14.fc17 ibus-1.4.99.20120304-3.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-3532/ibus-fbterm-0.9.1-14.fc17,ibus-qt-1.3.1-8.fc17,ibus-handwrite-2.1.4-4.fc17,sunpinyin-2.0.3-4.fc17,ibus-input-pad-1.4.0-7.fc17,eekboard-1.0.5-4.fc17,ibus-skk-1.4.0-3.fc17,ibus-sayura-1.3.1-4.fc17,ibus-rawcode-1.3.1.20100707-7.fc17,ibus-m17n-1.3.3-9.fc17,ibus-hangul-1.4.0-5.fc17,ibus-chewing-1.3.10-3.fc17,ibus-pinyin-1.4.0-14.fc17,ibus-1.4.99.20120304-3.fc17 then log in and leave karma (feedback).
ibus-fbterm-0.9.1-14.fc17, ibus-qt-1.3.1-8.fc17, ibus-handwrite-2.1.4-4.fc17, sunpinyin-2.0.3-4.fc17, ibus-input-pad-1.4.0-7.fc17, eekboard-1.0.5-4.fc17, ibus-skk-1.4.0-3.fc17, ibus-sayura-1.3.1-4.fc17, ibus-rawcode-1.3.1.20100707-7.fc17, ibus-m17n-1.3.3-9.fc17, ibus-hangul-1.4.0-5.fc17, ibus-chewing-1.3.10-3.fc17, ibus-pinyin-1.4.0-14.fc17, ibus-1.4.99.20120304-3.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.