Thanks for working on this -- I'm happy to test things once later. When I read your logic, I am a bit worried that things will break for multiple archives. And users normally have two archives: debian and debian-security. I'm not sure some of your versioning assumptions really hold cross-archives. Is this in scope? I suspect debian- security won't implement tag2upload tomorrow though, so maybe multiple archives can be deferred. And I recall debian-security do their own source-full uploads too, and don't want orig.tar reuse. I'm not sure of debian-backports or debian-proposed(-updates) though.
Maybe some reproducible rebuilder folks could provide advice here, the
orig.tar issue comes up often in that context too.
Re pristine-tar, couldn't tag2upload also support that? However there
is no current practice to tag pristine-tar commits, so you'll need to
introduce some new logic here (or demand signed commits?). And get
adoption of that.
I use pristine-tar and used to be a big supporter of it, but there was
a thread on that on debian-devel that some time ago where I couldn't
even convince myself that pristine-tar solves any significant problem.
Both guile-fibers and libntlm uses pristine-tar though, and I created
guile-fibers from scratch relatively recently so I guess old habits die
slowly. If tag2upload would support pristine-tar, maybe that is a more
reliable way forward, but I think you'll need the logic below anyway as
a fallback.
/Simon
fre 2025-05-16 klockan 11:41 +0100 skrev Ian Jackson:
> 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.
>
signature.asc
Description: This is a digitally signed message part
