FYI F-Droid disabled Autoupdate #1163
Comments
|
I'm not quite sure how this went from working to broken (given that we haven't changed our versioning for literally years). All releases are tagged, only tags with a trailing ".0" need to be considered (all other ones are beta or other development releases),
seems to correctly do that. The android version code can be retrieved from the manifest that is again completely standard. The version name is hidden away in a resource file, but the tag can simply be used instead of that, and that seems to be what you are doing in any case. In summary we don't seem to be doing anything that would cause things to break and given that it used to work I'm not sure what to do to fix the issue. |
|
Update check mode is either Tags or HTTP, not both. If the data grepped via HTTP points to a version not-yet tagged we can't build anything. The easiest solution, with HTTP, is for you to update the versionName/Code just before tagging, aka at the end of the version development, not like right now.
Not sure, maybe a fdroidserver change. Log: https://gist.github.com/licaon-kter/48c6202e3fbb88df88b66f537cd2eadf |
Why would you build a version that hasn't been tagged? Sorry, but none of the above makes any sense at all. When you checkout the latest tag version you will always have correct versions so why would it on earth matter what they are before or after the tag was created (not to mention that normally I do actually bump the versions immediately before tagging)? Looking at the log it seems the -actual- problem is totally clear: You are grepping through all the different manifest files and are zapping package, version and vercode when they are not present in the specific manifest. But given manifests are actually merged at build time this is totally correct (that the version information isn't present) and avoids duplicating information and potentially having conflicting information in the manifests. PS: and while I can't prove this, I suspect the reason why it was previously working was simply because the manifest files were processed in a different order. |
|
Again, fdroid can either use the Tag and versionCode/Name from build.gradle/.kts and/or AndroidManifest.xml OR get info from those files, not BOTH, not right now. |
|
Then "don't do that", just use the Tag. I think you are assuming something wrong here: that the maintainers and developers of this app have something to do with the build process on f-droid, but we have absolute zero, zilch, nada to do with it. I'm happy to help with debugging and historically we've adapted certain things to help f-droid, after all it provides an important service to users that don't want to use any of the commercial app stores, but that is exactly where the line is. |
|
Of course, my post was just a PSA so you know when users report bugs or complain that their version is old. :) |
|
I have extended F-Droid to support autoupdate for this app and enabled it: |
|
Thanks @jspricke Just to be clear, this means that f-droid no longer has the issue that it is not checking out the tagged branch and due to that it found an unexpected version? https://gitlab.com/fdroid/fdroidserver/-/merge_requests/937 would seem to indicate that the answer is "yes", so thanks again. |
yes |
|
The build is currently failing https://f-droid.org/wiki/page/de.blau.android/lastbuild_1704 unluckily the log is not very helpful Pinging @Bubu |
|
You can find the full build log here: https://monitor.f-droid.org/builds/log/de.blau.android/1704 so it should be build in the next cycle. Btw. the wiki is not really maintained anymore, try https://monitor.f-droid.org/builds/running instead. |
|
Thanks
Well I was just following the links on https://f-droid.org/en/packages/de.blau.android/ which I suspect you are saying should be changed? |
|
fair point, I opened a MR here: https://gitlab.com/fdroid/fdroid-website/-/merge_requests/670/diffs?commit_id=f84b4841d45492d213328f72797bea7a9a5f4a28 |
...as it wasn't really working anyway: https://gitlab.com/fdroid/fdroiddata/-/commits/30c91f91e4b14385743253059fd7476dffb36678/metadata/de.blau.android.yml and we needed to manually fix it
In theory we could use: https://f-droid.org/en/docs/Build_Metadata_Reference/#UpdateCheckMode and grep https://github.com/MarcusWolschon/osmeditor4android/blob/master/src/main/AndroidManifest.xml and https://github.com/MarcusWolschon/osmeditor4android/blob/master/src/main/res/values/appname.xml to get versionCode/Name, but you update them at the start of the development and there's no corresponding Tag at that point so that does not help either.
So, in the future, after each release, someone needs to come and open a MR adding the new version, or at least inform us and, as time permits, we can update it.
The text was updated successfully, but these errors were encountered: