Summary: | new ebuild for games-fps/wolf4sdl | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jared B. <nitro> |
Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | yamadharma |
Priority: | High | Keywords: | EBUILD |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.stud.uni-karlsruhe.de/~uvaue/chaos/ | ||
Whiteboard: | sunrise-suggested | ||
Package list: | Runtime testing required: | --- | |
Attachments: |
games-fps/wolf4sdl-1.6.ebuild
mouse smoothing patch strafing patch window mouse patch desktop icon games-fps/wolf4sdl-1.6.ebuild games-fps/wolf4sdl-1.6.ebuild per-user configuration directory patch window mouse patch strafing patch Alternative configname patch, with error checking games-fps/wolf4sdl-1.6.ebuild per-user configuration directory patch (and GCC fix) window mouse patch strafing patch desktop icon (wolf3d) desktop icon (spear) linux multi-user support and GCC fix linux multi-user support and GCC (4.5) fix |
Description
Jared B.
2010-07-05 09:27:09 UTC
Created attachment 237553 [details]
games-fps/wolf4sdl-1.6.ebuild
Created attachment 237555 [details, diff]
mouse smoothing patch
Created attachment 237557 [details]
strafing patch
Created attachment 237559 [details]
window mouse patch
Created attachment 237561 [details]
desktop icon
Please do not use patch directly (rather use epatch from eutils.eclass); also try not to overuse sed to apply changes. Changes also should happen in src_prepare not src_configure. Finally, hardcoding /tmp is a bad idea. 1. Oops, forgot about epatch. Will get that fixed. 2. I'm not trying to overuse sed, but I think it makes more sense to use that in the places I've used it than to create separate patch files. Other/better suggestions welcome if this is "bad". 3. Will update. 4. Yes, I know it's bad. As I mentioned, though, it's simply the best I could make work, and I figured it's better than not being able to save preferences at all (unless you're playing as root, which is also bad). A proper fix is definitely welcome here; it's just beyond my scripting skills. Created attachment 237565 [details]
games-fps/wolf4sdl-1.6.ebuild
Fixed 1 and 3. I looked at the sed usage again and still can't find a better way to handle it. The version.h stuff would require a separate patch file per game version, which seems like overkill. The other fixes, for the GCC and home directory issues, are just one-liners that seem much better to fix with sed than using a patch file. But again, suggestions welcome.
Thanks for the feedback.
Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Thanks, On behalf of the Gentoo Sunrise Team, Markos. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq Alright, I figured out a proper way to handle the config dir issue. With the new version, configuration will be saved to ~/.wolf4sdl/wolf3d.wl6 or ~/.wolf4sdl/spear.wl6, depending on which game you're playing. W00t. I don't have a retail copy of SoD, but I'll see if I can grab the shareware version and write another ebuild for wolf4sdl-spear. All of the patches should equally apply to it, so hopefully it shouldn't take much time. I'm quite ready to be done with this. :-) Created attachment 237819 [details]
games-fps/wolf4sdl-1.6.ebuild
Created attachment 237821 [details, diff]
per-user configuration directory patch
Created attachment 237823 [details, diff]
window mouse patch
Created attachment 237825 [details, diff]
strafing patch
Created attachment 237833 [details, diff] Alternative configname patch, with error checking (In reply to comment #12) > Created an attachment (id=237821) [details] > per-user configuration directory patch I had seen this bug and was drafting an alternate patch when you posted. Looking at your proposal, we followed a similar path. However, your approach lacks error checking. Although uncommon, it is legal for HOME to be unset, in which case getenv will return NULL. If not checked, this will cause a crash when your strcpy reads the returned value. Also, you use strcpy without any check that the value of HOME will fit within the declared buffer. I have attached my proposed change. I opted to mkdir the required directory inside the new subroutine, and so did not create separate variables for configdir and configname. OK, I'm officially ready to call this sucker done. The new ebuild includes support for SoD as well. It can be used like this: USE="wolf3d_apogee -wolf3d_shareware spear_full" emerge ... This will build and install support for both wolf3d and spear, with binaries being named wolf3d and spear accordingly, and data being saved to GAMES_DATA_DIR/wolf4sdl/(wolf3d,spear). Alternatively, USE="-wolf3d_shareware spear_demo" will only build and install support for the SoD demo. Ditto if you only want wolf3d installed. I also rolled the GCC fix into one of the patches and added new icons. I like this approach quite a bit - should make things really easy for users, and avoids the need for split ebuilds like I was originally thinking. (In reply to comment #15) > Created an attachment (id=237833) [details] > Alternative configname patch, with error checking Kevin, thanks so much for this. I just wish the timing was better. :-) I like the idea of extra validation, so I tried swapping out my patch for yours, but unfortunately I had some trouble with yours. It kept aborting with "Your $HOME is too long". I spent a while troubleshooting it and rewrote some of the code to get this part to work, but then it gave me a completely separate error when launching the game, something about "No protocol specified". That shouldn't have anything at all to do with this, but I guess it wasn't happy with the changes I made to your code. So, I reverted back to my own patch and basically incorporated your ideas. The same validation is there, just done in a different manner. The added benefit here is that I understand the syntax and was able to make it work. :-) Thanks, though; I very much appreciate your help, even through I wasn't able to use your patch directly. Created attachment 237849 [details]
games-fps/wolf4sdl-1.6.ebuild
Created attachment 237851 [details, diff]
per-user configuration directory patch (and GCC fix)
Created attachment 237853 [details, diff]
window mouse patch
Created attachment 237855 [details, diff]
strafing patch
Created attachment 237857 [details]
desktop icon (wolf3d)
Created attachment 237859 [details]
desktop icon (spear)
(In reply to comment #16) > (In reply to comment #15) > > Created an attachment (id=237833) [details] [details] > > Alternative configname patch, with error checking > > Kevin, thanks so much for this. I just wish the timing was better. :-) I finished it the day before, but was not able to test it until after you had posted your first iteration. No matter, I am glad that I was able to help. Looking at your final patch, I notice you do not cache the return value of getenv("HOME"). It looks like getenv is not declared as pure/const (see /usr/include/stdlib.h), so each occurrence of getenv in the code will translate to a separate call to getenv at runtime. For a single-threaded program, this is not racy, but it is slightly wasteful, which is why my proposed patch stored the result and then tested/used the pointer initialized from the call to getenv. I neglected to mention that I tried my proposed function in a test program, but did not build a patched wolf4sdl with my proposed change. In the test program it worked fine, and I expected it would work in the normal program as well. I have a problem with your wolf4sdl ebuild, at least on x86. When I try to save a game, I get a segmentation fault. This problem does not show up when I'm building manually wolf4sdl from source (without the ebuild). Thanks for the report. It probably has to do with the new code to save games to your home directory, and now that I think about it, I don't believe I actually tried saving a game. I verified the config files were created and persisted, but didn't think to test saving because I thought they were all the same. Oops. I'll try to fix this tonight. Created attachment 241169 [details]
linux multi-user support and GCC fix
Huh. That was far less painful to fix than I had anticipated... which probably means I did something wrong. ;-) Please give the new linuxfix.patch a try.
I can't say that this is the most elegant solution, but it works (at least for me). Please let me know if you have any trouble.
Great work Jared... saving and loading works just fine now. I found a little other glitch recently, concerning the keyboard layout: I can't manage to type numbers (for copy protection in Spear of Destiny, or a save game). I'm using a laptop with french keyboard, but even with the numeric keypad, I can't insert anything. It's particularly blocking for Spear of Destiny, as I can only answer to questions not requesting numbers. I'm also wondering if, as the game engine is free, we couldn't somehow bypass this protection (through the source code, of course). It's really annoying looking back at the old game documentation each time we start the game :) Huh, that's odd. I don't think keypads will work (it doesn't for me, at least), but the normal number keys should work fine. Maybe your keyboard is uses different codes for the numbers? Seems kind of odd, though, I really don't have an answer for that. To your second point, though, you actually can bypass the copy protection - just use the --goodtimes argument. Well, on french keyboards, the keys associated to numbers on the upper side of the keyboard must be shifted in order to get numbers (otherwise we get accents and other special characters). Maybe that's why it doesn't work for me. But I'm glad you gave me the --goodtimes argument... with that, it becomes a non-blocking issue. Created attachment 288299 [details]
linux multi-user support and GCC (4.5) fix
Updated linuxfix.patch to compile properly with GCC 4.5.
Is there a reason this was never put into portage? I'd suspect the usual: no dev has taken any personal interest in it. Same applies to many, many other ebuilds in bugzilla. Technically, though, it should work fine, at least on stable systems. I haven't tested on unstable. |