Yeah, some more thinking would be good. Another data point: https://packages.debian.org/source/unstable/libntlm https://packages.debian.org/source/experimental/libntlm
That is, instead of re-using the libntlm_1.8.orig.tar.gz (which is identical to upstream's official tarball and carefully constructed to be bit-by-bit reproducible from the git repository using git-archive) and libntlm_1.8.orig.gz.asc, tag2upload created a different libntlm_1.8.orig.tar.xz and lost the GPG signature. I think I'm in a minority that cares about these things, and think that a lot of people have given up on preserving identical tarballs and retaining GPG signatures. So fixing this may not be a big priority. But if you can make this work, it would be nice. I'm also not certain that there is any guarantee that an upload to experimental has to use the same source tarball as an earlier upload to unstable, for the same upstream version. It may be conceivable that the reason for the upload to experimental is to get another tarball into the archive, because there were some problem with the sid orig.tar. But maybe this is mostly a theoretical concern, and using tag2upload may not be relevant for this situation. /Simon Ian Jackson <[email protected]> writes: > Simon Josefsson writes ("Bug#1105766: [tag2upload 207] failed, git2cl 1:3.0-3 > [and 1 more messages]"): >> Nice example! It is just different in Sid vs experimental, I’m not sure >> there is any rule against this situation? But it is sub-optimal. I’m not >> sure other tools doesn’t have this issue too. > > I think tag2upload created this situation. (It's not a very > desirable one.) > > The t2u service ought to have found the existing .orig and reused it, > when it processed your upload to experimental. Instead, it didn't > find it, and then it made a new .orig.tar.xz with git-deborig and > uploaded that. > > I think the possibility that this situation can arise means I will > have to implement the a complicated algorithm for orig finding. > Something like this: > > * Retain the existing dgit fetch. We need the output of this anyway > because dgit push-source uses it. Doing it separately at the > beginning only costs a 2nd ftpmaster API query dsc_in_suite and a > 2nd no-op git fetch. > > In a normal NMU targeting the same suite this should always work, > unless maybe the current thing in sid is very new. > > * If we don't now have any origs, look to discover existing origs > with a file_in_archive query. Hopefully we find precisely one > .orig.tar.* and possibly some .orig_foo.tar.* (only one of each). > > * Thus having determined by API calls what origs we want, we attempt > to obtain them. If this does not work I think we must fail. > > * If we don't discover any matching origs then we know we need to > make a new orig and use git-deborig, using the upstream= from the > tag. > > * If we discovered some matching origs but there were stems for which > there were several files with the same stem, we don't know which to > choose. I don't see anything other to do but fail in this case. > > I will think about this some more and maybe implement it tomorrow. > > Ian.
signature.asc
Description: PGP signature
