Hi! ... > - tag2upload will improve the situation with .orig.tar because the > tag2upload server will always ensure that the uploaded source package > is prepared using an .orig.tar that dak will be happy with. > It won't matter what you're using locally for, e.g., the purpose of > feeding sbuild. > > So, teams and individual maintainers that switch over to tag2upload > will be able to forget about a lot of this stuff.
As you know I have been testing dgit and reviewing tag2upload, and to my understanding tag2upload will generate the *.orig.tar.gz tarballs using dgit which does only uses the debian/latest branch (in DEP14 terminology) and not at all the upstream/latest nor pristine-tar branches. As pristine-tar is not used, none of the upstream tarball signatures will be used either. The phrasing you used in "using an .orig.tar that dak will be happy with" conveniently hides the details about what the disagreement with ftp-masters was. Also the GR at https://www.debian.org/vote/2024/vote_002 was posted totally void of any details of what the disagreement was. Would you mind sheding some light into this? I am all for modern workflows and I would love to be able to run "gbp tag && gbp push" or equivalent to trigger tag2upload automation, but perhaps not at the cost at decreasing the supply chaing security from the point we have now? Or maybe I misunderstood still, happy to read more about it.
