Bug#575661: lintian: manpage-has-errors-from-man "Invalid or incomplete multibyte or wide character" when OK.

[Osamu Aoki]

Package: lintian
Version: 2.3.4
Severity: normal

I think lintian is wrong in testing encoding issue for manapage.  I have
installed hello-debhelper (2.5-1).  then I downloaded its binary package
hello-debhelper_2.5-1_amd64.deb and extracted to hello.1 into a working
directry.  

In short, instead of using complicated test, it should use iconv for encoding
test.

Let me show this problem.

First hello-debhelper package installed manpage shows OK under both
LANG=C and LANG=en_US.UTF-8.  I tested it with
 $ LANG=C man hello
 $ LANG=en_US.UTF-8 man hello

The only difference is copyright line.  LANG=C shows copuright as (C)
while UTF-8 uses fancy ©.  No problem.

But

$ lintian -i hello-debhelper_2.5-1_amd64.deb 
W: hello-debhelper: manpage-has-errors-from-man usr/share/man/man1/hello.1.gz  
Invalid or incomplete multibyte or wide character
N: 
N:This man page provokes warnings or errors from man.
N:
N:"cannot adjust" or "can't break" are trouble with paragraph filling,
N:usually related to long lines. Adjustment can be helped by left
N:justifying, breaks can be helped with hyphenation, see "Manipulating
N:Filling and Adjusting" and "Manipulating Hyphenation" in the manual.
N:
N:"can't find numbered character" usually means latin1 etc in the input,
N:and this warning indicates characters will be missing from the output.
N:You can change to escapes like \[:a] described on the groff_char man
N:page.
N:
N:Other warnings are often formatting typos, like missing quotes around a
N:string argument to .IP. These are likely to result in lost or malformed
N:output. See the groff_man (or groff_mdoc if using mdoc) man page for
N:information on macros.
N:
N:This test uses man's --warnings option to enable groff warnings that
N:catch common mistakes, such as putting . or ' characters at the start of
N:a line when they are intended as literal text rather than groff
N:commands. This can be fixed either by reformatting the paragraph so that
N:these characters are not at the start of a line, or by adding a
N:zero-width space (\&) immediately before them.
N:
N:At worst, warning messages can be disabled with the .warn directive, see
N:"Debugging" in the groff manual.
N:
N:To test this for yourself you can use the following command:
N: LANG=C MANWIDTH=80 man --warnings -E UTF-8 -l manpage-file >/dev/null
N:
N:Severity: normal, Certainty: certain
N:
$ LANG=C MANWIDTH=80 man --warnings -E UTF-8 -l hello.1 >hello.txt
col: Invalid or incomplete multibyte or wide character
$ iconv -f utf8 -t utf8 hello.1 >/dev/null && echo "UTF-8 compatible" || echo 
"non-UTF-8 found"
UTF-8 compatible
$ iconv -f ascii -t ascii hello.1 >/dev/null && echo "ascii compatible" || echo 
"non-ascii found"
ascii compatible

The first test is the one used by lintian.  Second and third test is mine to
check encoding of source code itself.

$ LANG=C   MANWIDTH=80 man --warnings  -l hello.1 >hello.c.txt
$ LANG=en_US.UTF-8 MANWIDTH=80 man --warnings -E UTF-8 -l hello.1 >hello.u.txt
$ LANG=C   MANWIDTH=80 man --warnings -E UTF-8 -l hello.1 >hello.cu.txt
col: Invalid or incomplete multibyte or wide character
$ ls -l hello.*.txt
-rw-rw-r-- 1 osamu osamu 1417 Mar 28 09:21 hello.c.txt
-rw-rw-r-- 1 osamu osamu0 Mar 28 09:53 hello.cu.txt
-rw-rw-r-- 1 osamu osamu 1418 Mar 28 09:21 hello.u.txt
$ diff -u hello.*.txt
--- hello.c.txt 2010-03-28 09:21:07.0 +0900
+++ hello.u.txt 2010-03-28 09:21:26.0 +0900
@@ -32,7 +32,7 @@
General help using GNU software: 

 COPYRIGHT
-   Copyright  (C) 2010 Free Software Foundation, Inc.  License GPLv3+: GNU
+   Copyright  ©  2010  Free Software Foundation, Inc.  License GPLv3+: GNU
GPL version 3 or later 
This is free software: you are free  to  change  and  redistribute  it.
There is NO WARRANTY, to the extent permitted by law.

The corresponding groff source has "\co" as in

