search

stefan-gr / abendbrot

Desktop oriented overlay for various ebuilds and the occasional gamer
19 stars 13 forks source link

Retroarch netplay broken. #68

Open jason-oliveira opened 7 years ago

jason-oliveira commented 7 years ago

Seems that using the .tar.gz files of the commits will not embed the first 7 letters of the commit hash at the end of a libretro core's version number, so netplay is now broken.

According to the retroarch devs, it needs to be accessed with git rev-parse --short HEAD

jason-oliveira commented 7 years ago

an alternative would be to somehow patch the first 7 digits of the commit number into the individual makefiles (a lot of work),

Appending "GIT_VERSION=e2a7b83" (or the appropriate hash slice) to make -f makefile.libretro was supposed to work, but I saw no success with it. Line 66 of the makefile.libretro in https://github.com/stefan-gr/abendbrot/blob/master/games-emulation/fbalpha-libretro/fbalpha-libretro-1.0_pre20170506.ebuild sets GIT_VERSION:= but that doesn't seem to work when set as en environment variable.

stefan-gr commented 7 years ago

Thanks for the report, It should be quiet easy to include the current rev in the makefile with libretro-core.eclass.

I think the only problem is version mismatch. As far as I'm aware netplay depends on the same core version between all clients. But since libretro doesn't have a release scheme at all we would be forced to guess the current commit of the upstream nightly buildbot. You will only be able to play with gentoo users since the current core versions aren't public and I opted to just fetching the latest commit every month instead.

I recommend using upstream builds for netplay. I'm changing the eclass later to include the short rev in every makefile.

jason-oliveira commented 7 years ago

I have not tested the change, but you've been taking the appropriate git commits for the version numbers, so I'm not too worried about a mismatch, now that the 7-digit hash is appended correctly.

That being said, even if you haven't been attempting to, the git commits you're basing your ebuilds on have been spot-on to the official core builds. This might be due to the fact that the cores usually don't have a steady stream of commits on the days after a release, but your accuracy has been perfect from what I've seen. This might not be a path you can maintain in the future, but only if development on the cores starts to exponentially skyrocket. Right now, it's great.

stefan-gr commented 7 years ago

It's a happy coincidence indeed. I worked a little on the tools/update_libretro.sh script to make it usable by users so that they can quickly update a specific core or all cores by themselves without exceeding the github API ratelimit too fast. This is how it's used:

cd tools
./update_libretro.sh # Crawls through all libretro cores and checks for an update
# Or to update only a specific core:
./update_libretro.sh ../games-emulation/2048-libretro/2048-libretro-9999-r2.ebuild

There is also the possibility to change the "LIBRETRO_COMMIT_SHA" of an ebuild to the desired one, it doesn't need to be the full hash, just the first 7 digits works too. Just remember to have USE="-debug -custom-cflags" for as close to upstream builds as possible. Use git reset --hard in case the overlay doesn't want to update with layman anymore.

Hmm, I guess I should write this on the frontpage or make a wiki page. Oh well, I hope you don't mind me leaving your issue open until this information is more exposed to the users.