The timestamp and hostname carries no value for the default build. If its really required in special environment, or if someone is emotionally attached to such strings, it is is handled by existing logic a few lines above: provide your own .version file
Once this patch is applied it is possible to get reproducible builds of Xens hvmloader.
Signed-off-by: Olaf Hering olaf@aepfle.de --- scripts/buildversion.sh | 1 - 1 file changed, 1 deletion(-)
diff --git a/scripts/buildversion.sh b/scripts/buildversion.sh index e5ce96c..338b7f0 100755 --- a/scripts/buildversion.sh +++ b/scripts/buildversion.sh @@ -11,7 +11,6 @@ elif [ -f .version ]; then else VERSION="?" fi -VERSION="${VERSION}-`date +"%Y%m%d_%H%M%S"`-`hostname`" echo "Version: ${VERSION}"
# Build header file
On Tue, Feb 03, 2015 at 01:23:53PM +0100, Olaf Hering wrote:
The timestamp and hostname carries no value for the default build. If its really required in special environment, or if someone is emotionally attached to such strings, it is is handled by existing logic a few lines above: provide your own .version file
Once this patch is applied it is possible to get reproducible builds of Xens hvmloader.
I've found the version information to be quite helpful when we get trouble reports - it helps indicate what was being run and who built the code (eg, distribution or local). During development cycles, it helps verify that test runs are executed with the expected code.
What breaks if the version changes?
It should be possible to force a static version with "make VERSION='xyz'", but I'd ask that that not be done for production builds as it makes handling trouble reports harder.
-Kevin
On Tue, 2015-02-03 at 10:58 -0500, Kevin O'Connor wrote:
On Tue, Feb 03, 2015 at 01:23:53PM +0100, Olaf Hering wrote:
The timestamp and hostname carries no value for the default build. If its really required in special environment, or if someone is emotionally attached to such strings, it is is handled by existing logic a few lines above: provide your own .version file
Once this patch is applied it is possible to get reproducible builds of Xens hvmloader.
I've found the version information to be quite helpful when we get trouble reports - it helps indicate what was being run and who built the code (eg, distribution or local). During development cycles, it helps verify that test runs are executed with the expected code.
What breaks if the version changes?
It should be possible to force a static version with "make VERSION='xyz'", but I'd ask that that not be done for production builds as it makes handling trouble reports harder.
Olaf posted some similar patches against Xen and it was suggested that using the git HEAD time and/or "git describe" would help.
We could probably arrange to do this when building SeaBIOS as part of Xen, or for tarball rather than git builds use the Xen release version?
Ian.
On Tue, Feb 03, 2015 at 04:38:15PM +0000, Ian Campbell wrote:
On Tue, 2015-02-03 at 10:58 -0500, Kevin O'Connor wrote:
On Tue, Feb 03, 2015 at 01:23:53PM +0100, Olaf Hering wrote:
The timestamp and hostname carries no value for the default build. If its really required in special environment, or if someone is emotionally attached to such strings, it is is handled by existing logic a few lines above: provide your own .version file
Once this patch is applied it is possible to get reproducible builds of Xens hvmloader.
I've found the version information to be quite helpful when we get trouble reports - it helps indicate what was being run and who built the code (eg, distribution or local). During development cycles, it helps verify that test runs are executed with the expected code.
What breaks if the version changes?
It should be possible to force a static version with "make VERSION='xyz'", but I'd ask that that not be done for production builds as it makes handling trouble reports harder.
Olaf posted some similar patches against Xen and it was suggested that using the git HEAD time and/or "git describe" would help.
We could probably arrange to do this when building SeaBIOS as part of Xen, or for tarball rather than git builds use the Xen release version?
SeaBIOS uses "git describe" as part of its version string today, and for SeaBIOS tar releases we embed a ".version" file with the release info (see scripts/buildversion.sh and scripts/tarball.sh for details).
Even with this, the build timestamp is still useful during development cycles (when the head may be dirty). And the hostname/timestamp are useful as a way of backtracking to the gcc/binutils environment on trouble reports even from official releases.
-Kevin
On Tue, Feb 03, Kevin O'Connor wrote:
Even with this, the build timestamp is still useful during development cycles (when the head may be dirty). And the hostname/timestamp are useful as a way of backtracking to the gcc/binutils environment on trouble reports even from official releases.
Please discard the suggested change. We will continue to patch it out.
Olaf
Kevin O'Connor wrote:
Once this patch is applied it is possible to get reproducible builds of Xens hvmloader.
I've found the version information to be quite helpful when we get trouble reports - it helps indicate what was being run and who built the code (eg, distribution or local). During development cycles, it helps verify that test runs are executed with the expected code.
What breaks if the version changes?
Reproducible builds; allowing to create a consensus that a particular binary is indeed the correct binary for a particular source code.
It should be possible to force a static version with "make VERSION='xyz'", but I'd ask that that not be done for production builds as it makes handling trouble reports harder.
I would recommend to use `git describe --tags --dirty` output, which tells if there are any local modifications.
//Peter
On Tue, Feb 03, 2015 at 06:31:46PM +0100, Peter Stuge wrote:
Kevin O'Connor wrote:
Once this patch is applied it is possible to get reproducible builds of Xens hvmloader.
I've found the version information to be quite helpful when we get trouble reports - it helps indicate what was being run and who built the code (eg, distribution or local). During development cycles, it helps verify that test runs are executed with the expected code.
What breaks if the version changes?
Reproducible builds; allowing to create a consensus that a particular binary is indeed the correct binary for a particular source code.
That is useful. A solution for stabilizing gcc/binutils output would also need to be found though, and that's a much harder problem.
It should be possible to force a static version with "make VERSION='xyz'", but I'd ask that that not be done for production builds as it makes handling trouble reports harder.
I would recommend to use `git describe --tags --dirty` output, which tells if there are any local modifications.
"git describe" is already there - see my recent email to Ian.
-Kevin
Kevin O'Connor wrote:
What breaks if the version changes?
Reproducible builds; allowing to create a consensus that a particular binary is indeed the correct binary for a particular source code.
That is useful. A solution for stabilizing gcc/binutils output would also need to be found though, and that's a much harder problem.
Do you mean code generation? Reproducible builds are created using the same particular compiler version everywhere. I recommend this presentation for more information:
https://media.ccc.de/browse/congress/2014/31c3_-_6240_-_en_-_saal_g_-_201412...
For direct video download links: https://media.ccc.de/browse/congress/2014/31c3_-_6240_-_en_-_saal_g_-_201412...
It should be possible to force a static version with "make VERSION='xyz'", but I'd ask that that not be done for production builds as it makes handling trouble reports harder.
I would recommend to use `git describe --tags --dirty` output, which tells if there are any local modifications.
"git describe" is already there - see my recent email to Ian.
It's important that there's nothing additional in the string that changes depending on transient things outside of the source code. I.e. it needs to be nothing but describe output, and I think it would be nice if it were the default, so as to support reproducible builds out of the box.
//Peter
On Tue, Feb 03, 2015 at 07:22:49PM +0100, Peter Stuge wrote:
Kevin O'Connor wrote:
What breaks if the version changes?
Reproducible builds; allowing to create a consensus that a particular binary is indeed the correct binary for a particular source code.
That is useful. A solution for stabilizing gcc/binutils output would also need to be found though, and that's a much harder problem.
Do you mean code generation? Reproducible builds are created using the same particular compiler version everywhere.
Well, sure. But that's not the current reality - we know there are lots of different compiler versions in use today. (Indeed, new versions come out every few months.)
I recommend this presentation for more information:
https://media.ccc.de/browse/congress/2014/31c3_-_6240_-_en_-_saal_g_-_201412...
Looks to be a long video - I'll add it to my queue.
For direct video download links: https://media.ccc.de/browse/congress/2014/31c3_-_6240_-_en_-_saal_g_-_201412...
It should be possible to force a static version with "make VERSION='xyz'", but I'd ask that that not be done for production builds as it makes handling trouble reports harder.
I would recommend to use `git describe --tags --dirty` output, which tells if there are any local modifications.
"git describe" is already there - see my recent email to Ian.
It's important that there's nothing additional in the string that changes depending on transient things outside of the source code. I.e. it needs to be nothing but describe output, and I think it would be nice if it were the default, so as to support reproducible builds out of the box.
If someone wants to add a SeaBIOS build flag to help with building a reproducible version, I'm okay with that. (Contrary to my earlier email, "make VERSION=xyz" no longer works.) I do not agree it should be the default.
-Kevin
On Di, 2015-02-03 at 10:58 -0500, Kevin O'Connor wrote:
On Tue, Feb 03, 2015 at 01:23:53PM +0100, Olaf Hering wrote:
The timestamp and hostname carries no value for the default build. If its really required in special environment, or if someone is emotionally attached to such strings, it is is handled by existing logic a few lines above: provide your own .version file
Once this patch is applied it is possible to get reproducible builds of Xens hvmloader.
I've found the version information to be quite helpful when we get trouble reports - it helps indicate what was being run and who built the code (eg, distribution or local).
Well, we patch out the very same line. Then 'echo "%{name}-%{version}-% release" > .version' in the rpm spec file is used to set the version string.
That way the version string compiled into the seabios binary matches the rpm package version, which is alot more useful than the build timestamp from a distribution point of view.
Using $(hostname) to see who built it isn't that great either. It may require insider knowledge to be useful. For example the prebuilt bios binaries in the upstram qemu git repo carry nilsson.home.kraxel.org because that happens to be the machine I'm doing the builds on. Not exactly obvious.
During development cycles, it helps verify that test runs are executed with the expected code.
I've found the 'git --describe' used when building from a git tree being good enough for this, I almost never look at the timestamp.
What breaks if the version changes?
Build twice from same source tree, diff binaries, figure they are not identical.
cheers, Gerd
-
Gerd Hoffmann -
Ian Campbell -
Kevin O'Connor -
Olaf Hering -
Peter Stuge