Bugzilla Bug 84419

An ebuild for glest-1.0.10, a cross-platform 3d realtime strategy game.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Created an attachment (id=52864) [edit]
glest-1.0.10.ebuild

glest-1.0.10.ebuild

(From update of attachment 52864 [edit])
mistake in ebuild...will fix and upload

Created an attachment (id=52896) [edit]
fixed glest-1.0.10.ebuild

Created an attachment (id=52897) [edit]
files/glestscript

files/glestscript is a script to launch glest from /usr/games/bin

Created an attachment (id=52899) [edit]
Final verison of glest-1.0.10.ebuild -- promise it works

Works now

(From update of attachment 52899 [edit])
Final version -- works

Created an attachment (id=52900) [edit]
files/glestscript -- works

this version works

Created an attachment (id=52901) [edit]
glestscript

glest.ini should be copied to user dir, not linked

Created an attachment (id=52980) [edit]
glest-1.0.10.ebuild (source revision 5)

source revision bump

Works for me.

Portage 2.0.51.19 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20050125-r0,                  2.6.10 i686)
=================================================================
System uname: 2.6.10 i686 Intel(R) Pentium(R) M processor 1.80GHz
Gentoo Base System version 1.6.9
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 26 2005, 17:00:31)                 ]
distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.5, 1.8.5-r3, 1.7.9-r1, 1.6.3, 1.9.4, 1.4_p6
sys-devel/binutils:  2.15.92.0.2-r1
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  2.6.8.1-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -march=pentium-m -pipe -mtune=pentium-m -fomit-frame-pointer"
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/share/config /usr/lib/X11/xkb /usr/shar                 e/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=pentium-m -pipe -mtune=pentium-m -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache digest distlocks sandbox sfperms"
GENTOO_MIRRORS="http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distri                 butions/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 aalib acpi alsa apm avi berkdb bitmap-fonts cdr crypt cups curl dvd d                 vdr emboss encode esd f77 fam flac font-server foomaticdb fortran gdbm ggi gif g                 pm gtk gtk2 guile i8x0 imagemagick imlib ipv6 ithreads jpeg ldap libg++ libwww m                 ad mikmod motif mp3 mpeg ncurses network nls nptl oggvorbis opengl oss pam pdfli                 b perl plotutils png pthreads python qt quicktime readline samba sdl speex spell                  sqlite ssl svg svga tcltk tcpd tiff truetype truetype-fonts type1-fonts xineram                 a xml2 xmms xv zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS

Why isn't this ebuild already gone into the tree ?!
Does anyone know or has is simply been forgotten or something?

Maybe because there is 84418 bugs before this one?  Maybe because there are
other bugs that are higher priority?  Maybe because the games developers are
also developers in other areas such as QA and Release Engineering that most
users consider quite a bit more important than glest and therefore get a higher
priority?  Maybe none of us have had time to test the game?

I can think of about a thousand more reasons why this hasn't gone in, but to be
honest, I know the reason is time.  New ebuild requests generally get the
bottom of the totem pole when it comes to bugs that we work on, as pretty much
any other bug is higher priority and reaches far more people.  Is there
something preventing you from using this in your overlay?

My suggestions:

1. Propose a package (games-strategy?)

2. Add ~arch only for archictures you really had access to.

3. The fact that you are using revision 5 of glest's source code should be reflected by the ebuild's version number. I know that this is somehow conflicting with this versioning scheme. Maybe you could contact the author of glest to name future releases like '1.0.10.revision' instead.

4. The CVS header is missing in the ebuild. Please synchronize with /usr/portage/skel.ebuild

5. The tone in the bugreports is getting worse IMHO. This GNU/Linux distribution needs an update to it's ebuild management policy. 

Btw: Stripping the binaries took a lot of time on my machine. Is this normal?

Otherwise the ebuild is fine and it worked on my machine. Thank you very much for your work.

