Behold! A Gentoo Ebuild: The Time Is at Hand

[leycec]

Bump. Overlay raiagent now supports the recently released and much anticipated beta 43. Go grab some fun!

If you receive fatal errors during compilation resembling:

Code: Select all

    ../src/physfs/physfsrwops.c:161:19: error: ‘SDL_RWops’ has no member named ‘size’

Just update SDL2 and cohorts, and try again:

Code: Select all

    emerge -av libsdl:2 sdl-image:2 sdl-ttf:2 tome4

[darkgod]

Thanks !

[leycec]

Thank you, darkgod. I'm just the delivery boy.

[lenocinor]

Bump. Overlay raiagent now supports the recently released and much anticipated beta 43. Go grab some fun!

If you receive fatal errors during compilation resembling:

Code: Select all

    ../src/physfs/physfsrwops.c:161:19: error: ‘SDL_RWops’ has no member named ‘size’

Just update SDL2 and cohorts, and try again:

Code: Select all

    emerge -av libsdl:2 sdl-image:2 sdl-ttf:2 tome4

Hey leycec: I'm getting this exact same error while trying to compile b43 for OS X currently. How did you fix this problem?

[greycat]

SDL_RWops comes from libSDL2 daily snapshots that are newer than some unknown date. The version that worked for beta42 (which called itself libSDL 1.3) won't work for beta 43. You'll also need Mercurial snapshots of SDL_image and SDL_ttf (unlike beta 42, which could use the stable releases of those even with libSDL 1.3).

When in doubt, it wouldn't be a bad idea to completely remove ALL the SDL libraries and start from a blank slate. It's really easy to get stuck in a weird state where you're pulling headers from one version but linking against libraries from another version.

[leycec]

Thanks for the helpful reply, greycat. Succinctly stated and spot on the money. I'm afraid source-based ToME4 compilation will continue to be a bit of a bear (...err, cat?) until SDL officially releases version 2.0. Until then, we're in the unenviable position of having to build against the moving goal post of a live Subversion repository. While I appreciate darkgod's forward-thinking decision to go this way, it does... complicate compilation.

Incidentally, Gentoo overlay raiagent now provides Tales of Maj'Eyal 1.0.0RC3 aka "Game of Candidates". As ever, I heartily recommend rebuilding SDL2 and cohorts before upgrading ToME4:

Code: Select all

emerge libsdl:2 sdl-image:2 sdl-ttf:2 tome4

Be safe, chronomancing Christmas revelers!

[leycec]

Thanks to the dastardly duo (i.e., FTL and Cataclysm: DDA), I appear to have missed a few world-shattering updates.

