In a -dev package providing an Ada library, Ada Library Information (.ali) files contain the mtime of each Ada source (.ads) file that they index. Any patched or generated Ada source will cause the build time to be embedded in the ALI file of every reverse dependency.

Detection

A file named /usr/lib/gnutriplet/ada/adalib/packagename/*.ali contains a line like 

131 D templates_parser.ads  20150226112341 7c7455e7

where the date in the fourth field happens after the extraction of the source package.

The GCC build ID may also be modified by this timestamp.

Checking this with lintian is not trivial, as the last changelog entry may not be available in the binary package, in case for example /usr/share/doc/package is a symbolic link to another package.

Work around

The "Adjusting mtimes" solution described for this similar issue may be applied between the last source modification and the call to gnatmake/gprbuild/gcc building the dynamic library. 

DEB_DATE := $(shell dpkg-parsechangelog -S date)
# Ensure deterministic timestamps in ALI files.
find . -name "*.ad[bs]" -a -newermt '$(DEB_DATE)' -print0 | \
  xargs -0r touch --no-dereference --date='$(DEB_DATE)'

Of course, tampering with timestamps may confuse Make, for example if generated sources are used as Make targets.

Solution

Fixed in version gcc-7/7-20170302-1, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856042. If GCC finds a SOURCE_DATE_EPOCH in the environment, it will truncate any timestamp written into an ALI file to this epoch.