Hello! is this normal that my app still hasn’t been updated on F-Droid and is currently stuck on version 7.4.7, even though 7.5.1 was released about a week ago. Is there usually a delay before the new version gets picked up?
thanks ! didnt know this change on my gradle was causing problem for your update bot ?
Traceback (most recent call last):File “/home/fdroid/fdroidserver/fdroidserver/build.py”, line 1208, in mainif trybuild(app, build, build_dir, output_dir, log_dir,~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^also_check_dir, srclib_dir, extlib_dir,^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^tmp_dir, repo_dir, vcs, options.test,^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^options.server, options.force,^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^options.onserver, options.refresh):^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^File “/home/fdroid/fdroidserver/fdroidserver/build.py”, line 921, in trybuildvcs.gotorevision(build.commit, refresh)~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^File “/home/fdroid/fdroidserver/fdroidserver/common.py”, line 1645, in gotorevisionraise excFile “/home/fdroid/fdroidserver/fdroidserver/common.py”, line 1634, in gotorevisionself.gotorevisionx(rev)~~~~~~~~~~~~~~~~~~^^^^^File “/home/fdroid/fdroidserver/fdroidserver/common.py”, line 1780, in gotorevisionxraise VCSException(_(“Git fetch failed”), p.output)fdroidserver.exception.VCSException: Git fetch failed==== detail begin ====From https://github.com/N-Zik-Group/N-Zik- [deleted] (none) → v7.4.7-dev-20260813- [deleted] (none) → v7.4.7-dev-20260814* [new branch] dependabot/gradle/media3-1.11.0 → origin/dependabot/gradle/media3-1.11.029f1f36fe..e40aff42d l10n_main → origin/l10n_mainab73efec1..1623018d1 main → origin/main* [new tag] v7.5.0-beta → v7.5.0-beta* [new tag] v7.5.1 → v7.5.1* [new tag] v7.5.1-dev-20260909 → v7.5.1-dev-20260909* [new tag] v7.5.1-dev-20260910 → v7.5.1-dev-20260910Fetching submodule modules/betterlyricsFrom https://github.com/N-Zik-Group/Better-Lyricse88ae61..1249e2d main → origin/mainFetching submodule modules/nextvisualizerFrom https://github.com/N-Zik-Group/Next-Visualizer9de5b6d..8c2b105 main → origin/mainfatal: remote error: upload-pack: not our ref 8432aa9161d11d966f376171f8e12220a31b3143fatal: remote error: upload-pack: not our ref cdc9189ac7947d219e91bd5117696880582c004bErrors during submodule fetch:modules/nextvisualizermodules/betterlyrics==== detail end ====
Is there an issue on my side? My submodules are currently on the main branch. Maybe I broke something when I updated them. I suppose I’ll need to push a new release to fix this. Sorry for the inconvenience!
@Licaon_Kter hello, could you check if my app have smth wrongly configurated? because dont seems to update thx !
Bookmark https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/com.nevar.nzik.foss.yml
Open it
See a green pill in the upper right
Open bot: Update N-Zik to 89 (!49479) · Merge requests · F-Droid / Data · GitLab
See the failed CI log: fdroid build (#16609182511) · Jobs · F-Droid / checkupdates-bot-fdroiddata · GitLab
Hi, thanks for the look! @Licaon_Kter
The binary mismatch is a build-config issue on my side, not a metadata one. The foss APK on my release and the F-Droid build are built from the exact same commit (f539bcb4, tag v8.1.0 I verified it via the Actions API), but my GitHub release pipeline injects Last.fm API credentials into buildConfigField via environment variables (System.getenv(“LASTFM_API_KEY”), with an empty-string fallback when absent). The F-Droid build has no such env vars, so the release APK contains the real keys while the F-Droid build contains empty strings → different dex files → the comparison fails.
These are client-side Last.fm API keys that are already publicly extractable from my release APKs, so this is purely a reproducibility issue, and I am not looking to pass secrets into the F-Droid build.
I’d like your guidance on the cleanest way forward:
- Force the foss build type to build with empty keys (the Last.fm feature is simply disabled in the store build the app already handles that), or
- Commit the keys in the repository so every build (GitHub and F-Droid) produces a bit-for-bit identical FOSS APK.
I’ll do the same for the other key read from local.properties to keep the whole build deterministic
Update: I found a clean solution and have implemented it on my side.
I will commit the Last.fm key and secret in the repository (a build.properties
at the repo root). The Gradle build resolves the values in this order:
local.properties (dev machines) → build.properties (committed) → environment
variables → empty. Both the GitHub release pipeline and the F-Droid build read
the same committed file, so they produce bit-for-bit identical FOSS APKs no
prebuild, no secrets, no external URL involved.
This is the approach the Inclusion Policy prescribes (“Even if provided by a
third party, we include them in both binary and source code releases”), and it
is what RiPlay already does on the official repo. The values are also already
publicly extractable from my release APKs, so committing them exposes nothing
new. For transparency: alongside the real values, the build file carries a
dozen random decoy constants compiled into the APK as unused fields the same
anti-key-harvester scheme RiPlay uses (friction for automated scrapers, not
access control).
i push a 91 update with this fix, you can close this merge and 90 one