Discussed at 2011-04-15 blocker review meeting. This issue needs to be evaluated per the new criteria clause:

"There may be times where a requirement is unmet only in a particular configuration, such as with some keyboard layouts but not others, or if a particular character is used in a username, password or passphrase. In such cases, the release team should use their judgment and refer to precedent to determine whether or not the issue should be considered to block the release. They should consider the number of users likely to be affected by the issue, the severity of the case when the issue is encountered, and the ease or otherwise with which the issue can be avoided by both informed and uninformed users. "

For that we need a very clear understanding of the impact. Can you maybe put it in practical terms? If you have an F14 install with a couple of available input methods, and do an upgrade to F15 (without this bug being fixed), what's your F15 experience? When you try and select an input method, it's completely random which one you get? Or something different? Thanks!

We will evaluate this issue next week when we have more information. For now its blocker status is undetermined.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Basically this more or less affects all of users. and how many people are aware of this depends on the package installation, languages and filesystem that affects to the order of immodules.cache's generation.

* Background

imsettings-gnome contains a backend module for GNOME desktop that updates the immodule configuration to gnome-settings-deamon, and it reflects to applications through XSETTINGS. if GTK+ detects any immodule configuration through XSETTINGS, that will be used, otherwise it tries to find out better one against current locale and immodules.cache. it depends on the order of content.

immodules.cache is a file generated by gtk-query-immodules-3.0-{32,64} at the package installation time.

* case 1

Selecting immodule relying on immodules.cache is unpredictable. the first item matched the locale will be picked up as "better one". when upgrading f14 to f15 on English install say, 'ibus' and 'xim' is available there though, "better one" depends on the order of it.

* case 2

In pt_BR and fi_FI, XKB through XIM immodule is used in f14 instead of gtk-im-context-simple because of Bug#505100 though, ibus may be used for same reason in case 1.

* case 3

Less problematic but regardless of languages you use, 'ibus' immodule may be used in f15 anyway, because ibus's immodule is supposed to work on every locales (see immodules.cache. you can see '*' there.) and the priority of gtk-im-context-simple is low. though ibus immodule emulates gtk-im-context-simple in some cases.

ibus-1.3.99.20110408-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/ibus-1.3.99.20110408-2.fc15

Package ibus-1.3.99.20110408-2.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ibus-1.3.99.20110408-2.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/ibus-1.3.99.20110408-2.fc15
then log in and leave karma (feedback).

It seems to me the correct fix is to really add the package as required in comps groups and make sure its pulled in for upgrades that way. i say that because other desktops as they adopt gtk3  or users use gtk3 apps on them can and will end up with package bloat due to unneeded apps and deps pulled in to satisfy the requirements.

This was discussed at the 2011-04-21 blocker bug review meeting. This only affects upgrades instead of default installs or F15 live media and thus, does not impact any release criteria directly.

That being said, this is an issue and it would be nice to see it fixed.

Rejected Blocker, Accepted NTH

(In reply to comment #5)
> It seems to me the correct fix is to really add the package as required in
> comps groups and make sure its pulled in for upgrades that way. i say that
> because other desktops as they adopt gtk3  or users use gtk3 apps on them can
> and will end up with package bloat due to unneeded apps and deps pulled in to
> satisfy the requirements.

You're right. but I claimed that since this happens on anaconda upgrading (and preupgrade too?) but not on yum upgrading if one follows the steps to http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum. but anaconda team rejected that.

ibus-1.3.99.20110408-2.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.