Does RetroPie support Debian 'testing' branch?

fc7

Subject says it all.

I'm using RetroPie for years now. On RPi, x86 and even in a docker container. :)
Always building on Debian stable branch.

Recently I upgrade the GPU on one of the PCs but unfortunately the current kernel and mesa versions in Debian stable are getting a bit old to best support the new GPU. So I went ahead and tried to build RetroPie on Debian testing instead which has more current versions than stable. Debian 'testing' is something in between Debian 'stable' and 'unstable' in terms of stability and is the base for the next stable release so it should be stable enough.
Anyway, I went through the source code and found that Debian 'unstable' while not officially supported will be identified as Debian 'stable' (currently version 11):

https://github.com/RetroPie/RetroPie-Setup/blob/b11c10a086c8e5ae3f4681dd01cf567cddf20e33/scriptmodules/system.sh#L178

but I couldn't find anything about Debian 'testing' branch. So I'm wondering if it's supported or not.

As a side note, RetroPie is failing to build on Debian 'testing' because of the new ffmpeg 5.0 that is used instead of 4.x. While troubleshooting the problem I found that RetroPie is not actually using RetroArch's source code directly but it's own fork. RetroArch added support for ffmpeg 5.0 around mid-Feb this year.

Do you have any ETA on when RetroPie's fork of RetroArch will be updated to a newer version (maybe 10.0.3)?

Thanks

mitu

@fc7 said in Does RetroPie support Debian 'testing' branch?:

Subject says it all.

Not specifically, but since usually Ubuntu releases some version based on testing at some point, when we add support for Ubuntu it will trickle down to testing. In this case Ubuntu ~~21.10~~ 22.10 (the upcoming Kinetic Kudu) includes ffmpeg v5 and will have the same issue.

We'll add at some point (sooner than later) support for RetroArch 1.10.3 and this issue will be fixed.

fc7

Thanks a lot for your reply.
All clear now. Looking forward RetroArch 1.10.3 to switch my builds to Debian 'testing' then.

mitu

As a workaround, until proper support is added in RetroPie, you can modify $HOME/RetroPie-Setup/scriptmodules/emulators/retroarch.sh
and change

rp_module_repo="git https://github.com/RetroPie/RetroArch.git retropie-v1.10.0"

to

rp_module_repo="git https://github.com/libretro/RetroArch.git v1.10.3"

and try to install from source. Revert the changes after installation, if you wish to be able to update the RetroPie-Setup script afterwards.

fc7

Will try this later today or during the weekend. Thanks for the tip.

Out of curiosity, and without going into many details as I don't want to take much of your time, what kind of patching is RetroPie doing over RetroArch source that it's using a fork instead of unmodified source?
Asking just to be aware of what I can expect from using RetroArch source directly over RetroPie's fork.

And one more, would it be possible to change https://github.com/RetroPie/RetroPie-Setup/blob/b11c10a086c8e5ae3f4681dd01cf567cddf20e33/scriptmodules/system.sh#L178 to match 'testing' or 'unstable' with Debian current as it is done currently for 'unstable' only?
This small change would allow anyone checking the source to understand that while 'unstable' and 'testing' are not officially supported they are still handled by RetroPie scripts.
What do you think?

Thanks in advance.

mitu

@fc7 said in Does RetroPie support Debian 'testing' branch?:

Out of curiosity, and without going into many details as I don't want to take much of your time, what kind of patching is RetroPie doing over RetroArch source that it's using a fork instead of unmodified source?

You can view the changes here, but they're basically 3 simple changes:

the re-addition of th 'video_shader' parameter to the config file, which was removed by RetroArch at some point. This makes it easier to configure shaders with the Configuration Editor per-system, without having to save a shader preset for each libretro core.
disables the search menu. I'm not quite sure of the reasons is there, but I think it's because once you're in the search menu you can't back out without a keyboard.
allows the default save path to be in the rom folders (this was default until removed by RetroArch last year).

And one more, would it be possible to change https://github.com/RetroPie/RetroPie-Setup/blob/b11c10a086c8e5ae3f4681dd01cf567cddf20e33/scriptmodules/system.sh#L178 to match 'testing' or 'unstable' with Debian current as it is done currently for 'unstable' only?
This small change would allow anyone checking the source to understand that while 'unstable' and 'testing' are not officially supported they are still handled by RetroPie scripts.

I think the issue with testing is that doesn't have a numeric version (lsb_realease -sidrc) and this trips the parsing. I'd rather we don't maintain this each time stable changes, right now the scripts issue a warning that testing is not understood, but it's not fatal and - barring issues such as yours - things mostly work.

fc7

Indeed.
'testing' doesn't have a version number, in the same way as 'unstable'.

So https://github.com/RetroPie/RetroPie-Setup/blob/b11c10a086c8e5ae3f4681dd01cf567cddf20e33/scriptmodules/system.sh#L178 could be changed to:

if [[ "$__os_release" == "unstable" || "$__os_release" == "testing" ]]; then

To match either and just go ahead same as with 'unstable'.

fc7

Just wanted to confirm that building RetroPie on current Debian ‘testing’ using RetroArch’s 1.10.3 source works perfectly.

Thanks!