Hi!

On Mon, 2026-06-08 at 10:44:44 +0200, Martin Quinson wrote:
> Le dimanche 07 juin 2026 à 03:35 +0200, Guillem Jover a écrit :
> > On Sat, 2020-07-25 at 22:42:02 +0200, Martin Quinson wrote:
> > > 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.
> 
> 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.

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
diff --git i/scripts/Dpkg/Source/Package/V2.pm w/scripts/Dpkg/Source/Package/V2.pm
index 22f0c035e..990892300 100644
--- i/scripts/Dpkg/Source/Package/V2.pm
+++ w/scripts/Dpkg/Source/Package/V2.pm
@@ -632,6 +632,8 @@ sub do_build {
     unless (-z $tmpdiff or $self->{options}{auto_commit}) {
         hint(g_('make sure the version in debian/changelog matches ' .
                 'the unpacked source tree'));
+        hint(g_('if there are no obvious visible changes, ' .
+                'check for whitespace or line ending changes'));
         hint(g_('you can integrate the local changes with %s'),
              'dpkg-source --commit');
         error(g_('aborting due to unexpected upstream changes, see %s'),

Attachment: dctrl.tar.xz
Description: application/xz

Reply via email to