Spec URL: http://people.atrpms.net/~hdegoede/boswars.spec SRPM URL: http://people.atrpms.net/~hdegoede/boswars-2.4.1-1.fc8.src.rpm Description: Bos Wars is a futuristic real-time strategy game. It is possible to play against human opponents over LAN, internet, or against the computer. Bos Wars aims to create a completly original and fun open source RTS game.
* At least libpng-devel is missing? http://koji.fedoraproject.org/koji/taskinfo?taskID=153491 (Recently, I seldom use normal rpmbuild and I usually use mock or koji...) * For scons, the following maybe useful. http://cvs.fedoraproject.org/viewcvs/*checkout*/rpms/aqsis/devel/aqsis.spec Would you try to use scons on %install?
(In reply to comment #1) > * At least libpng-devel is missing? > http://koji.fedoraproject.org/koji/taskinfo?taskID=153491 > (Recently, I seldom use normal rpmbuild and I usually use > mock or koji...) I guess I should change my habbits and stat using koji scratchbuilds to test BuildRequires, I (almost) never used mock because of my relatively slow internet connection at home. I'll add the missing BR and run it to koji to make sure its ok now and then post a new version. > * For scons, the following maybe useful. > http://cvs.fedoraproject.org/viewcvs/*checkout*/rpms/aqsis/devel/aqsis.spec > Would you try to use scons on %install? The problem with scons is that in order for things like settings CCFLAGS to work the scons file must be written properly, which it often isn't (hence my overriding CC trick in this case), the same goes for install. And fixing scons SConstruct files is a pain as its rather badly documented.
Here is a package with the buildRequires fixed: Spec URL: http://people.atrpms.net/~hdegoede/boswars.spec SRPM URL: http://people.atrpms.net/~hdegoede/boswars-2.4.1-2.fc8.src.rpm And here is the kojibuild of it: http://koji.fedoraproject.org/koji/taskinfo?taskID=153636
Created attachment 191591 [details] gdb log for boswars 2.4.1-2.fc8 on rawhide Almost okay, except for one minor rpmlint and one strange crash * file-not-utf8 /usr/share/doc/boswars-2.4.1/guichan-copyright.txt - Please change the encoding to UTF-8. * SIGABRT - Well, when I launch this by "boswars -d /usr/share/bosward" boswars crashes immediately. gdb log attached. What is strange is that when I am watching at some .flv file by xine (so I am listening to some music), boswards can surely be launched. Would you know why?
(In reply to comment #4) > * SIGABRT > - Well, when I launch this by "boswars -d /usr/share/bosward" s|bosward|boswars| > What is strange is that when I am watching at some .flv file > by xine (so I am listening to some music), boswards can surely > be launched. s|boswards|boswars|
(In reply to comment #4) > Created an attachment (id=191591) [edit] > gdb log for boswars 2.4.1-2.fc8 on rawhide > > Almost okay, except for one minor rpmlint and one strange crash > > * file-not-utf8 /usr/share/doc/boswars-2.4.1/guichan-copyright.txt > - Please change the encoding to UTF-8. > Will fix before import. How did you find this out? rpmlint used to warn about issues like thus, but no longer seems to do this, atleast not for me? > * SIGABRT > - Well, when I launch this by "boswars -d /usr/share/bosward" > boswars crashes immediately. gdb log attached. > > What is strange is that when I am watching at some .flv file > by xine (so I am listening to some music), boswards can surely > be launched. Would you know why? > Judging from the X errorhandler output (and experience) your videocards / drivers Xvideo support cannot handle the requested movie size / format. I remember writing ugly workarounds for this catching the Xerror and reverting to another format, when coding the XVideo support for xmame. Things work when you have xine running because that is already using your XVideo overlay port and thus boswars reverts to software video rendering mode. Depending on how you look at this, this is either an SDL bug (it should catch the error and revert to soft rendering mode, tell them to go dig in the xmame XVideo code for the ugliness of this), or a video driver bug as it shouldn't advertise xvideo capabilities it later turns out it cannot offer. Either way its not boswars fault. Feel free to file a bug against SDL or your video driver (I guess both would be best), and put me in the CC.
(In reply to comment #6) > (In reply to comment #4) > > Created an attachment (id=191591) [edit] [edit] > > gdb log for boswars 2.4.1-2.fc8 on rawhide > > > > Almost okay, except for one minor rpmlint and one strange crash > > > > * file-not-utf8 /usr/share/doc/boswars-2.4.1/guichan-copyright.txt > > - Please change the encoding to UTF-8. > > > > > Will fix before import. How did you find this out? rpmlint used to warn about > issues like thus, but no longer seems to do this, atleast not for me? - For me rpmlint (0.81-1.fc8) surely detected this, for binary rpm and installed rpm. > > > * SIGABRT > > - Well, when I launch this by "boswars -d /usr/share/bosward" > > boswars crashes immediately. gdb log attached. > > > > What is strange is that when I am watching at some .flv file > > by xine (so I am listening to some music), boswards can surely > > be launched. Would you know why? > > > > Judging from the X errorhandler output (and experience) your videocards / > drivers Xvideo support cannot handle the requested movie size / format. I > remember writing ugly workarounds for this catching the Xerror and reverting to > another format, when coding the XVideo support for xmame. Things work when you > have xine running because that is already using your XVideo overlay port and > thus boswars reverts to software video rendering mode. > > Depending on how you look at this, this is either an SDL bug (it should catch > the error and revert to soft rendering mode, tell them to go dig in the xmame > XVideo code for the ugliness of this), or a video driver bug as it shouldn't > advertise xvideo capabilities it later turns out it cannot offer. Well, then I will try to open a report for xorg-x11-drv-i810? Or maybe (from gdb log) against libxcb? Anyway okay for this package. ------------------------------------------------------- This package (boswars) is APPROVED by me -------------------------------------------------------
(In reply to comment #7) > > Depending on how you look at this, this is either an SDL bug (it should catch > > the error and revert to soft rendering mode, tell them to go dig in the xmame > > XVideo code for the ugliness of this), or a video driver bug as it shouldn't > > advertise xvideo capabilities it later turns out it cannot offer. > > Well, then I will try to open a report for xorg-x11-drv-i810? > Or maybe (from gdb log) against libxcb? > You could try to file a bug against the i810-driver but I'm not sure this can be fixed there, it might just not know that things will fail until the first frame gets pushed (thats what happened in xmame). So then a workaround (catching the error, falling back to sw rendering) needs to be added to SDL. libxcb is not involved here (atleast not in a bad way). > Anyway okay for this package. > ------------------------------------------------------- > This package (boswars) is APPROVED by me > ------------------------------------------------------- > > New Package CVS Request ======================= Package Name: boswars Short Description: Bos Wars is a futuristic real-time strategy game Owners: jwrdegoede Branches: F-7 devel InitialCC: <empty> Cvsextras Commits: Yes
Note: I just reproduced the video related crash on my work PC. As I've worked around this in xmame in the past I'll try to write a workaround for SDL too. Having this crash is quite bad considering the popularity of i810 video.
cvs done.
Thanks all, imported and build, closing.
Note, I've submitted a patch for SDL which fixes the crash on intel video, see bug 310841. I would be much obliged if you could build a local version of SDL with the patch, confirm that it fixes this and add a favorable comment to bug 310841. The SDL maintainer is usually not all that willing to take patches :(