Bugzilla Bug 122838

Rename ebuild, create digest, and you're set.

I'll get this one...

Created an attachment (id=79850) [details]
diff from games-fps/nexuiz-1.2.1

Hi,
Few changes from precedent ebuild.

I have a problem with sound.
I don't know if the problem is due to my system or to the game.
I launch nexuiz-sdl with nexuiz-sdl -sndstereo as a workaround

(In reply to comment #2)
> I have a problem with sound.
> I don't know if the problem is due to my system or to the game.
> I launch nexuiz-sdl with nexuiz-sdl -sndstereo as a workaround

Same problem here.
This is my emerge info:

Portage 2.0.54 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r2,
2.6.14-gent oo-r5 i686)
=================================================================
System uname: 2.6.14-gentoo-r5 i686 Intel(R) Pentium(R) 4 CPU 2.20GHz
Gentoo Base System version 1.6.14
ccache version 2.3 [enabled]
dev-lang/python:     2.3.5-r2, 2.4.2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium4 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env
/usr/kde/3.3/share /config /usr/kde/3.3/shutdown /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kd e/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/mozilla/default s/pref /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips /config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config /
/usr/share/texmf/xdvi/ /var/bind /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=pentium4 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks fixpackages sandbox sfperms strict"
GENTOO_MIRRORS="http://mir1.ovh.net/gentoo-distfiles/
http://mir.zyrianes.net/ge ntoo/ ftp://mir.zyrianes.net/gentoo/
ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mi rror/"
LANG="fr_FR.utf8"
LC_ALL="fr_FR.utf8"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X aac aalib adns alsa apache2 apm arts audiofile avi berkdb
bitmap-font s bzip2 cdr crypt cups curl divx4linux dts dvb dvd eds emboss
encode esd etherea l exif expat fam ffmpeg flac foomaticdb fortran gd gdbm
geoip gif glut gmp gnome  gpm gstreamer gtk gtk2 gtkhtml guile hal idn
imagemagick imlib ipv6 java jpeg l cms ldap libg++ libwww live mad matroska
mhash mikmod mmx mng mono motif mozilla  mp3 mpeg mysql nas ncurses nls
nsplugin ogg oggvorbis openal opengl oss pam pcr e pdflib perl png python qt
quicktime readline real recode samba sdl slang snmp speex spell sqlite sse sse2
ssl svga tcltk tcpd tetex tiff truetype truetype-fon ts type1-fonts udev
unicode usb vorbis win32codecs xine xml xml2 xmms xv xvid zl ib userland_GNU
kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LDFLAGS, LINGUAS

Created an attachment (id=79879) [details]
Error output from running nexuiz-(glx|sdl) (both give identical results)

I've just added an attachment containing the output that I get when I try to
run this latest version after making the ebuild and emerging. The game doesn't
load at all; all I get is 4 squares on my screen. I can access the console by
pressing esc.

My system details are as follows:

Gentoo Base System version 1.6.14
Portage 2.0.54 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r2,
2.6.11-gentoo-r11 i686)
=================================================================
System uname: 2.6.11-gentoo-r11 i686 AMD Athlon(tm) XP 1800+
dev-lang/python:     2.3.5-r2, 2.4.2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.4.3-r4, 1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X aac alsa apm arts audiofile avi berkdb bitmap-fonts browserplugin
bzip2 cdr cjk crypt cups curl divx4linux dts dvd eds emboss encode esd exif
expat fam ffmpeg flac foomaticdb fortran gdbm gif glut gmp gpm gstreamer gtk
gtk2 idn imagemagick imlib ipv6 jabber java jpeg kqemu lcms ldap libg++ libwww
live mad matroska mikmod mng motif mp3 mpeg msn mysql ncurses nls nptl nvidia
ogg oggvorbis opengl oscar oss pam pcre pdflib perl png python qt quicktime
readline real ruby samba sdl softmmu spell ssl svg svga tcltk tcpd tetex theora
tiff truetype truetype-fonts type1-fonts udev usb vorbis win32codecs xanim xine
xml xml2 xmms xv xvid yahoo zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS

