Chess Software for openSUSE

Get it here:

Index of /repositories/home:/Akoellh:/Chess

This repository contains several strong chess engines like

  • glaurung 2.2 (UCI engine)

  • stockfish 1.4 (UCI engine, based on glaurung 2.1)

  • crafty 23.0 (nuff said)

  • togaII 1.3.1 (UCI engine, based on fruit 2.1)

  • togaII 1.4.1 (UCI engine, with multithreading support)

Those engines rate at best with ELO between 2700 and 2800 on recent (and strong) hardware (or even higher, up to 3000 with strong multicore machines), some of them are among the top 20 rated chess engines.

CCRL 40/40 - Index

CCRL 40/4 - Index

CCRL 40/4 FRC - Index

Also included:

  • polyglot (recent version, at the time of writing 1.4.38b) - UCI adapter to use the above engines with

  • xboard (4.4.0.beta1)

All engine packages contain scripts to directly start them with xboard (xcrafty, xglaurung22, xtogaII-131 … I think you get the idea).

Other applications:

  • scid

A nice chess database application, can also load UCI engines (and non-UCI engines like crafty), allows you also to play matches against chess engines or “training” matches.

More perhaps still to come, what certainly won’t be packaged are:

  • commercial (non-free as in source available) chess engines like “fruit”, “Spike” etc.

  • all stuff not available for linux (if you want to mess around with wine, feel free to do so, but setup the stuff yourself)

  • standard engines already available (gnuchess, phalanx) or a lot weaker (gnuchess, phalanx :-))

  • knights

Looks nice, especially on KDE, but is no longer developed and -sorry- total, utter crap when trying to use UCI engines (i.e. regular crashes, works with “engine is black” but not with “engine is white”, because knights is not able telling the electronic, chess playing b.a.s.t.a.r.d to make the first MOVE!)

  • other stuff which is no longer maintained

  • stuff which is not related to serious chess (= at least advanced amateur and/or club players)

What might be packaged in the future:

  • regular updates if available (of course)

  • other Suggestions welcome, but I will not promise to package it, even if it matches all the necessary criteria (= does not match one of the “hell no”-criteria above).

Some new stuff has been packaged, more engines and also some other goodies.

A) Utilities

  1. polyglot (version 1.4.39b)

A UCI adapter, you will need this, if you want to use UCI engines with xboard (or eboard) as frontend (polyglot can also be used as a CLI-interface to UCI-engines).

  1. libegbb3 (version 3.3)

A library to enable endgame table bases (“NalimovBases”) in bitboard format, which then can be used with several engines.

All engines (except crafty, who has his own table bases) have been patched to use /usr/share/egbb/ as default path.

  • Download table bases in bitboard format from one of the well known chess sites

  • Copy them (as root) to /usr/share/egbb

  • set symbolic links (as root)

ln -s /usr/lib/ /usr/share/egbb/ # i586

ln -s /usr/lib64/ /usr/share/egbb/ # x86_64

ln -s /usr/lib64/ /usr/share/egbb/ # x86_64 for "scorpio"

and enjoy.

B) Engines

  1. crafty (Version 23.0)

The xboard-package in this repository uses crafty as standard engine.

  1. fruit (UCI engine, version 2.1)

Version 2.1 was the last version under GPL, so don’t expect updates here.

  1. glaurung (UCI engine)
  • version 1.2.1
  • version 2.2

The new stable version of glaurung, one of the strongest open source engines around.

  1. scorpio (version 2.2)

A winboard/xboard compatible engine, first test matches showed very impressive performance, especially in short (1 minute/game) blitz games.

  1. stockfish (UCI engine, version 1.4)

Based on glaurung 2.1, impressive playing performance, especially in sharp positions.

  1. toga II (UCI engine)

Based on fruit 2.1 and open source, a very strong engine.

  • version 1.3.1

The last version with “official” unix support (meaning it had a POSIX-compatible Makefile and compiled “OOTB”), no eggb-support.

  • version 1.3.4

Modified with patches and Makefile adapted from version 1.4.1 to compile under linux, first version with eggb-support, latest “stable” version.

  • version 1.4.1

Modified with patches for POSIX-support, see Posix ports of some recent version of Toga II for more information.

All engines are packaged with precompiled (and strong!) opening books.

**C) GUI Frontends **

  1. xboard (version 4.4.0.beta2)

