OpenLiero is a solution for all Linux-running Liero fans. Thanks to this software you can easily play good, old Liero on a machine running Linux. Reproducible: Always Steps to Reproduce:
Created attachment 152069 [details] games-action/openliero-9, first version
Hi Jan, it mighe be a better idea to attach the ebuild to the next bug: *** This bug has been marked as a duplicate of bug 164009 ***
Meh, missed the "x" letter, please ignore the last comment.
(In reply to comment #2) > Hi Jan, it mighe be a better idea to attach the ebuild to the next bug: > > *** This bug has been marked as a duplicate of bug 164009 *** > Near hit, Jan ;)
Created attachment 152163 [details] games-action/openliero-9, second version Slightly polished ebuild, thanks to folks from #gentoo-sunrise.
Created attachment 152165 [details] games-action/openliero-9, third version Removed useless src_compile and fixed the license information.
Created attachment 152647 [details] added correct eclass it looks nice, but i don't have copy of dos liero and i guess there should be somehow configured option on were the binary should look for files of old liero (ideal would be something like /usr/share/games/openliero/)
Created attachment 152649 [details] hotfix on my previous build damn me, again i edited in wrong overlay and posted untested build :(
Created attachment 152657 [details] SVN snapshot version, as published in Sunrise. Instead of using a self-created Makefile, this ebuild uses original jam build system. Moreover, it takes advantage of games.eclass and includes a gcc-4.3.0 patche. Additionally, it informs user that the original Liero binaries are required.
(In reply to comment #7) > it looks nice, but i don't have copy of dos liero and i guess there should be > somehow configured option on were the binary should look for files of old liero > (ideal would be something like /usr/share/games/openliero/) Adding the original Liero binaries would involve several difficulties. Firstly, Liero's licensing isn't clear. Secondly, a user may not necessarily want the original Liero. The choice of mods and hacks is very big - a user can prefer a different binary. Last but not the least, installing Liero binaries in /usr/ prevents users from adding new maps, as they are loaded exclusively from directory containing liero.exe. From my point of view, informing user on how to get the original binary is a better solution then bundling it within this package.
Created attachment 152663 [details, diff] Patch for gcc-4.3.0 users.
If licencing is not so clear please inform user about it in elog. Cause not everybody want break some licences even if it is abandonware. Dont make it depend on dev-util/jam it will be removed from tree. You should really add option to set from where it should look for orginal game as parameter ie: openliero --dir=/home/games/Liero/ so there will be easy execution as some desktop file :]
The OpenLiero's ebuild is in the sunrise overlay now, available at http://overlays.gentoo.org/svn/proj/sunrise/reviewed/games-action/openliero/
according to http://www.liero.be/ openliero was merged into a new version of liero. Ebuilds are at my overlay (layman -a xmw). http://git.overlays.gentoo.org/gitweb/?p=dev/xmw.git;a=tree;f=games-action/liero
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
