F-Droid can't build

[licaon-kter]

5.0 wanted Java17 first: https://monitor.f-droid.org/builds/log/github.umer0586.sensorserver/23#site-footer

So I added that: https://gitlab.com/fdroid/fdroiddata/-/blob/b8ea88726347a153db79c42a612f271733dc0385/metadata/github.umer0586.sensorserver.yml#L34-L37

And another fix: https://github.com/umer0586/SensorServer/pull/31

But now it's not repro anymore? https://gitlab.com/fdroid/fdroiddata/-/jobs/4805397553#L458

@umer0586 did you build https://github.com/umer0586/SensorServer/releases/tag/v5.0.0 with Java17?

/LE: fyi https://gitlab.com/fdroid/fdroiddata/-/commit/49451aee4d1bac13fa9c7d6709898ad36d883663

[umer0586]

did you build https://github.com/umer0586/SensorServer/releases/tag/v5.0.0 with Java17?

Yes with Java 17.0.6 which is embed in Android Studio

[umer0586]

I don't understand why its causing reproducible build failure. Is it baseline.profm which is causing this?

[licaon-kter]

reading https://f-droid.org/docs/Reproducible_Builds/ maybe implement https://gist.github.com/obfusk/61046e09cee352ae6dd109911534b12e ?

[umer0586]

After reviewing the links you shared, I discovered that I should update AGP (Android Gradle Plugin) to version 8.1.0. However, I'm concerned about potential reproducible build failure. Is there a method to compare the APK built by F-Droid, which had reproducible failures, with the APK I'll generate on my local machine before releasing a new version?

[licaon-kter]

I'll have to build it locally, early next week

[umer0586]

I'll have to build it locally, early next week

Should I wait until then before publishing new releases?

[licaon-kter]

I'm concerned about potential reproducible build failure

Can you build an APK from https://github.com/umer0586/SensorServer/commit/f172343642937b1346826f2ec19c67946b0308b0 so I can test repro against it?

/LE: app builds fine otherwise

[umer0586]

Should I provide the APK through the new releases tag, or is it sufficient to upload the APK here for you to check for a reproducible build first ?

[licaon-kter]

@umer0586 here is enough

[umer0586]

APK built with same source as https://github.com/umer0586/SensorServer/tree/v5.0.0 with different AGP i-e 8.1.0

Download SensorServer-v5.0.0.zip

[umer0586]

@licaon-kter ?

[licaon-kter]

Yup :tada: thanks https://gitlab.com/fdroid/fdroiddata/-/commit/2747768c26dece1cc476eba811bebc74a2920891

[umer0586]

Hi @licaon-kter, it's been over a week, and I still can't find version 5.1.0 of the app on F-Droid. You can check it out here: https://f-droid.org/packages/github.umer0586.sensorserver/

[licaon-kter]

We recommend to use F-Droid Client to get timely updates notifications and info on new apps. The website is extra and it takes more time for it to be refreshed once the new index is published.

I can see 5.1.0 just fine in Client, did you enable autoupdates (to pull the index etc)? If not, you can pull-to-refresh in Latest or Updates screens.

[umer0586]

Thank you for the information. Even though auto-updates were enabled, the F-Droid client wasn't fetching the latest index. I resolved the issue by clearing the app's data from the system settings and then relaunching the app. Now, I can see version 5.1.0 there.

[licaon-kter]

ref: https://monitor.f-droid.org/builds/log/github.umer0586.sensorserver/27#site-footer

so we scanignore that file

but then reproducibility fails, the diff log is huge: sens27.log.7z.ZIP (remove .ZIP from name)

/LE: fyi https://gitlab.com/fdroid/fdroiddata/-/commit/cb4f418bcd6be1279250f0a8f0c2e788bdb92377

[umer0586]

ref: https://monitor.f-droid.org/builds/log/github.umer0586.sensorserver/27#site-footer

so we scanignore that file

but then reproducibility fails, the diff log is huge: sens27.log.7z.ZIP (remove .ZIP from name)

/LE: fyi https://gitlab.com/fdroid/fdroiddata/-/commit/cb4f418bcd6be1279250f0a8f0c2e788bdb92377

All the files in the directory https://github.com/umer0586/SensorServer/tree/v6.0.0/app/src/main/assets/webapp are generated by Flutter from Dart source code found at https://github.com/umer0586/SensorServer/tree/v6.0.0/sensors_dashboard. Essentially, the SensorServer app includes a web application in its assets folder, which can be accessed through a web browser. Therefore, none of the files in the assets folder should be excluded when building the APK.

