Hi, Quoting Ian Jackson (2015-10-10 18:07:02) > > 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.
whoops, that sentence indeed had a *not* too many. Yes, the package was in sid and my upload added two more binary packages, meaning it is now in binary-new. > > 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. As far as I remember, even source packages which generate debian/control from a debian/control.in must ship their generated debian/control. So it should be possible to use debian/control together with dpkg-genchanges to retrieve the list of binary packages. > So this would be tricky. (But how does the dak tell: does it process > debian/control?) I do not know either what dak does. Maybe it uses the Binary field of the .changes file which lists the binary packages of the uploaded source package even for a source-only upload? That field is also part of the .dsc. > 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. Is there a "not" missing above? dgit could compare the Binary field of the previous .dsc file with the one of the new .dsc file and check if there are any changes in its value. > 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. Sorry me neither. I just know that it was bothersome for me that I only noticed my error after the "dgit push" and then had no idea how to fix the problem because I cannot just rebuild and dput again as I'd otherwise do. > > 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. But they didn't reach the archive yet, so they've been deleted. Not even I could retrieve the stuff I uploaded from there anymore. > 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). Aha, so --deliberately-include-questionable-history is the knob I have to turn. That wasn't clear to me from the documentation before you told me to use it, and reading the documentation again it is still not clear to me how that option works, why it exists and how it fixes my problem. From the context I assume that this option lets me do a `dgit push` even though I already pushed that exact same version? If so, then maybe this should be mentioned in the description of the option? I was also wondering about why the mentioning of copyright and redistributability reasons is important there. I can think of many other reasons why there could be a REJECT after a dgit push including the one we talked about in #800060 which was REJECTED because of a hash sum mismatch. So is --deliberately-include-questionable-history indeed the right option I want to do a `dgit push` of a fixed .changes or .dsc file after a REJECTED upload (assuming I didn't change anything of the packaging but just did a rebuild with different options)? > 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. So what I ended up doing (which might've been totally wrong but in that case it'll serve as a funny experiment) was to do a rebuild of the package with `dgit sbuild`, then added a field Dgit to the .dsc file containing the git commit hash of my top commit, then adjusted the .changes file with the changed size and hashes of the .dsc, then used debsign to sign both and then dput-ed the .changes file. Clearly, the upload now ended up in binary-new but was doing this also okay from the dgit side? Thanks for all your help! cheers, josch
signature.asc
Description: signature
