Embedded version strings causes non-deterministic builds

[grawlinson]

Just going through our repositories and ensuring all packages are deterministic/reproducible when I came across an issue with timescaledb. Some background on reproducible builds.

The project seems to hardcode some strings at compile-time, as shown below:

timescaledb/src/config.h.in

Lines 10 to 13 in eace5ea

	#define BUILD_OS_NAME "@CMAKE_SYSTEM_NAME@"
	#define BUILD_OS_VERSION "@CMAKE_SYSTEM_VERSION@"
	#define BUILD_PROCESSOR "@CMAKE_SYSTEM_PROCESSOR@"
	#define BUILD_POINTER_BYTES @CMAKE_SIZEOF_VOID_P@

Here's the plain-text output showing where the package fails reproducibility. If you don't want to read the output (I don't blame you, it can be a bit verbose); the packages are shown to be non-reproducible when compiled on a different kernel version, which happens on a regular basis with Arch Linux.

Is there any particular reason why the full kernel version needs to be hardcoded in the binary?

[mkindahl]

Thanks for the bug report @grawlinson. The link to the plain-text output above does not show anything. Could you paste parts of the text in the bug report so that we can find it later?

[grawlinson]

Apologies, seems that previous build output isn't saved.

So far through testing (compiling timescaledb on machines with different kernel releases), the only hardcoded variable that changes in-between builds is BUILD_OS_VERSION. As a rule of thumb, variables that change regularly shouldn't really make its way into the resultant binary.

What I've done downstream is patched out the BUILD_OS_VERSION with rolling, as that's what lsb_release -r will output on a machine running Arch Linux. This will affect other distributions, should they choose to package timescaledb AND ensure builds are reproducible.