Bugzilla Bug 19454

I created an ebuild for pingus-0.6.0, it is attached as pingus.tar.gz.

The Creation was very easy and the emerge worked from the start. I don't suspect
any bugs in the ebuild.

Although I am not sure about the dependencies, made them the latest stable
packages, didi not test older versions of the libs.

Homepage is http://pingus.seul.org

http://bugs.gentoo.org/show_bug.cgi?id=19412 requests this ebuild.

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

Created an attachment (id=10772) [details]
contains pingus-0.6.0.ebuild

You beat me to the posting.  Attached please find my varient.  My version of
the ebuild is a bit more advanced, has the libxml2 dependancy, and covers the
conditional dependancies.

Note that pingus is GPL-2, not GPL-1 (see COPYING).  I'm not sure how to see if
clanlib's GL support is properly installed from an ebuild; hence I detect off
of the opengl USE flag (note that pingus will NOT compile in support for
clanlib's clabGL unless explicitly told too, or so it seems to be telling me).

Also note that pingus 0.6 documentation wants clanlib-0.6.5, and the latest
Gentoo has is clanlib-0.6.3.  A version bump for clanlib likely is in order.

Created an attachment (id=10773) [details]
Another pingus-0.6.0 ebuild 

A (slightly) more advanced pingus ebuild varient.

You have things in IUSE you do not check for and which do not appear in the
dependencies. Please change this first.

*** Bug 19412 has been marked as a duplicate of this bug. ***

Hmm... not sure here.  I use the opengl check to set the flag, but I'm not sure
what clanlib requires since we seem to inherit it via clanGL. 
app-games/clanlib also does not check for a specific version of OpenGL.

The X flag gets a bit more confusing.  I see that clanlib does not require X,
but starting pingus from the console asks me to choose a display type, and the
only choice there is "x11".  Clanlib's online documentation does not make it
very clear at a glance what alternative 2D renderers it has in 0.6.

If clanlib can render 2D without X, we likely can get away with removing it. 
But if clanlib requires X yet can be compiled without it (like opengl), what is
the prefered strategy; should we (somehow) detect clanlib's settings via
probing for library files or similar, do nothing, or just USE "X" and require
"virtual/X11" like clanlib (although clanlib can --disable-x11)?

Dredging through the source code, I see the mikmod and oggvorbis dependancies
are also utilized via clanlib.  We may just be able to get away with checking
for clanlib, libxml2, and opengl and stating "if you want support for
(vorbis|mikmod|X|etc.), clanlib must have it."

This is going to take some work to hunt down.  Pingus also should have a nls
USE flag control; nls --[en]disable-nls is supported.

Just a few comments after reading what's been done so far:
1) Pingus requires ClanLib 0.6.5 and has some patches in /contrib which should be applied to ClanLib 0.6.5 (not mandatory but recommended)
2) OpenGL mode is not tested much and likely to crash
3) If you manage to get ClanLib framebuffer to work, Pingus won't need X (never tried it myself)
4) MikMod / Ogg is only required if ClanMikMod / ClanVorbis are present.
5) libxml2 is required to build Pingus
6) gettext is an optional dependency
7) Any problems with building Pingus may be directed to me, I'm Pingus developer and gentoo user (lacking the time to do an ebuild *g*)

Where's my brain today? There are three patches to ClanLib:

1. clanlib_x11_mousewheel.diff - harmless
2. clanlib_grave.diff - breaks binary compatibility, don't know wheter ebuilds may enforce recompile of everything dependend on ClanLib
3. clanlib_gui.diff - only usefull to Pingus, may harm other projects. I guess we should provide a better patch here

Is clanlib 0.6.5 an absolute dependancy, or is 0.6.3 acceptable?  I personally
have had no major issues running pingus under clanlib 0.6.3.  The only minor
details I have noticed is that OpenGL mode looks a bit ugly (low-color) on my
GeForce 3 Ti 200 via nvidia-glx, and that telling pingus to use a screen size
other than the default 800x600 does not work too well, as many graphics appear
to be statically sized.

We really need a good way to detect if some other ebuild has been compiled with
certain USE flags.  I have written several ebuilds and read dozens of others,
but I have not seen any that do this (is it possible?).

If Pingus compiles with ClanLib 0.6.3 it may be possible, but if I remember
right,  ClanLib 0.6.5 came to existence because of bug fixes made on behalf of
Pingus. I'd strongly recommend to make ClanLib 0.6.5 a prerequisite. It's the
final version of ClanLib 0.6 anyway unless some important patches are made by
ClanLib users.

Another variation ebuild using games.eclass so that users in group games can
just type "pingus" from the prompt rather than "/usr/games/pingus", also puts
the binary in /usr/games/bin 

Created an attachment (id=10846) [details]
ebuild for pingus with games.eclass support

Removed GL option because David recommended that.
Cleared IUSE because we don't check for anything now.
The vorbis and mikmod stuff is a clanlib issue, no need to depend on that
(or was there some other reason?).
Please test it, should be in portage after the next mirror update.

You don't need to deactivate OpenGL support, I've heard from some people that
they got it working. It would just be nice to print out a warning that OpenGL
is considered experimental for this release to prevent too much traffic on the
Pingus mailing list. ;-)
Even if you compile it with OpenGL support you still have to supply a command
line argument to run it.

Hm... tried to run pingus with xfree 4.3.0-r2 and just got a SIGABRT

last lines of an strace:

open("/home/kursawe/.pingus/config", O_RDONLY) = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
kill(27521, SIGABRT)                    = 0
--- SIGABRT (Aborted) ---
+++ killed by SIGABRT +++

will investigate further tomorrow.

hm... works fine on a different machine. Too fine. Wasted quite some time
playing the tutorial :-). After removing a few old gcc versions out of the
corners of the other machines' hard disc, it starts. So I think this was my
personal problem. Closing again.

*** Bug 14156 has been marked as a duplicate of this bug. ***