Bug#787124: gst-plugins-base1.0 embeds current timestamp in .rodata of all objects, making the build unreproducible

[Daniel Kahn Gillmor]

Package: gst-plugins-base1.0
Version: 1.5.0.1+git20150513-1
User: reproducible-builds at lists.alioth.debian.org
Usertags: timestamps

gstreamer's build process appears to want to embed the current timestamp
in binaries if they are being built from a snaphost.

You can see the current build timestamps embedded here:

https://reproducible.debian.net/dbd/experimental/amd64/gst-plugins-base1.0_1.5.0.1+git20150513-1.debbindiff.html

>From the build logs, you can see ./configure setting the variable:

https://reproducible.debian.net/rbuild/experimental/amd64/gst-plugins-base1.0_1.5.0.1+git20150513-1.rbuild.log

configure: Setting GST_PACKAGE_RELEASE_DATETIME to 2015-05-14T02:55Z

And that then gets embedded in the binaries.


I think this is getting set via gst-package-release-datetime.m4:

https://sources.debian.net/src/gst-plugins-base1.0/1.5.0.1%2Bgit20150513-1/common/m4/gst-package-release-datetime.m4/

which shows that it is being triggered only when the 4th element of the
release version is non-zero:

> dnl We need to treat pre-releases like git because there won't be an entry
> dnl in the .doap file for pre-releases yet, and we don't want to use the
> dnl date of the last release either.

So maybe a fix would be to modify
AG_GST_SET_PACKAGE_RELEASE_DATETIME_WITH_NANO to accept one more
argument, which is an externally-supplied timestamp (if some env var
present?  via an argument to ./configure?), and then to have the debian
package set that timestamp based on the most recent changelog entry.

I'm not enough of an m4 hacker to propose a concrete change here, sorry!

Regards,

        --dkg