From The Linux Game Tome: "A clone of Sega's Chu Chu Rocket Mures is a cross-platform clone of Sega's "Chu Chu Rocket," a multi-player puzzle game. Players place arrows on a board in an attempt to guide the mice into their rockets and away from opponents' rockets. A great party game." There is still a big issue with this ebuild, but there was nothing more I could do so I'll just post it here in hope that someone will fix it. The problem lies with the flags passed on to the compiler. The program can be built with or without OpenGL support. If you want OpenGL support built in, you have to add -DHAVE_GL and -lGL to the CFLAGS, and if you don't want it then you don't have to add these flags. So far so good. The problem arrises from the fact that, if you have OpenGL installed, the configure script autodetects this and passes these flags to the compiler. However, there may be persons that, even though they have OpenGL installed, may not want to build OpenGL support into the game. So far I have been unable to nicely resolve this issue ... read "I lack the knowledge" (see the ebuild for the hack I have implemented). This should _definately_ be fixed _before_ the ebuild is added to portage. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 32489 [details] mures-0.5.ebuild
Created attachment 32490 [details, diff] mures-0.5-screenshot.patch
Created attachment 32491 [details, diff] mures-0.5-save.patch There's really not much point to this patch as the game doesn't have any "load game" functionality even though it can save games (maybe it was planed for a future version). However, since I didn't know how the program reacted when it tried to save the game in a place where it couldn't because of permissions, I just thought it might be better to change the save game location to the home dirrectory.
Created attachment 32513 [details] mures-0.5.ebuild
A few things: eutils needs to be inherit'd for epatch if [ `use... needs to become if use ... installs a bunch of .lua files but lua isn't mentioned in DEPEND? hmmm.... The hack has to be cleaned up before it goes into portage.
>> eutils needs to be inherit'd for epatch I have always wondered about this. Epatch seems to work without inherit eutils for me... are you absolutely sure? And if so, why does it work without inherit eutils? >> if [ `use... needs to become >> if use ... quote from man 5 ebuild: "use <USE item> If USE item is in the USE variable, USE item will be echoed and the function will return 0. If USE item is not in the USE vari- able, the function will return 1. Example: if [ `use gnome` ] ; then guiconf="--enable-gui=gnome --with-x" elif [ `use gtk` ] ; then guiconf="--enable-gui=gtk --with-x" elif [ `use X` ] ; then guiconf="--enable-gui=athena --with-x" else # No gui version will be built guiconf="" fi" end quote Also shouldn't that be "If USE item is not in the USE vari- able, the function will return 0."?! >> installs a bunch of .lua files but lua isn't mentioned in DEPEND? hmmm.... The game package already provides lua. At least for me, it worked without lua installed. >> The hack has to be cleaned up before it goes into portage. Definately :) ... I just don't know how to do it
Created attachment 32514 [details] mures-0.5.ebuild : inherit eutils, if [ `use -> if use
Created attachment 41311 [details] mures-0.5.ebuild Finally got a chance to look at the program again and immediately managed to solve the problem. That's what 4 months can do ;)
Created attachment 41312 [details] mures-0.5.ebuild On second thought... that sed belongs in src_unpack()
The opengl stuff doesn't look like it works to me. Does something automatically rebuild configure after you've modified configure.in?
I don't know if it automatically rebuilds configure, but it worked for me. _How_ does it not work for you? Can you be a little more explicit? Anyway, I've reworked the ebuild a little bit. Hopefully it should solve your problems. If it doesn't work then please tell me _how_ it doesn't work.
Created attachment 54582 [details] mures-0.5.ebuild
Created attachment 55989 [details] mures-0.5.ebuild Updated header.
It's been almost a year already since this bug was fixed. Is there any interest of getting this ebuild in portage? Don't get me wrong, I'm not complaining, I just want to know if I should keep updating the ebuild or not. Also, I would like to know if there are any technical issues with the ebuild that I could possibly help with. I understand that you're all busy, but I think a minimum level of communication between developers and users is in order.
You're already at the minimum level of communication. Do you think we need less? We can surely accomodate that one. ;] Do you really want us making comments just like this one in every single bug stating that while this bug has not gone away, it will one day be completed? How about I give you a time estimate? I think this bug will be resolved 13 days after SpanKY wins the United States presidency. Now that my own sarcasm has piqued my interest in this, I'm adding it to my personal TODO list. However, I am in an away status at the moment, due to buying a new house, so anything on my list has to wait a few weeks. If one of the other guys hasn't done it by then, I'll put this in portage. As for updating the ebuild, it is definitely a better idea than abandoning them. After all, if the ebuild stays updated, then when we do visit it, we can simply test/commit, rather than having to update it for the latest version ourselves. Many times bugs get passed over for easier ones, especially when time is limited.
If you read the posts you will see that Mr Bones complained that the opengl stuff doesn't work for him without saying why or posting more information. Even after I tried fixing the problem he did not reply. This is the kind of stuff you for which you close bugs immediately if the users do it. Shouldn't developers set an example? This is what I was reffering to when I mentioned the lack of communication between developers and users. As far as your sarcastic comment is concerned, I think it is childish and totally uncalled for. I tried to formulate my post so as not to sound like I'm pestering or begging you, it was mainly to point out the lack of communication. I also tried to keep it as polite and respectful as possible. Maybe I failed to do that, however, this is no reason to post comments like the one you posted. I thought Gentoo had an etiquette policy ( http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=2 ). This has really left a bad taste in my mouth.
Wow... what can I say except that some of you guys really need to lighten up. Did you see the little ";]" at the end of that? Yeah, that means it is a joke. It means I was pulling your leg and trying to ease tension by being funny. If this has left a bas taste in your mouth, then I'm sorry, but you have to understand that we're all volunteers here, and we like to have fun. Pointing out our own policies as if we don't know them is rather insulting. I'm not really going to comment on that anymore, as there's no point. Anyway, I gave you your answer in the last post. I'll check it out as soon as I get more free time to work on Gentoo. We're a bunch of jokers on the games team. If this offends you in some way, please refrain from posting games requests, as I am sure we will continue to be the jovial personalities that you all either love ot loathe. ;]
Do I feel embarased? Yes. I did see the ";]" but the square bracket (instead of the round one) fooled me. If I made any comments that insulted you please accept my appologies. It was not on purpose. I know all the Gentoo developers are volunteers. I don't know if I've made more than two or three comments regarding the fact that things were not getting fixed or not getting added to portage since I started using Gentoo a few years ago. I _always_ keep in mind the fact that you are volunteers. However, we, the users trying to contribute to Gentoo by filing bug reports or submitting ebuilds, are also volunteers. When you (the developers) post things like "this, or that doesn't work" I know it's because you're trying to help. But please also post how, what or why it doesn't work. Maybe even an error message. This also goes for the users, of course. Again, I would like to appologise, for the previous post. If it was insulting it was maybe because I was also offended by what I thought was a rude comment. This is no excuse, I know. Sorry!
Added to CVS... Just a couple quick notes. - You can use doins -r to do recursive copies - This may be my personal preference, but I prefer to install the binary/shell script into the actual game directory and use games_make_wrapper to do the install into /usr/games/bin - Use ${dir} instead of ${DEST_DIR}... this is purely cosmetic, but it follows the same structure as most other games ebuilds Also, I left the DEPEND section the same. My only question is whether or not the game actually *requires* those versions or not. If it could work wiht lower versions, it should either be specified that way, or it should be left without a version atom. I'm not saying you did anything wrong, as I didn't check myself (yeah, yeah, bad wolfie) and am pretty much just trying to be informative. Thanks for the ebuild (and the patience!)
- You can use doins -r to do recursive copies * Thanks! I'll remember that. - This may be my personal preference, but I prefer to install the binary/shell script into the actual game directory and use games_make_wrapper to do the install into /usr/games/bin * I thought, and please correct me if I'm wrong, that it was the Gentoo policy for games to always put the binary/script in /usr/games/bin and only use a wrapper script if there was no way to patch the binary/script to use the Gentoo paths. - Use ${dir} instead of ${DEST_DIR}... this is purely cosmetic, but it follows the same structure as most other games ebuilds * Heh... this was my way of writing game ebuilds back then. I don't think there were a lot of ebuilds that that used ${dir} back then, at least not that I'm aware of. Also, you mean ${dir} as in a local variable defined with 'local dir' right? What would be a proper solution for the current ebuild? I used ${DEST_DIR} in several functions (src_unpack as well as src_install). Should I define ${dir} for both of them, or just make ${dir} global? - Also, I left the DEPEND section the same. My only question is whether or not the game actually *requires* those versions or not. If it could work wiht lower versions, it should either be specified that way, or it should be left without a version atom. * I think the DEPEND section can be safely changed to just DEPEND="media-libs/libsdl media-libs/sdl-image media-libs/sdl-net media-libs/sdl-ttf opengl? ( virtual/opengl )" since older versions are no longer in portage anyway. Those were the versions I tested it with (which were stable at the time) so I thought it sensible to use those in the ebuild so as not to generate possible erroneous bug reports from users about mures not working with older versions of those libraries.
- Use ${dir} instead of ${DEST_DIR}... this is purely cosmetic, but it follows the same structure as most other games ebuilds * Heh... this was my way of writing game ebuilds back then. I don't think there were a lot of ebuilds that that used ${dir} back then, at least not that I'm aware of. Also, you mean ${dir} as in a local variable defined with 'local dir' right? What would be a proper solution for the current ebuild? I used ${DEST_DIR} in several functions (src_unpack as well as src_install). Should I define ${dir} for both of them, or just make ${dir} global? Don't bother answering that (I just saw the ebuild you comitted, it wasn't in portage yet when I posted the question above) and I see what you meant.
- This may be my personal preference, but I prefer to install the binary/shell script into the actual game directory and use games_make_wrapper to do the install into /usr/games/bin * I thought, and please correct me if I'm wrong, that it was the Gentoo policy for games to always put the binary/script in /usr/games/bin and only use a wrapper script if there was no way to patch the binary/script to use the Gentoo paths. There isn't really a policy, but you're right. It should go into /usr/games/bin.
> There isn't really a policy, but you're right. It should go into /usr/games/bin. Right. So aren't you going to change the ebuild so that it installs the binary in /usr/games/bin then? Like in the original ebuild? Also, if you're going to do that you might as well trim version numbers from DEPEND since, as I've mentioned above, there are no older versions than those in portage anymore.
Also, there are six makefiles which `rm -f src/*/Makefile*` fails to delete. Those in maps/battle and maps/puzzle.
