Rename ebuild, create digest, and you're set.
I'll get this one...
Created attachment 79850 [details, diff] 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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 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] > 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 attachment 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.
