Package: dgit-infrastructure
Version: 13.12
Simon Josefsson writes ("Re: [tag2upload 626] failed,
golang-github-kevinburke-ssh-config 1.3-1"):
> Help me understand why this one failed? Where is the
> 'e7d5f11fee84e75dbe27f04087a12442f76d87ff' commit identifier coming
> from? I can't find it on salsa.
Firstly, sorry about the poor UX here. That's #1111357.
The object you're refeerring to is synthesised by dgit on the
tag2upload service. You don't have it.
STEPS
To reproduce this failure locally:
Install dgit from testing
git clone
https://salsa.debian.org/go-team/packages/golang-github-kevinburke-ssh-config.git
-b debian/1.3-1
cd golang-github-kevinburke-ssh-config/
dgit download-unfetched-origs
# observe that it didn't find the orig, so:
git-deborig
dgit --quilt=gbp build-source
ACTUAL RESULTS
For me, that printed the very same message, with
e7d5f11fee84e75dbe27f04087a12442f76d87ff in it.
git-diff --stat then told me that the differeences are in
`testdata/dos-lines`. In git that file has Unix line endings.
There is a .gitattributes file that tries to make the file be checked
out with DOS line endings in the working tree.
I see that git-deborig made the .orig.tar.xz with DOS line endings,
honouring the .gitattributes.
EXPECTED RESULTS
tag2upload and dgit don't honour .gitattributes at all, because they
are (in general) neither stable nor reversible. So it's not possible
to honour them and also obey the the git==dsc principle.
But there is a bug in the tag2upload service here. It ought to have
disregarded the gitattributes when generating the tarball.
So, the .orig.tar.xz generated on the tag2upload service ought to have
a `testdata/dos-lines` with Unix line endings. Then the upload would
have succeeded. (Possibly some tests would then later fail?)
OPTIONS FOR SRC:DGIT
A.
1. Change git-deborig to not honour .gitattributes, by default.
B.
2. Have the tag2upload service run dgit setup-gitattributes; and
3. Change dgit setup-gitattributes to affect git-archive, too.
We might want to do 1 and 2 anyway.
OPTIONS FOR THIS PACKAGE
IMO this is a completly crazy thing for this package to have done in
git. It amounts to having git construct your test data out of other
git-stored artifacts during checkout.
Instead, the file should be committed, in git, with DOS line endings.
IDK if this came from upstream; that seems likely. It could be fixed
by a patch (upstream, or in quilt) which changes the line endings and
removes the entry in .gitattributes.
Ian.
--
Ian Jackson <[email protected]> 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.
