Bug#801435: dgit: avoiding/fixing "Source-only uploads to NEW are not allowed"
Control: retitle -1 Want to spot "entirely NEW source-only upload to Debian" As I wrote in my initial response: > 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?) But: > [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. I think this is the only really actionable work item in this bug report. Retitling it accordingly. Thanks, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#801435: dgit: avoiding/fixing "Source-only uploads to NEW are not allowed"
Johannes Schauer writes ("Bug#801435: dgit: avoiding/fixing "Source-only
uploads to NEW are not allowed""):
> What do I do after I did `dgit push` and got a reject because binary-NEW
> doesn't allow source-only uploads?
Bump the package version.
Ian.
Bug#801435: dgit: avoiding/fixing "Source-only uploads to NEW are not allowed"
Hi,
Quoting Ian Jackson (2015-10-26 12:39:17)
> Johannes Schauer writes ("Bug#801435: dgit: avoiding/fixing "Source-only
> uploads to NEW are not allowed""):
> > So I tried using --deliberately-include-questionable-history when doing
> > `dgit
> > push` but this just results in:
>
> I think I must have confused myself and you when I wrote my earlier
> advice.
>
> In Debian
> dgit push --deliberately-include-questionable-history
> is applicable only for a completely-NEW source package.
okay, I see.
What do I do after I did `dgit push` and got a reject because binary-NEW
doesn't allow source-only uploads?
Thanks!
cheers, josch
signature.asc
Description: signature
Bug#801435: dgit: avoiding/fixing "Source-only uploads to NEW are not allowed"
Johannes Schauer writes ("Bug#801435: dgit: avoiding/fixing "Source-only
uploads to NEW are not allowed""):
> So I tried using --deliberately-include-questionable-history when doing `dgit
> push` but this just results in:
I think I must have confused myself and you when I wrote my earlier
advice.
In Debian
dgit push --deliberately-include-questionable-history
is applicable only for a completely-NEW source package.
Ian.
Bug#801435: dgit: avoiding/fixing "Source-only uploads to NEW are not allowed"
Hi, Quoting Johannes Schauer (2015-10-10 20:34:40) > Quoting Ian Jackson (2015-10-10 18:07:02) > > 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)? I just so happened to have made the same mistake and used `dgit push` with a source-only .changes file even though the values of the Binaries field of the .changes and .dsc changed compared to the last version. Thus I got, again, a reject. So I tried using --deliberately-include-questionable-history when doing `dgit push` but this just results in: josch@hoothoot> dgit push --deliberately-include-questionable-history canonical suite name for unstable is sid downloading http://ftp.debian.org/debian//pool/main/f/fuzzylite/fuzzylite_5.1+dfsg-1.dsc... last upload to archive has NO git hash % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 1221k 100 1221k0 0 2038k 0 --:--:-- --:--:-- --:--:-- 2042k % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 12364 100 123640 0 105k 0 --:--:-- --:--:-- --:--:-- 106k dpkg-source: info: extracting fuzzylite in fuzzylite-5.1+dfsg dpkg-source: info: unpacking fuzzylite_5.1+dfsg.orig.tar.xz dpkg-source: info: unpacking fuzzylite_5.1+dfsg-1.debian.tar.xz dpkg-source: info: applying pkgconfig_installdir Format `3.0 (quilt)', checking/updating patch stack Format `3.0 (quilt)', checking/updating patch stack synthesised git commit from .dsc 5.1+dfsg-1 HEAD is now at f327338 release 5.1+dfsg-2 Version actually in archive:5.1+dfsg-1 (older) Last allegedly pushed/uploaded: 5.1+dfsg-2 (newer or same) Perhaps the upload is stuck in incoming. Using the version from git. Format `3.0 (quilt)', checking/updating patch stack nothing quilty to commit, ok. checking that fuzzylite_5.1+dfsg-2.dsc corresponds to HEAD dpkg-source: warning: extracting unsigned source package (../../../../fuzzylite_5.1+dfsg-2.dsc) dpkg-source: info: extracting fuzzylite in fuzzylite-5.1+dfsg dpkg-source: info: unpacking fuzzylite_5.1+dfsg.orig.tar.xz dpkg-source: info: unpacking fuzzylite_5.1+dfsg-2.debian.tar.xz dpkg-source: info: applying pkgconfig_installdir Format `3.0 (quilt)', checking/updating patch stack Format `3.0 (quilt)', checking/updating patch stack You need a passphrase to unlock the secret key for user: "Johannes Schauer " 4096-bit RSA key, ID 8FBD83E1, created 2013-07-04 (main key ID CF4D3EB4) gpg: Signature made Mon 26 Oct 2015 11:07:58 AM CET using RSA key ID 8FBD83E1 gpg: Good signature from "Johannes Schauer " gpg: aka "Johannes Schauer " gpg: aka "Johannes Schauer " To git+ssh://d...@push.dgit.debian.org/dgit/debian/repos/fuzzylite.git ! [rejected]debian/5.1+dfsg-2 -> debian/5.1+dfsg-2 (already exists) error: failed to push some refs to 'git+ssh://d...@push.dgit.debian.org/dgit/debian/repos/fuzzylite.git' hint: Updates were rejected because the tag already exists in the remote. dgit: failed command: git push 'git+ssh://d...@push.dgit.debian.org/dgit/debian/repos/fuzzylite.git' HEAD:refs/dgit/sid 'refs/tags/debian/5.1+dfsg-2' dgit: subprocess failed
Bug#801435: dgit: avoiding/fixing "Source-only uploads to NEW are not allowed"
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
Bug#801435: dgit: avoiding/fixing "Source-only uploads to NEW are not allowed"
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.
Bug#801435: dgit: avoiding/fixing "Source-only uploads to NEW are not allowed"
Package: dgit Version: 1.4 Severity: wishlist Hi, 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. 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 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? Thanks! cheers, josch -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dgit depends on: ii ca-certificates20150426 ii coreutils 8.23-4 ii curl 7.44.0-1 ii devscripts 2.15.8 ii dpkg-dev 1.18.3 ii dput 0.9.6.4 ii git [git-core] 1:2.5.1-1 ii libdpkg-perl 1.18.3 ii libjson-perl 2.90-1 ii libwww-perl6.13-1 ii perl [libdigest-sha-perl] 5.20.2-6 Versions of packages dgit recommends: ii openssh-client [ssh-client] 1:6.9p1-1 Versions of packages dgit suggests: ii sbuild 0.66.0-2 -- no debconf information
