Add retroarch and libretro to Gentoo about abendbrot HOT 26 OPEN

You can find my work in progress at gentoo/gentoo#9330

from abendbrot.

You can find my work in progress at gentoo/gentoo#9330

Not sure what has happened to stefan

Are there still plans to integrate these ebuilds into the tree? I do see several libretro ebuilds listed now, however they're tied to the Kodi media application, instead of RetroArch itself

from abendbrot.

Is there any updates on this progress? not sure if I should still be submitting RetroArch version bumps here.

from abendbrot.

I use libretro through Kodi, so that's what I've been working on.

I'd like to not have libretro.eclass. Would you be interested in submitting a PR to https://github.com/gentoo/gentoo/ adding these packages, not using libretro.eclass?
games-emulation/retroarch
games-emulation/libretro-database (which is a dependency of games-emulation/retroarch)
games-emulation/retroarch-assets (which is a dependency of games-emulation/retroarch)
games-emulation/slang-shaders (which is a dependency of games-emulation/retroarch)
games-emulation/libretro-info (which is a dependency of games-emulation/retroarch)

It doesn't look like that would be too much effort, the packages in this repo are a great start. We just need things to be simpler (ie, not using libretro.eclass, can games-emulation/retroarch's build/install be simpler than what the ebuild here does).

I'd happily review and merge them if you did. I'd really like to get all of RetroArch into Gentoo. :)

from abendbrot.

@jason-oliveira @candrews I'm very much new to writing and maintaining ebuilds, but I'd love to help spearhead some effort with getting Retroarch directly included in Gentoo. Work is progressing in the upstream project with ARM64 architecture support, which would be nice to include

from abendbrot.

The best thing to do would be to make a PR to https://github.com/gentoo/gentoo/

I'll review, test, and provide help.

If you do that, we can get this into Gentoo quite soon.

from abendbrot.

@IntelMiner all patches welcome.

@candrews when I can find time, I'll happily submit a PR. if IntelMiner doesn't do it first. The ebuild could definitely do with a rewrite.

from abendbrot.

@jason-oliveira I've been using the ebuilds myself locally without too many issues. @stefan-gr did helpfully include an updater script which seems to rebase them against the git trunk builds of each repository

If you want to rewrite them first and submit a PR, that'd be fine. If not, they look like they could likely be submitted as they are(?)

from abendbrot.

I don't think libretro.eclass is going to be acceptable. I advise that the existing ebuilds be refactored to not use libretro.eclass then submitted to Gentoo.

Note that I think we're only talking about these packages:

• games-emulation/retroarch
• games-emulation/libretro-database (which is a dependency of games-emulation/retroarch)
• games-emulation/retroarch-assets (which is a dependency of games-emulation/retroarch)
• games-emulation/slang-shaders (which is a dependency of games-emulation/retroarch)
• games-emulation/libretro-info (which is a dependency of games-emulation/retroarch)

Many of the libretro emulators are in Gentoo already as games-emulation/libretro-*, take a look at https://github.com/gentoo/gentoo/tree/master/games-emulation/ to see the full list. If one is missing that you'd like to see, either submit a PR yourself adding it or ask me and I'll get on it.

from abendbrot.

This is being worked on.

from abendbrot.

@jason-oliveira Are you aiming to get all the libretro cores included in a similar manner to the existing ebuilds?

@candrews A lot of those ebuilds look rather out of date. As I understand it, RetroArch and its "Libretro" cores try to stay in sync with one another. Which may make tracking them a little difficult

from abendbrot.

A lot of those ebuilds look rather out of date. As I understand it, RetroArch and its "Libretro" cores try to stay in sync with one another. Which may make tracking them a little difficult

I'm happy to update them - are there any specifically that you'd like to see bumped?

Also, the fact they the cores don't release versions makes tracking incredibly difficult. If you can convince them to release actual versions, that would make life much easier.

from abendbrot.

@IntelMiner everything is currently living in https://gitlab.com/jason.oliveira/retroarch. All but the main ebuild are ported and working. Additions I made to the ebuild (updated dependencies, requests from RA devs) seem to have messed up the src_configure() step, so I'm walking-back the changes and re-iterating all my additions back in.

