F-Droid APK

[gaul]

Given that there is no direct package from Fox any more perhaps we should try to get F-Droid to include this? I don't think most users will know how to compile themselves and relying on third-party packages will have less trust. References #17.

[courville]

As an interim temporary solution, you can use obtainium to pick the apk that I generated on my fork (for personal use), see https://github.com/courville/tt-rss-android/releases. But I agree we need a long term solution.

[gaul]

Upstream issue: https://gitlab.com/fdroid/rfp/-/issues/135

[courville]

@gaul, I think a new submission should be done instead of reopening this one to get all the right pointers to this new repo.

[gaul]

FDroid packaging made some progress: https://gitlab.com/fdroid/rfp/-/work_items/135#note_3266411953 . One remaining issue is getting a non-zero versionCode. fox introduced a dynamic scheme in 712afbc which seems to confuse FDroid. Claude suggests:

Looking at org.fox.ttrss/build.gradle:100-130, getGitVersionCode() calls git log --pretty=%ct -n1 HEAD and formats the commit date as yyyyMMdd. Two things prevent this from working in F-Droid's scanner/builder:

1. The RFP scanner does static parsing, not execution
   F-Droid's issuebot parses build.gradle without evaluating Groovy, so getGitVersionCode() is never called — it reports versionCode: 0 by default. This is informational and won't block the actual build, but it's what you see in the note.

2. F-Droid's buildserver needs either:

• A literal versionCode in the Gradle file at the built commit, so their static metadata extraction works; OR
• Explicit versionCode: / versionName: in the fdroiddata recipe (metadata/org.fox.ttrss.yml), one per Builds: entry. This is the normal path — the recipe author hardcodes them per release tag.

Either way, F-Droid builds from a specific git tag (set via commit: in the recipe). Your current scheme depends on HEAD's commit timestamp, which is fine if the recipe pins commit: — git history is present in their builder, so git log -n1 HEAD will succeed.

What would make the dynamic computation "just work":

1. Tag releases with annotated tags (e.g., v25.09). The fdroiddata recipe then references those tags and your Gradle code produces a deterministic versionCode from the tagged commit's timestamp.
2. Keep a graceful fallback (you already return 0 on failure at line 128), but consider making it a real number read from a checked-in version.properties or similar, so static scanners and non-git builds produce a sensible value.
3. Document the derivation in the repo so the F-Droid packager (licaon-kter) can write the recipe with matching literal
   versionCode/versionName fields — F-Droid generally prefers recipes where the expected values are explicit and reproducible.

The shortest path to unblocking the RFP is option 3 combined with tags: pick a tag, compute yyyyMMdd from its commit timestamp, and hand licaon-kter the exact versionCode/versionName to put in the recipe.

@supahgreg Perhaps the easiest way to unblock this would be to set versionCode 20260420, versionName 26.04-0276170d in a commit, tag 26.04-xxxxxxxx, then revert the fixed version code?

[supahgreg]

@gaul 26.04-ab99085d

[Terrance]

Was there any more progress here? Looks like F-Droid's bot hasn't ran on the RFP MR since the above change?

[gaul]

I shifted my focus to improving the mobile web experience which I think it more promising. So please push this forward if you have interest.

[Terrance]

I have raised an app inclusion request here: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/45753

Note that I've patched the build config to use JDK 21 (17 isn't available in their Debian Trixie build environment), which doesn't seem to have caused any issues.

[Terrance]

@supahgreg F-Droid are requesting an author name and contact email address for the metadata entry -- do you have a preferred way to be credited?

[Terrance]

There's also a request for verifying reproducible builds -- I'm not sure what the plan here is for cutting release builds, but someone may need to chime in on the PR above with how they want builds and signing to work (I can adjust the proposed submission as needed).

[supahgreg]

@supahgreg F-Droid are requesting an author name and contact email address for the metadata entry -- do you have a preferred way to be credited?

#8 still applies-- I have no intention of supporting this app.