F-Droid can't build - unknown maven repo

[licaon-kter]

https://f-droid.org/wiki/index.php?title=de.rwth_aachen.phyphox/lastbuild_1010803&oldid=288124

[Staacks]

Thanks, I noticed this when I released 1.1.8 a day before my parental leave. Phyphox uses the Eclipse Paho MQTT library for its new MQTT support, but the corresponding repo is not whitelisted by F-Droid. At the moment I do not see how to solve this. I think that they either need to include this library or we need to ship the F-Droid version without MQTT support, which would be very unfortunate.

[linsui]

I guess ou can include the source in this repo?

[Staacks]

Sorry, was still on parental leave. I have now directly included their builds in the repo. Should properly build again with the next release.

[jspricke]

We don't allow binary code in the repo:

2021-04-19 05:54:48,870 ERROR: Found Java JAR file at app/libs/org.eclipse.paho/org.eclipse.paho.client.mqttv3-1.2.5.jar
2021-04-19 05:54:48,870 ERROR: Found Java JAR file at app/libs/org.eclipse.paho/org.eclipse.paho.android.service-1.1.1.jar
2021-04-19 05:54:48,871 ERROR: Found Android AAR library at app/libs/org.eclipse.paho/org.eclipse.paho.android.service-1.1.1.aar

https://monitor.f-droid.org/builds/log/de.rwth_aachen.phyphox/1010901

[Staacks]

Now that I see the problem, it makes sense. So, it goes back onto the todo list...

[Staacks]

Just a quick update on the subject.

I burned a few hours today by trying to include the Paho MQTT Android Service and the MQTT Client as a subrepository. Unfortunately, the Android Service has not been maintained for a few years, so the gradle script is no longer compatible with current gradle versions and I do not see a way to fix it without changing the source of the Android Service. Since I do not want to maintain a fork of their code base (and I am also not really inclined to getting into the proper handling of the EDL/EPL dual licencing for a fork - was annoying enough wheng it as a library), I will stick with wither using binaries or their repository, which both are incompatible with F-Droid.

In order to make F-Droids builds work again, I will have to figure out a way to create a version without MQTT for F-Droid (build flavors?). I think that MQTT is a rather niche (as in rarely used) feature and the overlap with the few F-Droid users is even smaller. I am not too happy about it, but in the light of already way less development time than things being on the todo list, I think that this will be the best option to get out of this situation.

(And it will still involve hours of setting up an F-Droid environment and testing option after option as one build error replaces the next one.)

[linsui]

F-droid can build the lib before the app with a different gradle so the gradle version is not a problem.

[linsui]

I just found that the lib is available in maven central so we just need to add mavenCentral. https://gitlab.com/fdroid/fdroiddata/-/merge_requests/9431 By the way, F-Droid requires en-US as the mandatory locale, could you please rename en to en-US? Thanks!

[Staacks]

Damn, now I feel stupid for spending hours trying to directly include the source. If you could not tell by now: I really hate dealing with the build chain :)

Did you include version 1.2.5 because I updated it with the last version, too? I am asking, because I was also about to revert that decision. There seem to be some incompatibilities, which I can only suspect come from Paho Android Service being last build several years ago with Paho MQTT Client 1.1.0 in mind. So, if there is no other reason, we will stick with 1.1.0.

After all this, this should be all that is necessary for future releases: https://github.com/phyphox/phyphox-android/commit/e1674ccf1e81a7ae654631746c3e400fc9affd60

Regarding the en-US locale: I could not find the exact requirement. Is this for store information or for the resource files themselves and would a symlink do? I would rather not touch this structure because our translations are done with Weblate (just like the translations for F-Droid) connected to a translation branch of this repository. "en" is the translation source, so I am very afraid to break things or at least mess up any progress and issue tracking by renaming it to en-US.

[linsui]

Yes, 1.2.5 is used. In the next version I'll revert those hack and 1.1.0 will be used.

en-US is a requirement of F-Droid and other locale will fall back to it. I thought you can add a link from en-US to en so that translation system won't broken.

[Staacks]

en-US is a requirement of F-Droid and other locale will fall back to it. I thought you can add a link from en-US to en so that translation system won't broken.

Jepp, but I could not find anything on this requirement except for it being the fallback for description texts and graphic.

So, I would need a symlink in our fastlane structure (which is not that complicated in regard to translations anyways), but there is no requirement to the Android resources or did I miss this? Just would like to avoid unnecessary symlink complications that might end up complicating things for developers who want to play with the code on non Linux systems.

[linsui]

Jepp, but I could not find anything on this requirement except for it being the fallback for description texts and graphic.

Yep, it works without en-US but if the fastlane is not translated to the system language the client will display nothing.

You can also copy en to en-US if it's not updated frequently.

[Staacks]

Great, I have added a symlink (the tiniest possible commit?). This part should be irrelevant to users who play with the code - I was mostly worried about the res folder.

I am closing this issue now. Thanks a lot for your help and input. Let's hope it won't pop up again with the next release.

[linsui]

Thanks!

[Staacks]

Unfortunately, the solution was extremely short-lived. The latest release of the Paho Android Service is no longer compatible with Android API level 31, breaking the simple repo solution immediately for the next phyphox release.

I will now go the route of forking the project and including the code as a sub-repo to clearly keep the licences separate and hopefully still allowing for an F-Droid build. Since the Paho stuff is under the Eclipse Public Licence (EPL) and therefore GPL-incompatible, I see no other way than keeping it separate, so my modifications within the Paho Android Service clearly fall under the EPL. The resulting modified library can then be included (as source) under the Eclipse Distribution Licence as it fortunately is dual-licensed.

If anyone with more knowledge of licence-compatibility and the F-Droid build process sees a better way or sees a reason why this won't work, please keep me from wasting time on this again...

[linsui]

IIUC, you'll update the app to target 31 and you need to use a Paho fork? I don't know much about licence-compatibility. It should works for F-Droid build.

[Staacks]

Exactly, I just need to modify a single line to make it compatible with 31, but I cannot expect this to happen in the original repo which has not been touch for several year.

[Staacks]

Hope this fixes it for good: 0689fa4f77dad68c626049ff1362e76c94b727d7