Bug 693809 - Error message about missing input methods should be removed
Summary: Error message about missing input methods should be removed
Alias: None
Product: Fedora
Classification: Fedora
Component: imsettings
Version: 15
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F15Blocker, F15FinalBlocker
TreeView+ depends on / blocked
Reported: 2011-04-05 15:57 UTC by Christopher Aillon
Modified: 2011-05-14 04:08 UTC (History)
9 users (show)

Fixed In Version: imsettings-1.2.2-3.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-05-14 04:07:36 UTC
Type: ---

Attachments (Terms of Use)
screenshot: I see this immediately after logging in (405.81 KB, image/png)
2011-04-05 15:57 UTC, Christopher Aillon
no flags Details
Proposed source patch (against git master) (1.30 KB, patch)
2011-04-21 20:49 UTC, Christopher Aillon
no flags Details | Diff
Proposed spec patch for f15 (2.62 KB, patch)
2011-04-21 21:05 UTC, Christopher Aillon
no flags Details | Diff
patch (878 bytes, patch)
2011-05-09 19:02 UTC, Christopher Aillon
no flags Details | Diff

Description Christopher Aillon 2011-04-05 15:57:08 UTC
Created attachment 490022 [details]
screenshot: I see this immediately after logging in

Description of problem:
Lately, I've been getting an ugly notification from imsettings when starting GNOME 3.

Version-Release number of selected component (if applicable):

How reproducible:
Not always, but it's been somewhat frequent of late.

Steps to Reproduce:
1.Login to GNOME
Actual results:
See attached screenshot.

Expected results:
No error message at all.

Additional info:
Aside from the fact that the error message is rather difficult to parse for a native English speaker, I really don't think we even want to display a message at all to the user in this case.

Comment 1 Akira TAGOH 2011-04-06 03:32:41 UTC
How did you install that? imsettings-gnome package should be pulled in by conditional state to imsettings in comps and that error won't happen if it's there though.

Comment 2 Christopher Aillon 2011-04-06 17:25:42 UTC
F14->F15 upgrade a while ago.

Comment 3 Akira TAGOH 2011-04-11 13:34:33 UTC
Ok, I see no imsettings-gnome package installed when upgrading F14 GA to F15 Beta RC2. though it gets pulled in if do yum groupupdate gnome-desktop. I'm assuming that anaconda will pulls packages in, including newly added in comps though, but it seems not.

That looks to me like the steps to upgrade via yum would rather makes similar what packages installed on fresh install though, any idea? reassigning to anaconda so far.

Comment 4 Chris Lumens 2011-04-11 14:18:18 UTC
Is imsettings-gnome a completely new package for F15?

Comment 5 Akira TAGOH 2011-04-12 02:08:19 UTC

Comment 6 Chris Lumens 2011-04-12 14:22:53 UTC
anaconda upgrades don't pull in new packages unless they are required by something else that's already scheduled for an upgrade.  We don't deal with things on the comps group level for upgrades - it's a simple iteration over the packages you've got checking for if there's something newer.  This is one of the reasons we don't really push upgrades very hard.

Comment 7 Christopher Aillon 2011-04-12 16:01:36 UTC
Anyway, I strongly feel that the real bug is that this message exists at all.

1) It is painfully obvious that the message was written by a non-native English speaker.  I am a native speaker, and I don't think I really understand what the message is trying to say in full.

2) I really don't think imsettings should ever be displaying an error at startup.  It doesn't matter if it's GNOME or KDE or Xfce or what, displaying error message for an optional feature seems just broken.  And doing it every login is even more broken.

3) If you still strongly feel the need to tell users something, you should offer to let the user install the modules directly from your message and open PackageKit with relevant results.  See what we do for missing printer drivers, missing fonts, missing codecs etc.  And then stop asking again.  I already said no.

Reopen and assigning back to imsettings.

Comment 8 Adam Williamson 2011-04-15 19:06:42 UTC
Adjusting summary to reflect that this is not 696510.

