Hi all
Line endings are CRLF in:
* python-bumps_1.0.5.orig.tar.gz in the Debian archive.
* the extracted source package for 1.0.5-1 (which Stuart presumably
made and uploaded with a traditional gbp and dput based workflow).
Yes, I was in the middle of getting a set of cooperating packages all
uploaded at the same time and so dputted the changes file I had from my
test build so that I could crack on with that work.
Line endings are newlines in
* upstream/1.0.5 tag, presumably generated by gbp import-orig.
(Stuart, can yhou confirm, and tell us the version?)
* salsa master branch and debian/1.0.5-1 tag.
Yes, upstream/1.0.5 was created by gbp import-orig --uscan,
git-buildpackage 0.9.38 from trixie was used. The tarball was downlaoded
from the upstream github release, meaning that it's a github-generated
tarball, meaning git-archive or something closely related is at work; I
know that file exclusion git-attributes apply to them but I'm not sure
about transformation ones). Looking at that tarball directly from
github, doc/make.bat has CRLF in it.
That means that the source data that was fed to gbp import-orig for this
file had CRLF in it; gbp import-orig has faithfully imported all the
files and git has transformed them back into LFs when importing them due
to the gitattributes but t2u has not undone that transformation? (Yes...
too many transformations.)
As for what is in the git repositories, I'm not sure how to answer that
question when git-attributions like this are active; at some sort of
philosophical level, I'm not sure that's a well posed question, given
that these transformations are intended not accidental.
FWIW though, I do not see those as newlines in a git checkout, so what
I'm seeing in front of me matches the tarball in the archive. I don't
see a contradiction in that.
$ git clone https://salsa.debian.org/science-team/python-bumps.git
$ cd python-bumps
$ file doc/make.bat
doc/make.bat: DOS batch file, ASCII text, with CRLF line terminators
So the source package, as built on the buildds, contains carriage
returns, but the working git branch, as the maintainers work with
locally, contains newlines! I think this is unintended and
undesirable. (Although, here, it's probably harmless.)
That's not what I'm seeing but maybe that's not what you're meaning. Is
it possible you have some local config in place that ignores or
overrides the .gitattributes in the repository? (I don't think I have
any config here that is relevant?). Or when you talk of the git repo on
salsa, is there something other than the 3 commands above you're looking
at to check?
(AFAICT actual upstream git is not being used here so isn't relevant,
but presuambly it has linefeeds. Four other files are affected too.)
Upstream git also has CRLF for that particular file when I clone (but
the .gitattributes ensure that).
Interestingly, when downloading this individual file from both the salsa
and github interfaces, the file I end up with is LF. I'm not sure what
to make of that little factoid in amongst the mess of attributes, but
thought it might be useful.
regards
Stuart
--
Stuart Prescott http://www.nanonanonano.net/ [email protected]
Debian Developer http://www.debian.org/ [email protected]
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
