maxrave-dev
F-Droid reproducible build failed
Describe the bug SimpMusic_v0.2.7.apk.html.zip
Could you please take a look? Thanks!
To Reproduce Steps to reproduce the behavior:
- Go to '...'
- Click on '....'
- Scroll down to '....'
- See error
Expected behavior A clear and concise description of what you expected to happen.
Screenshots If applicable, add screenshots to help explain your problem.
Log (Error Details) Paste the log from the crashing screen, if it is not a crash bug, skip it.
I try to use fdroidserver but same diff like you. How to fix this?
DOES NOT VERIFY
ERROR: APK Signature Scheme v3 signer #1: APK integrity check failed. CHUNKED_SHA256 digest mismatch. Expected: <9c2693d43d84e74c2acfd950ea111bed16f677728051a9b363ec1f104b8e1012>, actual: <47dc37b6587c9278d2c662b19c0708e03f2d1e9cbb3af92675beed428aa97061>
2024-12-31 17:06:25,436 ERROR:
/var/folders/01/scshqgb13bbc4xz1swkn7dsw0000gn/T/tmp9ee24znj/sigcp_com.maxrave.simpmusic_25.apk:
2024-12-31 17:06:25,436 INFO: ...NOT verified - /var/folders/01/scshqgb13bbc4xz1swkn7dsw0000gn/T/tmp9ee24znj/sigcp_com.maxrave.simpmusic_25.apk
2024-12-31 17:06:26,010 ERROR: Could not build app com.maxrave.simpmusic: compared built binary to supplied reference binary but failed
==== detail begin ====
verification of APK with copied signature failed
Comparing reference APK to APK with copied signature...
Unexpected diff output:
Binary files /var/folders/01/scshqgb13bbc4xz1swkn7dsw0000gn/T/tmp9ee24znj/unsigned_binaries_com.maxrave.simpmusic_25.binary/content/classes2.dex and /var/folders/01/scshqgb13bbc4xz1swkn7dsw0000gn/T/tmp9ee24znj/_var_folders_01_scshqgb13bbc4xz1swkn7dsw0000gn_T_tmp9ee24znj_sigcp_com.maxrave.simpmusic_25/content/classes2.dex differ
==== detail end ====
2024-12-31 17:06:26,014 INFO: Build for app com.maxrave.simpmusic:25 failed
Could you please try building with openjdk instead? Sometimes JBR produces different binary.
I mean I use fdroidserver to build local, but with same commit the local build can not verify sha256 apks
Also tracked in https://github.com/maxrave-dev/SimpMusic/issues/94#issuecomment-2574036743
You can check the apk in the latest release
That's the one built using fdroidserver? Because it fails as well (see the post @licaon-kter linked).
The apk I build using ./gradlew app:assembleRelease then zipalign then apksigner
Why the additional zipalign? I guess it would match if you'd skip that. We could of course try adding that in our recipe; can you give the full syntax you've used for zipalign (the apksigner call is not important on our side as we don't sign)?
This APK is repro, but, since it adds a suffix we can use this for this version only and in the next update we will go back to the old name. Is that ok?
@maxrave-dev congrats! Confirming RB at IzzyOnDroid (I just removed the FIXME to re-enable automatic updates at my builder again). On the first run at that, so even the flakyness seems to be gone (though that might be a bit early to say, which is why I left the shaker active in the recipe).
@licaon-kter @linsui Sorry for pinging. I checked Fdroid. By the way, why does SimpMusic not auto-update in Fdroid (the latest version on Fdroid is v0.2.8), and what I need to do right now
we needed to update the checker
let's see if ok, https://gitlab.com/fdroid/fdroiddata/-/merge_requests/20335/diffs
then maybe we can do an ABI split too
0.2.13 reproducible build failed. Maybe just need to clean the cache and rebuild it. Could you please have a try? Thanks!
Funny. It was RB here, @linsui – but it's marked as "flaky build" (aka non-deterministic). I would need to check the logs how many rounds it took, but maybe you can try the "shaker" (building in a loop until the hash of classes2.dex matches)? From our recipe:
build:
- sed -r '/abi \{/,/}/ { s/include\(.*\)/include("arm64-v8a")/ ; s/isUniversalApk = true/isUniversalApk = false/ }' -i app/build.gradle.kts
- chmod +x gradlew
- DEX_FILE=app/build/intermediates/dex/release/minifyReleaseWithR8/classes2.dex
- DEX_SHA1=05c7fd034ca02a29db3fa0751cff8ea552d07be0
- for _ in {1..10}; do
- ./gradlew clean assembleRelease --no-build-cache --no-configuration-cache --no-daemon
- if [ "$( sha1sum "$DEX_FILE" | cut -d' ' -f1 )" = "$DEX_SHA1" ]; then
- break
- fi
- done
(the sed is to have it build the arm64 variant only)
Edit: checked the logs. Took 2 rounds here.
Usually the prof changes when the dex changes (as baseline.prof also holds the checksums of all *.dex). Cases where only the prof changes were rare in the past, though funnily we see them more often nowadays (with off-by-one's in the hot methods, which in most cases (but not all) indicate a non-deterministic build – we could not figure the remaining ones yet).
This is one of the reasons I usually take the baseline.prof as reference for the hash compare – one of the few things Fay and I disagreed about, she was always going for the "root cause" (which here would be the classes2.dex). I usually go for the baseline.prof also for the reason that, where today classes2.dex is the culprit, the relevant "pieces" might move to classes3.dex with a future release – still affecting the very same baseline.prof 🤷♂
Interesting. In our build the different file is classes.dex. The prof file is the same. And when the classes.dex becomes the same, the classes2.dex is different.
And let me guess: in both cases, baseline.prof differs? So maybe doing the match on that would catch both birds with one corn?
@linsui @IzzySoft Maybe I forgot to add this to the build.gradle files of submodules
tasks.withType(CompileArtProfileTask).configureEach {
enabled false
}