Reproducible Builds: Unexpected Benefits and Problems

The presentation discusses how to debug and patch issues in software development, with a focus on reproducibility and reducing complexity in upstream processes.

• Set up tools to check for issues
• Debug to find the source of the issue
• Fix the issue by patching the code or dropping unreported elements
• Submit the patch to upstream or fork the project
• Add the patch to build reports and revisit later if necessary

The speaker mentions using a tool called autoclassify to build binaries with the least amount of variations and identify the source of an issue. They also suggest using autoprovenance to trace program activity and identify issues with parallelism. Additionally, they recommend looking for differences in build logs and output strings to pinpoint the root cause of an issue.

I have now worked on openSUSE reproducible builds for 6 years and would like to share some insights on where it can help, how to best debug non-determinism and what unexpected problems showed up with reproducible-builds. I plan for a good part of Q&A + discussion at the end.