F-Droid Version Not Updated

[Grossdm]

I noticed that your app (on F-Droid) had not been updated since 2017, so I followed a link in the description and found my way here.

Clearly you have updated the app, is there some difficulty in updating F-Droid?

If I install your app from GitHub, will it update itself?

TIA

[d4rken]

AFAIK f-droid should build a new version automatically based on tagged releases, e.g. https://github.com/d4rken/reddit-android-appstore/releases/latest

I'm not sure if I made a mistake or what's up, anyone else more familiar with F-Droid?

[Grossdm]

Wow you're fast!
Somehow I opened an issue with only a title, and you had responded before I could update my post/issue!

[d4rken]

The app has an update check, but it's not self-updating like via f-droid. Cross updating is also not possible because the github releases are signed by me, while the f-droid updates are signed by the f-droid build servers.

I'd recommend you post on f-droid forums, maybe the build-bot is drunk and needs some assistance or positive encouragement.

Wow you're fast!
Somehow I opened an issue with only a title, and you had responded before I could update my post/issue!

I was just doing my daily email cleanout when I got a notification for Github, 😉 .

[Grossdm]

I just glanced at the F-Droid docs and found this page on app updates.

I do know that you are not the only developer who struggles with F-Droid.

That said, many people do figure it out - surely someone as clever as you can do it! ;-)

[Grossdm]

Oh, also you didn't address one question - if I install your app from GitHub will it update itself?

[d4rken]

We are all volunteers. I'm certain you are just as clever. 💪

Give it a try, If you hit a roadblock due to needing access to something, let me know.

Oh, also you didn't address one question - if I install your app from GitHub will it update itself?

It's everyone's app ❤️. It will not update itself AFAIK. I think someone worked on that but I don't think any code was merged.

[Grossdm]

I have an idea: ask for help.

@IzzySoft, could you look at this app to see why it is not updating in F-Droid?

[IzzySoft]

@Grossdm good idea to ask. Usually I'd say to check the build log – but recently I'm not sure if that's updated correctly (there were issues with the web server part). The package name would help to check. While looking for it here in the repo, I've stumbled upon this – which already partly answers your questions: auto update check will fail as it doesn't "execute" the gradle but just parses it. So those values for versionCode and versionName MUST be literals.

Well, as the same has been done for packageId, I do not see its value and thus it's hard to check how UpdateCheckMode is set at F-Droid. Advices:

• open an issue on fdroiddata asking for a manual update
• fix those settings in build.gradle so automatic update checks can be enabled and work
• let me know the package name and I can check what the current setting is

Ah, here it is. OK, let's have a look. And see what I already expected:

AutoUpdateMode: None
UpdateCheckMode: Tags
CurrentVersion: 0.7.1
CurrentVersionCode: 7100

So unless someone manually requested an update, there won't be any as F-Droid will never notice there are newer versions (AutoUpdateMode: None). I'd strongly recommend solving the gradle issues and then ask at fdroiddata to update AutoUpdateMode: Version v%v, so it would also work for future updates – or at least ask for a manual update now (which then would have to be repeated with each new version).

