Your message dated Wed, 6 Sep 2023 14:40:24 +0200
with message-id <[email protected]>
and subject line Re: eboard: does not start gnuchess as white from arbitrary
board setup
has caused the Debian Bug report #444576,
regarding eboard: does not start gnuchess as white from arbitrary board setup
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
444576: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444576
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: eboard
Version: 1.0.3-1
Severity: normal
Steps to reproduce:
1. Play as black against gnuchess as white and bookmark the settings
2. Take a board with pieces in starting position and edit it. It does not
matter if you move the pieces legally or not, the bug
will show up anyway. It will also show up whether or not you swap the side of
the pieces.
3. After a few moves, click the button to play against a engine from that
position and choose the bookmarked settings
4. eboard will always make human play as white, regardless of the fact that the
settings said "gnuchess white, human black" and, if
it was up to the black (human) to move, the human (now white) will not be able
to move any piece despite to the fact that ebord
is waiting for him to move (clearly, because eboard is wrong and it should wait
for gnuchess move, not human's).
I suspect the same happens in other conditions, such as using other engines,
but I haven't tried that.
Moreover I'd like to file a wishlist, but the resolution of this bug may end up
adding that feature also: I'd like to play against
gnuchess or other engine starting from any arbitrary board setup, which is a
lot of fun for me because it's very interesting to see
the way gnuchess escapes a difficult situation or the way it looses starting
from a favorable position (let alone the fun of
fragging its pieces by putting 8 queens around!)
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (1001, 'stable'), (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22.7-athlon800
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Versions of packages eboard depends on:
ii libatk1.0-0 1.18.0-2 The ATK accessibility toolkit
ii libc6 2.6.1-1 GNU C Library: Shared libraries
ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra
ii libfontconfig1 2.4.2-1.2 generic font configuration library
ii libgcc1 1:4.1.1-21 GCC support library
ii libglib2.0-0 2.12.13-1 The GLib library of C routines
ii libgtk2.0-0 2.10.13-1 The GTK+ graphical user interface
ii libpango1.0-0 1.16.5-1 Layout and rendering of internatio
ii libpng12-0 1.2.15~beta5-1 PNG library - runtime
ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3
ii libx11-6 2:1.0.3-7 X11 client-side library
ii libxcursor1 1.1.7-4 X cursor management library
ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar
ii libxfixes3 1:4.0.1-5 X11 miscellaneous 'fixes' extensio
ii libxi6 1:1.0.1-4 X11 Input extension library
ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library
ii libxrandr2 2:1.2.1-1 X11 RandR extension library
ii libxrender1 1:0.9.1-3 X Rendering Extension client libra
Versions of packages eboard recommends:
ii sox 12.17.9-1 A universal sound sample translato
ii xfonts-75dpi 1:1.0.0-3 75 dpi fonts for X
-- no debconf information
--- End Message ---
--- Begin Message ---
The package is gone from sid.
--- End Message ---
