Bug#1126665: dpkg-source: Incomplete feedback when creating a new source package and there are extra files

Guillem Jover <[email protected]> Thu, 5 Mar 2026 01:44:36 +0100
Newsgroups gmane.linux.debian.devel.dpkg.bugs
Message-ID <aajR9CBbGvqFtUxY__16936.9270255387$1772671651$gmane$org@thunder.hadrons.org>
Hi!

[ Sorry, have had this sitting open in an editor. ]

On Wed, 2027-02-04 at 15:07:37 +0100, Santiago Vila wrote:
> On Sat, Jan 31, 2026 at 01:56:49PM +0100, Guillem Jover wrote:
> 
> > dpkg-source: error: cannot represent change to po/sv.gmo: binary file contents changed
> > dpkg-source: error: add po/sv.gmo in debian/source/include-binaries if you want to store the modified binary in the debian tarball
> > dpkg-source: info: local changes detected, the modified files are:
> >  po/stamp-po
> > dpkg-source: error: unrepresentable changes to source
> > dpkg-buildpackage: error: dpkg-source -b . subprocess failed with exit status 1
> > `---
> > 
> > But I'm unsure, whether the info after the errors and then the final
> > error might be confusing, and might be worth some rewording somewhere.
> 
> Would it make sense to have such info to be really an error?

I think the problem is that whether this might be an error depends on
the caller of the function emitting this info, so I guess it might
require some annoying restructuring, or state passing. And then
making errors non-fatal to be able to track them and then emit an
overall error that represents them all or something along those lines.

> Or maybe the info has to be info according to some style document or
> design principle? If this is the case, then let the info continue to
> be info. As an end user I don't really mind, the goal of providing all
> the information is achieved either way.

In this case it is just an info, because it is not fatal for the
function emitting it.

Thanks,
Guillem