Package: lintian Version: 2.111.0~bpo11+1, 2.114.0 I discovered during compilation of a (slightly) older package that still uses a debhelper (>= 12) compatibility with a debian/compat file stating 12 that the tag missing-build-dependency-for-dh-addon is unable to detect the fact that dh-autoreconf is needed when debhelper >= 10 is specified in the control file or in debian/compat. This resulted in the erroneous errors on missing dh-autoreconf in xca, where it's not needed by debhelper >= 12 with a compat file stating 12.
This does not trigger when using "debhelper-compat (= 12)" in debian/control without the debian/compat file, however the tag information and description I saw was this when triggered on mentors.debian.org: autoreconf => dh-autoreconf | debhelper (>= 9.20160403~) | debhelper-compat This suggests that if in debian/control you have a "debhelper (>= 9.20160403~)" line (which "debhelper (>= 12)" qualifies), OR you have debhelper-compat, that this should not trigger. HOWEVER, this triggers unless debhelper-compat is present in the build-depends, suggesting the tag is NOT being correctly matched during Lintian runs if multi-level compatibility or experimental debhelper compatibility (hence "debian/compat" and "debhelper >= 12" being present in a given package) based on what I've read in manpages. This looks like erroneous tag detection. Note that if you put in dh-autoreconf into build-deps it triggers the as-expected useless-autoreconf-build-depends tag. This currently triggers on the XCA package as uploaded to mentors.debian.net yesterday - both versions of the package (the one with dh-autoreconf in build-deps and the verison with debian/compat and "debhelper (>= 12)" in debian/control) exist to show this distinction, and both packages in sid sbuild chroots reproduce this behavior.
