| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 28 |
| Nodes: | 6 (1 / 5) |
| Uptime: | 45:50:47 |
| Calls: | 422 |
| Calls today: | 1 |
| Files: | 1,024 |
| Messages: | 90,336 |
builder:work$ dgit -wn -pgit2cl --build-products-dir=3D../bpd --for-push fe= tch experimental
canonical suite name for experimental is rc-buggy
no version available from the archive
dgit: source package git2cl does not exist in suite experimental
# [new]
# package is new in this suite
builder:work$ git deborig b2866e9a66b43855a37e462d17a8ba1ca3c51d90
This URL is helpful
https://api.ftp-master.debian.org/file_in_archive/%25git2cl%5C_3.0.orig.tar.xz
15 maj 2025 kl. 20:27 skrev Ian Jackson <ijackson@chiark.greenend.org.uk>:
Ian Jackson writes ("Bug#1105766: [tag2upload 207] failed, git2cl 1:3.0-3 [and 1 more messages]"):
This URL is helpful
https://api.ftp-master.debian.org/file_in_archive/%25git2cl%5C_3.0.orig.tar.xz
I discovered something quite exciting:
$ curl -Ss 'https://api.ftp-master.debian.org/file_in_archive/%25/guile-fibers%5c_1.3.1.orig%25.tar.%25' | jq .
[
{
"filename": "g/guile-fibers/guile-fibers_1.3.1.orig.tar.xz",
"component": "main",
"sha256sum": "9384ce475cb9af6b20b80b36f21c0e6d847517e0b8e5648afb215d4ed6883160"
},
{
"filename": "g/guile-fibers/guile-fibers_1.3.1.orig.tar.gz",
"component": "main",
"sha256sum": "a5e1a9c49c0efe7ac6f355662041430d4b64e59baa538d2b8fb5ef7528d81dbf"
}
]
What should we do in this case? (Also, what if the orig tarball(s)
are supposed to exist, but cannot be obtained from the mirror?)
Options are:
* Don't provide any origs and hope everything works anyway.
Often it will simply fail since dgit's quilt fixup will want those
origs. In principle it might sometimes result in a REJECT, but not
very often I think because dgit push-source will bomb out.
But I think it may have a chance of working anyway.
* Fail right away.
* If some origs are available, somehow pick one (maybe via a
dsc_in_suite query). This seems complicated. And it won't arise
in a purely-git-based workflow where everyone is just using
git-deborig.
Ian.
--
Ian Jackson <ijackson@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.
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.
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.
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:
* 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.
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.
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.
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.
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.
Maybe some reproducible rebuilder folks could provide advice here, the orig.tar issue comes up often in that context too.