Bugzilla Bug 131604

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 an attachment (id=85694) [details]
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] [details]
> 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 an attachment (id=85703) [details]
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 an attachment (id=85955) [details]
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.