Copyright \(co 2010 Free Software Foundation, Inc.

This is embedded nroff which is handled OK for both locale.

So the situation is clear.  There is no non-ASCII code in the source of
manpage.  Its manpage can be interpretted proprly with current tool set.

But test used by lintian breaks on groff copyright mark code.

I made hellox.1 in which "\co" is replaced with UTF-8 "©".  This is real error 
:-)

$ iconv -f ascii -t ascii hellox.1 >/dev/null && echo "ascii compatible" || 
echo "non-ascii found"
iconv: illegal input sequence at position 828
non-ascii found
$ iconv -f utf8 -t utf8 hellox.1 >/dev/null && echo "UTF-8 compatible" || echo 
"non-UTF-8 found"
UTF-8 compatible
$ LANG=C   MANWIDTH=80 man --warnings -E UTF-8 -l hellox.1 
>hellox.cu.txt
col: Invalid or incomplete multibyte or wide character
$ LANG=en_US.UTF-8 MANWIDTH=80 man --warnings -E UTF-8 -l hellox.1 >hellox.u.txt
$ LANG=C 

Bug#567485: [checks/lintian] changed-by-name-missing is not Severity: serious

[Jean-Christophe Dubacq]

clone 567485 -1
reassign -1 debian-policy
retitle -1 Clarify that Changed-By must have name and email address
severity -1 wishlist
tags -1 =
thanks
On 20/03/2010 23:51, Russ Allbery wrote:
> tags 567485 wontfix
> thanks
> 
> Jean-Christophe Dubacq  writes:
> 
>> Though the check is correct, it should not be severity serious: the
>> format of the Changed-By (and the Maintainer field) is not mandated by a
>> MUST, only a SHOULD.
> 
> I don't agree for two reasons:
> 
> * maintainer-name-missing and uploader-name-missing are both automatic
>   rejects in the ftp-master checks, which makes them automatically
>   severity: serious in Lintian.  That's not the specific one that you're
>   asking about, but that's the rule that Changed-By references.
> 
> * The Policy description for Changed-By says "The name and email address
>   of the person who changed the said package."  That's not a should.
>   That's a statement of what that field shall include, which means that if
>   it doesn't have the name and e-mail address, it's a syntax error and
>   therefore is a violation of an implicit must.
> 
> I see where your reading is coming from, but suspect the best fix is to
> just change the Policy wording to make it clear that this is a must.
> There's really no reason to use a different format, and Debian elsewhere
> already requires names.

Then let's reassign to debian-policy.


-- 
Jean-Christophe Dubacq



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bae671f.4040...@free.fr

¡Ven y únete a Media Naranja!

[Hector Valle]

Media Naranja: Alguien te está esperando...


¡Ven y únete el Media Naranja!

Hector Valle

Haz clic en el vínculo siguiente para participar:
http://tunaranja.ning.com/?xgi=12K8sG7JOBT69Y&xg_source=msg_invite_net

If your email program doesn't recognize the web address above as an active link,
please copy and paste it into your web browser



Ya son miembros el Media Naranja
Fernando Reyes, Williams Montoya Jimenez, kouassi richard, michele castro, 
maritza guadalupe dominguez.



Sobre Media Naranja
Media Naranja es el lugar de moda para conocer nuevos amigos.
No es un lugar de contactos.
Recomendamos leer las normas.

3962 miembros 
1408 fotos 
231 videos
20 discusiones
50 entradas de blog



Para controlar los emails que recibes en la esquina, o para salirte, ve a:
http://tunaranja.ning.com/?xgo=aUUmZioM7dyrcHc8IOotKj844v-MH4pGkdXWSMIN7kIlUo1Y90HeGdlnq5gzZzkT&xg_source=msg_invite_net

Processed: Re: Bug#567485: [checks/lintian] changed-by-name-missing is not Severity: serious

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> clone 567485 -1
Bug#567485: [checks/lintian] changed-by-name-missing is not Severity: serious
Bug 567485 cloned as bug 575639.

> reassign -1 debian-policy
Bug #575639 [lintian] [checks/lintian] changed-by-name-missing is not Severity: 
serious
Bug reassigned from package 'lintian' to 'debian-policy'.
Bug No longer marked as found in versions lintian/2.3.1.
> retitle -1 Clarify that Changed-By must have name and email address
Bug #575639 [debian-policy] [checks/lintian] changed-by-name-missing is not 
Severity: serious
Changed Bug title to 'Clarify that Changed-By must have name and email address' 
from '[checks/lintian] changed-by-name-missing is not Severity: serious'
> severity -1 wishlist
Bug #575639 [debian-policy] Clarify that Changed-By must have name and email 
address
Severity set to 'wishlist' from 'normal'

