Publish on F-Droid (main repository)

[austinhuang0131]

Since Element X is now there, though I'm not sure whether you forking components constitute a blocker.

[SpiritCroc]

Indeed, the main reason why I haven't PRed SchildiNext to fdroid yet are our forks of the Rust libraries (matrix sdk and rich-text-editor), irrespective of whether EleX is on fdroid or not.

In more detail, I haven't had enough motivation to publish these libraries to sonatype/mavencentral since I don't have experience with this yet and it seems like a lot of paperwork. Sonatype seems the best library hosting solution though, considering jitpack doesn't support building Rust libraries afaik.

Currently, I host these libraries on GitHub packages. Unfortunately GitHub requires you to use an API key to retrieve packages, even for public repositories. By now github is apparently no longer interested in opening this up. Now, when it comes to the fdroid main repository, requiring any secrets not available in the public repo for building is a no-go. (Also if we'd hard-code some github API keys in the repo for some throwaway account, github will immediately detect and block, so that won't work either xD).

So I probably need to get through the sonatype application process at some point.

[linsui]

Can't we build those libs? :)

[SpiritCroc]

@linsui I don't know about what means the fdroid tools provide for building these libs, but it's totally possible to build these dependencies locally!

• rich-text-editor can be released to local maven via ./gradlew publishToMavenLocal, such that when you add mavenLocal() to SchildiChat's settings.gradle.kts it can be picked up from there.
• The Rust SDK is a bit more complicated, you need both the actual SDK and the bindings. With these you can run some script will output an .aar into the SchildiChat directory, which the build process will automatically pick up if stored at the correct place. The repos have some READMEs for that but you can also check ./sc_tools/rust_sdk_build.sh in the SchildiChat repo, which I usually call. For release builds, one needs to pass -r as parameter. If one wants to build for a certain architecture separately rather then all at once, that's possible with ./sc_tools/rust_sdk_build.sh -t aarch64-linux-android -r. So if the fdroid build process doesn't allow you to re-use libraries for split ABI then that would speed things up, otherwise probably better to just build the SDK once.

Of course one needs to have a working Rust compiler set up in addition to the common Android build tools, and maybe some more dependencies, I'd need to check the respective READMEs again.

I'm just realizing that picking up the correct revision for the rust-sdk is a bit trickier than just following a single git tag, since the upstream build scripts that I adopted only add a git tag to the rust-components but not the SDK. How I've been doing it when merging upstream releases is fetching it from github releases, which would also work for SchildiChat:

> rust_ver=0.2.22
> curl https://github.com/SchildiChat/matrix-rust-components-kotlin/releases/tag/sc-sdk-v"$rust_ver" | grep ">https://github.com/SchildiChat/matrix-rust-sdk/tree/" | sed "s|.*https://github.com/SchildiChat/matrix-rust-sdk/tree/\\(.*\\)</a>.*|\\1|g"
9be4a0ed8531a37555bdd1d014b7a38015ae9fb6

I assume I could also teach the upstream build scripts to just also add a git tag to the SDK repo itself, but for merge conflicts it's always good to limit the changes I do.

BTW, on my desktop with decent hardware (AMD 5950X) building a release build of the Rust SDK for all architectures takes around 45 Minutes, so whatever runs the fdroid builds would need for allow such build times :)

[linsui]

We can do that, no problem. :)