Discussed at the 2011-04-15 blocker review meeting. Given that as it stands this is a design choice, though Chris thinks it's a bad one, we don't consider this a blocker. (remember there's an unfrozen period prior to final release, so it's still possible to change this prior to release and have the change included in the release; blocker status only affects whether it could be changed _after the final freeze_).

Fedora Bugzappers volunteer triage team

Comment 9 Christopher Aillon 2011-04-19 05:12:20 UTC
Renominating for blocker status.

1) This is not a warning message, this is an _error_ message that persists and does not go away.  See the screenshot.

2) This error message will appear for all upgrades from F14 -> F15.

3) Akira made it clear that the error message should not be present on an upgraded system, and thus is clearly _not_ a design choice.

This bug is about making that error message go away.  I don't really care if that's via adding a dependency on the necessary package, or by outright removing the error message from the code (I'd strongly prefer doing both: the functionality needs to be there for those that need it, and I don't think the message is useful to people).  But the fact that there is an _error_ message persisting after upgrades needs to be addressed for the final.

Comment 10 Dennis Gilmore 2011-04-21 18:37:36 UTC
my main concerns are how this will effect things running on non gnome desktops and non gnome gtk3 based desktops. we need a fix that makes sure things run right everywhere. but dont cause people to pull gnome in if they want to run gtk3 apps on non gnome desktops.

Comment 11 Christopher Aillon 2011-04-21 18:53:19 UTC
So, fwiw, it looks like F15 also grew an imsettings-qt package which did not exist in F14.  I'd imagine this might also affect KDE F14->F15 upgrades.

Comment 12 James Laska 2011-04-21 19:53:25 UTC
Discussed at 2011-04-21 blocker review meeting (http://meetbot.fedoraproject.org/fedora-bugzappers/2011-04-21/f15-blocker-review.2011-04-21-17.00.html) ...

AGREED: 693809 - AcceptedBlocker - May also impact other desktops, continue discussion in bug

Comment 13 Christopher Aillon 2011-04-21 20:49:50 UTC
Created attachment 493991 [details]
Proposed source patch (against git master)

Here's a patch against imsettings git master to remove the notification.

I think we also need to add a Requires: imsettings-gnome or imsettings-qt somewhere, but I'm not sure where the best place to do that is.

ISTR that yum tries to install the least amount of packages when multiple virtual provides would satisfy a require?  If so, we could maybe give the individual IM modules a virtual provide that imsettings would then require, and it should install the correct one for the respective DE.

Comment 14 Christopher Aillon 2011-04-21 21:05:33 UTC
Created attachment 493994 [details]
Proposed spec patch for f15

skvidal confirmed what I said in comment 13 on IRC:

<skvidal> that's correct
<skvidal> paths which pull in the least number of other packages are preferred
<caillon> skvidal, cool thanks
<skvidal> caillon: when in doubt: http://yum.baseurl.org/wiki/CompareProviders
<skvidal> caillon: that continues to be accurate

So, this should work as expected for each DE.

Comment 15 Akira TAGOH 2011-04-22 02:16:04 UTC
Thanks! that looks nice. I'll update the package with it and a fix in xinput.sh to set explicit environment variables to make it predictable when the certain modules isn't available.

Comment 16 Christopher Aillon 2011-04-22 03:28:15 UTC
To be clear, I think we should take both my patches (comment 13 and comment 14).

This would:
* never show the error message (comment 13)
* but it doesn't matter because we always have a module available (comment 14)

Comment 17 Akira TAGOH 2011-04-22 03:43:54 UTC
Yes. I'd respect all your changes. and what I said for updates of xinput.sh is to ensure better instead of showing an error. even though it won't happens on Fedora with the change in comment #14.

Comment 18 Christopher Aillon 2011-04-22 03:53:41 UTC
So, I had a further look.  I don't think a fix to xinput.sh is right.  I think even better (in addition to the previous fixes)

Since imsettings requires a module to be useful, it should enforce that at build time.  configure.ac should be patched to produce an error if there is no module being built.  Then, we are guaranteed to build a module, and it is up to the distro/packager to make sure that gets installed (which we do with comment 14).

Comment 19 Akira TAGOH 2011-04-22 07:40:58 UTC
basically it's unlikely since lxde module requires only glib2.0. sure, it's up to the distro/packager to get it working properly, but that would be safe to have any workaround in xinput.sh instead of just put a warning in the log and blame them.

Comment 20 Fedora Update System 2011-04-26 08:02:43 UTC
imsettings-1.2.2-1.fc15 has been submitted as an update for Fedora 15.

Comment 21 Fedora Update System 2011-04-26 15:33:51 UTC
Package imsettings-1.2.2-1.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 imsettings-1.2.2-1.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).

