Ian Jackson <[email protected]> writes: > This skew *is* undesirable so we try to minimise it. Sadly I don't > think there is a reasonable way for git-debpush to detect this > particular situation, without having it query the archive API, which > we don't want it to do because it's supposed to be a pure git tool. > > (I would be open to reconsidering this principle TBH. A call to the > ftpmaster API service wouldn't be a lot of code nor a lot of data > transfer, and it would jsut be part of the checks, not entangled with > the tag creation functionality.)
FWIW, as a user I would prefer if you stay out of using ftpmaster API service, because I think dgit has a good place in a future git-oriented Debian but the ftpmaster APIs less so. >> I upload my amd64 build at the same time as I do the git-debpush, and >> since gbp defaults to *.gz and tag2upload defaults to *.xz there is no >> filename clash in the upload, so my amd64 upload "wins" and the >> source-only upload gets discarded eventually. > > Why did you make these two uploads at the same time? You explain what > you did but not whether you did it deliberately :-). > > Our recommendation for NEW is to use dgit. "dgit push-built", > specifically. This fits roughly ito the same space as git-debpush, > except that of course you have to build binaries. "dgit sbuild" and > "dgit pbuilder" will do that for you. Presumably you have a suitable > chroot setup. Oh. My goal was to get the package source code into dgit (to make it possible to build packages directly from dgit), and pushing a signed tag to Salsa does that easily for me. I went from gbp-build-package+debsign+dput directly to tag2upload, so I never integrated dgit into my workflow. I have more NEW uploads coming up, so I will try to use 'dgit push-built' next time, I don't recall if I ever got dgit to build packages for me. >> 2) This package was ACCEPTED by ftp-masters into the archive, and BEFORE >> the orig.tar file appeared on deb.debian.org etc I did a source-only -2 >> upload of the package. That failed below, and I was somewhat ready for >> this to fail, because I wanted to see how things behaved in this >> situation. > > I think if we did what Sean suggests in this bug report, this would > work (at least, almost all of the time) - because t2u would be able to > reproduce the gbp-generated .orig.tar.gz. Without parsing gbp-related files, which I think you want to avoid? That would be nice. >> Re 1) I have used this a couple of times now. It leads to things not in >> the archive showing up on browse.dgit.debian.org. > > Was this package wholly-NEW, or only NEW due to new binary packages? Wholly NEW. > The system is supposed to hide wholly-NEW packages from the public git > view on browse.dgit.d.o and git.dgit.d.o until they are ACCEPTed. > If that isn't working it needs fixing. I didn't actually check but merely assumed that it automatically appeared on browse.dgit.d.o. I have several NEW uploads coming, I can try to use the same method again and report back. Nothing beats throwing things at live systems. /Simon
signature.asc
Description: PGP signature
