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
