Beginning with MAME 0.136u1, the sdlmame component has been included in the main sources and is no longer distributed separately. Some more info: http://rbelmont.mameworld.info/?p=519 http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=58111#Post58111 This has necessitated some changes to the ebuild in order to properly fetch, prepare, and build new versions of sdlmame beyond 0.136. As I had a need to test one of the bug fixes in 0.136u1, I spent some time working on an updated ebuild to support building on Gentoo. Attached is an ebuild for 0.136u3. I added support in this ebuild for the diff updates provided in between major upgrades, but they need to be downloaded manually from http://mamedev.org/updates.html and added to FILESDIR. The updates won't be needed for major releases (eg., when 0.137 is released), but I've written the ebuild in such a way that the patches will only be applied as necessary. Eg.,: sdlmame-0.136.3.ebuild - applies u1, u2, and u3 updates sdlmame-0.136.1.ebuild - applies u1 update sdlmame-0.137.ebuild or sdlmame-0.137.0.ebuild - applies no updates I also updated the mame.ini template, which has changed a good bit since it was originally created (it now contains numerous deprecated options that sdlmame complains about on launch). Finally, two output changes: the binary is now called sdlmame64 on amd64 systems (instead of just sdlmame), and ui.bdf no longer seems to be built. Otherwise, the final product works just as 0.136. Hope this helps save some time once the 0.137 release gets here. :-) Also, if anyway is interested in testing the interim updates, as mentioned above this ebuild now provides a good, easy way to do so. Reproducible: Always Steps to Reproduce:
Created attachment 221271 [details] games-emulation/sdlmame-0.136.3.ebuild
Created attachment 221273 [details] updated mame.ini
Comments: I want to keep the _p# style of naming for the ebuilds. get rid of the pkg_nofetch put the quoting back the way the current ebuild is the ini file should use the @GAMES... style as before so it's clear what's happening.
1. What do you mean by _p# style? Are you talking about the MY_PV and MY_P variables? That has to change, as the package name has changed. 2. Why would you want to get rid of pkg_nofetch? It provides more useful information about the problem than just saying that fetch restrictions are turned on. What would that function even be used for if not this very purpose? 3. What quoting are you referring to? 4. This can be changed back easily enough, but how is it more clear? Users should never see that file in the raw form, the sed commands work just as well in the ebuild, and it removes an otherwise unnecessary step to the packaging process, which I'm hoping would encourage the maintainer to update the file more regularly, as even for the 0.136 package it was out of date. Ideally, this file shouldn't be included like this anyway, as it can change with every new version. It should be generated post-installation by the binary itself, but I figured running the binary automatically to generate the config file wouldn't be good idea from a packaging perspective.
FYI, this ebuild works as-is for 0.137 final.
0.136.3 ebuild doesn't work for 137u1. I changed the patching part to this and it works for me: for i in ${FILESDIR}/${MY_PV}*.diff; do if [ $(echo ${i##*0137u} | cut -d. -f1) -le ${U} ]; then einfo Applying patch $i EPATCH_SOURCE=${FILESDIR} EPATCH_OPTS="--binary" epatch $i fi done (that doesn't address Mr. Bones' concerns but it makes it work for now so I can play) :)
thanks for the heads up. I haven't tried this with 0.137u1 yet - was mostly worried with just getting to 0.136u1 because of a specific fix I needed. The epatch command is new to me. Will look into that some more and update the ebuild using it.
I just got around to messing with myself and found that my ebuild was failing even after switching to your epatch syntax. It took me a while to realize that I had the major version number hardcoded in the if statement. Oops. :-( Can't believe I let that slip through. Anyway, I switched to using a variable there and updated the ebuild using your suggested epatch syntax and all appears well again. Thanks for the tip. Also, just for the record, being able to do this with a variable at the shell level is totally awesome: ${i##*${MY_PV}u} Bash kicks ass. :-)
Created attachment 226519 [details] games-emulation/sdlmame-0.137.1.ebuild
Hi! I'm new in this forums. I have a commet about this ebuild. If you use wget and the URL: "http://mamedev.org/downloader.php?&file=${MY_P}.zip" doesn't works. I've seen that this URL redirect to: "http://www.aarongiles.com/mirror/releases/${MY_P}.zip" This URL is working perfectly with wget. So I think we must change SRC_URI to: "http://www.aarongiles.com/mirror/releases/${MY_P}.zip -> ${MY_P}.zip" In that way we can fetch the package.
Hi, Eduardo. Welcome, and thanks for the comment. wget doesn't work because they block wget's user agent. This is why fetch restriction is enabled; you need to download the file first yourself before installing the package. You can actually work around this by using something like "wget -U blah http://filename..." to change the wget user agent and it'll work fine, but we can't do this from portage. As for your suggestion regarding changing the SRC_URI, I'd rather not. The one listed is the "official" download URL provide by MAME, which should always work. Since it's a redirect script, they could potentially change the backend link at any given time, but the main/official download link will continue working. I think this is the safer approach, if slightly less convenient.
It doesn't matter at all that they're blocking wget because it'll be uploaded to the Gentoo mirrors. Just leave mirror://gentoo/ in SRC_URI.
Created attachment 241461 [details] Version bump for sdlmame-0.139 Testing on Gentoo AMD64 system, builds and installs fine. I commented out the line below temporarily because I had neither of these files in my file folder and the install failed. #doins "${FILESDIR}"/{joymap.dat,vector.ini} || die "doins joymap.dat vector.ini failed" I realize these are two files are custom from user to user and also vital depending on the MAME setup. Is there a way to switch searching and installing these two configs with a use flag or multiple use flags such as joymap and vector?
(In reply to comment #13) > Testing on Gentoo AMD64 system, builds and installs fine. I commented out the > line below temporarily because I had neither of these files in my file folder > and the install failed. > > #doins "${FILESDIR}"/{joymap.dat,vector.ini} || die "doins joymap.dat > vector.ini failed" > > I realize these are two files are custom from user to user and also vital > depending on the MAME setup. Is there a way to switch searching and installing > these two configs with a use flag or multiple use flags such as joymap and > vector? FYI those files come from the normal portage version of sdlmame located in /usr/portage/games-emulation/sdlmame/files which you can copy to your local overlay.
Why did you remove the debug flag and thereby force a dependency on gconf and gtk+? This seems like a regression to me. Admittedly, I'm still confused by how the official ebuild disables the debugging code. I had to enable NO_X11 to get a manual compile to work. Cheers.
sdlmame-0.139_p2.ebuild is in portage.
(In reply to comment #16) > sdlmame-0.139_p2.ebuild is in portage. > error building: * Patching release with source updates * Applying 0139u1.diff ... * Failed Patch: 0139u1.diff ! * ( 0139u1.diff ) /var/tmp/portage/games-emulation/sdlmame-0.139_p2/temp/0139u1.diff.out is a large file with bunch of failures (pretty much all of the files fail to patch)
