Hi Sean, On Sat Jul 26, 2025 at 3:31 PM CEST, Sean Whitton wrote:
I think it would be helpful to work on the spec in tag2upload(5) before continuing too much with code. It'll make it easier to keep the three of us on the same page.
Ok :) Documentation work has arrived earlier than I had anticipated...
- The pristine-tar checking code is now only run if this is a non-native package (i.e., "if $upstream"). - The upstream version is used instead of the Debian-revised one.ITYM your new code, right? The old check already had both these properties.
Yes. I copied them from the old check :)
- [..] the t2u service can potentially handle the case where a pristine-tar upload was intended, but no orig is available in the archive yet. Please let me know if this makes sense or not!It might make sense, I'm not sure yet. Can you describe a concrete example that would lead to this being helpful?
This is meant as a way to handle the potential issue described by Ian in <[email protected]>. Unless I have misunderstood the issue, of course!
If one does a -2 upload and the archive does not have the orig yet, and t2u has a reference to the pristine-tar branch, it can (safely?) re-create the tarball as it would be bit-by-bit identical to the already uploaded one. Does it make sense?
diff --git a/git-debpush b/git-debpush index e3a4ba39..78e42fb9 100755 --- a/git-debpush +++ b/git-debpush @@ -457,6 +457,30 @@ if $upstream; then to_push+=("$upstream_tag") fi +# I obtain the commit ID at the time of the upload, so that I can be sure that +# the tag2upload service generates the tarball with the expected pristine-tar +# branch state +pristine_tar_info='' +if $upstream; then + uversion="${version%-*}" + + if pristine_tar_commit=$(git rev-parse --verify --quiet 'refs/heads/pristine-tar'); then + pristine_tar_tarballs=$(git ls-tree -z --name-only -- 'refs/heads/pristine-tar' \ + | grep -zF -- "${source}_${uversion}.orig.tar." \ + | grep -zc -- "\.id$") + + if [ "$pristine_tar_tarballs" -gt 1 ]; then + fail 'more then one pristine-tar orig' + fi + + # If there's no tarball, the user probably stopped using pristine-tar a + # while ago, but didn't delete the branch. Just ignore it. + if [ "$pristine_tar_tarballs" -eq 1 ]; then + pristine_tar_info=" pristine-tar=$pristine_tar_commit" + fi + fi +fi + #**** Useful sanity checks ****Can you explain why you've put this in at this point in the script? I think that maybe it should go later, after all the sanity checks.
No, I cannot explain that :)There's really no reason why really, I just tried to put everything pristine-tar related in the same place. Thinking about it, these checks can only go before obtaining the pristine_tar_info, because I cannot reasonably get the pristine-tar info before first making sure there's just one orig.
I take it you switched from invoking pristine-tar itself to calling git-ls-tree in order to use NUL termination? If so, maybe we should make that change first to the existing check. Perhaps you could prepare an MR to that effect.
Kind of. I first wrote the checks in tag2upload-obtain-origs using plain shell and git, and then simply copied them back here. This was before looking at the existing pristine-tar check. But yes, pristine-tar does not use nul termination.
You mean I should write a separate patch for the check and submit it independently from this patch? I'd like to finish this patch in a reasonable time, so maybe it doesn't make sense to fixup a local check which is going to be removed soon anyway?
@@ -2031,6 +2033,9 @@ END "s=$suite", "u=$t2u_upstreamc", ); + if (length $t2u_pristine_tar) { + push(@obtain_origs, "pristine_tar=$t2u_pristine_tar") + }Generally we avoid parentheses on builtin operators and use poetry style, so push @obtain_origs, "pristine_tar=$t2u_pristine_tar" if $t2u_pristine_tar;
Thanks! Also, the code mixes tabs and spaces for indentation; looking at the diff here made me remember that. Not my fault!
+# TODO: what about signature files?Do you think we could extract them and include them in the upload?I think we can verify them by using the upstream key embedded in the source package, right? And if that verification fails we should probably abort the upload -- maintainers who choose to use tarball signatures had better make sure they verify.
Yes, that'd be the correct thing to do. What I wasn't sure about is whether t2u should just checkout the signature and upload it to the archive, verify it as well, or not do anything at all. In other words: do we have to do verification here, or does it happen after sending everything to the archive with dput? In that case, would it make sense to duplicate the verification?
Thanks for the review, Sean!
signature.asc
Description: PGP signature