emerge info:
Gentoo Base System version 1.4.16
Portage 2.0.51.19 (default-linux/x86/2004.2, gcc-3.3.5, glibc-2.3.4.20041102-r1, 2.6.10-gentoo-r6 i686)
=================================================================
System uname: 2.6.10-gentoo-r6 i686 AMD Athlon(tm) XP 2200+
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb  8 2005, 22:56:34)]
distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.7.9, 1.9.4
sys-devel/binutils:  2.15.92.0.2-r1
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  2.6.8.1-r1, 2.6.8.1-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -march=athlon-xp -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/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/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig candy ccache distcc distlocks sandbox sfperms"
GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo"
LANG="de"
LC_ALL="de_DE.utf8"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
USE="x86 3dnow 3dnowex X aalib alsa apm avi beepmp berkdb bitmap-fonts cdr crypt cups curl directfb dvdr emboss encode esd fam fbcon ffmpeg flac font-server foomaticdb gcj gdbm gif gimpprint gnome gpm gstreamer gtk gtk2 gtkhtml guile hal imagemagick imlib ipv6 java jikes joystick jpeg junit libg libg++ libwww mad mikmod mmx mng motif mozilla mp3 mpeg mysql ncurses network nls oggvorbis opengl pam pdflib png ppds python quicktime readline ruby samba scanner sdl silc slang speex spell sse ssl svg svga tcpd tetex theora tiff truetype truetype-fonts type1-fonts unicode usb xml xml2 xv zlib linguas_de linguas_en"
Unset:  ASFLAGS, CBUILD, CTARGET, LDFLAGS

Ok, one further request: How about a desktop file for KDE/Gnome?

> 3. The fact that you are using revision 5 of glest's source code should be reflected
> by the ebuild's version number. I know that this is somehow conflicting with this
> versioning scheme.

The is no problem with the ebuild version theme. AFAIK there is the
'_p#'-suffix (patchlevel) for such revisions, see
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
so the ebuild should be named glest-1.0.10_p5.ebuild

You could avoid the explicit naming of the version inside the ebuild with this:
DATAVERSION="${PV/_p?/}"
SOURCEREVISION="${PV/_p/-r}"
SRC_URI="http://www.stud.uni-karlsruhe.de/~uxsm/glest-${SOURCEREVISION}-source.tar.bz2
http://www.stud.uni-karlsruhe.de/~unatc/glest/glest-${DATAVERSION}-data.tar.bz2"
(I hope this works; sorry that I haven't testet this but I'm not at my machine
right now)

Created an attachment (id=54488) [edit]
ebuild for glest-1.0.10_p5

1. renamed to 1.0.10_p5
2. added support for autogenerated source and data version
3. fixed header
4. added 3 language files (german, russian, danish)
5. added desktop entry (icon, anyone?)

(tested on x86)

Created an attachment (id=54497) [edit]
A icon for glest

I know this icon is crap. I whipped it up in a couple of minutes. I'll make a
better one after I have had some sleep. Please use this as a placeholder. Hey,
it's better then nothing, righ?

I think this doesn't belongs here, but I have this problem, when running glest:

dano@picard:~ $ glest 
void Shared::Platform::Window::setStyle(Shared::Platform::WindowStyle) not implemented.
void Shared::Platform::Window::setBounds(int, int, int, int) not implemented.
virtual void Shared::Platform::PlatformContextGl::makeCurrent() not implemented.
terminate called after throwing an instance of 'std::runtime_error'
  what():  Your system doesn't support OpenGL version 1.3
  You may solve this problem by installing your latest video card drivers
  /usr/games/bin/glest: line 32:  6966 Aborted                 ./glest


OpenGL should work, because quake3 is running fast. Glxgears gives 1300 FPS. DRI is on. Using radeon driver from xorg. Having Ati radeon mobility 7500.

I think this doesn't belongs here, but I have this problem, when running glest:

dano@picard:~ $ glest 
void Shared::Platform::Window::setStyle(Shared::Platform::WindowStyle) not implemented.
void Shared::Platform::Window::setBounds(int, int, int, int) not implemented.
virtual void Shared::Platform::PlatformContextGl::makeCurrent() not implemented.
terminate called after throwing an instance of 'std::runtime_error'
  what():  Your system doesn't support OpenGL version 1.3
  You may solve this problem by installing your latest video card drivers
  /usr/games/bin/glest: line 32:  6966 Aborted                 ./glest


