I have just had my backups fail due to the following chain of events: * I had python2.7-stdlib:amd64 2.7.12-3 installed * I did a backup * I upgraded to python2.7-stdlib:amd64 2.7.12-3+b1 was built * I did another backup, during which: * Many files were not copied to the backup volume because their mtimes had not changed * However, the contents of these files had changed because of the rebuild * My backup system is clever enough to spot that there is a problem
I see the python2.7 source package does this: LAST_CHANGE := $(shell dpkg-parsechangelog -S Date) export BUILD_DATE := $(shell LC_ALL=C date -u +'%b %e %Y' -d '$(LAST_CHANGE)') export BUILD_TIME := $(shell LC_ALL=C date -u +'%H:%M:%S' -d '$(LAST_CHANGE)') Is this a recommended recipe ? AIUI a buildd doing a binnmu will not modify the debian/changelog file. The result is that the file timestamps will be lies after a binnmu. I think this is quite undesirable. Less careful backup programs than mine wouldn't notice. The results would then be a corrupted backup, which would break when restored. There are probably other bad consequences. Can we come up with a better recipe ? For example perhaps DEBIAN_LAST_CHANGE ?= $(shell dpkg-parsechangelog -S Date) which would make it possible for a buildd to override the value. Thanks for your attention. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter. _______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds