Simon Josefsson writes ("Re: Bug#1105766: [tag2upload 207] failed, git2cl
1:3.0-3 [and 1 more messages]"):
> Another reflection: I'm not sure that API call is the best way to figure
> out which orig.tar's are relevant. The canonical source for this is the
> *.changes file for the particular suite, isn't it? Or secondary, the
> information in the Sources file on mirrors. So the logic could be
> something like:
The .dsc file I think you mean. .changes files are not readily
accessible. (I'm not sure they're accessible at all.)
> * For an upload of package X version (E:)Y-Z into suite S where Y is
> upstream version and E/Z is the Debian version, try to lookup package
> X upstream version Y from Sources on mirrors in suite S, or some
> internal API accessing *.changes files (which could be faster than
> relying on mirror pulses) and filter for suite S.
We are definitely limited by the ftpmaster APIs available. I don't
think anything involving Sources is tolerable here[1]. But happily:
We can easily look up the version of X in S (Es:Ys-Zs) and get its
.dsc. That will get tell us what origs X_Y.orig*.* belong to
Es:Ys-Zs. If E:Y == Es:Ys (the upstream version we are trying to
upload is the same as the one in S) this will find us the existing
origs.
E:Y < Es:Ys is excluded because uploads must be newer than the current
contents of the suite. Likewise E:Y > Es:Ys means that this upstream
version is new in this suite, so definitely no useful orig is in S.
So that's in fact what is currently implemented, via the additional
`dgit fetch` that t2u runs before thinking about git-deborig.
The part that is missing is the situation where there are origs in
other suites.
> The API you mention doesn't make any guarantee that you get the right
> *.orig* from a particular suite, does it? So it may return unrelated
> *.orig* files for some other suite, causing some confusion.
So, only if the target suite doesn't have it.
That situation is what this bug is about.
Simon Josefsson writes ("Bug#1105766: [tag2upload 207] failed, git2cl 1:3.0-3
[and 1 more messages]"):
> 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.
This is this same bug.
> 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.
tag2upload cannot convey a tarball, so for a new upstream version, you
must put up with it generating an orig using use git-archive via
git-deborig. The onoy way to do that would be pristine-tar. See my
other comments about that.
For an existing upstream version t2u should reuse existing origs.
That's what this bug is about.
Are you a user of pristine-tar ?
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
