"Reproducible Builds" mean the build process is fully deterministic: given a build definition, anyone can independently repeat the build on their own system and get an identical result.

Two reasons why this is useful:
- independent rebuilds increase trust in the build infrastructure,
- development is easier. Checking for reproducibility exposes various bugs, for example packaged temporary files or noarch packages with file paths dependent on the architecture.

This talk will discuss:
- changes to the build tools like rpm
- changes to build configuration, for example clamping of mtimes to $SOURCE_DATE_EPOCH
- fixes in packages to not introduce randomness in any build artifacts
- post-build cleanups done to normalize non-deterministic bits (static libraries, Python pyc files, Java jar and javadoc files)
- F41 Change to introduce a general post-build cleanup tool

If we fix general issues that affect broad classes of packages, we expect build reproducibility for 80+% of packages. The goal is to have 100% of packages reproducible. We'll discuss the current state and what needs to be done.