Behold! A Gentoo Ebuild: The Time Is at Hand

[leycec]

Lo, and it arises in the West.

Gentoo now has a working (albeit, unofficial) ToME 4 beta 41 ebuild on overlay raiagent. I estimate full installation including download time and transitive dependencies (e.g., SDL 2.0) to require roughly an hour and 400MB of free space. Your mileage may vary. ("On with the dreary show, you rogue!")

Installation instructions follow.

EDIT: Wiki article "Gentoo" now offers authoritative installation instructions summarizing this and the posts below. Unless you enjoy stumbling in the dark, in which case... read on, my pointy-hatted friend. Read on.

Code: Select all

# Install "layman", if you haven't already.
emerge -av layman
echo "source /var/lib/layman/make.conf" >> /etc/make.conf

# Add the "raiagent" overlay.
layman -o https://raw.github.com/leycec/raiagent/master/overlay.xml -f -a raiagent
layman -S

# Add helpful SDL USE flags. (Optional.)
echo "media-libs/libsdl xinput xrandr" >> /etc/portage/package.use

# Unmask "tome4" and friends.
echo ">=media-libs/libsdl-9999\n>=media-libs/sdl-image-9999\n>=media-libs/sdl-ttf-9999\n>=games-roguelike/tome4-1.0.0_beta1" >> /etc/portage/package.accept_keywords

# Install "tome4" and friends.
emerge -av tome4

By default, ToME4 installs with music. If you'd like to install without the official ToME4 soundtrack (saving about 200MB on download and installation at the cost of Blood God Shibboleth vengefully mauling a baby kitten), either:

Code: Select all

# Add "-music" to the ToME4-specific USE flags.
echo "games-roguelike/tome4 -music" >> /etc/portage/package.use

# Or, add "-music" to the global USE flags. (You might not want to do this.)
vi /etc/make.conf

# Reinstall.
emerge -av tome4

raiagent also hosts a working beta 42 ebuild. "Then why all the beta 41," you snarl? Well, my furry friend. Beta 42 "works" only in the sense of correctly installing. It installs. But it doesn't really run. Severe stability issues currently plague OS X and Linux. (That's us.) Grep the Bugs forum for "Particle emitter error." (Have fun with that.)

For his and her protection, I've hard-masked beta 42. If you still feel like dancing with death, you'll need to unmask it and reinstall "tome4". And did I mention? The tarball is about 60MB larger.

Code: Select all

# Unmask beta 42.
echo "=games-roguelike/tome4-1.0.0_beta42" >> /etc/portage/package.unmask

# Reinstall.
emerge -av tome4

Like ToME4 itself, this ebuild and friends (yes, SDL 2.0: I'm glaring at you) was the work of consummate neurosis, unyielding depravity, and many manly long slow burns of the midnight oil. In other words, let me know if you like it. Or hate it. Hate is nice. [Ed.: Only for the Afflicted. [Ed. ed.: Does that mean... I'm... Afflicted? Oh, God.]]

May darkgod have mercy on our "sed"-patched builds. Let the games begin.

P.S., @darkgod. Please consider not depending on SDL daily builds for future releases, following the official release of SDL 2.0. Daily build dependencies make Gentoo a sad solipsistic panda. Err, penguin.

