Since dgit(1) states:

  Options and arguments after sbuild will be passed on to sbuild.

and sbuild(1) describes a `--force-orig-source` option, it seems reasonable to
assume that:

  dgit sbuild --force-orig-source

would result in the orig source being included in the changes, but it does not.

BTW There is a workaround for this:

  dgit --ch:-sa sbuild

In case you're wondering why I want to do this, it is because I'm building
openqa for upload to debian-fasttrack, which has no buildd, so one needs to
build the binary package oneself, and I've generally already uploaded the
package to unstable before I add the ~fto13-1 version, so it looks like the orig
source would have already been uploaded, but not to fasttrack, hence the need to
force it.

Hello,

Thanks.  The build wrapper commands probably have other behaviours which
only make sense in the context of uploading to Debian.

We could special-case --force-orig-source easily enough, but ideally we
would come up with some overarching mode for building for something like
fasttrack.  Wanting to use 'dgit sbuild' to build binaries for uploading
there, in order to ensure the binary packages match up to Git, seems
like a legitimate use case.

Sean Whitton <spwhitton@spwhitton.name> writes:

My use case is probably a bit odd, even for fasttrack, because I have
used a profile and some conditionals in debian/rules to ensure that
builds for normal debian suites (unstable,backports,stable) exclude the
openqa package (the one that contains the fast-moving WebUI) so that the
openqa-client and openqa-worker packages will end up in stable, but the
webUI will not.

That means that I upload basically the same version to unstable,
stable-backports and stable-fasttrack (apart from trivial changelog
changes).

I'd guess that most fasttrack uploaders are treating fasttrack as their
only target for that package's uploads, so they would presumably get the
orig source included automatically, based on the way the versions change
in their changelog.

Perhaps I should ensure that there's no mention of the unstable upload
in the changelog that's used in the fasttrack branch in order to get
that behaviour, but I was thinking that interleaving the different
changelog entries should make what's going on much clearer to people
that wonder about it.

Cheers, Phil.

Sean Whitton writes ("Bug#1121818: dgit sbuild fails to honour --force-orig-source"):
parse sbuild's options.  But you can't reliable parse another
program's options because you don't know which arguments are option
values.

In the absence of proper support in dgit, I think --ch:--sa is the
right way to achieve Phil's goal.

Maybe we could write something in the docs?

Philip Hands writes ("Bug#1121818: dgit sbuild fails to honour --force-orig-source"):

I think this is a fine way to carry on.

Back to Sean:

I think it would be best if we could get rid of these build wrappers
entirely.  Avenues to explore:

Currently `dgit push-built` expects to find a built .dsc, along
with binaries.  It *checks* the .dsc and amends it to add the
Dgit:, but it doesn't rebuild it.

The reason we can't just use a .dsc built directly with an unwrapped
sbuild is the .gitignore handling bug in dpkg-source, #908747
(knowledge of which is probably now embedded in in gbp etc.etc.).

If dgit push-built (re)built the source package, then the binary build
(the first of the user's two commands) wouldn't need to build one for
dgit's benefit.  And if it did we could ignore it, or check that the
only discrepancy was in .gitignore.

This does increase the risk that the binaries aren't what gets
uploaded, especialy if dgit push-built doesn't demand that the binary
build did include a source package and check that everything is good
except for .gitignore.

Related, of course, is #868527 which is asking for sbuilt to be able
to build binaries without making a source package at all.

Ian.

Also, stepping back a bit:

Philip Hands writes ("Bug#1121818: dgit sbuild fails to honour --force-orig-source"):

wtf!  This is extremely alarming.

Ian.

Hello,

Well, sbuild is documented to have only one positional argument, so I
think it would be okay in this case.

Certainly it would be better to get rid of them.  It's just that it's
probably a very long way off.  But perhaps not so far off that it is
worth something complex to fix this bug, indeed.

Sean Whitton writes ("Re: Bug#1121818: dgit sbuild fails to honour --force-orig-source [and 1 more messages]"):
    $ sbuild -c --force-ignore-source
    ...
    E: --force-ignore-source: Chroot not found
More realistically, say:
    sbuild --debbuildopts --force-ignore-source

I'm surprised that you're not aware of this problem, which generally
exists whenever you try to manipulate the arguments of another,
nonconsenting, program.

This is an instance of the ubiquitous quoting/unquoting problem, which
plagues computing systems so much.

Every program's command line is its own language, which is parssed by
its argument parser.  This is workable because generally one is trying
to quote a known meaning into a set of arguments, and knowledge of the
meaning involves knowledge of how *that meaning* is represented.

To *modify* a set of arguments, in the general case, is not sound,
because you don't know the "lexical" structure.  It's the same
fundamental error as trying to edit arbitrary HTML with regexps.

Right.

Ian.

Hello,

I see what you mean.  I suppose I would have figured this out had I
tried to implement it :)