[Reproducible-builds] dpkg has lost some of its superpowers
Niko Tyni
ntyni at debian.org
Mon Oct 12 07:58:34 UTC 2015
On Sun, Oct 11, 2015 at 06:30:28PM +0000, Santiago Vila wrote:
> On Sun, Oct 11, 2015 at 12:35:18PM +0000, Santiago Vila wrote:
>
> > │ -rw-r--r-- 0/0 4 Oct 11 12:08 2015 debian-binary
> > │ -rw-r--r-- 0/0 4814 Oct 11 12:08 2015 control.tar.gz
> > │ -rw-r--r-- 0/0 250668 Oct 11 12:08 2015 data.tar.xz
> > │ +rw-r--r-- 0/0 4 Oct 11 12:10 2015 debian-binary
> > │ +rw-r--r-- 0/0 4814 Oct 11 12:10 2015 control.tar.gz
> > │ +rw-r--r-- 0/0 250668 Oct 11 12:10 2015 data.tar.xz
>
> Ok, as an experiment I managed this to be 1970-01-01 by setting
> SOURCE_DATE_EPOCH=0 before dpkg-buildpackage.
>
> But I don't think setting such variable should be required, because
> then: why Bug #759999 talks about the latest changelog entry?
>
> This is supposed to be automatic, right?
The perl package is affected too fwiw.
The 5eacc4dbec35525468ad195e6b026a857dc12220 commit message (in
dpkg pu/reproducible_builds) talks about dpkg-buildpackage setting
SOURCE_DATE_EPOCH, but the code uses DEB_BUILD_TIMESTAMP.
So if I understand this correctly, dpkg-buildpackage now sets
DEB_BUILD_TIMESTAMP but dpkg-deb looks at SOURCE_DATE_EPOCH.
Looks like an accidental merge/rebase error to me?
--
Niko Tyni ntyni at debian.org
More information about the Reproducible-builds
mailing list