Hello,

On Sat 26 Jul 2025 at 03:56pm +02, Andrea Pappacoda wrote:

> 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?

Right, I see, thank you.

> 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 would suggest it should go in the section marked "Gather git history
information".

>> 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?

What I was thinking is that changing to use git(1) instead of
pristine-tar(1) is a logically distinct change from changing from a
check to embedding pristine-tar info in the tag.  So they should be
separate commits anyway, and we'd want to run the full test suite
against both of them.  While we are still discussing design you could
get the first change out of the way with a MR now.

> Thanks! Also, the code mixes tabs and spaces for indentation; looking at
> the diff here made me remember that. Not my fault!

Yeah, this is our inconsistent use of Emacs, sorry about that.
Just don't worry about it.

> 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?

Do you mean whether dak does any verification?  I don't know.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature

Reply via email to