dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

Jean-Michel Vourgère nirgal at debian.org
Fri Mar 30 10:42:27 UTC 2018


Package: dpkg-dev
Version: 1.19.0.5
Severity: important
Justification: Make unrelated packages violate multi-arch specs

Dear Maintainer,

When doing bin-nmu, each architecture gets its own d/changelog entry like:


rrdtool (1.7.0-1+b1) sid; urgency=low, binary-only=yes
  * Binary-only non-maintainer upload for arm64; no source changes.
  * Rebuild without ruby2.3 support.
 -- arm Build Daemon (arm-conova-01) <buildd_arm64-arm-
conova-01 at buildd.debian.org>  Tue, 27 Mar 2018 12:27:33 +0000


rrdtool (1.7.0-1+b1) sid; urgency=low, binary-only=yes
  * Binary-only non-maintainer upload for armhf; no source changes.
  * Rebuild without ruby2.3 support.
 -- armhf / armel Build Daemon (hoiby) <buildd_armhf-hoiby at buildd.debian.org>  
Wed, 28 Mar 2018 08:13:09 +0000


As a result, when building rrdtool +b1 on arm64 [1] we have:
SOURCE_DATE_EPOCH="1522153653"
while on armhf [2] we have:
SOURCE_DATE_EPOCH="1522224789"

This causes the packages librrds-perl - that uses pod2man - to get /usr/share/
man/man3/RRDs.3pm.gz having different files on different architectures:
On amd64 architecture:
.TH RRDs 3pm "2018-03-27" "perl v5.26.1" "User Contributed Perl Documentation"
On armhf architecture:
.TH RRDs 3pm "2018-03-28" "perl v5.26.1" "User Contributed Perl Documentation"

This in turn results in the package no longer being Multi-arch:same after the 
bin-nmus, as reported by 

Since a bin-nmu can occur for a single architecture, I believe the best course 
of action would be to change dpkg-buildpackage behavior to keep previous 
SOURCE_DATE_EPOCH when building a bin-nmu'ed package. This could be achive by 
ignoring the entries in d/changelog that contain the "binary-only=yes" tag 
when setting SOURCE_DATE_EPOCH.
Note that I did not test this solution. WB team input would be great at this 
point.

Appologies for the severity. While multi-arch is not part of the policy 
(#749826), I guess it is used wildly-enough to justify this. Fell free to 
adjust, obviously.

See also https://lists.debian.org/debian-wb-team/2018/03/msg00040.html

[1] https://buildd.debian.org/status/fetch.php?
pkg=rrdtool&arch=arm64&ver=1.7.0-1%2Bb1&stamp=1522153882&raw=0
[2] https://buildd.debian.org/status/fetch.php?
pkg=rrdtool&arch=armhf&ver=1.7.0-1%2Bb1&stamp=1522225293&raw=0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20180330/227fdeb7/attachment.sig>


More information about the Reproducible-builds mailing list