OpenGL should work, because quake3 is running fast. Glxgears gives 1300 FPS. DRI is on. Using radeon driver from xorg. Having Ati radeon mobility 7500.

Getting this error when trying to use the 1.0.10.p5 ebuild on AMD64 gentoo:

>>> Install glest-1.0.10_p5 into /var/tmp/portage/glest-1.0.10_p5/image/ category games-strategy
cp: cannot stat `/usr/local/portage/games-strategy/glest/files/glestscript': No such file or directory
sed: can't read glestscript: No such file or directory
cp: cannot stat `glestscript': No such file or directory
>>> dobin: making /var/tmp/portage/glest-1.0.10_p5/temp/glest executable...
install: cannot stat `/var/tmp/portage/glest-1.0.10_p5/temp/glest': No such file or directory

!!! ERROR: games-strategy/glest-1.0.10_p5 failed.
!!! Function src_install, Line 50, Exitcode 4
!!! couldn't install launcher

download the glestscript file attached to this bug report and copy here
/usr/local/portage/games-strategy/glest/.

Created an attachment (id=54766) [edit]
ebuild for glest-1.0.10_p5 (>=media-libs/openal-20040303)

media-libs/openal-20020127 is too old to allow compiling glest.
That is why we need ">=media-libs/openal-20040303" dependency.

p7 is out with a Font Exception fix (which I get currently).

renamed ebuild seems to be trying to unpack *.lng files - I doubt it should be doing that. egamesconf giving error.

-Sud.

Created an attachment (id=55069) [edit]
glest-1.0.10_p7.ebuild

Created an attachment (id=55070) [edit]
glest

can you guys try out the new wrapper script / ebuild ?

question ... why is the libglestlib.a installed ?  it's not a dynamic library so it's not like the glest binary will be using it ...

Spanky: libglestlib.a is installed because I never even created or tested the
install target, simply speaking don't use the "jam install" and copy the stuff
yourself for the current versions.
After all it didn't make much sense to install the original packages (of course
your wrapper script is a nice workaround for this...)
Maybe if I find more time I'll try to make this game really LFS compliant.

k k, well for now i say not bother installing it if the game works fine without
it :)

so the new ebuild works fine ?

The ebuild emerges.

do a "rm ~/.glesr -Rf && glest"

and get:

/usr/games/bin/glest: line 23: /home/sudrien/.glest/glest: No such file or directory
/usr/games/bin/glest: line 23: exec: /home/sudrien/.glest/glest: cannot execute: No such file or directory

ls -l gives


lrwxrwxrwx  1 sudrien users  27 Apr  7 17:28 data -> /usr/share/games/glest/data
lrwxrwxrwx  1 sudrien users  28 Apr  7 17:28 glest -> /usr/share/games/glest/glest
-rw-r-----  1 sudrien users 792 Apr  7 17:28 glest.ini
-rw-r--r--  1 sudrien users   0 Apr  7 17:28 glest.log
lrwxrwxrwx  1 sudrien users  26 Apr  7 17:28 map -> /usr/share/games/glest/map
lrwxrwxrwx  1 sudrien users  27 Apr  7 17:28 Tech -> /usr/share/games/glest/Tech
lrwxrwxrwx  1 sudrien users  30 Apr  7 17:28 tileset -> /usr/share/games/glest/tileset


/usr/share/games/glest/glest does not exist.

-Sud.

er...

that was "rm ~/.glest -Rf && glest"

ok, i fixed the wrapper script and added to portage, thanks everyone

file a new bug for issues relating to whats in portage now ...

Emerged glest from amd64 system. I kept on getting:

Exception: Can't open properties file: glest.ini

and after this was fixed:

Exception: Can't open properties file: data/lang/english.lng

Both were solved by copying the files over to ~/.glest and keeping the
directory structure (so there were ~/.glest/glest.ini and
~/.glest/data/lang/english.lng files) Could this be corrected in the ebuild?

Sure.  Would you file a bug for that problem, since this bug was to have the
ebuild added to portage.