RetroArch
RetroArch copied to clipboard
libretro
[Android] [F-Droid] Current Status of LibRetro F-Doird Repository
Not a bug report, just asking if LibRetro F-Droid Repo is deprecated. The last update dates back to last November while IIRC it should be nightly release like the one in buildbot.
BTW, I notice there is RetroArch Plus on Play Store as mentioned in LibRetro news. If F-Droid repo is not reprecated, would there be two versions of RetroArch in it?
I see there are #4247, #6446 and #7940 so I assmue this is the right place to ask the question.
Similarly, I have recently noticed that https://f-droid.org/packages/com.retroarch (as well as com.retroarch.a32 and com.retroarch.aarch64) now 404s.
Even though 1.9.1 came out a few days ago, indeed there is still no update on the repo. Since F-Droid is listed on Android download section without strike-through line, the repo needs to be updated or unlisted from the download page.
I came here after noticing I cant install retroarch from fdroid... nothing happens when you click on install
F-Droid repository is still at version 1.9 from november . will retroarch releases continue to be released?
There's a guy who has historically set up the fdroid stuff for us. He's been busy for the past few months but has popped in long enough to say that he intends to get it going again soon(TM)
Thanks for the clarification! I guess now we just need a little patience then 😄.
Maybe we should file a request in fdroid-data. But I am not sure, if Retroarch is fully compliant for F-droid.
RetroArch itself is / should be, but many of the cores are not, and I recall they didn't like that it can download "non-free" cores, despite including the license information in the program so users know what they're getting.
Hi, it has been 6 months since the last update. Can you give an update on the current status please? Thank you.
As of writing this, Retroarch is still at 1.9.0_GIT. Isn't there a way to automate this on each new release?
is making a f-droid repo auto update the stable really that complicated ? ~~sorry if i sound rude <3
I just realized how old the build on the libretro F-Droid repo is.
Any chance of an update to this? I am kinda bad updating via APKs alone and keep forgetting to do it, lol. F-Droid would make this easier.
I recall they didn't like that it can download "non-free" cores, despite including the license information in the program so users know what they're getting.
Considering that the Android builds for the Google play store already are bundling custom sets of cores... IMHO, it would be interesting to have a "free" edition of this kind of bundle by including in the APK all the cores that are free and excluding the non-free ones.
That way I expect the F-droid team would have no issue with taking care of distributing and handling this edition themselves from their official F-droid repo. There's probably people interested in a version bundled with cores that exclude non-free ones.
Having an up-to-date f-droid-compatible repository would be very convenient for users. (And some people would prefer a repository with just releases versions, other people would prefer nightly builds: #7940)
Currently, the latest version from the f-droid repository is 1.8.4 from November 2020. And, due to #12181, the latest version from Google Play Store is 1.9.12 from November 2021. We are in March 2022 and the latest release is 1.10.1.
To make the matters worse for the end-user, both Google Play and the f-droid repository are still listed as official ways to download RetroArch: https://retroarch.com/?page=platforms
This leads to users downloading outdated versions without noticing, which can lead to obsolete bug reports and support requests, and also extra time spend by the user to manually install (side-load) a recent version.
@Ferk According to the reply from your post on the F-Droid forum, we should indeed consider "Libre Edition" RetroArch apk with Libretro cores bundled.
From the linked thread:
So the free cores that are GPL-compatible would be bundled in the Retroarch apk, any non-free or license-incompatible core would be excluded, and the downloader that allows obtaining external cores would be disabled.
Who would actually desire this behaviour?
I appreciate the F-Droid project because it gives me freedom and privacy by default (as opposed to the Google ecosystem/Google Play store experience). I don't understand why one would want these artificial restrictions imposed -- I mean, doesn't F-Droid explicitly tolerate "anti-features"? And why force bundling of cores?
FWIW, my preference would be for the vanilla APKs (nothing bundled, nothing disallowed) currently available from the RetroArch website.
Closely related: there's an inclusion request pending with us at F-Droid. Is there any chance we can process that? The scanners found a couple of issues, so it's currently™ (for 4 month) waiting for feedback. Could one of you please take a look and see if that can be solved? Thanks in advance!
The bitmap font is for the RGUI menu, I think, which would be good to keep around if at all possible. I'm not sure about the build.gradle thing.
Ah, that .bin is just a font – OK, there should be no problem with that. Leaves us with the Google Services which seemingly are included (which is what that gradle thing means):
dependencies {
implementation 'com.google.android.play:core:1.8.0'
}
That's a show stopper, as it's proprietary.
Just in case GitLab notifications are missed: the RFP at F-Droid is currently stuck waiting for the question concerning literal version numbers needed for automated update checking (you're using dynamic values currently). Details here, an answer is highly appreciated.
I think those are also being manually updated in the manifest when there's a new release, aren't they? https://github.com/libretro/RetroArch/blob/8b5b1ce96dcba293c4abb65333687b69757907bc/pkg/android/phoenix/AndroidManifest.xml#L5-L6 Also in a bunch of other places for the different platforms: https://github.com/libretro/RetroArch/commit/5ed375b7dfb0c1df3dcf4935c4622bcae3518061
I was pointing to the build.gradle – and there it wasn't set to "fixed values" with the last release. But thanks for the pointer, I'll update the RFP with that detail. Once the merge request was opened, we'll see if checkupdates is looking at the Manifest as well.
Besides that there's no merge request opened yet, any chance we can get the app's metadata (description, screenshots etc) in Fastlane structures here in the app's repo, so you stay in control of it (and F-Droid simply pulls it along with the other updates)?
@IzzySoft I opened a PR with the Play Store metadata added to the repo in Fastlane format, do you mind double checking and make sure the structure is correct?
Wow, even filled multiple layers of (screen size specific) screenshots! Thanks a lot, looks very good! I'll leave a note on the RFP. Can you give me another ping once you've tagged the next release (as bot and build look for Fastlane at the tag)? I'll then trigger another rescan by the bot and see that I can mark it ready for packaging.
@farmerbb the RFP reached its due-date again, so I came checking. Any chance for a new release being tagged soon so we can proceed?
I've been looking at this and I thought I'd see something a few days ago. A bit disappointed to see the due date moved by a whole month :( how likely is it that the 15th of August is accurate?
@farmerbb seems to be missing in action - can't seem to contact him either on Discord.
@KingDuckZ the due date is just a reminder for us to check back with upstream should nothing happen – which is why I'm here again now (the reminder fired, as the next due-date was reached). Seems there#s still no new tag. As @farmerbb seems to be active on Github (according to his profile), is there any chance now for an ETA on the next tag?