Debian and reproducible-builds.org incoherence?

[Alexis PM]

Hello

> The missing piece is the buildinfo file. :)

Attached.

> https://buildinfos.debian.net/buildinfo-pool/f/fbreader/fbreader_0.12.10dfsg2-4_amd64.buildinfo
> 
> This describes the environment (and most importantly which packages in
> which version were present back then).
> 
> For example gcc 4:9.2.1-3 was used to build
> fbreader_0.12.10dfsg2-4_amd64.deb, while the gcc version currently in
> Debian bullseye is 4:10.2.1-1. The `4:`, `-3`, `-1` are Debian specific,
> if we remove them (for the sake of making it simpler to explain) it's
> gcc 9.2.1 vs gcc 10.2.1. This alone makes it highly unlikely that both
> gcc versions are going to generate an identical binary for the given
> source code (other packages that have been updated in the meantime may
> have an effect as well).

Yes, gcc (= 4:9.2.1-3) versus gcc (= 4:10.2.1-1). 
Among many other version changes of build dependences.
I had not considered that the package was compiled when bullseye was testing,
with another compiler version.
I had a simpler idea in mind: "stable" and "reproducible".

Comparing sizes, my compiled binary is smaller.
-rwxr-xr-x 1 alexis alexis 1754752 sep  1  2019 test/usr/bin/FBReader
-rwxr-xr-x 1 alexis alexis 2139744 sep  1  2019 debian/usr/bin/FBReader

> To reproduce the package on packages.debian.org (the one everybody cares
> about), you need:
> 
> - this tool: https://github.com/fepitre/debrebuild
> - the build info file I linked above.
> 
> I've last looked into this early 2022, the command I used back then was:
> 
> ./debrebuild.py --output="some/dir/" --builder=mmdebstrap --use-metasnap
> path/to/fbreader_0.12.10dfsg2-4_amd64.buildinfo
> 
> There's a service doing this, run by Frédéric Pierret from QubesOS:
> 
> https://beta.tests.reproducible-builds.org/ (results may take a while to
> load)
> 
> The system at https://tests.reproducible-builds.org/debian/ doesn't use
> buildinfo files and always tests with the latest version of all
> dependencies, in otherwise very different environments (different
> hardware, different system time, different kernel, etc). I've sometimes
> referred to this as "build environment fuzzing". It's trying to detect
> potential problems as early as possible to make sure it's able to build
> them reproducible despite these factors.

It goes beyond my initial intentions, which was to know what was happening, 
but very interesting.

> I hope this helps, please let me know if anything is still unclear!

Thank you so much.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fbreader_0.12.10dfsg2-4_amd64.buildinfo
Type: application/octet-stream
Size: 14158 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230412/b717f860/attachment.obj>