> tags -1 =
Bug #575639 [debian-policy] Clarify that Changed-By must have name and email 
address
Removed tag(s) wontfix.
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.12697208763170.transcr...@bugs.debian.org

Bug#575633: lintian: does not find source if *.orig.tar.xz is used

[Andreas Beckmann]

Package: lintian
Version: 2.3.4
Severity: normal

Hi,

lintian fails to open an .orig.tar.xz tarball, probably lack of support
for the new compression scheme:

internal error: could not find the source tarball
warning: could not unpack package to desired level


Andreas

Just playing around with new possibilities :-)


-- System Information:
Debian Release: squeeze/sid
  APT prefers stable
  APT policy: (800, 'stable'), (700, 'testing'), (600, 'unstable'), (130, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.20.1-2  The GNU assembler, linker and bina
ii  diffstat   1.47-1produces graph of changes introduc
ii  dpkg-dev   1.15.5.6  Debian package development tools
ii  file   5.04-1Determines file type using "magic"
ii  gettext0.17-10   GNU Internationalization utilities
ii  intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libapt-pkg-perl0.1.24Perl interface to libapt-pkg
ii  libclass-accessor-perl 0.34-1Perl module that automatically gen
ii  libipc-run-perl0.84-1Perl module for running processes
ii  libparse-debianchangel 1.1.1-2   parse Debian changelogs and output
ii  libtimedate-perl   1.2000-1  collection of modules to manipulat
ii  liburi-perl1.52-1module to manipulate and access UR
ii  locales2.10.2-6  Embedded GNU C Library: National L
ii  man-db 2.5.7-2   on-line manual pager
ii  perl [libdigest-sha-pe 5.10.1-11 Larry Wall's Practical Extraction 

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch2.20.1-2   Binary utilities that support mult
pn  libtext-template-perl  (no description available)
ii  man-db2.5.7-2on-line manual pager

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100327195145.3077.39963.report...@calzone.localnet

Bug#575447: [Fwd: Re: Bug#575447: lintian: Please add a warning in a .jar is not in /usr/share/java/]

[Niels Thykier]

I see I accidentally failed to send this to the bug report

 Original Message 
Subject: Re: Bug#575447: lintian: Please add a warning in a .jar is not
in /usr/share/java/
Date: Thu, 25 Mar 2010 22:49:05 +0100
From: Niels Thykier 
To: Sylvestre Ledru 
References: <4babcb51.9080...@thykier.net>
<1269550852.5310.262.ca...@zlarin>

Sylvestre Ledru wrote:
> Le jeudi 25 mars 2010 à 21:45 +0100, Niels Thykier a écrit :
>> Hi
>>
>> I am not sure I can support this. There has been an interest in allowing
>> a package to install "private" jar files in /usr/share//.
>>
>> Though jar files beneath /usr/lib/ is *usually* a problem (the swt jars
>> are known exceptions). Though I think these are so rare that an override
>> is in order for these. Adding a warning for jars beneath /usr/lib/ will
>> cause a warning explosion in eclipse, but I am okay with that! I suspect
>> quite a few of them can be moved to /usr/share/ and a lintian warning
>> will serve as a good reminder of that.
> I am not sure to follow you. In the first paragraph, you say you do not
> agree and in the second, reading between the lines, I have the feeling
> you think it might be relevant. Am I wrong ?
> 

Hi

I agree with the need for a warning for jars being in weird places, but
I disagree that a jar file beneath "/usr/share//" should trigger a
warning (e.g I am okay with a warning for anywhere but /usr/share/java
and /usr/share//).
  Consider (e.g.) ant uses symlinks from /usr/share/ant/lib/ into
/usr/share/java/, so /usr/share/ (and beneath) should definitely be
allowed.
  Though there are more valid exceptions: maven has a public
"repository" that packages are encouraged to install their jars in (or
symlinks to them) beneath /usr/share/maven-repo.

The second paragraph was more informational to say that we have rare
cases where /usr/lib/java or /usr/lib/ is the correct location for
a jar-file (e.g. when storing native pointers in java code).
  Though I believe these to be so rare that it would be acceptable to
force packages legally shipping jars beneath /usr/lib/ to add an override.

That being said. Java Virtual Machines are allowed to ship jar files
beneath /usr/lib/jvm/${dir}/ (${dir} does not equal package name).

Also, I think we should allow a symlink in /usr/lib/ to point to a jar
file in a valid location beneath /usr/share. Java projects usually do
not care about "correct file system layouts" - patching all ~1638 jars
to respect FHS is not just not feasible [1]!

> BTW, I am just asking for a warning, not an error ;)
> 
> Sylvestre
> 

Actually, I think jars beneath /usr/lib/ might be good candidate for an
error (that can be overridden). Java is supposed to be arch:all and thus
so should jar files. Personally I only know one valid exception
(swt.jar)[2].

~Niels

[1] Generated via:
apt-file search .jar | grep -v /usr/share/java | grep -v /usr/lib/jvm |
grep -E .jar\$ | grep -v /usr/share | wc -l

The number may be inflated since I get data from testing and unstable
and some of these may just be symlinks.

[2] Though due to symlinks, this may trigger more than one warning/error.





signature.asc
Description: OpenPGP digital signature

Bug#575590: lintian: python-script-but-no-python-dep when using /usr/bin/python2.6 and Depending on python2.6

[Arto Jantunen]

Russ Allbery  writes:

> Arto Jantunen  writes:
>
>> Python-support generates python (>= 2.6) | python2.6 for this case
>> (which is partially broken since the scripts get /usr/bin/python2.6
>> which wouldn't be provided by 2.7 etc), maybe that is different from
>> just depending on 2.6?
>
> Ah, yes.  Lintian would correctly diagnose that bug in python-support,
> since python2.7 (or python3.0) won't provide the /usr/bin/python2.6
> binary.
>
>> Anyway, the package I see the problem with is available at
>> http://viiru.iki.fi/debian/bcfg2/
>
> I'm not getting this tag for that *.deb file with Lintian 2.3.4, and the
> Depends don't have the alternative that you describe:
>
> Depends: python2.6, python-support (>= 0.90.0), debsums, python-apt,
>  python-lxml (>= 0.9), ucf, lsb-base (>= 3.1-9),
>  python-m2crypto | python (>= 2.6)
>
> The python2.6 dependency is unconditional, and indeed Lintian doesn't
> warn.

For bcfg2 that is the case, but bcfg2-server gets the conditional
depends and lintian warns. Interresting that those are different,
btw. 

Hmm. I need to figure out why the two packages from the same source
get different results for python:Depends, but a bug in python-support
does seem quite likely.

This bugreport should probably be considered a false positive itself,
even though the tag lintian reports in this case is somewhat
misleading.

-- 
Arto Jantunen



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5n5bqp4@viiru.iki.fi

Bug#575590: lintian: python-script-but-no-python-dep when using /usr/bin/python2.6 and Depending on python2.6

[Russ Allbery]

Arto Jantunen  writes:

> For bcfg2 that is the case, but bcfg2-server gets the conditional
> depends and lintian warns. Interresting that those are different,
> btw. 

Doh.  I'm remarkably blind this morning.

> Hmm. I need to figure out why the two packages from the same source
> get different results for python:Depends, but a bug in python-support
> does seem quite likely.

Yeah, that's odd, particularly since they boht contain modules and they're
both architecture-independent.

> This bugreport should probably be considered a false positive itself,
> even though the tag lintian reports in this case is somewhat
> misleading.

I can try to improve the wording.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4sx4ppd@windlord.stanford.edu

Bug#575590: lintian: python-script-but-no-python-dep when using /usr/bin/python2.6 and Depending on python2.6

[Russ Allbery]

Arto Jantunen  writes:

> Python-support generates python (>= 2.6) | python2.6 for this case
> (which is partially broken since the scripts get /usr/bin/python2.6
> which wouldn't be provided by 2.7 etc), maybe that is different from
> just depending on 2.6?

Ah, yes.  Lintian would correctly diagnose that bug in python-support,
since python2.7 (or python3.0) won't provide the /usr/bin/python2.6
binary.

> Anyway, the package I see the problem with is available at
> http://viiru.iki.fi/debian/bcfg2/

I'm not getting this tag for that *.deb file with Lintian 2.3.4, and the
Depends don't have the alternative that you describe:

Depends: python2.6, python-support (>= 0.90.0), debsums, python-apt,
 python-lxml (>= 0.9), ucf, lsb-base (>= 3.1-9),
 python-m2crypto | python (>= 2.6)

The python2.6 dependency is unconditional, and indeed Lintian doesn't
warn.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878w9d65tz@windlord.stanford.edu

Re: lintian check on virtualbox-ose

[Russ Allbery]

Russ Allbery  writes:
> Michael Meskes  writes:

>> Besides these errors seem to be wrong as all the libraries lintian moans
>> about are in a private directory. Or what am I missing?

> Lintian doesn't know that /usr/lib/virtualbox is a valid private directory
> for a package named virtualbox-ose.  It's very literal about that sort of
> thing.  It wouldn't complain about /usr/lib/virtualbox-ose.

Hm, that being said, it should also allow rpath pointing to any directory
included in the package, and if I run the current Lintian against the
virtualbox-ose package on i386, I also don't see this problem.

It may be that this report on lintian.d.o is old, although there hasn't
been a relevant change to Lintian in quite some time.  I'm puzzled.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zl1t4qfq@windlord.stanford.edu

Bug#575590: lintian: python-script-but-no-python-dep when using /usr/bin/python2.6 and Depending on python2.6

[Arto Jantunen]

Russ Allbery  writes:

> Arto Jantunen  writes:
>> That package isn't yet in the archive, but as I see it any
>> python-support using package should do for a test case. Just set
>> debian/pyversions to 2.6-, build-dep on python2.6, Depend on
>> ${python:Depends} and this happens.
>
> I can't duplicate this.  A script starting with #!/usr/bin/python2.6
> produces no warnings in a package that depends on python2.6 for me.
>
> Could you put a package exhibiting this problem somewhere where I can take
> a look at it?

Python-support generates python (>= 2.6) | python2.6 for this case
(which is partially broken since the scripts get /usr/bin/python2.6
which wouldn't be provided by 2.7 etc), maybe that is different from
just depending on 2.6?

Anyway, the package I see the problem with is available at
http://viiru.iki.fi/debian/bcfg2/

-- 
Arto Jantunen



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y6hdbt3q@viiru.iki.fi

Re: lintian check on virtualbox-ose

[Russ Allbery]

Michael Meskes  writes:

> could you tell me which options you use when running lintian on
> virtualbox-ose?  I cannot get lintian to spit put all these
> binary-or-shlib-defines-rpath errors when running it locally.

Lintian isn't run with any special flags on lintian.d.o other than the
flags to show all tags (which aren't relevant here).  It is run on i386
packages, though, which can make a difference.

> Besides these errors seem to be wrong as all the libraries lintian moans
> about are in a private directory. Or what am I missing?

Lintian doesn't know that /usr/lib/virtualbox is a valid private directory
for a package named virtualbox-ose.  It's very literal about that sort of
thing.  It wouldn't complain about /usr/lib/virtualbox-ose.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874ok165pp@windlord.stanford.edu

lintian check on virtualbox-ose

[Michael Meskes]

Hi,

could you tell me which options you use when running lintian on virtualbox-ose?
I cannot get lintian to spit put all these binary-or-shlib-defines-rpath errors
when running it locally. Besides these errors seem to be wrong as all the
libraries lintian moans about are in a private directory. Or what am I missing?

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100327163835.ga4...@feivel.credativ.lan

Bug#575590: lintian: python-script-but-no-python-dep when using /usr/bin/python2.6 and Depending on python2.6

[Russ Allbery]

Arto Jantunen  writes:

> I'm positive:

> vi...@tsunami:~/debian/work$ lintian --version
> Lintian v2.3.4
> vi...@tsunami:~/debian/work$ lintian bcfg2_1.0.1-1_amd64.changes 
> W: bcfg2-server: binary-without-manpage usr/sbin/bcfg2-ping-sweep
> W: bcfg2-server: binary-without-manpage usr/sbin/bcfg2-reports
> E: bcfg2-server: python-script-but-no-python-dep
> ./usr/sbin/bcfg2-admin
> E: bcfg2-server: python-script-but-no-python-dep
> ./usr/sbin/bcfg2-build-reports
> E: bcfg2-server: python-script-but-no-python-dep ./usr/sbin/bcfg2-info
> E: bcfg2-server: python-script-but-no-python-dep
> ./usr/sbin/bcfg2-ping-sweep
> E: bcfg2-server: python-script-but-no-python-dep
> ./usr/sbin/bcfg2-repo-validate
> E: bcfg2-server: python-script-but-no-python-dep
> ./usr/sbin/bcfg2-reports
> E: bcfg2-server: python-script-but-no-python-dep
> ./usr/sbin/bcfg2-server
> zsh: exit 1 lintian bcfg2_1.0.1-1_amd64.changes
> vi...@tsunami:~/debian/work$

> That package isn't yet in the archive, but as I see it any
> python-support using package should do for a test case. Just set
> debian/pyversions to 2.6-, build-dep on python2.6, Depend on
> ${python:Depends} and this happens.

I can't duplicate this.  A script starting with #!/usr/bin/python2.6
produces no warnings in a package that depends on python2.6 for me.

Could you put a package exhibiting this problem somewhere where I can take
a look at it?

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87tys1687y@windlord.stanford.edu

Bug#575590: lintian: python-script-but-no-python-dep when using /usr/bin/python2.6 and Depending on python2.6

[Arto Jantunen]

Russ Allbery  writes:

> Arto Jantunen  writes:
>
>> Package: lintian
>> Version: 2.3.4
>> Severity: normal
>
>> False positives as described in the subject. Possibly 2.6 is missing
>> from the regexp used by this check?
>
> Are you positive you're using 2.3.4?  I added 2.6 in that version.

I'm positive:

vi...@tsunami:~/debian/work$ lintian --version
Lintian v2.3.4
vi...@tsunami:~/debian/work$ lintian bcfg2_1.0.1-1_amd64.changes 
W: bcfg2-server: binary-without-manpage usr/sbin/bcfg2-ping-sweep
W: bcfg2-server: binary-without-manpage usr/sbin/bcfg2-reports
E: bcfg2-server: python-script-but-no-python-dep
./usr/sbin/bcfg2-admin
E: bcfg2-server: python-script-but-no-python-dep
./usr/sbin/bcfg2-build-reports
E: bcfg2-server: python-script-but-no-python-dep ./usr/sbin/bcfg2-info
E: bcfg2-server: python-script-but-no-python-dep
./usr/sbin/bcfg2-ping-sweep
E: bcfg2-server: python-script-but-no-python-dep
./usr/sbin/bcfg2-repo-validate
E: bcfg2-server: python-script-but-no-python-dep
./usr/sbin/bcfg2-reports
E: bcfg2-server: python-script-but-no-python-dep
./usr/sbin/bcfg2-server
zsh: exit 1 lintian bcfg2_1.0.1-1_amd64.changes
vi...@tsunami:~/debian/work$

That package isn't yet in the archive, but as I see it any
python-support using package should do for a test case. Just set
debian/pyversions to 2.6-, build-dep on python2.6, Depend on
${python:Depends} and this happens.

-- 
Arto Jantunen



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739zlde4f@viiru.iki.fi

Bug#575590: lintian: python-script-but-no-python-dep when using /usr/bin/python2.6 and Depending on python2.6

[Russ Allbery]

Arto Jantunen  writes:

> Package: lintian
> Version: 2.3.4
> Severity: normal

> False positives as described in the subject. Possibly 2.6 is missing
> from the regexp used by this check?

Are you positive you're using 2.3.4?  I added 2.6 in that version.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hbo17tgh@windlord.stanford.edu

Bug#575590: lintian: python-script-but-no-python-dep when using /usr/bin/python2.6 and Depending on python2.6

[Arto Jantunen]

Package: lintian
Version: 2.3.4
Severity: normal


False positives as described in the subject. Possibly 2.6 is missing from the 
regexp used by this check?

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.33.1 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.20.1-3  The GNU assembler, linker and bina
ii  diffstat   1.47-1produces graph of changes introduc
ii  dpkg-dev   1.15.5.6  Debian package development tools
ii  file   5.04-1Determines file type using "magic"
ii  gettext0.17-10   GNU Internationalization utilities
ii  intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libapt-pkg-perl0.1.24Perl interface to libapt-pkg
ii  libclass-accessor-perl 0.34-1Perl module that automatically gen
ii  libipc-run-perl0.84-1Perl module for running processes
ii  libparse-debianchangel 1.1.1-2   parse Debian changelogs and output
ii  libtimedate-perl   1.2000-1  collection of modules to manipulat
ii  liburi-perl1.53-1module to manipulate and access UR
ii  locales2.10.2-6  Embedded GNU C Library: National L
ii  man-db 2.5.7-2   on-line manual pager
ii  perl [libdigest-sha-pe 5.10.1-11 Larry Wall's Practical Extraction 

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch (no description available)
pn  libtext-template-perl  (no description available)
ii  man-db2.5.7-2on-line manual pager

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100327124013.5845.24569.report...@tsunami