Non-FOSS in F-Droid build - io.objectbox:objectbox-gradle-plugin

[licaon-kter]

Ref: https://github.com/owntracks/android/blob/v2.4.10-beta2/project/settings.gradle.kts#L11

Ref: objectbox/objectbox-java#560

Ref: https://gitlab.com/fdroid/fdroidserver/-/merge_requests/1150

[licaon-kter]

ref: https://gitlab.com/fdroid/fdroiddata/-/commit/be6b00ca4d7f6b060ff2ae64df2afc4a47ab1e0f

[growse]

Oh, boo. Obviously this is not ideal - I had thought (somehow) that objectbox was FOSS.

Will resolve for the next release. Thanks for raising.

[LeoColman]

@growse
If you're looking for an alternative, I've considered

• Realm
• Room
• LitePal
• SQLDroid + KTorm

And ended up with SQLDelight.
I found it easy to use, it's very well maintained and seemed to me the closes solution with the "easier" migration.
I decided to bump it to a new major version instead of trying anything to migrate the previous database. My app already had an Export/Import option.

All commits related to this can be found in LeoColman/Petals@b00f1e4...3.0.2

I tried to keep the history as clean and clear as possible to facilitate migration for others.

[growse]

Thanks, I was leaning towards Room but I'll have a look at the others.

I've also got a branch here where I've removed the problematic gradle plugin and have just imported the object libraries directly (they're from maven, so not a problem). If I then "vendor" the plugin output classes into the codebase, everything seems to work. It doesn't feel like this is a long-term solution, but might be a short tactical way forward until a proper replacement can be found. Whether that's acceptable to F-Droid or not, I don't know.

[licaon-kter]

Reading Nonononoki/Hendroid#70 (comment) sounds like it's not gonna work?

[growse]

Oh, that's annoying. I wonder where in the source it's calling out to the native lib?

[LeoColman]

https://github.com/objectbox/objectbox-java/blob/556d9652babda6a7aeca64396dc827bea8f35e82/objectbox-java/src/main/java/io/objectbox/internal/NativeLibraryLoader.java

I think this is the leaf point

[licaon-kter]

@growse fyi https://gitlab.com/fdroid/fdroiddata/-/issues/2776

[growse]

Was fixed in #1436

[licaon-kter]

@growse great, ping us when the release is tagged ;)

[lerra]

@growse any eta ? Once again, big thanks for the effort :)

[trutas83]

Are there any blockers that prevents releasing this?

[jpmens]

It will be released when it's ready.

[rlees85]

yet the issues are closed, code merged and not on fdroid? I'm thankful for all open source projects, this one I am yet to try, but feel it would be beneficial to have a issue, that is open, tracking whatever is blocking the fdroid release.

if fdroid is becoming more hassle than its worth for the project, it would be good to have that clarity.

edit: i only post this as unless I have got mixed up, there has been releases on Github that contain these fixes, so there has been a release but seems not a submission to fdroid.

[mcoms]

I've been following these issues as I'd also like to see the app on F-Droid. The reason it's not there is the code changes haven't been released yet (there isn't a Github release, or a tagged version containing them).

Although the subsequent releases v2.4.11 and v2.4.12 were made in August, chronologically after the objectbox work was merged in July, they were hotfix releases with some specific commits and did not contain all of the changes in master. See v2.4.10...v2.4.11 and v2.4.11...v2.4.12. Therefore neither contain the objectbox removal work required for F-Droid submission, and it remains unreleased.

The reason the work hasn't gone out appears to be because the changes take place in the middle of quite a lot of other development, which presumably isn't finished yet.

Look at all the unreleased changes before: v2.4.12...19f306a (last release to replacing objectbox) and everything since: 19f306a...master. Hundreds of commits and files changed.

I don't work on this project, but I'm guessing the developers are in the middle of a big refactor. A number of people have asked for details and offered to help, but in lieu of that I guess they would prefer the community to just be patient.

Something the community might be able to do in the meantime is set up a custom F-Droid repository which builds the oss flavour of the app from master. I haven't tested how stable the master build is, but if it works, users would be able to add the custom repository and download and test owntracks before before the next release, and before any formal submission to F-Droid takes place.

[licaon-kter]

if fdroid is becoming more hassle than its worth for the project

If being FOSS you mean? 😆

[mnalis]

For those following this, owntracks 2.5.0 has landed in F-droid few days ago. Nice to have FOSS variant available again!