Spec Name or Url: http://home.zonnet.nl/jwrdegoede/worminator.spec SRPM Name or Url: http://home.zonnet.nl/jwrdegoede/worminator-3.0R2.1-1.src.rpm Description: You play as The Worminator and fight your way through many levels of madness and mayhem. Worminator features nine unique weapons, visible character damage, full screen scrolling, sound and music, and much more! Notice that you will also need the data files, I've created a seperate specfile for this: http://home.zonnet.nl/jwrdegoede/worminator-data.spec Sorry no SRPM, the data is too large (only 6MB) for my sucky ISP.
MUST ==== * rpmlint output clean (worminator only) * Package named correctly * GPL license OK. Thanks for including the license change discussion in %doc * spec file legible, in Am. English * Source matches upstream (srpm for -data not provided) * Successfully compiles and builds on at least one platform (FC-4 x86_64) * no locale data, shared libraries, or static libraries * No excessive Requires: or BR: * Summary and description ok * macro use consistent * Game content permissible * -data package owns the directory that it creates. * Not relocatable * %doc does not affect runtime * GAMES SIG MUST ============= * application and data packaged separately * Data in %{datadir}/games permitted (see below) * spec file group ok * license file and change discussion included * file ownership ok SHOULD ====== * Builds cleanly in mock for FC-4 i386, FC-4 x86_64, and FC-5 i386 MUSTFIX ======= * Data should be a noarch package. Use: BuildArch: noarch This will also clean up the rpmlint error on the -data package. * desktop file category incorrect. It should be: Category: Application;Game;ArcadeGame; * Segfaults on FC4-x86_64. strace shows that the game hangs after the segfault, leaving a lingering worminator process. * Started up on FC5-i386, but locked up during the tutorial. SHOULDFIX ========= * Data files should be put in /usr/share/worminator, not /usr/share/games/worminator. I realize there is still a discussion on the Games SIG regarding this, so I won't consider it a blocker.
MUSTFIX ======= * Data should be a noarch package. Use: BuildArch: noarch This will also clean up the rpmlint error on the -data package. * desktop file category incorrect. It should be: Category: Application;Game;ArcadeGame; I'll fix these 2 soon (no time tight now) * Segfaults on FC4-x86_64. strace shows that the game hangs after the segfault, leaving a lingering worminator process. Hmm, this could be because of the old (ancient) allegro in FC-4, unfortunatly it can't be upgraded because of .soname changes. Or did you happen to start it through ssh , there is are known allegro problems when doing this. * Started up on FC5-i386, but locked up during the tutorial. Hmm, it works fine here (x86_64), where exactly did it lock up, did you switch to a console and then attach gdb? Can you reproduce this?
(In reply to comment #2) > * Segfaults on FC4-x86_64. strace shows that the game hangs after the segfault, > leaving a lingering worminator process. > Hmm, this could be because of the old (ancient) allegro in FC-4, unfortunatly it > can't be upgraded because of .soname changes. Or did you happen to start it > through ssh , there is are known allegro problems when doing this. I was running it directly on the desktop, not via ssh. > * Started up on FC5-i386, but locked up during the tutorial. > Hmm, it works fine here (x86_64), where exactly did it lock up, did you switch > to a console and then attach gdb? Can you reproduce this? This is definitely reproducible, but it happens at slightly different places during the tutorial. It's always at or shortly after the 'Press Z to duck' screen. gdb shows that it's hung in reset_sound(), and in fact, there is no sound playing for me. I'm running this inside of vmware, and it's possible that vmware is competing with the host system's sound resources. I'll try to bring up FC-5 directly and see if it still happens.
(In reply to comment #3) > (In reply to comment #2) > > * Started up on FC5-i386, but locked up during the tutorial. > > Hmm, it works fine here (x86_64), where exactly did it lock up, did you switch > > to a console and then attach gdb? Can you reproduce this? > > This is definitely reproducible, but it happens at slightly different places > during the tutorial. It's always at or shortly after the 'Press Z to duck' > screen. gdb shows that it's hung in reset_sound(), and in fact, there is no > sound playing for me. Here's the stack while it's hung: #0 0x00501410 in ?? () #1 0xbfc7cc88 in ?? () #2 0x000001f4 in ?? () #3 0x00000001 in ?? () #4 0x00276bec in poll () from /lib/libc.so.6 #5 0x04e1f060 in snd_pcm_direct_check_interleave () from /lib/libasound.so.2 #6 0x04e1f4cf in snd_pcm_direct_server_create () from /lib/libasound.so.2 #7 0x04e17b12 in snd_pcm_dmix_open () from /lib/libasound.so.2 #8 0x04e184c9 in _snd_pcm_dmix_open () from /lib/libasound.so.2 #9 0x04de6b35 in snd_pcm_free () from /lib/libasound.so.2 #10 0x04de71b6 in snd_pcm_free () from /lib/libasound.so.2 #11 0x04de725b in snd_pcm_open_slave () from /lib/libasound.so.2 #12 0x04e01c3c in _snd_pcm_plug_open () from /lib/libasound.so.2 #13 0x04de6b35 in snd_pcm_free () from /lib/libasound.so.2 #14 0x04de7283 in snd_pcm_open_slave () from /lib/libasound.so.2 #15 0x04e1f674 in _snd_pcm_asym_open () from /lib/libasound.so.2 #16 0x04de6b35 in snd_pcm_free () from /lib/libasound.so.2 #17 0x04de71b6 in snd_pcm_free () from /lib/libasound.so.2 #18 0x00b2e34d in ?? () from /usr/lib/allegro//4.2/alleg-alsadigi.so #19 0x005c163e in install_sound () from /usr/lib/liballeg.so.4.2 #20 0x080883ac in reset_sound () at Worminator.c:3136 #21 0x0808b66a in initialize () at Worminator.c:3258 #22 0x080ab25b in main () at Worminator.c:309
MUSTFIX ======= * Data should be a noarch package. Use: BuildArch: noarch This will also clean up the rpmlint error on the -data package. Fixed, new spec file at: http://home.zonnet.nl/jwrdegoede/worminator-data.spec * desktop file category incorrect. It should be: Category: Application;Game;ArcadeGame; Fixed, new srpm at the same url as the previous one (I didn't bump release): http://home.zonnet.nl/jwrdegoede/worminator-3.0R2.1-1.src.rpm * Segfaults on FC4-x86_64. strace shows that the game hangs after the segfault, leaving a lingering worminator process. Hmm, I really believe this is because of the old (ancient) allegro in FC-4, concedering that FC-5 is almost released and since I don't have any FC-4 installs I won't fix this. * Started up on FC5-i386, but locked up during the tutorial. Looking at your strace this seems buried deep in alsalib, thus not a worminator problem, most likely a problem with alsa and vmware, also is your rawhide fully up2date? I've tried to reproduce this as you described, but it works for me. I've extensivly tested this on FC-5 x86_64 and Fc-5 i386 and I've seen no (unfixed) hangs or crashes. I've also had this tested on PPC to make sure me endian dixes where correct and there it worked too. Also the Cru packager has been playing it without any problems. I have to ask you to believe me here that worminator is not an unstable pile of XXXX, but that you just have 2 unlucky configurations.
(In reply to comment #5) > * Segfaults on FC4-x86_64. strace shows that the game hangs after the segfault, > leaving a lingering worminator process. > > Hmm, I really believe this is because of the old (ancient) allegro in FC-4, > concedering that FC-5 is almost released and since I don't have any FC-4 > installs I won't fix this. > > * Started up on FC5-i386, but locked up during the tutorial. > Looking at your strace this seems buried deep in alsalib, thus not a worminator > problem, most likely a problem with alsa and vmware, also is your rawhide fully > up2date? I've tried to reproduce this as you described, but it works for me. > > I've extensivly tested this on FC-5 x86_64 and Fc-5 i386 and I've seen no > (unfixed) hangs or crashes. I've also had this tested on PPC to make sure me > endian dixes where correct and there it worked too. Also the Cru packager has > been playing it without any problems. > > I have to ask you to believe me here that worminator is not an unstable pile of > XXXX, but that you just have 2 unlucky configurations. I finally got a FC5-x86_64 install on my desktop (this time not running in vmware), and it ran without problems. Since the earlier issues have been addressed, and I verified that it runs correctly: APPROVED
Imported, added to owners.list and build requested will close as soon as the build(s) complete.
Build successfully, closing.
I just found out on the allegro-devel mailing list why worminator was crashing for you with FC-4 - i386. You were running FC-4 i386 on an x86_64 and thus had NX protection on, and allegro contains a bug that causes it to fail on i386 with NX (not on x86_64 itself because there it doesn't generate asm as it does on i386). I've this fixed in FE-devel CVS.
(In reply to comment #9) > I just found out on the allegro-devel mailing list why worminator was crashing > for you with FC-4 - i386. You were running FC-4 i386 on an x86_64 and thus had > NX protection on, and allegro contains a bug that causes it to fail on i386 with > NX (not on x86_64 itself because there it doesn't generate asm as it does on i386). Not quite. This was on native FC-4 x86_64. $ rpm -qa allegro* allegro-devel-4.0.3-13.x86_64 allegro-4.0.3-13.x86_64 Here's the stack trace (sorry, there was no useful allegro-debuginfo package): (gdb) run Starting program: /usr/bin/worminator [Thread debugging using libthread_db enabled] [New Thread 46912496357536 (LWP 5533)] [New Thread 1084229984 (LWP 5557)] [New Thread 1094719840 (LWP 5558)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912496357536 (LWP 5533)] 0x0000003ade56a413 in _int_free () from /lib64/libc.so.6 (gdb) thread apply all bt Thread 3 (Thread 1094719840 (LWP 5558)): #0 0x0000003ade5c2682 in __select_nocancel () from /lib64/libc.so.6 #1 0x0000003d04b79bc8 in seqbuf_dump () from /usr/lib64/liballeg.so.4.0 #2 0x0000003adf00697c in start_thread () from /lib64/libpthread.so.0 #3 0x0000003ade5c992e in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 2 (Thread 1084229984 (LWP 5557)): #0 0x0000003ade5c2682 in __select_nocancel () from /lib64/libc.so.6 #1 0x0000003d04b7a5f0 in _read_os_type () from /usr/lib64/liballeg.so.4.0 #2 0x0000003adf00697c in start_thread () from /lib64/libpthread.so.0 #3 0x0000003ade5c992e in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 1 (Thread 46912496357536 (LWP 5533)): #0 0x0000003ade56a413 in _int_free () from /lib64/libc.so.6 #1 0x0000003ade56ac4e in free () from /lib64/libc.so.6 #2 0x0000003d04b78cd2 in _unix_unload_modules () from /usr/lib64/liballeg.so.4.0 #3 0x0000003d04b6c862 in install_sound () from /usr/lib64/liballeg.so.4.0 #4 0x0000000000412b28 in reset_sound () at Worminator.c:3136 #5 0x0000000000412e67 in initialize () at Worminator.c:3258 #6 0x0000000000459abf in _mangled_main (argc=Variable "argc" is not available. ) at Worminator.c:309 #7 0x0000003ade51c3cf in __libc_start_main () from /lib64/libc.so.6 #8 0x0000000000407ef9 in _start () #9 0x00007fffffe2d348 in ?? () #10 0x0000000000000000 in ?? () Of course, this is all academic unless you plan to build worminator on FC-4.
Darn, well the NX stuff still is a real problem. And as said this is all acadamic because I don't plan to release worminator for FC-4 because of the old allegro there.