Created attachment 308239 [details] openmw-0.13.0.ebuild An open source reimplementation of the role playing game The Elder Scrolls III: Morrowind This is very alpha and not really playable.
Created attachment 308241 [details, diff] openmw-0.13.0-cmake.patch
added to sunrise-overlay http://git.overlays.gentoo.org/gitweb/?p=proj/sunrise-reviewed.git;a=tree;f=games-engines/openmw
Created attachment 315345 [details] morrowind-data ebuild This ebuild extracts and copies the data from the morrowind cd to /opt/morrowind (which could be used by openmw for example). Expansions Bloodmoon and Tribunal aren't installed yet, room for improvement.
Created attachment 315347 [details] openmw-0.15.0 ebuild My own attempt to write an ebuild for openmw (didn't look for this bug before writing it). Assumes that data files are installed with the morrowind-data ebuild.
(In reply to comment #4) > Created attachment 315347 [details] > openmw-0.15.0 ebuild > > My own attempt to write an ebuild for openmw (didn't look for this bug > before writing it). Assumes that data files are installed with the > morrowind-data ebuild. I am interested in this ebuild too, but was too lazy to update, because of added MyGUI dependncy. Let me comment on this: - games.eclass now supports EAPI=4 (if you don't want to use that, then helper functions need a "|| die") - sed-call has no "|| die" - you don't call prepgamesdirs last - there are a few dependencies missing (virtual/pkgconfig, media-libs/freetype:2, ... check CMakeLists.txt and the files in zinnschlag-openmw-94498f5/cmake) - I would suggest to patch CMakeLists.txt rather than adding your own install rules in the ebuild - dodir is not needed when using "insinto" - you don't provide any useflags, but the build system let's you choose several options - I would set "games-rpg/morrowind-data" as PDEPEND. Then you are able to set openmw as RDEPEND in morrowind-data ebuild. Either way, it's not a build-time dependency. - doins takes multiple arguments, dogamesbin too - doins has an "-r" switch for recursively - $PN should never be in DESCRIPTION - cd "${WORKDIR}/${P}_build" is not future-proof, cause it will break for "CMAKE_IN_SOURCE_BUILD=1". Use ${CMAKE_BUILD_DIR} which works for both cases - I doubt that ogres "threads" useflag is neccessary for openmw - you don't install config files into "${GAMES_SYSCONFDIR}". Look at the sed in the existing ebuild - you currently don't make use of any eutils function, but do inherit it - you don't install the icon - you don't install the .desktop file
Thank you for the comment, I'll have a look at the things you mentioned this weekend and update the ebuild. (In reply to comment #5) > - I doubt that ogres "threads" useflag is neccessary for openmw http://openmw.org/wiki/index.php?title=Development_Environment_Setup#Gentoo_Dependencies lists them as a dependency, I just assumed the devs know best.
Created attachment 315437 [details] morrowind-data ebuild Updated morrowind-data ebuild.
Created attachment 315439 [details] openmw-0.15.0 ebuild Updated ebuild. Should now reflect all suggestions, where needed.
Created attachment 315441 [details] openmw-0.15.0-cmake patch file Patch for cmake configuration files.
I will upload modified versions of this to my overlay shortly. I don't feel that either of this is ready for the tree. MyGUI also needed some work. let me comment on your updated ebuild: > I just assumed the devs know best - surprisingly, that is rarely the case. boost and threads useflags are definitely not needed. - boost is NOT just build-time dep. OpenMW does link against it - use virtual/pkgconfig, not dev-util/pkgconfig anymore - dependencies should be ordered alphabetically - sed on openmw.cfg.install in src_install is pretty ugly. patch the openmw.cfg to take the variable MORROWIND_DATA_FILES which is already defined/definable and pass "-DMORROWIND_DATA_FILES=/opt/morrowind" to mycmakeargs - there are several QA notices. -fno-strict-aliasing should be appended for now via flag-o-matic - let us rather install the icon into /usr/share/icons/hicolor/256x256/apps then we need to use gnome2-utils eclass to update the icon cache pixmaps is only a fallback and should not be used for modern packages. patch the CMakeLists.txt to include an ICONDIR variable - some minor glitches in the cmake patch. We should also remove the random warnings flags completely. The user should specify which warnings he will get instead of upstream hiding some of them via flags. - the desktop file uses "Version" variable incorrectly. it should be removed. - there are major compile issues with ffmpeg useflag. headers are missing from ffmpeg_decoder.cpp. Note sure if that is gcc version related. - you should make the data-ebuild optional via a "cdinstall" useflag. It is not really neccessary. A windows-installation of morrowind does also work. - you could as well use "$(cmake-utils_use_use ffmpeg FFMPEG)", but that's rather style - I would prefer to do ">=" instead of "=" for ogre, so users in unstable arch can report bugs if a newer ogre version comes out :P - openmw-${PV} -> ${P} - unneccessary "${S}" in the dodoc line for the data ebuild: - all those mv stuff is not good. use EAPI=4 and proper doins calls - I don't understand why you copy videos over and don't install them directly - unshield is not a runtime dependency - don't unpack stuff in src_install. use src_unpack - you might want to consider to export CDROM_NAME variable (name of the morrowind cd when it's mounted. makes it easier for cdrom eclass to recognize it correctly) - check the size of the unpacked stuff. unshield often does weird things. so some checks for needed disk size would be nice via "check-reqs" eclass (when you do that you should put those variables e.g. CHECKREQS_DISK_BUILD in global scope, NOT local like other games ebuilds do, cause that is incompatible with EAPI=4) - I don't see where you use eutils eclass functions - I wonder if everything is fine with case sensitivity on linux, but haven't had problems myself
This is no longer maintained in sunrise (at least not by me) https://github.com/hasufell/hasufell-overlay/commit/bc17bf41be16884155eed4218a8a63415c9ef37c # layman -a hasufell
Thank you for all the information on how to improve the ebuilds. The devmanual is IMHO often lacking in a lot of these details. I'll be checking out your repo soon.
(In reply to comment #12) > I'll be checking out your repo soon. Seems to work ok. However, it seems that mygui is not working properly here. I don't get any 2D interface, like minimap, dialogs, etc. Do you have the same issue?
(In reply to comment #13) > However, it seems that mygui is not working properly here. > I don't get any 2D interface, like minimap, dialogs, etc. Do you have the > same issue? Nevermind. Some rebuilding fixed it.
Created attachment 316965 [details] openmw-0.16.0 ebuild OpenMW 0.16.0 was released today. Same ebuild as 0.15.0, but with a few minor changes. I just renamed the patches to reflect the new version.
Created attachment 325876 [details] openmw-0.18.0 ebuild Updated ebuild for 0.18.0. It builds now again, however running the program gives a black screen and does nothing in my case (running the developer provided linux binaries do work), seems to hang. Spend the whole evening yesterday to find out where the problem is, but it could very well be one of the dependencies. Could someone check if this does work in their case?
Created attachment 325878 [details] updated cfg patch
Created attachment 325880 [details] updated cmake patch
it's already updated since two days: https://github.com/hasufell/hasufell-overlay/tree/master/games-engines/openmw
(In reply to comment #19) > it's already updated since two days: > https://github.com/hasufell/hasufell-overlay/tree/master/games-engines/openmw Oops, checked the sunrise repo... which is outdated. I'll have a look if that works better.
I keep getting segfaults with this latest version at starting openmw (ebuild from the overlay). gdb output: Program received signal SIGSEGV, Segmentation fault. compare (__str="Material", this=0x7ffff7ecdbc8) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/include/g++-v4/bits/basic_string.h:2132 2132 const size_type __size = this->size(); (gdb) bt full #0 compare (__str="Material", this=0x7ffff7ecdbc8) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/include/g++-v4/bits/basic_string.h:2132 __size = <optimized out> __osize = <optimized out> __r = <optimized out> #1 operator< <char, std::char_traits<char>, std::allocator<char> > (__rhs="Material", __lhs= <error reading variable: Cannot access memory at address 0xffffffffffffffe9>) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/include/g++-v4/bits/basic_string.h:2419 No locals. #2 operator() (__y="Material", __x=<error reading variable: Cannot access memory at address 0xffffffffffffffe9>, this=<optimized out>) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/include/g++-v4/bits/stl_function.h:230 No locals. #3 std::_Rb_tree<std::string, std::pair<std::string const, Ogre::ResourceManager*>, std::_Select1st<std::pair<std::string const, Ogre::ResourceManager*> >, std::less<std::string>, Ogre::STLAllocator<std::pair<std::string const, Ogre::ResourceManager*>, Ogre::CategorisedAllocPolicy<(Ogre::MemoryCategory)0> > >::_M_insert_unique_ (this=0x7ffff7ecdb98, __position=<optimized out>, __v=...) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/include/g++-v4/bits/stl_tree.h:1226 No locals. #4 0x00007ffff7962fd8 in insert (__x=..., __position=<optimized out>, this=0x7ffff7ecdb98) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/include/g++-v4/bits/stl_map.h:541 No locals. #5 operator[] (__k="Material", this=0x7ffff7ecdb98) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/include/g++-v4/bits/stl_map.h:451 No locals. #6 Ogre::ResourceGroupManager::_registerResourceManager (this=0x7ffff7ecdb68, resourceType="Material", rm=0x7ffff7ed2428) at /var/tmp/portage/dev-games/ogre-1.8.0/work/ogre_src_v1-8-0/OgreMain/src/OgreResourceGroupManager.cpp:950 ogreAutoMutexLock = {m = 0x7ffff7ecdb70, is_locked = true} There is more after #6. strace output: write(3, "23:02:28: Creating resource grou"..., 42) = 42 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2917, ...}) = 0 write(3, "23:02:28: Creating resource grou"..., 43) = 43 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2917, ...}) = 0 write(3, "23:02:28: Creating resource grou"..., 45) = 45 open("/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 4 read(4, "0-3\n", 8192) = 4 close(4) = 0 mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9fec3ed000 mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9fec2ed000 mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9fec1ed000 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2917, ...}) = 0 write(3, "23:02:28: SceneManagerFactory fo"..., 73) = 73 futex(0x7f9ff49613f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2917, ...}) = 0 write(3, "23:02:28: Registering ResourceMa"..., 56) = 56 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xffffffffffffffe9} --- +++ killed by SIGSEGV +++ Any thoughts on how to tackle this?
no idea, compile from hand (without ebuild), retry and file a bug report upstream.
(In reply to comment #22) > no idea, compile from hand (without ebuild), retry and file a bug report > upstream. Does not segfault outside portage, does hang at a futex (was the same with 0.16. and 0.17.0, I'll post that upstream).
(In reply to comment #23) > (In reply to comment #22) > > no idea, compile from hand (without ebuild), retry and file a bug report > > upstream. > > Does not segfault outside portage, does hang at a futex (was the same with > 0.16. and 0.17.0, I'll post that upstream). Rebuilding ogre, mygui (inside portage) en openmw (outside portage) against boost_1.49 (there were 2 boost versions installed 1.48 and 1.49) fixed the building outside portage. The overlay openmw ebuild does not segfault any more now, but hangs at the same futex. Looking at the ebuild it seems it is forced to build against boost 1.48. Is there a reason for this?
a bit lazyness, cause I encountered trouble with boost-1.49 in many ways and don't want to support it currently
it's coming closer to a real beta version... it's almost playable now, except for very poor AI
*morrowind-data-2 (06 Nov 2014) 06 Nov 2014; Julian Ospald <hasufell@gentoo.org> +morrowind-data-2.ebuild, +metadata.xml: initial import wrt #411295 *openmw-0.33.0 (06 Nov 2014) 06 Nov 2014; Julian Ospald <hasufell@gentoo.org> +openmw-0.33.0.ebuild, +files/openmw-0.33.0-build.patch, +files/openmw-0.33.0-cfg.patch, +files/openmw-0.33.0-opencs.patch, +metadata.xml: initial import wrt #411295