Comment 22 James Laska 2011-04-29 16:30:12 UTC
Chris, are you still seeing this issue with imsettings-1.2.2-1.fc15?

Comment 23 James Laska 2011-04-29 18:51:47 UTC
Discussed at 2011-04-29 blocker review meeting (http://meetbot.fedoraproject.org/fedora-bugzappers/2011-04-29/f15-blocker-review.2011-04-29-17.00.html).  Still needs test feedback for updated imsettings to land in F15.  Will request including this update, regardless of test results, in Final TC1.

Comment 24 Christopher Aillon 2011-05-01 21:54:58 UTC
Was out last week, sorry I didn't get a chance to test until just a few hours ago.

So, I gave negative karma on the update already...  But here's fuller analysis:

* All imsettings modules require im-chooser, except for imsettings-gnome which requires im-chooser-gnome3.

* im-chooser-gnome3 is a (brand new) control center capplet, which _duplicates_ functionality of im-chooser.  You can either run im-chooser or use the control center capplet.  Also, im-chooser-gnome3 requires im-chooser, so both will be available to end users when -gnome3 is installed.  So, technically speaking, imsettings-gnome doesn't need to require im-chooser-gnome3.  (more ahead on why this breaks things):

* On upgrades, when trying to figure out the package to install, it gets down to which needs the least number of additional packages installed.  In this case, it is either imsettings-gnome which needs im-chooser-gnome3 or imsettings-qt which needs qt.  Since there's a tie, the shortest name wins.

So, what should probably happen is either:

1) Drop the control panel applet and the -gnome3 subpackage and just make the input method selector an application (and eventually see about getting it into Region and Language capplet instead of its own one because it looks really out of place the way it is...)

2) im-chooser grows stub subpackages for each of the desktops, with requires for each.  Eg. im-chooser-kde requires kdebase, im-chooser-xfce requires some xfce package to make sure that the DE specific imsettings

Comment 25 Fedora Update System 2011-05-02 03:40:08 UTC
imsettings-1.2.2-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 26 Adam Williamson 2011-05-06 23:33:30 UTC
re-opening this, since Chris was not happy with the pushed fix.

Fedora Bugzappers volunteer triage team

Comment 27 James Laska 2011-05-09 11:59:24 UTC
Akira, do you have some time to respond to caillon's feedback in comment#24.  Please note, F15 RC1 is scheduled for compose by end of day, Tuesday, May 10, 2011.  Any delays in resolving this accepted blocker may introduce a delay in F15.  Let us know if additional resources/input/testing are needed to resolve this issue in a timely manner.

Comment 28 Christopher Aillon 2011-05-09 19:02:49 UTC
Created attachment 497894 [details]

So, the lowest risk patch I can think of is this 1-line patch, which fixes the dependencies to match what all the other IM modules require, and technically is correct since all we need is a way to choose input methods and that is provided by im-chooser.

However, this probably deserves a release note, something like this:
"Users of the Fedora 15 Desktop who wish to select input methods can do so by running /usr/bin/im-chooser.  Alternatively, they can add a control panel item by running yum install im-chooser-gnome3."

Comment 29 Akira TAGOH 2011-05-10 02:08:06 UTC
Sorry, I was away last week. and thank you for testing.

I agree that keeping im-chooser as an application in f15 would be the lowest risk. I guess simply getting rid of -gnome3 package in f15 may be no troubles. we can avoid updating the release notes at this point then. I'll postpone dealing with them to the next release.

Comment 30 Fedora Update System 2011-05-10 02:52:09 UTC
imsettings-1.2.2-2.fc15 has been submitted as an update for Fedora 15.

