Description of problem: After finishing a game, I was sliding the side panel dividers left and right. Pychess hung with a horizontal double-arrow pointer. The gnome desktop was also hung -- could not change workspaces or pull down menus. The pointer moved but did not change when moved outside the pychess window. The keyboard (capslock/numlock) was responsive. The consoles could be displayed. Version-Release number of selected component (if applicable): pychess-0.10-0.1.20100203svn.fc12.noarch python-2.6.2-2.fc12.x86_64 How reproducible: Saw twice. Steps to Reproduce: 1. Enable display of side panels. 2. Disable display of chat side panel. 3. Play chess -- the second occurrence was after two moves. 4. Move various panel dividers left and right. Actual results: Pychess and gnome desktop hang. Expected results: Pychess and gnome desktop respond to input. Additional info: Recovered by killing all pychess processes from a console. CPU was at 100%, but I believe that occurs when hint/spy mode are enabled. Ran strace from a console on all of the pychess processes -- attachment to follow.
Created attachment 389315 [details] strace log for pychess processes while pychess was hung This was captured with the script command from a console.
Hi Steve, thanks for the bug report. I don't have a clue, what's going on there, so I reported this upstream at [1]. Hopefully they have a solution. [1] http://code.google.com/p/pychess/issues/detail?id=524
(In reply to comment #2) > I don't have a clue, what's going on there, so I reported this upstream at [1]. > Hopefully they have a solution. > [1] http://code.google.com/p/pychess/issues/detail?id=524 Thanks, Thomas. Here is some more version info: pygtk2-2.16.0-1.fc12.x86_64 pygtk2-libglade-2.16.0-1.fc12.x86_64 gnome-python2-rsvg-2.28.0-2.fc12.x86_64
Created attachment 389442 [details] strace while hung after changing hint/spy settings in View menu This hang occurs while enabling and disabling the hint and spy modes in the View menu. Procedure: 1. Enable both hint and spy analyzers in Preferences:Computer Opponents. 2. Start game. 3. While playing, variously enable and disable hint and/or spy mode in the View menu. 4. May hang while the View menu is displayed. I was able to reproduce this three times. Recover by switching to a console and doing a "killall /usr/bin/python" (assuming pychess is the only python prog. running, anyway :-)). Two of the pychess processes consume 100% of the CPU when the hint/spy analyzers are enabled. This attachment was captured with the "script" command in a console. I deleted all the control characters for legibility.
Could you also attach a logfile from ~/.pychess, when this happens? (Asked from upstream.)
(In reply to comment #5) > Could you also attach a logfile from ~/.pychess, when this happens? > > (Asked from upstream.) Hi Thomas, Didn't know about that ... Found quite a bit of my personal playing style there. I find it *very offensive* to my sense of privacy to be asked to upload a log of my chess games without being informed that I am doing so. I really like pychess and will be happy to contribute further, otherwise. BTW, is 100% CPU what you would expect from a chess program for beginners? And thanks for picking up the baton ...
Just noticed that the View:Show Sidepanels option is checked after starting a game, but no side panels are displayed. Unchecking it causes the entire chess board to disappear! And it cannot be restored. Are you able to reproduce any of these problems? The comments upstream have me wondering if there is an incompatibility between pychess-0.10-0.1.20100203svn.fc12.noarch and some of the libraries or packages in Fedora 12. I'm not sure which ones to check, so here is a long list (my system is fully updated): $ rpm -qa '*gtk*' | sort authconfig-gtk-6.0.0-2.fc12.x86_64 clutter-gtk-0.10.2-1.fc12.x86_64 GConf2-gtk-2.28.0-4.fc12.x86_64 gnome-python2-gtkhtml2-2.25.3-14.fc12.x86_64 gtk2-2.18.6-3.fc12.x86_64 gtk2-engines-2.18.4-4.fc12.x86_64 gtk2-immodule-xim-2.18.6-3.fc12.x86_64 gtkglext-libs-1.2.0-10.fc12.x86_64 gtkhtml2-2.11.1-6.fc12.x86_64 gtkhtml3-3.28.2-1.fc12.x86_64 gtkmm24-2.18.2-1.fc12.x86_64 gtksourceview2-2.8.2-1.fc12.x86_64 gtkspell-2.0.16-1.fc12.x86_64 gtk-vnc-0.3.10-2.fc12.x86_64 ibus-gtk-1.2.0.20100111-2.fc12.x86_64 libcanberra-gtk2-0.22-1.fc12.x86_64 libchamplain-gtk-0.4.3-1.fc12.x86_64 PackageKit-gtk-module-0.5.6-1.fc12.x86_64 pinentry-gtk-0.7.6-4.fc12.x86_64 pygtk2-2.16.0-1.fc12.x86_64 pygtk2-libglade-2.16.0-1.fc12.x86_64 pygtkglext-1.1.0-7.fc12.x86_64 pygtksourceview-2.8.0-1.fc12.x86_64 python-slip-gtk-0.2.7-1.fc12.noarch pywebkitgtk-1.1.6-2.fc12.x86_64 usermode-gtk-1.102-1.fc12.x86_64 webkitgtk-1.1.15.4-1.fc12.x86_64 xdg-user-dirs-gtk-0.8-4.fc12.x86_64
Ahah! I think I've discovered part of the problem! I simply moved the .pychessconf file and the .pychess directory out of my home directory, so pychess could recreate them. Voila! The side panels are now displayed when the "View:Show Sidepanels" option is selected and they disappear when it is deselected. The chess board remains visible. It occurs to me that the config files were left over from the *old* version of pychess. Does the installer do anything with them? Another possibility is that there was corruption, because I killed the processes after they hung.
(In reply to comment #6) > (In reply to comment #5) > > Could you also attach a logfile from ~/.pychess, when this happens? > > > > (Asked from upstream.) > Found quite a bit of my personal playing style there. > I find it *very offensive* to my sense of privacy > to be asked to upload a log of my chess games > without being informed that I am doing so. > > I really like pychess and will be happy to contribute further, otherwise. I find it *very pushy* to report not reproducable bug reports with the demand to fix them without helping out with such log files. It's your choice not to give your log files away, but don't expect any help from upstream then. Meanwhile there is a log file from someone else: http://code.google.com/p/pychess/issues/detail?id=524 (In reply to comment #8) > I simply moved the .pychessconf file and the .pychess directory out of my home > directory, so pychess could recreate them. Is it possible to get it crash again?
(In reply to comment #9) > I find it *very pushy* to report not reproducable bug reports with the demand > to fix them without helping out with such log files. > > It's your choice not to give your log files away, but don't expect any help > from upstream then. > Meanwhile there is a log file from someone else: > http://code.google.com/p/pychess/issues/detail?id=524 I apologize for overreacting. I have seen log files with personal/security info and am thus quite paranoid about blindly uploading. In this case they are not likely to be of much help anyway -- buffers not flushed, insufficient low-level detail, etc. > (In reply to comment #8) > > I simply moved the .pychessconf file and the .pychess directory out of my home > > directory, so pychess could recreate them. > > Is it possible to get it crash again? Unfortunately, yes. Pychess still hangs. Have you tried to reproduce the hanging?
Weird ... now I have pychess alone hung, and the gnome desktop working normally. CPU is at 100%. I was in the process of enabling hint and spy mode display in the View menu. IIRC, it hung after I had selected hint display and the green hint arrow was displayed, but before I could enable spy display. This is very similar to what I described in comment 4. This time I started pychess from a terminal: [stephent@walnut ~]$ pychess /usr/lib/python2.6/site-packages/pychess/System/uistuff.py:374: GtkWarning: GtkSpinButton: setting an adjustment with non-zero page size is deprecated self.glade = gtk.glade.XML(addDataPrefix("glade/%s" % filename)) Or is it me? Am I doing anything? shown changed 1 Am I doing anything? shown changed 2 Am I doing anything? shown changed 3 Am I doing anything? shown changed 4 setting spymode for <GameWidget object at 0x7f58c8095500 (pychess+widgets+gamewidget+GameWidget at 0x3ccb5a0)> to True The strace results look similar to ones already attached.
Created attachment 389638 [details] yet another strace log while hung This one occurred while attempting to enable display of the side panels. The desktop was hung. However, the analyzers were disabled, so there are only two processes. The straces were done for each process separately, making it a bit easier to see what each is doing. A gdb backtrace from a core file follows. Sorry about all the control characters -- was using "script" again and didn't want to accidentally delete something important.
Created attachment 389642 [details] gdb backtrace for pychess while hung This was produced as follows: $ kill -3 3290 $ sudo debuginfo-install python-2.6.2-2.fc12.x86_64 $ sudo debuginfo-install gtk2 $ sudo debuginfo-install libxcb $ gdb /usr/bin/python core.3290 (gdb) bt I don't really know how to interpret this, but it seems that the process hung waiting for a reply from the X server while attempting to get the pointer position. Googling finds several discussions of xcb_wait_for_reply.
One other curiosity ... :-) There is a known F12 bug in which "ls -a" may hang. I have encountered it several times, including just after pychess hung this last time. Procedure is simple -- from a console (any terminal, if the desktop is responding): $ cd $ ls -a # may hang here -- ctrl-C will not terminate this hang FUSE mounts may hang http://fedoraproject.org/wiki/Common_F12_bugs#fuse-mount-xattr
Created attachment 390013 [details] replacement for Attachment 389638 [details] Removed redundant lines from beginning of file. No new info, otherwise.
(In reply to comment #13) > Created an attachment (id=389642) [details] > gdb backtrace for pychess while hung Searched BZ for XQueryPointer and found this crash report, which is assigned to gtk2. Bug 549043 - [abrt] crash detected in NetworkManager-gnome-1:0.7.996-7.git20091113.fc12
Reproduced hanging on my laptop (previous cases were on my desktop). Removed .pychessconf and .pychess/ before starting from a terminal. Two things I do consistently: 1. Disable sound. 2. Hide and the show the side panels (leaving the layout reported in Bug 562895). Crash report induced by "kill -3" is here (incorrectly assigned to python): Bug 563739 - [abrt] crash in python-2.6.2-2.fc12
*** Bug 563739 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > Created an attachment (id=389642) [details] > gdb backtrace for pychess while hung > > This was produced as follows: > > $ kill -3 3290 > $ sudo debuginfo-install python-2.6.2-2.fc12.x86_64 > $ sudo debuginfo-install gtk2 > $ sudo debuginfo-install libxcb > $ gdb /usr/bin/python core.3290 > (gdb) bt > > I don't really know how to interpret this, but it seems that the process hung > waiting for a reply from the X server while attempting to get the pointer > position. There are too many 'value optimized out' to be useful :( The feature [1] is close to be usable and (partly) implemented in the python2 rawhide version. Maybe this can be reproduced on fc13 and the backtrace says a bit more. But because you use kill (again), the backtrace shows not, where pychess crashed, it shows, where you crashed it ;) So something from the X server 'is doing' something and you kill it. I'm unsure, if this is the right way to track this down... [1] https://fedoraproject.org/wiki/Features/EasierPythonDebugging
(In reply to comment #19) > There are too many 'value optimized out' to be useful :( OK. > The feature [1] is close to be usable and (partly) implemented in the python2 > rawhide version. Maybe this can be reproduced on fc13 and the backtrace says a > bit more. Thanks. That looks like a very nice tool. > But because you use kill (again), the backtrace shows not, where pychess > crashed, it shows, where you crashed it ;) > So something from the X server 'is doing' something and you kill it. In the hang documented in Attachment 390013 [details], all threads were blocked, IIUC, so there was only one place to kill it. :-) However, I now understand that what you really need is a python backtrace ... ABRT captured a python backtrace after the crash (not hang) that occurred on my laptop: Bug 563720. NB: This was not induced by me running "kill -3" ... it's not my fault. :-) Summary: TBa943226a PyChess.py:252:run:EOFError: EOF when reading a line For the same crash, I reported (in a separate ABRT report) the terminal output from pychess: Attachment 390128 [details] to Bug 563714. ISTM ABRT could have combined those into one report ... I had to manually add cross-references. > I'm unsure, if this is the right way to track this down... OK. > [1] https://fedoraproject.org/wiki/Features/EasierPythonDebugging
Possible crash reproducer using the "--sync" command line option. May take a few tries. I have gotten this to happen several times on two different systems. $ rm .pychessconf $ rm -r .pychess/ $ killall python # clean up any orphaned analyzer processes Start pychess with the "--sync" option: $ pychess --sync Start game. Enable View:Hint mode Enable View:Spy mode ... pychess aborts with an assertion failure or exits with an X error $ pychess --sync /usr/lib/python2.6/site-packages/pychess/System/uistuff.py:374: GtkWarning: GtkSpinButton: setting an adjustment with non-zero page size is deprecated self.glade = gtk.glade.XML(addDataPrefix("glade/%s" % filename)) Or is it me? setting spymode for <GameWidget object at 0x1b464b0 (pychess+widgets+gamewidget+GameWidget at 0x7f164c092660)> to True python: xcb_io.c:176: process_responses: Assertion `!(req && current_request && !(((long) (req->sequence) - (long) (current_request)) <= 0))' failed. Aborted (core dumped) Sometimes pychess doesn't abort, but simply exits: $ pychess --sync /usr/lib/python2.6/site-packages/pychess/System/uistuff.py:374: GtkWarning: GtkSpinButton: setting an adjustment with non-zero page size is deprecated self.glade = gtk.glade.XML(addDataPrefix("glade/%s" % filename)) 12:01:44 ('Gnuchess', '12:02:44.329') Warning: Chan closed for 'nopost' 12:01:44 ('Gnuchess', '12:02:44.329') Warning: Chan closed for ' ' 12:01:44 ('Gnuchess', '12:02:44.329') Error: Success 12:01:44 ('Python', '12:02:44.286') Warning: Chan closed for 'nopost' 12:01:44 ('Python', '12:02:44.286') Warning: Chan closed for ' ' Or is it me? setting spymode for <GameWidget object at 0x7fe1e40e6960 (pychess+widgets+gamewidget+GameWidget at 0x7fe1d8002620)> to True pychess: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. The "--sync" option is suggested in this error message reported in Bug 563714: ===== Gdk-ERROR **: The program 'pychess' received an X Window System error. This probably reflects a bug in the program. The error was 'BadIDChoice (invalid resource ID chosen for this connection)'. (Details: serial 101438 error_code 14 request_code 53 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) aborting... Aborted (core dumped) =====
Could you try to reproduce this with the new version? Nobody else (either me or upstream) can reproduce this. This is possibly a bug in a '*gtk*' package and not in pychess itself.
Created attachment 394222 [details] gdb session log for pychess while hung gdb session log for pychess-0.10-0.3.20100214svn.fc12.noarch while hung. pychess hung while testing for Bug 563330. It hung with a small, blue tooltip displayed. Hint/spy arrows were disabled and no chess moves were made. The desktop continued to respond as expected. Command was "pychess" (without the "--sync" option). I am temporarily using the vesa xorg video driver to see if that has any effect. I attached with gdb to the parent process while it was hung. (No "kill -3" needed -- my technique is improving ... :-)) All symbols were loaded. Am now using /usr/share/doc/python-devel-2.6.2/gdbinit to get a python file name and line number (pyframe).
(In reply to comment #22) > Could you try to reproduce this with the new version? > > Nobody else (either me or upstream) can reproduce this. > > This is possibly a bug in a '*gtk*' package and not in pychess itself. Unfortunately, pychess-0.10-0.3.20100214svn.fc12.noarch hangs. Could be a gtk bug, but given the complexity of this app., gtk devs. probably won't be convinced. :-) BTW, I also took your suggestion to try rawhide -- reproduced the abort described in comment 21. Booted desktop-x86_64-20100211.17.iso off a USB stick. Applied updates to some of the critical libs., e.g. gtk2, glib2. Ran "pychess --sync". Have any of you tried the "--sync" option? gdb didn't display python stack frame info. -- not sure what is wrong there.
(In reply to comment #24) > (In reply to comment #22) > > Could you try to reproduce this with the new version? > > Nobody else (either me or upstream) can reproduce this. > > This is possibly a bug in a '*gtk*' package and not in pychess itself. > > Unfortunately, pychess-0.10-0.3.20100214svn.fc12.noarch hangs. Good news! This combo seems to be solid on my desktop system: pychess-0.10-0.3.20100214svn.fc12.noarch rawhide: desktop-x86_64-20100211.17.iso booted off a USB stick Applied a lot of updates and then tried everything that had been failing before (including "pychess" and "pychess --sync"). It all worked great! No hangs, aborts, or abnormal exits. Will need to DL a 32-bit version of rawhide to try on my laptop.
(In reply to comment #25) > Will need to DL a 32-bit version of rawhide to try on my laptop. Now the bad news ... I got an abort on assertion failure with the two latest versions of pychess while running rawhide on my laptop (booted off a USB stick). Same procedure as in comment 21 ("pychess --sync"). "-0.3" took much longer to abort. http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-i386-20100214.18.iso (No updates were applied.) http://kojipkgs.fedoraproject.org/packages/pychess/0.10/0.2.20100203svn.fc13/noarch/pychess-0.10-0.2.20100203svn.fc13.noarch.rpm http://kojipkgs.fedoraproject.org/packages/pychess/0.10/0.3.20100214svn.fc13/noarch/pychess-0.10-0.3.20100214svn.fc13.noarch.rpm When pychess aborts, it is at xcb_io.c:183, and the assertion failure is the same as in comment 21. (I would post the full msg, but it is on my laptop, and I am using my desktop.) Also saw an exit on X error. My laptop is an Asus Z91E, Intel Pentium M 1.73GHz, 500Mb.
Created attachment 394489 [details] pychess session on rawhide ending with an abnormal exit Have now installed rawhide on a disk partition on my desktop system. Have reproduced the abnormal exit with the latest version of pychess. In summary, I can now reproduce the problem on two very different systems with the same software (except that one is 64-bit and one is 32-bit): desktop-x86_64-20100214.18.iso pychess-0.10-0.3.20100214svn.fc13.noarch.rpm The attached session also shows some other error msgs. involving gstreamer and audio that I don't know how to interpret. I was disabling sound effects as part of my testing. ... ERROR: Caught a segmentation fault while loading plugin file: /usr/lib64/gstreamer-0.10/libgstlv2.so ... Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/pychess/widgets/preferencesDialog.py", line 312, in <lambda> lambda data: data[3].startswith("audio/")) AttributeError: 'NoneType' object has no attribute 'startswith' ... Possible new trick for devs. to reproduce -- try underclocking your CPU. My desktop system runs at 2.7 GHz max., but with the CPU Frequency Scaling Monitor, I can set it to run as slow as 800 MHz. My desktop system is a Biostar A785GE mobo., AMD Sempron 140 (64-bit), 2 Gb.
This is something of a random hunch, but could this be another bug arising from the change to GDK client window rendering, rather than native rendering? Does the bug mysteriously go away if you set GDK_NATIVE_WINDOWS=1 in the environment when starting the pygtk application? See bug 543278 and http://library.gnome.org/devel/gtk/stable/gtk-migrating-ClientSideWindows.html I believe this changed in gtk2-2.18, in Fedora 12 onwards. Again, this is just a hunch
(In reply to comment #28) > This is something of a random hunch, but could this be another bug arising from > the change to GDK client window rendering, rather than native rendering? Thanks for your detailed tip, Dave. > Does the bug mysteriously go away if you set GDK_NATIVE_WINDOWS=1 in the > environment when starting the pygtk application? ... After setting GDK_NATIVE_WINDOWS, I cannot crash pychess in a few clicks (4 min.). Indeed, I can play long enough that I have to resign. :-) Thanks! Thomas, what do you think? Procedure: $ export GDK_NATIVE_WINDOWS=1 $ rm -r .pychess; rm .pychessconf $ killall python $ pychess --sync Start game check View:Hint mode check View:Spy mode uncheck View:Hint mode uncheck View:Spy mode (Before setting GDK_NATIVE_WINDOWS, pychess would usually have crashed by this point.) == gtk2-2.18.6-3.fc12.x86_64 pychess-0.10-0.3.20100214svn.fc12.noarch
Bingo! "... the cairo_reset_clip() call ..." http://library.gnome.org/devel/gtk/stable/gtk-migrating-ClientSideWindows.html (gdb) br cairo_reset_clip Breakpoint 1 at 0x3b4360e640: file cairo.c, line 2480. (gdb) c Continuing. [Thread 0x7fffdb4c7710 (LWP 19600) exited] Breakpoint 1, cairo_reset_clip (cr=0x1be0590) at cairo.c:2480 2480 { (gdb)
Steve: what's the rest of the backtrace: what's causing cairo_reset_clip to be called?
Created attachment 395291 [details] gdb backtrace at cairo_reset_clip (In reply to comment #31) > Steve: what's the rest of the backtrace: what's causing cairo_reset_clip to be > called? Sorry, I forgot to say that pychess uses cairo extensively -- so I didn't investigate further. This attachment has the backtrace for the first two calls. cairo_reset_clip is not explicitly called by pychess: [stephent@walnut pychess]$ pwd /usr/lib/python2.6/site-packages/pychess [stephent@walnut pychess]$ grep -r clip * /usr/bin/pychess Binary file widgets/ChessClock.pyc matches widgets/ChessClock.py: context.clip() widgets/BoardView.py: #context.clip() Binary file widgets/ChessClock.pyo matches [stephent@walnut pychess]$ Being a gdb noob, I'll have to figure out how to get a summary of all calls. The article on "Migrating to client-side windows" raises enough issues that the upstream devs. will need to comment. They are tracking this problem here: Issue 524: pychess hangs when moving panel dividers http://code.google.com/p/pychess/issues/detail?id=524
Here's the source for gdk_window_set_cairo_clip: http://git.gnome.org/browse/gtk+/tree/gdk/gdkwindow.c?h=client-side-windows#n4416
(In reply to comment #33) > Here's the source for gdk_window_set_cairo_clip: > http://git.gnome.org/browse/gtk+/tree/gdk/gdkwindow.c?h=client-side-windows#n4416 Uh oh ... the live code is different. Using gdb's "next" ... cairo_reset_clip is called outside cairo_save/cairo_restore. Program received signal SIGINT, Interrupt. 0x0000003180ed51e3 in __poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 87 int result = INLINE_SYSCALL (poll, 3, CHECK_N (fds, nfds), nfds, timeout); Breakpoint 1 at 0x3b43e46f20: file gdkwindow.c, line 4923. Continuing. Breakpoint 1, gdk_window_set_cairo_clip (drawable=0x1cd9280, cr=0x1d4ac00) at gdkwindow.c:4923 4923 { 4926 if (!private->paint_stack) 4923 { 4926 if (!private->paint_stack) 4941 GdkWindowPaint *paint = private->paint_stack->data; 4945 cairo_reset_clip (cr); 4946 if (paint->uses_implicit) 4948 cairo_save (cr); 4949 cairo_identity_matrix (cr); 4951 cairo_new_path (cr); 4952 gdk_cairo_region (cr, paint->region); 4953 cairo_restore (cr); 4955 cairo_clip (cr); 4958 } Continuing.
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
I cannot reproduce this with the latest update on F-14 (which is also being built for F-13); Steve, do you have an F-13/F-14 machine you can try these on? https://admin.fedoraproject.org/updates/pychess-0.10-0.8.rc1.fc13 https://admin.fedoraproject.org/updates/pychess-0.10-0.8.rc1.fc14 If a similar problem still happens, please retarget the bug to the Fedora release you're testing on; if not, this bug will close automatically next month.
(In reply to comment #36) > I cannot reproduce this with the latest update on F-14 (which is also being > built for F-13); Steve, do you have an F-13/F-14 machine you can try these on? > > https://admin.fedoraproject.org/updates/pychess-0.10-0.8.rc1.fc13 > https://admin.fedoraproject.org/updates/pychess-0.10-0.8.rc1.fc14 > > If a similar problem still happens, please retarget the bug to the Fedora > release you're testing on; if not, this bug will close automatically next > month. Letting this one expire is fine with me. Have done some testing with F13 and have not seen this. Will open a new bug if needed. pychess-0.10-0.8.rc1.fc13.noarch Has the issue raised by Dave Malcolm (Comment 28) been addressed? Thanks.
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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. Thank you for reporting this bug and we are sorry it could not be fixed.