Jochen Sprickerhof <jspricke@debian.org> writes: > Hi Wookey, > > * Wookey <wookey@wookware.org> [2026-04-15 19:59]: >>Which Ian are we talking about here (or is there a backup package in >> debian called 'Ian's backup system')? >>Does this issue affect more people than 'Ian'? >> >>Why does it break when binNMUs are built to (internally) match the >> SOURCE_DATE_EPOCH? >> >>Should a backup system not be able to cope with new files that have >>old dates in them (are the timestamps of the debs themselves set to >>the SOURCE_DATE_EPOCH?) >> >>Essentially I am wondering if perhaps this backup system should be >>fixed, rather than the build systems changed? >> >>Perhaps this has all been discussed already somewhere, and there is a >>good reason why this option has not been included in the solution-set? >>If so, do you have a pointer? > > See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843773 The problem isn't entirely well analyzed or summarized there, I think. In the thread, it seems the problem is that the newly built binNMU *.deb's have a modified time which is the same as the old ones, and that this is what causes problems for the backup system. Is that a correct reading? If so, I wonder: what code is setting the modtime of newly built files to SOURCE_DATE_EPOCH?! That seems bogus to me. Newly built files should have a new modtime. The (potentially arch-conflicting files) INSIDE that package should be identical to the old one, though, if the package supports reproducible builds. Modulo the changelog.Debian.ARCH.gz file. I may be mis-reading the bug report, because IIRC binNMU *.deb's ought to have different filenames too. If some backup system gets confused by two non-identical *.deb's with different filenames having the same modtime, that seems like a rather problematic backup system to me. Using different modtime's would solve that, though, it seems. /Simon
Attachment:
signature.asc
Description: PGP signature