EDIT: I'd like to add these instructions to the wiki but don't appear to have edit access. (That or I just can't find the "Edit" button. Oh, how I looked.) Since "http://te4.org/node/346/edit" gives "You are not authorized to access this page," I suspect it's the former. Call me fanciful, but isn't public writability the de facto definition of a wiki? If anyone with edit access could replace the existing (and very much non-working) Gentoo Linux instructions with these or even just link to this thread, the community would direly appreciate it. Cheers!

EDITEDIT: Ignore the prior EDIT. I wasn't logged in. Yes, insert foot in mouth here. If you need me, I'll be self-flagellatting myself behind the bleachers with a demonic dark axe of Kroll. You know the one.

[Vee]

Code: Select all

* This package will overwrite one or more files that may belong to other
 * packages (see list below). You can use a command such as `portageq
 * owners / <filename>` to identify the installed package that owns a
 * file. If portageq reports that only one package owns a file then do
 * NOT file a bug report. A bug report is only useful if it identifies at
 * least two or more packages that are known to install the same file(s).
 * If a collision occurs and you can not explain where the file came from
 * then you should simply ignore the collision since there is not enough
 * information to determine if a real problem exists. Please do NOT file
 * a bug report at http://bugs.gentoo.org unless you report exactly which
 * two packages install the same file(s). Once again, please do NOT file
 * a bug report unless you have completely understood the above message.
 * 
 * Detected file collision(s):
 * 
 *      /usr/bin/showimage
 *      /usr/lib/debug/usr/bin/showimage.debug
 * 
 * Searching all installed packages for file collisions...
 * 
 * Press Ctrl-C to Stop
 * 
 * media-libs/sdl-image-1.2.12
 *      /usr/bin/showimage
 *      /usr/lib/debug/usr/bin/showimage.debug
 * 
 * Package 'media-libs/sdl-image-9999' NOT merged due to file collisions.
 * If necessary, refer to your elog messages for the whole content of the
 * above message.

Though I don't think showimage is really needed for tome4. I'll try to hack my way around it... maybe work with ebuild and not emerge, and remove showimage right before merging...

[edge2054]

EDIT: I'd like to add these instructions to the wiki but don't appear to have edit access. (That or I just can't find the "Edit" button. Oh, how I looked.) Since "http://te4.org/node/346/edit" gives "You are not authorized to access this page," I suspect it's the former. Call me fanciful, but isn't public writability the de facto definition of a wiki? If anyone with edit access could replace the existing (and very much non-working) Gentoo Linux instructions with these or even just link to this thread, the community would direly appreciate it. Cheers!

Were you logged in? I think that's the only requirement for wiki edits. (It is a public wiki, if you logged in and it didn't let you edit we'll need to bug Darkgod about it when he gets back).

[tiger_eye]

Wonderful post, leycec, and anything you add to the wiki would be greatly appreciated!

[leycec]

@Vee Woops! Good catch. I blame the bug gnomes, damn their wee black hearts.

"showimage" and "showfont" are silly test binaries and arguably shouldn't be installed (or even built) by default. I've shifted both to USE flags. If you haven't already hacked around it, the latest ebuilds should fix you up:

Code: Select all

# Get the updated ebuilds.
layman -S

# Let's try again!
emerge -av sdl-image:2 sdl-ttf:2

[leycec]

@edge2054 That was it. Either you're certifiably genius or I had too much grog last night.

[Vee]

I just removed the binary between install and merge phases of the ebuild...

Another hopefully useful point:
Although portage 2.1.x accepts keyword-expressions without the keyword to accept, 2.2.0 and later expect them. so:

Code: Select all

=category/package-version ~x86
                           ^^^-- cannot be omitted (any longer)!

No idea if that '\n' works, I just put real linebreaks in there.

PS: Now I just need the hardware to not have those particles make tome lag...

[Grahammm]

I have tried this but b41 & b42 both segfault in the same place. The 'black' SDL window opens briefly without displaying anything and then it segfaults. During the build I noticed a few warnings - warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]. I am running 64bit.

The last few lines on the console are

Creating module example_realtime :: (as dir) true :: (as team) nil
Loaded module definition for example_realtime-1.0.0 using engine te4-0.9.42
Creating module tome-0.9.42.team :: (as dir) false :: (as team) 12
Loaded module definition for tome-0.9.42 using engine te4-0.9.42
tome boot
example tome
boot example
example_realtime boot
boot example_realtime
boot tome
example example_realtime
* Module: tome
** 0.9.42
* Module: boot
** 0.9.40
* Module: example
** 1.0.0
* Module: example_realtime
** 1.0.0
After fs.reset
[1] = {
[path] = /usr/share/tome4//game/engines/te4-0.9.42.teae
}
[ENGINE] Switching to turn based
Loading savefile /save//
Loading savefile /save/player/
/usr/bin/tome4: line 3: 15541 Segmentation fault ./t-engine

[leycec]

I just removed the binary between install and merge phases of the ebuild...

That works too.

Another hopefully useful point:
Although portage 2.1.x accepts keyword-expressions without the keyword to accept, 2.2.0 and later expect them. so:

Code: Select all

=category/package-version ~x86
                           ^^^-- cannot be omitted (any longer)!

No idea if that '\n' works, I just put real linebreaks in there.

Interesting. Being innately cautious ("O brave, brave Sir Leycec!"), I'm still on stable Portage. I'll add a note above.

That said, while I don't doubt you... are you dead sure about this? Neither the Gentoo Handbook (http://www.gentoo.org/doc/en/handbook/h ... t=3&chap=3), Gentoo Wiki (http://en.gentoo-wiki.com/wiki/Portage), or Gentoo Forums (from what I've hastily crawled through) mention such breaking changes. While Portage 2.2.x always did like life in the fast lane, I suspect the eventual Portage 2.3.x to permit keywordless atoms. Prohibiting keywordless atoms breaks backwards compatibility with Portage 2.1.x installations, which is most of them. Where's the upside? Less ambiguity when cross-compiling, I suppose?

