Bug#999601: [false positive] ocaml-dangling-cmi hint needs refinement

[Julien Puydt]

Hi,

Le mardi 16 novembre 2021 à 06:35 -0800, Felix Lechner a écrit :
> 
> On Sat, Nov 13, 2021 at 1:15 AM Julien Puydt 
> wrote:
> > 
> > I hope this is precise enough to improve the hint.
> 
> We would like to test improvements. Would you please point to
> installable packages that triggered the false positives? Thanks!

I suggest only one, libcoq-ocaml-dev:

- it has the larger choice of strange examples of the issue -- at least
that I know of ;

- hopefully there only remains false positives since I checked for real
issues ;

- but you'll have to "lintian -Io" to get over my overriding the hint
for all __ files ;

- and you should (temporarily) remove the code which says "three
strikes and then only a count", because a list of three explicits and
then a hundred silents gets you only so far.

(About the last point: I could understand why I had so many of them
only when I pushed the limit of showns hints to 300: the complete list
made obvious the __ was the problem)

I can easily find more, but since I'm new to the team (and apparently
they weren't using lintian that much...), I haven't had my hands in
many of them, so there will be real positives... and we don't want to
fix that!

Thanks for looking into this,

J.Puydt

Bug#999602: [false positive] shared-library-lacks-prerequisites

[Julien Puydt]

Package: lintian
Version: 2.111.0
X-Debbugs-CC: debian-ocaml-ma...@lists.debian.org

The Coq project comes with a kind of compiler, and generates files that
are ELF shared objects ; as such they do get detected by lintian, and
it tries to analyse them just like normal C/C++ shared objects.

Unfortunately, they contain many undefined symbols, and it's expected,
so there are a lot of false positives.

Lintian should disable that hint for .cmxs files.

Cheers,

J.Puydt

Bug#999601: [false positive] ocaml-dangling-cmi hint needs refinement

[Julien Puydt]

Package: lintian
Version: 2.111.0
X-Debbugs-CC: debian-ocaml-ma...@lists.debian.org

A new build system is seeing increasing use in the OCaml world, and is
putting the above hint implementation out of its depth: dune.

The current implementation of the hint is that for each foo.cmi, there
should be a corresponding foo.ml or foo.mli. That is still essentially
correct. But with dune, you can also have double-underscored filenames,
and for those the situation is a little different:

- in the simpler and most current case, for foo__Bar.cmi, the
associated file to look for is bar.ml or bar.mli. Notice that you only
keep the part after the (last?) double-underscore, and you have to
lowercase it.

- there can be a foo__.cmi and a corresponding foo__.ml or foo__.mli

- I have seen an foo__BAR.cmi with a corrresponding BAR.ml or BAR.mli
(no lowercase...)

- and I have seen a .private/foo_Bar.cmi with a corresponding bar.ml or
bar.mli (not in .private).


I hope this is precise enough to improve the hint.

Cheers,

J.Puydt

Bug#995498: FP? missing-build-dependency-for-dh-addon python3

[Julien Puydt]

Package: lintian
Version: 2.107.0
Severity: normal

Updating the python-anyio package, lintian complained quite vehemently
(an error):

E: python-anyio source: missing-build-dependency-for-dh-addon python3
=> python3:any | python3-all:any | python3-dev:any | python3-all-
dev:any | dh-sequence-python3

but in d/control:
Build-Depends: debhelper-compat (= 13),
   dh-python,
   python3,
   python3-hypothesis ,
   python3-pip,
   python3-setuptools,
   python3-setuptools-scm,
   python3-sniffio,
   python3-pytest (>= 6.2.5) ,
   python3-pytest-mock (>= 1.11.1) ,
   python3-trustme ,
   python3-uvloop 

so I think it's a false positive.

If it's not, both lintian's output and the error description in
/usr/share/lintian/tags/m/missing-build-dependency-for-dh-addon.tag
fail to explain what the matter really is.

Cheers,

J.Puydt

Bug#993758: source-includes-file-in-files-excluded should be smarter

[Julien Puydt]

Le dimanche 05 septembre 2021 à 22:57 -0700, Felix Lechner a écrit :
> 
> On Sun, Sep 5, 2021 at 10:54 PM Julien Puydt 
> wrote:
> > 
> > I have a javascript package
> 
> Which package, please?

node-rollup-plugin-node-resolve (but the salsa version might not be up
to date yet).

> > and that makes lintian go postal.
> 
> Please provide program output, or perhaps an illustrative part of it.

Well, the program output is hundreds of:
E: node-rollup-plugin-node-resolve source: source-includes-file-in-
files-excluded foo/stuff

because Files-Included lists the foo directory as included just after
Files-Excluded said *...

Cheers,

J.Puydt

Bug#993758: source-includes-file-in-files-excluded should be smarter

[Julien Puydt]

Package: lintian
Version: 2.104.0
Severity: wishlist

The source-includes-file-in-files-excluded error should be made
smarter. I have a javascript package where most of the upstream tarball
is garbage, so d/copyright reads:

Files-Excluded: *
Files-Included: very short list

and that makes lintian go postal.

It really should filter out the errors for files which have been
excluded then included.

Cheers,

J.Puydt

Bug#972614: False positive for package-does-not-install-examples

[Julien Puydt]

Le mercredi 11 novembre 2020 à 04:35 -0800, Felix Lechner a écrit :
> On Wed, Nov 11, 2020 at 12:13 AM Julien Puydt  > wrote:
> > You use -3 and I packaged and used -4 in my report :
> 
> Thanks for clarifying. Unfortunately, that version does not produce
> any tags whatsoever.

I run lintian 2.101.0, on node-posix-getopt 1.2.0+20150728-4.

Cheers,

JP

Bug#972614: False positive for package-does-not-install-examples

[Julien Puydt]

Le mardi 10 novembre 2020 à 03:49 -0800, Felix Lechner a écrit :
> Hi Julien,
> 
> On Mon, Nov 9, 2020 at 10:00 PM Julien Puydt 
> wrote:
> > P: node-posix-getopt source: package-does-not-install-examples
> > debian/examples
> > P: node-posix-getopt source: package-does-not-install-examples
> > examples/
> 
> Thanks for including a package name; we cannot investigate without.
> Alas, I cannot reproduce the tag you see:
> 
> ./bin/lintian --pedantic
> /mirror/debian/pool/main/n/node-posix-getopt/node-posix-
> getopt_1.2.0+20150728-3.dsc
> /mirror/debian/pool/main/n/node-posix-getopt/node-posix-
> getopt_1.2.0+20150728-3_all.deb
> I: node-posix-getopt source: older-debian-watch-file-standard 3

You use -3 and I packaged and used -4 in my report :

$ lintian -I --pedantic node-posix-getopt_1.2.0+20150728-4.dsc
P: node-posix-getopt source: package-does-not-install-examples
debian/examples
P: node-posix-getopt source: package-does-not-install-examples
examples/

Cheers,

JP

Bug#972614: False positive for package-does-not-install-examples

[Julien Puydt]

Hi,

I was about to report the same thing when I saw Xavier already filed
this bug ; here is another example, with a nice twist :

P: node-posix-getopt source: package-does-not-install-examples
debian/examples
P: node-posix-getopt source: package-does-not-install-examples
examples/

It complains about not installing two things, when the first is
precisely the file making the content of the second installed!

Cheers,

JP

Bug#971973: Shouldn't look into quilt's .pc/ directory

[Julien Puydt]

Package: lintian
Version: 2.97.0

This evening, while trying to update my giac package, I got :

E: giac source: source-is-missing .pc/d-dont-include-remote-
scripts.patch/doc/xcas.js line length is 467 characters (>256)

which means lintian had a look into .pc/ : this directory should be
excluded, as it contains copies of source files... which are the ones
for which the report would be meaningful.

Cheers,

JP

Bug#970306: unused-license-paragraph-in-dep5-copyright is a false positive when "+" is involved

[Julien Puydt]

Package: lintian
Version: 2.14.0
Severity: minor

I get many unused-license-paragraph-in-dep5-copyright I:-type messages
from lintian, because the paragraphs in question are License: foo and
used as License: foo+. Lintian should see that it's compatible and
accept it.

I hope that helps,

JP

Bug#906284: CC0 is short

[Julien Puydt]

Hi,

On 27/08/2018 19:09, Chris Lamb wrote:


