Your message dated Wed, 2 Sep 2026 22:39:55 +0200
with message-id <[email protected]>
and subject line Re: Bug#1146425: update sbuild on buildds to trixie-backports:
fix M-A:same binNMUs
has caused the Debian Bug report #1146425,
regarding update sbuild on buildds to trixie-backports: fix M-A:same binNMUs
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1146425: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1146425
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: buildd.debian.org
X-Debbugs-Cc: [email protected]
Hello,
there is a long-standing problem in Debian in that binNMUs of
Multi-Arch:same packages tend to not be coinstallable. As we introduced
Multi-Arch into Debian policy, this is a violation of a must and an RC
bug. This renders a fraction of our archive (I guess around 5% to 10%)
binNMU-unsafe.
The backstory is available at
https://salsa.debian.org/debian/sbuild/-/merge_requests/233 in detail.
Roughly speaking, a binNMU adds an arch-specific changelog entry and
uses the time of performing the binNMU as timestamp. This timestamp
naturally differs from buildd to buildd and often even the date differs
when an architecture has difficulties catching up. dpkg then uses this
timestamp as SOURCE_DATE_EPOCH. Many other tools then embed the relevant
date into shared output artifacts such as documentation. A violation of
Multi-Arch: same results.
The default behavior of sbuild has been changed in version 0.91.9 to
compute deterministic timestamps for binNMUs by default. An earlier
attempt used the timestamp of the source changelog, but that would cause
binNMUs to reuse the exact same timestamp as an earlier build. It would
result in confusing Ian's backup system which expects timestamps to
change when file contents change. A rebuild of a package must increase
the SOURCE_DATE_EPOCH. Strict monotonicity is now achieved by adding the
binNMU counter to the source changelog timestamp in seconds.
This change has been uploaded to trixie-backports as 0.91.9~bpo13+1, but
it could also be cherry-picked into a copy of sbuild used by the buildd
team. It is available since May and hasn't encountered bug reports yet.
I ask the wanna-build team to update sbuild on the buildd machines to
include this change either via backports or by using a fork of sbuild
specifically backporting this. If you prefer the latter, I volunteer to
rebase the patch.
Thanks for considering
Helmut
--- End Message ---
--- Begin Message ---
Hi,
On 2026-09-01 21:26, Helmut Grohne wrote:
> Package: buildd.debian.org
> X-Debbugs-Cc: [email protected]
>
> Hello,
>
> there is a long-standing problem in Debian in that binNMUs of
> Multi-Arch:same packages tend to not be coinstallable. As we introduced
> Multi-Arch into Debian policy, this is a violation of a must and an RC
> bug. This renders a fraction of our archive (I guess around 5% to 10%)
> binNMU-unsafe.
>
> The backstory is available at
> https://salsa.debian.org/debian/sbuild/-/merge_requests/233 in detail.
> Roughly speaking, a binNMU adds an arch-specific changelog entry and
> uses the time of performing the binNMU as timestamp. This timestamp
> naturally differs from buildd to buildd and often even the date differs
> when an architecture has difficulties catching up. dpkg then uses this
> timestamp as SOURCE_DATE_EPOCH. Many other tools then embed the relevant
> date into shared output artifacts such as documentation. A violation of
> Multi-Arch: same results.
>
> The default behavior of sbuild has been changed in version 0.91.9 to
> compute deterministic timestamps for binNMUs by default. An earlier
> attempt used the timestamp of the source changelog, but that would cause
> binNMUs to reuse the exact same timestamp as an earlier build. It would
> result in confusing Ian's backup system which expects timestamps to
> change when file contents change. A rebuild of a package must increase
> the SOURCE_DATE_EPOCH. Strict monotonicity is now achieved by adding the
> binNMU counter to the source changelog timestamp in seconds.
>
> This change has been uploaded to trixie-backports as 0.91.9~bpo13+1, but
> it could also be cherry-picked into a copy of sbuild used by the buildd
> team. It is available since May and hasn't encountered bug reports yet.
>
> I ask the wanna-build team to update sbuild on the buildd machines to
> include this change either via backports or by using a fork of sbuild
> specifically backporting this. If you prefer the latter, I volunteer to
> rebase the patch.
This has been pushed via puppet and all buildds got upgraded to the bpo
version.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
[email protected] http://aurel32.net
--- End Message ---
