Bug 693809

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.

F14->F15 upgrade a while ago.

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.

Is imsettings-gnome a completely new package for F15?

Yes.

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.

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.

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
https://fedoraproject.org/wiki/BugZappers

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.

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.

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.

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

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.

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.

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.

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)

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.

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).

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.

imsettings-1.2.2-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/imsettings-1.2.2-1.fc15

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:
https://admin.fedoraproject.org/updates/imsettings-1.2.2-1.fc15
then log in and leave karma (feedback).

Chris, are you still seeing this issue with imsettings-1.2.2-1.fc15?

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.

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

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.

re-opening this, since Chris was not happy with the pushed fix.



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

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.

Created attachment 497894 [details]
patch

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."

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.

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

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

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?

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).

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.

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 @@
+im-chooser  
 imsettings = 1.2.2-2.fc15
 libc.so.6()(64bit)  
 libc.so.6(GLIBC_2.2.5)(64bit)  
@@ -8,9 +9,7 @@
 libgthread-2.0.so.0()(64bit)  
 libimsettings.so.5()(64bit)  
 libpthread.so.0()(64bit)  
-libpthread.so.0(GLIBC_2.2.5)(64bit)  
 librt.so.1()(64bit)  
-lxde-settings-daemon  
 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.

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
https://fedoraproject.org/wiki/BugZappers

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
https://fedoraproject.org/wiki/BugZappers

anaconda doesn't do anything with comps on upgrade.

(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.

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)

(In reply to comment #39)
> 
> This has been built as 1.2.2-3.fc15.

Confirmed fixed with this build.

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
https://fedoraproject.org/wiki/BugZappers

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.

okay, please submit it as an update, then. and we'll hope nothing explodes.



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

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.

cool - akira, can you please submit them for stable? thanks.



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

Thanks so much for further investigation. requesting stable now..

Moving to VERIFIED based on feedback from caillon in the bodhi updates from comment#45.  Nice work gang!

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.

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.