Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
Summary: imsettings causes window manager confusion in Xfce
https://bugzilla.redhat.com/show_bug.cgi?id=471927
Summary: imsettings causes window manager confusion in Xfce Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: imsettings AssignedTo: tagoh@redhat.com ReportedBy: kevin@tummy.com QAContact: extras-qa@fedoraproject.org CC: tagoh@redhat.com, fedora-i18n-bugs@redhat.com Estimated Hours: 0.0 Classification: Fedora
If the imsettings and imsettings-xfce packages are installed xfwm4 settings are confused and don't think xfwm4 is the window manager.
1. Install imsettings-xfce 2. yum groupinstall XFCE 3. login and choose Xfce as your desktop. 4. right click on the desktop 5. choose settings manager 6. choose either "Window Manager" or "Window Manager Tweaks". 7. You will get a message:
"These settings cannot work with your current window manager (imsetting-xim)"
The code in xfwm4 hasn't changed in years here. It does:
wm_name = gdk_x11_screen_get_window_manager_name (gdk_screen_get_default ()); if (g_ascii_strcasecmp (wm_name, "Xfwm4")) { xfce_err (_("These settings cannot work with your current window manager (%s)"), wm_name); return; }
Is imsettings changing the gdk default window manager somehow?
Removing imsettings causes everything to work as normal.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
Rudolf Kastl che666@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |che666@gmail.com
--- Comment #1 from Rudolf Kastl che666@gmail.com 2008-11-17 13:25:18 EDT --- i can reproduce that on current rawhide. actually if you start the same setting application: xfce-setting-show in the gnome session it would return the correct property
"These settings cannot work with your current window manager (metacity)"
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #2 from Akira TAGOH tagoh@redhat.com 2008-11-17 23:32:30 EDT --- Hmm, strange. I can reproduce here too though, X property looks sane:
$ xprop -root | grep _NET_SUPPORTING_WM_CHECK _NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x1e00062 $ xprop -id 0x1e00062 | grep _NET_WM_NAME _NET_WM_NAME(UTF8_STRING) = 0x58, 0x66, 0x77, 0x6d, 0x34
Property is certainly set Xfwm4 but it complains me "There settings cannot work with your current window manager (imsettings-xim)" as you said. however imsettings definitely doesn't touch that property at all. I'm not really sure where Xfwm4 gets it from.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
Mario Schugowski mario@mediatronix.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mario@mediatronix.de
--- Comment #3 from Mario Schugowski mario@mediatronix.de 2008-11-18 04:04:43 EDT --- same Problem here. I can reproduce the Bug in 32Bit and 64Bit Environment.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mclasen@redhat.com Component|imsettings |gtk2 AssignedTo|tagoh@redhat.com |mclasen@redhat.com Summary|imsettings causes window |Unexpected result from some |manager confusion in Xfce |APIs relates to X property
--- Comment #4 from Akira TAGOH tagoh@redhat.com 2008-11-18 04:21:32 EDT --- Okay, I've tracked down this issue and the problematic code was in gtk+. gtk+ uses XGetWindowProperty to obtain the value assigned to certain X property. it specifies an offset and a length of value in X property. in man page, that says:
long_length Specifies the length in 32-bit multiples of the data to be retrieved.
And the problematic code in gtk+ does give G_MAXLONG as long_length. it will causes an overflow to negative. then it returns the unexpected result.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #5 from Akira TAGOH tagoh@redhat.com 2008-11-18 04:23:18 EDT --- Created an attachment (id=323868) --> (https://bugzilla.redhat.com/attachment.cgi?id=323868) proposed patch
confirmed a fix with this patch. it contains fixes for similar problematic code.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #6 from Kevin Fenzi kevin@tummy.com 2008-11-19 18:31:55 EDT --- Matthias: any chance this could go out as a F-10 0 day update? At least to updates-testing?
Or is this too invasive a fix?
Thoughts?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #7 from Matthias Clasen mclasen@redhat.com 2008-11-20 20:32:53 EDT --- I agree that using LONG_MAX here seems like a bad idea.
But it seems not sufficiently explained how imsettings-xim manages to trigger this problem here.
Do we actually get a BadValue error ?
Also needs to be filed upstream, too.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #8 from Akira TAGOH tagoh@redhat.com 2008-11-25 04:08:01 EDT --- Hmm, just putting a debugging message to see what happens with XGetWindowProperty in gtk+ made it working. also with -3, I can't reproduce this issue with "Window Manager Settings" from the menu. but "Window Manager Tweaks" introduces the above error. I have no idea to reproduce this though, I saw "There settings cannot work with your current window manager (gnome-screensaver)" too.
FWIW no BadValue error.
Assuming the man page describes it correctly, it doesn't says prop_return will be NULL when something went wrong. so maybe should check if actual_type_return and actual_format_return is the expected value and nitems_return is more than 0, also bytes_after_return is 0?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #9 from Akira TAGOH tagoh@redhat.com 2008-11-25 07:46:43 EDT --- For more information:
Sorry, the above was false alarm. and it races something. I've added the below code to see what value XGetWindowProperty returns in gdk_x11_screen_get_window_manager_name():
diff -pruN gtk+-2.14.4.orig/gdk/x11/gdkevents-x11.c gtk+-2.14.4/gdk/x11/gdkevent s-x11.c --- gtk+-2.14.4.orig/gdk/x11/gdkevents-x11.c 2008-10-17 13:06:37.000000000 +0 900 +++ gtk+-2.14.4/gdk/x11/gdkevents-x11.c 2008-11-25 19:40:42.000000000 +0900 @@ -2719,6 +2719,7 @@ gdk_x11_screen_get_window_manager_name ( &type, &format, &n_items, &bytes_after, (guchar **)&name); +g_print("%d: 0x%x, %d, %ld, %ld, %s\n", getpid(), screen_x11->wmspec_check_wind ow, format, n_items, bytes_after, name);
gdk_display_sync (screen_x11->display);
And this appears in .xsession-errors:
21550: 0xe00003, 8, 14, 0, imsettings-xim
pid 21550 is xfce-mcs-manager, which is reporting it. and imsettings-xim certainly owns window id 0xe00003, which was created as a communication window between client and server in XIM. there are no code to modify _NET_WM_NAME nor _NET_SUPPORTING_WM_CHECK in imsettings-xim though. and gtk+ has only code to modify _NET_WM_NAME. and window manager modifies _NET_SUPPORTING_WM_CHECK. actually just running X server and imsettings-xim doesn't create _NET_SUPPORTING_WM_CHECK on the root window.
Since this issue doesn't appear in metacity, I'm a bit suspecting xfwm4 behaves around it differently. looking at xfwm4 now.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
Bug Zapper fedora-triage-list@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|rawhide |10
--- Comment #10 from Bug Zapper fedora-triage-list@redhat.com 2008-11-26 00:31:26 EDT ---
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'.
More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
--- Comment #11 from Akira TAGOH tagoh@redhat.com 2008-11-27 01:31:42 EDT --- I got a trick. the scenario is:
1. metacity runs on gdm. and metacity is set an own window id to _NET_SUPPORTING_WM_CHECK. 2. the desktop session is going to start without restarting X server. and metacity is gone. but _NET_SUPPORTING_WM_CHECK is still there, with invalid window id. 3. imsettings-xim is running. it grabs same window id. thus, window id on _NET_SUPPORTING_WM_CHECK is valid again. which isn't right. 4. xfce-mcs-manager is running before xfwm4. and the unexpected window id is set to GDK_SCREEN_X11 (screen)->wmspec_check_window. it's cached during the instance is alive. so gdk_x11_screen_get_window_manager_name() always returns the unexpected name.
There are some points:
a. metacity doesn't delete _NET_SUPPORTING_WM_CHECK from the root window. it may be dangerous since the window id could be reused. b. invoking xfce-mcs-manager before xfwm4 may be not a good idea as long as it uses gdk_x11_screen_get_window_manager_name(), because of caching the value. it's still likely to return "unknown" if no _NET_SUPPORTING_WM_CHECK is set to the root window and it's being cached before running xfwm4. c. or using gdk_x11_screen_get_window_manager_name() in xfce-mcs-manager may be not a good idea. d. or caching the value in GdkScreen may be not a good idea.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
Paul Michael Reilly pmr@pajato.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pmr@pajato.com
--- Comment #12 from Paul Michael Reilly pmr@pajato.com 2008-12-14 21:21:47 EDT --- FWIW, I've noticed that even after doing a yum remove on the imsettings package (and its dependencies) that I still have a problem with gnome-screensaver which is resolved by removing it and adding xscreensaver. I'm not sure why I see this issue but no one else seems to have it.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #13 from Akira TAGOH tagoh@redhat.com 2008-12-14 22:21:39 EDT --- (In reply to comment #12)
FWIW, I've noticed that even after doing a yum remove on the imsettings package (and its dependencies) that I still have a problem with gnome-screensaver which is resolved by removing it and adding xscreensaver. I'm not sure why I see this issue but no one else seems to have it.
As I've mentioned it at the above comment, the root cause is either of a or b or c or d. but this issue may be not gone completely with one fix only.
for example, if we have a fix for (a) only, you'll see "There settings cannot work with your current window manager (unknown)". a fix for (b) only, there may be a side-effect if xfwm4 requires xfce-mcs-manager working. a fix for (c) only or (d) only, there may be a side-effect so that there are still possibility that xfce-mcs-manager gets a window manager name from X property other than Xfwm4.
I suppose this issue may be gone completely with fixes for (a) and (b). or if some one is sure there are no side-effects with a fix of (c) or (d), we could go with it. but I'm not familiar with Xfce. so need feedbacks from Xfce wizards.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #14 from Matthias Clasen mclasen@redhat.com 2008-12-15 00:04:25 EDT --- Akira, thanks for investing the time to track this down this far.
3. imsettings-xim is running. it grabs same window id. thus, window id on _NET_SUPPORTING_WM_CHECK is valid again. which isn't right.
Have you confirmed that this is actually happening ? I'd be surprised if the X server recycled client ids that quickly, but it is of course possible...
a. metacity doesn't delete _NET_SUPPORTING_WM_CHECK from the root window. it may be dangerous since the window id could be reused.
Worth filing a bug about.
b. invoking xfce-mcs-manager before xfwm4 may be not a good idea as long as it uses gdk_x11_screen_get_window_manager_name(), because of caching the value. it's still likely to return "unknown" if no _NET_SUPPORTING_WM_CHECK is set to the root window and it's being cached before running xfwm4.
If things work as expected, you'll get a window-manager-changed signal in xfce-mcs-manager when xfwm4 starts up, so this shouldn't be a problem. But you'll of course have to expect the warning
xfce_err (_("These settings cannot work with your current window manager (%s)"), wm_name);
to trigger if you start xfce-mcs-manager earlier than xfwm4. And the manager needs to handle window manager changes correctly.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #15 from Matthias Clasen mclasen@redhat.com 2008-12-15 00:07:07 EDT --- Btw, a simple workaround might be to scrub _NET_SUPPORTING_WM_CHECK using xprop, first thing in your session startup, before anything else.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #16 from Matthias Clasen mclasen@redhat.com 2008-12-15 00:32:13 EDT --- Created an attachment (id=326904) --> (https://bugzilla.redhat.com/attachment.cgi?id=326904) try to unset _NET_SUPPORTING_WM_CHECK
Does this metacity patch make things work for you ?
Note that this is only a best-effort patch, it will only help if metacity is shut down gracefully. If it is simply killed, it still leaves _NET_SUPPORTING_WM_CHECK behind.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #17 from Matthias Clasen mclasen@redhat.com 2008-12-15 00:40:52 EDT --- Filed upstream: http://bugzilla.gnome.org/show_bug.cgi?id=564561
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #18 from Akira TAGOH tagoh@redhat.com 2008-12-15 01:05:41 EDT --- (In reply to comment #14)
Akira, thanks for investing the time to track this down this far.
- imsettings-xim is running. it grabs same window id. thus, window id on
_NET_SUPPORTING_WM_CHECK is valid again. which isn't right.
Have you confirmed that this is actually happening ? I'd be surprised if the X server recycled client ids that quickly, but it is of course possible...
Yes, I have. it was surprised to me too. please try the simple testing code I'll attach later.
a. metacity doesn't delete _NET_SUPPORTING_WM_CHECK from the root window. it may be dangerous since the window id could be reused.
Worth filing a bug about.
Sure. filed to Bug#476481 and upstream too (see reference in that bug).
(In reply to comment #15)
Btw, a simple workaround might be to scrub _NET_SUPPORTING_WM_CHECK using xprop, first thing in your session startup, before anything else.
Yes, I did similar thing in a hook of XChangeProperty with LD_PRELOAD to track it down accurately.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #19 from Akira TAGOH tagoh@redhat.com 2008-12-15 01:12:39 EDT --- Created an attachment (id=326906) --> (https://bugzilla.redhat.com/attachment.cgi?id=326906) simple test code
% ./a.out opening a display: f23010 creating a window: 5c00001 destroying a window closing a display: 0 opening a display again: f23010 creating a window again: 5c00001 window id isn't sane enough destroying a window closing a display
So window is is re-used in even same program. for more testing, run it some times. you'll get same window id until any applications grabs and keep running.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #20 from Matthias Clasen mclasen@redhat.com 2008-12-15 10:41:44 EDT --- Does my metacity patch solve your problem ? If yes, I'll put it in our Fedora packages.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #21 from Fedora Update System updates@fedoraproject.org 2008-12-15 12:27:27 EDT --- metacity-2.24.0-4.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/metacity-2.24.0-4.fc10
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #22 from Akira TAGOH tagoh@redhat.com 2008-12-15 21:56:22 EDT --- Unfortunately no. I've installed metacity-2.24.0-4.fc10 and there are still _NET_SUPPORTING_WM_CHECK property in root window before imsettings-xim running say - just put "xprop -root | grep _NET_SUPPORTING_WM_CHECK" line before bringing up imsettings-xim in /etc/X11/xinit/xinitrc.d/50-xinput.sh.
Does this mean metacity shut down with the unexpected way?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #23 from Matthias Clasen mclasen@redhat.com 2008-12-15 21:59:02 EDT --- Yeah, it probably means that metacity was just killed
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #24 from Matthias Clasen mclasen@redhat.com 2008-12-15 22:01:57 EDT --- And just to be clear, the basic problem in all of this is that im-settings stuff is started outside the user session.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #25 from Akira TAGOH tagoh@redhat.com 2008-12-15 22:19:58 EDT --- This isn't imsettings specific issue as per comment #8 and comment #12. this issue is still there even if imsettings moves back behind window manager. assuming applications will grabs different window id or _NET_SUPPORTING_WM_CHECK on the root window without window manager running is really bad.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #26 from Matthias Clasen mclasen@redhat.com 2008-12-15 23:19:18 EDT --- Sure, but
kill wm;...start a bunch of other X apps;... start another wm
is not exactly the typical sequence. In most cases, the wm should be the first X app started in the user session. Anyway, I'll look at making GTK+ handle this a little better. But not tonight.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ON_QA
--- Comment #27 from Fedora Update System updates@fedoraproject.org 2008-12-17 19:38:44 EDT --- metacity-2.24.0-4.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update metacity'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11381
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
Heiko Adams heiko.adams@mymail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |heiko.adams@mymail.ch
--- Comment #28 from Heiko Adams heiko.adams@mymail.ch 2008-12-26 14:16:17 EDT --- Installed metacity-2.24.0-4.fc10 from updates-testing but this does not solve this problem. The problem is still present.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #29 from Matthias Clasen mclasen@redhat.com 2009-01-03 22:36:42 EDT --- Can you try if this build fixes the problem ?
http://koji.fedoraproject.org/koji/taskinfo?taskID=1030934
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #30 from Kevin Fenzi kevin@tummy.com 2009-01-04 14:38:49 EDT --- Yes, the gtk2 package from comment #29 fixes the problem here.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #31 from Heiko Adams heiko.adams@mymail.ch 2009-01-04 16:21:30 EDT --- I can confirm that the gtk2 package from comment #29 fixes the problem
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #32 from Akira TAGOH tagoh@redhat.com 2009-01-05 02:10:56 EDT --- I've tried too. it would be better than before. but I can still sometimes see the one-shot error dialog. it's ok next time as what you've fixed.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
Ken Dreyer ktdreyer@ktdreyer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ktdreyer@ktdreyer.com
--- Comment #33 from Ken Dreyer ktdreyer@ktdreyer.com 2009-01-08 10:28:26 EDT --- I tried with
metacity-2.24.0-4.fc10.i386 gtk2-2.14.5-4.fc10.i386
the error only comes up for "Window Manager Tweaks", and only for about the first 60 seconds after logging in to Xfce. After that, the Window Manager Tweaks dialog appears fine.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #34 from Ken Dreyer ktdreyer@ktdreyer.com 2009-01-08 10:42:25 EDT --- I timed it with "watch -n1 xfce-setting-show wmtweaks"... looks like it's actually only takes about 5 or 10 seconds until it works.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
--- Comment #35 from Bug Zapper fedora-triage-list@redhat.com 2009-11-18 03:53:01 EDT ---
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 '10'.
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 10'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 10 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
Kevin Fenzi kevin@tummy.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |CLOSED Resolution| |CURRENTRELEASE
--- Comment #36 from Kevin Fenzi kevin@tummy.com 2009-11-18 11:35:33 EDT --- This was fixed a while back I am pretty sure... feel free to reopen or file a new one if you spot it again.
i18n-bugs@lists.fedoraproject.org
-
Red Hat Bugzilla