Bug 175966 - gvim shows corrupt buttons
gvim shows corrupt buttons
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
23
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-16 14:26 EST by Pete Zaitcev
Modified: 2016-12-20 06:54 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 06:54:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot (43.93 KB, image/png)
2005-12-16 14:26 EST, Pete Zaitcev
no flags Details

  None (edit)
Description Pete Zaitcev 2005-12-16 14:26:51 EST
Please see the attached screencap.

This happens when running gvim over the network (with ssh -Y forwarding).
Both hosts are i386s running Rawhide.

vim-X11-6.4.003-1

The bug is not reproducible. Only happens infrequently.
Comment 1 Pete Zaitcev 2005-12-16 14:26:51 EST
Created attachment 122344 [details]
screenshot
Comment 2 Karsten Hopp 2006-05-08 07:25:32 EDT
works just fine here with vim-X11-6.4.007-2 and vim-X11-7.0.000-1, please
try those and reopen when the bug is still reproducable.
Note: This looks more like an gtk2 rendering bug to me
Comment 3 Pete Zaitcev 2006-05-08 14:09:27 EDT
I'm sure it's not specifically gvim's fault. I saw Azureus doing it, of all
things. But it's not ubiqutous. Never happens to Ethereal, for example.
I just hoped you'd have some ideas where to look.
Comment 4 Dave Airlie 2007-12-05 04:36:37 EST
sounds like a bug in the xorg driver.. what xorg driver are you using?
Comment 5 Adam Jackson 2007-12-05 08:27:02 EST
Actually.  I'm fairly sure there's something more subtle at work.  The MIT-SHM
extension still shows up in the extension list when using X forwarding.

MIT-SHM does attempt to notice when the client is non-local, but the ssh client
_does_ appear to be local, it's using a Unix socket after all.  So you fall
through to the next failure check, which is that if you're on different
machines, the server's shmat() to the segment provided by the client should
fail.  Except, it only fails statistically; if there are shm segments on both
machines with the same shmid, the server's shmat() will succeed.

If this happens to be the shm segment for the gnome icon cache...

Pete, next time this happens, run 'ipcs' on both machines and see if this is the
case.
Comment 6 Pete Zaitcev 2007-12-05 14:12:07 EST
On display host:

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 32768      zaitcev   600        393216     2          dest         
0x00000000 65537      zaitcev   600        393216     2          dest         
0x00000000 98306      zaitcev   600        393216     2          dest         
0x00000000 131075     zaitcev   600        393216     2          dest         
0x00000000 163844     zaitcev   600        393216     2          dest         
0x00000000 196613     zaitcev   600        393216     2          dest         
0x00000000 229382     zaitcev   600        393216     2          dest         
0x00000000 262151     zaitcev   600        393216     2          dest         
0x00000000 294920     zaitcev   600        393216     2          dest         
0x00000000 327689     zaitcev   600        393216     2          dest         
0x00000000 425994     zaitcev   600        393216     2          dest         
0x00000000 4325387    zaitcev   600        393216     2          dest
0x00000000 1540108    zaitcev   600        393216     2          dest
0xae5256c1 1802254    zaitcev   660        64528      0

On application host after the failure:

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 32768      zaitcev   600        393216     1          dest         

If application starts normally, there's no shared segment.
Comment 7 Adam Jackson 2007-12-07 09:54:30 EST
Well that explains that.

I think the correct solution here is for openssh to mangle the connection block
to remove the MIT-SHM extension, although we should probably also best-effort
this in xtrans and always consider processes named 'ssh' to be non-local.
Comment 8 Adam Jackson 2007-12-10 11:23:41 EST
Reassigning to xserver.
Comment 9 Adam Jackson 2007-12-12 13:54:51 EST
I built a (terrible) hack for this in the newest X server in rawhide
(xorg-x11-server-1.4.99.1-0.13.fc9).  Give it a try.
Comment 10 Pete Zaitcev 2007-12-14 23:26:04 EST
Looks like it works, after a restart of sshd.
Comment 11 Pete Zaitcev 2007-12-22 18:27:09 EST
It just reccured now. The ipcs shows:

key        shmid      owner      perms      bytes      nattch     status      
0x00000000 65537      zaitcev   600        393216     1          dest         

Segment 65537 exists at the display host.

Installed xorg packages:

xorg-x11-apps-7.3-1.fc8
xorg-x11-docs-1.3-1.fc7
xorg-x11-drivers-7.2-10.fc9
xorg-x11-drv-acecad-1.1.0-5.fc8
xorg-x11-drv-aiptek-1.0.1-5.fc8
xorg-x11-drv-apm-1.1.1-2.1
xorg-x11-drv-apm-1.1.1-7.fc8
xorg-x11-drv-ark-0.6.0-6.fc8
xorg-x11-drv-ast-0.81.0-6.fc8
xorg-x11-drv-ati-6.7.196-1.fc8
xorg-x11-drv-avivo-0.0.1-6.fc8
xorg-x11-drv-calcomp-1.1.0-4.fc8
xorg-x11-drv-chips-1.1.1-5.fc8
xorg-x11-drv-cirrus-1.1.0-5.fc8
xorg-x11-drv-citron-2.2.0-2.fc7
xorg-x11-drv-digitaledge-1.1.0-4.fc8
xorg-x11-drv-dmc-1.1.0-3.fc7
xorg-x11-drv-dummy-0.2.0-6.fc9
xorg-x11-drv-dynapro-1.1.0-3.fc7
xorg-x11-drv-elographics-1.1.0-4.fc8
xorg-x11-drv-evdev-1.2.0-1.fc9
xorg-x11-drv-fbdev-0.3.1-4.20071113.fc9
xorg-x11-drv-fpit-1.1.0-4.fc8
xorg-x11-drv-glint-1.1.1-7.fc8
xorg-x11-drv-hyperpen-1.1.0-5.fc8
xorg-x11-drv-i128-1.2.1-1.fc8
xorg-x11-drv-i740-1.1.0-5.fc8
xorg-x11-drv-i810-2.2.0-1.fc9
xorg-x11-drv-jamstudio-1.1.0-4.fc8
xorg-x11-drv-keyboard-1.2.2-3.fc9
xorg-x11-drv-magellan-1.1.0-4.fc8
xorg-x11-drv-magictouch-1.0.0.5-5.fc8
xorg-x11-drv-mga-1.4.6.1-6.fc8
xorg-x11-drv-microtouch-1.1.0-2.fc7
xorg-x11-drv-mouse-1.2.3-3.fc9
xorg-x11-drv-mutouch-1.1.0-5.fc8
xorg-x11-drv-nouveau-2.1.6-2.fc9
xorg-x11-drv-nv-2.1.6-2.fc9
xorg-x11-drv-openchrome-0.2.900-7.fc9
xorg-x11-drv-palmax-1.1.0-4.fc8
xorg-x11-drv-penmount-1.1.0-3.fc7
xorg-x11-drv-rendition-4.1.3-5.fc8
xorg-x11-drv-s3-0.5.0-5.fc8
xorg-x11-drv-s3virge-1.9.1-5.fc8
xorg-x11-drv-savage-2.1.3-1.fc8
xorg-x11-drv-siliconmotion-1.5.1-3.fc8
xorg-x11-drv-sis-0.9.3-4.fc8
xorg-x11-drv-sisusb-0.8.1-9.fc8
xorg-x11-drv-spaceorb-1.1.0-4.fc8
xorg-x11-drv-summa-1.1.0-4.fc8
xorg-x11-drv-tdfx-1.3.0-6.fc8
xorg-x11-drv-tek4957-1.1.0-4.fc8
xorg-x11-drv-trident-1.2.3-6.fc8
xorg-x11-drv-tseng-1.1.0-7.fc8
xorg-x11-drv-ur98-1.1.0-4.fc8
xorg-x11-drv-v4l-0.1.1-8.fc8
xorg-x11-drv-vesa-1.3.0-11.20071113.fc9
xorg-x11-drv-vga-4.1.0-5.fc8
xorg-x11-drv-via-0.2.2-4.fc8
xorg-x11-drv-vmmouse-12.4.3-1.fc8
xorg-x11-drv-vmware-10.15.2-1.fc8
xorg-x11-drv-void-1.1.1-7.fc9
xorg-x11-drv-voodoo-1.1.1-1.fc8
xorg-x11-filesystem-7.1-2.fc6
xorg-x11-fonts-100dpi-7.2-4.fc9
xorg-x11-fonts-75dpi-7.2-4.fc9
xorg-x11-fonts-ISO8859-1-100dpi-7.2-4.fc9
xorg-x11-fonts-ISO8859-1-75dpi-7.2-4.fc9
xorg-x11-fonts-misc-7.2-4.fc9
xorg-x11-fonts-truetype-7.2-4.fc9
xorg-x11-fonts-Type1-7.2-4.fc9
xorg-x11-font-utils-7.2-2.fc8
xorg-x11-proto-devel-7.3-7.fc9
xorg-x11-server-common-1.4.99.1-0.13.fc9
xorg-x11-server-devel-1.4.99.1-0.13.fc9
xorg-x11-server-utils-7.3-2.fc9
xorg-x11-server-Xorg-1.4.99.1-0.13.fc9
xorg-x11-twm-1.0.3-1.fc8
xorg-x11-util-macros-1.1.5-1.fc7
xorg-x11-utils-7.3-1.fc8
xorg-x11-xauth-1.0.2-3.fc8
xorg-x11-xfs-1.0.5-1.fc8
xorg-x11-xinit-1.0.7-2.fc8
xorg-x11-xkb-utils-7.2-3.fc8
xorg-x11-xtrans-devel-1.0.3-5.fc8
Comment 12 Adam Jackson 2008-02-13 13:40:46 EST
Grr.  Well, the patch in the X server is definitely doing its job at rejecting
XShmAttach() calls from ssh clients.  Perhaps we need to be more aggressive and
should mangle the connection block on the server side?  I'm loathe to try to
hack that into ssh, its knowledge of X protocol is politely described as primitive.
Comment 13 Pete Zaitcev 2008-02-13 18:59:38 EST
I did not realize that the patch was applied to the server size,
which probably wasn't updated at the time. Please give me a day or
two to retest (I started using screen(1) and vi to avoid this, so
I don't have the test data right away).
Comment 14 Matěj Cepl 2008-02-14 09:08:06 EST
Bureaucratic nitpicking -- let's keep this open, until you retest it.
Comment 15 Matěj Cepl 2008-03-19 12:35:55 EDT
Reporter, could you please reply to the previous question? If you won't reply in
one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Comment 16 Pete Zaitcev 2008-03-19 13:43:59 EDT
It works now.
Comment 17 Pete Zaitcev 2008-04-06 23:56:43 EDT
You won't believe it, but it reoccured just now.

On display server, ipcs:

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 0          root      644        72         0
0x00000000 32769      root      644        16384      0
0x00000000 65538      root      644        280        0
0x00000000 98307      root      644        72         0
0x00000000 131076     root      644        16384      0
0x00000000 163845     root      644        280        0
0x00000000 294918     zaitcev   600        393216     2          dest
0x00000000 327687     zaitcev   600        393216     2          dest
0x00000000 360456     zaitcev   600        393216     2          dest
0x00000000 393225     zaitcev   600        393216     2          dest
0x00000000 425994     zaitcev   600        393216     2          dest
0x00000000 458763     zaitcev   600        393216     2          dest
0x00000000 491532     zaitcev   600        393216     2          dest
0x00000000 524301     zaitcev   600        393216     2          dest
0x00000000 557070     zaitcev   600        393216     2          dest
0x0056a4d5 30507023   zaitcev   600        488        1
0x00000000 688144     zaitcev   600        393216     2          dest
0x0056a4d6 30539793   zaitcev   600        65536      1
0x00000000 26476562   zaitcev   600        393216     2          dest
0x00000000 26509331   zaitcev   600        393216     2          dest
0x00000000 33226772   zaitcev   600        393216     2          dest
0x00000000 2752533    zaitcev   600        12288      2          dest
0x00000000 2785302    zaitcev   600        393216     2          dest
0x00000000 2818071    zaitcev   600        12288      2          dest
0x00000000 3309592    zaitcev   600        393216     2          dest
0x00000000 33259545   zaitcev   600        393216     2          dest
0x00000000 33292314   zaitcev   600        12288      2          dest
0x00000000 33652763   zaitcev   600        393216     2          dest
0x00000000 33685532   zaitcev   600        393216     2          dest
0x00000000 33718301   zaitcev   600        12288      2          dest
0x00000000 33914911   zaitcev   600        393216     2          dest
0x00000000 33947680   zaitcev   600        393216     2          dest
0x00000000 33980449   zaitcev   600        12288      2          dest
0x00000000 34570274   zaitcev   600        393216     2          dest
0x00000000 34603043   zaitcev   600        393216     2          dest
0x00000000 34635812   zaitcev   600        12288      2          dest
0x00000000 34996261   zaitcev   600        393216     2          dest
0x00000000 35029030   zaitcev   600        393216     2          dest
0x00000000 35061799   zaitcev   600        12288      2          dest

On application system, ipcs:

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 0          root      644        72         0                       
0x00000000 32769      root      644        16384      0                       
0x00000000 65538      root      644        280        0                       
0x00000000 98307      root      644        72         0                       
0x00000000 131076     root      644        16384      0                       
0x00000000 163845     root      644        280        0                       
0x00000000 294918     zaitcev   600        393216     1          dest         
0x00000000 327687     zaitcev   600        393216     1          dest         

I don't quite know what this means, so I looked at PIDs just
in case (who knows when it occurs again!).

------ Shared Memory Creator/Last-op --------
shmid      owner      cpid       lpid      
0          root       1465       1465      
32769      root       1465       1465      
65538      root       1465       1465      
98307      root       1488       1488      
131076     root       1488       1488      
163845     root       1488       1488      
294918     zaitcev    10005      10005     
327687     zaitcev    10009      10009     

Processes 1465, 1488 do not exist anymore. I'm sure they have some-
thing to do with the system startup. The 10005 and 10009 do not
exist either, but 10006 and 10010 are gvim instances. Since gvim
backgrounds itself, they must be gvims.
Comment 18 Pete Zaitcev 2008-04-07 00:16:24 EDT
Just in case - on server:

------ Shared Memory Creator/Last-op --------
294918     zaitcev    2325       1964
327687     zaitcev    2386       5706

2335: scim-panel-gtk   -- no, srsly
1964: X
2386: gnome-panel
5706: [does not exist]

ssh is 5933

xorg-x11-server-utils-7.3-3.fc9.x86_64
xorg-x11-server-Xorg-1.4.99.901-16.20080401.fc9.x86_64
xorg-x11-server-common-1.4.99.901-16.20080401.fc9.x86_64
Comment 19 Bug Zapper 2008-05-13 22:04:05 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 20 Mike Gahagan 2008-06-18 12:37:19 EDT
I see this on occation with firefox, thunderbird and a few other random apps
when run remotely for probably over 2 years. I've thought it might be a gtk or
other related toolkit issue, but have never been able to isolate the problem and
reproduce reliably, but I probably see it about 10% of the time with various
combinations of RHEL 5, Fedora 8,9.

Come to think of it, I have never seen a kde app do this that I can remember
which sort of lead me to believe this might be a tool kit issue.
 
Comment 21 Bug Zapper 2009-06-09 05:08:31 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 22 Matěj Cepl 2009-11-05 13:18:31 EST
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Comment 23 Mike Gahagan 2009-11-05 13:33:49 EST
It has been a really long time since I have seen this issue, but I will keep an eye out for it for the next week or so and try and reproduce it if it happens on one of my F12 systems.
Comment 24 Pete Zaitcev 2009-11-06 13:43:37 EST
Very easy to reproduce
 xorg-x11-server-common-1.7.0-1.fc12.x86_64
 libX11-1.3-1.fc12.x86_64
Comment 25 Bug Zapper 2009-11-16 02:50:19 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 26 Bug Zapper 2010-11-04 08:17:56 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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
Comment 27 Pete Zaitcev 2010-11-04 10:34:01 EDT
libX11-1.3.1-3.fc13.x86_64
xorg-x11-server-common-1.8.2-4.fc13.x86_64

I take it, since Ajax's attempt to fix in 2007, nothing else was found
to be possible. Maybe we should just wontfix this?
Comment 28 Bug Zapper 2011-06-02 14:44:33 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  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 '13'.

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 13'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 13 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
Comment 29 Fedora End Of Life 2012-08-07 16:07:35 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

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
Comment 30 Richard W.M. Jones 2013-04-05 06:20:12 EDT
Apparently this could be fixed after this commit
was added to the X server:

http://cgit.freedesktop.org/xorg/xserver/commit/?id=e2c7d70e5ddb8b17676a13ceebfbb87d14d63243

It requires two additional fixes to openssh and libX11:

<quote source="ajax">

So at this point we just need client support, which I think is:

a) hack openssh to do the new handshake
b) add XLIB_FORCE_REMOTE=1 support to libX11

</quote>
Comment 31 Tim Waugh 2014-10-17 05:22:40 EDT
Should bugs be filed for those items then? They don't seem to be fixed yet.
Comment 32 Jan Kurik 2015-07-15 11:27:40 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Comment 33 Fedora End Of Life 2016-11-24 05:17:01 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. 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 EOL if it remains open with a Fedora  'version'
of '23'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.
Comment 34 Fedora End Of Life 2016-12-20 06:54:43 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.