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 attachment 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 attachment 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 attachment 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. ***
