Do you mind if I write a request to be added to F-Droid?

[d4rken-org]

Do you mind if I write a request to be added to F-Droid?

[d4rken]

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 😮‍💨.
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 👋🏻

[d4rken]

@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 🥲.

[d4rken]

@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 😦

[licaon-kter]

@IzzySoft we're not there yet, still waiting for the devs about other issues, afaik

[jv-k]

I recommend using ver-bump as a globally installed package, it's superior to that gist that I wrote 🙌🏼

[d4rken]

https://gitlab.com/fdroid/fdroiddata/-/merge_requests/12569

[d4rken]

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

[Artem13327]

Is crowdin-cli.jar needed to build?

What to specify in the field developer and developer mail?

[d4rken]

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 😅.

[Artem13327]

It is also desirable to tell the site of the developer

[d4rken]

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

[licaon-kter]

@d4rken halp https://gitlab.com/fdroid/rfp/-/issues/2222#note_1116255404

[Artem13327]

This already seems to have failed 😦
😅

[IzzySoft]

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 😉 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.

[Donkey-Doug]

There currently is no release to download in fdroid. I cannot download this app other than manually downloading github releases.

[licaon-kter]

@Donkey-Doug you've seen already that https://gitlab.com/fdroid/rfp/-/issues/2222#note_1116255404 is still open and not merged, right?

[the4anoni]

For some reason IzzyOnDroid version doesn't install, it requires android.hardware.type.watch.

[licaon-kter]

@the4anoni think it's: https://gitlab.com/fdroid/fdroidclient/-/issues/2430 ;(

[the4anoni]

@the4anoni think it's: https://gitlab.com/fdroid/fdroidclient/-/issues/2430 ;(

It actually doesn't install directly from APK.

[IzzySoft]

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?

[the4anoni]

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?

Now it works as it should :)

[d4rken]

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.

[licaon-kter]

...
> 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

[d4rken]

What's the plan with bugsnag?

Didn't I move that into an extra flavor? 🤔
I'll look into it, give me a few hours.

[d4rken]

@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 ☹️ Gradle 😠
edi2: Okay pr checks pass ☺️

I don't mind if there is no extra work for me.

🥲 famous last words

[IzzySoft]

@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.

[IzzySoft]

I'd be okay with keeping both if you think there is benefit. Your solution was very low maintenance so far for me ☺️.

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.