dev-games/clanlib-0.8.0 and games-sports/trophy-1.1.5 have been long enough in the tree, have no open bugs and work. games-arcade/methane-1.4.8 may be a candidate too but I haven't tested it yet. @games, can we stabilize them?
yep
On amd64 I'm getting a segfault in trophy after quitting the game. Backtrace: (gdb) bt #0 0x00002afd8b1c0bd7 in CL_Thread::wait () from /usr/lib/libclanCore-0.8.so.1 #1 0x00002afd8ac92090 in CL_SoundOutput_Generic::stop_mixer_thread () from /usr/lib/libclanSound-0.8.so.1 #2 0x00002afd8ac947a4 in CL_SoundOutput_OSS::~CL_SoundOutput_OSS () from /usr/lib/libclanSound-0.8.so.1 #3 0x0000000000417845 in CATrophy::main (this=0x62b920, argc=<value optimized out>, argv=0x7fff202b2318) at catrophy.cpp:198 #4 0x00002afd8b5e2ee6 in main () from /usr/lib/libclanApp-0.8.so.1 #5 0x00002afd8bf96b74 in __libc_start_main () from /lib/libc.so.6 #6 0x0000000000405049 in _start () I'm attaching the core dump. # emerge --info Portage 2.1.4.4 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24.3 x86_64) ================================================================= System uname: 2.6.24.3 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ Timestamp of tree: Sun, 23 Mar 2008 13:46:01 +0000 app-shells/bash: 3.2_p17-r1 dev-lang/python: 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=athlon64 -m3dnow -mmmx -msse -msse2 -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -pipe -march=athlon64 -m3dnow -mmmx -msse -msse2 -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="ccache collision-protect distlocks metadata-transfer multilib-strict parallel-fetch sandbox sfperms strict test unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://mirrors.blueyonder.co.uk/mirrors/gentoo " LINGUAS="es_ES es en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow 3dnowext acl amd64 berkdb cli cracklib crypt cups dri fortran gdbm gpm iconv ipv6 isdnlog midi mmx mmxext mudflap ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection session spl sse sse2 sse3 ssl tcpd unicode userlocales xorg zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="es_ES es en" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Too big for an attachment, uploaded it here: http://www.yourfilehost.com/media.php?cat=other&file=trophy_core.tar.bz2
Exception caught: Could not open X11 display! Program received signal SIGSEGV, Segmentation fault. 0x00002b2a987bbf38 in CL_DisplayWindow::hide_cursor () ---Type <return> to continue, or q <return> to quit--- from /usr/lib/libclanDisplay-0.8.so.1 (gdb) bt #0 0x00002b2a987bbf38 in CL_DisplayWindow::hide_cursor () from /usr/lib/libclanDisplay-0.8.so.1 #1 0x000000000041451c in CATrophy::reconfigure () #2 0x0000000000416904 in CATrophy::main () #3 0x00002b2a98ebff56 in main () from /usr/lib/libclanApp-0.8.so.1 #4 0x00002b2a99872b74 in __libc_start_main () from /lib/libc.so.6 #5 0x0000000000405309 in _start () and this when DISPLAY is not correctly set up. I'll test with clanlib-0.8.1, and maybe Debian patches, let's see.
trophy will fail when clanlib is built without USE=opengl, please add built_with_use check
No, we'll pick that up later with use-based deps.
Trophy works fine for me on amd64: [ebuild R ] games-sports/trophy-1.1.5 0 kB [ebuild R ] dev-games/clanlib-0.8.0 USE="mikmod opengl sdl vorbis -doc -ipv6" I have "opengl" enabled
(In reply to comment #2) > On amd64 I'm getting a segfault in trophy after quitting the game. Same for me on x86
Segfault goes away here with clanlib 0.8.1. Santiago and Paul please test again.
The segfault Santiago reported still happens. Mine doesn't Exception caught: Could not open X11 display! Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2b8c4f650300 (LWP 13888)] 0x00002b8c4c357450 in CL_DisplayWindow::hide_cursor () from /usr/lib/libclanDisplay-0.8.so.1
(In reply to comment #10) > The segfault Santiago reported still happens. Mine doesn't How can one reproduce it?
Unset DISPLAY, try running the game. Also works if the user running the game doesn't have permission to access the display.
Is that enough to stop it going stable? It wouldn't work anyway in those conditions.
(In reply to comment #13) > Is that enough to stop it going stable? It wouldn't work anyway in those > conditions. > Wouldn't that depend on whose fault it is? If it's trophy not correctly doing it's checks, it shouldn't be too important but if it's clanlib's fault not correctly notifying of errors, it shouldn't be considered stable, right? Just asking
(In reply to comment #13) > Is that enough to stop it going stable? It wouldn't work anyway in those > conditions. Depends on how likely it is that a user will hit it. At the moment I am reluctant to mark it stable as it is first version of the 0.8 series to hit arch.
After thinking it through again, I mark it stable now on x86...prematurely to get it out of the way
nothing more to do here.