If you want to go for the "complete solution" (incl. AutoUpdateCheck) but need time to adjust the gradle stuff, I could offer to temporarily take the app into my repo (to have a recent version available ASAP). But note that the signature would then match yours (I'd take the APK you attach here to releases/) and not the one F-Droid uses. Just let me know if you want that, @d4rken – I gladly assist.

[Grossdm]

@IzzySoft, thank you for taking your time to help.

I hope this gets things moving so that more users can benefit from the work done on this project.

[Grossdm]

@d4rken, did you think that @IzzySoft's ideas could be helpful?

If you are amenable to his offer to take the latest release into his own repo (which I have installed in my F-Droid app, BTW), that would be very nice to get the latest release available before committing more time to resolve this.

[IzzySoft]

@Grossdm note I'd just pick the APK from here where it is available anyway. You could do the same if you want that version (would probably require you to uninstall first if you've installed the app from F-Droid, as the signatures won't match). Taking the APK into my repo just makes it easier to (find and) update, plus you'd be notified whenever there is an update. But yes, my offer stands @d4rken 😉

[d4rken]

@Grossdm
I currently don't have time to further look into automating f-droid builds. I dislike hardcoding the versions in the gradle file just so the parser can read it. Maybe there is a nice workaround I currently don't see though? PRs welcome.

@IzzySoft
Feel free to copy the APK into your repo 👍 . Besides courtesy, I don't think you'd need permission from me to do that though, e.g. APK Mirror does the same hundredfold without asking anyone 🤔. It is nice to ask though, a little more courtesy in the world never hurts 😄.

@Grossdm Not sure how much this helps though as users would still need to add his repo, and @IzzySoft still has to manually update the APK too.

[IzzySoft]

@d4rken yes, but courtesy never hurts 😄 Apart from that, in this case the special cause is the confusion it might arise for the unaware by "signature mismatch", so I wanted to make sure not to add another burden on you if you'd not be willing to risk it. Thanks for that!

IzzySoft still has to manually update the APK too.

No, I can enable auto-update here as I only pick the APK, so no build checks on my end. I only check tag names and timestamps (depending on whether I pick the APK from a tag or from a commit – here it will be the tag).

OK, revived it in my repo (was there before it moved to the official repo – good thing I always keep metadata backed up 🤣). Should show up again with the next sync (next regular sync will run in about 20h).

[Grossdm]

Thanks to everyone for helping with this!

[d4rken]

in this case the special cause is the confusion it might arise for the unaware by "signature mismatch", so I wanted to make sure not to add another burden on you if you'd not be willing to risk it. Thanks for that!

I'll just direct all messages to @Grossdm 🤷‍♂️ 😄

[d4rken]

I guess this can be closed now. I hope everyone has a nice weekend!

[IzzySoft]

I guess this can be closed now.

Sure? How was the update in the official repo addressed? Did I miss something? Guess we have a nice work-around with the app being available in my repo again – but the original issue still remains.

Options we have (as I stated a week ago, slightly adjusted):

• @Grossdm opens an issue at fdroiddata asking for an update
• same, but asking to enable AutoUpdateMode: Version v%v
• … opens an MR to achieve one of the above
• someone else does one of the above
• @d4rken asks someone to do some of the above (and specifies his preference)

Don't get me wrong: I happily keep your app in my repo. But I guess users would prefer having it in the official repo.

While we're on it: @d4rken would you consider establishing Fastlane (or Triple-T) with your repo – so provide e.g. screenshots? Both can be used with Playstore (if your app is there) and F-Droid as well, probably even with more. For my repo, I've picked the screenshots manually. Other things Fastlane helps provide are localized descriptions, a featureGraphic, per-release changelogs. If you're interested, I can give more details – or you check here for a starter and follow up the relevant links.

[d4rken]

Sure?

Not really, it was premature. It's a time motivation/issue ☹️ .

I'm currently not able to work much on this, though I'm also not really motivated to do so. The whole thing was supposed to be more of a group effort with 20 or so devs on reddit saying they want to help. I just took the initiative as otherwise I doubt we would have gotten here at all. It's our app, not my app 💪

We can do anything, someone just has to step up. Fastlane is awesome! If you want to add it, send a PR 😉. Regarding the official F-droid Repo, if changing the version in the gradle file to allow parsing is the best solution, then let's do it. I'm sure there are other projects on f-droid with a good way to solve the version parsing issue, someone send a PR and let's do it 😛 .

My preference is that someone else than me should step up, anything not too far of from common practice is okay.

[IzzySoft]

I'm fully with you (which is why I suggested keeping this issue open until really solved). I'm not a dev, though, not even using Reddit myself and already loaded with many other tasks – so I cannot fill those gaps myself.

Thanks!

[Grossdm]

@IzzySoft,
I'd like to do more, but I am out of my depth here.
For example, I don't know what AutoUpdateMode: Version v%v is.

Honestly, it's a bit frustrating to see so many potential solutions proposed but no one willing to "pull the trigger".

If someone in this discussion knows what changes need to be made to a specific file (gradle?), I wonder why a PR is not opened.

🆘🔠🅿️ (a few random emoji to show confusion)

[IzzySoft]

I don't know what AutoUpdateMode: Version v%v is.

It describes by what pattern new versions can be detected. Here, with UpdateCheckMode: Tags, it's a pattern on tag names saying the tag name is the Version (%v; aka versionName in gradle/Manifest) prefixed by a v. As that seems the pattern used here, it would enable F-Droid to automatically detect and queue updates – so this change would even work for future versions.

OK, so what: here you go. I've just prepared the MR to enable auto update check. I won't merge it myself (II've got no build experience, so I better leave it to another F-Droid member to cross-check if it works or I overlooked something). 🤞

[IzzySoft]

@d4rken currently we cannot enable auto update check it seems:

Won't work because version code and name are calculated: https://github.com/d4rken/reddit-android-appstore/blob/v0.9.2/app/build.gradle#L46

We'd need literals here (as update check just performs a simple RegEx scan, it doesn't "execute" the gradle just to check the version as that would be too much overload). Would that be possible?

(PS: Meanwhile, with the next index update your app will be updated to 0.9.2 in F-Droid)

[d4rken]

Would that be possible?

#184 (comment)

Regarding the official F-droid Repo, if changing the version in the gradle file to allow parsing is the best solution, then let's do it. I'm sure there are other projects on f-droid with a good way to solve the version parsing issue, someone send a PR and let's do it

[Grossdm]

@IzzySoft, I just learned (or perhaps re-learned) that a GitLab "MR" is analogous to a GitHub "PR".

Thanks! 😀 (These Pie emoji look strange to me, I hope I'm not posting offensive ones)

[IzzySoft]

Hehe, yeah, "terminus confusius" 😆

[IzzySoft]

@d4rken with F-Droid having caught up with the version, do you still want me to keep the app in my repo additionally?

[d4rken]

@IzzySoft Up to you, if you want to spent time on it, I don't mind either way. I'm not a heavy f-droid user so I think the question should be whether it is positive or negative for users to have the app available from two f-droid repos?

@Grossdm I assume this can now be closed?

[IzzySoft]

OK, I'll remove it again then (to avoid the confusion arising from "signature mismatch" and "2 APKs with the same version"). It's really not much more than moving the metadata file out. Should the need arise again in the future, I can always move it back in, just ping me.

[AllanWang]

CCing myself as I have the same problem with Frost. If I find a solution to my app I'll let you know.

I do think it's a notable burden to expect a constant for version codes. For projects with multiple modules or tags, it becomes more error prone the more we hardcode the values. Hopefully we can come up with a solution.

[IzzySoft]

@AllanWang it's on our wish list for quite a while, but nobody found time yet to implement it. I wouldn't even know where to start (not my area of proficiency). I'm pretty sure if someone made a sound MR, that would be accepted very gladly: working auto-updates reduce the load on our packagers as well and would keep the backlog of manual updates much smaller. If someone wants to look into it: my guess is this place is the context of what would need tweaking, and this would be the function to be tweaked.

[AllanWang]

@IzzySoft I'll take a look, but on a quick glance the code seems to look at build directories and Android manifest, which seems to be after a gradle build. If there are enforced checks before any function call, then there wouldn't be any reliable way to get the version code beyond regex, as everyone would have their own way. And even if we were allowed to supply the version some other way, it would defeat the purpose as it might not match the actual version.

With that, I feel the only way this will work is if f-droid is willing to forgo version checks pre build, or allow for some version check function beforehand (eg through a pre build command)

[IzzySoft]

@AllanWang The gradle checks start here. And AFAIU the idea is to make sure we have a new version (higher versionCode) before we clone the repo. Imagine on each run we'd have to clone several thousand repos just to figure which ones have valid updates 😱

As indicated, I'm not much involved with fdroidserver coding (true, I supplied a few minor tweaks – but nothing on that level), so I'm obviously the wrong person to give good advice. So what I say here is just how I understand it: I cannot speak for the team really working on fdroidserver. I guess what might be acceptable is along the lines: "New tag? Clone, check. Everything fine? Build. Issues (versionCode not increased etc.)? place a marker which tag we checked so we skip it next time." That "marker" could e.g. be a disabled build block for that tag (disabled: <reason>, e.g. disabled: versionCode not increased). But then, that would mean fixing it requires a new tag.

Well, here is certainly the wrong place to discuss this. I just looked where we had it; so may I suggest moving this to Support checkupdate for dynamically generated versioncodes/versionnames? Also relevant in this context: Auto-Update: Support reading Flutter pubspec.yaml files concerning Flutter.