Bug#1131881: want way to supporess dpkg-genchanges missing package warning

On Thu, 2026-03-26 at 13:00:08 +0000, Ian Jackson wrote:
> Guillem Jover writes ("Re: Bug#1131881: want way to supporess dpkg-genchanges missing package warning"):
> > Something that I think would be generic and I could see adding support
> > for, would be introducing the notion of source artifacts; perhaps along
> > the attached patch (including docs for it), which would add support for
> > source artifacts in the form of «<name>_<version>_source.<type>», which
> > in this case would then be «hippotat_1.3.2_source.git.tar.xz», although
> > thinking about this a bit, that also seems odd, as it would be letting
> > through whatever is there w/o any knowledge of what's going on, or any
> > validation (so in a sense it's a generic way to special case source
> > BYHAND artifacts, and make them not look like BYHAND which seems wrong);
> > perhaps alternatively either using "source" as section for the
> > debian/files BYHAND entry could be used to distinguish this, or a new
> > keyword could be added for debian/files entries to denote this is a
> > source BYHAND artifact (see deb-src-files(5)). I'll think about these,
> > but I'm tending now towards something along the two last options.
> 
> I'm afraid I don't quite follow all this.  My previous understanding
> of the notion of BYHAND was that it was something the archive software
> knew about.  I don't think it appears in .changes files so I'm not
> sure why dpkg-genchanges needs to know about it.  Evidently I am
> missing something.

Sorry if any of the following is obvious or previously known, just
going by what I understand might be missing.

A BYHAND artifact is one that is added to the "release" by
dpkg-distaddfile (internally to the debian/files for tracking), which
then gets recorded in the .changes file by dpkg-genchanges so that it
gets included in the upload by (dupload/dput/dput-ng). Otherwise if
the artifact would not be listed in the .changes file the upload tools
would not know this would even exist.

dpkg-genchanges applies sanity checks and filters over files to be
included depending on what kind of "release" this is (source-only,
binary, full, etc). These checks apply over the well-known patterns
that are expected for binary packages, and whether that matches known
entries in debian/control, etc.

So the main issue here is how to let dpkg-genchanges know that a
BYHAND artifact is source relevant (when currently all BYHAND
artifacts are assumed to be binary), be that via known and generic
filename patterns, or file properties (either via f.ex. the
dpkg-distaddfile section or a new keyword=value attribute).

> >  In this specific case this is _just_ about a warning (or a bunch of
> > them), most of them caused by the particular, idiosyncratic, or
> > uncoordinated assumptions on the use of these tools, where I don't
> > really see why whatever is currently driving the tools that end up
> > generating the warnings, could not filter them from its logging.
> 
> To be clear: you are suggesting that we would capture the stderr
> output of dpkg-genchanges and filter out messages that we know are
> expected.
> 
> We can certainly do that.

Right, sorry I guess this might not have been clear. Because if the
output ends up in a log, I assume there's at least something redirecting
it there.

> Normally filtering out messages by string matching doesn't work
> because of message translation, but here we're talking about a service
> which (for good reasons) always writes to its users in English.
> 
> But, of course, if the message text(s) changed, things would break -
> we'd have to update our filtering.

Yes, I considered that too, and I agree this is in general a non-ideal
pattern, but thought this was not too bad in this specific case at least
as an immediate solution, because as this is handled in a controlled
environment, then both localization does not play a big role here, and
service upgrades could deal with potential string changes (if that
happens) where this should only need attention every couple of years
(or so).

I don't think I agree that (all) the warnings listed in the blocked
report are incorrect, but for the ones that are, then this also gives
time to come up with ways to either make them not be emitted, or
depending on their generality to perhaps add scape-hatches or toggles
to disable them (if that even makes sense at all!).

Thanks,
Guillem