Applied the patch, created a digest file and emerged. Works fine for me
(amd64).

Also, it would be great if nexuiz could be ~amd64 keyworded by default.

Created an attachment (id=82001) [details]
that should work properly, my first ebuild

wanted to nexuiz.sh as attachment but bugzilla complained about an empty file,
so here it goes:
#!/bin/sh
cd "/usr/share/games/nexuiz/"
nexuiz-sdl "${@}"

Works fine on my AMD64 ...

Portage 2.1_pre6-r1 (default-linux/amd64/2006.0, gcc-4.1.0, glibc-2.3.6-r3,
2.6.15-gentoo-r7 x86_64)
=================================================================
System uname: 2.6.15-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3000+
Gentoo Base System version 1.12.0_pre16
dev-lang/python:     2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=athlon64 -fomit-frame-pointer -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon64 -fomit-frame-pointer -pipe"
DISTDIR="/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="ftp://ftp.linux.cz/pub/linux/gentoo http://mirror.gentoo.sk/pub
http://distfiles.gentoo.org/"
LANG="cs_CZ.UTF-8"
LC_ALL="cs_CZ.UTF-8"
LINGUAS="cs"
MAKEOPTS="-j3"
PKGDIR="/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/portage"
PORTDIR_OVERLAY="/overlay"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X aac acpi alsa apm audiofile avi bash-completion bitmap-fonts bzip2
cdr css cups dbus dga dio directfb dri dts dvd dvdr dvdread emboss encode fbcon
ffmpeg flac flash foomaticdb fortran ftp gdbm gif gpm hal i8x0 icq id3 id3v2
imagemagick imlib ipv6 jabber javascript jpeg kde kdeenablefinal lame lcms lzw
lzw-tiff mad matroska mbox mikmod mime mp3 mpeg mplayer ncurses nls nowebdav
nptl nptlonly nvidia ogg oggvorbis openal opengl osc oscar pcre pdflib perl pic
png posix ppds python qt quicktime readline sdl session sftplogging skey
sockets speex ssl subversion svg symlink theora tiff truetype truetype-fonts
type1-fonts unicode usb userlocales utf8 vcd vorbis xine xml xml2 xpm xv xvid
zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux
linguas_cs userland_GNU video_cards_nvidia"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LDFLAGS

Created an attachment (id=82109) [details]
nexuiz-1.5.ebuild

Here is a tidied ebuild.

So this game *requires* opengl/X11 to build?  If not, then it shouldn't be in
DEPEND and only in RDEPEND.  Also, if ti is possible to build a decicated-only
server without the client, then the ebuild should support it.  I would say that
it most likely would need to be wrapped around the opengl USE flag.

Created an attachment (id=82162) [details]
nexuiz-1.5.ebuild

Here are better DEPENDs.

Who would try to emerge an OpenGL/SDL client, *before* emerging Xorg? It's far
simpler to make them emerge Xorg first.

drop pkg_setup() and have it default to something reasonable.  The use flag
check and die thing is not what we want.

The "default" is opengl. How can the ebuild "default to something reasonable"
whilst remaining reasonably elegant? Something has to *give* - and it's the USE
flags that the user specified.

Created an attachment (id=82188) [details]
nexuiz-1.5.ebuild

Slightly better DEPENDs, using a parameter as in the app-emulation/vice ebuild.

Hi,

- Why to use an shell script wrapper instead of sed to modify source code ?

The description of opengl useflag in /usr/portage/profile/use.desc is in
contradiction with how it is used in this ebuild imho.
The sdl version needs opengl of course. sdl is just used as a layer for
keyboard/mouse input, video intialisation and some other stuff.
And media-libs/libsdl has to be build with opengl and X useflags.


About the problem to have a dedicated only build, I think the best way is to
have an separate ebuild, maybe named nexuiz-dedicated.

Can you tell me what do you think about it ?
If you are ok, I'll open a new bug and send an ebuild who just build the
dedicated server, and in this case, I think we can remove all the related stuff
in the "client" ebuild, and build the glx version by default.