To amend my lamentable ways, I've bumped the ebuild to support ToME4 1.0.3: A New Dawn. If upgrading from an older version, you'll probably confront a merge conflict. Overlay gamerlay now gratefully hosts the SDL2 ebuild, which has thus been masked in overlay raiagent. To resolve the conflict, subscribe to "gamerlay" (if you haven't already), update all overlays, explicitly uninstall and reinstall SDL2, and upgrade ToME4: e.g.,

Code: Select all

layman -a gamerlay
layman -S
emerge -C libsdl:2
emerge libsdl:2 sdl-image:2 sdl-ttf:2 tome4

As ever, let me vociferously know if you have any difficulties.

[darkgod]

Thanks

[hasufell]

Those ebuilds have a few issues including incorrect dependencies, segfaults at game start and some QA issues.

We might add tome4 to the official gentoo tree if the situation improves
See:
http://forums.te4.org/viewtopic.php?f=42&t=38712
http://forums.te4.org/viewtopic.php?f=42&t=38713
http://forums.te4.org/viewtopic.php?f=42&t=38714
http://forums.te4.org/viewtopic.php?f=42&t=38715
http://forums.te4.org/viewtopic.php?f=42&t=38716
http://forums.te4.org/viewtopic.php?f=42&t=38718

and the gentoo bug report
https://bugs.gentoo.org/show_bug.cgi?id=387061

until then I maintain it in my dev overlay:
https://github.com/hasufell/hasufell-ov ... like/tome4

send pull requests there. Also mind that I do not consider overlays such as "gamerlay" safe. They have caused a lot of problems for users during the ABI eclass migration and have added crucial system libs such as SDL2 without knowing that it can break stuff for users, because they have not coordinated any of that with the official tree.
When using such overlays follow this:
https://wiki.gentoo.org/wiki/Overlay#Us ... e_overlays

Using dev overlays should be fairly safe. An alternative is sunrise the official user overlay where every ebuild gets a dev review:
http://overlays.gentoo.org/proj/sunrise

Before you create your own overlay and start pushing stuff there without knowing if it adheres to ebuild writing standards etc consider really contributing to gentoo, as in: open bug reports with attached ebuilds, ask for review in #gentoo-dev-help beforehand or contribute to #gentoo-sunrise as mentioned before. Alternatively become a gentoo dev. If all that fails, then your own overlay should be the last resort, never the first.

[hasufell]

It seems the Tome4 developer has no interest in fixing any of those bugs.

[Zireael]

It seems the Tome4 developer has no interest in fixing any of those bugs.

The developer has been busy working on other bugs, as far as I know.

[leycec]

Thanks for the heads-up, all! And especially Gentoo developer hasufell. In the interests of consistency, I've updated the raiagent ebuild with hasufell's helpful changes. Given hasufell's enthusiasm for adopting the ebuild, however, I'm happy to officially hand it over. While both the raiagent and hasufell ebuilds now provide equivalent functionality and reliability, users should consider switching to hasufell's ebuild for future patches and support. A hearty thanks.

And on a very tangentially related note having nothing whatsoever to do with ToME4 —

There does appear to be a growing disconnect between third-party Gentoo overlay developers (e.g., on gamerlay) and official Portage developers. While overlay developers tend to favor decentralized technologies (git, github.com, zugaina.org) and governance structures (consensus-based collectivist, anarchist, or even infoanarchist, at least in practice), Portage developers tend to favor centralized technologies (CVS, Portage, gentoo.org) and governance structures (conventional non-profit hierarchicalism – complete with requisite quizzes, bureaucracy, and factionalism). Neither are wrong. In fact, both are essential. But the divergence between unofficial and official Gentoo developers in intention, implementation, and scope does tend to render discussion between the two camps somewhat... well, discordant.

I have no good solution. I don't think anyone does. Portage's eventual migration to git should smooth over a few of these differences. But is a mere technology upgrade enough? We might want to contemplate a community "upgrade" as well.

I authored the original libsdl:2, sdl-image:2, and sdl-ttf:2 ebuilds later adopted by gamerlay, so I'm fairly close to the source of the issue. No one contacted me at any step in the process. (That would have been nice.) While I'm content with the eventual resolution, the contention it caused could probably have been averted at an earlier stage of the development cycle. But again: no one's to blame. A difference in values between official and unofficial developers invariably stymies communication.

Incidentally, the Gentoo wiki article appears to have either been deleted or failed to make the transition over to the new wiki. The article was fairly comprehensive and only slightly out-of-date. I was hoping to update it. Anyone know where it shuffled off to?

tl;dr
raiagent's ToME4 1.0.4 ebuild is now up-to-date, but will probably not be updated in the future. Please add hasufell's overlay to receive future updates.

[Grahammm]

I have just tried building from hasufell's overlay but get the following errors.

Code: Select all

Building configurations...
Running action 'gmake'...
Generating Makefile...
Generating build/TEngine.make...
Generating build/physfs.make...
Generating build/luadefault.make...
Generating build/luasocket.make...
Generating build/fov.make...
Generating build/lpeg.make...
Generating build/luaprofiler.make...
Generating build/tcodimport.make...
Generating build/expatstatic.make...
Generating build/lxp.make...
Generating build/luamd5.make...
Generating build/luazlib.make...
Generating build/luabitop.make...
Generating build/te4-bzip.make...
Done.
sed: can't read build/buildvm.make: No such file or directory
sed: can't read build/minilua.make: No such file or directory
 * ERROR: games-roguelike/tome4-1.0.4::hasufell failed (configure phase):
 *   premake sucks
 * 
 * Call stack:
 *     ebuild.sh, line  93:  Called src_configure
 *   environment, line 2673:  Called die
 * The specific snippet of code:
 *       sed -i -e 's~^[        ]*LINKCMD.*$~LINKCMD = $(CC) $(CFLAGS) -o $(TARGET) $(OBJECTS) $(RESOURCES) $(LDFLAGS) $(LIBS)~' build/{buildvm,minilua,TEngine}.make || die "premake sucks"
 * 

[hasufell]

I have just tried building from hasufell's overlay but get the following errors.

Code: Select all

Building configurations...
Running action 'gmake'...
Generating Makefile...
Generating build/TEngine.make...
Generating build/physfs.make...
Generating build/luadefault.make...
Generating build/luasocket.make...
Generating build/fov.make...
Generating build/lpeg.make...
Generating build/luaprofiler.make...
Generating build/tcodimport.make...
Generating build/expatstatic.make...
Generating build/lxp.make...
Generating build/luamd5.make...
Generating build/luazlib.make...
Generating build/luabitop.make...
Generating build/te4-bzip.make...
Done.
sed: can't read build/buildvm.make: No such file or directory
sed: can't read build/minilua.make: No such file or directory
 * ERROR: games-roguelike/tome4-1.0.4::hasufell failed (configure phase):
 *   premake sucks
 * 
 * Call stack:
 *     ebuild.sh, line  93:  Called src_configure
 *   environment, line 2673:  Called die
 * The specific snippet of code:
 *       sed -i -e 's~^[        ]*LINKCMD.*$~LINKCMD = $(CC) $(CFLAGS) -o $(TARGET) $(OBJECTS) $(RESOURCES) $(LDFLAGS) $(LIBS)~' build/{buildvm,minilua,TEngine}.make || die "premake sucks"
 * 

I'm unable to reproduce that, please report here https://github.com/hasufell/hasufell-overlay/issues with "emerge --info" and _full_ build log

[hasufell]

I have no good solution. I don't think anyone does. Portage's eventual migration to git should smooth over a few of these differences. But is a mere technology upgrade enough? We might want to contemplate a community "upgrade" as well.

Depending on how it will be implemented it may improve workflow (or not...). In the end... it will not be hosted on github or anything like that, so you still end up doing the manual thing which is not that much different from attaching an ebuild to a bug report.
It will also not change the attitude of the fire-and-forget fraction.

I authored the original libsdl:2, sdl-image:2, and sdl-ttf:2 ebuilds later adopted by gamerlay, so I'm fairly close to the source of the issue. No one contacted me at any step in the process. (That would have been nice.) While I'm content with the eventual resolution, the contention it caused could probably have been averted at an earlier stage of the development cycle. But again: no one's to blame. A difference in values between official and unofficial developers invariably stymies communication.

gamerlay has caused us devs a lot of trouble, because people do not ask us about what to do and end up hacking system libraries without knowing what it can cause for other users.

No one I know from gamerlay ever cared to collaborate. I don‘t waste time on people who show little interest in getting reviews and improving their ebuild skills (I'm sorry, but that is a soft spot). Those who actually want to contribute can read up here: http://forums.gentoo.org/viewtopic-t-970998.html

As mentioned in that link... packaging does not work well if decentralized. That is a fact and is proven by experience and bug reports.
We want help, but we require some motivation and thoroughness.