Add to F-Droid

[prusnak]

so people can install OBW easily from F-Droid store.

SBW was added to F-Droid here: https://f-droid.org/en/packages/com.btcontract.wallet/

I can help with the inclusion, but I need the permission of the upstream to include it. What do you think @fiatjaf?

[prusnak]

Trying to build from source on F-Droid, the build failed because it cannot find com.fiatjaf:immortan_2.13:0.7.11-SNAPSHOT. And indeed the last published version vas 0.7.10 as can be seen here: https://mvnrepository.com/artifact/com.fiatjaf/immortan_2.13

Is it possible to avoid the SNAPSHOT version of the dependencies in the tagged releases?

[fiatjaf]

Yes, sorry about that. This snapshot thing wasn't supposed to happen, but I was fixing a bunch of bugs simultaneously and it ended up happening. The next release will be clean as Immortan is more stable.

[prusnak]

No worries. I'll patiently wait for the next release.

About the inclusion: are you OK with me adding OBW to F-Droid? I need explicit approval from you in order to to proceed.

[fiatjaf]

I am OK and very grateful for that. I intended to do it but couldn't parse the steps and requirements yet.

But how do we manage releases there? Can I trigger a new release there whenever I make a new release here or do I have to ping you? How does it work?

[prusnak]

Can I trigger a new release there whenever I make a new release here

There are several strategies that can be configured in F-Droid. In my opinion, the best strategy is to let F-Droid automate the release when there is a new tag in the source repository. However, this means that you should never tag an unstable commit, but only commits that you really want to share with F-Droid users as a new update.

See https://f-droid.org/docs/Build_Metadata_Reference/#UpdateCheckMode for more info.

[fiatjaf]

Yes, let's do that. It will keep me honest and ensure I'll never publish an unbuildable release (like the current) ever again.

[prusnak]

ensure I'll never publish an unbuildable release

I guess nothing bad will happen even if a tag can't be built - most probably F-Droid will just skip this update. But yes, it's always better to tag buildable releases.

[fiatjaf]

@prusnak if you're still willing to proceed with this it would be great. There is a new release now and no SNAPSHOT dependencies. It was built just fine on GitHub Actions so it should for you too.

[prusnak]

Great!

I created a merge request to fdroid/fdroiddata repository here: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/12216

Once this is merged, hopefully nothing else needs to be done and every time you tag a release here, the F-Droid will try to build it and everything goes well, it will publish the update to their story. Everything should happen automatically (the auto-update script will update the Builds part of the YAML to contain new builds).

[prusnak]

Can we add changelogs to fastlane dir? PR here: #27

It was requested in the F-Droid MR here: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/12216#note_1201349964

For reference, SBW had changelogs here: https://github.com/btcontract/wallet/tree/master/fastlane/metadata/android/en-US/changelogs

[fiatjaf]

So, what happens now? Apparently you've fixed all the things they requested on the F-Droid PR, but then the discussion stopped. What can I do to move it forward?

[prusnak]

What can I do to move it forward?

Not sure, I bumped the conversation in the GitLab: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/12216#note_1224757130

So it seems we still haven't resolved the apksigner issue, but it seems to me that "Reproducible builds" are just suggested, not required or recommended.

Can we proceed with merging this PR and deal with the apksigner issue later?

Edit: I also bumped the version in the PR to v0.2.1