Reproducible builds: build_path showing variation #231
Comments
We were already checking that building a wheel twice yields the same checksum both times, but we weren't confirming that the checksum matched what's already committed to version control. Let's do that. Still leaving the 'reprotest' check enabled because it supports multiple methods for checking reproducible, which should help us shake out problems like #231.
|
Dug into this a bit. The build path is embedded inside Snipped out that file removes the specific variation reported above, but has a side-effect of altering the checksumming in the
@kushaldas It seems to me we can snip these files out of the Debian package, via the strip-nondeterminism step, to get better reproducibility. Do you see any problems with that? |
In #231 we noticed that the filesystem path used to build the debian packages was breaking reproducibility. That's due to the filepath being recorded inside `direct_url.json`, as stipulated by PEP610. Also relevant is PEP427, which describes the `RECORD` file for wheels. Here we remove that file, as well, to ensure full reproducibility regardless of path.
I am okay with removing them, I still asked the upstream to get some details (if any). |
In #231 we noticed that the filesystem path used to build the debian packages was breaking reproducibility. That's due to the filepath being recorded inside `direct_url.json`, as stipulated by PEP610. Also relevant is PEP427, which describes the `RECORD` file for wheels. Here we remove that file, as well, to ensure full reproducibility regardless of path.
We were already checking that building a wheel twice yields the same checksum both times, but we weren't confirming that the checksum matched what's already committed to version control. Let's do that. Still leaving the 'reprotest' check enabled because it supports multiple methods for checking reproducible, which should help us shake out problems like #231.
|
Resolved by #244. |
We were already checking that building a wheel twice yields the same checksum both times, but we weren't confirming that the checksum matched what's already committed to version control. Let's do that. Still leaving the 'reprotest' check enabled because it supports multiple methods for checking reproducible, which should help us shake out problems like #231.
Discovered while debugging #228. See the diff from two package builds of
securedrop-client, built from the 0.4.1 tag, but built in slightly different locations:Depending on the buildroot for the package build, we're seeing artifacts within the deb package change. That's not good. A few questions:
+build_pathfor reprotest in CI?Let's do some research and see what's what.
full diffoscope output
The text was updated successfully, but these errors were encountered: