Proposal for making Multi-Arch:same binNMU-safe

Simon Josefsson simon at josefsson.org
Thu Apr 16 09:25:13 BST 2026


Jochen Sprickerhof <jspricke at debian.org> writes:

> Hi Wookey,
>
> * Wookey <wookey at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260416/b9c3304f/attachment.sig>


More information about the Reproducible-builds mailing list