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 <m...@hazelmollusk.org>
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 <pe...@pblackman.plus.com>
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 <a...@debian.org>, 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
