Mupen64Plus has undergone substantial changes since the last stable release (1.5). This includes no native GUI, a modular build system, new build options/dependencies, lots of fixes/updates that required patching in the previous version, etc. This is a largely rewritten ebuild to address most of those changes, as well as optionally pull in compatible 3rd party plugins. I made it pull the live sources simply because the last dev snapshot, 1.99.4, is almost a year old. I don't expect this to enter the tree, but since most of this work will need to be done anyway once version 2.0 is released I figured I'd get a head start on it now (plug, I want to test the latest version). I'm pretty happy with the ebuild, except for one thing: because the application is split into multiple modules in their own repositories with no 'master' repository, AND because the mercurial eclass only supports pulling from a single repo (best I can tell), I have to directly pull the code within the ebuild. While this works fine, it means that the full source tree needs to be pulled EVERY time the package is installed; it writes the data to $WORKDIR, which, of course, gets wiped out after installation. I couldn't find any way to write to $DISTDIR/hg (or whatever) to leverage the caching that's usually done with live builds. If anyone knows how to work around this, suggestions/patches welcome. I started a discussion on the subject here, but didn't get any responses: http://forums.gentoo.org/viewtopic-t-895388.html Also also found bug 381655 when posting this, but that seems to apply to the 1.5 release. The live version should already include most, if not all, of the suggested patches. Reproducible: Always
Created attachment 288503 [details] games-emulation/mupen64plus-9999.ebuild
Created attachment 288623 [details] games-emulation/mupen64plus-9999.ebuild Minor update: removed ftbfs patch as it apparently doesn't need to be applied to 1.99, and moved man path fix to src_prepare().
Created attachment 288813 [details] games-emulation/mupen64plus-9999.ebuild Updated based on feedback from the Debian package maintainer: 1. Removed old/unneeded dependencies 2. Added undocumented dependencies for plugins (if USE flag enabled) 3. Dropped sed man dir fix in favor of MANDIR build option
Created attachment 288877 [details, diff] games-emulation/mupen64plus/files/mupen64plus-minizip.patch thanks a lot for your ebuild, Jared! Would be nice to see it in the gamerlay one day (same for the dolphin ebuild) ;) the api in >=sys-libs/zlib-1.2.5.1-r1 changed a bit and a minizip useflag was introduced. using zlib-1.2.5.1-r2 here I need to apply attached patch to work. with USE="+lirc" I get some undefined reference to some lirc function. probably an upstream bug forgetting an #ifdef or something similar. please keep up the great work (pcsx2 hint hint ;) )
(In reply to comment #4) > thanks a lot for your ebuild, Jared! > Would be nice to see it in the gamerlay one day (same for the dolphin ebuild) You're very welcome, Marcel. Someone else will need to add it to an overlay, though - I don't use them, so I'm more interested in getting my ebuilds merged into portage. > the api in >=sys-libs/zlib-1.2.5.1-r1 changed a bit and a minizip useflag was > introduced. using zlib-1.2.5.1-r2 here I need to apply attached patch to work. Yeah, someone else mentioned this as well, but I run stable so I haven't encountered this, and after reading bug 383351 and doing a couple quick searches I still can't figure out what the actual problem was, why it seems to only affect gentoo, or why the proper fix is. Do you have any suggestions? It builds and runs fine on my system. > with USE="+lirc" I get some undefined reference to some lirc function. > probably an upstream bug forgetting an #ifdef or something similar. > please keep up the great work (pcsx2 hint hint ;) ) I don't use lirc so I haven't encountered this, but I'll take a look and see if I can figure something out. Thanks for the report. As for pcsx2, I actually spent quite a while trying to get something going there, but with no wxwidget support in the emul-linux-x86 libraries it just isn't going to happen. Not unless someone far smarter than I gets involved anyway. I actually spent a while building a 32-bit chroot just so I could test out the newer version, but even when I did manage to get it built and running it seemed quite unstable, and had some seriously buggy plugins. I opened a bug report or two about it, and was pretty much told that Linux support doesn't get much love anymore, so I just gave up on it at that point.
Yeah, no idea on the lirc thing. I opened up an upstream bug report about it: http://code.google.com/p/mupen64plus/issues/detail?id=461
hi Jared, thank you for reporting the lirc bug upstream. I haven't tried the changeset yet, but it looks good :} the reason for the zlib breakage only happening in gentoo is that some gentoo maintainers decided to rename some badly chosen macro definitions (ON/OF). snip from zlib-1.2.5-r2 --- sed_macros() { # clean up namespace a little #383179 # we do it here so we only have to tweak 2 files sed -i -r 's:\<(O[FN])\>:_Z_\1:g' "$@" || die } --- I didn't want to go too offtopic with pcsx2 here. unfortunately I don't find the time to write a proper ebuild (argh, all those emulators should at least have some standalone snapshot tarballs at least from their plugins :} ), but it works quiet fine on my ~x86 machine. If you don't mind I'll commit your dolphin and mupen64plus ebuilds soon to gamerlay. friendly, marcel
Created attachment 289139 [details] games-emulation/mupen64plus-9999.ebuild (meta)
Created attachment 289141 [details] games-emulation/mupen64plus-audio-sdl-9999.ebuild
Created attachment 289143 [details] games-emulation/mupen64plus-core-9999.ebuild
Created attachment 289145 [details] games-emulation/mupen64plus-input-sdl-9999.ebuild
Created attachment 289147 [details] games-emulation/mupen64plus-rsp-hle-9999.ebuild
Created attachment 289149 [details] games-emulation/mupen64plus-rsp-z64-9999.ebuild
Created attachment 289151 [details] games-emulation/mupen64plus-ui-console-9999.ebuild
Created attachment 289153 [details] games-emulation/mupen64plus-video-arachnoid-9999.ebuild
Created attachment 289155 [details] games-emulation/mupen64plus-video-glide64-9999.ebuild
Created attachment 289157 [details] games-emulation/mupen64plus-video-rice-9999.ebuild
Created attachment 289159 [details] games-emulation/mupen64plus-video-z64-9999.ebuild
thanks Jared and Franz, added with some minor works-for-me changes to gamerlay.
Created attachment 289225 [details] games-emulation/mupen64plus-9999.ebuild (meta)
Created attachment 289227 [details] games-emulation/mupen64plus-audio-sdl-9999.ebuild
Created attachment 289229 [details] games-emulation/mupen64plus-9999.ebuild (meta)
Created attachment 289231 [details] games-emulation/mupen64plus-audio-sdl-9999.ebuild
Created attachment 289233 [details] games-emulation/mupen64plus-core-9999.ebuild
Created attachment 289235 [details] games-emulation/mupen64plus-input-sdl-9999.ebuild
Created attachment 289237 [details] games-emulation/mupen64plus-rsp-hle-9999.ebuild
Created attachment 289239 [details] games-emulation/mupen64plus-rsp-z64-9999.ebuild
Created attachment 289241 [details] games-emulation/mupen64plus-ui-console-9999.ebuild
Created attachment 289243 [details] games-emulation/mupen64plus-video-arachnoid-9999.ebuild
Created attachment 289245 [details] games-emulation/mupen64plus-video-glide64-9999.ebuild
Created attachment 289247 [details] games-emulation/mupen64plus-video-rice-9999.ebuild
Created attachment 289249 [details] games-emulation/mupen64plus-video-z64-9999.ebuild
@Marcel Unbehaun: I tested gamerlay and it just fails with (btw., my version worked): * Failed Patch: mupen64plus-core-minizip.patch ! * ( /var/lib/layman/gamerlay/games-emulation/mupen64plus-core/files/mupen64plus-core-minizip.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/games-emulation/mupen64plus-core-9999/temp/mupen64plus-core-minizip.patch.out * ERROR: games-emulation/mupen64plus-core-9999 failed (prepare phase): * Failed Patch: mupen64plus-core-minizip.patch! * * Call stack: * ebuild.sh, line 91: Called src_prepare * environment, line 2577: Called epatch '/var/lib/layman/gamerlay/games-emulation/mupen64plus-core/files/mupen64plus-core-minizip.patch' * environment, line 1244: Called die * The specific snippet of code: * die "Failed Patch: ${patchname}!"; * * If you need support, post the output of 'emerge --info =games-emulation/mupen64plus-core-9999', * the complete build log and the output of 'emerge -pqv =games-emulation/mupen64plus-core-9999'. * This ebuild is from an overlay named 'gamerlay-stable': '/var/lib/layman/gamerlay/' * The complete build log is located at '/var/tmp/portage/games-emulation/mupen64plus-core-9999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/games-emulation/mupen64plus-core-9999/temp/environment'. * S: '/var/tmp/portage/games-emulation/mupen64plus-core-9999/work/mupen64plus-core-9999'
franz, "my version" worked fine this morning, but you're right: now it doesn't build here anymore too. assuming some upstream changes. I'll probably look into this next week or simply commit your latest ebuild :}
Comment on attachment 288877 [details, diff] games-emulation/mupen64plus/files/mupen64plus-minizip.patch fixed upstream
removed obsolete patch in gamerlay.
Created attachment 289269 [details] games-emulation/mupen64plus-9999.ebuild Another minor revision: 1. Changed zlib dependency to the following, so it should work with both stable and unstable versions: || ( <sys-libs/zlib-1.2.5.1-r1 >=sys-libs/zlib-1.2.5.1-r2[minizip] ) 2. Removed dependency on virtual/glu, as it appears to be fully redundant with virtual/opengl. 3. Updated description to be a bit more useful and informative (knowing that it's a fork of a dead project isn't very helpful :-) ) Marcel, since I don't use unstable zlib, can you confirm that this should now work without any additional patches? That appears to be the case after the upstream changes you mentioned, but just want to be sure. Also, the LIRC bug has been fixed upstream, so that should not longer be a problem after a fresh build. Thanks.
hi Jared, I can confirm that both the lirc and the minizip bugs were fixed upstream. commit https://bitbucket.org/richard42/mupen64plus-core/changeset/c6f0456c4300/raw/ fixed lirc and commit https://bitbucket.org/richard42/mupen64plus-core/changeset/b9cb56e9ba07/raw/ fixed zlib/minizip (cmake checks which version is installed)
Created attachment 289313 [details] games-emulation/mupen64plus-core-9999.ebuild
Created attachment 289315 [details] games-emulation/mupen64plus-9999.ebuild (meta)
Created attachment 289317 [details] games-emulation/mupen64plus-audio-sdl-9999.ebuild
Created attachment 289319 [details] games-emulation/mupen64plus-core-9999.ebuild
Created attachment 289321 [details] games-emulation/mupen64plus-input-sdl-9999.ebuild
Created attachment 289323 [details] games-emulation/mupen64plus-rsp-hle-9999.ebuild
Created attachment 289325 [details] games-emulation/mupen64plus-rsp-z64-9999.ebuild
Created attachment 289327 [details] games-emulation/mupen64plus-ui-console-9999.ebuild
Created attachment 289329 [details] games-emulation/mupen64plus-video-arachnoid-9999.ebuild
Created attachment 289331 [details] games-emulation/mupen64plus-video-glide64-9999.ebuild
Created attachment 289333 [details] games-emulation/mupen64plus-video-rice-9999.ebuild
Created attachment 289335 [details] games-emulation/mupen64plus-video-z64-9999.ebuild
Created attachment 304585 [details] games-emulation/mupen64plus-9999.ebuild Not sure how I missed this before, but I had the shared data directory set directly to ${GAMES_DATADIR}/ rather than ${GAMES_DATADIR}/${PN}/. This small update corrects that problem.
Ebuild for new frontend is here https://bugs.gentoo.org/show_bug.cgi?id=423405 .
Created attachment 350058 [details] Updated mupen64plus-9999 ebuild I modified Jared's latest ebuild. -Use mercural_fetch from the mercural eclass instead of calling hg clone manually. -Default USE=plugins on. -Disable internal CFLAGS by setting an empty OPTFLAGS. (see comment in ebuild for details)
Created attachment 350088 [details] games-emulation/mupen64plus-9999.ebuild Another ebuild update. -Utilize USE_EXPAND for optional plugins. This allows enabling of individual plugins. See below for a few known issues. -Remove verbose compiler output I accidentally left in when debugging modules building -Check if the file plugindir/RELEASE exists before attempting to install it. NOTES: * As the comment in the ebuild says you need to add USE_EXPAND="MUPEN64_PLUGINS_RSP MUPEN64_PLUGINS_VIDEO" to your make.conf for the USE flags to display properly. * The USE_EXPAND plugins all assume the repository has the same base uri in the form of PLUGIN_BASE_URI/mupen64plus-PLUGINTYPE-PLUGINNAME. This may not be true for all future plugins, but is true for all current plugins. * I assume the glide64 plugin is the only one that depends on GLEW, maybe someone can correct me if this is wrong.
Created attachment 350376 [details] games-emulation/mupen64plus-9999.ebuild Another update. -Always run make with DEBUG=1. This option only adds -g to CFLAGS and doesn't strip binaries. Portage handles stripping for us. -Fix disabling compiling against libsamplerate. Correct option is NO_SRC=1 -Add optional speex dependency. The speex resampler is used by the SDL audio plugin. -Unconditionally disable OSS support. -Use local variables in src_compile and src_install instead of depending on accidental globals in src_install. -Fix a minor copy-paste bug on my part in src_install.
Created attachment 354052 [details] games-emulation/mupen64plus-9999.ebuild *Add glew dependency for the z64 video plugin. It doesn't comple with glew-1.10.0 because of bug 477948. 1.10.0-r1 is in the tree and fixes this issue.
I will work on this in a few days time.
Since 2.0 is out, we'll add that instead following bug #482614. If you really feel like needing live ebuilds, please reopen.
