NanoLedger
NanoLedger copied to clipboard
chvp
F-Droid can't build
ref: https://gitlab.com/fdroid/fdroiddata/-/jobs/7198511509#L843
diff log: nano40100.log
/LE: fyi https://gitlab.com/fdroid/fdroiddata/-/commit/4ea2ca7bcf9e3eaf1ee66b69c82181dabd447766
Do you have any idea on how to fix this issue? Neither https://gitlab.com/fdroid/wiki/-/wikis/HOWTO:-diff-&-fix-APKs-for-Reproducible-Builds nor https://f-droid.org/docs/Reproducible_Builds/#potential-sources-of-unreproducible-builds seem to mention differences in smali files.
smali files are disassembled from classes.dex, fyi
did you build the APK from https://github.com/chvp/NanoLedger/commit/c21e13bd5ca7213cda52290bf435c83513f9894b for sure? Maybe try to clean up all caches as rebuild?
attach the APK here so I can test locally maybe
The APK is built in GitHub actions, definitely from that commit: https://github.com/chvp/NanoLedger/actions/runs/9680655127/job/26709312310#step:2:83
GitHub does not keep build cache, it only caches dependencies, so it was built with a clean cache. The APK can be found here: https://github.com/chvp/NanoLedger/releases/tag/v0.4.0.
Looking at the docs here though, it might be due coreLibraryDesugaring (this was introduced relatively recently). Although that bug was fixed in 2021 apparently, so it seems weird that this would still be an issue.
I've tried to "fix" the issue in #139, I will follow the pipelines in the fdroiddata repo to see if it is actually fixed.
great https://gitlab.com/fdroid/fdroiddata/-/commit/60ad0d7dcf6ac37842689bdeb9f00be0af816d2a
It seems to still fail though? https://gitlab.com/fdroid/fdroiddata/-/jobs/7211423746
I've disabled again: https://gitlab.com/fdroid/fdroiddata/-/commit/fc9f8774d19a102197993a91dc343270438c3cdb
testing locally, I can see:
- success
- fail but the same APK sha256sum
- fail but the same APK sha256sum yet another one
tested on 2 machines
tested with limiting CPU cores to 1, 2, 4
not sure I see a pattern but I did see the same APK between these 2 machines, on multiple runs (yet not success vs yours)
@linsui thoughts?
Maybe https://github.com/chvp/NanoLedger/blob/main/.github/workflows/release.yml#L28 is related.
Good find, looks that maybe we can do the same in postbuild then, install that sdk 34, use its zipalign
I can look into upgrading to SDK 35 as well, that's probably a more future-proof solution.
https://gitlab.com/linsui/fdroiddata/-/jobs/7220014923 Now the dex file is also different...
Oh, I reverted the removal of useCoreLibraryDesugaring because it didn't fix the issue, I didn't realize that the issue was apparently two-fold. I'll revert the revert and make a new release. Hopefully that will finally fix it.
To be honest I'm not sure I have the skills to figure out what the issue is here. The app doesn't use native code, and except for version bumps and some small features, there were basically no changes since the last release on F-droid. (There was also the useCoreLibraryDesugaring, but that's not present in the latest release.)
I know achieving reproducible builds in general and the F-Droid tooling in specific is a bit of a chore, but know that there are quite a few of us out there that really appreciate it and much prefer to get and rely on apps that are available that way as opposed to not being sure of what is under the hood or when they will just disappear.
I get that, but as mentioned before I have no idea on how to even get started debugging this. If I could bisect the repository to see when the issue showed up, I would do so, but the fdroid build process isn't really compatible with my linux distribution (since it relies on apt-get a lot).
here's the diff log for reference: nan40500.log
whenever I see method and iget-object and invoke in diff logs, with params slightly shifted around, I think about minify: https://github.com/chvp/NanoLedger/blob/v0.4.4/app/build.gradle.kts#L28
we had some cases that looked sameish in https://gitlab.com/fdroid/fdroiddata/-/merge_requests/15432#note_2020587507 and https://gitlab.com/fdroid/fdroiddata/-/merge_requests/15486#note_2022283874 (see the logs)
@chvp can you build with minify disabled and attach the APK for us to check?
There's a ZIP with a non-minified APK here: https://github.com/chvp/NanoLedger/actions/runs/10375192313/artifacts/1808005823
(I would prefer not to have to disable minification permanently, it's a 500% increase in artifact size...)
@licaon-kter were you able to test this? Or should I really create a new release without minification?
@chvp
There's a ZIP with a non-minified APK here: https://github.com/chvp/NanoLedger/actions/runs/10375192313/artifacts/1808005823
confirmed, that APK is repro compared with my local built APK from https://github.com/chvp/NanoLedger/commit/a191118d2d0bbe015d25e0d967a7366fc6caea83
(note: you built your APK from https://github.com/chvp/NanoLedger/commit/e81f2f6dc8dd294b1a8bd3e4d89c297b4d972c93 but I can't build from that as it's not part of any tree or smth)\
/LE: wow the unminified APK is like 10x the size :crying_cat_face:
confirmed, that APK is repro compared with my local built APK from a191118
🎉
(note: you built your APK from e81f2f6 but I can't build from that as it's not part of any tree or smth)\
The actions are run against the potential merge commit. And since main has moved since then, that commit doesn't exist anymore. It should be the exact same content as a191118, since the branch was up to date at the time.
/LE: wow the unminified APK is like 10x the size 😿
Yeah, that's why I would prefer not to turn minification off. Is there anything we can do while preserving minification, or should I just eat the increase in artifact size?
@licaon-kter
It should be the exact same content as a191118 , since the branch was up to date at the time.
The APK contains the VCS info that points to the used commit, the APKs end up different... if commits are different.
We advise to always build from the tagged commit, here this was just a test so it does not matter. :)
No idea on the minify future though.
We have more and more apps that minify makes non-deterministic. :(