(In reply to comment #12)
> Created an attachment (id=82162) [edit] [details]
> nexuiz-1.5.ebuild
> 
> Here are better DEPENDs.
> 
> Who would try to emerge an OpenGL/SDL client, *before* emerging Xorg? It's far
> simpler to make them emerge Xorg first.
> 

Perhaps someone who uses aalib? ;)

(In reply to comment #16)
> The sdl version needs opengl of course. sdl is just used as a layer for
> keyboard/mouse input, video intialisation and some other stuff.

Are you *positive* on this?  What about SDL to aalib?  SDL to DirectFB?  Is
opengl *required* for this to build/run?

> And media-libs/libsdl has to be build with opengl and X useflags.
> 
> 
> About the problem to have a dedicated only build, I think the best way is to
> have an separate ebuild, maybe named nexuiz-dedicated.

No.

Building the dedicated server should be independant of building the client. 
You should be able to do both from the same ebuild.  The only time we should
ever see a separate *-ded ebuild is when upstream publishes a dedicated-only
version of their software, such as ut2004-ded or nwn-ded.  It simply isn't
necessary for a source-based ebuild.

Here's the thing, if the game *requires* opengl to build the client, then you
would do it pretty much like this (pseudo-code):

if use dedicated ; then build dedicated-server
if use opengl; then build client
if ! use dedicated && ! use opengl ; then build client

This gives us "sensible defaults" of defaulting to the client when the user has
neither USE flag selected.  I don't know if the game client can be run without
opengl, but that would be something to investigate, as it might make it easier
to build, rather than having opengl, sdl, and dedicated in IUSE.

(In reply to comment #16)
> - Why to use an shell script wrapper instead of sed to modify source code ?

I see it as more reliable for an ebuild (which will hopefully stay unchanged,
apart from the filename, for several versions of the app) to exploit an app's
default behaviour, than to hack the source code.

(In reply to comment #18)
> if ! use dedicated && ! use opengl ; then build client

The equivalent of that would be needed in the DEPENDs also. Which makes the
ebuild ugly.

What the "default behaviour" should do is debatable - a choice of dedicated,
opengl or sdl. Perhaps the opengl client is more stable, but the sdl client has
more eye-candy - is it a fast PC & video card? And of course, if the PC doesn't
even have xorg installed, then the user probably only wants the dedicated
server. This is all too uncertain. It's much cleaner to force the user to
choose. It's common practice to have "opengl" as a global USE flag anyway (or
even "dedicated" for servers), in which case that already specifies the default
behaviour that the user wants.

(In reply to comment #18)
> Are you *positive* on this?  What about SDL to aalib?  SDL to DirectFB?  Is
> opengl *required* for this to build/run?

Please, have a look in darkplaces source code if you have some time to spend on
it. In particular vid_sdl.c


(In reply to comment #19)
> see it as more reliable for an ebuild (which will hopefully stay unchanged,
> apart from the filename, for several versions of the app) to exploit an app's
> default behaviour, than to hack the source code.

And hopefully, the hack will stay unchanged too ;)
Imho, a wrapper is an ugly workaround to avoid when possible.
Please read Description of fonctions here :
http://www.gentoo.org/proj/en/desktop/games/games-ebuild-howto.xml#doc_chap4

> It's much cleaner to force the user to choose.
As a gentoo user, I will hate this.
Imagine if all ebuilds are stopping for any reason.

(In reply to comment #20)
> And hopefully, the hack will stay unchanged too ;)

Look at the first file attachment for this bug, and the problems caused by not
finding the data files (such as 4 squares appearing on a black screen) :)

> Imagine if all ebuilds are stopping for any reason.

I'd rather imagine something sensible, like prodding the user to configure his
USE flags properly. Would you have the ebuild automatically go for the opengl
client, even when the user could have "-opengl" in make.conf? That, to me,
would be a clear case of a bug in the ebuild.

(In reply to comment #21)
> I'd rather imagine something sensible, like prodding the user to configure his
> USE flags properly. Would you have the ebuild automatically go for the opengl
> client, even when the user could have "-opengl" in make.conf? That, to me,
> would be a clear case of a bug in the ebuild.

Well, so long as the package actually builds with the default USE flags from a
stage3, I don't really care if it bails out on USE="-opengl -dedicated" as
much.

I *really* dislike ebuilds that bomb out like that.  Most people will consider
that when they are merging a game that it will work for them.  I would also go
as far as to say that most people expect the client.  For those that do *not*
expect the client, there is USE="dedicated" already.  The reasoning for having
USE="-opengl" even *possible* in the ebuild is for dedicated server users
*only*.  The game *requires* opengl *except* when used as a dedicated server. 
I think the ebuild should reflect that.  In fact, I'm going to make sure that
any other games ebuilds in the tree that are not following this guideline do
so, as users expect things to work when they emerge them.

(In reply to comment #22)
> I *really* dislike ebuilds that bomb out like that.  Most people will consider
> that when they are merging a game that it will work for them.

Most people using Gentoo (as opposed to *ahem* Mandrake and the like) will not
expect to see blatant disregard of their USE flags. Who exactly is meant to be
in control of the PC - the ebuild maintainer, or the root user? Most packages
do have a fairly obvious default - this package does not. So, the obvious
action is to ask the user to clarify, rather than have the audacity of assuming
a setup which could totally conflict with the existing setup of USE flags (-X,
-opengl and -alsa, to take the example of a headless games server).

*Determinism* in computers is a good thing. Is Gentoo now trying to become a
distro which Aunt Ethel can maintain? :)

I look forward to seeing the awkward logic in the ebuild you propose, and the
bug reports from people mystified at its behaviour. An ebuild which dies while
saying "you have 3 options - choose at least one, because *you* are the
appropriate person to have the choice" is far more sane.

Created an attachment (id=82291) [details]
nexuiz-1.5.ebuild

Added required space between "!" and "use".

(In reply to comment #23)
> Most people using Gentoo (as opposed to *ahem* Mandrake and the like) will not
> expect to see blatant disregard of their USE flags. Who exactly is meant to be
> in control of the PC - the ebuild maintainer, or the root user? Most packages
> do have a fairly obvious default - this package does not. So, the obvious

Here is where I will obviously disagree with you.  I think that *any* game has
an obvious default, the game client.  In this case, it is exactly as I said
above.  The game should build the client if no USE flags are selected, the
dedicated server *and* client if USE="dedicated opengl", and only the dedicated
server if USE="dedicated -opengl".

> action is to ask the user to clarify, rather than have the audacity of assuming
> a setup which could totally conflict with the existing setup of USE flags (-X,
> -opengl and -alsa, to take the example of a headless games server).

Bad example, as you would also have USE="dedicated" for such a scenario.

> *Determinism* in computers is a good thing. Is Gentoo now trying to become a
> distro which Aunt Ethel can maintain? :)

Why not?  You have a problem with my Aunt Ethel?

> I look forward to seeing the awkward logic in the ebuild you propose, and the
> bug reports from people mystified at its behaviour. An ebuild which dies while
> saying "you have 3 options - choose at least one, because *you* are the
> appropriate person to have the choice" is far more sane.

We have differing opinions here, and I'm afraid we're just going to have to
live with it being that way.  I don't think an ebuild should *ever* die unless
a user has explicitly set a conflicting set of USE flags (like both mysql and
postgresql in a package that supports only one or the other).  Not having
either USE="opengl" or USE="dedicated" is *not* an example of this, as one
could say that the game client requires opengl.  The *only* case in which
opengl is *not* a requirement is when the user wants only a dedicated server,
which is facilitated by USE="dedicated -opengl".  There's no point in
continuing to argue over it, as I can accept that you think differently than I
do on this matter.  Besides, according to www.nexuiz.com "Nexuiz is a 3d
deathmatch game project, created online by a team of developers called
Alientrap."  Sounds like being a 3D game, not a game server, is the "default"
to me.

Like I said, we could argue this back and forth forever, but I'd rather just
get the game into the tree, as I'm sure you would, too.