So yeah, don't use the other repo for the next 48 hours or so, and then I'll be happy to start submitting them to gentoo via pull request (can gitlab and github interact? guess I'll find out!).

@candrews Is there any objections to making most of the assets/shaders/cores live in userspace, say in ~/.local/retroarch/ subdirs? This is how Lutris and Steam operate, so I set this as the default configuration in the ebuilds I plan to submit.

from abendbrot.

Is there any objections to making most of the assets/shaders/cores live in userspace, say in ~/.local/retroarch/ subdirs? This is how Lutris and Steam operate, so I set this as the default configuration in the ebuilds I plan to submit.

If they're executables, then that would not be acceptable. Everything must be built from source. If it's unclear, then I suggest you submit the PR to Gentoo, and we can take a look and figure it out - it'll be easier to have that conversation with a concrete ebuild than with an abstract proposal.

from abendbrot.

Ugh. @stefan-gr, it profoundly saddens me that our mutual efforts on RetroArch and LibRetro have largely died and been left to bitrot across a medley of unstable and largely unmaintained overlays (e.g., vortex, menelkir). It's equally disappointing that most prior efforts to merge our work into the Portage tree (e.g., this ridiculous 10,000 commit patchset adding RetroArch, which was unsurprisingly closed without comment several years ago) also fell by the wayside and were summarily buried, excluding a few unstable and outdated LibRetro cores which mysteriously appeared in the Portage tree (e.g., games-emulation/libretro-bnes) but will probably be removed shortly due to developer disinterest.

This isn't anyone's fault, of course – or, rather, this was everyone's fault including my own. In the time-honoured spirit of "If you want something done, just put down that plastic-cracked SNES controller down and do it!", I'm strongly considering resurrecting quasi-official RetroArch support at raiagent, yet another overlay where I recently shepherded PySide2 into the Portage tree.

The endgame would be exactly the same: preserve Portage-quality RetroArch support at raiagent until one or more official Gentoo developers relieve me of my terrible, exhausting, and debilitating burden by fully merging that support into the Portage tree.

Because the current state of RetroArch on Gentoo is abysmally tragicomic,^{...except nobody's laughing, are they?} this will probably happen. It's more a question of when, really. I'm currently hip-deep in a bold new open-source Python project into the uncharted recesses of the human soul, which consumes my precious volunteer resources. Once I excrete out the next stable release of that sometime, RetroArch on Gentoo might be next up to bat.

Let's see what the dismal future brings, friends. 🙉

from abendbrot.

Also, obligatory necrobump.

from abendbrot.

It's not dead yet.
Literally all I need to do is write a new ebuild for common-shaders, and it'll be pretty easy to get everything upstreamed.

from abendbrot.

That "10,000 commit" PR is not what it appears to be. IIRC, all PRs that were filed before our infamous GitHub hack ended up in this silly state. Perhaps most of them were closed automatically and we lost track. At least we have some of the cores in the tree now. I wasn't aware that @candrews lost interest. These things fall behind quickly. Although I have a passing interest in RetroArch myself, I'm already struggling with the day to day games issues. More manpower please.

from abendbrot.

Hi yes oops I'm back

@jason-oliveira have you made any progress on getting the RA stuff upstreamed?

I was looking at diving into getting it running on my new RPi 4, and I finally remembered to check Github

from abendbrot.

@IntelMiner not upstreamed, but stable ebuilds are being updated at my gitlab repo:
https://gitlab.com/jason.oliveira/retroarch

The plan is to 1) update master overlay list with my repo, and 2) submit ebuilds upstream and watch them lose their minds at USE="-cores" being default.

from abendbrot.

I should probably footnote that last point by letting people know that my repo uses cores built by RetroArch's buildbot, installed to userspace. As such, I have not updated all the individual cores. Considering RA builds for each arch Gentoo supports, this shouldn't provide too many issues. Feel free to launch hate and vitriol at me for this decision if you run into problems while I'm making this nice enough to upstream.

from abendbrot.

@jason-oliveira If I'm understanding you correctly. You mean that your ebuilds simply install the pre-built RetroArch binaries from upstream?

from abendbrot.

@IntelMiner Nowhere near that elegant. I just made a blatant "screw you, let retroarch manage that part in userspace" USE flag so that RA would install cores inside it's own manual downloader to wherever /etc/retroarch.cfg and/or ~/.config/retroarch/retroarch.cfg tells them. I personally prefer ~/.local/share/retroarch. Portage is completely out of the picture when it comes to installing an RA core. games-util/lutris (somehow upstreamed) does something similar for wine and libretro cores already, so a useflag to enforce this mode seems to be the best decision, at least short-term while preparing things for upstream (which will probably need all the old cores, plus all the new ones, as ebuilds).

from abendbrot.

@jason-oliveira Fair enough. Are there any plans to break things out into their own source builds? I suspect what I'm going to be doing with RA is going to require patching cores and lots of fiddling. But the thought of writing an ebuild for every core is a nightmarish prospect

from abendbrot.

@IntelMiner One would assume you do not have to disable USE="-cores" in order to build an individual core.

The current plan is to steal liberally from this repo's (or @barbudreadmon 's) ebuilds for cores, and update them to current. An ebuild per core is required, and there have been lots of cores added to RA since @stefan-gr went AWOL.

An easy flowchart (read: patches/pull requests welcome) would be:
Locate abendbrot retroarch core ebuild -> update to current -> make changes you want -> submit to repo.

from abendbrot.

It's the same as with kodi pretty much, binary plugins are in separate ebuilds ( including retroarch cores ). Scripts are downloadable.
Just cherry pick the recently updated/still being developed ones ( cores )
There's a lot of dead cores out there, no need to cram in them all.
I'm using vortex repo for RA stuff, it has up to date ebuilds of some cores

from abendbrot.