Red Hat Bugzilla – Bug 448411
XFCE should require imsettings-xfce
Last modified: 2009-06-23 01:50:08 EDT
Description of problem:
Taskbar showing SCIM icon, and right click on the icon shows the context menus
alright, but SCIM not working, even after im-chooser (both as user/root) and
several time resetup of SCIM. SCIM only working in Gedit/Mousepad, if from
right-click --> input method --> scim is chosen. Opening Gedit/Mousepad once
again showing the input method has again gone back to 'system'. SCIM is working
fine in Gnome in F9, but not in Xfce.
Version-Release number of selected component (if applicable):
Fedora 9 Xfce 4 Desktop Environment version 4.4.2 (Xfce 4.4) SCIM: Smart Common
Input Method 1.4.7
Steps to Reproduce:
<<Quoting a portion of my email to Fedora Users List for better understanding>>
I am using SCIM on Fedora for around two years. In Fedora 7 and
then 8, everything was working as fine as it could be.
All this time I was working with SCIM, which I use for changing to and
fro between Bangla (Bengali) keyboard layout 'Probhat' for Bangla texts
and the US English layout as the default one.
After I upgraded to Fedora 9, in two machines, the SCIM thing is not
working. I have used 'im-chooser' to choose this input method. I have
checked with the 'scim-setup' but with no avail. No application in XFCE
will get the SCIM keyboard switcher (Ctrl+Space) activated. Claws-mail,
mousepad, OpenOffice -- nothing, in all which I regularly used Bangla
When I installed Gedit, or Mousepad from XFCE, which is a fork of Gedit
if I am remembering correctly, from the context menu option for
choosing input method, after I choose SCIM there the CTRL-Space switch
is working. But, then again when I log out and come back to XFCE with
'startx', again I have to do the same thing in Gedit or Mousepad context
menu. Though all this type the SCIM icon is there on the task bar. And
the icon is showing the usual context menu, but not the usual keyboard
After the Gedit experience I installed Gnome things with 'yum
groupinstall gnome-desktop' and I am getting SCIM properly there,
everything OK. But, I want XFCE.
Am I doing something wrong, something has changed in Fedora 9 version
of XFCE? Or, is it some problem?
After I reported this problem to the XFCE mailing list, friends there
told me that in their recently updated XFCE too SCIM is working fine,
so maybe it is a problem of the FC9-build.
Does 'rpm -q imsettings-xfce' show that the imsettings-xfce package is installed?
I am going to assign this to the im-chooser maintainer to look at, as I think
it's a im-chooser issue. (I will stay copied on the bug and follow it's progress).
Thanks for reporting it!
Oh no: this is not installed.
[root@mamdo ~]# rpm -q imsettings-xfce
package imsettings-xfce is not installed
So, now, if I install it, would it solve my problem?
No, it did not. At least, before a new 'startx', because some works are going on
in one terminal that will take time.
But, even if it solves after a restart of xfce, why this thing imsetting-xfce
was not within dep list? Was I doing some mistake? As far as I remember F7 or F8
never required me to install this package separately.
Oh, thank you Fenzi for responding so fast.
Yes, it worked. But, after restart into XFCE only im-chooser after the
installation of imseetings-xfce did not work. I had to run 'im-setting-list'
which showed: '* 1: SCIM (recommended)'. And then I clicked on the icon, and at
last it showed all the keyboards. Now it is working fine with oowriter, and so I
think it will work with everything else.
(In reply to comment #4)
> No, it did not. At least, before a new 'startx', because some works are going on
> in one terminal that will take time.
> But, even if it solves after a restart of xfce, why this thing imsetting-xfce
> was not within dep list? Was I doing some mistake? As far as I remember F7 or F8
> never required me to install this package separately.
having deps to im-chooser makes extra dependencies for Xfce, which isn't a
default desktop for Fedora. you could have imsettings-xfce from xfce-desktop
group since it's certainly described in comps.
(In reply to comment #5)
> Yes, it worked. But, after restart into XFCE only im-chooser after the
> installation of imseetings-xfce did not work. I had to run 'im-setting-list'
> which showed: '* 1: SCIM (recommended)'. And then I clicked on the icon, and at
> last it showed all the keyboards. Now it is working fine with oowriter, and so I
> think it will work with everything else.
Sorry, failed to parse it. you mean you didn't get im-chooser working even if
#1: I did install the Xfce-group. But, that imsetting-xfce was not within it
though all through I had all these components scim/bengali/im-chooser selected.
Anyway, has it got something to with 'preupgrade'? I used that for switching to
f9 just two or three days back. And the same experience occurred in one or two
more cases. Probably it happened with 'xpdf', while the system was showing it
installed, it was not getting the libraries. I did 'yum erase' and 'yum install'
on xpdf once again, and it started working. This happened once or twice more. I
wanted to remember them later and report it, but, by that time I forgot it
(blame it on my 47 years and a heavy schedule in the college). From what you say
I get that, imsetting-xfce was always already a part of the xfce-group. But, in
that case, my not knowing about the package shows that in F8 or F9, where I all
through used xfce and scim, the dependency overdetermination of the system was
working fine. I used it without knowing it. Now I had to know and install it
separately. So, something must be broken somewhere, if it is not a contribution
of the upgrade-process. Maybe a fresh install would not have done it. And you
know, even when doing fresh-install, checking the group xfce on does not help,
they don't get installed. After the primary installation is complete, you have
to group-install it.
#2: yes, even after I logged out and did 'startx' into xfce, the im-chooser was
not working. Somewhere down the line, when I was trying the new thing, I was
tabbing after typing 'imsetting' and seeing that list thing 'imsetting-list',
ran it without knowing what it is, because '--help' was not working, the scim
thing started working. I had nothing like dmesg on, and so I cannot tell you
exactly how and why it happened. One thing maybe important (see, I am not sure,
without having the technical knowledge, and so I am reporting it in full), after
the restart into X, because I was surprised to see that such an important
component was not installed at all, I wanted to check the whole installation,
and I became 'su' and wanted to run the PackageKit thing from the x-term command
line, but could not find out how. So, in order to install the good old 'yumex'
which 'yum search' was showing to be there, unlike 'pirut', I issued 'yum
install yumex' and the moment after parsing the command it started installing
there were a few lines that I did not expect, they went up fast, they were about
scim and something like X-11 and gtk (sorry there). Was it this thing that
worked? Maybe I should have run the im-chooser as the root in the first instance.
Another thing, from the time I did restart X, the session is running for all
these hours (a two pass encoding of 'Water-horse' for my niece with mencoder is
taking an unimaginable time, after all it is an Athlon-1800+). If I restart X, I
don't know if the scim thing will be there or not. Though now it is running OK
everywhere, even on xterm.
Thank you dear Tagoh for responding. And it will be real helpful if you suggest
me some documentation about the working of im-chooser and scim, particularly on
xfce, I am no developer but even using the system needs some level of literacy
(In reply to comment #8)
> #1: I did install the Xfce-group. But, that imsetting-xfce was not within it
> though all through I had all these components scim/bengali/im-chooser selected.
Confirmed. that issue would be better filing a bug against comps anyway.
> #2: yes, even after I logged out and did 'startx' into xfce, the im-chooser was
Please keep a clean comment for this issue. talking about the irrelevant thing
directly or indirectly makes harder to track the issue down.
Anyway, from my experience of the fresh install and groupinstall xfce-desktop
and japanese-support, after installing imsettings-xfce, restarting the desktop
works for me. im-chooser can bring up SCIM properly with turning on/off a check
box. I can see SCIM icon at the systray right.
You didn't mention what you did with im-chooser, what you were expecting and how
im-chooser didn't work. also I'm not quite sure what locale you're running on.
currently SCIM doesn't have a default hotkey to activate IM for non-CJKI locales
because it eats the keys for these hotkeys, which sometimes prevents doing
something for another applications, and got some complaint from non-CJKI people.
so SCIM might be brought up by im-chooser properly on your box, but it may be
likely to do nothing when you press ctrl+space. if it's the case, try to set up
the hotkey from scim-setup. you could even activate them from clicking the SCIM
icon at the systray though.
FYI, imsettings-list is just an utility to see which IM is selected for you,
like you can see it on im-chooser nicely. and it doesn't do nothing more than
that. and im-chooser is just a configuration tool for users, but not for
system-wide. running as root just makes a configuration for root.
Anyway, there seems to be nothing else I can do on im-chooser so far, except
imsettings-xfce should depends on im-chooser since it brings up from GUI
configuration for Xfce.
(In reply to comment #9)
> You didn't mention what you did with im-chooser, what you were expecting and how
> im-chooser didn't work. also I'm not quite sure what locale you're running on.
> currently SCIM doesn't have a default hotkey to activate IM for non-CJKI locales
The trigger in the Indic keyboards (Bengali/Hindi) by default is 'Ctrl+Space' as
I see it by default there every time I enter Scim setup. And I said, Scim was
not working. Not that im-chooser was not working: how can I know im-chooser is
not working -- even when Scim is not working, im-chooser allows me to choose
Scim as the input method, and so it seems it IS working. When I restarted Xfce,
I saw that Scim was not working, because I could not get the Bengali keyboard by
'Ctrl+Space' and then I did im-chooser once again, and again it did show the
default setting as 'Scim'. And still Scim was not working.
And then, all of a sudden, it started working. I don't know how or why. That is
why I reported everything, from the pin to the elephant. When you ask me to say
only relevant things you are making a flip-flop subject position, maybe
unknowingly. I could understand what is relevant IFF I were you, and that
unfortunately is not the situation, and exactly that is why I am reporting it to
you without reporting it to myself. (Was this comment irrelevant too? I think it
is. Exactly the way your comment about irrelevance was, to be exact,
self-recursive, that is, irrelevant.) ;)
(In reply to comment #10)
> The trigger in the Indic keyboards (Bengali/Hindi) by default is 'Ctrl+Space' as
> I see it by default there every time I enter Scim setup. And I said, Scim was
> not working. Not that im-chooser was not working: how can I know im-chooser is
> not working -- even when Scim is not working, im-chooser allows me to choose
> Scim as the input method, and so it seems it IS working. When I restarted Xfce,
> I saw that Scim was not working, because I could not get the Bengali keyboard by
> 'Ctrl+Space' and then I did im-chooser once again, and again it did show the
> default setting as 'Scim'. And still Scim was not working.
Saying "not working" as you didn't get what you expected is vague. I understand
it since you reported that here. otherwise you don't need to do that, do you? :)
Anyway you need to check if the SCIM processes is really running when you think
SCIM doesn't work. AFAICT if it's running but just nothing happens by pressing
ctrl+space, it's what I said in the previous comment. you have to set up your
hotkey with scim-setup and this isn't a bug at all. Otherwise please give me
more info like if you can see any warnings if you run im-chooser on the terminal.
Also, well, the previous comment may be not friendly, but if you aren't sure
what I'm saying, that would be better asking how to get it -- give me the result
of 'locale' command on the terminal, please.
> And then, all of a sudden, it started working. I don't know how or why. That is
> why I reported everything, from the pin to the elephant. When you ask me to say
> only relevant things you are making a flip-flop subject position, maybe
> unknowingly. I could understand what is relevant IFF I were you, and that
> unfortunately is not the situation, and exactly that is why I am reporting it to
> you without reporting it to myself. (Was this comment irrelevant too? I think it
> is. Exactly the way your comment about irrelevance was, to be exact,
> self-recursive, that is, irrelevant.) ;)
Obviously whether or not you install yumex, and what you were doing with
mencoder and what CPU you use is irrelevant here. what I'd like to hear the
details here is, 1) which locale is your desktop running on, 2) when you're
logging in to your desktop after you install imsettings-xfce, what im-chooser
shows you and you can see if SCIM processes are running, 3) what the kind of
hotkeys are set up in scim-setup.
#1. Output of 'locale':
#2.I told you, I ran im-chooser first as user, and then as root. In both the
cases, when I ran it from command prompt, without any error message it put forth
one window, with three fields. And it took a really long time in coming up in
both the cases. 'Enable Input Method' was selected, because by this time I ran
im-chooser so many times that it was already that. Within 'Input Method' it was
showing 'Use Scim (recommended)'. And the third field 'Input Method Preferences
...', when clicked was bringing in 'scim-setup'. Then the comment about this
thing not working, till the next login, except gtk+ applications. Every time I
ran im-chooser, as user or root, after the very first time, when the 'Use Scim'
was not there and it came up after I selected 'Enable Input', this was the same
thing. Oh, one thing, the 'Close' button is active and the 'logout' button is
grayed out. This is the same thing 'im-chooser' showed, before or after
installing 'imsetting-xfce'. Or, even now, it is reacting the same way.
#3 Every time I ran scim-setup, before installing 'imsetting-xfce' or after,
before it actually worked or after, scim-setup was always showing 'Ctrl+Space'
as the trigger and so, I never had to do it myself. I think that part maybe
there because it was a preupgrade upgrading, not a fresh install.
I have tried restarting X more than once, and also restarting machine once, and
the Scim that got activated after installation of 'imsetting-xfce' by something
that I don't know is still active, allowing me to switch keyboards with
You just don't understand the uncertainty of a NON-developer-user. I try to
report everything, that is EVERYTHING, because I don't know what is what. This
is what happened in my Desktop. Now let me report the laptop, where Scim is not
Let me do it step by step.
1. Ran 'im-chooser' from the x-terminal. Window took very long time to come up,
but showing the exact things that I told above. I ran it as user, not root,
because you did not mention anything about it. Clicked 'Close'.
2.Ran 'scim-setup' again as user. Scim-setup -> Frontend -> Global Setup showing
the 'Ctrl+Space' trigger there, keyboard layout as 'US English'. ImEngine ->
Global Setup showing Bengali with variants selected within, Hindi the same way
and other -> English/European. Clicke 'OK'.
(a) Opened 'oowriter' (as user). Hit 'Ctrl+Space'. Nothing happened. Not exactly
nothing some one-character field or something is getting selected in oowriter
window, and so I have to hit 'discard' to exit. But no change in the Scim line
(b) On the xfce X terminal itself hit 'Ctrl+Space' nothing happened. When active
keyboard layout changes here too.
(c) Opened 'mousepad' (as user). Hit 'Ctrl+Space'. Nothing happened. Right
clicked on the window and brought up 'Input Methods', showing the very first one
'System' as selected. I change it to the ninth one: 'Scim-Bridge Input Method'.
Now keyboard switching is working with 'Ctrl+Space'. But there are some messages
on the terminal, from where I ran 'mousepad':
Loading socket Config moduele ...
Creating backend ...
Loading x11 FrontEnd module ...
Failed to load X11 FrontEnd module.
I typed it as correctly as I can. This came up when I selected Scim in the
context menu. Though it reports something 'failed', but Scim is now working, as
I told. I exit from mousepad. Run mousepad once again, but, again the context
menu Input Method has gone back to system, and Scim is not working, that is
'Ctrl+Space' is not switching keyboards. Keyboard is and remains English.
(d) Gedit shows the same experience.
4. Run 'locale' as user, showing all variables as 'en_US.UTF-8', and the last
line 'LC_ALL=' blank.
5. Now I come back to terminal, become 'su'. Give 'yum grouplist' and then 'yum
groupinstall XFCE'. And the funny thing is that though during installation I
selected the XFCE group with gui-click, and then ran yum-update several times,
this is now showing:
Transaction Summary -> Install imsettings-xfce 0.99.6-4 and for dependency
update im-chooser 0.99.6-4.
(I ran 'im-chooser --version' as user from another terminal and this showed 0.99.6.)
I gave 'y' to yum and it gave error exit, with a message that
im-chooser-0.99.6-4.fc9.i386 is already installed.
6. Now I enter yumex as root. And in the gui search and select imsettings-xfce
for installation. It installs and comes out with no error.
7. I run through steps 1-4 once again with identical results.
8. I log-out and restart X.
9. I run 1-3 once again, and this time in oowriter/mousepad/gedit with
'Ctrl+Space' I get keyboard switch.
9. So, as I see, installing imsettings-xfce which does not get installed the
groupinstall way or anaconda gui group selection, does the trick. And it seems
now, I was wrong there in assuming something else is doing the trick. Probably I
made some mistake in checking the 'Ctrl+Space' switch immediately after
installing imsettings-xfce. And later, when I got the switch I thought something
else did it.
And this laptop installation in Comment 12 was a fresh install, unlike the
desktop preupgrade one.
Okay, thanks. so summarizing your report, my understanding is:
* You couldn't use SCIM for input on OOo, mousepad and gedit on Xfce.
* You could use SCIM on them if you change Input Method from the pop up menu.
* You can use SCIM now after installing imsettings-xfce
Right? and that is on upgraded systems. but not fresh install. assuming this
understanding is correct, you should file a bug to comps to get imsettings-xfce
with groupinstall or groupupdate. it's not a im-chooser's fault actually.
For fresh install, please check if you have any hotkeys on scim-setup. as long
as your desktop's locale is en_US, the default one is empty as I said earlier.
it's more likely to be a scim issue but not a im-chooser issue then. to dig
down, if Input Method's process is running anyway, I can do nothing on
You were correct about the trigger. In this fresh install on the desktop I can
remember, I was surprised to find that the trigger was not there and I added it
myself. And because I did it earlier, today, when trying to activate Scim it was
And I never thought it was im-chooser's fault. To think that I have to know the
system much better. I simply reported here that my Scim is not working.
Anyway, thanks for all the help, and can you suggest me any not-so-difficult
documentation on Scim/IM and these things? I use them absolutely blindly.
For documentation, not really. we will have to spend more time after making IM
better. Although this is written for developer a bit, you can find out about
imsettings from http://code.google.com/p/imsettings/, but anyway.
Reassigning this to scim for "no hotkeys on non-CJKI locale" issue.
SCIM will not use Ctrl + Space in non-CJKI locales. It's not a bug. If you still
has some problem, please feel free to reopen it.
What should be the Hotkey in Indic context, Bengali or Hindi?
(In reply to comment #17)
> SCIM will not use Ctrl + Space in non-CJKI locales. It's not a bug. If you still
> has some problem, please feel free to reopen it.
What do you suggest to use? And why not Ctrl+Space?
(In reply to comment #19)
> (In reply to comment #17)
> > SCIM will not use Ctrl + Space in non-CJKI locales. It's not a bug. If you still
> > has some problem, please feel free to reopen it.
> What do you suggest to use? And why not Ctrl+Space?
Ctrl + Space should be work in India locales.
I saw your locale in comment #12 is not India. In en_US locale, we will not use
Ctrl + Space by default.
> I saw your locale in comment #12 is not India. In en_US locale, we will not use
> Ctrl + Space by default.
I was not asking about locale, I was asking which trigger do you suggest to use
to get Bangla/Hindi keyboards in Scim? (In reply to comment #20)
I do not use Indian input methods, so I can not answer your question.
FYI. Below is default config for Trigger. Different locales have different
/Hotkeys/FrontEnd/Trigger/as_IN = Control+space
/Hotkeys/FrontEnd/Trigger/bn_IN = Control+space
/Hotkeys/FrontEnd/Trigger/gu_IN = Control+space
/Hotkeys/FrontEnd/Trigger/hi_IN = Control+space
/Hotkeys/FrontEnd/Trigger/ja_JP = Zenkaku_Hankaku,Alt+grave,Control+space
/Hotkeys/FrontEnd/Trigger/kn_IN = Control+space
/Hotkeys/FrontEnd/Trigger/ml_IN = Control+space
/Hotkeys/FrontEnd/Trigger/mr_IN = Control+space
/Hotkeys/FrontEnd/Trigger/ne_IN = Control+space
/Hotkeys/FrontEnd/Trigger/or_IN = Control+space
/Hotkeys/FrontEnd/Trigger/pa_IN = Control+space
/Hotkeys/FrontEnd/Trigger/si_LK = Control+space
/Hotkeys/FrontEnd/Trigger/ta_IN = Control+space
/Hotkeys/FrontEnd/Trigger/te_IN = Control+space
/Hotkeys/FrontEnd/Trigger/ur_IN = Control+space
/Hotkeys/FrontEnd/Trigger/zh_CN = Control+space
/Hotkeys/FrontEnd/Trigger/zh_HK = Control+space
/Hotkeys/FrontEnd/Trigger/zh_SG = Control+space
/Hotkeys/FrontEnd/Trigger/zh_TW = Control+space
(In reply to comment #22)
> /Hotkeys/FrontEnd/Trigger/as_IN = Control+space
> /Hotkeys/FrontEnd/Trigger/bn_IN = Control+space
> /Hotkeys/FrontEnd/Trigger/gu_IN = Control+space
> /Hotkeys/FrontEnd/Trigger/hi_IN = Control+space
See, your list is showing the hotkey trigger for Assamese, Bengali, Gujrati and
Hindi is 'Ctrl+Space'. Whatever the locale maybe, what it has got to do when I
am going into scim, what is the problem in having C+S as the trigger, as your
list itself shows it. I don't understand it. (Maybe it is not meant to be
understood with the absolute lack of technical knowledge like mine.) Anyway, I
have added that trigger and it is working fine.
Another point I do not understand, why this report was renamed in the first
place. It was a problem of Scim not getting activated in Xfce in F9, not
something with hotkeys.
After preupgrading to Fedora9 from Fedora 8, I also went through the same
problem as d das pointed. And I was not able to reach this bug after searching
internet so many times.
My locale is en_US
In im-chooser I had enabled SCIM
In scim-setup I had put the CTRL+SPACE trigger and (Sinhala (si_LK) keyboards
And only after installing imsettings-xfce and restarting X only I was able to
switch IM. (That with the help of das because he has reported the issue in other
mailing lists so I was able to reach him)
My point here is this.
After Fedora 9 preupgrade a user who has used SCIM and XFCE before his IM
switching via keyboard trigger will stop work. When he search the internet he
will never reach this bug because of the misleading title.
PLEASE CHANGE THE TITLE OF THE BUG
(In reply to comment #23)
> Another point I do not understand, why this report was renamed in the first
> place. It was a problem of Scim not getting activated in Xfce in F9, not
> something with hotkeys.
This issue isn't actually relevant to Xfce at all. you could even see no hotkeys
issue on GNOME if you run it on en_US say at the first time.
forgot to mention this too. you have two issues in this report. one is a comps
bug that imsettings-xfce isn't installed from yum groupinstall or groupupdate as
I said earlier. and you should file a bug for that separately to comps. one is
the issue as summary says.
(In reply to comment #26)
> forgot to mention this too. you have two issues in this report. one is a comps
> bug that imsettings-xfce isn't installed from yum groupinstall or groupupdate as
> I said earlier. and you should file a bug for that separately to comps. one is
> the issue as summary says.
Exactly: you told it earlier, but what is 'comps'? How to open a bug there? Can
you just move this bug there, the way you moved it once from its original
context? It is better if you do it, I feel so nervous whenever I come to these
bugzilla pages, and I know so little about these things.
Das: You should be able to file a new bug, against Fedora->9->comps (it should
show up just like any other package). Perhaps a summary of 'imsettings-xfce not
installed by groupinstall' would be good? And provide a link back to this bug
for additional background?
It is in comps-f9 since before F9 was released, however conditional on im-chooser.
So it may depend on the install order.
I am adding it to comps-f10 for @input-methods too.
I am not really sure how to get imsettings-xfce pulled in when upgrading.
It may not be possible unless something requires it explicitly.
dasd: BTW imsettings-xfce is a new package in F9 - which is why you would not know
about it for F8 and earlier.
Update with current status. testcase was:
1. fresh install F-9
2. yum upgrade yum\* rpm\*
3. yum groupinstall japanese-support
4. yum groupinstall xfce-desktop
5. yum groupremove xfce-desktop
6. yum groupinstall xfce-desktop
7. yum groupinstall japanese-support
after step 4, imsettings-xfce has been installed successfully.
after step 5, scim*, im-chooser and imsettings* was removed too.
after step 6, no imsettings-xfce was installed.
after step 7, scim* im-chooser and imsettings* except imsettings-xfce and -devel
as well was installed.
So, as Jens said at comment #29, current behavior depends on the install order. FYI.
I discussed this issue briefly on #fedora-devel list also with Kevin;
and Jeremy Katz suggested that really XFCE should just require imsettings-xfce.
Sorry for the long delay here.
Looking at this further it looks like the conditional in comps was backwards. ;(
It's been fixed at some point, so I think it should now do the right thing.
Can anyone here confirm or deny that it now does the right thing on the initial xfce groupinstall?
I have tried the same steps at comment #32. and I'm afraid it was the same result. or should I try this on rawhide instead of F-9?
I don't think the steps in comment #32 are useful.
The problem is that it's setup to install only if you have installed im-chooser.
If that package is installed and you 'yum groupinstall XFCE' you should see it install imsettings-xfce.
In the orig f9 comps, it was backwards, so it would install im-chooser if imsettings-xfce was installed, which was very wrong.
I guess the ways to see if this bug is fixed is:
1. fresh install F-9
2. yum upgrade yum\* rpm\*
3. yum groupinstall japanese-support
4. yum groupinstall xfce-desktop
and see if imsettings-xfce is installed.
Fedora 10 media install, confirm that Xfce doesn't show up in the list to be installed, as it's not included on the media.
Or is there some other case here I am missing now?
that should works originally by the condition in comps. my understanding is, xfce needs to have a dependency of imsettings-xfce because yum doesn't pull in imsettings-xfce on upgrading now.
Actually in the above test case, imsettings-xfce was pulled in by yum groupinstall japanese-support and the packages in japanese-support group is available in the media. but not imsettings-xfce as well as xfce packages isn't available. If xfce doesn't have a dependency of imsettings-xfce, one needs to do yum groupinstall japanese-support anyway, which should be finished in the usual upgrading already. that doesn't make sense.
requested by Jens Petersen (#27995)
Sorry for the delay here. This bug slipped off my radar. ;(
>that should works originally by the condition in comps. my understanding is,
>xfce needs to have a dependency of imsettings-xfce because yum doesn't pull in
>imsettings-xfce on upgrading now.
ok, so for new installs this works ok now, but for old installs where the user has upgraded it does not, as it doesn't pull in imsettings-xfce, as there is no dependency in place there. I guess that makes sense...
>Actually in the above test case, imsettings-xfce was pulled in by yum
>groupinstall japanese-support and the packages in japanese-support group is
>available in the media. but not imsettings-xfce as well as xfce packages isn't
>available. If xfce doesn't have a dependency of imsettings-xfce, one needs to
>do yum groupinstall japanese-support anyway, which should be finished in the
>usual upgrading already. that doesn't make sense.
ok. I see what you are saying.
I guess I will look at adding that dependency, but I am not entirely sure what Xfce package it should be on. ;(
I think the langpack extension to yum that I am envisaging for F11 might be able to help with these input method package issues.
ok. I think this is fine now in F11 (and possibly in F10 as well now).
Can anyone confirm or deny that the problem still exists?
I've tried to see with Fedora-11 Preview with rawhide repo.
The result for steps at comment #32 is:
After step 4, imsettings-xfce has been installed successfully.
After step 5, IM packages except ibus-libs, imsettings and imsettings-libs are removed.
After step 6, im-chooser and imsettings-xfce has been installed.
After step 7, ibus and ibus-anthy has been installed.
It looks better than the previous behaviour though, I'm a bit surprised that yum groupremove xfce-desktop removes gdm and some GNOME libraries too as well as other IM packages installed originally. I may want to file a bug for that separately, but just FYI.
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Closing according to comment #42.