Subject: Re: Bug#1014156: lintian: very-long-line-length-in-source-file for non-text source files

From: Axel Beckert <[email-masked]>
Date: Sun, 3 Jul 2022 03:38:21 +0200

Control: tag -1 + confirmed
Control: clone -1 -2
Control: retitle -2 lintian: very-long-line-length-in-source-file should use file/magic to distinguish text from binary files
Control: submitter -2 Matt Barry <[email-masked]>
Control: severity -2 wishlist
Control: clone -1 -3
Control: retitle -2 lintian: very-long-line-length-in-source-file should ignore lines starting with INSERT or SELECT (i.e. commonly long SQL statements)
Control: submitter -2 Peter B <[email-masked]>

Hi,

Daniel Kahn Gillmor wrote:
> lintian 2.115.2 complains (in --pedantic) in the following way about
> these non-text files in the gnupg2 sources:

Thanks for this list.

From my point of view while many of these binary files might not be in
the preferred representation (especially for the .gmo files I'd expect
a plain text file to be the source),
very-long-line-length-in-source-file should not be emitted for binary files.

> I'd prefer it if lintian instead just wouldn't flag non-text source
> files with this tag.

Correct. Currently this is handled via a blacklist of common binary
file suffixes.

>  - some of them are GNU message catalogs -- compiled output of .po files
>    that upstream prefers to ship in the tarball for folks building the
>    package without l10n toolchains.  we rebuild them in debian, but i'd
>    still rather ship the upstream tarball if possible.

Yep. Do expect that there will be a future lintian tag for these kind
of files which is meant to be overriden if and only if the build
system rebuilds them at build time.

Matt Barry wrote:
> Looking at the check, it seems there is an exemption for SVG files
> built in;

At least not at the suffix list.

> would it make any sense to search for a text/* mime type
> instead (ala libfile-libmagic-perl)?

Yes, that would probably make more sense than manually curating a list
of suffixes. Also the performance impact should be low as Lintian
seems to run "file" over nearly every file anyways.

That's nevertheless not a short term fix. Cloning this bug report into
a new one to track this separately.

Peter B wrote:
> On 01/07/2022 06:08, Daniel Kahn Gillmor wrote:
> > Package: lintian
> > Version: 2.115.2
> > Severity: minior
> > Control: affects -1 src:gnupg2
> > 
> > lintian 2.115.2 complains (in --pedantic) in the following way about
> > these non-text files in the gnupg2 sources:
> > 
> > P: gnupg2 source: very-long-line-length-in-source-file 1008 > 512
> > [po/eo.gmo:7]

Please refrain from doing fullquotes in the Debian bug tracking system
unless really necessary. Thanks!

> I'm also seeing this with strawberry. Several hits from binary sound
> files in it's test suite.

Thanks for that list as well. One item though caught my eye:

> > P: strawberry source: very-long-line-length-in-source-file 3435 > 512 [dist/macos/strawberry.icns:5678]

The suffix "icns" is already in the blacklist since 2.115.2. With
which version of Lintian did you generate that list?

> > P: strawberry source: very-long-line-length-in-source-file 543 > 512 [CMakeLists.txt:535]
> > P: strawberry source: very-long-line-length-in-source-file 687 > 512 [3rdparty/SPMediaKeyTap/README.md:4]
> > P: strawberry source: very-long-line-length-in-source-file 756 > 512 [3rdparty/SPMediaKeyTap/LICENSE:8]

These are likely a valid cases.

> > P: strawberry source: very-long-line-length-in-source-file 559 > 512 [data/schema/schema-8.sql:587]
> > P: strawberry source: very-long-line-length-in-source-file 566 > 512 [data/schema/schema-11.sql:235]

These are corner cases IMHO. Not really binary files, but also files
where long lines are very common, especially for INSERT and SELECT.

I tend to write code which explicitly ignores lines starting with
INSERT or SELECT for that.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <[email-masked]>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE