Hi, just to tell that openrpg 1.6.3 is out and that the last ebuild available is 1.6.1. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 74614 [details] the ebuild should work great, basically a renamed 1.6.1
Created attachment 74615 [details, diff] the patch file... you'll need this too this is the patch file used the old one as a template
Created attachment 74617 [details] the ebuild(working.. or not) erm... so it was a little harder then that... but it works now
Comment on attachment 74617 [details] the ebuild(working.. or not) builds but doesen't work
Version 1.6.3 seems to discover the path of the files dynamically. With the current ebuild it crash as it will be looking at the file relatively to the discovered root. The options, to me, are: 1) drop the package or 2) use a wrapper and leave the tree as it was "badly" designed or 3) fix every single place where it is referring to other files. I won't do the 3rd :)
(In reply to comment #5) > Version 1.6.3 seems to discover the path of the files dynamically. > [...] > 2) use a wrapper and leave the tree as it was "badly" designed or > 3) fix every single place where it is referring to other files. Could you expound on these a bit? If you could explain what needs to be done, perhaps someone else (e.g., myself) could do the grunt work.
> Could you expound on these a bit? If you could explain what needs to be done, > perhaps someone else (e.g., myself) could do the grunt work. In the new openRPG version, the developer(s) seems to have "automatically" detected where all the files are located, I guess taking the current path of a python file, and then derived where all the other files are, just using this path as a reference. This works only if we assure that the files are deployed in the same way they are in the tar.gz . Gentoo, according to the http://www.gentoo.org/proj/en/desktop/games/games-ebuild-howto.xml use to deploy files following its own rules. So the work to be done is to replace any path, in openRPG, to point to the correct location. But the better would be that the developers do this, as we have, otherwise, to reapply different patches to any new release of software. Hope to be clear enough :/
*** Bug 172265 has been marked as a duplicate of this bug. ***
openrpg-1.7.1 requires python 2.5 and wxpython 2.8. python 2.5 is not yet unmasked (set a depend on bug 148333?), and wxpython 2.8 is not in the tree (new bug needed?).
this is the last thing in the tree depending on wxpython-2.4. we need a decision made - update or remove.
The new version needs wxpython-2.8, so it should definitely not be removed but updated. In the long run it is good!
I am working on a brand new ebuild for OpenRPG. The devs for OpenRPG have added features that break the old ebuild's design. The current ebuild should be removed from portage, as it is completely useless. The only way it *could* be used, is if the user connected to a server running OpenRPG 1.6.1, of which there are none listed on the metaserver. I am still deciding exactly how to structure the ebuild, but I imagine in the future OpenRPG will be installed in to /opt/openrpg1, and there will be a shell-starter script in /usr/games/bin/ that cd's in to /opt/openrpg1 then executes start.py. In other words, rather than using a gentoo-normalized structure and editing every single openrpg path, why not preserve openrpg's way of doing it and install to /opt/ (which is normally reserved for binary installations, but this could be thought of as a "binary" in the sense that nothing in it should be altered).
Created attachment 119495 [details] openrpg-1.7.1.ebuild Working but security-flawed ebuild. Like all previous versions of OpenRPG, this ebuild changes the group-write-permissions to ON for the directory /usr/share/games/openrpg1. This allows anyone in the "games" group to write and execute arbitrary code that is shared amongst all users in the "games" group. I believe there is no solution short of rewriting all of the pathing code in OpenRPG. The ebuild contains a good 15-second pause to get this point across.
Created attachment 119496 [details] openrpg-client wrapper executable A required file used in the installation of openrpg-1.7.1.
Created attachment 119497 [details] openrpg-server wrapper executable A wrapper script for start-server.py
The provided ebuild and two wrapper executables (which both go in the files/ package directory) create a functioning OpenRPG-1.7.1 ebuild. It is a complete rewrite of the old ebuild, and is probably NOT compatible with it. You should --unmerge the previous OpenRPG's. I'm not sure what DEPENDS to set to ensure this (-<games-rpg/openrpg-1.7.1 perhaps?). This is my second ebuild ever (the first being a wxPython-2.8 ebuild provided earlier today in bug #178727), so please look it over closely. Could someone from the Gentoo Games herd please add bug 178727 as a depends for this bug? Happy gaming!
*** Bug 255720 has been marked as a duplicate of this bug. ***
Ok, OpenRPG 1.8.0 is out, and uses wxpython 2.8.10. Currently, this seems to be in Last Rites because it "needs updated to use a newer wxpython than 2.6". I feel that updating the ebuild would be a far better solution to that problem than simply removing OpenRPG from the tree. --Arek75
This package has been gone from the tree for years, so closing.
