tags 680655 unreproducible thanks Hi,
Have you all got some idea what is going on here. I tried this with scim 1.4.14-2 and 1.4.13-5 in unstable. No problem for me. Unreproduceble. Please read on and give me updated feed back with result of test script below. On Mon, Aug 13, 2012 at 03:09:24PM +0800, Tz-Huan Huang wrote: > Hi Osamu Aoki, ... > > This Bug#680655 is somehow related to im-config with scim. With recent > > multiarch and major system updates of scim, I am not sure what is > > happening. Can you check this since this seems to be scim related. > > Since scim doesn't use dbus, it might not related to the > initialization problem. I'll try to figure it out, thanks. This is good point. I did try to reproduce problem by setting im-config to SCIM and relog-in. It works without problem. Let's see Andrew's log: | + msgbox 'Current configuration for the input method: | * Active configuration: scim (normally missing) | * Automatic configuration: ibus (normally ibus or fcitx or uim) | * Number of valid choices: 6 (normally 1) | The configuration set by im-config is activated by re-starting X. | Explicit selection is not required to enable the automatic configuration if the active one is default/auto/cjkv/missing. | Available input methods: ibus uim hime gcin scim xim | Unless you really need them all, please make sure to install only one input method tool.' This is im-config line 162: > msgbox "$IM_CONFIG_MSG" This calls im-config.common line 127 defining msgbox: | + '[' X = console ']' | + echo -n 'Current configuration for the input method: | * Active configuration: scim (normally missing) | * Automatic configuration: ibus (normally ibus or fcitx or uim) | * Number of valid choices: 6 (normally 1) | The configuration set by im-config is activated by re-starting X. | Explicit selection is not required to enable the automatic configuration if the active one is default/auto/cjkv/missing. | Available input methods: ibus uim hime gcin scim xim | Unless you really need them all, please make sure to install only one input method tool.' | + zenity --width=600 --height=400 --title 'Input Method Configuration (im-config, ver. 0.17)' --text-info | /usr/share/im-config/im-config.common: line 127: 26214 Done echo -n "$1" | 26215 Segmentation fault | zenity --width=600 --height=400 --title "$IM_CONFIG_ID" --text-info Clearly, zenity is broken here. You say you pressed cancel. My case nothing happens. I know Anthony said to have zenity 3.4.0-2 on Sun, 8 Jul 2012 at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680655#15 The original bug report was on the same day with packages in testing (not in unstable) and certainly it was there. [2012-05-23] zenity 3.4.0-2 MIGRATED to testing So this is very odd. Unreproduceble here. Unless you have zenity 3.4.0-1, it does not make sense. Is this experienced by Anthony only or both by Tz-Huan and by Anthony? Can you try again? Can you test the following simple script and past its result here? ====== ls -l /bin/sh dpkg -l zenity dash bash echo -n "SIMPLETEXT MESSAGE" | zenity --width=600 --height=400 --title 'TITLE' --text-info FOO="$(echo -n 'Current configuration for the input method: * Active configuration: scim (normally missing) * Automatic configuration: ibus (normally ibus or fcitx or uim) * Number of valid choices: 6 (normally 1) The configuration set by im-config is activated by re-starting X. Explicit selection is not required to enable the automatic configuration if the active one is default/auto/cjkv/missing. Available input methods: ibus uim hime gcin scim xim Unless you really need them all, please make sure to install only one input method tool.')" echo -n $FOO | zenity --width=600 --height=400 --title 'Input Method Configuration (im-config, ver. 0.17)' --text-info ==== Osamu PS: As I checked scim in the mean time, it is in a sad state. In 1.4.14-2 unstable release In 1.4.13-5 testing release The major difference seems to be | scim (1.4.14-1x1) experimental; urgency=low | | * scim-clutter-immodule: install files from multi-arch paths. | Closes: #679724 | -- Rolf Leggewie <f...@rolf.leggewie.biz> Wed, 04 Jul 2012 12:35:06 +0800 But as I looked into these... In 1.4.14-2 unstable release, scim-clutter-immodule and scim-qt-immodule exist. In 1.4.13-5 testing release, scim-clutter-immodule and scim-qt-immodule do not exist So there is no way this much different package can be accepted to unblock without serious and early request with reasonable explantion. Unfortunately, scim package maintainer is not following proper upload procedure under freeze initially. Uploading new upstream package is NOT-GOOD under freeze. Not getting unblock request approved is NOT-GOOD. Creating new packages just saying "start shipping a couple of newly introduced im-module packages" is not sufficient as documentation of major changes under freeze. Maybe scim package maintainer did something else but it did not get FTP master approval in the end ... So we are stack with broken package if this serious #679724 bug affects But this seems nothing to do with Bug#680655: scim and im-config. Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org