The most well known chess GUI for *NIX-type OSes. All engines above contain simple startup scripts to launch them with xboard (i.e. xcrafty, xglaurung121, xscorpio22 …).

  1. eboard (version 1.1.1)

Nice GUI written in GTK+ 2, works only with winboard compatible engines natively, if you want to use an UCI engine with eboard, you need polyglot as UCI adapter.

  1. scid

A great database application, highly configurable with a lot of features, it also loads UCI engines directly (so no polyglot needed here).

  • version 3.7.3 (the latest stable version)

  • version 4.0 beta (named “scid-beta” and versioned 3.9.9_CVSsomething in the repo)

Version 4 of scid uses a new database format, old databases can be converted quite easily, however, as this is a development release => BACKUP YOUR OLD DATABASES!

Wow !

Thats great. I have to try some of that software that you have packaged.

I’ve been maintaining the openSUSE chess wiki (since no one else had done it for a while) but you are welcome to update that wiki.
Games/Chess - openSUSE

I’ll also try to keep it up to date

Give it a shot.

A few other engines are still “in queue”, compiling ist the easiest part (in most cases) but packaging it that they work correctly with startup scripts and use the default paths for everything external (i.e. endgame table bases) and connect nicely to xboard is a PITA sometimes.

The UCI engines are normally the most uncooperative when it comes to xboard, but if you get one of them to run the rest is (was) easy, because it works always in the same way.

Now there are some other engines with their own way of handling config files, paths, …

So I have to find a unique solution for each one, which is the real PITA.

Speaking about P(s)ITA(ses), to me writing/changing/maintaining wiki articles is the greater one than packaging stuff with strange behaviour, so sorry, but I’d rather stay with packaging stuff up.

OK, … if you do the packaging, and I’ll do the wiki updates. If you put any write-ups you want here in this thread, and I’ll transcribe / move the information to the wiki as best I can.

I have some ideas now on how to clean up the chess wiki (and also add your information from the 1st two posts in this thread), and I’ll start on the wiki update this weekend (possibly sooner).

Well, as I also used the wiki as a starting point for searching apps and their sources, a few things I found:

  1. GambitFruit

not provided with openSUSE, but there is Linux source code and Windows compiled versions on web.

=> No more linux binaries available

  1. Arasan

not provided with openSUSE, but there is Linux source code and Windows compiled versions on web

True, but a very strange license, see also FAQ:

" I want to distribute Arasan on a CDROM or in a magazine or though download.

If you distribute it unmodified and are not charging for the software itself, just incidentally for the magazine or a small charge for the CDROM, I’m ok with this. "

Sounds “free” at first glance, but both restrictions render it “unpackageable” for openSUSE (if you take “unmodified” really strict, I could not even patch it to compile and work correctly in linux, which I had to do for nearly every engine).

  1. sjeng

not provided with openSUSE, but there is Linux source code on the web.

True, but only very old versions (11.7 over 5 years old and the last version being surely under GPL). I also found source code of a 12.9 version, but that tarball was quite odd.

The file “COPYRIGHT” normally containing a copy of the License (in older versions that was a copy of the GPL v2) was empty although the file “README” contained a statement, that the source was released under GPL. I don’t really know what to do with that one.

  1. Jose

Jose is a chess database that allows one to view/add games to the database, analyse games with a selected chess engine, and play against the chess engine. A number of different opening books are easily downloadable. It does not come with openSUSE, but because it is java based (requires java-1.4) it runs readily on openSUSE.

Yes and no.

Yes, it runs great under i586 and you would expect it to run also great under x86_64 because it is a java application, … but:

It uses shared libraries inside its own installation directory and these are only available as 32 bit version, so guess what happens under 64 bit if you want to use one of the functions requiring that librarie(s).

(I give you a hint … it starts with “c”, ends with “ash” and has an “r” somewhere in between.)

And those shared libraries are used for database access, so guess how often that happens in a database application. :slight_smile:

Development on jose looks also “dead”, but to be more clear, it “looked dead”, because maybe

jumcclure’s jose-chess at master - GitHub

somebody will pick it up (and make it hopefully also available for x86_64).

  1. chessdb

ChessDB is a free chess database which can be used on Microsoft Windows, Linux, Apple Macs running OS X, FreeBSD, and most modern UNIX versions. The program has translations into many languages. It does not come with openSUSE and must be custom compiled, where its compilation is not straight forward.

