Reproducible Build failed for v6.0

[IzzySoft]

Not sure for the culprit, but did you build that APK from a clean tree (no local changes, no artifacts left over from previous builds) at the commit the tag points to? The diff is rather massive; I'm attaching you the files here so you can take a look for yourself:

diffs.zip

[dead8309]

No, there was a small patch so I updated the release apk manually. Those patches were pushed an hour later on GitHub

[IzzySoft]

That's deadly for reproducible builds – as it means we cannot reproduce them. Your APK claims to have been built from 85be93a – which matches the commit the tag points to. So did you build from the next commit before committing it? That only updates strings. Or from which one, so I can try if we can fix this on our end?

[dead8309]

I would say it was built from a56d945 but then I rebased commits on top of #413, so can't tell the exact commit

[IzzySoft]

I can rule out 29365a5 (just tried that, and the renaming of locale_zh to locale_zh_rcn was part of the diff, so that was not yet in your APK. A build from a56d945 is currently running, so I can tell you in a few minutes. Should that fail as well, we have no means to reproduce, and need to mark this release "RB failed". But let's wait for the running build first.

[IzzySoft]

Sadly, that also did not reproduce your APK. Guess it was built "somewhere between commits", so close to no chance getting that reproduced. The diff there is rather small now, just some translations that were changed, and a little code piece somewhere (thanks to obfuscation, I cannot pinpoint the latter – the former was in res/values-tr/strings.xml – which is strange, as such is not part of either of the two commits). The code change seems to be just in a single method – but afraid we won't be able to reproduce that.

OK, so it seems we need to declare v6.0 "RB failed", no chance to fix that on our end. You could of course make a v6.0.1 as "maintenance release", to get the shield up again.

For future releases, please remember the "first basic rule" of our hints on reproducible builds: "Always build the APK from a clean tree at the commit the tag points to" 😉

[dead8309]

got it. thanks!

[IzzySoft]

Sadly, it seems the situation repeats with v6.2: lots of differences in classes.dex. Was that built from a "dirty tree" (with local, uncommitted changes)? So, again between commits?

diff.zip

[dead8309]

that's strange, i have no local commits

[IzzySoft]

Grmpf, what could be the cause then? You're still using JDK 17 to build the app, right? Anything else changed that might be the culprit here?

Edit: you did run clean before the release build? Else it could also be artifacts remaining from prior builds.

[IzzySoft]

As more than 24h are up already, I guess we'll have to pass the negative result now. Would be good to get it fixed for the next release then, though…

[dead8309]

i recently moved to a mac setup, the gradle jdk might have changed b/w linux(prior) and current

[IzzySoft]

Oh – good that I didn't commit yet. Which one is it using now? We can try different ones, as long as the are LTS releases (so e.g. JDK 17, 21, 25). The gradle itself still matches what your gradle/wrapper/gradle-wrapper.properties says, yes?

[IzzySoft]

Unfortunately, using JDK 21 makes no difference at all. Thanks to your building on a Mac now, the "Windows newlines" in META-INF/services/* are gone, so we could remove the fix for that.

Maybe with the next release, you give Github actions a chance? You already have them set up for debug builds. Using assembleRelease instead of assembleDebug (and changing the path where the APK would then be found), should be all the adjustment needed for that. And optionally, instead of "adopt 17" using "temurin 21" – as the build seems to work fine with that?