bbhttI started working on a reproducibility checker, à la `buildstream-reprotest` for Flatpak apps on Flathub. It basically automates the process of rebuilding and comparison and makes it a single command.
https://github.com/flathub-infra/flathub-repro-checker
Most of the initial 0.1.0 code was written between 11 PM to 2 AM on this Wednesday night, so there may be bugs 😅
0.1.0 is usable with some caveats. The CI has artifacts of non-reproducible and reproducible packages.
Initial impressions:
— There is a lot of benefits to build on Flathub infra and maintain consistency for this type of checking to work. Certain assumptions don't hold for direct uploads.
— Direct uploads are missing a bunch of pieces on their side to make them testable with this. I'm on to some of them, but not sure if some other things can be done.
— I was pleasantly suprised to see some apps I thought would be unreproducible, were reproducible.
— I tried only 10-11 out of 2500, but one immediate difference is Flatpaks here do and are generally encouraged to remove man pages, docs etc. out of the final artifact. They are avoiding one of the common sources of embedded dates etc. these days.
— The debuginfo generation process done by flatpak-builder is sometimes inconsistently introducing unreproducibility in debug data. I can't see it in GitHub CI (Ubuntu 22.04) but I can see it locally. Probably something to do with elfutils. I need to investigate more but I guess I need to set up a consistent environment to run the checks as well.
— There are some things that need to be done at the Flatpak or Flatpak Builder level. I documented some at https://docs.flathub.org/docs/for-users/rebuilding#notes when that page was written.
— Data generated by Appstream is unreproducible, and I think that's expected. I ignore those, since app maintainers have no control over that.
IzzyOnDroid ✅
Hans-Christoph Steiner
mmu_man
Rexo the Trans Bus 🏳️🌈🏳️⚧️🚌
Risotto Bias