Closed ghost closed 1 year ago
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.
I would also prefer to bundle no cores and keep the downloader enabled.
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?
@IzzySoft I don't have any insight on when releases or tags are made, sorry.
Thanks Braden – then who does? @LibretroAdmin seems to have suggested you would, but it looks like I misunderstood the suggestion then. F-Droid is just waiting for a new tag to be able to pick up again.
It is libretroadmin who makes the tags/releases, we just haven't done a stable in >4 months. It's probably about time to do so, though, and if that's what's holding us up, we should consider doing it ASAP.
Just let us know please (here or at the RFP) when it's available. Thanks a lot!
I spoke with him today and it sounds like we might have something going within the next week or so. I'll be sure we ping you here once it's done. Thanks!
Due-date of the RFP was reached for the third time now, but it seems this is still hung. Will lift it one more time – but we don't want to keep it open eternally I guess :wink:
It's taking us time to get a new stable out. We hope to have something out before the end of this month.
@IzzySoft the new tag was just added. Let us know if we need to do anything else on our end.
Thanks! I've removed the due date from the RFP and triggered another issuebot scan. If results permit, hopefully it will be picked up for a merge request soon.
Thanks! Keep us posted if we need to do anything else to get it rolling :)
We'll at least ping you from the RFP then. As building your app is far beyond my expertise, I've pinged another maintainer who promised to take a look. Might still take a little as I guess his queue is well filled, so please bear with us :wink:
Feedback pls: https://gitlab.com/fdroid/rfp/-/issues/1933#note_1125250001
/LE: fastlane looks ok, except a missing changelogs/1597175252.txt
here https://github.com/libretro/RetroArch/tree/master/fastlane/metadata/android/en-US ;)
Does the changelog need to be in a specific format? Or could we just copy our main CHANGES.md into that location with the version string as the name?
Just a .txt file with some (not huge though) info on changes
We have a file called CHANGES.md in the root of the repository, is there not a possibility you guys can just copy and paste that on your end in some way to form the package? That way we wouldn't have to duplicate files and keep maintaining it whenever we push an update.
These are different things, we can link to such a file, yes.
But the changelog .txt appears in the app description on top, eg. https://f-droid.org/packages/im.quicksy.client/
oh yeah, we wouldn't want our full changelog there, I suppose :O
For a BAD practice, you can just point it to a fixed URL like https://www.libretro.com/index.php/category/blog/ or https://github.com/libretro/RetroArch/blob/master/CHANGES.md, if that's what remains before shipping RetroArch onto F-Droid (at last).
Tutanota did that for their F-Droid package:
New in version {{xxx}}
see: https://github.com/tutao/tutanota/releases
Again this is BAD as it per se tells nothing, but if I read right, we are shipping the tagged stable releases, so checking the url a few times a year is not that bad for me.
So much talk about a bit of text, but no one tested the actual APK? :)
@licaon-kter Sorry I should have clarified that I'm not a contributor, just a passer-by user giving random suggestions I think up that may help the developers.
I downloaded the APK from RFP, and made a quick test on two devices (regular phone running Android 12 & Switchroot running Android 10), here is the only problem I could find:
The features I tested that work:
I didn't test other features like import content, GLSL shaders, cheats, achievements etc, but I think it's supposed to be ok❤️
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.