PS: Now I just need the hardware to not have those particles make tome lag...

Since you run on the wild side, I'm sure you've already tried this: but have you taken a look at the "Particle effects density" option under "Video Options"?

[leycec]

@Grahammm Ugh. Ghg. Hgu. Orc leycec say, "That suck, bro."

darkgod seems to be out of the house at the moment. This bug's probably in his court, I'm afraid. Beta 41's been running stably on my amd64 machine for a few days now, which makes diagnosing your fatal error somewhat challenging. (Like, stab me in the eye with a mallet challenging.)

But there's still a bit we can work through. A few questions:

• Is your system fairly up-to-date? Specifically, when was the last time you gave "emerge -uDNav world" a go? It's a long shot, but it's easy and (occasionally) resolves stability concerns.
• Are you running a non-multilib 64-bit installation (i.e., a pure 64-bit installation with no support for 32-bit libraries or executables)? If so, that might be your culprit. Of course, switching from non-multilib to multilib and vice versa isn't exactly a trivial affair. [Read: There Be Deep Dragons Here.]
• Are you running aggressive "CFLAGS", "CPPFLAGS", "CXXFLAGS", or "LDFLAGS"? If so, try backing off a bit. (I've been running CFLAGS="-march=k8-sse3 -O2 -pipe" to good effect.) Then recompile ToME4 and friends:

  Code: Select all

  # Got popcorn? Good. You'll need it.
  emerge -aev tome4
  

• Did you emerge "libsdl", "sdl-image", and/or "sdl-ttf" with USE flags I haven't tested yet? Specifically, one or more of the following: altivec aqua directfb fusionsound gles nas oss pulseaudio static-libs tslib xinerama xvidmode? My current USE flags for all three are as follows:

  Code: Select all

      media-libs/libsdl:2 3dnow X alsa joystick mmx opengl sse sse2 threads xinput xrandr xscreensaver -altivec -aqua -directfb -fusionsound -gles -nas -oss -pulseaudio -static-libs -tslib -xcursor -xinerama -xvidmode
      media-libs/sdl-image:2 gif jpeg png tiff webp xpm -showimage -static-libs
      media-libs/sdl-ttf:2 X -showfont -static-libs
  

• If you're still dumping core, I'm afraid it's probably ToME4's fault. But you can still help out, should you choose to accept this arduous and largely unfulfilling quest. Here's how:
• Add "-ggdb" to CFLAGS in "/etc/make.conf" to enable gdb backtracing (e.g., CFLAGS="-march=k8-sse3 -O2 -ggdb").
• Add "splitdebug" to FEATURES in "/etc/make.conf" to disable gcc stripping (e.g., FEATURES="candy ccache multilib-strict strict splitdebug").
• Add "multilib-strict" to FEATURES as well, as a sanity check.
• Ensure the "debug" USE flag is not enabled in "/etc/make.conf". (You should either have "-debug" or no "debug" at all.)
• Recompile ToME4 and friends. (You know the score.)

  Code: Select all

  # Better get some more popcorn.
  emerge -aev tome4
  

• Enable core dumps (General Setup ---> Configure standard kernel features ---> Enable ELF core dumps) in your kernel configuration (e.g., "cd /usr/src/linux; make menuconfig").
• Recompile your kernel (e.g., "cd /usr/src/linux; make && make modules_install").
• Reset. Congratulations! You can now get ToME4 to produce a core dump. It's not as fun as actually playing ToME4... but it's something.
• Run:

  Code: Select all

  # Temporarily enable core dumps for this shell session.
  ulimit -c unlimited
  
  # ToME4, ya!
  cd /usr/share/tome4
  ./t-engine
  
  # Log the backtrace of the core dump to "crash.txt".
  gdb t-engine --core "whatever-the-core-dump-is-called" --batch --quiet -ex "thread apply all bt full" -ex "quit" > crash.txt
  

• Post "crash.txt" to the "Bugs" forum. Phew! Your tireless efforts are a lesson for us all.

EDIT: Trolling briefly through the "Bugs" forum, I tripped across a number of related posts on "Segmentation faults": http://forums.te4.org/viewtopic.php?f=42&t=31264 and http://forums.te4.org/viewtopic.php?f=44&t=31455. The PNG interface in "sdl-image" seems to be a popular culprit. Have you disabled the "png" USE flag perhaps? If so, that'd probably be it.

[Grahammm]

The problem turned out to be Gentoo related rather than Tome. It needed the MPROTECT PaX flag set on t-engine.

[leycec]

The problem turned out to be Gentoo related rather than Tome. It needed the MPROTECT PaX flag set on t-engine.

Nice sleuthing. For the desperately curious amongst us (you're out there! I can feel you), the ToME4 build system enables a LuaJIT 2 compiler by default. If enabled, ToME4 runs LuaJIT 2 running machine code assembled in-memory and hence violating MPROTECT restrictions under PaX-hardened kernels.

I've updated the ToME4 ebuilds to account for this, adding a new "jit" USE flag enabled by default. If enabled, we install the LuaJIT 2 compiler and disable MPROTECT restrictions on the resulting "t-engine" binary; otherwise, we install a non-JIT Lua interpreter (which under PaX-hardened kernels should run under MPROTECT restrictions without error).

Sadly, I haven't made the inevitable switch to a Hardened profile yet. (Probably due to just such issues. I'm also lazy. Really, really lazy.) While I can't test my own changes, I feel 100% confident that absolutely nothing could possibly go wrong.

[darkgod]

Well just passing by to thank you for your efforts! Many thanks!

[Grahammm]

[quote="leycec"I've updated the ToME4 ebuilds to account for this, adding a new "jit" USE flag enabled by default. If enabled, we install the LuaJIT 2 compiler and disable MPROTECT restrictions on the resulting "t-engine" binary; otherwise, we install a non-JIT Lua interpreter (which under PaX-hardened kernels should run under MPROTECT restrictions without error).[/quote]

I have now tried the new ebuild. With the jit USE flag it works OK. Without the jit flag it segfaults as it still needs MPROTECT disabling.

[leycec]

I have now tried the new ebuild. With the jit USE flag it works OK. Without the jit flag it segfaults as it still needs MPROTECT disabling.

Thanks for giving it a go, Grahammm. That's... odd. Perhaps ToME4 itself executes in-memory assembly irrespective of Lua JIT? I'll disable MPROTECT across the board and add a "FIXME" comment. Perhaps I'll even fix it, someday.