Bug#1019980: lintian: source-is-missing check for HTML is much too sensitive

[Colin Watson <cjwatson@debian.org>]

On Thu, Feb 08, 2024 at 06:39:18PM +0000, Bastien Roucariès wrote:
> Are you sure it is not embdeded base64 encoded png or minified javascript* ?

Yes, I'm absolutely certain.

> If not we could try to know why it choke ?  

I already gave a full explanation of this in my first message, which for
some reason people are ignoring:

"""
So it issues a diagnostic for every HTML file with a somewhat long line
(over 512 characters) unless it has an associated .fragment.js somewhere
"""

The HTML files it's issuing a diagnostic on here are perfectly innocuous
and readable.  Here's an example of one of the "offending" lines:

  In version 0.51 and before, local echo could not be separated from local line editing (where you type a line of text locally, and it is not sent to the server until you press Return, so you have the chance to edit it and correct mistakes <em>before</em> the server sees it). New in version 0.52, local echo and local line editing are separate options, and by default PuTTY will try to determine automatically whether to enable them or not, based on which protocol you have selected and also based on hints from the server. If you have a problem with PuTTY's default choice, you can force each option to be enabled or disabled as you choose. The controls are in the Terminal panel, in the section marked &#8216;Line discipline options&#8217;.

I mean, come on.  Sure, there are a couple of character entities (which
have nothing to do with the diagnostic here anyway), but otherwise you
can't tell me with a straight face that that's some kind of obscure
compiled format; I would have written it exactly the same way by hand
except for the word-wrapping.

> Another alternative if we could determine the file was compiled by halibut, we could demote to pedantic warning 
> and ask to repack in order to be sure to recompile from source.

Or we could fix the ridiculously-oversensitive diagnostic.

On the matter of repacking (which I will not do in this case), please
see my comment in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019980#15.

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]