Well, I didn’t try that, but not because of the possible problems compiling and packaging it (that would rather have been a good reason to grab the stuff) but due to this:

ChessDB - a free Chess Database

Looks like scid at first glance, but OK, maybe it’s a fork, so

Relationship between ChessDB and Scid

ah, yes, sounds great at first glance but most of those improvements are now in scid and that one is still actively maintained, chessdb looks also “dead” (last commit over 2 years ago).

  1. Pgn-Extract

Pgn-Extract is a freeware utility program (for DOS/Unix/Linux) that extracts and manipulates games from PGN-files. You can use many criteria and search/extract doubles, positions, players, move sequence, ECO-codes etc. This program is not provided with openSUSE.

=> Last update 2003 and no linux binary on that page?

Thanks for the update. … Lots of clean up to do on that wiki :slight_smile: I have not really dug into this for a while, but rather have been doing minor maintenance. Your look at this is the first good major look that has been done in some time.

reference: Gambit Fruit

I recall liking that program.

It does look like it is gone. … I went looking again, and I found this:
… but I think that is the simple “Fruit” engine and not “Gambit Fruit”.

When I checked one of the “download” pages, it was no longer there for Linux (only Windows):
Gambit fruit

I also looked on this chess engine download page:
Chess Downloads
and could not find it.

I found a binary here:
Index of FTP Directory for PGN-Extract
I’ll update the wiki

Edit: I’m not convinced that URL will work … if not, one can go here:

I added some minor edits to the chess wiki Games/Chess - openSUSE … but the big cleanup incorporating the first couple of posts from this thread still needs to be done.

When looking at your repos for 11.1, I note


i.e. one is update, and one is not. What is the difference? I note for the alsa sound driver repos, typically the “openSUSE_11.1_Update” corresponds to the latest kernel ( while the “openSUSE_11.1” corresponds to the stock kernel. What is the criteria you follow for the nominal vs the update? Is it also the kernel version?

It’s absolutely the same set of criteria, the “Update” repository contains packages which are compiled against the recent state of dependencies and get automatically rebuilt if there was a regular update of a dependency.

As there are no “chess specific kernel modules” in my repo, the difference is not as obvious as with other repos containing lots of kernel module packages.

All UCI engines got a workover in their startup routines.

This should make things a lot easier if you want to run your own, customized configuration and (hopefully) not break anything that worked before.

The changes are quite simple.


  • executable was called $NAME_OF_ENGINE installed in /usr/bin

  • opening books and configs were installed to /usr/share/$NAME_OF_ENGINE

  • the xboard-script did this on startup:

exec xboard $OPT -fd /usr/share/$NAME_OF_ENGINE/ -fcp "polyglot /usr/share/$NAME_OF_ENGINE/$NAME_OF_ENGINE.ini" -sd /usr/share/$NAME_OF_ENGINE/ -scp "polyglot /usr/share/$NAME_OF_ENGINE/$NAME_OF_ENGINE.ini" "$@" &


  • executable is called $NAME_OF_ENGINE.bin installed in /usr/bin

  • every engine has a startup script $NAME_OF_ENGINE being installed to /usr/bin which looks like this:

# This is a $NAME_OF_ENGINE startup file, it will create all neccessary settings
# in $HOME/.$NAME_OF_ENGINE like copying the opening book, the ini-file for polyglot and setting the correct paths.
# This script was adapted from a script originally written by Oliver Korff <ok(at)>

if  ! -d $HOME/.$NAME_OF_ENGINE ] ; then
                mkdir -p $HOME/.$NAME_OF_ENGINE ;

if  ! -e $HOME/.$NAME_OF_ENGINE/$NAME_OF_ENGINE.ini ] ; then
                cp /usr/share/$NAME_OF_ENGINE/$NAME_OF_ENGINE.ini $HOME/.$NAME_OF_ENGINE/
                sed -i "s|/usr/share/$NAME_OF_ENGINE|$HOME/.$NAME_OF_ENGINE|g" $HOME/.$NAME_OF_ENGINE/$NAME_OF_ENGINE.ini
                sed -i "s|/tmp|$HOME/.$NAME_OF_ENGINE|g" $HOME/.$NAME_OF_ENGINE/$NAME_OF_ENGINE.ini ;

                cp /usr/share/$NAME_OF_ENGINE/$NAME_OF_BOOKFILE $HOME/.$NAME_OF_ENGINE/ ;


exit 0

On first startup, this script copies all the necessary data to $HOME/.$NAME_OF_ENGINE, eliminating possible problems with non-writable files and/or enabling the possibility of unique setups for every user on the installation.

  • furthermore, the x$NAME_OF_ENGINE script was also modified accordingly to use the files in $HOME (and double check for those files to be absolutely sure nothing gets lost)

Thanks …

I started looking at this, hoping that I could play the engines, before I undertook the task of updating the wiki. … I note after having installed xboard, and having installed your packaged polyglot and glaurung22, to play glaurung22 using polyglot the following command works:

xboard -size medium -fd '/usr/share/glaurung22' -fcp 'polyglot glaurung22.ini'

Thanks for putting the glaurung22.ini file under /usr/share/glaurung22.

and with crafty also installed, one can play glaurung22 against crafty using xboard as follows:

xboard -size medium -fd '/usr/share/glaurung22' -fcp 'polyglot glaurung22.ini' -scp crafty

… and along those lines, with your packaged stockfish14 installed, one can play stockfish14 with:

xboard -size medium -fd '/usr/share/stockfish14' -fcp 'polyglot stockfish14.ini'

and have stockfish14 play crafty with:

xboard -size medium -fd '/usr/share/stockfish14' -fcp 'polyglot stockfish14.ini' -scp crafty

Well, to be precise all ini-files for UCI-engines are located in /usr/share/<engine> and they are also named <engine>.ini.

With the new startup scripts

xboard -fd ~/.glaurung22 -fcp "polyglot glaurung22.ini" -size *whateveryouwant*

should do the trick now (with the possibility of creating your own, custom configuration by modifying “~/.glaurung22/glaurung22.ini”).


The easiest way to start xboard with glaurung22 would be:


If you don’t like the board size, then copy /usr/bin/xglaurung22 to ~/bin/xglaurung22 and make the desired changes.

This of course works with all engines packaged in my repo, to call xboard with <engine>, simply type x<engine> (xcrafty, xglaurung121, xfruit21 …).

The only disadvantage of the “x<engine>”-scripts; they will start the same engine for “fcp” and “scp”, so if you want to have two different engines playing against each other, you will have to call xboard from CLI with the respective “-fd”, “-fcp”, “-sd” and “scp”-commands (which is, what one had to do before also).

I am thinking about writing a shell script which might make things easier, but I am not really good at this.

The perfect solution would be a little GUI (and with GUI I mean “ncurses” with dialouges would be more than only “good enough”) where you get asked which engines you want to have, perhaps with a little menu to choose from.

For somebody with more than only my basic knowledge, this should be rather easy to implement, but for me this is a (too?) big task to do.

Perhaps something like this already exists, but I haven’t found it yet, although it would be very convenient, because -to be honest- functionality of xboard is excellent but in some cases “usability” is a nightmare, i.e. on loading/saving games as pgn, where you don’t get a menu to click yourself to your desired destination but have to type the path yourself.

It would of course be even better if this “choose engine 1, now choose engine 2” could be implemented directly into xboard, but I don’t think that will happen very soon, although xboard 4.4.0.beta has some really nice new features (give it a try, you will like it and it’s also quite stable, I had no issues with it).

Thanks for the recommendation.

I did a preliminary update of the openSUSE chess wiki Games/Chess - openSUSE , incorporating references to your repository, but there is more work still to be done. For the moment, I ran out of energy.

Please feel free to edit the wiki. I noted at the start the repos was the Akoellh repository, but from then on called it the openSUSE chess program repository. If you prefer to call it the Akeollh repos through out, I have no problems with that.

I’m thinking maybe a second wiki page, where I can add some of the explanations you gave in this thread, so that information does not get lost.

I also need to sort out the chess endgame database you have in your repository (both install on my PC, test on my PC, and update the wiki),

… but I think that may need to wait for another day before I get around to it … and when my “batteries” are sufficiently charged. Right now I am rather ‘drained’. :slight_smile: Wiki editing does that to me. (ie drains “my batteries” ).

Many thanks for packaging these many 1st class chess programs (and for packaging the polyglot interface which provides the “glue” making it possible for some of these programs to run).

Looks good.

I made a few changes though, in short:

a) The reference to the kernel version is a bit misleading, there are no dependencies of any package to the kernel version in the chess repo (I like that name, it’s about what you get and not who packaged that stuff up, so that’s fine with me).

It now reads:

openSUSE users should add not that URL to their Software Package manager, but rather add the repository that is applicable to their openSUSE version. For example, openSUSE-11.1 users with the latest Novell/SuSE-GmbH online updates installed would add the repository Index of /repositories/home:/Akoellh:/Chess/openSUSE_11.1_Update More specifically, for the openSUSE-11.1 users with a fully updated system (via YaST => Software => Online Upddates), this can be done by the command:
zypper ar Index of /repositories/home:/Akoellh:/Chess/openSUSE_11.1_Update chess

For example, openSUSE-11.1 users with the fresh install not yet being updated via YaST => Software => Online Updates instead add the repository:
zypper ar Index of /repositories/home:/Akoellh:/Chess/openSUSE_11.1 chess

openSUSE-10.3 and 11.0 users would need to add the repositories applicable to their openSUSE version.

In any case, we recommend to update your system first, not because of the programs in the chess repository but because of the security and bug fixes which are available via YaST Online Updates.

The last sentence is -at least to me- a very important one, updating your system first and then thinking about some fun with chess programs should be the thing every user should do.

To be honest, my first idea was to offer packages via only “Update”-repos and not for the stock versions, but that would be confusing no matter how I would call the repos:

  • if I called them $openSUSE_Version-Update, some users might think they are incompatible with $SUSE_Version because of the “Update” in its name. (… and then even start messing up their system by adding “factory”-repos. This sounds ridiculous at first, but never underestimate the strange ideas some [newbie-]users get.)

  • if I call them $openSUSE-Version and package only against the latest dependecies it might (although very unlikely) break some packages which would run with a fully patched system (and result in threads/PMs/mails "$thingy not working … Your stuff CRAP!111ONEONEONE!!)

b) Changed the entry for scorpio:

Scorpio needs the front end xboard installed to run (see above Front End section in this wiki). With xboard installed, the openSUSE chess program repository version of Scorpio can be run with the command:

or alternatively with xboard run with the more traditional method:
xboard -size medium -fcp scorpio22

I removed the reference to polyglot as scorpio is not an UCI engine, so it doesn’t need polyglot (I think it wouldn’t even work with polyglot).

c) Added hyperlinks for stockfish ( - this is the git-repository) and changed a little typo:


Glaurung is a chess program based on glaurung 2.1 …



Stockfish is a chess program based on glaurung 2.1

Thanks for the quality control/corrections.

I also added a section on the end, with some xboard usage hints. Games/Chess - openSUSE

Now back to recharging (my batteries) before I tackle some of the more challenging parts of documenting this thread.

Another “goodie” got just packaged up:

DeepLearningToga (UCI engine, version 1.5.21a)

This version of TogaII is derived from 1.4.1 and aimed at multi processor machines and has a learning mode implemented.

By default the number of cpu’s is detected automatically, so you can also use this on a single core machine.

The ini-file for polyglot is set to 2 cores by default, which is safe as it will be ignored if you are running DeepLearningToga via polyglot (i.e. with xboard) on a single core machine.

If you have a machine with more than two cores and want to use all of them, just set this

Threads = 2

to the amount of cores you have.

In scid use “Configure UCI engine” option when configuring the engine (Tools => Analysis Engine => New/Edit) and set
“Number of Threads” accordingly.

Learning mode is disabled by default in the ini-File for polyglot:

Use Learn = false
Generate Learn = true
Information File = toga_info.finf

If “Use Learn” is set to “true”, learning will be enabled.
Beware, that this will create a growing file “/home/Your_Username/.DeepLearningToga-1.5.21a/toga_info.finf”, check the size of that file regularly!

The startup scripts “xDeepLearningToga-1.5.21a” and “DeepLearningToga-1.5.21a” will create the file “toga_info.finf” in $HOME/.DeepLearningToga-1.5.21a/ automatically.

For scid set the appropriate parameters with the “Configure UCI engine” option when configuring the engine (Tools => Analysis Engine => New/Edit) and use absolute paths (/home/Your_Username/.DeepLearningToga-1.5.21a/)

It is recommended to use the same path as for xboard/polyglot to combine the learning results.

See “/usr/share/doc/packages/DeepLearningToga-1.5.21a/readme.txt” for more details.