Hello,

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.

Thanks for the fish,
Mt

Hi!

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

Hello Guillem,

thanks for your answer, and thanks for maintaining dpkg.

Le dimanche 07 juin 2026 à 03:35 +0200, Guillem Jover a écrit :

The best solution would certainly to do an appropriate error message when this
niche case occurs. Maybe this issue should be reassigned to diff or whichever
program you use to compute the patch. That program should add a comment if/when
the only changes come from differing line endings. I don't have the
/tmp/widelands_21-1.diff.YyKJqP anymore, but it would have been really helpful
if it could contain a comment about this fact.

Thanks again for your time,
Mt

Hi!

I'm attaching the few files I used to play with this as tarball.

I don't think diff(1) could emit such messages by itself, unless
requested by an explicit option, because a legitimate change might be
wanting to fix one style of line ending to another. That would also
mean that we'd need to wait for an old enough diff(1) to be available to
be able to rely on it.

What I had in mind as a hint was something along the lines of the
attached patch. But then on a second thought it seems a bit unnecessary
as this can occur in many other instances where diffing files. And then
checking aa.diff with various editors, I see that several make this kind
of different clear, for example by representing the CR as ^M. From the
few editors I tested vim/nvim/nvi, and mceditor all made this visible.
Unfortunately nano didn't, but then I would not consider nano appropriate
for this kind of code inspection, and I'd go for hd(1) instead I guess.

As an additional example I've had the following in my .vimrc for a long
time (inspired by someone else) to make other kinds of invisible stuff
visible:

  if has("multi_byte")
    set listchars=tab:»‐,trail:·,extends:…,nbsp:‗
    set list
  endif

I guess my concern with adding this kind of hint output, is that I can
imagine potentially other such general situations (not specific to the
packaging context), and this might be opening the door for further hint
addition requests, which would make the output rather crowded (but perhaps
there are not many other such problems)? While it seems the better course
of action would be to use tools that better help with this kind of
situation instead?

So I think I have a slight preference for closing this with no further
changes, unless you think the additional text is really a good
trade-off between making this possibility explicit vs outputting
perhaps too much stuff on the common case.

Thanks,
Guillem

Hello,

I agree that your current patch is both the best thing I could imagine to fix
the issue, and a bit verbose in 99.99% of the cases, i.e. when there is no line
ending issue.

I would not be hurted if you close the bug as is. I would love to have a better
idea, but I have none. Please proceed.

Thanks for the time devoted to thinking about this,
Mt