Hi, here is a patch for Quake4 for the new version which adds an smp binary. "id" should be in lower-case, according to http://en.wikipedia.org/wiki/Id_Software
Created attachment 85694 [details, diff] quake4-bin-1.2.diff Patch of quake4-bin-1.2.ebuild to create quake4-bin-1.2.1.ebuild
(In reply to comment #1) > Created an attachment (id=85694) [edit] > quake4-bin-1.2.diff > > Patch of quake4-bin-1.2.ebuild to create quake4-bin-1.2.1.ebuild > This ebuild works fine, and enables smp support with a USE flag.
Created attachment 85703 [details, diff] quake4-bin-1.2.diff Removed out-of-date mirrors (which didn't even contain the now-old version 1.2). Also removed 3dgamers mirror, because portage will wget a HTML error file if a HTTP mirror does not contain the new version. Added RESTRICT="primaryuri".
x86 ebuild ran smooth
Version 1.2.1 has some stability issues with smp, apparently: http://forums.gentoo.org/viewtopic-t-436661-start-30.html
It may be worth it to put this into portage marked testing and put quake4-bin-1.2 stable. This version does fix some issue that I have read around the net some Linux users were having. Here is the three fixes from the change log * no longer using SDL_ListModes to filter available resolutions ( use +set r_useSDLModes to re-enable, SDL_ListModes returns way too little of the possible resolutions ) * fix stalls that may happen with DNS resolution ( Linux bug only ) * fix a download bug: if the server is configured with some of the fs_*path cvars having a trailing slash, they might cut one character when returning download URLs.
Since x86 and amd64 are identical (symlink) I've just removed the arch checks entirely. I also am not adding the smp USE flag. I'm just installing it by default since that's what upstream does.
quake4-bin-1.2.1 currently in Portage does not install /opt/quake4/quake4smp.x86 "smp" should be a USE flag. Who wants to see an additional SMP desktop entry if they haven't got an SMP processor? Also, any ebuilds for Quake 4 mods would have to be changed to execute quake4-smp rather than quake4. id's .run file does not rename libSDL-1.2.id.so.0 to libSDL-1.2.so.0, so why should the ebuild?
Created attachment 85955 [details, diff] quake4-bin-1.2.1.diff Patch to apply to quake4-bin-1.2.1.ebuild, to fix the issues I mentioned.
I ran just quake4 when I saw there was no quake4-smp but in console I did r_useSMP 1 and it seemed to turn smp on. It would be nice to do it the offical ID way.
> it seemed to turn smp on. It's lying, unless the frames per second increased. id's package contains quake4.x86 and quake4smp.x86 - it seems unlikely that quake4.x86 contains smp code also.
(In reply to comment #11) > > it seemed to turn smp on. > > It's lying, unless the frames per second increased. id's package contains > quake4.x86 and quake4smp.x86 - it seems unlikely that quake4.x86 contains smp > code also. > hmm ok just thought I would try it. I havnt played much because of school and work since beat the game(1.0.x) so it did seem faster to me. heh it also didnt crash at all. I wonder why Id cannt have the SMP code in one bin and be able to turn it on and off?
I've fixed up the ebuild in portage to install the smp binary. I actually just missed that when I did my test. Anyway, I'm *not* adding any USE flags for this, as it's asinine when upstream installs it no matter what.
(In reply to comment #13) > I've fixed up the ebuild in portage to install the smp binary. There's a typo in line 61 of the ebuild file. It should read bin/Linux/x86/libSDL-1.2.id.so.0 bin/Linux/x86/quake4smp.x86 \ instead of bin/Linux/x86/libSDL-1.2.id.so.0 bin/Linux/x86/quakesmp4.x86 \
(In reply to comment #13) > as it's asinine when upstream installs it no matter what. Why so reluctant to fix upstream's broken behaviour? Especially when it's easy, and I've supplied a patch to do it. I'm reopening this bug, due to the outstanding problem mentioned in comment #14.
DO NOT REOPEN THIS BUG!!! This bug is for having the ebuild in the tree. Quit reopening it for other things that are NOT about getting it in the tree.
This has been done, so CLOSING.
> This bug is for having the ebuild in the tree. Would that be an ebuild which actually works for a change, since you ignore my patches?
Excellent attitude... See, your patches are not ignored. In fact, if you noticed what I commit, you'd see that most of what goes into them is the same as your patches. However, when your patches include things that I, as the maintainer of the package, do not feel need to go in, I'm not going to apply them. A good example of this is the smp USE flag, which I find to be an unnecessary addition. Because of this, I had to manually add parts of the patches that I liked, which means I'm more likely to make a mistake. In the future, I'll simply wait until I can be at home and actually test everything properly before making any commits, even if it means a delay in getting fixes into the tree. If you want your patches to be accepted verbatim, quit adding features to them, especially features where the maintainer has already stated in the bug that the feature wasn't wanted. Adding it back in is really a slap in the face to me. Now, if you feel like you need to continue to discuss this, feel free to contact me outside of bugzilla, as this isn't a discussion forum.
> which I find to be an unnecessary addition. Well, that's a totally unsatisfactory explanation, for anyone who actually cares about improving the ebuild. Care to elaborate? I have already stated two logical reasons why it is a desirable addition, in comment #8. And provided the patch. What more am I supposed to do? State logical reasons, and I will happily accept them. Show that I am wrong, and I will happily apologize and try to produce better results in the futue. But, treat me like an imbecile and give me crap, and you lose my support.
how exactly do you want "unnecessary" spelled out for you ? controlling the generation of a symlink via the USE flag 'smp' is unnecessary overhead; no more explanation is needed
(In reply to comment #21) > how exactly do you want "unnecessary" spelled out for you ? In a way that makes sense, please. > controlling the > generation of a symlink via the USE flag 'smp' is unnecessary overhead; no more > explanation is needed It takes seconds for me to add the USE flag as a patch. How long does it take to add it to Gentoo Portage? Why class it as unnecessary overhead, versus a desirable enhancement? Adding duplicate useless menu entries, just because upstream mistakenly thinks it's a good idea, doesn't make it a good idea for Gentoo.
