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.
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.
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.
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.