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

On Wed, 2026-03-25 at 19:42:15 +0000, Ian Jackson wrote:
> Package: dpkg-dev
> Version: 1.22.22
> Control: block 1131609 by -1

(*Sigh*, that blocked bug report, here we go again… :( )

> In tag2upload, we see warnings like this from dpkg-genchanges:
> 
> > >> Appending 'hippotat_1.3.2.git.tar.xz net optional' to debian/files
> > dpkg-genchanges: warning: package hippotat-client in control file but not in files list
> > dpkg-genchanges: warning: package hippotat-server in control file but not in files list
> > dpkg-genchanges: warning: package hippotat-common in control file but not in files list
> 
> The reason for this seems to be the `.git.tar.xz` file, which is a
> bundle of git stuff which forms part of our agreement with the ftp
> archive team.
> 
> This causes dpkg-genchanges to no longer consider the upload
> source-only, and instead it complains about all the missing binaries.

This is considered an unknown BYHAND or raw artifact (see
Dpkg::Dist::Files), which have always been considered binary artifacts
with unknown content, to be processed by the archive side (either
manually, or automatically if it conforms to some specific convention).

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.

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

> Could this warning please be suppressed, somehow, or made suppressable?
> A tag2upload-specific option would be fine, or an option to suppress
> this specific warning.  Alternatively, special handling of the
> `.git.tar.xz` would be a possibility.
>
> NB that the .git.tar.xz forms part of the upload (ie is mentioned in
> .changes) but not part of the source package (so is not mentioned in
> the .dsc).

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.

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'd also document the existing pattern rules used to decide what
constitutes a BYHAND artifact (updated to cover the new source and binary
semantics), which I don't see explicitly documented anywhere (besides in
code comments and logic). And I should add in any case and regardless
of how this request ends up being addressed a way to specify accepted
keywords via dpkg-distaddfile.

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

Thanks,
Guillem

diff --git i/scripts/dpkg-genchanges.pl w/scripts/dpkg-genchanges.pl
index 2b249ae4e..d11724c16 100755
--- i/scripts/dpkg-genchanges.pl
+++ w/scripts/dpkg-genchanges.pl
@@ -352,6 +352,14 @@ foreach my $file ($dist->get_files()) {
         next;
     }
 
+    if (defined $a && $a eq 'source') {
+        if (build_has_any(BUILD_SOURCE)) {
+            # Allow source byhand artifacts.
+            $checksums->add_from_file("$uploadfilesdir/$fn", key => $fn);
+        }
+        next;
+    }
+
     # If this is a source-only upload, ignore any other artifacts.
     next if build_has_none(BUILD_BINARY);