Comment 31 Fedora Update System 2011-05-10 11:55:47 UTC
im-chooser-1.4.2-2.fc15 has been submitted as an update for Fedora 15.

Comment 32 James Laska 2011-05-10 13:32:05 UTC
Changing to MODIFIED based on pending imsettings and im-chooser updates.

Anyone have a setup already available who can confirm the changes and provide karma feedback?

Comment 33 Christopher Aillon 2011-05-10 15:39:18 UTC
So, here's what I'm doing to test:

yum erase imsettings-libs im-chooser qt
wget http://caillon.fedorapeople.org/693809-notfixed/693809-notfixed.repo
wget http://caillon.fedorapeople.org/693809-notfixed/693809-fixed.repo
cp 693809*.repo /etc/yum.repos.d
yum --disablerepo=* --enablerepo=693809-notfixed install imsettings

Test: logout and back in to gnome (should see the screenshot in my initial comment)

yum --disablerepo=* --enablerepo=693809-fixed update

Test: Make sure that qt is NOT pulled in by the update

Test: log out and back into gnome (should NOT see the screenshot in my initial comment).

Comment 34 Christopher Aillon 2011-05-10 15:40:50 UTC
I get:

Resolving Dependencies
--> Running transaction check
---> Package imsettings.x86_64 0:1.2.1-1.fc15 will be updated
---> Package imsettings.x86_64 0:1.2.2-2.fc15 will be an update
--> Processing Dependency: imsettings-desktop-module = 1.2.2-2.fc15 for package: imsettings-1.2.2-2.fc15.x86_64
---> Package imsettings-libs.x86_64 0:1.2.1-1.fc15 will be updated
---> Package imsettings-libs.x86_64 0:1.2.2-2.fc15 will be an update
--> Running transaction check
---> Package imsettings-lxde.x86_64 0:1.2.2-2.fc15 will be installed
--> Processing Dependency: lxde-settings-daemon for package: imsettings-lxde-1.2.2-2.fc15.x86_64
--> Finished Dependency Resolution

which is clearly bad, since now we're pulling in lxde packages instead...  :-(

It would really be helpful if someone who better understood the dependency stuff better could help with this.

