It should be possible to reproduce, byte for byte, every build of every package in Debian. More information about reproducible builds in general are available at reproducible-builds.org.
Reproducible builds of Debian as a whole is still not a reality, though individual reproducible builds of packages are possible and being done. So while we are making very good progress, it is a stretch to say that Debian is reproducible.
Most packages built in sid today are reproducible under a fixed build-path and environment.
We have a continuous integration platform that builds and immediately rebuilds packages. With this we can detect problems related to timestamps, file ordering, CPU usage, (pseudo-)randomness and other things.
Many patches have already been submitted, and we are continuously writing new ones.
You can check which packages installed on your system are still unreproducible by using the reproducible-check script in the devscripts package.
Big outstanding issues
These are the critical items necessary to have reproducible builds for at least the required packages of Debian
#894441: binNMUs should be replaced by easy "no-change-except-debian/changelog-uploads" (as of 20190302, 12% of all binaries in Buster were binNMUs.)
#900837: Mass-rebuild of packages for reproducible builds (blocked by #894441)
#763822: ftp.debian.org: please include .buildinfo file in the archive, with this two related bugs:
User-facing interfaces (see proof-of-concept in #863622: apt: warn when installing packages that are not reproducible
currently debian-policy says "packages should be reproducible", though we aim for "packages must be reproducible" though it's still a long road until we'll be there: currently (Oct 2018) there are more than 1250 unreproducible packages in Buster, thus if policy would be changed today, 1250 packages would need to be kicked out of Buster (well, or fixed) immediatly, so this policy change right now is not feasable.
Annoying but not major
Nice to have
- Tighten up the Policy definition of "reproducible" to be stricter about environment variables and build paths.
Discuss which environment variables we should blacklist or whitelist, 876055.
#929397: ftp.d.o: please upload LTS .buildinfo files to ftp-master (this is not relevant yet, as Jessie is the LTS release, while only dpkg from Stretch and newer produces .buildinfo files.)
There are many other possible nice-to-haves, e.g., making builds independent of their build directory, making it possible to create archive formats (like tar.gz and zip) with different tools yet result in the same byte order, etc. Many of those are valuable, but they shouldn't distract from getting the results of reproducible builds out to users.
For more concrete tasks to be done, look at how to contribute.