Tasty, tasty version bump, now with fewer mysterious crashes! I've pattern-matched myself up an ebuild for it; thought it might be worth tossing back into the tree. Reproducible: Always Steps to Reproduce:
Created attachment 176839 [details] Proposed ebuild
Created attachment 176840 [details, diff] New version of the filename-friendliness patch
According to ./garglk/Jamfile and ./Jamrules, fmod is disabled by default, so there is no need of fmod dep
I also test gargoyle on amd64 arch, it works (without fmod dep, as I say earlier) with tads2, agt and infocom games
Created attachment 177995 [details] This is ebuild with my modifications (~amd64 and dropped fmod)
Created attachment 178109 [details] experimental ebuild Hello, I have another ebuild, it's experimental because of bug with geas. Changes: 1) dropped sdl-sound dep because gargoyle compiles with internal copy 2) add smpeg and libvorbis deps (found this in sources) 3) add sdl flag 4) temporary disable building of geas, when sdl disabled, because of many errors (need help with fixing this) 5) enable merging of glulxe and nitfol interpreters
Created attachment 178113 [details] Log with geas building errors This is build.log after USE=-sdl emerge gargoyle (my experimental ebuild with enabled building of geas). Sorry for packing, but it's about 2.5Mb. Maybe someone can fix this errors?
Created attachment 178213 [details] ebuild fith my fixes and fix for geas I receive geas patch from upstream, so I can enable geas building now. I also drop level9 patch because I can build level9 interpreter without it. And also I drop gtk detection fix, because it was fixed in upstream. Please anybody test this ebuild, especially level9 and geas, with or without sdl, on 32/64 bit arch
Created attachment 178214 [details, diff] geas building fix from upstream
Also, upstream propose disabling of filename-friendliness-20081225.patch: [quote] Oh, I see what's happened. You're applying a patch that prefixes all the interpreters with "gargoyle-" at the time the object files are linked together. This is not recommended for several reasons; the main one is that it breaks portability for custom Gargoyle .ini files that authors might ship with their games. A better approach is outlined in a discussion on this list from two weeks ago: http://groups.google.com/group/garglk-dev/browse_thread/thread/cdd4cd... Essentially, by setting certain variables on the command line when Jam compiles, you can control the destination of the library, the interpreter binaries, and the launcher script. This prevents filename clashes with other software of the same name - the source control Git, as well as other IF interpreters. [/quote] I can't fix ebuild to do this, so please, help me. After that fix geas patch will not be needed.
*** Bug 265485 has been marked as a duplicate of this bug. ***
Created attachment 187837 [details] Another proposed ebuild
I added another ebuild, based on my earlier proposal, but merging in Yaroslav's changes (removed dependencies, added sdl USE flag). The merit of my proposal is that it installs all libraries into /usr/libexec/gargoyle/ and symlinks to them in /usr/bin (e.g. /usr/bin/gargoyle-git links to /usr/libexec/gargoyle/git). This removes the need to patch the Jamfile, satisfies upstream's requests to keep the interpreter names unchanged, but still allows us to add the prefix so users can call interpreters directly while avoiding file name clashes with other tools. I hope at least one of the proposed ebuilds can finally be added; all of them are better than what we have now. If there are problems why none of these can be added, at least speak up, but don't silently ignore volunteers attempting to contribute to the project.
I want to add that svn version can install executables: For a system-wide install, the following three steps should place the binaries, shared library, and configuration file in appropriate locations. However, please verify that the referenced paths actually exist before you proceed. 1. jam -s EXEMODE=755 -s FILEMODE=755 \ -s _BINDIR=/usr/local/libexec/gargoyle \ -s _APPDIR=/usr/local/libexec/gargoyle \ -s _LIBDIR=/usr/local/lib/gargoyle \ install 2. ln -s /usr/local/libexec/gargoyle /usr/local/bin/gargoyle 3. cp garglk/garglk.ini /etc/garglk.ini So when developers release new version, ebuild will be very trivial
@Yaroslav: that doesn't solve the problem of symlinking the binaries, and I guess you should include ${D} in the installation paths, but otherwise that would work too. I don't care much which ebuild is comitted exactly, as long as one gets comitted. Something else to consider: even when I install without the sdl use flag, I see direct dependencies on the following libraries: atk, fontconfig, cairo, pango. Unless these are guaranteed to be pulled in by some of the other libraries, these should probably be added to the list of library dependencies.
@Maks: Yes, symlinks must be added by ebuild, but other tasks IMHO must be done in official way. fontconfig, atk, cairo, pango, fontconfig are deps of gtk+, and gargoyle doesn't depends on it (no such words in sources :), so we have no need to include these deps.
And I don't care which ebuild is commited, too :)
And I mean that gargoyle doesn't depend on cairo etc, not gtk+
What's the status of this? Would love to see a fresh gargoyle version hit the official portage tree. Thanks.
There is new version, gargoyle-2009-08-25
Created attachment 202282 [details] ebuild for new version
Please change summary to "games-engines/gargoyle version bump (2009-08-25)"
The biggest problem with the submitted ebuilds so far is that they don't respect the GAMES_* variables from games.eclass.
Created attachment 216248 [details] Updated ebuild using the games eclass
Created attachment 216249 [details, diff] Patch errors in glk.h, needed to build the August 2009 release.
Created attachment 216251 [details, diff] Rename getline to build the August 2009 release
(In reply to comment #23) > The biggest problem with the submitted ebuilds so far is that they don't > respect the GAMES_* variables from games.eclass. True. I've added an updated ebuild that uses the games eclass, so everything goes under /usr/games as it should.
more comments: should use EAPI=2 needs local terp in src_install dodir is unneeded in src_install call epatch once use edos2unix instead of sed for ini file (and inherit eutils) error check all seds sort KEYWORDS
Created attachment 236303 [details] Updated based on comments. I intend to run this through sunrise QA for potential inclusion there. This ebuild uses bundled interpreters - it would be better (if much more work) to add each individual interpreter to portage rather than use the versions shipping with gargoyle.
Created attachment 236305 [details] Updated following repoman.
> I intend to run this through sunrise QA for potential inclusion there. That sounds great. I would still very much like to see a good IF player in portage so Sunrise would be a good start. Your latest revision of the ebuild looks perfect, except I don't see the need to quote $terp when it's pretty clear that all terp names are simple words, but OK. > This ebuild uses bundled interpreters - it would be better (if much more work) > to add each individual interpreter to portage rather than use the versions > shipping with gargoyle. I agree. In that case it would probably be best to create a separate ebuild for the garglk library, have an ebuild for every terp that depends on it, and have a master ebuild (with a lot of USE flags) that just depends on the individual ebuilds and installs the wrapper script. The garglk library itself could already support more USE flags to dynamically select sound and image support and such, I think. It might be even nicer if the GLK library could be selected at-runtime with eselect, but that may well be more work than it's worth, especially since I don't think there are any competing GLK libraries for Linux in portage yet. If you want to discuss this further, you can probably catch me in #gentoo-sunrise on Freenode, though I would much prefer having the current ebuild committed rather than discussing options for another six months. :-)
Created attachment 237181 [details] updated ebuild Updated ebuild - removing unneccessary patching + other fixes suggested in #gentoo-sunrise. Works, but still has some TODOs. I won't be able to work on it for immediate future, uploading so someone else can carry the torch. (may be ready for sunrise as-is) Updated LICENSE to cover bundled interpreters - needs new licenses (will attach) Also needs luximono license (already in sunrise) Added USE="fmod" (disabled by default) Enabled debug build so that portage can strip.
Created attachment 237183 [details] gargoyle meta-license
Created attachment 237185 [details] hugo license
Created attachment 237187 [details] metadata
Any news here?
(changed bug summary to match latest version)
Are the remaining patches still necessary?
(In reply to comment #38) > Are the remaining patches still necessary? The two patches that I submitted have been retrofitted into the stable branch by the upstream maintainer (Ben Cressey) so these are no longer necessary. James' latest version of the ebuild doesn't include them and works for me (though I haven't tested all interpreters). Also re: James' comments in the ebuild: > games-engines/frotz interpreter is already in portage > games-engines/frobtads is in portage, not sure if it can replace > included tads2/tads3 interpreter. frotz and frobtads in portage are curses-based console versions of the interpreters. The versions distributed with Gargoyle have been patched to use Glk and use the Gargoyle library to provide a graphical (though obviously still text-based) interface to the interpreters. From an end-user perspective the two are very different, so I think they should be maintained independently in portage. (For comparison: the difference is like that between gdb and ddd.)
Created attachment 249228 [details] Preliminary ebuild for 2010.1 Comments/fixes are welcome. I've only tested this with default USE-flags so far.
Created attachment 249440 [details] Updated ebuild - Fixed various bugs in the ebuild. - Changed to use external fonts which provide better language support and which can be installed from portage, instead of compiling Bitstream Mono and Luxi Sans into the library. - Install a desktop entry and application icon.
Created attachment 249491 [details] Updated ebuild - Removed hopelessly broken fmod USE flag; SDL is much better anyway. - Removed need to patch the launcher by installing it with the terps. - Updated RDEPEND so all dependencies are there (and removed glib) Tested on ~x86 and ~amd64 with and without USE=sdl and it all works. Sound and fancy fonts work like they are supposed to.
Created attachment 250207 [details] Revamped ebuild for gargoyle 2010.1 Hi, please use the gargoyle ebuild I just commited here. I consider it ready for inclusion in Portage save from luximono license, which is still missing. Changes from your ebuild: - changed ebuild version to 20100930 (otherwise old version in Portage is seen as newer than this) - added some work to make ebuild honour Gentoo LDFLAGS If you are able to provide a license for luximono, I think I shall commit it to Portage.
Michele, Thanks for posting; your ebuild is indeed an improvement over the last one I posted here, but I made a few changes locally since that I think should be considered for inclusion as well. If I read it correctly, your version differs from the previous one I posted here in the version number (about which I don't particularly care -- I've masked the 2009 ebuilds to ensure the new version gets installed even if it is called 2010.1) and the inclusion of linker flags (which I forgot, but have since fixed). The most important updates in the new ebuild that I will attach are as follows: 1) I went over the bundled interpreters and updated the LICENSE line accordingly. However, the licensing status for some of them isn't very clear, except that upstream promises that everything is "freely distributable". It's dubious that libgarglk (licensed GPL-2) is dynamically linked to BSD and MIT licensed code, although for Gentoo that is probably OK, since everything is compiled from source code and the resulting binaries are not distributed. (But maybe we need to restrict building packages from this ebuild?) 2) I changed the fonts from being bundled with the interpreter to installing Liberation and Libertine fonts as dependencies. Note that the default config references these fonts too (even though they are not part of the Gargoyle distribution). This takes care of the font licensing problem, saves 250KB or so in libgarglk.so (the new dependencies take space too, of course, but at least they are shared) and gives players better support for foreign languages. (I made this change after noticing the Aotearoa didn't run correctly with the current ebuild).
Created attachment 250223 [details] Latest version on my end.
Created attachment 250225 [details] Glulxe license
(In reply to comment #44) > Michele, > > Thanks for posting; your ebuild is indeed an improvement over the last one I > posted here, but I made a few changes locally since that I think should be > considered for inclusion as well. Marks, I'll probably be fine with whatever changes you still want to make before adding the new package version to Portage. What I'm asking for is, please, merge your work with my ebuild and use it for any subsequent change you make. Otherwise in the end I'll have to make my changes again, and I'm short on free time... > If I read it correctly, your version differs from the previous one I posted > here in the version number (about which I don't particularly care -- I've > masked the 2009 ebuilds to ensure the new version gets installed even if it is > called 2010.1) and the inclusion of linker flags (which I forgot, but have > since fixed). Linker flags have not been fixed. Package won't honour Gentoo linker flags without my modifications, you don't normally notice because probably package linker flags are equal to Gentoo default ones. If you change Gentoo linker flags in your /etc/make.conf you will notice that. Cannot provide you the actual flags to test this since I'm not on my Gentoo box now. For the rest, I'm fine with whatever changes you will want to include.
Just FYI ... I've been lurking on this bug as an interested gargoyle user. I'll be happy to test ebuilds or help in any way I can. I maintain a number of gentoo boxes, not wildly different, but enough so to be useful for testing. I'm also anxious to grow my ebuild skillset, so if there are any non-blackbelt tasks involved, please describe. I'm excited about finally seeing gargoyle in portage. Thanks to all involved for their hard work.
(In reply to comment #47) > What I'm asking for is, please, merge your work with my ebuild and use it for > any subsequent change you make. I understand, and I try to. I thought I had everything covered, but I see now that I missed SHRLINKFLAGS which is used (only) when linking libgarglk.so. Since you seem to prefer to stick to the YYYYMMDD version numbering scheme even though upstream changed the format for their release, I've changed that too. (In reply to comment #48) > I'll be happy to test ebuilds or help in any way I can. If you haven't already, just stick it an overlay and see if it works for you or you find anything broken/missing. Suggestions for are improvement are always welcome!
Created attachment 250387 [details] Updated version that links correctly.
(In reply to comment #49) > I understand, and I try to. Thanks :-) > I thought I had everything covered, but I see now > that I missed SHRLINKFLAGS which is used (only) when linking libgarglk.so. OK, sounds good > Since you seem to prefer to stick to the YYYYMMDD version numbering scheme even > though upstream changed the format for their release, I've changed that too. Actually, I prefer the new naming scheme, which unfortunately is incompatible with the old one. Since I cannot add this version to Portage and contextually remove the old one, I have to use the old naming scheme. Only when the new version is stabilized (a month after inclusion if no outstanding bugs come out), I'll remove the old one and change the naming scheme. Please, tell me as soon as you think the ebuild is ready for inclusion in Portage.
(In reply to comment #48) > I'll be happy to test ebuilds or help in any way I can. Welcome aboard, I'll be happy to have someone to test gargoyle as soon as it enters Portage :-)
(In reply to comment #51) > Please, tell me as soon as you think the ebuild is ready for inclusion in > Portage. I've tested this ebuild with the different combinations of USE flags on ~amd64 and ~x86, and I haven't encountered any problems, though I only tested with Glulxe and Z-code games. From a technical point of view, I would say it is ready (but maybe David Hostetler would like to test too). The only dubious part, I think, is which licenses apply, though it seems mostly a theoretical issue. In any case it didn't prevent the previous version from being committed. So if you don't see any objections in that regard, I don't either.
(In reply to comment #53) > I've tested this ebuild with the different combinations of USE flags on ~amd64 > and ~x86, and I haven't encountered any problems, though I only tested with > Glulxe and Z-code games. From a technical point of view, I would say it is > ready (but maybe David Hostetler would like to test too). Cool :-) > The only dubious part, I think, is which licenses apply, though it seems mostly > a theoretical issue. In any case it didn't prevent the previous version from > being committed. So if you don't see any objections in that regard, I don't > either. It seems to me you did a good enough job at identifying the various licenses. From my point of view, we can wait a hundred years in order to get everything perfect, or we can commit the package now and then fix any issue that may arise ;-)
New version of Gargoyle is in Portage, ready for testing. Please test and hunt down bugs ;-) Thanks to everyone who did contribute here, I did nothing but harvesting the fruits...