Bug#954149: this tag needs work

from #debian-qa IMHO executable-in-usr-lib expresses a preference not supported by Debian policy (or FHS 3.0) A helpful bystander: the FHS page lintian links to says "To accomodate this restriction, it became common practice to use /usr/lib instead. Either practice is now

Bug#906281: lintian: Severity and Certainty of emacsen-common-without-dh-elpa are wrong / false positives despite "Certainty: certain"

Chris Lamb writes: > Chris Lamb wrote: > >> tags 906281 + moreinfo >> thanks >> >> Hi all, >> >> > lintian: Severity and Certainty of emacsen-common-without-dh-elpa >> > are wrong / false positives despite "Certainty: certain" >> >> So, what are the next, concrete, steps for Lintian here? I

Bug#908350: lintian: wrong-path-for-interpreter needs updating to match policy 4.2.1

Chris Lamb writes: > --- a/checks/scripts.desc > +++ b/checks/scripts.desc > @@ -198,7 +198,7 @@ > . > Note that, as a special exception, Debian Policy § 10.4 states that > - Perl scripts must use /usr/bin/perl directly and not > + Perl scripts should use /usr/bin/perl directly

Bug#908350: lintian: wrong-path-for-interpreter needs updating to match policy 4.2.1

Package: lintian Version: 2.5.100 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Since policy downgraded the "must" quoted by this tag to a "should", at least the text of the tag should change. Maybe perl folk have suggestions? Also, should it still be an error? Are those only

Bug#906281: lintian: Severity and Certainty of emacsen-common-without-dh-elpa are wrong / false positives despite "Certainty: certain"

Axel Beckert writes: > Please note that I'm not 100% sure if these wildcards would match all > relevant packages for now. Looking into the dh_elpa source code again > might reveal some better metrics. Maybe also David Bremner (reincluded > in Cc) might have some more insight with wh

Bug#904420: lintian: Warn about empty fields in source package control files

Chris Lamb writes: > > Naturally, this could also be indicative of a problem with the > packaging. Very happy to entertain a request to raising the severity > though; fancy retitling the bug to match? Done.

Bug#904420: lintian: Warn about empty fields in source package control files

Chris Lamb writes: > tags 904420 + moreinfo > thanks > > Hi David, > >> Vcs-Browser: has only whitespace, and Vcs-Git: is empty > > Unless I'm missing something, this should already be warned by "debian- > control-has-empty-field" as well as "file-contains-trailing-whitespace". > > (These are

Bug#904420: lintian: Warn about empty fields in source package control files

Package: lintian Version: 2.5.93 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I just encountered a source package with Vcs-Browser: Vcs-Git: (Vcs-Browser: has only whitespace, and Vcs-Git: is empty). This seems like something lintian should complain about. This is related

Bug#883772: lintian: please don't map implimentation language to sections

Guillem Jover writes: > TBH I think the distinction here is clear (at least to me), language- > specific sections should *only* contain things that are language specifc > modules that are automatically depended on, and language-specific > toolchains and similar. But nothing

Bug#883772: lintian: please don't map implementation language to sections

Chris Lamb writes: > Hey David! > >> the programming-language sections are a mess > > Whilst I don't necessarily disagree, I'm not sure what the next steps > for Lintian are here. > > Putting it another way, I see you linked #802488 but until that gets > some kind of resolution

Bug#886219: lintian should be less pedantic about latest policy version

Sean Whitton writes: > Let me first say exactly what change I'd recommend: > > - out-of-date-standards-version should be I: or P: instead of W: > - ancient-standards-version should remain W: > - ancient-standards-version should be triggered when S-V contains a >

Bug#883772: lintian: please don't map implimentation language to sections

Package: lintian Version: 2.5.59 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 As summarized in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802488 the programming-language sections are a mess. It's not clear why the user cares about the implimentation language when

Bug#877999: lintian: false positive: license-problem-non-free-RFC debian/copyright

Package: lintian Version: 2.5.54 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The tag in the subject is generated for source package Racket. Severity is because this is used as an autoreject tag. Maybe that's not lintian's fault. I suspect it's triggered by some

Bug#867042: lintian: new tag: emacsen-common-without-dh-elpa

Sean Whitton writes: > > CCing David, who wrote the code that adds the Built-Using header, but > I'm pretty sure that it is indeed there for GPL compliance purposes. > > dh-elpa adds emacsen-common maintscripts to packages built using > dh-elpa, and (according to the

Bug#864555: lintian: please use a more reliable heuristic than line length to detect source-is-missing

Package: lintian Version: 2.5.50.4 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On polymake 3.1 source lintian reports: E: polymake source: source-is-missing external/js/renderers/SVGRenderer.js line length is 258 characters (>256) An examination reveals this to be a false

Bug#652602: lintian: false positive weak-library-dev-dependency for arch:all lib packages.

Package: lintian Version: 2.5.4 Severity: normal Running lintian on gmime2.4_2.4.25-1.dsc (from sid) produces E: gmime2.4 source: weak-library-dev-dependency libgmime2.4-cil-dev on libgmime2.4-cil (= ${source:Version}) But this is dependency is actually OK afaict, since libgmime2.4-cil is

Bug#607694: updated patch, tests.

Here is an update patch, with better analysis of files containing only blank lines and comments, and some tests. pgpVBtsiGPPan.pgp Description: PGP signature From 9bc1134735d5121dd7526fbafb05be0badc5665e Mon Sep 17 00:00:00 2001 From: David Bremner brem...@debian.org Date: Sun, 19 Dec 2010 11

Bug#607694: lintian: new check: did the user mean to export patches using gitpkg?

information From 3c001aeaae1cf3699215406fdb963d12e6f187e8 Mon Sep 17 00:00:00 2001 From: David Bremner brem...@debian.org Date: Sun, 19 Dec 2010 11:01:57 -0400 Subject: [PATCH] checks/debian-source-dir: add check for exporting from d/s/git-patches If debian/source/git-patches exists, read debian/patches

Bug#490591: lintian fails on sketch-doc 1:0.89

Package: lintian Version: 1.23.46 Severity: normal I'm not sure if something is wrong with my package or lintian, but lintian gets an internal error when run on sketch-doc. You can fetch the package from the sid archive % sudo aptitude reinstall sketch-doc % lintian

Bug#460350: please support configuration option to make --display-info default

Package: lintian Version: 1.23.42 Severity: wishlist --- Please enter the report below this line. --- Hi; As a beginner packager, I find the -I option to lintian very helpful. I would like to be able to configure lintian to display-info by default. Aliases do not help because I mostly use