A new version of freepops is out, although I was unable to get the ebuild working. The new version doesn't seem to need the patch (the changes are already present in the source, and they've mentioned gentoo in their CVS logs). For some reason the new version seems to embedd the portage work directory in the executable and it goes looking for the LUAs in /var/tmp/portage... I'm not sure how that is happening. The executable does not contain them after the compile step, but it seems to recompile on the install step and that is when you can find the string in the binary. This behavior does not occur with 0.0.30. Perhaps the solution is to patch the /etc/freepops/config.lua file to include the full path to /usr/share/freepops? Reproducible: Always Steps to Reproduce: 1. 2. 3.
Ok, I have a working ebuild and patch file. I apologize if my solution is not the most elegant, as I've hard-coded the install location into the Makefile.
Created attachment 63504 [details] working ebuild
Created attachment 63505 [details, diff] patch for src/Makefile to hard-code lua search path
this can be considered tested on amd64 and keyworded ~amd64 - I've been running for about a day now using yahoo mail which was the biggest change.
added - thank Richard. amd64 people - please keyword as per use request.
i have no idea what you're talking about, freepops has always had amd64 KEYWORDS
