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
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
> >
>
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, le
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:
>
>
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 does
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 that
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
usr/lib/python3/dist-packages/PyNaCl-1.5.0.dist-in
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
> runtime-test-file-uses-supported-pytho
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 py3versions
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 about
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 l
...
> 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 isn
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-vertuale
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:
python-package-depends-on-package-from-other-py
5:28.0 -0400
@@ -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
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 th
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
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
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
lintia
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 th
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
>
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 portable
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 python3
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 thi
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 t
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 thi
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 the
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 effectivenes
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
interest. 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 Ki
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 signature,
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, it
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 depended
On Monday, May 07, 2018 01:35:30 PM Russ Allbery wrote:
> Scott Kitterman writes:
> > Package: lintian
> > Version: 2.5.85
> > Severity: normal
> >
> > Also, please reduce the certainty from certain. It's not.
> >
> > I'd just noticed depe
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 wron
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 addition of an objective
>target
>> (ie. z
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 checks in Lintian that
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
>
> checks/debhelper.desc
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
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
>
> This seems a little s
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
> dok
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 release
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 from
On January 14, 2018 8:12:00 AM UTC, Niels Thykier wrote:
>Scott Kitterman:
>> Package: lintian
>> Version: 2.5.68
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> When new-package-should-not-package-python2-module appears on
>lintian.d.o, it
>&
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
On January 7, 2018 5:25:21 PM UTC, Mattia Rizzolo 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 ported to python3 in
On Thursday, January 04, 2018 09:02:10 AM Chris Lamb wrote:
> tags 886303 + wontfix
> thanks
>
> Hi Scott,
>
> > There is no python3-qscintilla2, but there is python3-pyqt4.qsci
>
> Getcha. However, this doesn't seem like a common case and weakening
> the general case & making it a little more m
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 pytho
On Friday, September 30, 2016 05:01:00 PM Niels Thykier wrote:
> On Wed, 06 Jul 2016 00:30:08 -0400 Scott Kitterman
>
> wrote:
> > [...]
> >
> > If that's the case, then it's premature before the freeze. Python2.7 is
> > 'supported' through t
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 from being
> packaged
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 in
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 keep
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 configur
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? Co
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
Pyth
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 '^.*-d
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 vehicle
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 of
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.
-
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, 'ha
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 can
Package: lintian
Version: 1.24.2
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since any file in /opt will already trigger the Error dir-or-file-in-opt,
also firing off the Warning file-in-unusual-dir seems redundant and
distracting.
- -- System Information:
Debian Release: lenn
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 the
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 cur
64 matches
Mail list logo