[all] Package reproducibility: shall we hard-wire our CI to avoid it in the future?
Hi, It used to be that a number of packages were not reproducible. If you do not know why reproducibility of packages is important, please read on: https://reproducible-builds.org/ This has been patched numerous times in numerous packages. However, it looks like the community is still not aware of the problem, and how to avoid it. One of the very common pitfall, is adding a default in an oslo.config string, that leaks properties of the build host, like for example the hostname, the number of CPU cores, and so on. Here's a very common example that was commited last summer: https://review.opendev.org/c/openstack/oslo.messaging/+/889425/9/oslo_messag... Yet the fix is super simple, thanks to oslo.messaging sample_default: https://review.opendev.org/c/openstack/oslo.messaging/+/915314 If I'm writing this, it is *not* to point at anyone, especially *not* the commiter of the above patch. it just happen to be the latest occurrence I noticed thanks to the Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068377 This message is only to raise awareness of the problem, and avoid having it happen again. I also wonder: would it be possible to have our CI avoid this type of mistake? It wouldn't be so hard to have the doc build twice, with different hostname, CPUs, etc. configuration, would it? (note: I'm not volunteering, just pushing for the idea...) Cheers, Thomas Goirand (zigo)
On Tue, 2024-04-09 at 11:59 +0200, Thomas Goirand wrote:
Hi,
It used to be that a number of packages were not reproducible. If you do not know why reproducibility of packages is important, please read on:
https://reproducible-builds.org/
This has been patched numerous times in numerous packages. However, it looks like the community is still not aware of the problem, and how to avoid it. One of the very common pitfall, is adding a default in an oslo.config string, that leaks properties of the build host, like for example the hostname, the number of CPU cores, and so on. Here's a very common example that was commited last summer:
https://review.opendev.org/c/openstack/oslo.messaging/+/889425/9/oslo_messag...
Yet the fix is super simple, thanks to oslo.messaging sample_default: https://review.opendev.org/c/openstack/oslo.messaging/+/915314
If I'm writing this, it is *not* to point at anyone, especially *not* the commiter of the above patch. it just happen to be the latest occurrence I noticed thanks to the Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068377 im glad you raised this as i have never heard of the desire to produdce repoducable packages ever disucssed here or that spcific problem with defautl cfg.StrOpt('hostname', default=socket.gethostname(), help='Hostname used by queue manager'), vs cfg.StrOpt('hostname', sample_default='node1.example.com', default=socket.gethostname(), help='Hostname used by queue manager. Defaults to the value ' 'returned by socket.gethostname().'),
from my perspective this is not something we have as a conrtact today and if you wanted to supprot this in all packages it would be a new feature and ongoing requirement.
This message is only to raise awareness of the problem, and avoid having it happen again.
it sounds like you have a requirement or expecation that is not actully a commitment by the project at least nova has never commited to this or even been asked too as far as im aware.
I also wonder: would it be possible to have our CI avoid this type of mistake?
not withtout first agreeing that we should do this but im not really agaisnt trying to do that.
It wouldn't be so hard to have the doc build twice, with different hostname, CPUs, etc. configuration, would it? (note: I'm not volunteering, just pushing for the idea...)
Cheers,
Thomas Goirand (zigo)
participants (2)
-
smooney＠redhat.com
-
Thomas Goirand