Processing commands for cont...@bugs.debian.org:
> reopen 884499
Bug #884499 {Done: Chris Lamb } [lintian] lintian: Pedantic
check for packages not using debhelper or CDBS
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be
Processing commands for cont...@bugs.debian.org:
> # Reopen the correct bug
> reopen 898091
Bug #898091 {Done: Chris Lamb } [lintian] lintian: Alter the
semantics (etc.) of --pedantic?
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions
Hi Helmut,
> No. I was pondering it on irc and it didn't seem immediately actionable
> to me. You wanted a bug report anyway and you got one.
(Sure, and that was appreciated so we didn't lose the idea and
context.)
> Is there really much point in discussing whether tool diversity is good?
>
On Fri, May 04, 2018 at 07:54:46PM +0100, Chris Lamb wrote:
> How did you get on with this? :)
No. I was pondering it on irc and it didn't seem immediately actionable
to me. You wanted a bug report anyway and you got one.
Is there really much point in discussing whether tool diversity is good?
clone 884499 -1
retitle -1 lintian: Alter the semantics (etc.) of --pedantic?
severity -1 wishlist
tags -1 + moreinfo
thanks
Hi Russ
> […]
At the very least lets not lose this conversation in a somewhat-
unrelated bug, hence cloning etc. Tagging as "moreinfo" for now.
> lintian --suggestions,
Processing commands for cont...@bugs.debian.org:
> clone 884499 -1
Bug #884499 {Done: Chris Lamb } [lintian] lintian: Pedantic
check for packages not using debhelper or CDBS
Bug 884499 cloned as bug 898091
> retitle -1 lintian: Alter the semantics (etc.) of --pedantic?
Bug
Chris Lamb writes:
> Y'know, I think we could make it even more effective if we renamed --
> pedantic at the same time. This would have the benefits of a)
> highlighting the change of semantics and b) we could perhaps choose a
> name that does not imply it is "just" another
Hi Russ,
> My modest proposal, and this is going to sound nuts so bear with me for a
> moment, would be to make it impossible to get pedantic tags and regular
> tags at the same time. If you use --pedantic, suppress all other tags.
Ooh, now that's an interesting concept. :) Let me run that over
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
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. zero output) only encourages our
Hi Russ & Scott,
> I'm not sure how one could possibly be more clear. If one's definition of
> lintian-clean includes --pedantic, one's definition of lintian-clean is,
> well, wrong.
There is no doubt that you are absolutely right in a technical sense
and maintainers should not be using
Scott Kitterman writes:
> Back in the debate about the python2 check (thanks for fixing), I made
> the point that not all lintian checks are created equal. Some represent
> serious package defects that needs to be addressed and some merely
> reflect the lintian
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
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 have no
basis in Policy? :)
(100% agree that there is no
Chris Lamb:
> tags 898077 + pending
> thanks
>
>> Lintian should perhaps check of there is a python package that meets the
>> dependency requirement? Or allow e.g. "*scour"?
>
> We can't do a wildcard (!) but we can also check for
> python-scour. I've done this in Git, pending upload:
>
>
>
tags 898077 + pending
thanks
> Lintian should perhaps check of there is a python package that meets the
> dependency requirement? Or allow e.g. "*scour"?
We can't do a wildcard (!) but we can also check for
python-scour. I've done this in Git, pending upload:
Processing commands for cont...@bugs.debian.org:
> tags 898077 + pending
Bug #898077 [lintian] lintian: False positive in
missing-build-dependency-for-dh-addon, python package
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
898077:
Package: lintian
Version: 2.5.55
Severity: normal
Dear Maintainer,
When building laditools, the missing-build-dependency-for-dh-addon lintian
warning is received because scour is not a build dependency when the scour dh
addon is used in debian/rules.
However, python-scour is a build dependency
18 matches
Mail list logo