Your message dated Tue, 08 Sep 2020 11:05:13 +0300
with message-id <[email protected]>
and subject line Re: gst-plugins-base1.0 embeds current timestamp in .rodata of
all objects, making the build unreproducible
has caused the Debian Bug report #787124,
regarding gst-plugins-base1.0 embeds current timestamp in .rodata of all
objects, making the build unreproducible
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
787124: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787124
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: gst-plugins-base1.0
Version: 1.5.0.1+git20150513-1
User: [email protected]
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
--- End Message ---
--- Begin Message ---
This should be fixed since quite some time. The release time is now
taken from a file that is shipped with the tarballs.
--- End Message ---
