Obtainium
Obtainium copied to clipboard
ImranR98
F-Droid inclusion
Hi,
Since this app is FLOSS itself, it could be a good idea to add it to F-Droid, so that people knows about it and use it.
What do you think?
If it was on F-Droid, Obtainium would not be able to update itself (because F-Droid apps have their own signature). That's fine, but it means there would have to be a separate build of the which does not automatically include Obtainium as a tracked App out of the box (because then it would try to update itself from GitHub and fail). Right now that's hardcoded but can probably be changed to be optional based on a build option or something.
But is not a priority especially since part of the motivation for this app was to move away from F-Droid. Will leave the issue open but may not get around to it anytime soon.
Perhaps a separate repo that can be added to F-Droid would be a solution for now?
Perhaps a separate repo that can be added to F-Droid would be a solution for now?
Obtainium is now on the IzzyOnDroid repo: https://apt.izzysoft.de/fdroid/index/apk/dev.imranr.obtainium
@rollingmoai does this require any maintenance when the app is updated? Or does it automatically grab everything from GitHub?
It automatically grabs everything from GitHub, so you don't have to worry about it.
@ImranR98
(because F-Droid apps have their own signature)
That's not a problem if the app is reproducible... but
Obtainium would not be able to update itself
F-Droid would like this to be opt-in :)
Obtainium would not be able to update itself
F-Droid would like this to be opt-in :)
@licaon-kter Maybe some misunderstanding about this? Obtainium "updates" itself just the same as an app store does, like F-Droid and its forks. It just makes use of its core feature and ability of downloading and installing any app added by users. Except for the fact that Obtainium is added on list in advance (a workaround is to replace the GitHub url for F-Droid url upon publishing on F-Droid, or ask users to choose upon initialisation), I don't feel it a real problem since it doesn't exclusively add a module for self update like how common apps typically do.
@ImranR98 Maybe we can review this since signature is not a problem now as licaon-kter mentioned. And if you don't reject this idea, it's should be not hard since licaon-kter can help with it.
@momobobe the repro idea is "the app is reproducible and F-Droid hosts the APK from the developer AFTER it verifies that reproducibilty"
An in-app updater bypasses any verification, so users that put their trust in F-Droid get "lied" (strong word, bare with me) that all the app updates were verified.
FYI, almost every F-Droid cycle there's a repro app that fails verification.
So, to make things clear, an opt-in app updater is okay, as long as the user turns it on and gets informed that then the update comes straight from the developer.
@ImranR98 can you please build and attach fdroid flavor builds as well to regular ones when you upload new releases?
@ClockGen I can't build fdroid flavours (i mean i can build it, but it wouldn't actually be signed by f-droid). That needs to be done by f-droid when/if the app is published there.
@ImranR98 Weird, I thought that F-Droid maintainers are currently waiting for you to publish f-droid flavor apks so they can set up reproducible builds (so apks signed by you are published in f-droid), with the only changes that f-droid flavor has, is that the package id is different and obtainium doesn't add itself to app list automatically https://github.com/ImranR98/Obtainium/pull/236. (Here's fdroiddata merge request: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/12514)
Thanks for the links, I forgot where the issue was. I'll include F-Droid builds with the next release.
@ImranR98 Do you want reproducible build for the F-Droid build? I'm not sure if it's what you want. With reproducible build the apk signed by you will be published directly. I ask because the PR for that was merged but the target branch is removed. For reproducible build we still need that to ensure the same flutter version is used. You can also declare the flutter version somewhere else though. Currently you always use the latest stable flutter version.
Since F-Droid needs to build background_fetch from source not sure we can hope for reproducibility
Do you want reproducible build for the F-Droid build?
The F-Droid inclusion issue has been pushed by other contributors from the start (I've only been merging PRs etc.) so I'm not sure. Sounds like reproducible builds may not be possible?
I'll remove the F-Droid APKs from the release assets since it isn't clear whether they will actually be used or if F-Droid will be doing their own signed builds, and they are just causing confusion right now (people accidentally downloading them, causing App ID issues). Instead I can attach the builds to the GitLab issue for now.
I ask because https://github.com/ImranR98/Obtainium/pull/253 was merged but the target branch is removed.
Sorry, I must have deleted the branch thinking whatever it was for had already been merged to main. I can re-merge it into main (https://github.com/ImranR98/Obtainium/pull/1324) if someone indicates that I should do so (not sure if we're still going for repro builds since @licaon-kter mentioned it might not be possible due to background_fetch).
I've merged that PR and updated the Flutter submodule to make sure it's on the commit for Flutter's latest stable branch. I've also updated the GitHub actions CI to crash if I ever forget to update the submodule, leading to a mismatch between latest/stable and the submodule (haven't confirmed it works yet).
Live on F-Droid : https://f-droid.org/packages/dev.imranr.obtainium.fdroid/ Feel free to use their badge: https://gitlab.com/fdroid/artwork/-/blob/master/badge/README.md
