Hi Sean and Ian, On Sat, Oct 11, 2025 at 03:36:37PM +0100, Sean Whitton wrote: > On Sat 11 Oct 2025 at 01:09pm +01, Andrew Bower wrote: [...] > > Running 'git deborig' I obtained a different tarball from what 'git debpush' > > had previously caused to be generated by the tag2upload builder. > > > > It would be nice to make sure that an out-of-the-box local invocation > > produced > > bit-exact tarballs to what tag2upload produces to reduce the barriers to > > understand and accept this type of workflow. [...] > tag2upload doesn't invoke git-deborig in any special way, so this > difference can only be due to version skew between tar and/or xz-utils > on the tag2upload Builder and your machine.
Understood. So presumably likely to resolve itself (eventually) in the course of upgrades. > I don't think there is much we can do other than preserve information > about the versions of the software involved, which we already do in the > .buildinfo file included with the upload. On Sat, Oct 11, 2025 at 04:46:41PM +0100, Ian Jackson wrote: > I think the real question for me is why we mind that the .origs aren't > bitwise identical. I sgree that it's better if they are, but maybe we > can arrange that it doesn't matter. > > Andrew, in this bug you report that these tarbalsl aren't identical. > Sean thinks that's difficult to prevent, but we may yet think of a > way. > > What problems do you anticipate from the discrpeancy? The two > generated tarballs have identical contents and are functionally > equivalent. Technically, I agree that this doesn't matter. My interest arises from the social angle - a couple of examples: pristine-tar branches are so widespread that some people get confused by their absence. If local tools produce the same as a download from the archive (from an earlier tag2upload) that reduces friction in these cases. the UDD maintainer dashboard now has an 'orig-check' that shows 'ok-ish' when tarballs differ only before normalisation. It still shows up as a positive result but it seems to penalise packages whose upstreams have been through tag2upload. This is unquestionably a trivial report - please feel free to close this bug! I only raised it as a possible barrier to adoption. One thing on my mind is that contributors are reliant on sponsors being familiar with their preferred workflow and that this might channel contributors away from trying workflows that might be a better fit for us. Thanks, Andrew
