[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