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

Guillem Jover writes ("Re: Bug#1131881: want way to supporess dpkg-genchanges missing package warning"):
> The problem is that the filename patterns that are considered BYHAND
> do not have a structured format to denote that they are generically
> "source" (or any arch-specific) artifacts.

I see the problem.  It's a shame that you weren't in the conversation
about this filename choice, but of course that was a very unpleasant
political row so I quite understand why you weren't.  I'm sorry that
it didn't occur to me to ask your opinion.

> On Wed, 2026-03-25 at 19:42:15 +0000, Ian Jackson wrote:
> > Empirically, passing `-S` to dpkg-genchanges causes it to omit the
> > .git.tar.gz, which is also wrong.
> 
> It might be wrong for what you intended, but it is correct from what
> dpkg has understood those types of artifacts to be.

Yes, sorry, I meant "wrong in this particular use case".

> I don't think dpkg should special case this (or any, really) BYHAND
> artifact, which it has no hand at creating, nor any awareness of its
> contents, and which is taking on a very generic name from the filename
> namespace.

That's quite a reasonable point of view.  Of course it would be
possible for our code to pass an option to dpkg-genchanges saying
"please treat this particular file or pattern a particular way", but
that seems like a lot of API surface etc. for a minor issue.

> 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.

> > I think ideally we would like this fix to be backported to stable-bpo.
> > The tag2upload builder uses dpkg-dev from stable, and I don't think we
> > want to change that.
> 
> AFAIR the backports team has had a long standing policy of not
> accepting dpkg backports (which I agree with).

Ah.  Yes.

>  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.

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.

Ian.

-- 
Ian Jackson <[email protected]>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.