Johannes Schauer writes ("Bug#801435: dgit: avoiding/fixing "Source-only
uploads to NEW are not allowed""):
> Package: dgit
> Version: 1.4
> Severity: wishlist
...
> after a "dgit push" of the package src:pdfrw I got a REJECT from
> ftpmaster because "Source-only uploads to NEW are not allowed". Since
> the source package is not yet in Debian I guess this talks about an
> upload to binary-NEW.
Looking at the ftpmaster db I think you misspoke. You said "the
source package is not yet in Debian" but in fact it appears that 0.1-3
is in sid.
> Here are two issues I have with this (close this bug as you see fit):
>
> 1. dgit is Debian specific so I guess it might be reasonable to assume
> that it encodes Debian specific rules like the above such that I can
> never do a "dgit push" of a source-only .changes file if there are
> new binary packages in the upload compared to the last
By definition a source-only upload doesn't involve dgit seeing the
binary packages. I'm not even sure that it is possible to determine
which binary packages ought to be produced without doing the actual
build. So this would be tricky. (But how does the dak tell: does it
process debian/control?)
Also it would be possible for dgit to see that the package is entirely
new (which I think it is in your case) and to know to reject a
source-only upload in that case.
dgit is not Debian-specific, but it does have the ability to apply
different rules to different archives. OTOH the more policy
information like this I encode in dgit, the more I have to track
ftpmaster's policy changes. I don't know if this ftpmaster rule is
likely to change.
> 2. I do not see documentation of how to fix this situation. Is the only
> way around to bump my Debian revision to -2, rebuild with binaries
> and then do "dgit push" again? Or is there a way to mangle my
> source-only .changes file file I already have such that it contains
> the new binary packages while at the same time doesn't break any of
> dgits expectations?
Ideally you should bump the revision, yes, because the old tag and
signed .dsc and .changes for the old package are out in the wild with
your signature on.
You will need to tell dgit --deliberately-include-questionable-history
because it doesn't know why the package was REJECTed and it wants to
be told that it's not because of copyright problems (in which case
ideally you would provide a differnet git history as well as a
different package).
In some circumstances you might need to say --dpkg-genchanges:-sa I
think, to tell dgit to tell dpkg-genchanges to include the original
source, or --dpkg-genchanges:-sd to tell dgit tell dpkg-genchanges not
to. I'm not 100% sure which the archive requires but given that 0.2-1
is in new I guess it can reuse the old .orig, in which case the
default should DTRT. Please let me know what you discover. TBH I
think dgit should figure this out for itself but I'm not sure of the
exact rules.
Ian.