Thanks for that. Do you happen to have some "bad" ones handy too?


I don't have anything handy, but I remembered : when I packaged 
minetest-mod-unified-inventory and found it used CC0, I used 
codesearch.debian.net, to find other packages where CC0 was used.


So perhaps it's possible to use codesearch.d.n to find bad examples too, 
by looking at a known-wrong expression in path:debian/copyright? I 
naively searched "only some of the key features" and "not a license and 
has no legal value" found only the source of the lintian check in which 
I already took the words anyway.


Does that check actually detect anything?

jpuydt on irc.debian.org

Bug#906284: Too many false positives?

[Julien Puydt]

Hi,

in my previous mail, I asked if that test was worth anything.

It's possible to know what packages trigger the test:
https://lintian.debian.org/tags/incomplete-creative-commons-license.html

I had a look from the start of the list (took the 20 first), and found 
only 4 where I would say it's a real positive:


https://sources.debian.org/src/3depict/0.0.19-1/debian/copyright/ (lines 
9-20)


https://sources.debian.org/src/astromenace-data/1.3.2+repack-3/debian/copyright/ 
(lines 34-43)


https://sources.debian.org/src/audacity/2.2.2-1/debian/copyright/
(lines 2146-2149).

https://sources.debian.org/src/bibletime/2.11.1-1/debian/copyright/ 
(lines 45-59)


I have a bad opinion on a test with so many false positives : that means 
people will learn to ignore it and even the few problems it catches will 
get overlooked!


Perhaps just looking at the size of the license text (say < 20 lines) 
would work better? I don't know perl at all, so I can't help write it, 
but I would be quite surprised if that wasn't easy to do for someone 
with a minimal knowledge of the language and the codebase.


I hope it helps,

jpuydt on irc.debian.org

Bug#906284: CC0 is short

[Julien Puydt]

On 27/08/2018 15:36, Chris Lamb wrote:

Julian et al.,


if ($full_license and $short_license =~ m/cc-/) {
 if ($full_license !~ /definitions/i and
 $full_license !~ /copyright and related rights/i and
 $full_license !~ m%/usr/share/common-licenses/CC) {
 tag 'incomplete-creative-commons-license';
 }
}


Apply to apply this, but before I do can you supply some "known good"
and "known bad" texts? That way I can supplement our testsuite..

best wishes,


I'm not 100% sure my test is "known good", but here it is:

License: CC0
 To the extent possible under law, the author(s) have dedicated all 
copyright

 and related and neighboring rights to this software to the public domain
 worldwide. This software is distributed without any warranty.
 .
 You should have received a copy of the CC0 Public Domain Dedication 
along with
 this software. If not, see 
.


Cheers,

jpuydt on irc.debian.org

Bug#906284: CC0 is short

[Julien Puydt]

Hi,

the following also triggers the check, and I think it's a false 
positive, and would still be even with the proposed change:


License: CC0
 To the extent possible under law, the author(s) have dedicated all 
copyright

 and related and neighboring rights to this software to the public domain
 worldwide. This software is distributed without any warranty.
 .
 You should have received a copy of the CC0 Public Domain Dedication 
along with
 this software. If not, see 
.



If it's legit, I'll fix :-)

Cheers,

jpuydt on irc.debian.org

Bug#873096: Now nodejs provides node

[Julien Puydt]

Package: lintian
Version: 2.5.52
Severity: wishlist

Hi,

since a recent decision of the technical comity, the nodejs package
provides /usr/bin/node, in addition to /usr/bin/nodejs for backward
compatibility.

It would be nice if lintian were warning about nodejs uses in script
(and in particular in debian/tests/).

Thanks,

Snark on #debian-js

Bug#872699: Now nodejs also provides node

[Julien Puydt]

Package: lintian
Version: 2.5.52
Severity: minor

Since a recent decision of the technical comity, the nodejs package is
providing /usr/bin/node, while still providing /usr/bin/nodejs during a
transition period.

It would be nice if lintian could recognize this new interpreter name as
being correct ; for now I get :

W: node-regjsparser: unusual-interpreter
usr/lib/nodejs/regjsparser/bin/parser #!node

for a package I'm preparing.

Thanks,

Snark on #debian-js