Re: gbp-buildpackage showing change outside debian/, possibly after DEP-14 conversion

[Bernhard Schmidt <berni@debian.org>]

Am 12.03.19 um 09:12 schrieb Ian Campbell:

Hi Ian,

thanks a lot for your feedback

>>> I have no idea where the line terminators difference in one single
>>> branch in one single file that is never used in Debian builds comes
>>> from. I don't think it's the pristine-tar data, when I remove the
>>> generated orig.tar.xz and have it regenerated with --git-no-pristine-tar
>>> it has a different md5sum (so pristine tar is apparently not used), but
>>> the file in the archive still has a different linefeed than the one in
>>> the git archive.
>>
>> There are various settings in git-config (either ~/.gitconfig,
>> .git/config) which can cause line endings to be modified in the working
>> tree, `core.{eol,safecrlf,autocrlf}` are the main ones I see in git-
>> config(1). You might have one of those in an unexpected location?
>>
>> I think that .gitattributes has similar controls, which might explain
>> it affecting only a single file.
> 
> Of course, I forgot I can check this myself...
> 
> Your bind9 repo has:
> 
>    bind9$ cat .gitattributes 
>    *.sln.in eol=crlf
>    *.vcxproj.in eol=crlf
>    *.vcxproj.filters.in eol=crlf
>    *.dsw eol=crlf
>    win32utils/**.txt eol=crlf
> 
> I suppose contrib/dlz/example/win32/dxdriver.dsw is the only file which
> doesn't already have crlf in the version stored in the repo, so it is
> the only one actually rewritten in the working copy...

Thanks for your feedback. I was looking at .gitattributes but thrown
off, because in debian/buster the file does not contain *.dsw. It was
changed in 9.11.6, which is in debian/master.

---
*.sln.in eol=crlf
*.vcxproj.in eol=crlf
*.vcxproj.filters.in eol=crlf
---

https://salsa.debian.org/dns-team/bind9/blob/debian/buster/.gitattributes
https://salsa.debian.org/dns-team/bind9/blob/debian/master/.gitattributes

I still don't get why it's only happening now, and only with export=WC,
as I'm not in that branch. Is it possible that the tarball generation
somehow looks at the .gitattributes from HEAD (debian/master) instead of
the current debian branch or upstream tag? The file dxdriver.dsw has not
been changed since 9.9.0a1 was imported 7 years ago.

Bernhard