Control: tags -1 + moreinfo
Colin Watson writes ("Bug#994014: dgit push-source unnecessarily fails if gpg
updates its trustdb"):
> dgit: failed command: git verify-tag
> 7fc8242a8eaa1da7e442993b6a300b8da9f34d5f
Firstly, thanks for diligently filing a report.
> dgit: error: subprocess failed with error exit status 1
> ! Push failed, *after* signing the tag.
> ! If you want to try again, you should use a new version number.
>
> I'm not sure why "git verify-tag" apparently returned non-zero here, but
> the trustdb junk in the output is suspicious. Perhaps dgit ought to run
> gpg with the "--no-auto-check-trustdb" option to suppress this?
Possibly. I think it's more likely to be random flakiness in gnupg2.
In principle dgit might have assembled an incorrect git tag (it
doesn't use git-tag to make tags which is one reason it verifies
them). But it doesn't seem very likely. There are some obvious
possible stochastic failure modes involving random strings of variable
length, but if dgit has one of those it has a very low probability.
Was the tag in fact correct, DYK?
I already knew that git-verify-tag sometimes has poor error handling -
it can fail to say what it tried to do to verify the tag and what the
results were. I don't think that's helping.
If the trustdb theory is right, then it's a bug in gnupg or maybe the
way git-verify-tag calls it. But I doubt it's worth attempting to
constructing a repro based on that theory.
Under the circumstances (particular, gnupg2's past history of low
probability random lossage) I don't think this bug is worth any
followup unless we have a repro. This is vexing, because I want dgit
to be reliable.
Sorry.
In any case, I don't think this is at all likely to be a bug in dgit.
I'm going to tag this moreinfo. Feel free to leave it open, or close
it, as you like.
Thanks,
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.
