Bug#966280: dpkg-source should ignore CRLF vs. LF differences
Guillem Jover <[email protected]> Sun, 7 Jun 2026 03:35:53 +0200
| Newsgroups | gmane.linux.debian.devel.dpkg.bugs |
|---|---|
| Message-ID | <aiTK-QHPlWOl5l2N__44549.0529805952$1780796248$gmane$org@thunder.hadrons.org> |
Hi! On Sat, 2020-07-25 at 22:42:02 +0200, Martin Quinson wrote: > Package: dpkg > Version: 1.19.7 > Severity: normal > when trying to build the new upstream version of Widelands with git- > buildpackage, I had an error message saying that some files were modified out > of the debian/ directory. It turns out that the difference is only about the > line endings: some files of the upstream tarball are encoded with CRLF while > most of them are LF only. > > When importing the files in the upstream branch of my git, the CRLF are > automatically converted to LF by git, but when dpkg-source compares the content > of the current dir (ie, the checkout) with the content of the tarball, it fails > with a rather uninformative error message: > > dpkg-source: info: local changes detected, the modified files are: > widelands-21/cmake/Modules/FindSDL2_image.cmake > widelands-21/cmake/Modules/FindSDL2_mixer.cmake > widelands-21/cmake/Modules/FindSDL2_ttf.cmake > widelands-21/data/maps/Twin_Lagoons_v2.wmf/elemental > widelands-21/src/third_party/eris/README.eris > dpkg-source: error: aborting due to unexpected upstream changes, see > /tmp/widelands_21-1.diff.YyKJqP > > My first glance at the diff was not enough to understand the pb, stupid me. > Instead it took me several hours to understand the issue. I repacked and > reimported my upstream tarball quite a few times before that. Then, I had to > manually repack the upstream archive after dos2unix'ing the relevant files to > fix it. > > I think that it'd be really better if dpkg-source would ignore those difference > in the first place. I'm not completely sure, but I think that this is what the > --strip-trailing-cr option of diff is meant for. I don't think using --strip-trailing-cr is safe, because (AFAICT) patch(1) would reject applying patches on different line endings, so this could accept diffs that then could not be applied. I guess we could add a message hint mentioning the potential issue of CRLF vs LF, but I'm not sure if that's too niche for such message to be shown always? Otherwise I think I'd close this. Thanks, Guillem