From noreply at release.debian.org  Mon Apr 13 05:39:08 2026
From: noreply at release.debian.org (Debian testing watch)
Date: Mon, 13 Apr 2026 04:39:08 +0000
Subject: diffoscope 317 MIGRATED to testing
Message-ID: <E1wC94m-002ndR-37@respighi.debian.org>

FYI: The status of the diffoscope source package
in Debian's testing distribution has changed.

  Previous version: 316
  Current version:  317

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.


From ebender at niceguanjia.com  Tue Apr 14 01:02:03 2026
From: ebender at niceguanjia.com (Oliver Wolf)
Date: Tue, 14 Apr 2026 02:02:03 +0200
Subject: Business inquiry for electric bicycle cooperation
Message-ID: <s537m9ZQsYHU784W0oWi3t=BXuSBJ2MN2fnxfuqbLMkFN@limokc.com>

Dealer Inquiry: E-Bike Supply OptionsEnglish section above. Der deutsche Text steht direkt danach.Dear Team,

We would like to briefly introduce several e-bike options that could be relevant for your purchasing plan.

Our range is positioned for practical daily riding, with stable handling, useful equipment, and a style that is easy to present to end customers.

When inventory is available in the Germany warehouse, EU delivery can typically...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260414/20137f9b/attachment.htm>

From noreply at release.debian.org  Tue Apr 14 05:39:21 2026
From: noreply at release.debian.org (Debian testing autoremoval watch)
Date: Tue, 14 Apr 2026 04:39:21 +0000
Subject: diffoscope is marked for autoremoval from testing
Message-ID: <E1wCVYX-00408y-0g@respighi.debian.org>

diffoscope 317 is marked for autoremoval from testing on 2026-05-13

It (build-)depends on packages with these RC bugs:
1131838: libguestfs: qemu does not exist on 32bit hosts anymore, but libguestfs build-depends on it (and other qemu deps issues)
 https://bugs.debian.org/1131838



For more information on the autoremoval process, including hints to prevent
autoremoval can be found on the wiki: https://wiki.debian.org/Autoremoval

This mail is generated by:
https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl

Autoremoval data is generated by:
https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl


From news at carpediemdmc.mailgraf.net  Tue Apr 14 09:39:14 2026
From: news at carpediemdmc.mailgraf.net (Carpe Diem Events)
Date: Tue, 14 Apr 2026 10:39:14 +0200 (CEST)
Subject: =?UTF-8?Q?Invita=C8=9Bie_la_=C3=AEnt=C3=A2lnirile_B2B_din_Rom=C3=A2nia?=
Message-ID: <wgk5ox3b7xxtubsiop3lcslzjt5spkfwu7dyxgq@carpediemdmc.mailgraf.net>