Comment 35 Bill Nottingham 2011-05-10 16:00:43 UTC
Going through the CompareProviders checklist (http://yum.baseurl.org/wiki/CompareProviders):

0. each pkg starts out with a score of 0.

1. if any of the providers is a newer version of something we have installed then increase their score by 5

=> would be same

2. if any of the providers are not the newest version of themselves then decrease their score by 1024.

=> would be same

3. if any of the providers are obsoleted by another provider, decrease that provider by 1024.

=> would be same

4. check the arch distance between the requiring pkg and each of the providers. The pkg with the smallest arch distance gets a 5 added to their score. Do the same check but comparing the pkg arch distance to the system arch, not the requiring pkg arch

=> would be same

5. compare the sourcerpm on each provider to the requiring pkg's source rpm. If they share a sourcerpm add 20 to the score

=> would be same

6. check the base pkg for each subpkg. If the base pkg is installed on the system add 5 to the provider's score.

=> would be same

7. check the prefix of the pkg to the requiring pkg prefix (perl-foo and perl-lib) for each common character in the prefix add 2 points to the provider's score.

=> would be same (imsettings-)

8. if, at this point, we have pkgs with an equal score - look at the deplist (one layer deep) and see what they would pull in that is NOT already installed. Add 1 to the score of the pkg with the least new deps to be pulled in.


Here's the diff of the requirements in 1.2.2-5:

--- lxde	2011-05-10 11:47:17.853597225 -0400
+++ gnome	2011-05-10 11:47:42.121597233 -0400
@@ -1,3 +1,4 @@
 imsettings = 1.2.2-2.fc15
@@ -8,9 +9,7 @@
 rpmlib(CompressedFileNames) <= 3.0.4-1
 rpmlib(FileDigests) <= 4.6.0-1
 rpmlib(PayloadFilesHavePrefix) <= 4.0-1

The libpthread one is a no-op, as glibc is (obviously) already installed.
So, one new package for both, in theory. (if im-chooser isn't already part of the install set.)

9. if all else fails and we STILL have two pkgs with the same score - take the leaders from the list and compare their name length. We add 1,000 and then subtract the length of the number of character's in the pkgs name from its score (the addition of 1000 is to ensure that one of the leaders will be picked).

=> lxde wins.

10. return the list of providers, sorted best to worst.

Potential, absolutely silly fix:

Change imsettings-lxde to require both lxde-settings-daemon and lxsession. This will change the number of added requirements of imsettings-lxde, without actually changing the closed dependency set.

Comment 36 Adam Williamson 2011-05-10 16:04:58 UTC
notting: from his yum output I suspect lxde-settings-daemon is already installed (note there's no line saying it's going to *get* installed), so it may be winning on metric #8, not #9.

Fedora Bugzappers volunteer triage team

Comment 37 Adam Williamson 2011-05-10 16:05:50 UTC
notting: since yum isn't a supported upgrade method but anaconda is, could we fix this using comps groups, somehow? anaconda pays attention to those on upgrade, yes?

Fedora Bugzappers volunteer triage team

Comment 38 Bill Nottingham 2011-05-10 16:10:51 UTC
anaconda doesn't do anything with comps on upgrade.

Comment 39 Bill Nottingham 2011-05-10 16:37:50 UTC
(In reply to comment #35)
> Potential, absolutely silly fix:
> Change imsettings-lxde to require both lxde-settings-daemon and lxsession. This
> will change the number of added requirements of imsettings-lxde, without
> actually changing the closed dependency set.

This has been built as 1.2.2-3.fc15.

Comment 40 Christopher Aillon 2011-05-10 16:40:45 UTC
Adam, I culled the output slightly.  I don't have lxde anything installed.  It would have been installed though had I let yum do its thing (and had i given it a repo which contained lxde anything)

Comment 41 Christopher Aillon 2011-05-10 16:41:07 UTC
(In reply to comment #39)
> This has been built as 1.2.2-3.fc15.

Confirmed fixed with this build.

Comment 42 Adam Williamson 2011-05-10 16:48:12 UTC
trying to game yum's algorithm seems like a pretty weak fix to me, but I don't think there's a really good way to address this issue given the limitations of how RPM does dependencies :/

does this still need to be a blocker, though? it was accepted as a blocker due to the large cosmetic impact of the error message; if the error message issue is gone, this probably isn't a blocker any more. what's the current status there?

Fedora Bugzappers volunteer triage team

Comment 43 Christopher Aillon 2011-05-10 17:04:26 UTC
Without the additional fix, it will pull in some other DE packages to the Desktop spin, which will make things confusing at best and potentially cause breakage.  I really think we need the -3 package, and then let's never speak of this bug again.

Comment 44 Adam Williamson 2011-05-10 17:09:14 UTC
okay, please submit it as an update, then. and we'll hope nothing explodes.

Fedora Bugzappers volunteer triage team

Comment 45 Christopher Aillon 2011-05-10 17:12:15 UTC
I already upkarma'd https://admin.fedoraproject.org/updates/imsettings-1.2.2-3.fc15 and https://admin.fedoraproject.org/updates/im-chooser-1.4.2-2.fc15 both of which are needed here.

Comment 46 Adam Williamson 2011-05-10 17:43:33 UTC
cool - akira, can you please submit them for stable? thanks.

Fedora Bugzappers volunteer triage team

Comment 47 Akira TAGOH 2011-05-11 01:29:29 UTC
Thanks so much for further investigation. requesting stable now..

Comment 48 James Laska 2011-05-11 12:10:49 UTC
Moving to VERIFIED based on feedback from caillon in the bodhi updates from comment#45.  Nice work gang!

Comment 49 Fedora Update System 2011-05-14 04:07:30 UTC
im-chooser-1.4.2-2.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 50 Fedora Update System 2011-05-14 04:07:58 UTC
imsettings-1.2.2-3.fc15 has been pushed to the Fedora 15 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.