Version 2011.1 is available. % grep MY_PV= gargoyle-20100930.ebuild MY_PV="2010.1" Reproducible: Always
I added a cleaned up ebuild for 2011.1 in the interactive-fiction overlay. (It's in layman.) Direct link to the ebuild: http://repo.or.cz/w/gentoo-interactive-fiction.git/blob_plain/HEAD:/games-engines/gargoyle/gargoyle-2011.1.ebuild Is this is added to portage, the current 20100930 version should be removed since it has an unfortunate version number and makes 2011.1 look like a downgrade. (In the overlay, 20100930 is masked due to this.)
(In reply to comment #1) > Is this is added to portage, the current 20100930 version should be removed > since it has an unfortunate version number and makes 2011.1 look like a > downgrade. (In the overlay, 20100930 is masked due to this.) And I just found out that portage ignored the package.mask of overlays (grr!), so you still have to mask 20100930 manually.
The ebuild fails for me with the error: >>> Compiling source in /var/tmp/portage-tmpfs/portage/games-engines/gargoyle-2011.1/work ... Invalid option: -l usage: jam [ options ] targets... -a Build all targets, even if they are current. -dx Display (a)actions (c)causes (d)dependencies (m)make tree (x)commands (0-9) debug levels. -fx Read x instead of Jambase. -g Build from newest sources first. -jx Run up to x shell commands concurrently. -n Don't actually execute the updating actions. -ox Write the updating actions to file x. -q Quit quickly as soon as a target fails. -sx=y Set variable x=y, overriding environment. -tx Rebuild x, even if it is up-to-date. -v Print the version of jam and exit. ERROR: games-engines/gargoyle-2011.1 failed (compile phase): (no error message) Call stack: ebuild.sh, line 85: Called src_compile environment, line 2171: Called die The specific snippet of code: jam -sGARGLKINI="${GAMES_SYSCONFDIR}/garglk.ini" -sUSESDL=yes -sBUNDLEFONTS=no ${MAKEOPTS} || die In my make.conf I have: MAKEOPTS="-j5 -l6" If I remove the -l6 from MAKEOPTS, the ebuild works fine.
I changed the ebuild to not pass MAKEOPTS to jam. I wonder if there's a way I can just filter out the "-jN" part of MAKEOPTS and ignore the rest?
see lincity-ng-2.0.ebuild
(In reply to comment #5) > see lincity-ng-2.0.ebuild Thanks. I've now used the same sed line and pushed the changes to the overlay. Please let me know if there's anything in the ebuild that still needs work.
Could someone please rename gargoyle-20100930.ebuild in portage to gargoyle-2010.1.ebuild (that's the actual version number that gets installed by it) so that the ebuild in the overlay can appear as an upgrade?
(In reply to comment #7) Ebuild 20100930 has been renamed to 2010.1.
Created attachment 311073 [details] gargoyle-2011.1 ebuild build log Hi, I just tried compiling gargoyle-2011.1 using the ebuild from: http://repo.or.cz/w/gentoo-interactive-fiction.git/blob_plain/HEAD:/games-engines/gargoyle/gargoyle-2011.1.ebuild The ebuild failed to compile on my amd64 box. Attached you will find the build log; the interesting bit is where it complains: SharedLink build/linux.release/garglk/libgarglk.so Cc build/linux.release/agility/agxfile.o Cc build/linux.release/agility/auxfile.o Cc build/linux.release/agility/filename.o Cc build/linux.release/agility/parser.o Cc build/linux.release/agility/exec.o Cc build/linux.release/agility/runverb.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lsmpeg /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lvorbisfile collect2: ld returned 1 exit status x86_64-pc-linux-gnu-gcc -shared -Wl,-O1 -Wl,--as-needed -Wl,-soname,libgarglk.so -o build/linux.release/garglk/libgarglk.so build/linux.release/garglk/gi_blorb.o build/linux.release/garglk/gi_dispa.o build/linux.release/garglk/cggestal.o build/linux.release/garglk/cgblorb.o build/linux.release/garglk/cgfref.o build/linux.release/garglk/cgmisc.o build/linux.release/garglk/cgstyle.o build/linux.release/garglk/cgstream.o build/linux.release/garglk/cgunicod.o build/linux.release/garglk/cgdate.o build/linux.release/garglk/window.o build/linux.release/garglk/winblank.o build/linux.release/garglk/winpair.o build/linux.release/garglk/wingrid.o build/linux.release/garglk/wintext.o build/linux.release/garglk/wingfx.o build/linux.release/garglk/winmask.o build/linux.release/garglk/event.o build/linux.release/garglk/draw.o build/linux.release/garglk/config.o build/linux.release/garglk/imgload.o build/linux.release/garglk/imgscale.o build/linux.release/garglk/fontdata.o build/linux.release/garglk/babeldata.o build/linux.release/garglk/sndsdl.o build/linux.release/garglk/sysgtk.o build/linux.release/garglk/fontgtk.o build/linux.release/babel/babel_static.a `pkg-config freetype2 gtk+-x11-2.0 gdk-x11-2.0 gobject-2.0 glib-2.0 fontconfig --libs` -ljpeg -lpng -lz -lSDL_mixer -lSDL_sound -lSDL -lsmpeg -lvorbisfile ...failed SharedLink build/linux.release/garglk/libgarglk.so ... ...skipped gargoyle for lack of libgarglk.so... ...skipped advsys for lack of libgarglk.so... ...skipped tadsr for lack of libgarglk.so... I would say the ebuild is missing dependencies for -lvorbisfile ;-)
Thanks for catching that one! Looking at the sources reveals that Jamrules is linking against libraries that are not used directly by gargoyle. Vorbis and smpeg libraries are used by SDL_sound, which gargoyle links against. I will submit a fix upstream. Use flag deps on sdl-sound and (for this version of the ebuild) a sed for Jamrules should fix it. Before I commit, I'd like to know how can I split this: sed -i -e "s/GARGLKLIBS += -lSDL_mixer -lSDL_sound -lSDL -lsmpeg -lvorbisfile ;/GARGLKLIBS += -lSDL_mixer -lSDL_sound -lSDL ;/g" Jamrules into several lines so that it doesn't violate the 80 columns rule :-/
OK, I've just shortened that sed line. Let me know if you find any other problems with the ebuild.
Ebuild worked fine this time. Just added it to Portage :-)
(In reply to comment #12) > Ebuild worked fine this time. Just added it to Portage :-) Thanks! I can now remove the ebuild from the overlay. You might want to alter the USE deps a bit. For example, although "modplug" is preferred, "mikmod" is also possible (though inferior; libmodplug supports more MOD music formats). Same goes for "mp3" (it uses mpglib) vs "mpeg" (which uses the semi-broken SMPEG library which has trouble with some MP3 files). I wasn't sure what to do here, so I simply chose the optimal flags. The most "politically correct" thing would be to depend on modplug OR mikmod, and on mp3 OR mpeg.
Let someone who actually would rather use mikmod or mpeg step forward and open a new bug. Gargoyle ebuild is already complicated enough as it is ...
