Hi, Quoting Nicholas D Steeves (2025-10-30 22:44:20) > I hadn't run sbuild directly in ages, and today I discovered that that it > still defaults to binary-only uploads! Of course this results in an > auto-reject. Yes, my mistake was carelessness and assuming that sbuild.conf > defaults had been updated to keep pace with ftpmasters policy from...what is > it now, five or six years? > > The question is probably: Should sbuild build source+bin, or just source.
if you want to build a source package, this is the tool you should use:
dpkg-source -b .
As a convenience for you, sbuild runs the above if you execute it inside an
unpacked source package directory. It needs to, because the source package is
the *input* to sbuild, not its output. If you want to build source packages,
then sbuild is the wrong tool for the job.
In your workflow, you want to use sbuild to build *binary* packages and verify
that your build works and creates usable artifacts. You do not want to use
sbuild to produce binaries for upload (except maybe in the rare situations
where you upload to NEW).
If you want to make sure that the binaries you built and tested are connected
to the source package you upload, you can use another convenience feature:
--source-only-changes tells sbuild to create a .changes file which includes the
source package that it used to build just now.
Here is a quote from the man page for --source:
> Build the source package in addition to the other requested build artifacts.
> By default, the dsc will not be rewritten because the source package is the
> input to sbuild, not its output. Even when running from an unpacked source
> tree sbuild will first build the source package using dpkg-source and then
> pass that on to the sbuild machinery. Use this option only when you know what
> you are doing. This will rewrite the original dsc passed to sbuild.
Do you think something should be added to the above to clear up the confusion?
Thanks!
cheers, josch
signature.asc
Description: signature