If you cannot read our email or can only read part of it, please click here. (https://carpediemdmc.mailgraf.net/i/fpOQtGbSJNf_HU1w7mPbWHgtRmTUbNysc5bdycWiR9zWnh4uuc1cmQ)

Bun? ziua,

Avem pl?cerea de a v? invita la un eveniment de networking organizat de Asocia?ia Exportatorilor Turci, care va conecta produc?tori turci cu companii rom?ne?ti.

Descoperi?i oportunit??i ?n industrii cheie precum: textile ?i mod?, automotive, utilaje, agricultur? ?i produse alimentare, chimicale, s?n?tate, materiale de construc?ii, electronice, mobil? ?i altele.

Detalii eveniment:

Data: 29 aprilie 2026

Ora: 10:00 ? 18:00

Loca?ie: InterContinental Ath?n?e Palace, Bucure?ti

Participarea este gratuit? pentru companiile rom?ne?ti, iar serviciile de traducere vor fi oferite gratuit.

Al?tura?i-v? pentru a descoperi noi furnizori, a v? extinde re?eaua de contacte ?i a construi parteneriate valoroase.

V? rug?m s? confirma?i participarea r?spunz?nd la acest e-mail sau s? ob?ine?i biletul gratuit acces?nd butonul de mai jos.

Cu stim?,

Echipa Carpe Diem Event

E: b2b at carpediemdmc.com (mailto:b2b at carpediemdmc.com)

Vizita?i site-ul web al evenimentului (https://carpediemdmc.mailgraf.net/i/8Ol4SWeflVWsqnetfq0NXVirMQB3f5PvbVtf4YN8cfs)

CARPE DIEM EVENTS & DESTINATION MANAGEMENT

ADDRESS: Three Sails Tower18th Floor, C3 P.O Box 106994 Abu Dhabi - UAE

PHONE: +971 56 202 2676
WEBSITE: www.carpediemdmc.com

This content has been sent to you because you are a Carpe Diem Events subscriber.

Please contact us at b2b at carpediemdmc.com (mailto:b2b at carpediemdmc.com?subject=Unsubscribe) for any information requests.

To Unsubscribe? Please click here (https://carpediemdmc.mailgraf.net/i/63ksTTXESCHMuA6qKyxDkK8XPNhaS6M897p-admQ-nc).

Powered by MailGraf (https://carpediemdmc.mailgraf.net/i/tAFaC2CyGVLes6qMplDLLQA_Y2Y6FuDH7koYXII03EA)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260414/d95405a3/attachment.htm>

From helmut at subdivi.de  Wed Apr 15 10:49:42 2026
From: helmut at subdivi.de (Helmut Grohne)
Date: Wed, 15 Apr 2026 11:49:42 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
Message-ID: <20260415094942.GA99313@subdivi.de>

Hello,

I am reaching out to the wanna build team (where I see changes needed),
reproducible builds (as a driving force for deterministic build
artifacts), sbuild team (where I see changes needed) and cross builders
(as the main consumers of packages marked Multi-Arch: same).

Problem
=======

When requesting a binNMU, the changelog entry is generated on the build
daemon. The timestamp used is the time the build was started. When
building a Multi-Arch: same package for multiple architectures, this
timestamp typically differs between architectures. Due to reproducible
builds, this timestamp is then transferred to SOURCE_DATE_EPOCH where it
is used by various build systems for creating reproducible artifacts.
Often times, it ends up in e.g. C header files. Those end up being
reproducible, but architectures reproduce varying contents. This tends
to break coinstallation.

Earlier, SOURCE_DATE_EPOCH was seeded from the most recent non-binNMU
timestamp, but that happened to break Ian's backup system. It used to
make Multi-Arch: same work though.

Proposed solution
=================

Use the timestamp of when the binNMU was requested in the binNMU
changelog.

When running wanna-build --binNMU (e.g. via wb wrapper), a row is
inserted into the transactions table for each architecture setting the
action to --binNMU. The first change here is using the same timestamp
for all those rows. The time column already is not unique and this would
coalesce a few more timestamps to the same values.

When a build daemon "takes" a build using API version 1, it receives a
YAML object containing metadata about the build being performed. This
happens to include the binNMU increment and the changelog text. This
should be augmented with a new field named binNMU-timestamp. Existing
autobuilders deal with unknown extra fields and ignore it.

To get the timestamp during the take action, there are two possible
approaches. It mainly draws information from the packages table, but
does not record the relevant timestamp. Therefore, another SQL query
would be needed to query the transactions table for the most recent time
a --binNMU was requested for the same
package/version/architecture/distribution combination. This can work
given that a newer binNMU cancels out an earlier one.

Alternatively, the packages table is augmented with a new column
recording the timestamp when the binNMU was requested. This would be
readily available in the subroutine add_one_building and could be
emitted. In my opinion, this would be slightly cleaner at the cost of a
schema change.

>From here we leave the wanna-build source code and continue in sbuild.
It already has --binNMU-timestamp and all that the buildd code would
have to do here is check for the newly added field and pass it along
using the new option. When the field is not provided, the option is
skipped. Thus, this change would also be backwards compatible.

Updated wanna-build would work with old buidds and updated buildds would
work with old wanna-build. Only when both are updated, the timestamp
would be changed and an entire class of Multi-Arch: same file conflicts
would go away.

Discussion
==========

What do you think about this solution?

buildd team:
 * Would you be ok with the projected extensions?
 * Do you prefer the schema change or the extra query?

reproducible team:
 * Do you see any issues arising from the projected changes?

sbuild team:
 * Would you be ok with the projected changes?

all:
 * Do you see any reason for why this would not work?

Let me answer for cross builders that this would fix somewhere between
10 and 100 M-A:same file conflicts. This always is a latent problem that
only surfaces once a package is binNMUed and therefore the full scale is
difficult to gauge.

Ian's backup system would be happy with this as far as I can tell.

Helmut



From josch at debian.org  Wed Apr 15 12:08:20 2026
From: josch at debian.org (Johannes Schauer Marin Rodrigues)
Date: Wed, 15 Apr 2026 13:08:20 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <20260415094942.GA99313@subdivi.de>
References: <20260415094942.GA99313@subdivi.de>
Message-ID: <177625130050.8007.6479366885756825982@localhost>

Quoting Helmut Grohne (2026-04-15 11:49:42)
> From here we leave the wanna-build source code and continue in sbuild.  It
> already has --binNMU-timestamp and all that the buildd code would have to do
> here is check for the newly added field and pass it along using the new
> option. When the field is not provided, the option is skipped. Thus, this
> change would also be backwards compatible.
>
> [snip]
> 
> sbuild team:
>  * Would you be ok with the projected changes?

I do not see what change in sbuild would be required. As you pointed out, you
can already pass it the timestamp. What else would be needed? There is also
--binNMU-changelog which can be passed to completely control the changelog
entry without sbuild messing up anything.

We talked about this topic in the context of https://bugs.debian.org/843773
which also triggered the addition to --binNMU-changelog in sbuild.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260415/0b68e271/attachment.sig>

From simon at josefsson.org  Wed Apr 15 15:05:27 2026
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 15 Apr 2026 16:05:27 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <20260415094942.GA99313@subdivi.de> (Helmut Grohne's message of
 "Wed, 15 Apr 2026 11:49:42 +0200")
References: <20260415094942.GA99313@subdivi.de>
Message-ID: <875x5s2uag.fsf@josefsson.org>

Helmut Grohne <helmut at subdivi.de> writes:

> Proposed solution
> =================
>
> Use the timestamp of when the binNMU was requested in the binNMU
> changelog.

Couldn't we use the timestamp of the last source upload instead?

That is, whatever code set SOURCE_DATE_EPOCH based on debian/changelog
timestamps has to be modified.  Instead of using the timestamp of the
most recent entry, have it skip over all binNMU entries to find the
timestamp of the most recent non-binNMU entry.

Setting SOURCE_DATE_EPOCH to the binary build date seems strange to me,
even if you were to force it to be identical for all binNMU archs.

This approach also solves partial binNMU: sometimes there is no point in
scheduling a binNMU for all architectures, but only for a particular
one.  With my approach, the SOURCE_DATE_EPOCH value will be the same for
these partiaul binNMU's, but with your approach it will differ from the
earlier non-binNMU SOURCE_DATE_EPOCH value.

/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/20260415/757dfaf8/attachment.sig>

From helmut at subdivi.de  Wed Apr 15 13:57:48 2026
From: helmut at subdivi.de (Helmut Grohne)
Date: Wed, 15 Apr 2026 14:57:48 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <177625130050.8007.6479366885756825982@localhost>
References: <20260415094942.GA99313@subdivi.de>
 <177625130050.8007.6479366885756825982@localhost>
Message-ID: <20260415125748.GB214615@subdivi.de>

Hi Johannes,

On Wed, Apr 15, 2026 at 01:08:20PM +0200, Johannes Schauer Marin Rodrigues wrote:
> I do not see what change in sbuild would be required. As you pointed out, you
> can already pass it the timestamp. What else would be needed? There is also
> --binNMU-changelog which can be passed to completely control the changelog
> entry without sbuild messing up anything.

The sbuild source package also builds the buildd binary package. It
contains the code that adds --binNMU-changelog and I argue that it
should also be adding the --binNMU-timestamp flag. See
lib/Buildd/Daemon.pm. This is pending an agreement with the wanna-build
team of how wanna-build communicates such a timestamp.

Helmut



From helmut at subdivi.de  Wed Apr 15 15:34:19 2026
From: helmut at subdivi.de (Helmut Grohne)
Date: Wed, 15 Apr 2026 16:34:19 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <875x5s2uag.fsf@josefsson.org>
References: <20260415094942.GA99313@subdivi.de> <875x5s2uag.fsf@josefsson.org>
Message-ID: <20260415143419.GA216388@subdivi.de>

Hi Simon,

On Wed, Apr 15, 2026 at 04:05:27PM +0200, Simon Josefsson wrote:
> Couldn't we use the timestamp of the last source upload instead?
>
> That is, whatever code set SOURCE_DATE_EPOCH based on debian/changelog
> timestamps has to be modified.  Instead of using the timestamp of the
> most recent entry, have it skip over all binNMU entries to find the
> timestamp of the most recent non-binNMU entry.

That's an earlier solution. It was discarded, because it broke Ian's
backup system. With that scheme, a binNMU could change a file and retain
is modification time. This breaks the principle of least surprise.

> Setting SOURCE_DATE_EPOCH to the binary build date seems strange to me,
> even if you were to force it to be identical for all binNMU archs.

That's what we presently do except that it is different for each
architecture.

> This approach also solves partial binNMU: sometimes there is no point in
> scheduling a binNMU for all architectures, but only for a particular
> one.  With my approach, the SOURCE_DATE_EPOCH value will be the same for
> these partiaul binNMU's, but with your approach it will differ from the
> earlier non-binNMU SOURCE_DATE_EPOCH value.

It does not. Besides files having equal contents, the version of the
package must match exactly. Of course we could relax that, but then the
point of a binNMU is to get a different result, so we'd trade a new set
of problems arising from various binNMUs having become coinstallable
that really should not be coinstallable.

Helmut



From josch at debian.org  Wed Apr 15 16:49:45 2026
From: josch at debian.org (Johannes Schauer Marin Rodrigues)
Date: Wed, 15 Apr 2026 17:49:45 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <20260415125748.GB214615@subdivi.de>
References: <20260415094942.GA99313@subdivi.de>
 <177625130050.8007.6479366885756825982@localhost>
 <20260415125748.GB214615@subdivi.de>
Message-ID: <177626818546.8007.7691030193287809130@localhost>

Hi,

Quoting Helmut Grohne (2026-04-15 14:57:48)
> On Wed, Apr 15, 2026 at 01:08:20PM +0200, Johannes Schauer Marin Rodrigues
> wrote:
> > I do not see what change in sbuild would be required. As you pointed out, you
> > can already pass it the timestamp. What else would be needed? There is also
> > --binNMU-changelog which can be passed to completely control the changelog
> > entry without sbuild messing up anything.
> 
> The sbuild source package also builds the buildd binary package. It
> contains the code that adds --binNMU-changelog and I argue that it
> should also be adding the --binNMU-timestamp flag. See
> lib/Buildd/Daemon.pm. This is pending an agreement with the wanna-build team
> of how wanna-build communicates such a timestamp.

ah okay. I do not consider myself responsible for the buildd scripts and libs
and according to "git log bin/buildd* lib/Buildd/" I have only ever touched
them five times in my 11 years of sbuild involvment. I consider the
responsibility for the buildd scripts 100% on the wb-team and when they
want/need to change something, at least as far as I am concerned, they can just
perform whatever change they want and upload it. Maybe Jochen wants to have a
say but from my side, the wb-team can just do whatever they need with that part
of sbuild. Thank you for your work!

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260415/5a921162/attachment.sig>

From jspricke at debian.org  Wed Apr 15 17:39:52 2026
From: jspricke at debian.org (Jochen Sprickerhof)
Date: Wed, 15 Apr 2026 18:39:52 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <177626818546.8007.7691030193287809130@localhost>
References: <20260415094942.GA99313@subdivi.de>
 <177625130050.8007.6479366885756825982@localhost>
 <20260415125748.GB214615@subdivi.de>
 <177626818546.8007.7691030193287809130@localhost>
Message-ID: <ad-_WCiC0sjcgxAQ@vis>

* Johannes Schauer Marin Rodrigues <josch at debian.org> [2026-04-15 17:49]:
>perform whatever change they want and upload it. Maybe Jochen wants to have a
>say but from my side, the wb-team can just do whatever they need with that part
>of sbuild. Thank you for your work!

I quickly discussed this with Helmut earlier today and I am fine with 
it. Happy to see anyone do the needed changes on the sbuild side or I 
can do an upload if preferred. Looking forward to get this fixed :).

Cheers Jochen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260415/05f4447c/attachment.sig>

From wookey at wookware.org  Wed Apr 15 19:59:31 2026
From: wookey at wookware.org (Wookey)
Date: Wed, 15 Apr 2026 19:59:31 +0100
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <20260415143419.GA216388@subdivi.de>
References: <20260415094942.GA99313@subdivi.de> <875x5s2uag.fsf@josefsson.org>
 <20260415143419.GA216388@subdivi.de>
Message-ID: <ad_gEw60JnbJftKx@mail.wookware.org>

On 2026-04-15 16:34 +0200, Helmut Grohne wrote:
>Hi Simon,
>
>On Wed, Apr 15, 2026 at 04:05:27PM +0200, Simon Josefsson wrote:
>> Couldn't we use the timestamp of the last source upload instead?
>>
>> That is, whatever code set SOURCE_DATE_EPOCH based on debian/changelog
>> timestamps has to be modified.  Instead of using the timestamp of the
>> most recent entry, have it skip over all binNMU entries to find the
>> timestamp of the most recent non-binNMU entry.
>
>That's an earlier solution. It was discarded, because it broke Ian's
>backup system.

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?

Wookey
-- 
Principal hats:  Wookware, Debian
http://wookware.org/
Matrix: @wookey:matrix.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260415/42af61ce/attachment.sig>

From jspricke at debian.org  Wed Apr 15 20:25:40 2026
From: jspricke at debian.org (Jochen Sprickerhof)
Date: Wed, 15 Apr 2026 21:25:40 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <ad_gEw60JnbJftKx@mail.wookware.org>
References: <20260415094942.GA99313@subdivi.de> <875x5s2uag.fsf@josefsson.org>
 <20260415143419.GA216388@subdivi.de>
 <ad_gEw60JnbJftKx@mail.wookware.org>
Message-ID: <ad_mNI29nRO2mHWn@vis>

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

Cheers Jochen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260415/7ce5a8ab/attachment.sig>

From josch at debian.org  Wed Apr 15 20:33:08 2026
From: josch at debian.org (Johannes Schauer Marin Rodrigues)
Date: Wed, 15 Apr 2026 21:33:08 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <ad_gEw60JnbJftKx@mail.wookware.org>
References: <20260415094942.GA99313@subdivi.de> <875x5s2uag.fsf@josefsson.org>
 <20260415143419.GA216388@subdivi.de> <ad_gEw60JnbJftKx@mail.wookware.org>
Message-ID: <177628158873.8007.13266865689864294077@localhost>

Hi,

Quoting Wookey (2026-04-15 20:59:31)
> On 2026-04-15 16:34 +0200, Helmut Grohne wrote:
> >Hi Simon,
> >
> >On Wed, Apr 15, 2026 at 04:05:27PM +0200, Simon Josefsson wrote:
> >> Couldn't we use the timestamp of the last source upload instead?
> >>
> >> That is, whatever code set SOURCE_DATE_EPOCH based on debian/changelog
> >> timestamps has to be modified.  Instead of using the timestamp of the
> >> most recent entry, have it skip over all binNMU entries to find the
> >> timestamp of the most recent non-binNMU entry.
> >
> >That's an earlier solution. It was discarded, because it broke Ian's
> >backup system.
> 
> 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?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843773

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260415/583cd707/attachment.sig>

From pkern at debian.org  Wed Apr 15 21:26:29 2026
From: pkern at debian.org (Philipp Kern)
Date: Wed, 15 Apr 2026 22:26:29 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <177626818546.8007.7691030193287809130@localhost>
References: <20260415094942.GA99313@subdivi.de>
 <177625130050.8007.6479366885756825982@localhost>
 <20260415125748.GB214615@subdivi.de>
 <177626818546.8007.7691030193287809130@localhost>
Message-ID: <7d0c4d18-4c96-4016-9b6c-53d69e3dc543@debian.org>

On 4/15/26 5:49 PM, Johannes Schauer Marin Rodrigues wrote:
> ah okay. I do not consider myself responsible for the buildd scripts and libs
> and according to "git log bin/buildd* lib/Buildd/" I have only ever touched
> them five times in my 11 years of sbuild involvment. I consider the
> responsibility for the buildd scripts 100% on the wb-team and when they
> want/need to change something, at least as far as I am concerned, they can just
> perform whatever change they want and upload it. Maybe Jochen wants to have a
> say but from my side, the wb-team can just do whatever they need with that part
> of sbuild. Thank you for your work!

It's on my very near-term list to finally finish the pybuildd migration. 
Hopefully that eliminates the need there. I'm trying to get to that this 
month. (Running two stacks is annoying.)

Kind regards
Philipp Kern


From bunk at debian.org  Wed Apr 15 23:29:46 2026
From: bunk at debian.org (Adrian Bunk)
Date: Thu, 16 Apr 2026 01:29:46 +0300
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <20260415094942.GA99313@subdivi.de>
References: <20260415094942.GA99313@subdivi.de>
Message-ID: <aeARWi5C4yljTRSL@localhost>

On Wed, Apr 15, 2026 at 11:49:42AM +0200, Helmut Grohne wrote:
>...
> Proposed solution
> =================
> 
> Use the timestamp of when the binNMU was requested in the binNMU
> changelog.
> 
> When running wanna-build --binNMU (e.g. via wb wrapper), a row is
> inserted into the transactions table for each architecture setting the
> action to --binNMU. The first change here is using the same timestamp
> for all those rows. The time column already is not unique and this would
> coalesce a few more timestamps to the same values.
>...

"wb nmu <package> . ANY" creates (up to) 18 wanna-build commands, one 
per architecture. Depending on locking, there might be several seconds 
between the first and last command executed.

Other architectures are not binNMU'ed when a Multi-Arch: same package 
needs a binNMU only on a ports architecture, there might already be
a several years old timestamp for this binNMU number on an architecture 
when a "wb nmu <number> <package> . ANY" is issued.

> Helmut

cu
Adrian


From bunk at debian.org  Wed Apr 15 23:32:11 2026
From: bunk at debian.org (Adrian Bunk)
Date: Thu, 16 Apr 2026 01:32:11 +0300
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <20260415143419.GA216388@subdivi.de>
References: <20260415094942.GA99313@subdivi.de> <875x5s2uag.fsf@josefsson.org>
 <20260415143419.GA216388@subdivi.de>
Message-ID: <aeAR6y_2JXNko6ya@localhost>

On Wed, Apr 15, 2026 at 04:34:19PM +0200, Helmut Grohne wrote:
>...
> On Wed, Apr 15, 2026 at 04:05:27PM +0200, Simon Josefsson wrote:
> > Couldn't we use the timestamp of the last source upload instead?
> >
> > That is, whatever code set SOURCE_DATE_EPOCH based on debian/changelog
> > timestamps has to be modified.  Instead of using the timestamp of the
> > most recent entry, have it skip over all binNMU entries to find the
> > timestamp of the most recent non-binNMU entry.
> 
> That's an earlier solution. It was discarded, because it broke Ian's
> backup system. With that scheme, a binNMU could change a file and retain
> is modification time. This breaks the principle of least surprise.
>...

AFAIR I already suggested somewhere in these discussions that the date 
of a binNMU could be the date of the source upload plus the binNMU 
number added in seconds (e.g. +b5 is 5 seconds after the source upload).

> Helmut

cu
Adrian


From helmut at subdivi.de  Thu Apr 16 09:15:54 2026
From: helmut at subdivi.de (Helmut Grohne)
Date: Thu, 16 Apr 2026 10:15:54 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <aeAR6y_2JXNko6ya@localhost>
References: <20260415094942.GA99313@subdivi.de> <875x5s2uag.fsf@josefsson.org>
 <20260415143419.GA216388@subdivi.de> <aeAR6y_2JXNko6ya@localhost>
Message-ID: <20260416081554.GA286201@subdivi.de>

Hi Adrian,

On Thu, Apr 16, 2026 at 01:32:11AM +0300, Adrian Bunk wrote:
> AFAIR I already suggested somewhere in these discussions that the date 
> of a binNMU could be the date of the source upload plus the binNMU 
> number added in seconds (e.g. +b5 is 5 seconds after the source upload).

This keeps coming up. wRAR also mentioned it recently. If we gather
consensus about this alternative, I'm happy to implement it. From what I
can tell, all it takes is modifying pybuildd (not buildd) and making it
compute a suitable timestamp to pass to sbuild from the information that
it already has.

This is where I'd like input from the reproducible folks.

Helmut



From simon at josefsson.org  Thu Apr 16 09:25:13 2026
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 16 Apr 2026 10:25:13 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <ad_mNI29nRO2mHWn@vis> (Jochen Sprickerhof's message of "Wed, 15
 Apr 2026 21:25:40 +0200")
References: <20260415094942.GA99313@subdivi.de> <875x5s2uag.fsf@josefsson.org>
 <20260415143419.GA216388@subdivi.de>
 <ad_gEw60JnbJftKx@mail.wookware.org> <ad_mNI29nRO2mHWn@vis>
Message-ID: <87ldenmhw6.fsf@josefsson.org>

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>

From helmut at subdivi.de  Thu Apr 16 09:43:28 2026
From: helmut at subdivi.de (Helmut Grohne)
Date: Thu, 16 Apr 2026 10:43:28 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <87ldenmhw6.fsf@josefsson.org>
References: <20260415094942.GA99313@subdivi.de> <875x5s2uag.fsf@josefsson.org>
 <20260415143419.GA216388@subdivi.de>
 <ad_gEw60JnbJftKx@mail.wookware.org> <ad_mNI29nRO2mHWn@vis>
 <87ldenmhw6.fsf@josefsson.org>
Message-ID: <20260416084328.GA336031@subdivi.de>

Hi Simon,

On Thu, Apr 16, 2026 at 10:25:13AM +0200, Simon Josefsson wrote:
> 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?

Yes, Ian's backup system compares a recorded modification time to the
actual modification time and backs up the file unless they match
exactly.

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

That is what we did for a long time. If you were to rebuild the same
package at two different points in time with the same set of
dependencies, that would get you different file modification times.
Those would be recorded in data.tar and therefore the rebuilt .deb would
differ from the earlier one. This broke reproducible builds and is what
caused the addition of SOURCE_DATE_EPOCH. Now, dh-strip-nondeterminisim
clamps the modification time of installed files to SOURCE_DATE_EPOCH and
this aspect no longer causes issues to reproducible builds.

The modification time is just one of several aspects influenced by
SOURCE_DATE_EPOCH. Some tools also use it to derive the content of
files. It is these content differences that are relevant to the M-A:same
conflicts that caused me to start this mail thread.

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

There is no obligation for a binNMU to change any filenames. Indeed, it
may even produce the very same binary packages (up to version) as
before.

Helmut



From simon at josefsson.org  Thu Apr 16 10:02:33 2026
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 16 Apr 2026 11:02:33 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <20260416084328.GA336031@subdivi.de> (Helmut Grohne's message of
 "Thu, 16 Apr 2026 10:43:28 +0200")
References: <20260415094942.GA99313@subdivi.de> <875x5s2uag.fsf@josefsson.org>
 <20260415143419.GA216388@subdivi.de>
 <ad_gEw60JnbJftKx@mail.wookware.org> <ad_mNI29nRO2mHWn@vis>
 <87ldenmhw6.fsf@josefsson.org> <20260416084328.GA336031@subdivi.de>
Message-ID: <87cxzzmg5y.fsf@josefsson.org>

Helmut Grohne <helmut at subdivi.de> writes:

> Hi Simon,
>
> On Thu, Apr 16, 2026 at 10:25:13AM +0200, Simon Josefsson wrote:
>> 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?
>
> Yes, Ian's backup system compares a recorded modification time to the
> actual modification time and backs up the file unless they match
> exactly.
>
>> 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.
>
> That is what we did for a long time. If you were to rebuild the same
> package at two different points in time with the same set of
> dependencies, that would get you different file modification times.
> Those would be recorded in data.tar and therefore the rebuilt .deb would
> differ from the earlier one. This broke reproducible builds and is what
> caused the addition of SOURCE_DATE_EPOCH. Now, dh-strip-nondeterminisim
> clamps the modification time of installed files to SOURCE_DATE_EPOCH and
> this aspect no longer causes issues to reproducible builds.
>
> The modification time is just one of several aspects influenced by
> SOURCE_DATE_EPOCH. Some tools also use it to derive the content of
> files. It is these content differences that are relevant to the M-A:same
> conflicts that caused me to start this mail thread.

Thanks for (patiently) explaining for us lacking context!

That all sounds okay, except I don't follow why the final *.deb has to
have the SOURCE_DATE_EPOCH modtime too?

It was (and is) a good idea to clamp modtime of INSTALLED files so the
archive becomes identical.

But if a newly built *.deb file contains a modified
changelog.Debian.ARCH.gz file, it seems really strange for that *.deb
file to have a modtime value of an earlier (non-identical) package.

A better modtime for that *.deb seems to be the binNMU changelog
timestamp, for reproducability of the final archive including modtime.

What would break if you went back to setting SOURCE_DATE_EPOCH to the
last non-binNMU debian/changelog source timestamp entry AND set the
modtime of the resulting *.deb's to the timestamp of the binNMU
changelog timestamp?

/Simon

>> 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.
>
> There is no obligation for a binNMU to change any filenames. Indeed, it
> may even produce the very same binary packages (up to version) as
> before.
>
> Helmut
>
-------------- 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/841d51bf/attachment.sig>

From helmut at subdivi.de  Thu Apr 16 10:08:21 2026
From: helmut at subdivi.de (Helmut Grohne)
Date: Thu, 16 Apr 2026 11:08:21 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <87cxzzmg5y.fsf@josefsson.org>
References: <20260415094942.GA99313@subdivi.de> <875x5s2uag.fsf@josefsson.org>
 <20260415143419.GA216388@subdivi.de>
 <ad_gEw60JnbJftKx@mail.wookware.org> <ad_mNI29nRO2mHWn@vis>
 <87ldenmhw6.fsf@josefsson.org> <20260416084328.GA336031@subdivi.de>
 <87cxzzmg5y.fsf@josefsson.org>
Message-ID: <20260416090821.GA337732@subdivi.de>

Hi Simon,

On Thu, Apr 16, 2026 at 11:02:33AM +0200, Simon Josefsson wrote:
> That all sounds okay, except I don't follow why the final *.deb has to
> have the SOURCE_DATE_EPOCH modtime too?

The modification time we were talking about was the one of installed
files. I don't know whether the .deb's modification time is clamped nor
am I aware of any problems around its modification time.

> What would break if you went back to setting SOURCE_DATE_EPOCH to the
> last non-binNMU debian/changelog source timestamp entry AND set the
> modtime of the resulting *.deb's to the timestamp of the binNMU
> changelog timestamp?

Ian's backup system.

Installed files would be changing content while not changing their
modification time. The backup system would treat them as unchanged and
skip them. His backup is inconsistent as a result.

Helmut



From pkern at debian.org  Thu Apr 16 10:21:53 2026
From: pkern at debian.org (Philipp Kern)
Date: Thu, 16 Apr 2026 11:21:53 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <20260416084328.GA336031@subdivi.de>
References: <20260415094942.GA99313@subdivi.de> <875x5s2uag.fsf@josefsson.org>
 <20260415143419.GA216388@subdivi.de>
 <ad_gEw60JnbJftKx@mail.wookware.org>
 <ad_mNI29nRO2mHWn@vis> <87ldenmhw6.fsf@josefsson.org>
 <20260416084328.GA336031@subdivi.de>
Message-ID: <dbcde6eb-c4af-4d8f-bac4-7be6556f5027@debian.org>

On 4/16/26 10:43 AM, Helmut Grohne wrote:
> That is what we did for a long time. If you were to rebuild the same
> package at two different points in time with the same set of
> dependencies, that would get you different file modification times.
> Those would be recorded in data.tar and therefore the rebuilt .deb would
> differ from the earlier one. This broke reproducible builds and is what
> caused the addition of SOURCE_DATE_EPOCH. Now, dh-strip-nondeterminisim
> clamps the modification time of installed files to SOURCE_DATE_EPOCH and
> this aspect no longer causes issues to reproducible builds.

IIUC we are already doing a transformation of both packages before they 
are being compared, right? Out of curiosity: How much does it actually 
buy us to choose to care about the timestamps here?

Kind regards
Philipp Kern


From helmut at subdivi.de  Thu Apr 16 10:32:15 2026
From: helmut at subdivi.de (Helmut Grohne)
Date: Thu, 16 Apr 2026 11:32:15 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <dbcde6eb-c4af-4d8f-bac4-7be6556f5027@debian.org>
References: <20260415094942.GA99313@subdivi.de> <875x5s2uag.fsf@josefsson.org>
 <20260415143419.GA216388@subdivi.de>
 <ad_gEw60JnbJftKx@mail.wookware.org> <ad_mNI29nRO2mHWn@vis>
 <87ldenmhw6.fsf@josefsson.org> <20260416084328.GA336031@subdivi.de>
 <dbcde6eb-c4af-4d8f-bac4-7be6556f5027@debian.org>
Message-ID: <20260416093215.GA377213@subdivi.de>

Hi Philipp,

On Thu, Apr 16, 2026 at 11:21:53AM +0200, Philipp Kern wrote:
> IIUC we are already doing a transformation of both packages before they are
> being compared, right? Out of curiosity: How much does it actually buy us to
> choose to care about the timestamps here?

No. The point of reproducible builds is to fully reproduce the .deb file
in a rebuild up to every single bit. There is no transformation being
performed prior to comparison. diffoscope does dig into the .deb files
and tell you about the origin of differences, but that's a diagnostic
tool and it is not recommended to run diffoscope on untrusted input.

Thanks to the work of the reproducible builds folks we can reproduce
(i.e. rebuild and get the exact same .deb files) for more than 98% of
packages in forky. (See https://reproduce.debian.net/)

Dropping the timestamp clamping would instantly get us to 0%. As much as
I would like to fix coinstallability, that is not a sensible trade.

Helmut



From simon at josefsson.org  Thu Apr 16 17:28:31 2026
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 16 Apr 2026 18:28:31 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <20260416090821.GA337732@subdivi.de>
References: <20260415094942.GA99313@subdivi.de>
 <875x5s2uag.fsf@josefsson.org> <20260415143419.GA216388@subdivi.de>
 <ad_gEw60JnbJftKx@mail.wookware.org> <ad_mNI29nRO2mHWn@vis>
 <87ldenmhw6.fsf@josefsson.org> <20260416084328.GA336031@subdivi.de>
 <87cxzzmg5y.fsf@josefsson.org> <20260416090821.GA337732@subdivi.de>
Message-ID: <748501be445cad64211ac59f0dd13426f55b3fba.camel@josefsson.org>

Thanks for explaining -- I see the problem now (my backup system uses
modtime+size and could be affected by this too...), and my new
preference for solving this is to implement the 'binNMUs should be
replaced by easy "no-change-except-debian/changelog-uploads' idea from
the #894441 title, although I suspect there are objections to that. 
Anything involving BinNMU's seems complex and brittle, and the entire
concept seems problematic for many reasons to me.

/Simon

tor 2026-04-16 klockan 11:08 +0200 skrev Helmut Grohne:
> Hi Simon,
> 
> On Thu, Apr 16, 2026 at 11:02:33AM +0200, Simon Josefsson wrote:
> > That all sounds okay, except I don't follow why the final *.deb has
> > to
> > have the SOURCE_DATE_EPOCH modtime too?
> 
> The modification time we were talking about was the one of installed
> files. I don't know whether the .deb's modification time is clamped
> nor
> am I aware of any problems around its modification time.
> 
> > What would break if you went back to setting SOURCE_DATE_EPOCH to
> > the
> > last non-binNMU debian/changelog source timestamp entry AND set the
> > modtime of the resulting *.deb's to the timestamp of the binNMU
> > changelog timestamp?
> 
> Ian's backup system.
> 
> Installed files would be changing content while not changing their
> modification time. The backup system would treat them as unchanged
> and
> skip them. His backup is inconsistent as a result.
> 
> Helmut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1252 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260416/a7212598/attachment.sig>

From bthiel at kezhishuzi.com  Fri Apr 17 05:43:03 2026
From: bthiel at kezhishuzi.com (Melanie Dietrich)
Date: Fri, 17 Apr 2026 06:43:03 +0200
Subject: =?UTF-8?B?NDhWIDIwQWggZS1iaWtlIGZvciBkZWFsZXJzIGFuZCByZXNlbGxlcnMgLSA0OFYgMjBBaCBFLUJpa2UgZsO8ciBIw6RuZGxlciB1bmQgV2llZGVydmVya8OkdWZlcg==?=
Message-ID: <_3o1rIjLaims4laZ9q1EPNnyljxDWQ63eef@lilmissfitsdance.com>

full suspension bicycle from Germany stockKurze Info: Englisch steht zuerst, die deutsche Version folgt direkt danach.Dear Sir or Madam,

Please allow us to briefly introduce a 26 inch fat tire bicycle with full suspension.

The model is built with a 48V 20Ah battery and a 250W motor for the EU version.

It is designed for riders who want a more comfortable ride and a stronger product image in the shop.

The combination of full suspension and wide tires helps create a smoother feeling on broken roads, lighter trails, and everyday routes.

At the same time, the bicycle has the kind of stronger visual identity that many customers notice immediately when comparing different models in store.

This makes it a good addition for retailers who want a comfort-focused model with broader custo...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260417/5b3969db/attachment.htm>

From holger at layer-acht.org  Fri Apr 17 17:26:08 2026
From: holger at layer-acht.org (Holger Levsen)
Date: Fri, 17 Apr 2026 16:26:08 +0000
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <aeAR6y_2JXNko6ya@localhost>
References: <20260415094942.GA99313@subdivi.de> <875x5s2uag.fsf@josefsson.org>
 <20260415143419.GA216388@subdivi.de> <aeAR6y_2JXNko6ya@localhost>
Message-ID: <aeJfIEvl1gyWXOQ1@layer-acht.org>

On Thu, Apr 16, 2026 at 01:32:11AM +0300, Adrian Bunk wrote:
> AFAIR I already suggested somewhere in these discussions that the date 
> of a binNMU could be the date of the source upload plus the binNMU 
> number added in seconds (e.g. +b5 is 5 seconds after the source upload).

this seems like a rather simple solution for this problem which I believe
is much preferable to the quite complex solution Helmut proposed in the 
initial mail to this thread.

I still think we should replace binNMUs with proper sourceful uploads,
because having source packages which dont contain the full sources are
annoying & harmful, but... perfect is the enemy of good, so yay, progress!
(that's #894441: binNMUs should be replaced by easy "no-change-except-debian/changelog-uploads")


-- 
cheers,
	Holger

 ???????
 ???????  holger@(debian|reproducible-builds|layer-acht).org
 ???????  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ???

Bottled water companies don't produce water, they produce plastic bottles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260417/d8911ca9/attachment.sig>

From helmut at subdivi.de  Sun Apr 19 11:20:59 2026
From: helmut at subdivi.de (Helmut Grohne)
Date: Sun, 19 Apr 2026 12:20:59 +0200
Subject: Proposal for making Multi-Arch:same binNMU-safe
In-Reply-To: <aeJfIEvl1gyWXOQ1@layer-acht.org>
References: <20260415094942.GA99313@subdivi.de> <875x5s2uag.fsf@josefsson.org>
 <20260415143419.GA216388@subdivi.de> <aeAR6y_2JXNko6ya@localhost>
 <aeJfIEvl1gyWXOQ1@layer-acht.org>
Message-ID: <20260419102059.GA899191@subdivi.de>

Hello all,

On Fri, Apr 17, 2026 at 04:26:08PM +0000, Holger Levsen wrote:
> On Thu, Apr 16, 2026 at 01:32:11AM +0300, Adrian Bunk wrote:
> > AFAIR I already suggested somewhere in these discussions that the date 
> > of a binNMU could be the date of the source upload plus the binNMU 
> > number added in seconds (e.g. +b5 is 5 seconds after the source upload).
> 
> this seems like a rather simple solution for this problem which I believe
> is much preferable to the quite complex solution Helmut proposed in the 
> initial mail to this thread.

I would like to correct myself. In my previous reply to Adrian I agreed
that this would be simple, but pybuildd (or now buildd) as a component
does not have access to the relevant information (the last non-binNMU
timestamp). It gets the source package and the version. In principle it
could now download the package to extract that timestamp, but that would
require access to the apt configuration of the build environment.
Otherwise downloading the source package using the machine environment's
apt could easily fail. In addition to being error prone, downloading the
source package just for extracting a timestamp also is less than ideal
for resources.

Things would become quite a bit easier if sbuild were performing the
computation of said timestamp as it already has access to the source
package at the time it creates the binNMU changelog. I now imagine
expanding the way BIN_NMU_TIMESTAMP is interpreted by sbuild. Presently,
there is no sensible way to pass a value that starts with "+". I suggest
that BIN_NMU_TIMESTAMP="+<digits>" should be interpreted by sbuild as
adding that number of seconds to the last non-binNMU changelog's
timestamp. Is that a change sbuild maintainers would be comfortable
with?

Once doing so, the proposed change to pybuildd would become quite a bit
simpler:

https://salsa.debian.org/wb-team/pybuildd/-/blob/master/buildd.py?ref_type=heads#L291

@@ -291,6 +291,7 @@
         if pkg.binnmu and pkg.binnmu_changelog:
             cmd.append('--binNMU={}'.format(pkg.binnmu))
             cmd.append('--make-binNMU=' + pkg.binnmu_changelog)
+            cmd.append('--binNMU-timestamp=+{}'.format(pkg.binnmu))
         if pkg.extra_depends:
             cmd.append('--add-depends=' + pkg.extra_depends)
         if pkg.extra_conflicts:

I would also like to get feedback from Wanna Build maintainers (probably
Philipp Kern) as to whether this change (and the general scheme of using
deterministic binNMU timestamps) would be acceptable.

Helmut



