SUMMARY Ideally, building the project twice on equivalent systems should result in the same bit-by-bit result. This helps verify there's been no compromise of build systems, especially when the project is part of a larger aggregate. You can read more about this at https://reproducible-builds.org/. kirigami seems quite close to being reproducible, but to suffer from an issue similar to https://qt-project.atlassian.net/browse/QTBUG-137440: a missing explicit library dependency in the CMakeLists.txt of a project using qml leads to a nondeterminism in what code is generated for it. This issue was identified while reproducing the NixOS graphical installation issue, and is tracked there as https://github.com/NixOS/nixpkgs/issues/450720 STEPS TO REPRODUCE Build kirigami in an 'essentially equivalent' environment, but for example varying the parallelism between '2' and '16'. OBSERVED RESULT Different generated code / output. Specifically, the generated src/dialogs/.rcc/qmlcache/KirigamiDialogs_Dialog_qml.cpp (generated from ./src/dialogs/Dialog.qml) is different: for 6.20.0, the methods not consistently generated are "color at line 328, column 9", "size at line 331, column 13", and "width at line 337, column 13" I'm not familiar enough with QML to go from here to actually specifying that dependency, though - I'd be happy to test further if you can point me in the right direction! EXPECTED RESULT The same generated code / output
Possible fix: https://invent.kde.org/frameworks/kirigami/-/merge_requests/1991
As a user of both Debian and F-droid repositories, on Debian 14 and LineageOS 23, which have almost all amd64 packages and 68% of apps reproducible: https://wiki.debian.org/ReproducibleBuilds https://f-droid.org/en/2025/11/27/twif.html I very much prefer and want reproducible builds! Especially today with so many attacks on the open source software.