Acknowledgement sent
to Daniel Kahn Gillmor <[email protected]>:
New Bug report received and forwarded. Copy sent to Debian Lintian Maintainers <[email protected]>.
Your message specified a Severity: in the pseudo-header, but
the severity value minior was not recognised.
The default severity normal is being used instead.
The recognised values are: critical, grave, serious, important, normal, minor, wishlist, fixed.
Acknowledgement sent
to Matt Barry <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <[email protected]>.
(Fri, 01 Jul 2022 21:24:03 GMT) (full text, mbox, link).
Looking at the check, it seems there is an exemption for SVG files
built in; would it make any sense to search for a text/* mime type
instead (ala libfile-libmagic-perl)?
Cheers,
Matt
Acknowledgement sent
to Axel Beckert <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <[email protected]>.
(Sun, 03 Jul 2022 01:42:03 GMT) (full text, mbox, link).
Subject: Re: Bug#1014156: lintian: very-long-line-length-in-source-file for
non-text source files
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 protected]>
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 protected]>
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 protected]>, 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
Changed Bug title to 'lintian: very-long-line-length-in-source-file should use file/magic to distinguish text from binary files' from 'lintian: very-long-line-length-in-source-file for non-text source files'.
Request was from Axel Beckert <[email protected]>
to [email protected].
(Sun, 03 Jul 2022 01:42:04 GMT) (full text, mbox, link).
Changed Bug title to 'lintian: very-long-line-length-in-source-file should ignore lines starting with INSERT or SELECT (i.e. commonly long SQL statements)' from 'lintian: very-long-line-length-in-source-file should use file/magic to distinguish text from binary files'.
Request was from Axel Beckert <[email protected]>
to [email protected].
(Sun, 03 Jul 2022 01:42:06 GMT) (full text, mbox, link).
Changed Bug title to 'lintian: very-long-line-length-in-source-file should use file/magic to distinguish text from binary files' from 'lintian: very-long-line-length-in-source-file should ignore lines starting with INSERT or SELECT (i.e. commonly long SQL statements)'.
Request was from Axel Beckert <[email protected]>
to [email protected].
(Sun, 03 Jul 2022 02:18:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Matt Barry <[email protected]>:
Extra info received and filed, but not forwarded.
(Wed, 06 Jul 2022 00:21:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Andreas Beckmann <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <[email protected]>.
(Wed, 04 Jan 2023 12:39:02 GMT) (full text, mbox, link).
Subject: Re: lintian: very-long-line-length-in-source-file should use file/magic to distinguish text from binary files
Date: Wed, 04 Jan 2023 13:35:37 +0100
Followup-For: Bug #1014255
tested with current git (2.115.3-66-ge45c16683):
E: pyopencl source: source-is-missing [_skbuild/linux-x86_64-3.11/cmake-install/pyopencl/_cl.cpython-311-x86_64-linux-gnu.so]
P: pyopencl source: source-contains-prebuilt-binary [_skbuild/linux-x86_64-3.11/cmake-install/pyopencl/_cl.cpython-311-x86_64-linux-gnu.so]
X: pyopencl source: very-long-line-length-in-source-file 21987 > 512 [_skbuild/linux-x86_64-3.11/cmake-install/pyopencl/_cl.cpython-311-x86_64-linux-gnu.so:21]
Just funny that lintian considers the prebuilt binary as source ...
(not going to be uploaded, already fixed in a new pyopencl upstream release)
Andreas
Acknowledgement sent
to "Dr. Bas Wijnen" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <[email protected]>.
(Wed, 02 Aug 2023 19:03:03 GMT) (full text, mbox, link).
Subject: Long lines should also be ignored from non-code text files
Date: Wed, 2 Aug 2023 21:01:19 +0200
Hi,
Axel writes that README.md and LICENSE are likely valid cases. I disagree.
While I (and I expect many developers in Debian) are used to using short lines
in text files, this is not that common for other people. Many will use the
automatic word-wrap feature of text editors and write a whole paragraph on a
single line.
I don't think I should ask upstream to reformat their non-code text files; it's
not a good use of their time, and also they would likely not even do it.
Instead, I hope lintian can avoid emitting this tag for non-code text files (in
particular: *.txt, *.html, *.md). Although CMakeLists.txt is probably an
exception: that is code and it shouldn't contain long lines.
I could add overrides, but I don't think this would be an appropriate case for
that. But please let me know if it is.
Thanks,
Bas
Acknowledgement sent
to Louis-Philippe Véronneau <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <[email protected]>.
(Wed, 02 Aug 2023 19:33:05 GMT) (full text, mbox, link).
On 2023-08-02 15 h 01, Dr. Bas Wijnen wrote:
> Hi,
>
> Axel writes that README.md and LICENSE are likely valid cases. I disagree.
> While I (and I expect many developers in Debian) are used to using short lines
> in text files, this is not that common for other people. Many will use the
> automatic word-wrap feature of text editors and write a whole paragraph on a
> single line.
>
> I don't think I should ask upstream to reformat their non-code text files; it's
> not a good use of their time, and also they would likely not even do it.
>
> Instead, I hope lintian can avoid emitting this tag for non-code text files (in
> particular: *.txt, *.html, *.md). Although CMakeLists.txt is probably an
> exception: that is code and it shouldn't contain long lines.
>
> I could add overrides, but I don't think this would be an appropriate case for
> that. But please let me know if it is.
>
> Thanks,
> Bas
>
Note that the 'very-long-line-length-in-source-file' was marked as
'experimental' in this commit [1] exactly for that kind of reason.
The default lintian mode doesn't use the 'experimental' tags and I would
advise you not to include them if this tag is currently bothering you.
[1]:
https://salsa.debian.org/lintian/lintian/-/commit/899bd1b683c479e166ebd465ff0ad101fbd04ee2
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ [email protected] / veronneau.org
⠈⠳⣄
Acknowledgement sent
to Russ Allbery <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <[email protected]>.
(Wed, 02 Aug 2023 20:03:03 GMT) (full text, mbox, link).
Subject: Re: Bug#1014255: Long lines should also be ignored from non-code
text files
Date: Wed, 02 Aug 2023 13:02:01 -0700
"Dr. Bas Wijnen" <[email protected]> writes:
> Axel writes that README.md and LICENSE are likely valid cases. I
> disagree. While I (and I expect many developers in Debian) are used to
> using short lines in text files, this is not that common for other
> people. Many will use the automatic word-wrap feature of text editors
> and write a whole paragraph on a single line.
Or, if not a whole paragraph, there are pretty strong arguments for
following https://xkcd.com/1285/ whenever writing in any markup language,
including Markdown, which can lead to long lines for complex sentences.
That's the standard for our projects at my current employer.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.