[umer0586]

@licaon-kter ???

[licaon-kter]

I've rebuilt, there were still some differences, will check the logs asap.

[licaon-kter]

Here's the log: sens27_2.log.7z.ZIP (remove .ZIP from name)

looks like the generated stuff is not repro

[umer0586]

Here's the log: sens27_2.log.7z.ZIP (remove .ZIP from name)

looks like the generated stuff is not repro

I don't understand why this diff log is so large. I built the APK using the v6.0.0 tag. All the files under https://github.com/umer0586/SensorServer/tree/v6.0.0/app/src/main/assets/webapp are generated by the Dart compiler and should be included in Android's assets folder as they are. The log shows differences in these files, which is confusing to me.

[licaon-kter]

generated by the Dart compiler and should be included in Android's assets folder as they are.

yup, I cleaned up their line endings, and those are ok now

up next, see the smali differences in the log

[umer0586]

up next, see the smali differences in the log

Checking...

[umer0586]

│ │ │ │ │ │ ├── +++ github.umer0586.sensorserver_27/smali_classes2/github/umer0586/sensorserver/andserver/plugin/generator
│ │ │ │ │ │ │ ├── file list
│ │ │ │ │ │ │ │ @@ -1 +1 @@
│ │ │ │ │ │ │ │ +Cibuudunar.smali
│ │ │ │ │ │ │ │ -Rvrymzjxfw.smali
│ │ │ │ │ │ │ │   --- SensorServer-v6.0.0/smali_classes2/github/umer0586/sensorserver/andserver/plugin/generator/Rvrymzjxfw.smali
│ │ │ │ │ │ │ ├── +++ github.umer0586.sensorserver_27/smali_classes2/github/umer0586/sensorserver/andserver/plugin/generator/Cibuudunar.smali
│ │ │ │ │ │ │ │ @@ -1,10 +1,10 @@
│ │ │ │ │ │ │ │ +.class public final Lgithub/umer0586/sensorserver/andserver/plugin/generator/Cibuudunar;
│ │ │ │ │ │ │ │ -.class public final Lgithub/umer0586/sensorserver/andserver/plugin/generator/Rvrymzjxfw;
│ │ │ │ │ │ │ │  .super Ljava/lang/Object;
│ │ │ │ │ │ │ │ +.source "Cibuudunar.java"
│ │ │ │ │ │ │ │ -.source "Rvrymzjxfw.java"

Here is the problem: In version v6.0.0 (27), I used a new library with its plugin (https://github.com/yanzhenjie/AndServer). This plugin generates a Java class under github/umer0586/sensorserver/andserver/plugin/generator/, but it generates the class name with a random string each time. As a result, each build ends up with a different, unknown class name. This is the main reason why the reproducible build was failing. Unfortunately, the plugin does not provide any configuration options to address this issue.

[licaon-kter]

you can't rename the file after generation?

[umer0586]

you can't rename the file after generation?

I think I need to write a custom Gradle task that executes before assembleRelease. I am currently working on finding a solution.

Will update you shortly.

[umer0586]

The plugin generates this source file, and I'm not sure where else this file is referenced. Since the file is generated by a plugin, renaming it could lead to unexpected behavior or errors. I suggest disabling reproducible builds for this app.

[linsui]

I can't understand why they use a random file name here. I thought we have to fork the plugin to fix this problem...

[umer0586]

I can't understand why they use a random file name here. I thought we have to fork the plugin to fix this problem...

I also don't understand why they use a random file name here.

[umer0586]

@licaon-kter Please disable reproducible builds check for this app

[licaon-kter]

It's not a toggle you turn on/off every other month when tools/deps you use/add misbehave.

Will see about maybe patching that lib instead...

[umer0586]

It's not a toggle you turn on/off every other month when tools/deps you use/add misbehave.

Will see about maybe patching that lib instead...

I am asking for disabling it for all subsequent builds and not enabling this check ever again.

[umer0586]

Fixed : https://gitlab.com/fdroid/fdroiddata/-/merge_requests/15371

[licaon-kter]

Since the app is no longer build reproducible, I would not call this solved... :person_frowning:

[umer0586]

Since the app is no longer build reproducible, I would not call this solved... :person_frowning:

We cannot consider this a complete solution; however, it serves as a temporary fix for the current issue.