capod
capod copied to clipboard
d4rken-org
Do you mind if I write a request to be added to F-Droid?
I don't mind if there is no extra work for me.
Is this the difference between a 3rd party repo and "the default" f-droid repo?
We already have this: https://apt.izzysoft.de/fdroid/index/apk/eu.darken.capod
/cc @IzzySoft
Is crowdin-cli.jar needed to build?
What to specify in the field developer and developer mail?
Is crowdin-cli.jar needed to build?
No, it's for synchronizing translations.
What to specify in the field developer
darken or Matthias Urhahn
and developer mail?
if it's for admin stuff [email protected] if it's for users [email protected] but f-droid users who have issues should go on GitHub, not email me :sweat_smile:.
AuthorName: Matthias Urhahn
AuthorEmail: [email protected]
AuthorWebSite: https://darken.eu
Donate: https://github.com/sponsors/d4rken
SourceCode: https://github.com/d4rken-org/capod
IssueTracker: https://github.com/d4rken-org/capod/issues
Changelog: https://github.com/d4rken-org/capod/releases
@d4rken halp https://gitlab.com/fdroid/rfp/-/issues/2222#note_1116255404
@d4rken halp https://gitlab.com/fdroid/rfp/-/issues/2222#note_1116255404
I replied there.
I don't mind if there is no extra work for me.
This already seems to have failed :frowning:
Is this the difference between a 3rd party repo and "the default" f-droid repo?
The F-Droid.org repo is more trusted than mine, for good reasons (which doesn't mean my repo is not trustworthy – but more eyes looking on it plus reproducing the build, thus making sure the APK really corresponds to the source etc is something I cannot do alone :wink: So the F-Droid.org repo is the higher goal you are suggested/recommended to aim at – while of course your app is welcome to stay with my repo if you prefer. For some rough comparison, take a look here.
There currently is no release to download in fdroid. I cannot download this app other than manually downloading github releases.
@Donkey-Doug you've seen already that https://gitlab.com/fdroid/rfp/-/issues/2222#note_1116255404 is still open and not merged, right?
For some reason IzzyOnDroid version doesn't install, it requires android.hardware.type.watch.
@the4anoni think it's: https://gitlab.com/fdroid/fdroidclient/-/issues/2430 ;(
@the4anoni think it's: https://gitlab.com/fdroid/fdroidclient/-/issues/2430 ;(
It actually doesn't install directly from APK.
Uh-Oh… Fixed. My updater had grabbed the wrong APK. When I added the app to my repo, there was just a single APK available at each release. Since v2, there are 2 of them attached to releases/: one is WEAROS and the other not. The WEAROS one requires android.hardware.type.watch, the other does not. I've just told my updater to ignore the WEAROS one and replaced the latest release.
@the4anoni please try again after the next sync today at around 6 pm UTC.
@licaon-kter maybe our recipe needs an update then as well, so we (also) build the other one?
@IzzySoft we're not there yet, still waiting for the devs about other issues, afaik
Uh-Oh… Fixed. My updater had grabbed the wrong APK. When I added the app to my repo, there was just a single APK available at each release. Since v2, there are 2 of them attached to
releases/: one is WEAROS and the other not. The WEAROS one requiresandroid.hardware.type.watch, the other does not. I've just told my updater to ignore the WEAROS one and replaced the latest release.@the4anoni please try again after the next sync today at around 6 pm UTC.
@licaon-kter maybe our recipe needs an update then as well, so we (also) build the other one?
Now it works as it should :)
Alright, we now have a release script.
Thanks to some nice scripting work by @jv-k, I had something to start from, my bash isn't great :face_exhaling:.
It bumps the version, writes it to all necessary places, creates a VERSION file that F-Droid can hopefully be setup to parse, and then tags the commit and pushes it.
./release.sh -b -p origin
Option set: Disable committing to new branch.
Option set: Pushing to <origin>, as the last action in this script.
Current version from <VERSION> file: 2.2.1-rc0
Enter a new version number [2.2.1-rc0]:
Parsing 2.2.1-rc0
✅ Successfully parsed 2.2.1-rc0 to 2.2.1-rc0
V_MAJOR=2
V_MINOR=2
V_PATCH=1
V_BUILD_TYPE=rc
V_BUILD_COUNTER=0
Setting version to [2.2.1-rc1 (20201010)] ....
––––––
Parsing version.properties:
Found major, replacing: project.versioning.major=2 -> project.versioning.major=2
Found minor, replacing: project.versioning.minor=2 -> project.versioning.minor=2
Found patch, replacing: project.versioning.patch=1 -> project.versioning.patch=1
Found build, replacing: project.versioning.build=0 -> project.versioning.build=1
✅ Updated [version.properties] file
✅ Updated [VERSION] file
Committing...
✅ [main 63f37e5] Release: 2.2.1-rc1
2 files changed, 2 insertions(+), 2 deletions(-)
✅ Added GIT tag
Pushing files + tags to <origin>...
✅ To github.com:d4rken-org/capod.git
* [new tag] v2.2.1-rc1 -> v2.2.1-rc1
To github.com:d4rken-org/capod.git
01ea08a..63f37e5 main -> main
––––––
✅ Bumped 2.2.1-rc0 –> 2.2.1-rc1
Done 👋🏻
I recommend using ver-bump as a globally installed package, it's superior to that gist that I wrote 🙌🏼
I recommend using ver-bump as a globally installed package, it's superior to that gist that I wrote 🙌🏼
I'd still have to modify it too, to fit this use-case. I don't have a package.json that I need to bump but a custom gradle properties file.
...
> Task :app:packageFossRelease
> Task :app:bugsnagReleaseFoss-releaseTask FAILED
WARNING:API 'ApkVariantOutput.getVersionCodeOverride()' is obsolete and has been replaced with 'VariantOutput.versionCode()'.
It will be removed in version 7.0 of the Android Gradle plugin.
Gradle Properties must be used to change Variant information.
For more information, see https://d.android.com/r/tools/use-properties.
To determine what is calling ApkVariantOutput.getVersionCodeOverride(), use -Pandroid.debug.obsoleteApi=true on the command line to display more information.
WARNING:API 'ApkVariantOutput.getVersionNameOverride()' is obsolete and has been replaced with 'VariantOutput.versionName()'.
It will be removed in version 7.0 of the Android Gradle plugin.
Gradle Properties must be used to change Variant information.
For more information, see https://d.android.com/r/tools/use-properties.
To determine what is calling ApkVariantOutput.getVersionNameOverride(), use -Pandroid.debug.obsoleteApi=true on the command line to display more information.
Bugsnag: Uploading to Releases API
{"errors":["API key not recognised: deadbeef"],"status":"error"}
> Task :app:createFossReleaseApkListingFileRedirect
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:bugsnagReleaseFoss-releaseTask'.
> java.util.concurrent.ExecutionException: java.lang.IllegalStateException: Bugsnag request failed to complete
What's the plan with bugsnag?
Recipe:
- versionName: 2.7.2-rc0
versionCode: 20702000
commit: 48fd3543e3ca947c06a9b5e805dfeed051538678
subdir: app
gradle:
- foss
rm:
- crowdin-cli.jar
prebuild:
- cp ../version.properties .
- sed -i -e 's/${bugsnagApiKey}/deadbeef/' ../app-wear/src/main/AndroidManifest.xml
src/main/AndroidManifest.xml
What's the plan with bugsnag?
Didn't I move that into an extra flavor? :thinking: I'll look into it, give me a few hours.
@licaon-kter Thanks, can we recheck against this branch (#88): https://github.com/d4rken-org/capod/tree/foss_fdroid_tweaks
or should I create a release with this?
edit: nvm build fails :frowning_face: Gradle :angry: edi2: Okay pr checks pass :relaxed:
I don't mind if there is no extra work for me.
:smiling_face_with_tear: famous last words
@d4rken do you want me to keep it in my repo once it becomes available at F-Droid? I see you've mastered the "supreme discipline" and are going with reproducible builds, so there'd be no conflict: users can install from F-Droid (for added trust) and profit from faster updates via my repo if they wish.
@d4rken do you want me to keep it in my repo once it becomes available at F-Droid? I see you've mastered the "supreme discipline" and are going with reproducible builds, so there'd be no conflict: users can install from F-Droid (for added trust) and profit from faster updates via my repo if they wish.
I'd be okay with keeping both if you think there is benefit. Your solution was very low maintenance so far for me ☺️.
Not sure what I did do for reproducible builds, but it did require quite some patience to get it all to work in the end 😅.
Thanks to @licaon-kter who helped me along 🥲.
I'd be okay with keeping both if you think there is benefit. Your solution was very low maintenance so far for me :relaxed:.
Glad to read it was easy going – and marked for keep. Once it shows up at F-Droid, on my repo's website it will have the hint of being available in both places.
And yes, sometimes RB works out-of-the-box, at other times it needs some tweaking. Luckily the cases we cannot get it working and have to give up are few.
https://github.com/d4rken-org/capod#license
I wonder what's the license of those assets 🤔 because F-Droid already use them. No license means F-Droid should add "Non-Free Assets" AntiFeature in my opinion.
@d4rken I'm afraid @shuvashish76 is right there and we'll have to add the NonFreeAssets then. Unless that section is meant as "not covered by GPL but …" – and the "but" is another libre license (e.g. CC-BY 4.0 or CC-BY-SA 4.0, see here for a list of options). Can you please clarify?
Thanks for the ping @IzzySoft , sorry for missing your comment @shuvashish76.
The excluded assets are not available under another libre license at this time.
I'm not super well versed in the open-source license details, maybe you could educate me here. I've read conflicting opinions online about whether the GPL3 only covers source-code, not assets like icons, by default.
Looking at other projects on F-Droid without the NonFreeAssets tag, some projects specify and extra license for assets and some don't.
My intention is to disallow just copying the app 1:1 and e.g. just adding ads. To prevent bad actors from creating a look a-like to trick users.
I would be okay with adding the NonFreeAssets tag. I think the source-code is what is
important for users to review, and to other developers to build upon. The icons are not that important to this cause.
Note that other projects of mine have similar license setups, so we will have to add the NonFreeAssets tag there too.