enabling architecture builds for a source package with a lower version than its binary packages

[Jeremy Bícha]

When renaming a source package, it might be desired to use a lower
version (or epoch) for the new source package than for the binaries
that were previously built by the old source package. wanna-build
struggles with this case and refuses to build for architectures other
than "all". One workaround is to build the binary packages yourself.

Debusine
========
If you can use debusine, it can build and upload binary packages for
many architectures.

dput -O debusine_workflow_data.upload_include_binaries=true -O
debusine_workflow_data.upload_include_source=false debusine.debian.net
hello_1.0-1_source.changes

Copying from https://wiki.debian.org/DebusineDebianNet

> Go to the URL printed after "Created workflow" (which will contain an
> actual workflow ID rather than the placeholder in the example above) to
> monitor the progress of your workflow (it doesn't auto-reload, so you
> have to manually reload the page from time to time).
>
> One of the "steps" is named "Wait for signature on upload for …". When
> that work request is marked as "Running", then you can decide to trigger
> the upload to Debian. If you are happy with the results of the QA
> checks, and want to upload the package to Debian, click on that "Wait
> for signature" work request and run the debusine provide-signature ...
> command shown there, after which Debusine will upload the package to
> Debian for you.
>
> If you are not happy with the results of the QA checks, you can cancel
> the upload workflow by clicking on the red "Abort work request" button
> on the top right, either on the workflow page or in the "Waiting for
> signature" work request page.

You'll need to provide the signature for every architecture except "all".

At the time I wrote this, that's amd64, arm64, armhf, i386, and ppc64el.

sbuild
======
For the remaining architectures, you'll need to build the binary
packages yourself. If you're using sbuild with the recommend unshare
backend as documented at https://wiki.debian.org/sbuild , it's
probably as easy as following the cross-compiling command there:

sbuild --host=s390x

debsign hello_1.0-1_s390x.changes
and then dput that changes file to Debian.

When I wrote this, the release architectures that were not handled by
Debusines are riscv64 and s390x so do this for both.

conclusion
==========
After all your binary uploads have been accepted, you should be able
to follow up with a source-only upload (with a new version number).

other notes
===========
This issue was also discussed in the uswsgi-plugins thread in February
https://lists.debian.org/debian-wb-team/2025/02/threads.html

In my case this week, I was doing it for meta-gnome which is replacing
meta-gnome3 and building the same binary package names. I removed the
epoch from the source package and used a dh_gencontrol override to
keep the epoch for the binary packages.

One suggestion in the February discussion was to simply ask ftpmasters
to remove the old source and binary packages from unstable. That's a
lot more disruptive for meta-gnome since it builds key packages.

experimental was not affected by this issue. My guess is that the
binary package names with newer versions from a different source
package were technically not published to experimental.

For my purposes, I only needed to be concerned with release
architectures. Once the old source package is removed from unstable, I
expect my new source package to automatically build binaries for ports
like loong64. The simple sbuild command I provided earlier didn't work
for loong64 because the build-essential source package is currently
only configured to build the crossbuild-essential packages for release
architectures.

Thank you,
Jeremy Bícha