Bug#487780: lintian: Check for ancient-standards-version based on age of next version

Package: lintian Version: 1.24.1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The ancient-standards-version check would be more useful if it checked against the age of the next version. A trivial example is that if debian-policy went two years without an update, then the

Bug#490264: lintian: [checks/copyright-file] copyright-should-refer-to-common-license-file-for-gpl false positive

Package: lintian Version: 1.24.1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The python-dns package contains code derived from Python code licensed under the CNRI OPEN SOURCE GPL-COMPATIBLE LICENSE. This reference trips the rule and should not. That is the actual name of

Bug#493920: lintian: debconf-error-requires-versioned-depends test apparently obsolete

Package: lintian Version: 1.24.2 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to the extended description in debconf-error-requires-versioned-depends, it is only relevant for oldstable (Sarge) backports. Since Sarge is no longer supported, it would seem this test

Bug#496826: source: package-lacks-versioned-build-depends-on-debhelper 5 test should be removed

Package: lintian Version: 1.24.3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since oldstable (Sarge) is no longer supported, this test can be removed. - -- System Information: Debian Release: lenny/sid APT prefers hardy-updates APT policy: (500, 'hardy-updates'), (500,

Bug#505826: lintian: Redundant check for symbols-file-contains-debian-revision

Package: lintian Version: 2.0.0 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If symbols-file-contains-current-version-with-debian-revision is a problem, also reporting symbols-file-contains-debian-revision for the same symbol is redundant and just makes lintian reports noisy.

Bug#616553: lintian: missing-python-build-dependency doesn't know about python3 packages

Package: lintian Version: 2.4.3ubuntu2 Severity: normal The new pacakge py3dns triggers the missing-python-build-dependency error even though it's not missing anything. See http://lintian.debian.org/maintainer/sc...@kitterman.com.html#py3dns The test should also look for the python3 versions

Bug#642908: Please don't

There's no basis in policy for trying to push DEP-5 format on people. If people want to spend their time on converting perfectly adequate copyright files into a new complex format that has more rules and is less readable, they are welcome to, but it's not appropriate to use Lintian as a

Bug#664520: lintian: [new check] Unusual documentation package name, foo-docs

Package: lintian Version: 2.5.5 Severity: wishlist It turns out a few people (including me) have been using -docs for documentation package names intead of -doc: $ zcat Packages.gz | grep-dctrl -F Package -e '^.*-doc$' -ns Package | wc -l 2415 $ zcat Packages.gz | grep-dctrl -F Package -e

Bug#673734: lintian: python-script-but-no-python-dep check should not check python3 directories

Package: lintian Version: 2.5.7 Severity: normal E: python3-pykde4: python-script-but-no-python-dep usr/lib/python3/dist-packages/PyQt4/uic/pykdeuic4.py python-script-but-no-python-dep should not check for scripts in usr/lib/python3. Instead, a Python 3 version of the test should check for

Bug#745694: lintian: False positive E: clamav source: source-is-missing unit_tests/encode.js.ref

Package: lintian Version: 2.5.22.1 Severity: normal encode.js isn't actually minified, there's just not much there, so this is a false positive. Have a look at the clamav source. -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble?

Bug#755355: lintian: New check for use of pyqtconfig

Package: lintian Version: 2.5.25 Severity: wishlist For applications that use python-qt4, pyqtconfig has been the standard way to access attributes about the PyQt4 installation. Upstream has decided to drop this for alternate methodes. For now, we can continue to use the upstream legacy

Bug#769036: lintian: Please add no-human-maintainers to Ubuntu profile

Package: lintian Version: 2.5.30 Severity: normal As in the subject, this test isn't relevant for the Ubuntu team maintenance approach, so it should be skipped in Ubuntu. I've added this to the package in Ubuntu and would appreciate it being added to the Ubuntu profile in Debian's package to

Bug#791611: lintian: Sysv init script false positives on service files

Package: lintian Version: 2.5.32 Severity: normal I just uploaded the first version of opendkim that shipped a systemd sevice file. Lintian was seriously unhappy with it: opendkim W executable-not-elf-or-script etc/init.d/opendkim.service etc/init.d/opendkim.service E

Bug#829744: Add new-package-should-not-package-python2-module tag

On Wed, 06 Jul 2016 01:06:57 +0200 Chris Lamb wrote: > Mattias Klose wrote: > > > Please only trigger this warning if no corresponding > > python3 module is uploaded (at least until after the > > stretch release). > > Are we sure? The idea is to dissuade the Python 2 module

Bug#829744: Add new-package-should-not-package-python2-module tag

On Friday, September 30, 2016 05:01:00 PM Niels Thykier wrote: > On Wed, 06 Jul 2016 00:30:08 -0400 Scott Kitterman > > <deb...@kitterman.com> wrote: > > [...] > > > > If that's the case, then it's premature before the freeze. Python2.7 is > > 'supported

Bug#884499: lintian: Pedantic check for packages not using debhelper or CDBS

On May 7, 2018 12:20:04 AM UTC, Chris Lamb wrote: >Hi Scott, > >> For what it's worth, this is an example of the kind of check that >isn't >> supported by policy. > >I'm not quite following your chain of logic wrt to Lintian and Debian >Policy. I mean, there are countless

Bug#884499: lintian: Pedantic check for packages not using debhelper or CDBS

On May 7, 2018 1:26:36 AM UTC, Russ Allbery wrote: >Chris Lamb writes: > >> However, my experience with being an author of a handful of static >> analysis tools is that people have a slight tendency to delegate >> thinking to the computer's output. The

Bug#892304: lintian: Warn about "old" X-Python3-Version fields?

On Friday, May 04, 2018 04:17:37 PM Nicholas D Steeves wrote: > I remember this Thanks for mentioning this bug in > #debian-python. I followed > https://wiki.debian.org/Python/LibraryStyleGuide#Python_versions and > it would seem it also needs to be updated. ... > > Should articles in the wiki

Bug#892304: lintian: Warn about "old" X-Python3-Version fields?

On Thu, 08 Mar 2018 02:07:36 + Chris Lamb wrote: > Package: lintian > Version: 2.5.77 > Severity: wishlist > > Hi, > > Should we warn about "old" X-Python3-Version fields? For example, I > just saw a new package from a sponsee with: > > X-Python3-Version: >= 3.2 > >

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

On Monday, May 07, 2018 01:35:30 PM Russ Allbery wrote: > Scott Kitterman <deb...@kitterman.com> writes: > > Package: lintian > > Version: 2.5.85 > > Severity: normal > > > > Also, please reduce the certainty from certain. It's not. > > > &g

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

Package: lintian Version: 2.5.85 Severity: normal Also, please reduce the certainty from certain. It's not. I'd just noticed depends-on-mail-transport-agent-without-alternatives. I mainain approximately 10% of the packages affected by the check (3 of 33) and in all those cases the check is

Bug#884499: lintian: Pedantic check for packages not using debhelper or CDBS

On Sat, 05 May 2018 19:42:05 +0100 Chris Lamb wrote: > tags 884499 + pending > thanks > > Actually, let's give this a whirl. Implemented in Git, > pending upload: > > > https://salsa.debian.org/lintian/lintian/commit/1ecc761fea7b22f85faf400ac134d24438454e4d > >

Bug#897213: lintian: Please remove dependency-on-python-version-marked-for-end-of-life until after Buster releases

Thanks. I think that will work. Scott K On Thursday, May 03, 2018 05:48:36 AM Chris Lamb wrote: > tags 897213 + pending > thanks > > > People pay attention to lintian results and so the tags > > should be actionable. > > Indeed, that's convincing enough and I have not heard anything from >

Bug#897213: lintian: Please remove dependency-on-python-version-marked-for-end-of-life until after Buster releases

Package: lintian Version: 2.5.84 Severity: important Dear Maintainer, There has been a lot of discussion on debian-devel about the future of python2.7 in Buster. The dependency-on-python-version-marked-for-end-of-life flag is confusing people into thinking they should drop python2.7 support

Bug#897213: lintian: Please remove dependency-on-python-version-marked-for-end-of-life until after Buster releases

On Monday, April 30, 2018 06:52:30 AM Chris Lamb wrote: > [adding Matthias to CC as he filed #883581] > [adding Holger to CC as he filed #886259] > > Hi Scott, > > Thanks for opening this! > > > I understand (and agree with) the intent of this check, but in practice, > > it's harming the

Bug#886303: lintian: python-foo-but-no-python3-foo false positive

On January 7, 2018 5:25:21 PM UTC, Mattia Rizzolo <mat...@debian.org> wrote: >On Sun, Jan 07, 2018 at 11:40:41AM -0500, Scott Kitterman wrote: >> As discussed, stepic is another case of this that I just ran into. >The test >> was a useful reminder that it hadn't been po

Bug#887124: lintian: Do not use new-package-should-not-package-python2-module on lintian.d.o

Package: lintian Version: 2.5.68 Severity: normal Dear Maintainer, When new-package-should-not-package-python2-module appears on lintian.d.o, it is an unneeded distraction. At this point it's no longer a new package. Any future upload will 'fix' the issue since all this test does is check that

Bug#887124: lintian: Do not use new-package-should-not-package-python2-module on lintian.d.o

On January 14, 2018 8:12:00 AM UTC, Niels Thykier <ni...@thykier.net> wrote: >Scott Kitterman: >> Package: lintian >> Version: 2.5.68 >> Severity: normal >> >> Dear Maintainer, >> >> When new-package-should-not-package-python2-module appear

Bug#886303: lintian: python-foo-but-no-python3-foo false positive

Package: lintian Version: 2.5.67 Severity: normal Dear Maintainer, As you can see on lintian.d.o [1], qscintilla2 has: W python-foo-but-no-python3-foo python-qscintilla2 python-qscintilla2-dbg This is literally true, but not useful. There is no python3-qscintilla2, but there is

Bug#904817: lintian: Warn that depending on both Python 2 and Python 3 interpreters is unusual, likely a mistake?

On Sat, 28 Jul 2018 14:16:11 +0100 Chris Lamb wrote: > Hi Stuart, > > > In the upload of translate-toolkit 2.3.0-3, I ended up with the following: > > > > Depends: python3, python3-pkg-resources, python3-six, python3-translate, > > python3:any, python:any > > > > such that the package

Bug#904817: lintian: Warn that depending on both Python 2 and Python 3 interpreters is unusual, likely a mistake?

On July 29, 2018 7:39:53 AM UTC, Chris Lamb wrote: >Hey Scott, > >> You don't need to know. All you need to know is a package depends on >both. I >> don't think that there is any need to limit it to pyhon{3}-* >pacakges. > >Nod. :) > >(Oh, just in case I am parsing your '{3}' regex wrong,

Bug#916735: lintian: appstream-metadata-missing-modalias-provide should be info, not warn

Package: lintian Version: 2.5.117 Severity: normal The appstream-metadata-missing-modalias-provide relates to a nice to have feature. Lintian treating this at a "Warning" level seems excessive for something that's completely optional. Info seems right. Scott K

Bug#917094: lintian: systemd-service-file-missing-hardening-features doesn't actually help

On December 22, 2018 3:42:17 PM UTC, Chris Lamb wrote: >tags 917094 + moreinfo >thanks > >Scott Kitterman wrote: > >> Is lintian really an advertising medium for various package features? > >Come now, that's an unfortunately combative way of phrasing this

Bug#917094: lintian: systemd-service-file-missing-hardening-features doesn't actually help

Package: lintian Version: 2.5.117 Severity: normal Is lintian really an advertising medium for various package features? This seems like something that would be better a subject of a blog post on planet.d.o than a lintian tag. I know it's just experimental, but I get to see it 11 times if I go

Bug#916207: lintian: debian-watch-does-not-check-gpg-signature certainty considered annoying

est. Could your > concern be resolved by better naming? > > I process the tag name (it has already been renamed once [1]) as > "debian-watch-does-not-check-A-gpg-signature." Without a signature > that is an objective fact. > > On Tue, Dec 11, 2018 at 5:18 AM Scott Kitterm

Bug#917264: lintian: dependency-on-python-version-marked-for-end-of-life needs an action

Package: lintian Version: 2.5.118 Severity: normal As I've discussed before in lintian bug reports, I think lintian tags should be actionable. This one isn't, but I have an idea. What if the description were updated to suggest adding an override for that it's known aren't being ported to

Bug#917028: lintian: package-contains-no-arch-dependent-files false positive

Package: lintian Version: 2.5.117 Severity: normal Running the current lintian against libnitrokey, subject rule is tripped, but the package contains: ./usr/lib/x86_64-linux-gnu/ ./usr/lib/x86_64-linux-gnu/pkgconfig/ ./usr/lib/x86_64-linux-gnu/pkgconfig/libnitrokey-1.pc The claim that all

Bug#916735: lintian: appstream-metadata-missing-modalias-provide should be info, not warn

On Thursday, December 20, 2018 01:08:54 PM Petter Reinholdtsen wrote: > [Paul Wise] > > > I don't think I have the requisite time and understanding to do this, > > hopefully Petter will be interested to work on this but in general I > > think it will be best for individual upstreams to work on

Bug#916207: lintian: debian-watch-does-not-check-gpg-signature certainty considered annoying

Package: lintian Version: 2.5.116 Severity: minor As designed, debian-watch-does-not-check-gpg-signature does not check if upstream provides a GPG signature to make checking it possible. I get that the "Certainty: certain" is meant to mean that it's certain that uscan won't check a GPG

Bug#916735: lintian: appstream-metadata-missing-modalias-provide should be info, not warn

On December 19, 2018 7:18:42 AM UTC, Paul Wise wrote: >On Wed, 19 Dec 2018 01:00:43 +0100 Chris Lamb wrote: > >> Nobody is doubting the value here, one just has to square that with >> the idea that Lintian being too pedantic, noisy or making the wrong >> priority choices is bad for

Bug#926469: lintian: Postfix results missing from lintian.d.o

Package: lintian Version: 2.12.0 Severity: normal Reporting this as a bug against the package because the web site says: "Comments about these web pages? Please use reportbug to report a bug against the lintian package." I am 100% certain that postfix is not lintian clean, yet it isn't on

Bug#926060: lintian: portable-executable-missing-security-features false positives

Package: lintian Version: 2.11.0 Severity: normal I'm reasonably confident that clamav testfiles don't need hardening features, so [1] seems pretty pointless. Scott K [1] https://lintian.debian.org/maintainer/pkg-clamav-de...@lists.alioth.debian.org.html#clamav clamav-testfiles E

Bug#926060: lintian: portable-executable-missing-security-features false positives

On Monday, April 01, 2019 04:45:44 AM Chris Lamb wrote: > tags 926060 + moreinfo > thanks > > Hi Scott, > > > I'm reasonably confident that clamav testfiles don't need hardening > > features, so [1] seems pretty pointless. > > I don't disagree at all here but I'm wondering how Lintian would be

Bug#926060: lintian: portable-executable-missing-security-features false positives

On April 1, 2019 10:30:58 AM UTC, Chris Lamb wrote: >Hi Scott, > >> > > I'm reasonably confident that clamav testfiles don't need >hardening >> > > features, so [1] seems pretty pointless. >> > >> > I don't disagree at all here but I'm wondering how Lintian would be >> > able to detect that

Bug#933167: lintian: python-script-but-no-python-dep test has false positives

Package: lintian Version: 2.16.0 Severity: normal There are several python3 packages that ship python scripts in usr/lib/python3/dist-packages. Currently this trips the test. As far as I can tell, it's a false positive in all such cases (since files in dist-packages aren't supposed to be called

Bug#941774: lintian: False positive for symbols-file-contains-current-version-with-debian-revision

Package: lintian Version: 2.24.0 Severity: normal The current version of lintian on lintian.d.o generates false positives for this test. See https://lintian.debian.org/maintainer/sc...@kitterman.com.html#libnitrokey for an example. The line in the symbols file that's referenced for libnitrokey

Bug#956698: lintian: package-from-other-python-variant exception: python-pip-whl

Package: lintian Version: 2.65.0 Severity: normal The package python-pip-whl is a special case of a Python package built to work with either python or python3. Currently python3-vertualenv gets the following lintian warning: W: python3-virtualenv:

Bug#956698: lintian: package-from-other-python-variant exception: python-pip-whl

On Tuesday, April 14, 2020 9:22:37 AM EDT Mattia Rizzolo wrote: > On Tue, Apr 14, 2020 at 08:41:01AM -0400, Scott Kitterman wrote: > > The package python-pip-whl is a special case of a Python package built > > to work with either python or python3. Currently python3-vert

Bug#958666: lintian: please downgrade mailing-list-obsolete-in-debian-infrastructure warning

On Friday, April 24, 2020 12:08:46 PM EDT Shengjing Zhu wrote: > On Fri, Apr 24, 2020 at 11:44 PM gregor herrmann wrote: > [...] > > > > Could this wiki page be more useful? > > > https://wiki.debian.org/Salsa/AliothMigration#Import_mailing_list > > > > Not really; the lists we are talking

Bug#958182: mailing-list-obsolete-in-debian-infrastructure tag considered harmful

Thanks. I don't have a good solution to the overall problem. I'm mostly concerned about not having to fix packages with wrong maintainer addresses due to people trying to fix this 'issue'. Personally, I think it's inclusion is premature, but as long as the priority is lowered, I guess I can

Bug#958182: mailing-list-obsolete-in-debian-infrastructure tag considered harmful

... > lintian (2.67.0) unstable; urgency=medium > . >* Summary of tag changes: > + Added: ... >- mailing-list-obsolete-in-debian-infrastructure ... What is the recommended action to resolve this warning? For lists that aren't suitable to transition to lists.debian.org there

Bug#954763: lintian: Lintian should warn about use of py3versions -i in autopkgtests

Package: lintian Version: 2.59.0 Severity: normal Is recently discussed in a thread on debian-devel [1] there is a common error in python related auotpkgtests where py3verions -i is used to loop over 'installed' python3 versions. This is currently causing a substantial number of failures since

Bug#954819: lintian: Please update the old and ancient python-versions tags to warn about py3versions -r

@@ -1,3 +1,10 @@ +lintian (2.59.0+) UNRELEASED; urgency=medium + + * Update old and ancient python-version-field tag text to suggest also +checking for incorrect use of py3verions -r + + -- Scott Kitterman Mon, 23 Mar 2020 20:55:28 -0400 + lintian (2.59.0) unstable; urgency=medium [ Chris

Bug#961686: lintian: false positive: runtime-test-file-uses-supported-python-versions-without-python-all-build-depends

Package: lintian Severity: normal >From lintian.debian.org, so I don't know the lintian version: https://lintian.debian.org/sources/dkimpy/1.0.4-1.html among other things it says: W runtime-test-file-uses-supported-python-versions-without-python-all-build-depends debian/tests/py3

Bug#961686: lintian: false positive: runtime-test-file-uses-supported-python-versions-without-python-all-build-depends

On Wednesday, May 27, 2020 6:11:51 PM EDT you wrote: > Package: lintian > Severity: normal > > From lintian.debian.org, so I don't know the lintian version: > > https://lintian.debian.org/sources/dkimpy/1.0.4-1.html > > among other things it says: > > W >

Bug#1005184: lintian: package-does-not-install-examples should not look in tests

Package: lintian Version: 2.114.0 Severity: minor Currently on lintian.d.o the package-does-not-install-examples test is triggered for python-tomlkit because of files in [tests/examples/]. These aren't, in fact, examples for tomlkit, they are examples of TOML files used in the tests. I think

Bug#1005200: lintian: prefer-uscan-symlink should to single maintainer packages at most

Package: lintian Version: 2.114.0 Severity: minor The relatively new prefer-uscan-symlink tag suggests it's better to rely on a setting ~/.devscripts instead of using filenamemangle in debian/watch. It's not clear why this would be better in any case and the uscan man page that is referenced

Bug#1005184: marked as pending in lintian

On Tuesday, February 8, 2022 5:29:08 PM EST Felix Lechner wrote: > Control: tag -1 pending > > Hello, > > Bug #1005184 in lintian reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: >

Bug#1003913: lintian: False positive: package-contains-documentation-outside-usr-share-doc

Package: lintian Version: 2.114.0 Severity: normal For the current (from experimental, but will be in unstable shortly) build for python-nacl I get the following from lintian: I: python3-nacl: package-contains-documentation-outside-usr-share-doc

Bug#1025164: lintian: missing-prerequisite-for-pyproject-backend tag needs to check Build-Depends-Indep too

Package: lintian Version: 2.115.3 Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org The missing-prerequisite-for-pyproject-backend check appears to only look for the prerequisite packages in Build-Depends, but since they aren't needed for clean, they could be in Build-Depends-Indep,

Bug#1025164: lintian: missing-prerequisite-for-pyproject-backend tag needs to check Build-Depends-Indep too

On Wednesday, November 30, 2022 10:38:30 PM EST Stuart Prescott wrote: > Hi Scott, > > On 01/12/2022 02:16, Scott Kitterman wrote: > > Package: lintian > > Version: 2.115.3 > > Severity: normal > > X-Debbugs-Cc: debian-pyt...@lists.debian.org > > >

Bug#1032078: lintian: False positive for debian-watch-could-verify-download test

Package: lintian Version: 2.116.3+reprocess Severity: normal The UDD lintian report currently lists this warning as being applicable to dkimpy-milter [1], but the watch file does verify the download. I downloaded a new version yesterday and the signature was verified. The package's d/watch does